[go: up one dir, main page]

WO1998053599A1 - Traitement d'appel oriente vers l'objet et plate-forme de creation de services - Google Patents

Traitement d'appel oriente vers l'objet et plate-forme de creation de services Download PDF

Info

Publication number
WO1998053599A1
WO1998053599A1 PCT/US1998/010585 US9810585W WO9853599A1 WO 1998053599 A1 WO1998053599 A1 WO 1998053599A1 US 9810585 W US9810585 W US 9810585W WO 9853599 A1 WO9853599 A1 WO 9853599A1
Authority
WO
WIPO (PCT)
Prior art keywords
call
call processing
class
node
order entry
Prior art date
Application number
PCT/US1998/010585
Other languages
English (en)
Inventor
Steven P. Higgins
Richard D. Moore
Michael M. Myers
Alastair N. Spinks
Original Assignee
Mci Communications Corporation
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 Mci Communications Corporation filed Critical Mci Communications Corporation
Priority to AU76938/98A priority Critical patent/AU7693898A/en
Publication of WO1998053599A1 publication Critical patent/WO1998053599A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H04Q3/0054—Service creation techniques

Definitions

  • the present invention relates generally to methods and systems for processing telephone calls, and more particularly to a method of and system for creating call flows and processing telephone calls using object oriented technology.
  • Modern telecommunications networks provide a variety of services that require enhanced call processing.
  • Such services include 800, Virtual Private Networks (VPN), and credit card accounts .
  • These enhanced services may also include advanced features that require additional call processing.
  • Such advanced features generally relate to methods of performing least cost routing (LCR) , and result in more than one possible route for a single number.
  • LCR least cost routing
  • the object of LCR is to choose the network route which minimizes costs based on certain variables.
  • These variables, which define the advanced features of enhanced services include such things as time-of-day, day-of-year, day-of-week, percent allocation, point of origination, and point of termination.
  • ISR International Simple Resell
  • LTRR long-term regulatory routing
  • Call processing refers to the functionality a network employs to determine how to route each call. It may be as simple as determining a single network termination for residential number, or as complicated as processing through several dozen tiers of logical decisions to determine the optimal one of hundreds of possible network terminations for a customer service 800 number.
  • a plan for how a call will be processed by a network is referred to as a call flow.
  • SCP Service Control Point
  • NCS Network Control System
  • the current method of call processing on an NCS platform includes receiving from a switch a query message that contains originating ANI, dialed number, and possibly other data.
  • the NCS then performs an iterative series of algorithms and table lookups .
  • An initial key may be a customer identification based on either the originating ANI (i.e., for a VPN call) or on the dialed number (i.e., for an 800 call) .
  • a table lookup is then performed to determine which set of features needs to be called upon. Table lookups for each of those features needs to be performed. Additional table lookups may be required if point of call origination or point of termination is relevant.
  • An improved method for developing intelligent call processing products and for performing intelligent call processing services on a telecommunications network is provided by an advanced object-oriented platform.
  • New call processing products are developed at a workstation with a graphical user interface (GUI) by selecting and placing icons, each of which represent a product feature, to create a call flow.
  • GUI graphical user interface
  • This call flow is in the form of a node tree.
  • the nodes of the tree which represent the various features of the product, are embodied by objects in call processing. Nodes are defined by object classes. When a particular node is traversed in call processing, an object is referenced which represents the instantiation of that class (node) used by the particular call that is being processed.
  • a new product, or call flow When a new product, or call flow, is built, it is downloaded from the workstation to an object oriented database on a server. Data from this object oriented database are then uploaded to the network control platform.
  • the customer When a query for call processing is received by the network control platform from a switch, the customer is identified by performing an initial table lookup. A customer identification key that is returned serves as a pointer to the object that represents the base node of the appropriate call processing node tree. Alternatively, a specific product, revenue owner, or other parameter may be initially identified and used to point to the base node of the appropriate node tree.
  • each node of the node tree is traversed via object pointer navigation.
  • a pointer is an attribute in one object that contains an explicit reference to another object.
  • its object contains pointers to additional objects. These objects represent subsequent nodes on the node tree; one of them is chosen as the next node by the node being traversed. In such a manner, the nodes are traversed until an end node is reached.
  • An end node represents the termination of call processing.
  • the end node points to an information node that specifies how the call is to be handled. This specification will be a network address for routing, a request for default routing, or a request for call treatment (such as voice recording) to be applied at the switch.
  • an object-oriented call processing and service creation platform may be implemented as a platform for fast product development. Therefore, it is referred to as the Fast Product Development (FPD) platform.
  • the FPD platform is coupled to an existing Network Control System (NCS) platform.
  • NCS Network Control System
  • the NCS platform provides call processing functionality from the prior art.
  • Both the NCS and FPD platforms utilize transaction servers to receive switch queries, perform call processing, and respond with a network routing address.
  • Platform coupling is accomplished by linking the Fast Product Transaction Servers (FPTS) of the present invention and the NCS Transaction Servers (NCS TS) via a Fiber Distributed Data Interface (FDDI) ring, which provides a local area network (LAN) environment.
  • FPTS Fast Product Transaction Servers
  • NCS TS NCS Transaction Servers
  • FDDI Fiber Distributed Data Interface
  • call queries that qualify for FPD processing can be passed through the NCS TS and onto the FPTS.
  • Other call queries can be processed by the NCS TS .
  • call queries which qualify for FPD processing may be sent directly to the FPTS.
  • This architecture allows for a distributed call processing environment in which call processing for both FPD applications and NCS applications can be performed on a single platform. It also allows for a phased migration from a traditional NCS platform to the FPD platform.
  • a Service Creation Environment (SCE) is provided in the FPD platform by one or more Fast Order Entry (FOE) Workstations.
  • the FOE Workstation presents a GUI and may operate on any standard PC. It allows the user to create products by building call flows in a graphical manner that is analogous to the way in which a person visualizes call flows .
  • the FOE Workstations are connected to a Fast Order Entry (FOE) Server, which is in turn connected to each FPTS.
  • FOE Fast Order Entry
  • the FOE Server maintains a centralized object-oriented database of record for all FPD call processing products. It also distributes the data from this database to each of the FPTS ' s in redundant fashion.
  • the FOE Server is also connected to the order entry system of the NCS platform. This allows for network configuration updates that are entered in the NCS order entry system to be input to the FOE Server database. It also allows for network configuration updates to be entered into the FOE Workstation and fed to the NCS platform.
  • Products are created on the FOE Workstation by building call flows in a graphical manner. Call flows are built by placing icons, which represent call features, into a node tree. Each node in the tree represents a decision point in the call flow. Examples of nodes are the country a call originates in, the country a call terminates in, the time of day a call originates, the day of week of call origination, etc. Each branch of the node tree ends with a customized network routing termination, a default network routing termination, or a call treatment, which is typically a message played by a switch.
  • the nodes of the completed tree become instances of object classes embedded with pointers (object associations) , and are then loaded into an object oriented database (OODB) on the FOE Server.
  • OODB object oriented database
  • Each node, or object class, on a node tree represents a certain call feature, such as time of day of call origination. They are defined to have, as attributes, pointers to other objects based on the value of the key attribute (e.g., time-of-day) of the object.
  • Data from the OODB is distributed to each FPTS for use in call processing. There may be a different node tree for different products, customers, revenue owners, other parameters, or combinations thereof.
  • the switch When a switch receives a call that requires enhanced call processing, the switch issues a query to the NCS platform. This query contains such information as the dialed number and originating ANI .
  • the NCS TS processes the query to a certain extent, based on the type of call. Then, if the query requires additional processing, the NCS TS sends the query to the FPTS.
  • the FPTS When the FPTS receives the query, it performs an initial table lookup to determine the appropriate node tree to reference.
  • the base node of the appropriate node tree is pointed to, a method on that base node is called, and an entire branch of the node tree is traversed via object pointer navigation.
  • the last node, or object, referenced will point to an information object that provides either a network address for routing, a request for default routing, or a request for call treatment.
  • Information objects are part of a separate inheritance tree than the call processing objects, and may therefore be modified (i.e., to reflect changes in network configuration) independently, without affecting call processing objects.
  • Figure 1 is a block diagram illustrating the network architecture of the preferred embodiment, in which the FPD platform is coupled to an existing NCS platform.
  • Figure 2 is a block diagram illustrating the network architecture of a single cluster of FPD Transaction Servers and NCS Transactions Servers.
  • Figure 3 is a block diagram illustrating the internal systems architecture and data flow of the Fast Product Transaction Server (FPTS) .
  • FPTS Fast Product Transaction Server
  • Figure 4 is an example of a call processing node tree for a single customer, illustrating the representation of call product features as object classes.
  • Figure 5 is an example of a call processing node tree used for LTRR for a telecommunications carrier (Revenue Owner) .
  • Figure 6a is an OMT object modeling diagram showing inheritance and association for call processing object classes .
  • Figure 6b is an OMT object modeling diagram showing inheritance and association for information nodes object classes .
  • Figure 7 is a use case diagram illustrating the processing of a call query on the FPD platform.
  • Figure 8 is a sample screen from an FOE Workstation showing the graphical presentation of a call flow builder.
  • Figure 9 is a block diagram illustrating the internal systems architecture of the FOE Server.
  • FIG 1 illustrates the network architecture of a preferred embodiment of the invention.
  • Each switch 10 of a telecommunications switch network is connected to an NCS platform 16 including three NCS Data Access Points (DAPs)
  • DAPs NCS Data Access Points
  • NCS DAP 12 is a cluster of communication and transaction servers, and is shown in greater detail in Figure 2.
  • NCS DAP 12 is the primary NCS component for enhanced call processing.
  • the three NCS DAPs 12 are totally redundant. The purpose of connecting a switch to three redundant NCS DAPs 12 is for network survivability.
  • a Fast Product Transaction Server (FPTS) 14a ... 14c is the primary call processing component of the FPD platform 25.
  • an FPTS i.e., 14a
  • 14a is a cluster of two DEC Alpha 2100 units and one DEC Alpha 1000. This provides hardware scalability. However, more or fewer hardware units may be used. They operate with DEC'S VMS operating system.
  • Figure 2 A detailed architecture of the preferred embodiment is shown in Figure 2.
  • each NCS DAP i.e., 12a
  • a primary FPTS i.e., 14a
  • the FDDI ring 13 provides a LAN environment for the DAP 12a and
  • DECNet provides the data communications protocol over the FDDI ring 13.
  • Each NCS DAP (i.e., 12a) is also coupled to the other two FPTS's (i.e., 14b and 14c) via standard Tl communications links 15, again using DECNet protocol. This is to provide redundancy in the event of an FPTS failure.
  • the switch 10 When the switch 10 receives a call that requires enhanced call processing, the switch 10 issues a query to the NCS DAP 12.
  • This query is a message, which may be identified as an Application Data Field (ADF) message.
  • ADF Application Data Field
  • the ADF message contains information such as originating ANI and dialed number.
  • the ADF message is sent to the NCS DAP 12 over the X.25 data link 11.
  • the DAP 12 receives the ADF message and processes the query. If the query is for a qualified call (a call that requires additional processing on the FPD platform) , then a Generic Request Message (GReqM) is created by the DAP 12 and sent to a Fast Product Transaction Server (FPTS) 14 via the FDDI ring 13.
  • GeqM Generic Request Message
  • FPTS Fast Product Transaction Server
  • the FPTS 14 processes the call and returns instructions for routing to the DAP 12.
  • the DAP 12 then passes these instructions in an ADF response message to the switch 10.
  • Order entry on FPD platform 25 occurs on one or more
  • FEE Workstations 20a ... 20n These Workstations operate on standard PCS running Windows 3.11, Windows '95, or Windows NT. Each FOE Workstation 20 is connected to an FOE Server 18 via Wide Area Network (WAN) 19 in a client/server architecture.
  • WAN Wide Area Network
  • FOE Server 18 is a DEC Alpha 2100.
  • FOE Server 18 serves several functions.
  • FOE server 18 maintains the object database of record for all products created on the FPD platform. Additionally, FOE server 18 provides FOE Workstations 20 with the data needed to develop call flows.
  • FOE server 18 validates the products and call flows created on FOE Workstations 20. Finally, FOE server 18 distributes the new call flows to the FPTSs 14.
  • communications between the FOE Workstations 20 and the FOE Server 18, as well as communications between the FOE Server 18 and the FPTS 14, is via TCP/IP on links 19 and 17, respectively.
  • NCS platform 16 also includes an order entry system.
  • NCS Order Entry (NCS OE) system 22 accepts input from a user representing network configuration data. This data includes the dialed number or network address translations that are needed by NCS for call processing.
  • An NCS Service Control Manager (SCM) 24 converts the data to a format readable by the DAPs 12, and distributes it among the DAPs 12 over link 21.
  • the NCS SCM 24 is also connected to the FOE Server 18 by a link 23. This allows for updates in network configuration data to be fed to the FPD platform, if routing translations are to be performed in the FPTS.
  • the FOE Server 18 maintains the centralized object database and will update this database with data entered from the NCS OE 22 and FOE workstation 20.
  • FIG. 2 illustrates the preferred architecture of a single DAP/FPTS cluster, such as DAP 12a and FPTS 14a.
  • a single DAP 12a generally includes up to 25 Communication Servers (CS) 30a ... 30b, although only two are shown for illustrative purposes. The actual number implemented will depend on traffic volumes.
  • a DAP 12a also includes a plurality of NCS Transaction Servers (TS) 32a ... 32b.
  • TS NCS Transaction Servers
  • An FDDI ring 13 provides a LAN environment for the various servers to operate in, communicating via DECNet protocol (although other protocols may be used) .
  • the FPTS 14a preferably includes multiple units, each operating as a distinct FPTS 14a-l ... 14a-3. In the example shown in Figure 2, three FPTS's are used. However, the architecture is scaleable and additional FPTSs may be added to support increased call volumes.
  • the FPTSs 14 are linked to the NCS servers via the FDDI ring.
  • Each NCS TS 32 and FPTS 14 may embody call processing functionality for different call applications. For example, as shown in Figure 2, there is an NCS TS 32a for VPN and credit card applications, and an NCS TS 32b for 800 applications .
  • Each switch 10 in the telecommunications network is connected to each DAP 12a redundantly, via a single X.25 data link to each of two CSs 30a and 30b. This provides survivability in the event of either a link 11 failure or CS 30 failure.
  • CS 30 identifies the call type. The CS 30 then determines which NCS TS 32 to route the query to. If it is for a VPN or a credit card call, the query is routed to NCS TS 32a for processing. If it is for an 800 call, the query is routed to NCS TS 32b for processing.
  • NCS TS 32 processing of the query, it is determined whether the query requires processing by an FPTS 14. This determination is based on predefined conditions. NCS call processing is done by creating an initial database key, such as a customer identification code derived from the originating ANI, and performing a table lookup on that key. The result will be used to create another key, which will be used for another table lookup. This is an iterative process. During processing, predefined conditions may result in a request for FPTS processing. This is the trigger point. At this point, the NCS TS 32 creates a Generic Request Message (GreqM) . The GreqM, which contains data from the original ADF message along with that obtained from NCS TS processing, is sent to an FPTS 14.
  • GreqM Generic Request Message
  • the FPTS 14 processes the query and returns instructions for routing to the NCS TS 32.
  • the NCS TS 32 then includes this information in the ADF response message that it sends back to the switch 10.
  • object oriented technology is applied to call processing on FPTS 14.
  • OOT object oriented technology
  • the present invention provides both an improved platform for building enhanced call products, and an improved platform for enhanced call processing.
  • the prior art of call processing on NCS TS 32 performed a series of hashing and table lookups .
  • an initial hashing key would be created from the originating ANI or dialed number. This key would then be used to perform a table lookup to retrieve a customer identification. The customer identification would then create another hashing key, which may be used to perform a table lookup to retrieve a key indicating that a day-of-week routing algorithm is to be used.
  • This iterative process could incorporate various features of call processing (time-of-day, day-of-week, percent allocation, point of origination, etc.), but only in a specific orders pre-defined by the product type. It is also burdened by the slow execution of multiple table lookups.
  • Call processing using OOT is performed by defining each feature (i.e., day-of-week (DOW) routing) as an object class, and each instantiation of a feature (DOW) in a call flow as an object.
  • DOW day-of-week
  • These objects represent nodes on a node tree.
  • the node tree itself represents the call flow, or call processing plan, for a particular customer's product or service.
  • Each object contains pointers to other objects in the node tree.
  • a pointer is an attribute in one object that contains an explicit reference to another object.
  • Nodel may be of the class day-of-week (DOW) . It may contain an attribute that points to Node2 if the day of week of call origination is Monday through Friday, and another attribute that points to Node3 if the day of week of call origination is Saturday or Sunday. Based on the specific value (e.g., "Tuesday”) given for the day of the week, a specific pointer is chosen and processing continues with the node pointed to by that pointer. This is referred to as pointer navigation, and replaces the traditional key table lookups in call processing.
  • DOW day-of-week
  • FIG. 3 illustrates the internal logical architecture of an FPTS 14. Also indicated in Figure 3 are data flows, numbered in order, to represent a typical call processing flow among the program modules of FPTS 14.
  • a transaction server communications manager (Tscm) 40 receives messages from and sends messages to the NCS DAP 12.
  • a call processing mailbox (CpMbx) 42 is the logical repository for messages sent to Tscm 40 from the NCS DAP 12.
  • CpMbx 42 is a VMS system mailbox.
  • a call processing distributor (CpDistributor) 44 distributes work to a call processing application (Cp) 46 by putting messages into a call processing queue (CpQueue) 48.
  • CpQueue call processing queue
  • there are multiple Cps 46 there are multiple Cps 46, with each Cp application 46 having its own CpQueue 48.
  • Cp 46 applies routing rules to a request for routing information and returns routing information. There are multiple Cp instances.
  • a response mailbox (RspMbx) 50 is the logical repository for messages sent from the Cp applications 46 to CpDistributor 44.
  • CpDistributor 44 takes messages from RspMbx 50 and sends them to a transaction server communication manager mailbox (TscmMbx) 52, which is the logical repository for messages sent from Cp 46 to the NCS DAP 12.
  • TscmMbx transaction server communication manager mailbox
  • Cp application 46 creates a call record (CallRecord) 54 with information from the routing request.
  • a call processing database (CpDb) 56 which is an object-oriented database contain routing rules and information, provides the information, based on a CallRecord 54, for creating a generic response 58.
  • a statistics application (StatsApp) 60 collects call processing statistics for the FPD platform. In the preferred embodiment, StatsApp 60 resides on the FOE Server 18. The FPTS call processing flow is as follows:
  • Tscm 40 will Get a generic request message (GReqM) from the NCS DAP 12.
  • TSCM 40 will Put a Message into the CpMbx 42.
  • CpDistributor 44 will Get the Message from the CpMbx 40.
  • CpDistributor 44 will Put the Message into the CpQueue 48 for a Cp 46.
  • Cp 46 will Get the Message from the CpQueue 48.
  • Cp 46 will Create a Call Record 54 from the GReqM. 7.
  • Cp 46 will Apply Rules (call processing rules) from the CpDb 56.
  • Cp 46 will Increment Call Processing Statistics based on the call tree nodes that were traversed in the CpDb 56.
  • Cp 46 will Create a Generic Response 58 from the CallRecord 54 and the database rules.
  • Cp 46 will Put a Message (Generic Response 58) in the RspMbx 50.
  • CpDistributor 44 will Get the Message (Generic Response 58) from the RspMbx 50. 12. CpDistributor 44 will Put the Message (Generic
  • Tscm 40 will Get the Message (Generic Response 58) from the TscmMbx 52.
  • Tscm 40 will Send a Generic Response Message back to the NCS DAP 12.
  • Cp 46 will Send CallRecord 54 and Response 58 to StatsApp 60.
  • the CpDb 56 receives regular data updates from the FOE Server 18. Because call processing occurs around the clock, these updates must be made to the CpDb 56 while it is in use by a call processing application Cp 46. To ensure data integrity is maintained, a data locking mechanism must be used.
  • the object oriented database (OODB) which is maintained in the FOE Server 18 and uploaded to the CpDb 56 on the FPTS 14, is built with a commercially available product called ObjectStore, offered by Object Design Inc., of Burlington, MA. This product allows an application to persistently store and access objects as if they were stored in local virtual memory even though these objects are stored in a remote database . Another mechanism which may be used is a CpFlipper.
  • a second copy of the CpDb 56 is made and stored in the FPTS 14. At any given time, one copy is designated “read” and is used by Cp 46. The other copy is designated “write” and is updated by the upload from the FOE Server 18.
  • the CpFlipper is a process that receives a flip request from the FOE Server when an update has been performed. CpFlipper will request a flip by placing a message into the CpQueue 48. Cp 46 will then get this message from the CpQueue and will flip the "read/write” designations on the two copies of the CpDb 56. That is, Cp 46 will start reading from the other copy.
  • FIG. 4 illustrates a sample call processing node tree. This node tree is manifest as a collection of associated object classes (objects are associated via pointers) in the OODB that is stored on the FOE Server 18 and on each FPTS 14. On the FPTS 14, the OODB is stored in the CpDb 56 component, and cached into Cp 46.
  • object classes objects are associated via pointers
  • the CPMainProcess node 62 represents the processing of the Call Record 54 (created in step 6 from Figure 3) to determine which node tree to call. This can be accomplished in a number of ways, depending on how the user partitions the various call trees. Generally, an initial lookup in a customer hash table is performed on either the dialed number, originating ANI, or carrier code to identify a product type, customer, or carrier. These options will depend on the particular application of the present invention. For example, if the dialed number is an
  • the lookup will be to determine the owner of the 800 number. This will be the customer identification and will determine which call processing node tree to use. The customer identification will be the first node, or Base Node , of the tree .
  • Node trees are called with a pointer to a base node. More specifically, when Cp 46 determines the appropriate node tree from an initial hashing, it retrieves a pointer to an object in the CpDb 56 that represents the base node of that node tree. From there, various nodes are traversed in a branch that will end with an End Node. In the example shown in Figure 4, after the Base Node has been called by the CPMainProcess 62, the Base Node points to the next node, CpDOYl 64. This is defined as an object class that determines routing based on day of year of call origination. Days of year are numbered 1-366, and routing is defined as ranges of days.
  • an object is retrieved based on the value of the day-of-year (DOY) parameter that is obtained from the Call Record (created in step 6 from Figure 3) .
  • DOY day-of-year
  • the CpDOWl node 66 is pointed to and called.
  • CpDOW nodes route based on a day-of-week (DOW) parameter.
  • CpTOD nodes route based on a time-of-day (TOD) parameter.
  • CpDOWl and CpDOW2 are distinct nodes, defined differently by the range values and referenced nodes in their pointers. Such is also the case with CpTODl and CpTOD2, CpDOW2 and CpDOW3 , etc.
  • Each branch ends with an EndNode . EndNodes always point to a Cplnfo node.
  • the Cplnfo nodes contain explicit instructions for routing. These instructions will be included in a Generic Response Message that is returned to the DAP. They generally include either a network address for routing, a request for default routing (default routing is specified by the DAP), or a request for call treatment, which is, generally, a message played by the switch.
  • EndNode must point to one and only one Cplnfo node (so as to return a definite decision for call processing) , but an EndNode node may be pointed to by zero, one, or many CpFeature nodes .
  • the Cplnfo objects are separately accessible through their own hash tables. This allows the Cplnfo objects to be modified (i.e., to reflect network configuration updates) without affecting the call processing objects.
  • Figure 4 is a sample node tree.
  • the present invention allows for any order of features, or nodes, to be implemented. Thus it provides for extensive customization of call flows for various customers and products. It also allows for various types of base nodes, including product type, customer identification, and revenue owner. It is also important to note that the nodes are defined as object classes.
  • Figure 5 illustrates another example of a call processing node tree; in this case, one used for long term regulatory routing.
  • This node tree is for a particular originating country for a particular revenue owner, and is thus only part of a more extensive node tree. Included as part of this Revenue Owner's 80 node tree, but not shown in Figure 5, will be several additional branches stemming from the second node down: Originating Country 82.
  • Originating Country 82 The example shown in Figure 5 is for when the originating country is
  • the base node is the Revenue Owner 80. This is the carrier that owns the revenue for the call. For a call in which British Telecom (BT) is identified as the Revenue Owner 80, a pointer to the next node shown - Originating Country 82 - is made. When call processing traverses this node, it is determined that the originating country is Italy. This determination is made from a specific datum - the country code - that is included with the original switch query in the ADF message. It is sent to the FPTS 14 from the DAP 12 in the Generic Request Message (GReqM) , and becomes part of the Call Record 54 that is created in step 6 of Figure 3.
  • GeqM Generic Request Message
  • Egress Type 84 - is made.
  • Egress type is defined by the type of network facility to be used to terminate the call. The two egress types are switched (shared) and dedicated access line (DAL) .
  • each node is traversed based on a determination made in the previous node. These determinations are manifest when a node chooses a subsequent node to process the call.
  • Each object that is referenced has, as attributes, pointers to other objects.
  • the node tree is traversed via pointer navigation.
  • the second Terminating Country node 88 is not the same node as the first Terminating Country node 86, repeated. It is a distinct node, in which the object that it represents is defined differently (with different values) than the first Terminating Country node 86. Specifically, the attributes are going to define different pointers, as the nodes shown in the next level down are different.
  • the Country Point-of-Entry (POE) nodes 90 and 92 determine at which location the Revenue Owner received the call. This determination will result in tree traversal based on the point of entry carrier.
  • the bottom end nodes represent the end of call processing.
  • Their objects contain pointers to other objects known as information objects (included in the end nodes for illustrative purposes) .
  • An information object will contain explicit instructions for call processing. These instructions will be included in a Generic Response Message that is returned to the DAP. They generally include either a network address for routing, a request for default routing (default routing is specified by the DAP) , or a request for call treatment.
  • Information objects are not part of the same inheritance tree as the other call processing objects. They are independently accessible from separate lookup tables in the OODB. This allows for information objects, which represent the results of call processing, to be quickly modified by network configuration data input from the FOE
  • OOT provides other desirable features for call processing.
  • Data encapsulation insulates the internal structures and algorithms of a call processing node. This allows for a feature to change its internal algorithms for processing information without affecting other nodes that call it or the nodes that it in turn calls. Thus, each and any node may be modified without affecting the rest of call processing. This is not possible in the prior art, which utilizes iterative hashing and table lookups.
  • the call processing nodes exhibit independent behavior. This means the nodes are autonomous, not needing information from other features to do their work. In this manner, a call processing node does not care how it was called, nor does it care about which node it is calling. It only needs to know how to do its processing, which is embedded in the object class definition.
  • Call data such as origination date/time, is obtained from a central data store, namely, a call record created internally in the FPTS memory from the GReq .
  • Figure 6a is an OMT diagram of an inheritance tree, showing the associations among the various call processing object classes.
  • the representation of Figure 6a is not equivalent to the call processing node tree shown in Figure 4.
  • the inheritance tree of Figure 6a shows how the object classes that form the call processing nodes are defined.
  • each box is a defined object class.
  • Triangles represent inheritance from a single base class to one or more derived classes.
  • Solid balls represent multiplicity, with the ball being on the multiple class end.
  • Diamonds represent aggregation (components to an assembly) and are on the assembly end.
  • each class inherits attributes from the base class CpNode 94. From the CpNode class 94, two sub-classes, CpFeature 96 and CpEndNode 98 inherit.
  • CpEndNode class 98 is for end nodes in the call processing node tree. End nodes indicate that call processing has reached a termination point.
  • a CpEndNode object will contain a pointer to a Cplnfo object.
  • the Cplnfo object contains the information needed to determine the termination type for a call.
  • Cplnfo classes are part of a different inheritance tree. This tree and the association between CpEndNode and Cplnfo classes are shown in Figure 6b.
  • the CpFeature class 98 is the base class for the features that determine routing in a call flow, such as DOW, DOY, TOD, Egress, Access, etc. If additional features are to be defined, they will inherit from the CpFeature base class. From the
  • CpFeature class 98 three subclasses - CpRangeFeature 100, CpIndexFeature 102, and CpBinSortFeature 104 - inherit.
  • CpRangeFeature 100 is the base class for features that may be specified by ranges. These include day-of-year (DOY) , time-of-day (TOD) , and random percent allocation
  • CpRangeFeatures 100 are CpDOY 106, CpTOD 108, and CpRPA 110. Of course, additional subclasses may be added.
  • the pointers for these subclasses are kept in arrays, in which a pointer to a specific object is specified for a value range in the array.
  • CpIndexFeature 102 is the base class for features that may be specified by an index value. While DOY, TOD, and RPA may fit this category, it is more appropriate for features like day-of-week (CpDOW) 112, which only has seven values.
  • CpEgress 114 which determines type of network facilities (dedicated vs. shared) used to terminate a call
  • CpAccess 116 which determines type of network facilities used to originate a call.
  • CpBinSortFeature 104 is the base class for features that map a Binary Coded Decimal (BCD) to a value.
  • BCD Binary Coded Decimal
  • a BCD is a binary notation for a decimal number in which each digit is represented by a 4-bit sequence, or nibble.
  • the number 7135551212 is represented in BCD by 10 nibbles, or 40 bits.
  • Features that may utilize this include country of origination or termination, and carrier. This is because country codes that identify countries and carrier codes that identify carriers are included in the Call Record. These codes are in BCD format and may be mapped to a value in an array that identifies a pointer, based on the country or carrier represented. Therefore, the subclasses CpCountry 118 and CpCarrier 120 inherit from CpBinSortFeature 104.
  • CpWZlSub 122 Another subclass that inherits from CpBinSortFeature 104 is CpWZlSub 122, which represents a value for countries in what is defined as World Zone 1 (WZ 1) .
  • WZ 1 World Zone 1
  • WZ 1 World Zone 1
  • countries in WZ 1 include the United States, Canada, and various Caribbean islands.
  • countries in WZ1 all use the same country code (1) . It may be desirable to distinguish routing based on the origination or termination within different WZ1 countries and Caribbean islands. Therefore, pseudo-country codes (PCCs) are assigned. In this manner, the CpWZl subclass serves many of the same features as the CpCountry class 118.
  • PCCs pseudo-country codes
  • Some boxes in Figure 6a are identified as arrays with predetermined sizes and have the format ***_tp ⁇ ***>. These represent values of array sizes that are determined when the classes are defined.
  • the arrays are used as attributes in feature classes. They embody the various object pointers as array values. The actual sizes of these arrays are determined at compile time; a specific value is given during the declaration of the class. Therefore, in Figure 6a, these boxes represent these values which must be passed on to the subclasses during compile time.
  • the box identified as CpIndexFeature_tp ⁇ egressLngth> 124 represents a value for the array size of the array that will be used as a pointer in the subclass CpEgress 114; egressLngth is the constant that actually defines the array size.
  • Figure 6b is an OMT diagram of another inheritance tree, showing the associations among classes that inherit from information objects.
  • the information object class is named Cplnfo 126.
  • Cplnfo 126 is associated with the CpEndNode class 96, but is from a different inheritance tree. In this way, Cplnfo 126 and its subclasses may be modified without affecting the CpNode class 94 and its subclasses from the call processing inheritance tree of Figure 6a.
  • Cplnfo class 126 is in the form of a pointer within the CpEndNode class 96. Each CpEndNode may be pointed to by zero, one, or multiple CpFeature nodes. However, a Cplnfo node must be pointed to by exactly one CpEndNode.
  • the Cplnfo 126 classes specify how a call is to be treated or routed on the switch network 10. Three subclasses inherit from the Cplnfo 126 base class: CpRteDefault 128, CpRteTreatment 130, and CpRteSCP 132.
  • the CpRteDefault 128 class specifies that default routing is to be used on the call. Default routing is as specified in the NCS DAP 12.
  • CpRteTreatment 130 class specifies that a treatment is to be applied to the call at the Switch 10.
  • a treatment may be a voice recording that informs the caller the call cannot be completed.
  • CpRteSCP 132 class specifies a particular network address to route the call to.
  • the CpRtelnfoTbl 134 is a hash table that contains pointers to all Cplnfo nodes, which contain all default routing instructions, call treatment instructions, and network addresses for FPD-specified routing.
  • Figure 7 is a use case showing call processing on the FPD platform.
  • the entities represented include 800 Gateway, which is equivalent to the NCS DAP 12.
  • the NCS TS for 800 (32c from Figure 2) has received the initial switch query, and a gateway to this component is used to pass the query on to the FPTS 14.
  • CP Application is the Cp 46 component of the FPTS 14, shown in Figure 3.
  • CpCallResp is the call processing object class for the Generic Response message 58 generated by Cp 46 of the FPTS 14.
  • CpDOY is the call processing object class for the day-of-year features (CpDOY 106 of Figure 6a) .
  • CpDOW is the call processing object class for the day-of- week features (CpDOW 112 of Figure 6a) .
  • CpTOD is the call processing object class for the time-of-day features (CpTOD 108 of Figure 6a) .
  • CpCallRec is the call processing object class for the Call Record 54 created by Cp 46 from the GReqM, as shown in Figure 3.
  • Call Record 54 is used by the call processing features to obtain call data.
  • CpTermNode is equivalent to CpEndNode 96 of Figure 6a, the final node of call processing that contains a pointer to a CpInfoNode 126, as shown in Figure 6b.
  • GReqM is sent from 800 Gateway (DAP) to CpApplication.
  • Cp Application builds a Call Record (CpCallRec) and performs call processing by making a routing decision based on the day of year of call origination.
  • CpDOY queries the CpCallRec for the day of year of call origination and
  • CpCallRec responds with an answer "36.”
  • CpCallRec responds with an answer, "Wednesday.”
  • CpCallRec responds with an answer, "0347.
  • CpTermNode returns with specific instructions for call routing, based on information received from the Info node it pointed to. Control is returned to Cp Application and Cp Application builds a GResM (CpCallResp) . Cp Application sends the GResM (CpCallResp) to the 800 Gateway (DAP) .
  • SCE Service Creation Environment
  • FOE Workstation 20 operates on standard PCs running conventional operating systems such as Windows 3.11, Windows 95, or Windows NT.
  • the FOE Workstation 20 provides a graphical presentation that is used to create call flows. This may be built, as in the preferred embodiment, with VisualAge (TM) .
  • VisualAge is an IBM product that provides an 00 visual application development environment .
  • IBM VisualAge allows the user to develop applications by visually arranging and connecting both prefabricated and customized parts. It uses and includes Smalltalk, an 00 programming language.
  • the FPD application that operates on the FOE Workstations 20 does so in a Smalltalk environment.
  • FIG 8 is an illustration of a sample screen from a FOE Workstation 20.
  • Figure 8 shows a call flow builder that is used for building customer call flows.
  • a call flow for an LTRR application is being built.
  • An LTRR call flow is built for a Revenue Owner, which is the carrier that originates the call . Revenue Owners are indicated with a "$" icon 140.
  • MCI is the Revenue Owner.
  • the left column 142 contains icons that represent the various features of a call flow. By clicking and dragging an icon over to the call flow node tree 144, the icon is put in place in the call flow. By selecting the icon, specific values for that feature may be designated.
  • a globe represents a country or call origination/termination.
  • the user may select whether it indicates a country of origination (a globe with an "0" in it) , a country of termination (a globe with an "T” in it) , or a point of entry country, which is the country where the call enters the network (a globe with a "P" in it) .
  • the icon Once the icon has been dragged onto the node tree, the user may also select which country is represented by double-clicking on the icon.
  • the first node in the second level of the tree shown is for calls that originate in the United Kingdom 146.
  • the first node in the third level is for calls that terminate in the United Kingdom or the United States 148.
  • a triangle with an incoming arrow represents access type, and may be specified as shared or dedicated.
  • one access type is shared 150.
  • a triangle with outgoing arrow represents egress type, and may be specified as shared with a dialing plan (DP) , shared without a DP, dedicated, or VNC.
  • DP dialing plan
  • one egress type is dedicated or VNC 152.
  • Clock icons represent time- of-day features, calendars represent day-of-week features, and telephones represent the end nodes of the tree, in which explicit instructions for call routing are given. Other icons for other features not shown, such as call percent allocation, may be included.
  • End nodes may include a default routing request, as indicated by a telephone with a "D" 154 in it, or a specific termination, as indicated by the "Londonl” 156 specification in Figure 12. Other values may be specified in accordance with the application.
  • All the data that is needed to create any call flow is stored on the FOE Server 18.
  • FOE Workstation 20 When a user logs onto an FOE Workstation 20, their access is validated by the FOE Workstation 20. The user then selects which application they wish to build a call flow for. Based on this selection, the FOE Server 18 will upload all data needed for such an application. This includes values for each icon/feature selected.
  • the FOE Server 18 validates it to ensure all default options are specified, all parameters are specified for range features (for example, it validates that if DOW feature is used, all seven days of the week are accounted for in the call flow), and each type of feature (DOW, TOD, etc.) is traversed only once on any single branch of a tree (for example, to prevent a DOW decision from being made twice in the same branch) .
  • the call flow is downloaded to the FOE
  • the Call flow is stored as a collection of associated objects .
  • FIG 9 illustrates the internal architecture of the FOE Server 18, and its interfaces with the FOE Workstations 20 and the FPTS 14.
  • the FOE Server 18 and Workstations 20 interact in a client/server model using DEC'S ObjectBroker (OBB) .
  • OBB is an interprocess communications product that allows data to be passed between different operating environments .
  • OODB 162 is a memory-cached disk-resident database on the FOE Server 18.
  • OODB 162 is the database of record for the entire FPD platform.
  • OODB 162 is implemented with ObjectStore, an object oriented database product commercially available through Object Design Inc., of Burlington, MA.
  • FPTS Data Distributors 164 are used to distribute data from OODB 162 to multiple FPTSs 14. Data distribution is performed by copying records from the local OODB 162 (on the FOE server 18) to the remote database on the FPTS 14. This copy utilizes ObjectStore mechanisms which make the remote database appear no different to the data distributor than the local database; that is, the data distributor simply manipulates objects in the databases (in this case, calling a method on the object in the FOE server database to create a copy of itself in the FPTS database) .
  • a safe-stored queue 166 on the FOE server 18, which is managed by a queue manager 168, is used to indicate to the data distributors that updates need to be distributed; the records in this queue contain references to the trees that have changed, along with a mask.
  • a mask is a series of bits, with each bit having one-to-one correspondence with an FPTS. Prior to data distribution, each bit is set to "1". When an FPTS successfully receives the record, the bit is flipped to "0" On the FPTS 14, these trees are placed in CpDb 56, shown in Figure 3. The trees are then available for call processing.
  • the present invention provides object oriented call processing.
  • the FPD platform allows fast product development by reducing the time to market for new products from about 54 weeks to 3-4 months. It provides a platform for meeting regulatory routing requirements while taking advantage of least cost routing features.
  • the present invention simplifies product development, and allows products to be created and modified easily by non-programmers. It can process equal or greater transactions per second (TPS) , on the same type of processor, as the existing NCS platform. It can be built with commercially available, off-the-shelf products, which minimizes vendor costs.
  • TPS transactions per second

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Exchange Systems With Centralized Control (AREA)

Abstract

Un système de traitement d'appel orienté vers l'objet comprend une base de données orientée vers l'objet et une application de traitement des appels. Une plate-forme (25) de création de services d'un service de télécommunications comprend un serveur (18) d'entrée des commandes qui comprend une base de données centrale orientée vers l'objet servant à conserver en mémoire des flux d'appels. Plusieurs postes de travail (20, 20n) d'entrée des commandes sont en communication avec le serveur (18) d'entrée des commandes. Plusieurs serveurs (14a, 14b, 14c) de transaction de produits sont en communication avec le serveur (18) d'entrée des commandes. Chaque commutateur (10) d'un réseau de commutation de télécommunications est relié à une plate-forme (16) SCR comprenant trois points d'accès de données SCR (12a, 12b, 12c) comprenant des liaisons (11) de communication de données classiques. Une entrée (22) de commandes SCR accepte des entrées provenant d'un utilisateur représentant des données de configuration du réseau. Un gestionnaire (24) des commandes de services SCR convertit les données dans un format lisible par les PAD (12) et les distribue entre les PAD (12) sur la liaison (21).
PCT/US1998/010585 1997-05-23 1998-05-21 Traitement d'appel oriente vers l'objet et plate-forme de creation de services WO1998053599A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU76938/98A AU7693898A (en) 1997-05-23 1998-05-21 Object oriented call processing and service creation platform

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US86228097A 1997-05-23 1997-05-23
US86228997A 1997-05-23 1997-05-23
US08/862,289 1997-05-23
US08/862,280 1997-05-23

Publications (1)

Publication Number Publication Date
WO1998053599A1 true WO1998053599A1 (fr) 1998-11-26

Family

ID=27127683

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1998/010585 WO1998053599A1 (fr) 1997-05-23 1998-05-21 Traitement d'appel oriente vers l'objet et plate-forme de creation de services

Country Status (2)

Country Link
AU (1) AU7693898A (fr)
WO (1) WO1998053599A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1014316A1 (fr) * 1998-12-24 2000-06-28 Koninklijke KPN N.V. Structure de serveur de transaction
US6724875B1 (en) * 1994-12-23 2004-04-20 Sbc Technology Resources, Inc. Flexible network platform and call processing system
EP2383968A1 (fr) * 2010-04-27 2011-11-02 Research In Motion Limited Identification des appels entrants vers un PBX comme provenant de PBX-associés téléphones mobiles par l'utilisation d'une table de hachage

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5511116A (en) * 1992-08-25 1996-04-23 Bell Communications Research Inc. Method of creating and accessing value tables in a telecommunication service creation and execution environment

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5511116A (en) * 1992-08-25 1996-04-23 Bell Communications Research Inc. Method of creating and accessing value tables in a telecommunication service creation and execution environment

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6724875B1 (en) * 1994-12-23 2004-04-20 Sbc Technology Resources, Inc. Flexible network platform and call processing system
US7461381B2 (en) 1994-12-23 2008-12-02 At&T Labs, Inc. Flexible network platform and call processing system
EP1014316A1 (fr) * 1998-12-24 2000-06-28 Koninklijke KPN N.V. Structure de serveur de transaction
WO2000039757A1 (fr) * 1998-12-24 2000-07-06 Koninklijke Kpn N.V. Structure de serveur de transaction
EP2383968A1 (fr) * 2010-04-27 2011-11-02 Research In Motion Limited Identification des appels entrants vers un PBX comme provenant de PBX-associés téléphones mobiles par l'utilisation d'une table de hachage
US8370484B2 (en) 2010-04-27 2013-02-05 Research In Motion Limited Provisioning for enterprise service
US8533325B2 (en) 2010-04-27 2013-09-10 Blackberry Limited Provisioning for enterprise service

Also Published As

Publication number Publication date
AU7693898A (en) 1998-12-11

Similar Documents

Publication Publication Date Title
US5579384A (en) Telecommunications network service central management system interfacing with protocol specific regional stations providing services to subscribers
US5907607A (en) Service creation apparatus for a communications network
EP0858710B1 (fr) Dispositif de creation de services pour un reseau de telecommunications et methode correspondante
US6724875B1 (en) Flexible network platform and call processing system
US4698752A (en) Data base locking
US6445786B2 (en) Telemanagement system with single point of entry
US5974409A (en) System and method for locating information in an on-line network
US5241588A (en) Systems and processes providing programmable or customized customer telephone information services
US5345380A (en) System and processes specifying customized customer telecommunication services using a graphical interface
US5933828A (en) Method of structuring a database of a control system for access by third party software
US6556996B1 (en) Service package application and a service activation manager for use with a service control point in an advanced intelligent network
US5315646A (en) Systems and processes for providing multiple interfaces for telephone services
WO1998053599A1 (fr) Traitement d'appel oriente vers l'objet et plate-forme de creation de services
WO2001086495A1 (fr) Gestion centralisee d'un systeme de bases de donnees reparties
JPH09160847A (ja) クライアント・サーバ型分散処理システム
EP0126122B1 (fr) Verrouillage de base de donnees
US20090228900A1 (en) Systems and methods for application programming using persistent objects
US7031976B1 (en) Computer framework and method for isolating a business component from specific implementations of a datastore
JP3731860B2 (ja) 顧客サービス処理システム内のタスクの順序付け
Kraemer Open distributed management of telecom systems: the missing link
Gallersdörfer¹ et al. Application (INDIA)
JP2001243340A (ja) 顧客サービス処理システム内のプロダクト定義
JPH04175852A (ja) 通信パラメータ管理方式

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU CA JP MX

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: CA

NENP Non-entry into the national phase

Ref country code: JP

Ref document number: 1998550722

Format of ref document f/p: F

122 Ep: pct application non-entry in european phase