CA2125239A1 - Network service provisioning - Google Patents
Network service provisioningInfo
- Publication number
- CA2125239A1 CA2125239A1 CA 2125239 CA2125239A CA2125239A1 CA 2125239 A1 CA2125239 A1 CA 2125239A1 CA 2125239 CA2125239 CA 2125239 CA 2125239 A CA2125239 A CA 2125239A CA 2125239 A1 CA2125239 A1 CA 2125239A1
- Authority
- CA
- Canada
- Prior art keywords
- service
- building blocks
- building block
- building
- parameters
- Prior art date
- Legal status (The legal status 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 status listed.)
- Abandoned
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
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/135—Service creation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13502—Indexing scheme relating to selecting arrangements in general and for multiplex systems primitives - inc. service-independent building blocks [SIBBs]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13525—GUI - graphical user interface, inc. for service creation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13547—Indexing scheme relating to selecting arrangements in general and for multiplex systems subscriber, e.g. profile, database, database access
Abstract
A network service provision system and method for advanced intelligent networks uses a hierarchy of three structures: service building blocks, features, and services. Services are defined in terms of features. Features are defined in terms of building blocks. The building blocks are simple software defined procedures requiring a set of parameters. The features are decision graphs built from building blocks using data. Services are then built using a subscriber profile from combinations of service building blocks and feature decision graphs together with the subscriber profile and support data. 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 UAIN 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 -parame~ers; 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 Descri~tion of the Drawinas 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 Descri~tion 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 queryprocessors 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 sys`tem 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.
~12~239 -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 UserID 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 subscriberls 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. soth 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. Dèploying 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.
212523g -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 nnm~n~geable 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 ex~m;ning 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 suilding_slock_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 `- 2125239 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
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 UAIN 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 -parame~ers; 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 Descri~tion of the Drawinas 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 Descri~tion 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 queryprocessors 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 sys`tem 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.
~12~239 -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 UserID 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 subscriberls 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. soth 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. Dèploying 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.
212523g -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 nnm~n~geable 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 ex~m;ning 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 suilding_slock_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 `- 2125239 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.
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 (11)
1. 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.
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.
2. A method as claimed in claim 1 further comprising the step of retrieving a service profile for the service to be provided.
3. A method as claimed in claim 2 wherein the step of retrieving a service profile 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.
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.
6. A method as claimed in claim 5 wherein the step of interpreting includes the step of determining which feature or building block to invoke, passing execution control to the feature or building block, and retrieving parameter values from various locations and passing these values to the building blocks.
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, retrieving the building block template and using a pointer into the feature decision graph data structure, sequentially retrieving all parameters to the building block.
8. 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.
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.
9. A network service system as claimed in claim 8 wherein each building block comprises a procedure requiring a set of parameters.
10. A network service system as claimed in claim 9 wherein the interpreter includes a parameter resolution process for retrieving the parameter values to the building block.
11. A network service system as claimed in claim 10 wherein the parameter values are retrieved from any of the service profile, the feature decision graph support data and call variables.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2125239 CA2125239A1 (en) | 1994-06-06 | 1994-06-06 | Network service provisioning |
| PCT/CA1995/000297 WO1995034175A1 (en) | 1994-06-06 | 1995-05-23 | Network service provisioning |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2125239 CA2125239A1 (en) | 1994-06-06 | 1994-06-06 | Network service provisioning |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2125239A1 true CA2125239A1 (en) | 1995-12-07 |
Family
ID=4153740
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA 2125239 Abandoned CA2125239A1 (en) | 1994-06-06 | 1994-06-06 | Network service provisioning |
Country Status (2)
| Country | Link |
|---|---|
| CA (1) | CA2125239A1 (en) |
| WO (1) | WO1995034175A1 (en) |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| SE511357C2 (en) * | 1996-12-19 | 1999-09-20 | Ericsson Telefon Ab L M | Method and apparatus of a telecommunications network |
| EP0873026B1 (en) | 1997-04-14 | 2005-01-12 | Alcatel | Method for providing a service for users of a telecommunication network |
| DE69731182T2 (en) * | 1997-04-14 | 2005-10-13 | Alcatel | Messaging method between a service switching center and a service control device in a telecommunications network |
| ATE298173T1 (en) * | 1997-04-14 | 2005-07-15 | Cit Alcatel | METHOD FOR OFFERING AT LEAST ONE SERVICE TO TELECOMMUNICATION NETWORK USERS |
| US6002756A (en) * | 1997-04-18 | 1999-12-14 | At&T Corp | Method and system for implementing intelligent telecommunication services utilizing self-sustaining, fault-tolerant object oriented architecture |
| FI106988B (en) * | 1997-05-16 | 2001-05-15 | Nokia Networks Oy | Realization of service-independent design elements |
| US5974252A (en) * | 1997-08-21 | 1999-10-26 | Alcatel Usa Sourcing, L.P. | System and method for implementing programmable transaction capabilities application part communication protocol |
| US6047059A (en) * | 1997-08-21 | 2000-04-04 | Alcatel Usa Sourcing, L.P. | System and method for communicating transaction capabilities application part information |
| CA2313043A1 (en) | 1997-12-04 | 1999-06-10 | British Telecommunications Public Limited Company | Communications network |
| FI108497B (en) | 1998-02-03 | 2002-01-31 | Nokia Corp | Provision of services in a telecommunications network |
| FI108325B (en) | 1998-02-03 | 2001-12-31 | Nokia Corp | Provision of services in a telecommunications network |
| FI108495B (en) | 1998-02-03 | 2002-01-31 | Nokia Corp | Provision of services in a telecommunications network |
| FI108499B (en) | 1998-02-03 | 2002-01-31 | Nokia Corp | Production of services in a telecommunications network |
| FI108496B (en) | 1998-02-03 | 2002-01-31 | Nokia Corp | Provision of services in a telecommunications network |
| JP2000156733A (en) * | 1998-05-28 | 2000-06-06 | Alcatel Usa Sourcing Lp | Ain/inssp extension product |
| US6330319B1 (en) | 1998-12-23 | 2001-12-11 | Ericsson Inc. | System and method for adding services to computer telephone systems |
| DE19920640A1 (en) * | 1999-04-29 | 2000-11-02 | Siemens Ag | Procedures for creating utilities |
| FI19991886A (en) * | 1999-09-03 | 2001-03-03 | Nokia Networks Oy | Intelligent network service control information |
| DE10109899A1 (en) * | 2001-02-23 | 2002-09-12 | Siemens Ag | Process for realizing requirements of telecommunication subscribers |
| FI20015009A (en) * | 2001-06-08 | 2002-12-09 | Sonera Oyj | Decentralized object component network |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5323452A (en) * | 1990-12-18 | 1994-06-21 | Bell Communications Research, Inc. | Visual programming of telephone network call processing logic |
-
1994
- 1994-06-06 CA CA 2125239 patent/CA2125239A1/en not_active Abandoned
-
1995
- 1995-05-23 WO PCT/CA1995/000297 patent/WO1995034175A1/en active Application Filing
Also Published As
| Publication number | Publication date |
|---|---|
| WO1995034175A1 (en) | 1995-12-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2125239A1 (en) | Network service provisioning | |
| US5303369A (en) | Scheduling system for multiprocessor operating system | |
| US5889848A (en) | Peripheral control in an intelligent network | |
| US5724406A (en) | Call processing system and method for providing a variety of messaging services | |
| CN1104797C (en) | Telecommunication switch having programmable network protocols and communications services | |
| US5778059A (en) | Distributed predictive and event-driven processing environment | |
| US6317492B1 (en) | System and method for developing and processing automatic response unit (ARU) services | |
| US5418793A (en) | Method and apparatus for testing a complex entity | |
| JPH07202979A (en) | Telecommunication system interface | |
| EP0903922A2 (en) | Voice processing system | |
| US5991541A (en) | Dynamically modifiable call processing methods and apparatus | |
| WO1999009723A2 (en) | Method for implementing programmable transaction capabilities application part (tcap) protocol | |
| US5754795A (en) | Method for communication between processors of a multi-processor system | |
| US6064729A (en) | Peripheral control in an intelligent network | |
| US6002758A (en) | System and method for developing message processing applications | |
| US6243697B1 (en) | Detecting service interactions in a telecommunications network | |
| CA2245156C (en) | Service logic portability based on interface definition of execution environment in an intelligent network | |
| US5974118A (en) | System for coordinating on-line updates of call flows, functions and voice prompts of a telephony applications | |
| JP3223953B2 (en) | Service logic program identification method | |
| US5894574A (en) | Apparatus and method for SIB-based global title translation services | |
| US6330319B1 (en) | System and method for adding services to computer telephone systems | |
| AU743834B2 (en) | A control type or service independent building block | |
| CN1612581A (en) | Telecommunications service program | |
| US20050063417A1 (en) | Communication system and method | |
| Peng et al. | Feature Interaction Detection Technique Based on Feature Assumptions. |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Dead |