WO1995034175A1

WO1995034175A1 - Network service provisioning

Info

Publication number: WO1995034175A1
Application number: PCT/CA1995/000297
Authority: WO
Inventors: Kenneth Allan Borg; Lidia Dora Cormier; Christian Cornelius Ellens
Original assignee: Northern Telecom Limited
Priority date: 1994-06-06
Filing date: 1995-05-23
Publication date: 1995-12-14
Also published as: CA2125239A1

Abstract

A network service provision system and method for advanced intelligent networks uses a hierarchy of three structures: service building blocks (60), features (62), and services (64). Services (64) are defined in terms of features. Features (62) are defined in terms of building blocks (60). The building blocks (60) are simple software defined procedures requiring a set of parameters. The features (62) are decision graphs built from building blocks (60) using data. Services (64) are then built using a subscriber profile (86) from combinations of service building blocks (60) and feature decision graphs (74) together with the subscriber profile (86) and support data (90). As new services can be defined using data, loading new services can be accomplished in service control points without interrupting services already active.

Description

NETWORK SERVICE PROVISIONING

This invention relates to network service provisioning and is particularly concerned with advanced intelligent network (AIN) services. Background to the Invention

The Advanced Intelligent Network (AIN) architecture has been evolved through the efforts of standards groups, in particular Bellcore and CCITT. These two groups have issued respective documentation defining general architecture for AIN. This evolution is being driven by the increasing demand for rapid and responsive deployment of services on the telecommunications network. In order to provide optimized service deployment, specifications for service provisioning have been developed. For example the Bellcore document "AIN SCP Generic Requirements Application Support Processing" GR-1280-CORE, Issue 1, August 1993 defines a service provisioning architecture for the AIN SCP.

While this basis for service provisioning ensures compatibility in a multi-vendor network, there is a need for service provisioning schemes that comply with the requirement while ensuring flexible and cost effect service deployment.

One of the problems in developing software for a telecommunications product, such as a service switching point (SSP) or a service control point (SCP) , is deploying new software into products that are handling calls and therefore cannot go out of service while loading or transitioning to new software programs. Known systems suffer from the problem of requiring new software in order to evolve or modify the SCP application. Summary of the Invention

An object of the present invention is to provide improved network service provisioning.

In accordance with another aspect of the present invention there is provided a network service provisioning method comprising the steps of: providing a set of building blocks, each defining a procedure that requires a set of parameters; defining a set of features as decision graphs whose nodes are building blocks; and defining a service profile as a set of features; the building block parameters and features and hence the service all being specified by data.

In accordance with an aspect of the present invention there is provided a network service provisioning system comprising: a set of building blocks, each defining a procedure that requires a set of parameters; a set of feature decision graphs whose nodes are building blocks; a service profile including a directed set of feature decision graphs and building blocks; and an interpreter for navigating the service profile and feature decision graphs. An advantage of the present invention is meeting the challenge of deploying new services or applications by defining these services through data, not software. All service logic is represented by data, with general service- independent functions implemented in software. Deploying new or changed data into an SCP is a much simpler and more predictable process than deploying software. Brief Description of the Drawings

The present invention will be further understood from the following description with reference to the drawings in which: Fig. 1 illustrates a known service control point (SCP) for an advanced intelligent network (AIN) ;

Fig. 2 illustrates in a block diagram a known service provisioning system;

Fig. 3 illustrates in a block diagram a service provisioning system in accordance with an embodiment of the present invention;

Fig. 4 illustrates a hierarchy of components used in the service provisioning system of Fig. 3;

Figs. 5 illustrates in a block diagram the relationship between service provisioning parameters and the components of Fig. 3 and provisioning data; and Fig. 6 illustrates a parameter block in accordance with an embodiment of the present invention.

Similar references are used in different figures to denote similar components. Detailed Description

Referring to Fig. 1, there is illustrated a known service control point (SCP) for an advanced intelligent network (AIN) . The general purpose service control point (SCP) includes a network interface peripheral 10, a high- speed bus or local area network (LAN) 12 and multiple query processors 14. Each query processor 14 includes storage media 16 and 18 for retaining data related to service provisioning. The network interface peripheral 10 and the query processors 14 and interconnected via the high-speed bus or LAN 12. The network interface peripheral 10 is connected to service switching points (SSP) in the network via CCS7 network links 20.

The SCP is an example of a loosely-coupled architecture in which each processor is a self-contained computer system having local memory, disk drives and other I/O devices. The query processors 14 communicate with one another by sending messages across the high-speed bus or LAN 12.

In operation, messages arrive from SSP via the CCS7 network links 20. The messages are first processed by the network interface peripheral 10, then distributed to the query processors via the high-speed bus or LAN 12. A message arriving from the CCS7 network may be part of an ongoing transaction with control processing occurring within a single query processor 14. In known service provisioning systems, telecommunication services that execute within an SCP have been developed as software programs.

Referring to Fig. 2, there is illustrated in a block diagram a known service provisioning system. Fig. 2 shows a representation of the major components that are related to service software within an SCP based on GR-1280-CORE using flexible service logic (FSL) concepts. The known service provisioning system includes application specific software, as represented by a block 22, a subscriber profile database, as represented by a block 24, a decision graph, as represented by a block 26, a call variables stack, as represented by a block 28 and TCAP query and response as represented by blocks 30 and 32, respectively.

In operation, the software, labeled as the Application Specific Software 22 in Fig. 2, is designed to receive a TCAP query message 30, retrieve a subscriber profile from the customer profile database 24 database, perform some application specific work, and finally send a TCAP response 32 message back to the originating SSP. During the processing of a specific message 30, call variables 28 are used to store temporary information related to the message being acted upon.

In the document GR-1280-CORE, issued August 1993, Bellcore published AIN SCP Generic Requirements. In this document Bellcore proposed the idea of supplementing application program logic of the application software 22 through the use of decision graphs 26. A phrase, Flexible Service Logic (FSL) , refers to this usage of decision graphs 26 to define functions or algorithms instead of developing software to perform the work. The role of the decision graphs 26 is to assist the application software 22 in the processing of a message.

Referring to Fig. 3, there is illustrated in a block diagram a service provisioning system in accordance with an embodiment of the present invention. Fig. 3 presents the major software and data components of the service provisioning system. The service provisioning system includes a transaction control block 40, a TCAP decode block 42, a retrieve subscriber profile block 44, a FSL interpreter block 46, and a TCAP encode block 48, a subscriber profile database 50 and feature decision graphs 52. Both subscriber profile and feature decision graphs are represented by data. In operation, the transaction control block allocator 40 retrieves or allocates a block of memory, a transaction control block (TCB) , that is used to store all call variables for a specific SSP transaction. The software in this function first examines the Transaction ID field in the received message to determine if the message belongs to an existing transaction or represents the initiation of a new transaction. If there is an existing transaction, the appropriate TCB is retrieved from a pool of current transaction TCBs. If the message represents a new transaction, a TCB is retrieved from a pool of unused TCBs. The TCAP decode block 42 takes, as input, the received TCAP message, and places the decoded information into the transaction control block 40. This function decodes the message type, and places the value into the Message_Type call variable within the TCB. Each parameter found in the TCAP message is decoded and placed in a predefined call variable using a data dictionary. The dictionary function takes as input the TCAP parameter tag, and returns an address of the call variable that should be used to store the information.

The retrieve subscriber profile block 44 uses one or more call variables to build a key that is then used to retrieve a record from a subscriber profile database 50. Some AIN services use a particular TCAP parameter, whereas other services require the building of a key using two or more TCAP parameters. Specifically, AIN 0.1 services require the use of the UserlD parameter found in all messages that arrive from an SSP. The SCP system can determine which key-building function to use by referring to the Sub-System Number parameter which is also included in the received message. The Sub-System Number parameter, which is stored as a call variable, is also used to determine the database file name that should be used when performing the database retrieve function.

Upon a successful exit from the retrieve subscriber profile block 44, the FSL interpreter is then invoked by the system. The FSL interpreter block 46 navigates through subscriber profile and feature decision graphs used by the particular service being provided. The major responsibilities of the interpreter are: • to determine which feature or building block to invoke next,

• pass execution control to building blocks,

• check for and handle error conditions,

• retrieve parameters values from various locations within the system and pass these values to building blocks. The TCAP encode block 48 performs a generic TCAP encode function that takes as input call variables and produces an encoded TCAP message. This function is invoked after the completion of the FSL interpreter. The TCAP encode block first examines a specific call variable which indicates what Message type the TCAP response message should have. If this call variable has not been set properly by the features and building blocks that were executed, then a default error message is sent back to the SSP. If the message type call variable has been set properly, then other call variables are checked for validity before the message is encoded and sent out. The validity checks mentioned are based on the Sub-system number, and have been documented by standards groups such as ANSI, CCITT, and Bellcore. In this system, SCP services can be created or extended simply by changing the set of feature decision graphs and subscriber profiles. This design solves the problem of requiring software deployment in order to extend or create new SCP services. The service provisioning system of Fig. 3 differs from the known system of Fig. 2, inter alia, in the representation of the subscriber profile. In known service designs, the subscriber profile consists of a set of data values that are used to customize a service for an individual user of that service. In the system of the present invention as represented by Fig. 3, the subscriber profile is defined as a directed graph of service features. The term feature is used to specify an optional component of a service.

For example, an SCP service that screens incoming calls may consist of 3 features: one feature that allows certain callers to get through, one feature to perform tighter screening during specific hours of the day, and another feature to display the name of the caller on the subscriber's telephone. Referring to Fig. 3, the implementation of this call screening service would require: a) the design of three separate feature decision graphs 52 using a library of predefined building blocks; and b) provisioning of subscriber records that consist of a key, which is the subscriber identification, and a linked set of feature invocations including parameter values. Both of these steps are achieved by sending data only to the SCP. Individual customers not only provide data values for the various feature parameters, but can also specify the sequence and selection of features. The benefit of this approach is the degree of flexibility offered to the users of a service.

As discussed hereinabove, one of the problems in developing services for a service control point (SCP) , is deploying new software into products that are handling calls and therefore cannot go out of service while loading or transitioning to new software programs. Known systems suffer from the problem of requiring new software in order to evolve or modify the SCP application. It is an advantage of the present invention that services based upon data and hence new services are deployed by providing a data download for the service. Such a data download does not interrupt existing services being provided.

The present invention meets the challenge of deploying new services or applications by defining these services through data, not software. All service logic is represented by data, with general service-independent functions implemented in software. Deploying new or changed data into an SCP is a much simpler and more predictable process than deploying software.

One of the problems encountered when designing decision graphs to perform certain functions is to decide upon the scope or complexity of particular building blocks (nodes) within the graph. If the individual building blocks are very simple in nature, then it may require a large number of nodes to perform a function required by a service. If the individual building blocks are very complicated, then there will not be much reuse of the building blocks between decision graphs. The description in GR-1280 takes the approach of defining a few very simple building blocks.

The approach used in the present invention is to define building blocks at both extremes using the following principles: a) Simple, service-independent building blocks are written in software. These building blocks are expected to be reused in many services without modification. b) Service-specific building blocks are developed by creating a decision graph of the simpler building blocks, without writing any new software.

Referring to Fig. 4, there is illustrated a hierarchy of components used in the service provisioning system of Fig. 3. These components include building blocks 60, feature graphs 62 and services 64. Fig. 4 shows the relationship between services 64, features 62, and building blocks 60. Services 64 are defined in terms of features 62, and features 62 are defined in terms of building blocks 60. in accordance with an embodiment of the present invention the feature decision graph 62 is a data structure which includes information on:

• the length of the data structure,

• the number of building blocks in the graph,

• for each building block: the building block identification, the number of parameters in the building block, and the actual parameters. The advantage of this three level hierarchy is that complex services can be broken down into a number of features which can then be defined by a decision graph 62 of simple building blocks 60. Without the concept of a feature, complex services become unmanageable when defined only in terms of simple building blocks. It has also been found that certain features can be designed to be reusable across many services, thereby reducing the cost involved in developing and deploying new AIN services. Referring to Fig. 5, there is illustrated in a block diagram the relationship between service provisioning parameters and the components of Fig. 3 and provisioning data. In accordance with an embodiment of the present invention, each building block 60 is represented as a procedure 70 that requires a set of parameters. A feature decision graph 62 can also be realized as a procedure that requires a set of parameters. In each case, parameter values may be provided directly or indirectly. It is the building block designer's role to define the number and type of parameters required by the building block software. By examining the usage of a building block 60, it is evident that parameter values must originate from multiple, different locations within the SCP software architecture. The actual location and value and a building block parameter is defined when a service designer uses the building block to develop a feature. Fig. 5 presents an example case in which Building_Block_a 70 has been developed and requires 5 parameters. Fig. 5 illustrates one usage instance in which the first parameter value 72 is provided within a feature decision graph 74, the second parameter value 76 refers to a call variable value 78, the third parameter value 80 refers to a call variable 82 that will be updated by the building block, the fourth parameter value 84 is provided from a subscriber profile 86, and the fifth parameter value is provided from other service supporting information 90. In accordance with an embodiment of the present invention, specialized software is provided to resolve and retrieve the required parameter values whenever building blocks are executed. This software is hereinafter referred to as parameter resolution software. Without this software provided in the FSL interpreter, each building block would have the responsibility of determining the exact location of parameter values each time the building block was invoked.- The parameter resolution software was developed to reduce this duplication of software, and to simplify the design of building blocks. The parameter resolution software uses of a building block template table. This building block template specifies for each parameter: the parameter data type (for example, integer), and whether or not the parameter is repeating (an array) . Every building block introduced to the SCP system requires a new entry into this table. When a building block is invoked, its first responsibility is to call the parameter resolution software and in so doing, must indicate the building block ID and a ' pointer to the feature decision graph data structure. The parameter resolution software then retrieves the building block template and then uses the pointer into the feature decision graph data structure to sequentially retrieve all parameters to the building block.

Each parameter within the feature decision graph data structure defines where the present value of parameter can be found, for example, a specific call variable. The parameters found in the feature decision graph data structure may directly or indirectly refer to the true parameter value to be used, it is the responsibility of the parameter resolution software to locate and return a direct pointer to each parameter that the building block requires.

The parameter resolution software returns an integer code which indicates to the building block whether or not it was successful in resolving all parameters. If successful, the parameter resolution software also returns a set of pointers that the building block can use to access all required parameters. The parameter resolution software described is service, feature and building block independent.

The present invention simplifies the design of each building block and enables SCP software to evolve more efficiently by not duplicating the parameter resolution function throughout the system and service software.

Referring to Fig. 6, there is illustrated a parameter block in accordance with an embodiment of the present invention. The format of building block parameters within the present invention includes a tag 100 and a value 102. The tag 100, a 4-bit portion of the parameter, identifies the data structure from which the value should be retrieved. The value 102, a 16-bit portion of the parameter, represents either the actual value, in the case of an immediate tag, or an address (or offset) into the data structure indicated by the tag. An embodiment of the present invention uses only 5 tags. The five tags used are:

1) Nil

2) Immediate 3) Transaction Control Block (where all call variables are stored)

4) Subscriber Record

5) Support Table.

An important use of building block parameters is to indicate the next building block to execute after the current block terminates. In this case the parameter tag is set to Immediate, and the parameter value is set to the offset in the feature decision graph data structure where the next building block information can be found. Numerous modifications, variations and adaptations may be made to the particular embodiments of the invention described above without departing from the scope of the invention, which is defined in the claims.

Claims

WHAT IS CLAIMED IS:

1. A network service provisioning method comprising the steps of: providing a set of building blocks (60) , each defining a procedure (70) that requires a set of parameters (72, 76, 80, 84, 88) defining a set of features (62) as decision graphs whose nodes are building blocks (60) ; and defining a service profile (64) as a set of features (62); the building block parameters and features and hence the service all being specified by data.

2. A method as claimed in claim 1 further comprising the step of retrieving a service profile (64) for the service to be provided.

3. A method as claimed in claim 2 wherein the step of retrieving a service profile (64) includes the steps of receiving a message, decoding the message and building a key based upon the message and predetermined procedures to retrieve a subscriber service profile (86) .

4. A method as claimed in claim 3 wherein the message is a TCAP message.

5. A method as claimed in claim 2 further comprising the step of interpreting the service profile (86) .

6. A method as claimed in claim 5 wherein the step of interpreting includes the step of determining which feature (62) or building block (60) to invoke, passing execution control to the feature (62) or building block (60) , and retrieving parameter values from various locations and passing these values to the building blocks (60) .

7. A method as claimed in claim 6 wherein the step of retrieving parameter values comprises the steps of providing a building block template table having an entry for every one of the set building blocks, identifying the building block (60) , retrieving the building block template and using a pointer into the feature decision graph data structure, sequentially retrieving all parameters to the building block (60) .

8. A network service provisioning system comprising: a set of building blocks (60) , each defining a procedure (70) that requires a set of- parameters (72, 76, 80, 84, 88); a set of feature decision graphs (62) whose nodes are building blocks (60) ; a service profile (64) including a directed set of feature decision graphs (62) and building blocks (60) ; and an interpreter (46) for navigating the service profile (64) and feature decision graphs (62) .

9. A network service system as claimed in claim 8 wherein each building block (60) comprises a procedure (70) requiring a set of parameters (72, 76, 80, 84, 88).

10. A network service system as claimed in claim 9 wherein the interpreter (46) includes a parameter resolution process for retrieving the parameter values to the building block (60) .

11. A network service system as claimed in claim 10 wherein the parameter values are retrieved from any of the service profile (64) , the feature decision graph support data (90) and call variables.