EVOLUTION OF THE NEC NEAX 61E TOWARDS THE INTELLIGENT NETWORK Authors: NEC America, Inc.

Carl F. Reisig Jeremy Chiou Sushi1 Gill Tuan Pham
NEC Corporation

Kazuo Shimazaki Eiichi Murayama Toshiyuki Misu
ABSTRACT

separately from the operating software controlling t h e underlying switch structure.
NEAX 61 E EVOLUTION TOWARD THE INTELLIGENT NETWORK

NEC’s NEAX 61E switch is evolving toward the Intelligent Network with the addition of a n Application Services Processor (ASP). The ASP provides a services software platform which can be integrated into the NEAX 61E or deployed on a stand-alone basis. The concept of a Connection Control Model ( C C M ) is developed to provide a n interface between the basic switch s o f t w a r e a n d A S P . T h e CCM p r e s e n t s a l o g i c a l representation of a call’s status to the ASP. This approach means physical implementations within the NEAX 61E a r e invisible to the ASP, greatly simplifying the task of service creation.

INTRODUCTION

The public telecommunications network is under increasing pressure to offer the new and competitive services being demanded by o u r evolving i n f o r m a t i o n s o c i e t y . An Intelligent Network ( I N ) is being defined to address these needs. This IN must accomplish the following objectives: Provide Service Programmability - Service programming must be divorced from the underlying operating software of the public switching network. Traditionally, service software has been a n integral part of a switch’s operating software, thereby largely restricting service development to the switch vendors. Separating service logic from the underlying connection control logic of the switch allows the public network to use o t h e r sources, i n c l u d i n g themselves, for developing new services. Provide Timely Service Development - Because of the integration of service and operating software in the past, introduction of new services required a n upgrade of the switch generic program. Due to this process, the interval between service concept a n d implementation i s measured in years. A service development interval of 6 12 months is needed. Service Flexibility - Service flexibility has two aspects, the ability to tailor a service to a single user or group of users (service customization) and the ability to introduce services a t various locations based on market demand rather than type of switch deployed (service portability). Service flexibility is greatly enhanced in the intelligent network since service programmability i s under t h e network providers direct control and can be implemented

NEC’s NEAX 61E switch consists of four subsystems as i l l u s t r a t e d in F i g u r e 1. T h e Application s u b s y s t e m interfaces all lines, trunks and service circuits supported by the switch. Local call processors (LCP’s) a r e distributed within the various peripheral units to perform functions, sU’ch a s circuit monitoring, which are local to the circuit and therefore logically should be distributed throughout the architecture. The O p e r a t i o n s a n d M a i n t e n a n c e ( O N ) subsystem consists of the maintenance and administration terminal (MAT) and switch storage devices, a s well a s providing network communications (NCOM) channels to external terminals and operations support systems (OSS’s). The network subsystem consists of up to 22 interconnected time division switching networks able to support u p to 100,000 lines with their associated t r u n k s a n d service circuits. T h e f o u r t h s u b s y s t e m i s t h e NEAX 6 1 E p r o c e s s o r community. A redundant pair of call processors (CLP’s) a r e dedicated to each switching network. The C L P s house both connection control and service logic software for t h e i r network. All CLP‘s a r e connected via a n internal bus for interworking purposes. In addition to the CLP‘s, a s e t of processors (OMP’s) a r e dedicated to providing the O&M capabilities of the switch which a r e better supported on a centralized basis. The multi-processor architecture of the NEAX 61E allows a graceful e x p a n s i o n to s u p p o r t t h e I N c o n c e p t . An Application Services Processor (ASP) is added to the switch to provide a services software platform. This ASP will eventually be integrated into the basic switch architecture to provide maximum service capacity, but the initial version will be deployed a s part of the Application subsystem, with a standardized interface between t h e ASP and NEAX 61E. This version of the ASP will communicate with the processor subsystem over SS7 links, using a defined command set of functional components (FC’s). While the integrated and stand-alone versions of the ASP will use different interfaces into the NEAX 61E, they will provide identical services software platforms. The method of deploying the ASP will therefore be transparent to developed service logic. In developing the ASP, NEC has adopted t h e following design principles:

33A.4.1.
1212
CH2682-318910000-1212 $1 .OO

0 1989 IEEE

in this mode of deployment. which is used to interface with the ASP. Figure 3 also identifies the software modules t h a t a r e housed 4) O&M Integration . When the ASP is integrated into t h e basic switch. a gateway function converting to the synchronous X. the intelligent peripheral (ASP plus associated peripheral hardware) supports information path connections as well a s a signaling connection between itself and the NEAX 61E. communications will be via a defined command set of FC’s. The stand-alone version of t h e ASP ( u s i n g SS7 links to connect with the NEAX 61E) c a n be centrally located to support several switching locations. Use of this logical model allows a service on the ASP to interact with the conceptual connection conditions existing on the NEAX 61E without requiring any detailed knowledge of the physical condition of t h e switch. ASP DEPLOYMENT MODES Three possible modes of deployment. The Connection Control P a r t (CCP) comprises t h e major addition to e x i s t i n g s o f t w a r e w i t h i n t h e basic s w i t c h processor subsystem.Activity is currently u n d e r w a y to define a s t a n d a r d s e t of f u n c t i o n a l components (FC’s) to be used a s the command set for the Intelligent Network NEC i n t e n d s to s u p p o r t a n y standard which evolves for these FC’s.The ASP must provide full operations and maintenance capabilities for a n y services implemented on it and these O&M capabilities must be provided as a n integral part of the switch‘s O&M rather than on a stand-alone basis. identifying t h e software necessary to support the Intelligent Network via the ASP. Such a programming e n v i r o n m e n t m u s t also provide t h e software tools necessary for a service designer to work effectively. 5) M a i n t a i n I n t e g r i t y of C a l l C o n t r o l . While some stand-alone O&M capabilities will be necessary i n i t i a l l y . shown as the second deployment mode i n Figure 2.W i t h t h e introduction of the ASP. it would be possible to down-load services from the central ASP to local ASP‘s. This allows the service logic to be based on a conceptual rather than physical knowledge of t h e switch.25 interface into a packet network to also provide ASP service capabilities in that environment. though we will also offer a d d i t i o n a l n o n . The version selected would affect the physical implementation and total capacity of t h e ASP. the ASP serves the functions of the SCP defined in the Intelligent N e t w o r k c o n c e p t of B e l l C o m m u n i c a t i o n s R e s e a r c h (Bellcore). If asynchronous users (ex.The NEAX 61E addresses service logic and connection logic a s separate software layers. have been identified for the Application Services Processor. t h e switch processor s u b s y s t e m communicates with a stand-alone ASP over a standard SS7 link. In the case where both central and local ASP’s a r e deployed. as shown in Figure 2. but would be logically identical for service deployment purposes in both cases. NEC’s proprietary protocol would be used over the internal bus. services housed on different processors may be invoked during a single call. In both cases.4. Many services will require providing a user access to peripheral hardware such as a n announcement machine o r service d a t a base. The CCP is responsible for insuring the integrity of all calls invoking a service on t h e ASP. As explained e a r l i e r . This provides a graceful method of handling service deployment into the network. Therefore. overall responsibility for insuring the integrity of t h e call always remains the responsibility of t h e basic switch software. The service developer should “see” a logical representation of the network a t this interface rather than being required to know the actual physical implementation for each vendor. In this mode. A high level view of the NEAX 61E software architecture is shown in Figure 3. RS232) a r e to be supported in this type of application. While each service may “control” the call a t different instances. This would allow a n ASP service to provide such functions as selection menus to a user. 1213 . The basic modification required within this software is t h e addition of trigger and re-entry points to support interaction between the existing connection control logic and t h e service logic introduced on the ASP. 2) Build upon existing layered software . The ASP providing these services operates as a n integrated entity with the required peripheral hardware. 33A.2.s t a n d a r d FC’s as well to increase t h e capabilities available to t h e service designer. The third mode of implementation for t h e ASP is a s a n Intelligent Peripheral (IP). In addition to the control link.I) Provide a customer programming environment . To accomplish this. X.T h i s means to present a well defined and versatile interface between the services software platform and the service logic being developed. t o t a l system integration is a n important goal. with t h e connection logic r e s i d i n g between service logic and the switch’s operating system. The Service Control and Speech P a t h Control modules a r e e x i s t i n g NEAX 61E software providing the connection control layer and its underlying hardware server software respectively. NEAX 61E SOFTWARE ARCHITECTURE FOR THE INTELLIGENT NETWORK 3) Use a Standard “FC” Interface . o v e r a l l responsibility for t h e c a l l r e m a i n s with t h e C C P . While the instantaneous control of a call may be transferred between t h e basic switch processor a n d ASP. The calls c u r r e n t s t a t u s is logically represented by a Connection Control Module (CCM). t h e C C P m a i n t a i n s knowledge of t h e current status of all calls invoking a n ASP service. Or the ASP can be collocated with the NEAX 61E as a “local S C P . A possible future upgrade would be to support a n X. the ASP initiates a connection through the NEAX 61E from the user to the appropriate peripheral hardware. Such layering of the software leads to simpler service logic. T h i s conceptual interworking approach greatly simplifies the task of service development on the ASP. either a stand-alone or integrated version of the ASP can be deployed.25 links may be provided to the NEAX 61E network fabric to allow the ASP to act as a n integrated Intelligent Peripheral (IP). This application is for future study.25 protocol would have to be added. I n t h e s e situations. In this mode.

This greatly reduces the complexity of ASP service development. The method selected for implementing the ASP will be transparent to the services housed there. CCM and SLP‘s on the ASP. A basic call leg model is shown in Figure 5 to illustrate t h e possible s t a t e s a n d transitions for a basic two-party call. FC’s a r e not used between the BCPM and CCM. and traffic control as well as supporting 110 functions other than ASP-main switch communications. Movement from one s t a b l e s t a t e to a n o t h e r r e q u i r e s The promise of the Intelligent Network is to provide service programmability within t h e public t e l e c o m m u n i c a t i o n s network. If the trigger is active. The CCM creates a connection model for the call which will be used to provide call integrity for the interval that a n ASP service is active. Once the ASP based service is terminated. Part of a task within the CCM and ASP may be the sending or receiving of a n FC to support interaction. trunk or service c i r c u i t ) on a connection. but r a t h e r to demonstrate how this conceptual call model approach is used to control interaction. T o understand this conceptual approach. the state boxes within the ASP show a single leg connection (hold state) followed by two double leg connections (talking states). 1214 . u s i n g t h e Connection C o n t r o l Model. This capability will provide a much greater degree of service flexibility a n d e n a b l e more t i m e l y s e r v i c e development. In either case. To illustrate. The OAM section of the SLI software layer performs traffic measurement. This re-entry point may be a different point in the BCPM program t h a n t h e initiating trigger point.3. The Service Logic Programs (SLP’s) a r e the service scripts created by the service designer. c o m m u n i c a t i o n s between the BCPM and CCM are not a s straightforward as this description indicates. But the basic call leg model of Figure 5 illustrates the principles of this approach. Basic connection control can also be represented by a logical Basic Call Processing Model ( B C P M ) . The blank boxes represent stable states within the model. as for a three-way call.4. NEC defines a leg as a single termination (line. Each service developed will have one SLP. which provides coordination among all active service invocations and is responsible for t h e typical “housekeeping” t a s k s r e q u i r e d i n a m u l t i . While the service creation platform and i t s associated software development tools could be located within the ASP. concerning the s t a t u s of a call. T h i s provides a simpler image from which t h e s e r v i c e d e s i g n e r c a n work. with the O&M software supporting a n interface for the downloading of SLP’s which a r e ready to be placed into service. This figure is not meant to present a n actual call model. The existing separation of service and connection logic through a layered software approach and the use of a multiprocessor control architecture allow t h e NEAX 61E to gracefully evolve via the ASP. For purposes of example. The O&M module supports the service creation platform as well as t r a d i t i o n a l O&M interfaces and functions. the CCM terminates the connection model it had created for the call. a two-party call has one connection and two legs As the call topology becomes more complex. assume a basic call connection program is in progress within the NEAX 61E processor subsystem. At a given point in the program logic. 33A. t h e CCM will return control of the call to the BCPM a t some permitted program re-entry point. this would not be advisable due to t h e impact of mixing software development a n d service implementation in a single processor. Service operation is controlled by a Service Logic Manager (SLM). Interaction between these services and the supporting switch is accomplished through use of a defined command s e t of functional components (FC’s). the service designer m u s t know only t h e CCM c a l l control model a n d t h e associated trigger table setting possibilities.t a s k environment. So it is assumed t h a t service logic program development will be done on a dedicated processor.within the ASP. NEC is actively supporting t h e Intelligent Network concept on i t s NEAX 61E switch t h r o u g h t h e development of a n Application Services Processor (ASP). CONCLUSION The CCP and ASP interact on a conceptual r a t h e r t h a n physical level. information concerning the call is sent to the CCM. so does the associated call model. The heart of the ASP software architecture is the Service Logic Interpreter (SLI). NEAX 61E CONTROL MODEL REPRESENTATION performance of predefined tasks. But the service designer creating services for the ASP is protected from this complexity by the CCM. The program will check a t r i g g e r t a b l e to determine if the trigger point is active for this particular invocation. Since the existing software within the processor subsystem is not modularized to match t h e BCPM. The ASP can be integrated into the NEAX 61E processor community or implemented on a stand-alone basis. Rather. Once the BCPM has regained control of the call. For example. In F i g u r e 6. The CCM then informs t h e ASP of t h e service request via a n appropriate FC a n d i t s associated parameters. a conceptual approach is used to demonstrate interaction among the BCPM. This would be a logical state order for a SLP involving a twoparty connection which requires a n intermediate action to be performed by the NEAX 61E before t h e service c a n be completed. giving a more detailed picture of i t s organization. a trigger point has been activated. To control interaction between the ASP based service and NEAX 61E processor subsystem. The data manager and network interface manager provide t h e database management and ASP-basic switch communications functions respectively. The functional component m a n a g e r (FCM) handles the sending and receiving of FC’s and t h e FC library. trigger and re-entry points a r e located throughout the BCPM logic which can be set a s part of the service logic in a fashion similar to t h e establishment of translations in existing switches. it is necessary to know the possible stable states a call may occupy and the s t a t e transitions which a r e permitted. the program will either continue or interrupt processing depending on instructions in the trigger table. An expanded view of t h e SLI is shown in Figure 4. The ASP and CCM a r e now both tracking the call status and interacting via FC’s.

. I t was also shown that the concept of a call leg model can be used to create a Connection Control Model (CCM) within the main switch to present a logical view of a call’s status to the ASP. either in the stand-alone node or integrated into the NEAX 61E. it can serve as the SCP of Bellcore’s Intelligent Network concept. NEAX6l E System Application Network O/M 1 Processor Legend: )MI . thus making manipulations within the switch invisible to a service designer. Creation of the CCM approach makes physical manipulations within the switch invisible to a service designer. A high level view of the NEAX 61E software architecture illustrates how service logic deployed on the ASP interacts through the use of triggers with the underlying connection control logic controlling the physical switch.Service Information Path Gateway(if required) Control Signaling Path 0peration. Signaling MAT W C A M lYIb -Information Figure 2.* x 25 W Service Logic Interpreter 1 -- Printer OAM t ) \ f Real-Time Operating System Dirk i _ _ _ _ _ _ A : I OAM I ’ I 1-1 L-i . It can also serve a s a “local SCP”.Three modes of deployment have been described for the ASP.. NEAX 61 E Software Architecture 33A.. NEAX 61E System Architecture Processor Subsvstem Applications Service Processor I’ ‘ Service Logic Program _ _ _ _ _ _ _+ c . greatly simplifying the task of service creation.4.Administrationand Maintenance Figure 3.4... . ASP Deployment Modes Figure 1. 1215 .-. In a stand-alone implementation. The CCM is used to describe and control service interaction between the basic call processing model (BCPM) and services on the ASP.-.

FC Figure6. NEAX 61E Call Control Model for IN Services 33A. Logic Program / = I . MGR (NW Terminating I * Originating Terminating Holding Figure 5. Basic Call Leg Model Baric Switch ASP 0 5 Trigger Point ECPM Basic Call PrMernnp Model CCM Connect.Service Logic MGR 0 A (SLM) SLI Layer & M Data MGR (DM) Network INTF.4. n d ~"Tc ~uw an .5. 1216 .on Control Model SLP Servcic.

Sign up to vote on this title
UsefulNot useful