WO1999001992A2 - Acheminement base sur l'identification automatique du numero (ani) - Google Patents

Acheminement base sur l'identification automatique du numero (ani) Download PDF

Info

Publication number
WO1999001992A2
WO1999001992A2 PCT/US1998/013748 US9813748W WO9901992A2 WO 1999001992 A2 WO1999001992 A2 WO 1999001992A2 US 9813748 W US9813748 W US 9813748W WO 9901992 A2 WO9901992 A2 WO 9901992A2
Authority
WO
WIPO (PCT)
Prior art keywords
call
routing information
service
code
isp
Prior art date
Application number
PCT/US1998/013748
Other languages
English (en)
Other versions
WO1999001992A3 (fr
Inventor
Tasvir Shah
Lynn C. Daniel
Hu Shen
Comandur S. Kannan
Original Assignee
Dsc Telecom L.P.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Dsc Telecom L.P. filed Critical Dsc Telecom L.P.
Priority to AU82826/98A priority Critical patent/AU8282698A/en
Publication of WO1999001992A2 publication Critical patent/WO1999001992A2/fr
Publication of WO1999001992A3 publication Critical patent/WO1999001992A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/4228—Systems providing special services or facilities to subscribers in networks

Definitions

  • This invention relates in general to telecommunications and, more particularly, to devices for providing enhanced services.
  • AIN Advanced Intelligent Network
  • calls are routed by receiving a code indicative of the calling party in a switch, passing the code to an external database engine coupled to said switch, retrieving routing information based on said code in the database engine and sending said routing information to said switch.
  • Switches are inherently limited in the routing choices they can make.
  • an external database engine such as a service node with SCF functions, a virtually unlimited number of routing choices can be provided for, based on calling number, destination number, type of call, carrier, or other criteria. Similarly screening of calls could be provided as well. This ability allows a long distance company to provide services to other long distance providers with flexibility in services.
  • Figure 1 illustrates a block diagram of an ISP used in a communications system
  • Figure 2 illustrates a block diagram of a logical view of the ISP of Figure 1;
  • Figure 3 illustrates a flow chart of a service which could be provided by the
  • FIG. 4 illustrates a detailed block diagram of the ISP of Figure 2;
  • Figure 5 illustrates a block diagram of an SS7 stack of Figure 4.
  • FIG. 6 illustrates an ISP which can also be configured as an Network IP
  • Figure 7 illustrates a logical diagram of the ISP of Figure 6
  • Figure 8 illustrates a block diagram of the software layers of the Network IP
  • Figure 9 illustrates a detailed block diagram for the software layers shown in Figure 8.
  • Figure 10 illustrates the communications between subsystems in the Network IP
  • Figure 11 illustrates an embodiment for advanced long distance routing using an ISP
  • Figures 12a and 12b show a flow chart describing a method of long distance routing.
  • FIG. 1 illustrates a first embodiment of an ISP (Intelligent Service Peripheral) which allows enhanced services using non- AIN switches, such as a DSC DEX 600 switch (by DSC Communications Corporation of Dallas, Texas).
  • ISP Intelligent Service Peripheral
  • the ISP 10 is connected to a non- AIN switch 12 (along with other switches 14, which may be either AIN or non- AIN switches) through the SS7 network 16.
  • User devices, such as phones 18, are connected to the switches 12 and 14 through LECs (Local Exchange Carriers) 20.
  • LECs Local Exchange Carriers
  • the ISP 10 allows a service provider to provide enhanced features to its customers.
  • a calling party connected to a non- AIN switch 12 enters the number indicating a called party and the voice connection is set up between the originating and destination switches by the SS7 layer 16 in response to the number.
  • Features such as interactive voice prompting for additional information are not normally available over the non- AIN switch 12.
  • the ISP 10 overcomes many of the limitations of the non- AIN switch 12. Phone numbers associated with enhanced features are set in the non- AIN switch 12 to connect with ISP 10. The ISP 10 can then process the call using an internal application program as appropriate based on the phone number of the called party. For example, for a given phone number, the ISP 10 could return a connection path to the non- AIN switch 12 information based on the ANI (automatic number identification) received by the ISP 10 from the non- AIN switch 12. This would be useful, for example, if a company wanted to connect a customer to the nearest service location based on the customers area code. In another example, the ISP 10 could use voice prompts to receive a PIN (personal identification number) from the calling party.
  • PIN personal identification number
  • FIG. 2 illustrates a first embodiment of a logical structure for the ISP 10.
  • An SSF (service switching function) 22 is connected to the non- AIN switch 12 (through the SS7 layer 16).
  • the SSF is coupled to the SCF (service control function) 24 and to the SRF (specialized resource function) 26.
  • the SCF 22 is coupled to the SRF 26.
  • the SSF 22 is responsible for communicating with the non- AIN switch 12 and the SCF 24.
  • the SSF is also responsible for connecting the calling part to a resource located in the SRF 26 at the request of the SCF 24.
  • the SSF can be implemented similarly to a SSP (service switching point).
  • the SCF 24 receives messages from the SSF 22, executes SLPs (service logic programs) and sends messages to the SSF 22.
  • the SCF 22 also communicates with the SRF 26 to provide instructions when the SRF 26 is interacting with a user.
  • the SCF 24 can be implemented by an SCP (a service control point, which is commonly used in the SS7 network for providing a database) and a SLI (service language interpreter, for interpreting SLP instructions to implement the enhanced features).
  • the SRF provides resources such as voice announcements, DTMF (dual tone multifrequency) digit collection, and other multimedia functions.
  • FIG. 3 illustrates an example of the use of the ISP 10 to provide enhanced functionality compatible with non-AIN switches.
  • SAC service access code
  • N00/888 service access code translation
  • An incoming call ISUP/SS7 is received by the SSF 22 from the non-AIN switch 12 (block 30).
  • the SAC number is sent from the non-AIN switch 12 to the SCF 24 for validation. If the number is invalid in decision block 32, the call is denied in block 34 and the SCF 24 instructs the SRF 26 to play an announcement corresponding to the denial in block 36. If the call is valid in decision block 32, the SRF 26 is instructed by the SCF 24 to prompt the user for PIN numbers and collect the DTMF digits from the user in block 38.
  • the SCF 24 looks up the translated number and generates routing information in block 44.
  • the translated number and routing information is sent by the SSF 22 to the non-AIN switch 12, which completes the connection to the proper destination switch 14. If a proper PIN is not collected in block 40 or if a valid PIN is not collected in block 42, an error procedure is invoked. In blocks 48 and 50, the user is given a predetermined number of attempts to provide a proper and valid PIN.
  • the user is either forwarded to customer service (using the SRF 26 to announce the forwarding step and the SCP to generate the connection information for completing the connection at the non-AIN switch 12) or an error message is generated by the SRF 26 indicating the proper number to call.
  • Figure 4 illustrates a specific embodiment of the ISP 10, using dual SUN SOLARIS computers. It should be noted that the allocation of processes between computers shown in Figure 4 is for illustrative purposes only; the number of computers used in a particular SSF 22 can vary upon the power of the computer and the desired capacity and complexity of the specialized resources.
  • the SS7/ISUP data stream from a non-AIN switch 12 is received at the SS7 stack 50.
  • the SS7 stack 50 is connected to the SSF 22, which includes state machine 52, BCM (Basic Call Manager) 54, FIM (Feature Interaction Manager) 56 and IN-SM (IN Switching Manager) 58.
  • the SCF 24 is connected to the SSF through the FIM 56 and to the SRF 26 through a MPU (multimedia processing unit) Manager 60.
  • the BCM 54 and the state machine 52 of the SSF 22 are also in communication with the MPU Manager 60.
  • the SRF contains one or more multimedia processes (MPs) 62.
  • the MPs 62 execute the various features provided by the SRF 26, such as announcement capability and DTMF digit collection. In the illustrated embodiment, the MPs 62 are executed by a first computer 70a and the remaining functions of the ISP 10 are executed by a second computer 70b.
  • the SS7 stack 50 provides an SS7 interface including MTP1, MPT2, MPT3 and
  • the SS7 interface encodes and decodes the ISUP messages to and from the non-AIN switch 12.
  • the SS7 stack 50 is divided into three main functional areas as shown in connection with Figure 5: an MTP1,2,3 layer 72, and ISUP layer 74 and an ISUP access layer 76.
  • the ISUP layer 74 is divided into three functional areas: a SPRC (signaling procedure control) area 78 provides forward and backward message distribution procedures, a CPC (call processing control) area 80 provides basic circuit switched service procedures and a CSC (circuit supervision control) area 82 provides circuit maintenance and recovery procedures.
  • SPRC signalling procedure control
  • CPC call processing control
  • CSC circuit supervision control
  • the ISUP Access layer 76 converts the ISUP message to/ from signal independent C++ messages and transfers the messages to the state machine 52/ BCM 54 and the MPU Manager 60.
  • the SSF 22 includes the state machine 52 for processing service requests.
  • the state machine 52 tracks the state transitions for a service request as it is processed by the various components of ISP 10.
  • the state machine 52 assigns a transaction ID to the service request and saves any information need to process the request in a call control instance.
  • BCM 54 provides basic call modeling for the protocol associated with each service request message.
  • FIM 56 determines which SCF features are associated with each service request.
  • the IN-SM 58 routes service requests to the SCF 24 and MPU Manager 60.
  • the SSF 22 receives ISUP service request messages from the SS7 interface and controls the call processing and messaging between the SSF 22, SCF 24, the SRF 26, and the SS7 stack 50.
  • SSF processing begins with an ISUP service related message received over the SS7 link and converted to a C++ object including SS7 header information.
  • SSF 22 performs the following call processing related functions:
  • Origination Point Code in the non-AIN switch 12.
  • the SCP When the SCP receives the IDP message, it will process the IDP message and sends back one of the following INAP messages to the SSF: 1) "Connect", indicating call service completion to a Called Party
  • the SLP may provide a call completion index which will point to a routing table in Sybase (or other network). In this case, the SSF 22 will retrieve the routing table and package it in the ISUP connect message sent to the non-AIN switch 12. 2) "Release Call” (RC)
  • SSF receives "Release Call” from the SCP, then SSF will send all ISUP "Release trunk” (REL) message hack to the non-AIN switch 12 and terminate call processing. If "Connect” is received, then the SSF sends an ISUP RLT to the non-AIN switch 12 and terminates call processing.
  • REL Release trunk
  • the SSF 22 can receive a "Release Trunk” (REL) message from the non-AIN switch 12 which will result in a UABORT message sent to the SCP and MP along with the necessary Transaction ID and Trunk Circuit Code.
  • REL Release Trunk
  • the SSF completes UABORT by sending a RLC back to the non-AIN switch 12
  • the SSF 22 accesses ISUP call service requests through an ISUP C++ message object which provides interfaces for getting and setting message parameters. SSF 22 will capture all origination information necessary to generate a reply to the non-AIN switch 12 switch.
  • the SSF 22 will be able to access trunk status through the MPU Manager interface.
  • the SSF 22 has access to a trigger point database which allows translation of ISUP service requests to the internal service key used to access an SCP service.
  • the SSF 22 supports an MMI interface which displays summary call statistics and individual call status for system debug purposes.
  • the SSF call status includes a summary history of messaging between the SSF, SCP, and MPU. In addition, total call processing time for each call in the history buffer is maintained.
  • System TRACE messages plays all messages that are received and sent by SSF 22 along with their call processing state transitions.
  • the State Machine object provides the interface to the ISUP access for sending and receiving ISUP messages. It captures the Call Control Instance associated with a service request, validates the circuit assignment for the service notifies the MPU, and forwards the ISUP request to the INMGR.
  • the Call Control Instance provides storage and coordination between the SM, INMGR and MPU for service processing.
  • the CCI includes the following:
  • the IN-SM 58 Calls SSM (Service Specific Mapper) to map service specific parameters from ISUP to INAP and provides the SSF/ INAP Call Model.
  • SSM Service Specific Mapper
  • the IN-SM 58 determines which INAP message sequence to expect for interfacing to the SCP and provides state control, timeout and transitioning for the INAP messages to/ from the SCP.
  • SSM Service Specific Mapping
  • the MPU Manger 60 receives INAP MPU service request messages from the SCF 24 and the SSF 22. In addition, it maintains the trunk database and processes trunk maintenance messages.
  • the responsibilities of the MPU manager 60 include: 1) Receive INAP instructions to play an announcement and/ or play announcement and collect digits;
  • the MPU manager 60 Upon receiving instructions to play announcement and/ or collect digits, the MPU manager 60 determines which MP will handle the request. It then informs the appropriate MP to perform the action. The MPU manager 60 also times the action to verify the MP sends back the appropriate results. If a time-out occurs, the MPU manager issues the appropriate message back to the requester stating the error.
  • MPU manager 60 Upon receipt of CIC- Assigned, MPU manager 60 will do the following:
  • MPU manager 60 Upon receipt of CIC-In Use, MPU manager 60 will do file following: • Convert CIC code into appropriate Span and circuit number.
  • MPU manager 60 Upon receipt of CIC-Release, MPU manager 60 will do file following:
  • MPU manager 60 Upon receipt of Play Announcement message, MPU manager 60 will do the following:
  • MPU manager 60 Upon receipt of Prompt and Collect User Information message, MPU manager 60 will do the following:
  • MPU manager 60 Upon receipt of "Play Announcement” response from MPU, MPU manager 60 will do the following:
  • MPU manager 60 Upon receipt of "PAC" response from MPU, MPU manager 60 will do the following:
  • MPU manager 60 Upon timeout of "Play Announcement” or "PAC" response from MPU, MPU manager 60 will do the following:
  • MPU manager 60 • Format and send the appropriate 'NAP message back to the SCP with an error indication.
  • MPU manager 60 Upon timeout of "ARI" response from SCP, MPU manager 60 will do the following:
  • MPU manager 60 Upon receipt of "Play Announcement” or "Prompt and Collect User Information” CANCEL message, MPU manager 60 will do the following: • Convert CIC code into appropriate Span and circuit number.
  • Figures 6 - 10 illustrate an embodiment of a device which can be configured as either as an ISP 10, complete with SSF, SCF and SRF capabilities, or as a Network IP (intelligent peripheral), without the SCF.
  • the ability to configure the device as either a ISP or an IP allows greater flexibility in configuring a device to the needs of a customer.
  • FIG. 6 illustrates a block diagram of an ISP/ IP 90, along with connections to a variety of devices.
  • the ISP/ IP 90 would be connected to some, but not all of the devices shown. Further, the ISP/ IP 90 could be connected to other devices by providing a suitable interface, as discussed below.
  • the ISP/ IP 90 comprises a NetworkIP 92 and an SCP 94.
  • the NetworkIP 92 implements the SSF and SRF functions described above.
  • the SCP 94 implements the SCF functions.
  • the ISP/ IP 90 can be used with the SCP 94 as an ISP, or without the SCP 94 as just the NetworkIP 92.
  • the ISP/ IP 90, through the NetworkIP 92 can be connected to a non-AIN switch 12 using a ISUP/SS7 connection for signaling and a Tl connection for audio transmissions from the SRF.
  • the NetworkIP 92 could be connected to other switches, such as Class 3/5 switches 96, other Class 5 switches 98 or to a wireless system including a MSC (Mobile Switch Center, a switch for the wireless system) 100 and a HLR (home location register, roughly equivalent to an SCP for the wireless system) 102.
  • the NetworkIP 92 could also be connected to other AIN SSPs 104 or to an AIN SCP 106.
  • the flexibility of the ISP/ IP 90 allows a vendor to use a single hardware platform to provide solutions to various customer needs. Further, a customer with a need for specialized functions in a variety of situations can use ISP/ IPs 90 in a variety of situations, simplifying maintenance problems associated with having separate devices for each situation.
  • a customer already has purchased an SCP and would like to add DTMF digit collection capabilities to a non-AIN switch 12, that customer can purchase the NetworkIP 92, rather than the entire ISP with the SCP, thereby saving cost. Further, that customer can purchase other ISP/ IPs 90 for connection to other switches in its communications network.
  • the customer gains by reducing the number of different hardware platforms in its system, and the vendor gains by reducing the engineering effort needed to address a customer's particular needs.
  • the ISP subsystems can be implemented using multiple computers coupled by a network, or by a single computer.
  • the number of computers needed for an application will depend upon the power of the computer and the number and complexity of the enhanced features supported by the ISP.
  • FIG. 7 A block diagram of the ISP/ IP 90 is shown in Figure 7.
  • the ISP/ IP 90 when configured as an ISP includes an SSF 22, SCF 24 and an SRF 26.
  • the components of the ISP/ IP 90 are configured slightly differently from the ISP 10 of Figure 2.
  • the SRF 26 is not directly coupled to the SCF 24. Accordingly, instructions for the SRF 26 come from the SSF 22.
  • NetworkIP 92 when the SCF function is not provided in the ISP/ IP 90.
  • Figure 8 illustrates a logical software architectural view of the ISP/ IP 90.
  • Four layers are shown: an access layer 110, a service framework layer 112, a service application layer 114, and an OAM & P (Operation, Administration, Maintenance, and Provisioning) layer 116.
  • Figure 9 illustrates each layer in greater detail.
  • an ISUP Engine 118 three subsystems are shown: an ISUP Engine 118, an ISDN engine 120, and one or more MPU Agents 122.
  • the service framework layer 112 four subsystems are shown: a Basic Call Processing Engine 124, a Resource Manager 126, a Basic IN-IP Manager 128 and a Database Server 130.
  • the service application layer may comprise one or more Specific Service Feature Managers 131 for each feature provided.
  • the OAM&P layer 116 comprises a PeerNetworkIP 132, an OAM&P Agent 133 and a Presentation Module 134. It should be noted that other subsystems could be provided at each layer, depending upon the functionality desired for a specific design. With reference to Figures 8 and 9, the layers that house the NetworkIP subsystems are described below:
  • the Access Layer 110 contains subsystems that provide access to external networks. This includes the signaling network access and media access for specialized resource handling. These subsystems contain logical component called ProtocolBroker to perform adaptation functions to convert the various external protocol format to an internal universal format. ProtocolBrokers are intermediate agents to hide the various specific protocol interface to the rest of the components of the NetworkIP system because they adapt/ convert from different protocol messages to an internal universal messages.
  • the Protocols mentioned here are for both call setup related protocols such as ISUP, ISDN, and IS-93, and TCAP related protocols such as INAP, AINAP, and IS-41.
  • the Service Framework Layer contains subsystems that provide the basic call processing, resource handling, and message distribution capabilities.
  • This framework layer is the foundation for the NetworkIP 92 to build upon to provide various service features. New service-features can be added by re-using the same infra structure offered by the framework as the previous service feature uses.
  • the framework layer could support Voice/ Data Interworking and Data Gateway functionality.
  • the Voice/ Data Interworking function provides the interworking between voice related service and data service. It is a conversion and bridging service such as the voiceband modem pool being used to deposit a custom short message by the caller's computer dial-up connection to a subscriber that is handled by a Short Message Service Message Center (a NetworkIP specific service feature Application Entity).
  • the Data Gateway function provides data access to data networks.
  • Database Server 130 handles database related transactions to access data.
  • BasicCallProcessingEngine 124 handles Basic Call State Model for both Originating Call Segment and Terminating Call Segment.
  • the BasicCallProcessingEngine 124 provides a common context for call processing in the NetworkIP system.
  • ResourceManager 126 handles both specialized resource and regular resource handling on the behalf of the other components within the NetworkIP system.
  • the examples of specialized resources are DTMF digit collection, announcements, and so on, and the regular resources can be listed as circuit, trunk group assignment management, among others.
  • BasicIN-IP Manager 128 handles IN-IP related transactions and interfaces to SCP/HLR.
  • the Service Application Layer 114 contains subsystems that provide specific service features that the NetworkIP 92 supports. These subsystems utilize the core capabilities of the Service Framework Layer 112 to accomplish its goals.
  • the OAM&P Layer 116 provides several functions. These can be listed as statistic collection, event report, IPR, logging, alarm management, fault management, configuration management, subscriber and service update, billing, craft interface and similar functions.
  • the OAM&P Layer 116 also provides housekeeping functions such as back-up, usage monitoring, and diagnostics and provides cooperation with external manager to carry out the OAM&P functionality as an agent by interacting with Network Operation/ Management Center.
  • the OMAP layer 116 interfaces with the SCE (service creation environment) for service logic deployments that are supported by the NetworkIP system.
  • a low level communication called Message Distribution Layer 117 is treated as an embedded layer that allows messages to be exchanged among the entities within NetworkIP system.
  • Figure 10 illustrates a block diagram describing the interfaces among the Network IP subsystems at the application level shown in Figure 9.
  • the NetworkIP 92 is designed to accept various protocols, as shown in Figure 6.
  • a universal protocol i.e., not dependent upon an external protocol
  • a particular universal internal protocol is described herein, the Universal Service Application Protocol (USAP).
  • USAP is an internal connectionless object oriented application protocol to allow NetworkIP subsystems to exchange messages to each other.
  • the USAP is composed of a header followed by binary variable length data to contain the structured data of a particular message object.
  • the USAP transports the object data as binary data where the receiver retrieves the binary data to initialize the object that is referred in the header.
  • the receiver pre-fabricates these objects, which are called vacant objects.
  • the vacant objects become alive when they are initialized with the binary data from the USAP protocol data unit (PDU) binary data portion.
  • the USAP does not know about the structure of the data that it carries, only information about it (meta data) which is contained.
  • the meta data in this case is also self describing data. There is no dependence between USAP protocol and the object data.
  • mapping between an external protocol is accomplished by the protocol broker component 118.
  • the USAP can be implemented using a low level communication such as memory-mapped 10 for transporting binary data; i.e., passing a reference to the receiver to improve performance within a machine.
  • a low level communication such as memory-mapped 10 for transporting binary data; i.e., passing a reference to the receiver to improve performance within a machine.
  • an inter-process communication interface or the regular socket interface can be used as intermediate step to transport the meta data using TCP/IP.
  • the binary data portion of the USAP PDU is populated with a particular object data and the USAP header contains the identity of this object. This mechanism allows the USAP PDU to transport many object data types easily since it is typeless.
  • the ISUPEngine subsystem resides at the Access Layer of the NetworkIP system to provide ISUP protocol access to signaling network. It includes an ISUPBroker component to adapt/ convert between ISUP messages and internal USAP messages (and vice versa), and an ISUPStateMachines component to support the ISUP protocol.
  • the ISUPEngine (a)supports the ANSI ISUP protocol over SS7 MTP, (b) exchanges circuit related managements with the ResourceManager- TrunkManager, (c) exchanges generic call setup information with the BasicCallProcessingEngine, (d) performs adaptation/ conversion of the ISUP PDU to internal USAP message format (and vice versa), (e) utilizes a configuration mechanism to initialize its internal operating data such as CIC, Point Codes, Timers, and (f) exchanges timed-out notifications to the BasicCallProcessingEngine.
  • the ISUPEngine has the following interfaces:
  • the ISDNEngine subsystem resides at the Access Layer of the NetworkIP system to provide ISDN protocol access to signaling network. It includes an
  • ISDNBroker component to adapt/ convert between ISDN messages and internal USAP message (and vice versa) and an ISDNStateMachines component to support the ISDN protocol.
  • the ISDNEngine (a) supports the ITU-ISDN protocol, (b) exchanges circuit related managements with the ResourceManager-TrunkManager, (c) exchanges generic call setup information with the BasicCallProcessingEngine, (d) performs adaptation/ conversion of the ISDN PDU to internal USAP message format (and vice versa), (e) utilizes a configuration mechanism to initialize its internal operating data and (f) exchanges timed-out notifications to the BasicCallProcessingEngine.
  • the ISDNEngine has the following interfaces:
  • vendor specific APIs or class library to interface to the vendor ISDN subsystem.
  • the MPU Agent subsystem resides the Access Layer of the NetworkIP subsystem and it contains various Media Processors (MPs) to access to the specialized resources. These specialized resources can be listed as announcements, voice recognition devices, DTMF digit collection, audio conference bridge, text-to- speech, and so on.
  • MPs Media Processors
  • the MPU Agent executes commands from MPUManager and responds with the results.
  • a sample of commands can be listed as: play announcement, collect digits or a combination of the above,
  • the MPUAgent has the following interfaces:
  • vendor specific APIs or class library to interface to the vendor subsystem for a particular media.
  • the BasicCallProcessingEngine subsystem resides in the Service Framework Layer of the NetworkIP system. It includes a FeatureSelectlNteractManager component to select which service-features need to be handled by the IP Feature- Manager or by the SCP via BasicIN-IPManager, and the interactions if needed among the service features. This component is designed to be based on the ITU-IN Feature Interaction Manager/ Call Manager model as described in the ITU Q.1214.
  • the BasicCallProcessingEngine subsystem further includes a BasicCallManager component to handle the Basic Call State Model for both Originating and Terminating segments. This component is designed to be based on the ITU-IN Basic Call Manager model as described in the ITU Q.1214.
  • the BasicCallProcessingEngine uses an object oriented Basic Call State Model that is based on the BellCore 1298, AIN 0.2 call model.
  • the Basic Call State Model (BCSM) is a state machine to establish, maintain, and provide connection control the communication paths (both originating and terminating call segments) for users.
  • the BCSM reports the IN events that require the invocation of the IN service logics.
  • Call State exception handling is followed as specified by BellCore 1298 call model.
  • the BasicCallProcessingEngine subsystem selects which service logic instance need to be invoked locally via the NetworkIP application server or the SCP service logic program in order to accomplish a particular service-feature. The selection mechanism is based on the analyzing of the called digits.
  • the BasicCallProcessingEngine subsystem exchanges generic call setup protocol data units with the Protocol Engine such as ISUPEngine and processes the timed-out notifications that are received from the Protocol Engine such as ISUPEngine.
  • the BasicCallManager does not have any timers associated with the Call Setup Protocol activities in its state machine such as timed-out while waiting on ACM or ANM of the ISUP call.
  • the BasicCallProcessingEngine subsystem reports IN events to either the BasicIN-IP Manager or the ApplicationFeatureManager.
  • the call context information is exported to either the BasicIN-IP Manager or the ApplicationFeatureManager. It further analyzes and executes the instructions in the received responses from either the BasicIN-IP Manager or the ApplicationFeatureManager.
  • BasicCallProcessingEngine subsystem requests the circuit assignment, validation with the ResourceManager-TrunkManager in order to process the basic call, uses a configuration mechanism to initialize its internal operating data and uses asynchronous message processing (non-blocking wait on response). This requires message context information need to be saved for later correlations.
  • the BasicCallProcessingEngine subsystem has the following interfaces: • an USAP interface to Resource Manager-Trunk Manager.
  • USAP header indicates the Resource Related category.
  • the ResourceManager subsystem resides in the Service Framework Layer of the NetworkIP system. It includes a Trunk Manager to manage the circuit, trunk group resources, and an MPUManager to manage the specialized resources such as DTMF digit collection and announcements.
  • the Resource Manager processes CIC, trunk resource requests from clients by managing the CIC assignment, maintaining the circuit state, and converting back and forth between the trunk span and circuit identifier to CIC (it is stateless since the clients have state machines), (b) supports configuration activities to provision the circuit, trunk, trunk group database, (c) processes specialized resource requests (collect digit, play announcement, text-to-speech, or combination of them) from clients by issuing commands to and obtaining results from MPU Agents (it is stateless since the clients have state machines), (d) managing MPU Agents to allow clients to access to a pool of media resources, (e) performs resource house-keeping (keep track of resource states and generating IPRs and execute appropriate actions if there are errors encounter) for both specialized and regular resources (the regular resources house-keeping functions include processing circuit management messages and maintaining the trunk database), (f) exchanges circuit management activities with the Protocol Engines such as ISUPEngine and (g) uses asynchronous message processing (non-blocking wait on response). This requires message context information need to
  • the ResourceManager subsystem has the following interfaces: • an USAP interface to BasicCallProcessingEngine.
  • the USAP header indicates the Resource Related category.
  • the BasicIN-IP Manager subsystem resides in the Service Framework Layer of the NetworkIP system. It includes a SRF StateMachine (SRFSM) component supporting the SRF states to handle the specialized resource activities (this component is designed to be based on the ITU-IN SRF FSM as described in the ITU Q.1218 and ETSI) and a IN-SwitchingManager (INSwMgr) component to interact with SCF in the course of providing IN service features.
  • SRFSM SRF StateMachine
  • IN-SwitchingManager IN-SwitchingManager
  • This component is designed to be based on the ITU-IN Switching Manager model as described in the ITU Q.1214.
  • the NetworkIP INSwMgr is also designed to be based on ITU-IN SSF FSM as described in the ITU Q.1218 and ETSI. This component is scaled down if the NetworkIP is deployed as a stand-alone IP system; not ISP.
  • the BasicIN-IP Manager also includes an INAPBroker+TCAPlibrary component to handle INAP protocol on top of TCAP over IPC.
  • other protocol such as AINAP or 1S41 can be plugged in without changing the internal messaging format.
  • This component is designed to be compliant with the ITU-INAP as described in the ITU Q.1218.
  • the INAPBroker+TCAPlibrary component could alternatively be located in the Access layer.
  • the BasicIN-IP Manager (a) commands the specialized resource activities in the course of providing IN service features by using SRF State Machine and by exchanging internal messages with the MPUManager.
  • the error recovery procedure is followed as specified in the ITU-IN SRF FSM and ETSI;
  • (b) interacts with SCP in the course of providing IN service features by using SSF State Machine in the relaying mode, and by exchanging INAP TCAP transactions that utilize Service Key as appropriate. If the NetworkIP is deployed as a stand-alone IP system (not ISP Service Node), then this function is scaled down to just simply provides the INAP/TCAP transaction interface for the SRF State Machine.
  • the error recovery procedure is followed as specified in the ITU-IN SSF FSM, ETSI, and ANSI TCAP;
  • (c) serves the ApplicationFeatureManagers needs in accessing SCP service logic database via INAP/TCAP protocol. This requires the BasicIN-IP Manager to manage the TCAP transactions on the behalf of the servers and to support a mechanism to route an internal responded messages back to which server that participates in a given transaction;
  • (e) processes IN events and coordinates with the BasicCallProcessingEngine-FeatureSelectlnteractManager to perform feature interactions among the service logic instances; (f) uses a configuration mechanism to setup the operating mode of the NetworkIP as ISP or IP, and to initialize its internal operating data as well as protocol association such as INAP or MNAP or 1S41 (or other); and (g) uses asynchronous message processing (non-blocking wait on response). This requires message context information need to be saved for later correlations.
  • the BasicIN-IP Manager subsystem has the following interfaces:
  • the DataBaseServer resides in the Service Framework Layer.
  • the DataBaseServer includes a Database Request Broker to handle external requests to the DatabaseServer.
  • This DBMS interface could have an object-oriented interface (such as ROGUEWAVE dbtool++), or standard SQL, or OQL (Object Query
  • the DataBaseServer further includes a Database Transaction Manager to manage the database transactions to ensure data integrity and concurrency among database users and a Database Server Engine to manage the persistent data resources.
  • the DatabaseServer processes database requests from the clients, performs database transaction management to ensure the data integrity and to resolve dead lock and manages the data resources on the behalf of the clients including fail-over, back-up, restore, and provisioning.
  • the DatabaseServer has the following interfaces: a DBMS interface to ResourceManager a DBMS interface to ApplicationFeatureManager a DBMS interface to BasicIN-IP Manager a DBMS interface to BasicCallProcessingEngine a DBMS interface to OAM&P Layer.
  • the Specific Service Feature Manager subsystem resides in the Service Application Layer of the NetworkIP system.
  • the Specific Service Feature Manager subsystem includes a FeatureManager Service Logic State Machine component to support a specific state machine for a particular IP service feature (Debit Card, Voice Mail, Fax Messaging, Short Message, and so on) and a the SRF StateMachine
  • SRFSM SRF-IN SRF FSM
  • ITU Q.1218 ITU-IN SRF FSM
  • the Specific Service Feature Manager a) commands the specialized resource activities in the course of providing IP specific service features by using SRF State Machine and by exchanging internal messages with the MPUManager. The error recovery procedure is followed as specified in the ITU-IN SRF FSM. b) interacts with SCP on a needed basis in the course of providing
  • IP specific service features via BasicIN-IPManager subsystem.
  • c) exchanges internal generic protocol independent IN events and responses with the BasicCallProcessingEngine- BasicCallManager to direct the BCSM during the course of providing IP specific service feature.
  • d) processes IN events and coordinates with the BasicCallProcessingEngine-FeatureSelectlNteractManager to perform feature interactions among the service logic instances. This function is for future iteration.
  • e) uses a configuration mechanism to initialize its internal operating data.
  • f) uses asynchronous message processing (non-blocking wait on response). This requires context information (state) need to be saved for later correlations.
  • the Specific Service Feature Manager subsystem has the following interfaces:
  • the OAM&P Layer contains subsystems to support the general OAM&P tasks, the craft interface, and the peer NetworkIP interface.
  • the OAM&P Layer supports a GUI (Graphical User Interface) and an OAM&P.
  • the configuration management includes NetworkIP system tables, application tables, trunk tables, operation and measurement tables, and log tables.
  • the OAM&P has the following interfaces: • craft interface
  • FIG. 6-10 illustrates an IP in a number of different circumstances.
  • Using an internal protocol independent of the external protocol (s) to communicate between subsystems of the NetworkIP allows the device to be easily modified and expanded as circumstances require.
  • Figures 11 - 12 illustrate an ANISR (automatic number identification specific routing) which provides routing based on a user's ANI (or authorization code).
  • the ANISR service could be used by CLDCs (competitive long distance carriers) who provide a point of presence (POP) to other long distance carriers (OCLDCs) on the LEC (local exchange carrier) network.
  • CLDCs competitive long distance carriers
  • POP point of presence
  • OLDCs long distance carriers
  • LEC local exchange carrier
  • FIG 11 illustrates a setup for using ANISR for a specific OCLDC ("Carrierl").
  • LEC switches 130 (individually referenced as 130a and 130b) are coupled home switches 132 (individually referenced as 132a and 132b).
  • Home switches 132a and 132b are coupled to ISP 10 (which could also be ISP/IP 90, or another IP device with similar features).
  • Home switches 132 are coupled to carrier switches 134 (individually referenced as 134a through 134e).
  • home switch 132a is coupled to carrier switches 134a and 134b
  • home switch 132b is coupled to carrier switches 134b through 134e.
  • the CLDC may have one or more home switches 132 coupled to the ISP 10.
  • the OCLDCs supported by the CLDC may set up dedicated trunk groups which terminate on the home switches 132. Calls which originate from ANIs or authorization codes subscribing to the OCLDCs are routed over the dedicated trunk groups belonging to the OCLDCs. If there are no dedicated trunk groups for the dialed number, the calls are routed over the CLDC network.
  • ANISR In operation, long distance calls associated with an OCLDCs using the ANISR service are routed by one of the LECs 130 to an associated home switch 132.
  • the SCF of the ISP 10 is accessed to get a route list based on a "CarrierlD".
  • the "CarrierlD" can be determined through the authorization code or the ANI associated with the call.
  • the SCF based on the ANI (or authorization code), reads the route list associated with the subscribed CarrierlD and returns routing information to the SSF.
  • the SSF routes the call back to the home switch 132 with terminating routing information.
  • ANISR allows routing information to be dependent upon a number of factors.
  • ANISR can support Call Type routing where terminating route lists are based on the type of call, as shown in Figure 11. The following call types can be supported:
  • a second type of routing which may be supported by ANISR is Origin Based routing.
  • This type of routing may be used where an OCLDC has more than one point of presence (POP), i.e., it has terminating routes on more than one home switch 132.
  • POP point of presence
  • Carrierl has two points of presence, since it has terminating routes on two home switches.
  • Origin Based routing the terminating route lists are based upon the home switch accessing the ISP 10 (via the CarrierlD), as well as on the type of call.
  • a third type of routing is based upon the first three digits (NPA) or six digits (NPA/ NXX) of the called number.
  • the ISP 10 will first search for a route list corresponding to the CarrierlD based on the NPA/ NXX of the called number. If there is no match on the NPA/ NXX, the ISP 10 will then search for a route list corresponding to the CarrierlD based on the NPA of the called number. If there is no match on the NPA, the ISP 10 will provide the default route list assigned for 1+ calls in the CarrierlD table (described below).
  • the home switch give an ATB (all trunks busy) treatment to the call.
  • Figures 12a and 12b show a flow chart further describing operation of ANISR.
  • a call requiring ANISR is routed to the ISP 10 over a home switch 132.
  • the ISP determines the CarrierlD in block 140 by accessing the Authorization Code
  • the Route List Index for that call type is read from the corresponding field of the CarrierlD Table for that call type in block 148.
  • the NPA/NXX Table is accessed responsive to the appropriate CarrierlD and the first six digits of the called number in block 152. If no match is found, then the NPA/NXX Table is accessed responsive to the appropriate CarrierlD and the first three digits of the called number. If a match is found in decision block 154, then the Route List Index is obtained from that record of the NPA/NXX Table. If no match is found to either the six digit or the three digit field, then the Route List Index for 1+ (DDD) calls is read from the CarrierlD Table in block 148.
  • DDD Route List Index for 1+
  • the terminating route list is obtained from the Route List Table in block 158, if the Route List Index is not NULL in decision block 156.
  • the ISP returns a CONNECT with TRP (termination route package) 3 if VPN (virtual private network), else TRP 5, requesting the home switch to route the call based on the terminating route list accessed in block 158.
  • the terminating route list is based on the TPART/ OPART of the ANI and the called number in block 162.
  • a CONNECT is sent from the ISP 10 to the home switch 132 with TRP 7 for VPN or TRP 6 otherwise.
  • ANISR could be further enhanced to offer other services. For example, call screening could be offered to customers where, based on the ANI (or authorization code), certain numbers or groups of numbers could be made inaccessible. Such a feature could use a table linked to the ANI and Authorization Code Service tables to lookup a number prior to forming a connection.
  • Time of day routing could be used to route calls differently based on the time of day for certain ANIs or authorization codes.
  • VPN virtual private network
  • a virtual private network in addition to the VPN capabilities of the home switch, could be used to offer specific plans to companies, allowing enhanced features such as short dialing between sites.
  • ANISR provides significant advantages to long distance carriers, because it expands the capability of the switch to use different routes for different customers beyond that which would be available using the TPART of a home switch, which limits the routing options. With the addition of the ISP, the options for routing, or screening, are virtually unlimited. ANISR provides the capability to perform routing (or screening) responsive to ANI/ authorization code, call type, incoming trunk, time, destination or carrier. OCLDCs which have a partial infrastructure can benefit from enhanced services through another provider. Enhancements to the services can be made easily by the provider using an SCE (service creation environment).
  • SCE service creation environment

Abstract

Selon cette invention, un périphérique de service intelligent, ou ISP (10), permet de réaliser des fonctions améliorées compatibles avec les commutateurs n'appartenant pas au type AIN (réseau intelligent évolué). Les prestataires de services peuvent ainsi offrir aux abonnés des fonctions telles que les messages guidés parlés, la collecte de signaux multifréquence à double tonalité (DTMF), la télécopie automatique et d'autres fonctions similaires. Dans un mode de réalisation, un ISP peut être également configuré comme un périphérique intelligent (IP). L'utilisation du périphérique ISP permet de mettre en oeuvre des fonctions améliorées telle que l'acheminement évolué d'appels interurbains sur la base de l'identification automatique du numéro (ANI), les codes d'autorisation, les types d'appel, l'horloge, ainsi l'origine et la destination des appels.
PCT/US1998/013748 1997-07-03 1998-07-01 Acheminement base sur l'identification automatique du numero (ani) WO1999001992A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU82826/98A AU8282698A (en) 1997-07-03 1998-07-01 Ani based routing

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US5173197P 1997-07-03 1997-07-03
US60/051,731 1997-07-03
US5269997P 1997-07-16 1997-07-16
US60/052,699 1997-07-16

Publications (2)

Publication Number Publication Date
WO1999001992A2 true WO1999001992A2 (fr) 1999-01-14
WO1999001992A3 WO1999001992A3 (fr) 1999-03-25

Family

ID=26729773

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1998/013748 WO1999001992A2 (fr) 1997-07-03 1998-07-01 Acheminement base sur l'identification automatique du numero (ani)

Country Status (2)

Country Link
AU (1) AU8282698A (fr)
WO (1) WO1999001992A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1158814A1 (fr) * 2000-05-26 2001-11-28 Siemens Aktiengesellschaft Méthode pour le contrôle de destinations dans un réseau intelligent

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5425090A (en) * 1993-12-07 1995-06-13 Bell Communications Research, Inc. System and method for providing advanced intelligent network services
US5469500A (en) * 1993-11-12 1995-11-21 Voiceplex Corporation Method and apparatus for delivering calling services

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5469500A (en) * 1993-11-12 1995-11-21 Voiceplex Corporation Method and apparatus for delivering calling services
US5425090A (en) * 1993-12-07 1995-06-13 Bell Communications Research, Inc. System and method for providing advanced intelligent network services

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
CHOPRA M: "EXPLORING INTELLIGENT PERIPHERAL CONFIGURATIONS" INTERNATIONAL CONFERENCE ON UNIVERSAL PERSONAL COMMUNICATIONS,27 September 1994, pages 635-639, XP000600315 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1158814A1 (fr) * 2000-05-26 2001-11-28 Siemens Aktiengesellschaft Méthode pour le contrôle de destinations dans un réseau intelligent
US6804343B2 (en) 2000-05-26 2004-10-12 Siemens Aktiengesellschaft Method for destination control in an intelligent network

Also Published As

Publication number Publication date
AU8282698A (en) 1999-01-25
WO1999001992A3 (fr) 1999-03-25

Similar Documents

Publication Publication Date Title
US6226373B1 (en) Intelligent service peripheral/intelligent peripheral
US6175618B1 (en) ANI based routing
US5732130A (en) System and method of providing enhanced subscriber services in a multi-node telecommunications network
US6366658B1 (en) Telecommunications architecture for call center services using advanced interactive voice responsive service node
US6151390A (en) Protocol conversion using channel associated signaling
KR100319954B1 (ko) 통신전송방법및통신시스템
US6560327B1 (en) Method and system for providing telecommunications services using mediated service logic
US6094479A (en) Computer telephony integration gateway
US6333931B1 (en) Method and apparatus for interconnecting a circuit-switched telephony network and a packet-switched data network, and applications thereof
USH1921H (en) Generic wireless telecommunications system
US6181787B1 (en) System and method for automated provision and customer selection of temporary advanced intelligent network services
CA2338149A1 (fr) Appareil d'interface multiprotocole en un point de commande de services
EP0820681A1 (fr) Vote a distance dans un reseau intelligent
US6341162B1 (en) Telecommunications intelligent network
US6687364B1 (en) Service provision in a telecommunications network
EP0998829B1 (fr) Peripherique de service intelligent/peripherique intelligent
US6775367B1 (en) Service provision in a telecommunications network
US6535598B1 (en) Service provision in a telecommunications network
KR20000020585A (ko) 지능망 연동 시스템
Martikainen et al. Tutorial on intelligent networks
US6744870B1 (en) Service provision in a telecommunications network
WO1999001992A2 (fr) Acheminement base sur l'identification automatique du numero (ani)
US6714633B1 (en) Service provision in a telecommunications network
JP4222738B2 (ja) インテリジェント・ネットワーク・アプリケーションにアクセスするための方法およびシステム
US7010618B1 (en) Network architecture for communication networks or data networks

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE GH GM GW HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW SD SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML MR NE SN TD TG

AK Designated states

Kind code of ref document: A3

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE GH GM GW HU ID IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW SD SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: CA

Ref country code: JP

Ref document number: 1999507359

Format of ref document f/p: F