WO2001019094A1

WO2001019094A1 - Control data of intelligent network service

Info

Publication number: WO2001019094A1
Application number: PCT/FI2000/000743
Authority: WO
Inventors: Sanna Laaja
Original assignee: Nokia Corporation
Priority date: 1999-09-03
Filing date: 2000-09-01
Publication date: 2001-03-15
Also published as: FI19991886A; AU7002600A

Abstract

The invention relates to an intelligent network and method of producing an intelligent network service in such a manner that the internal logic of the intelligent network service can also be controlled in other ways than by selecting functions. In the invention, at least one execution part is defined, which contains at least all the functions required by the service logic of the service. In addition, an instruction logic is defined, which indicates the functions of the execution part to be used in the service and the order of execution of the functions. The service logic of the service is formed of the execution part, the instruction logic and values of parameters controlling the service. The service is produced in such a manner that the execution part calls (409) the functions in the order shown by the instruction logic indicated by the service logic.

Description

CONTROL DATA OF INTELLIGENT NETWORK SERVICE

BACKGROUND OF THE INVENTION

The invention relates to the internal structure of a service logic of an intelligent network service and especially to the order of execution of the modules forming the internal structure.

In telecommunications networks intelligence refers to the ability to access stored data, to process the data and to make decisions based on the data. Even the present telecommunications networks, such as the public switched telephone networks PSTN, are to some extent intelligent, since they are capable of processing stored data in routing a call, for instance. A typical 'intelligent' facility in present telecommunications networks is conditional call forwarding in which the call situation must be analysed and the call must be routed on according to the stored call forwarding service profile. Intelligent facilities of this kind have, however, so far been an inseparable part of the basic network and consequently, changing or adding facilities has required software updating, for instance, in all network switching centres.

An intelligent network IN is a network architecture attached to a basic network (fixed or mobile network, for example), which enables a swifter, easier and more flexible implementation and control of services. This is done by moving the control of the services away from the switching centre to a separate intelligent network functional unit. This way, the services can be made independent of the operation of the basic network, and the structure and software of the basic network need not be altered when services are changed or added. Intelligent network services are defined and created independent of the actual implementation and network technology, in which case they can be distributed in the physical network structure. The services are constructed by means of modular functions independent of the used service, which can be joined to each other as components when creating new services. The modular functions are referred to as functions in the following. A function is a reusable, monolithic building block which depicts one entire operation and by means of which an operational service can be formed. The functions can receive values of parameters controlling the service as input, of which allowed numbers transmitted to the validation function of a called number is an example. The function is typically implemented by means of a service independent block SIB. The functions can be facility functions or conditional functions. A facility function corresponds to a part of a program in which an action according to the service, for instance playing an announcement to the subscriber, is performed. A conditional function corresponds to a part of a program in which in executing the program, one of several alternatives is selected according to the parameters associated with the call and service.

By means of a global service logic, required service properties and services are put together from the functions. The global service logic can be described as a kind of glue which defines the order according to which the functions are executed to produce the service.

A problem with the arrangement described above is that functions cannot be combined in any other way than by chaining them for execution one after the other in a certain order. For each service, a separate service logic is then needed even though the services only differed in that one has one less function than the other, for instance, or the same functions are executed in a slightly different order in the services. This substantially restricts the possibility of an operator to create different services and to customize services.

BRIEF DESCRIPTION OF THE INVENTION

It is thus an object of the invention to develop a method and an apparatus implementing the method so as to solve the above problem. The object of the invention is achieved by a method, intelligent network and service logic characterized in what is stated in the independent claims. Preferred embodiments of the invention are disclosed in the dependent claims.

The invention is based on forming the service logic of a single service from several parts, of which one can be common to the service logics of several different services. An individual service logic is formed of an execution part, an instruction logic and values of parameters controlling the operation of the service. The execution part contains all functions or addresses of functions required in the service logic and when the service is triggered, it handles the calling of the functions in the order indicated by the instruction logic and the transmission of the parameters controlling the operation to the functions. The execution part is the part of the service logic which is common to the service logics of several different services. The functions contain all of the detailed logic which is required for implementing the building blocks of the services, i.e. the service independent blocks. The instruction logic defines how a service logic program is constructed from the functions. In other words, the instruction logic defines which functions of the execution part are used in this service and in which order they are executed. The parameters controlling the operation of the service are calling sequences of the functions. Several different services can be implemented using the same execution part by defining a separate instruction logic for each service. This way, an operator has more possibilities to manage the internal logic of the intelligent network service he has created, by selecting not only the functions, but also the order of execution for the functions. The method and intelligent network of the invention provide the advantage that services operating in different ways can be created from the same functions, when the functions are, for example, given different orders of execution. In addition to this, the invention simplifies the structure of the service logic. The invention also provides the advantage that forming the service logic of several parts reduces memory requirements and speeds up the operation: numerous services can be executed using one execution part in such a manner that, when a service is triggered, for instance, the execution part fetches from the subscriber database, for instance, information on which instruction logic to select for this subscriber, and then fetches the required parameter data. This way, the execution part can with quite a small amount of data produce several difference services using the same functions. The techniques used traditionally in user interface environments, such as forming a separate code segment for each service, cannot be used due to memory restrictions and to the fact that loading a code segment into the memory of a service execution environment may be too slow in connection with triggering the service. Communication between programs, i.e. processes, being executed in parallel, such as between the part executing the functions and the part forming the instruction logic, is too slow for executing the functions.

In a preferred embodiment of the invention, the instruction logic to be used is stored in the subscriber data. This makes versatile service creation and customization possible even for each subscriber specifically using the same functions. It is, for instance, possible to leave out an intermediate enquiry from certain subscribers while it is executed for others.

In some preferred embodiments of the invention, the instruction logic is made up of at least two parts: a common part and a subscriber or group-specific part. This allows for a more exact customization of the service while enabling the best possible use of resources (memory space, for instance).

BRIEF DESCRIPTION OF THE FIGURES

In the following, the invention will be described in more detail by means of preferred embodiments and with reference to the attached drawings in which

Figure 1 shows an example of the physical structure of an intelligent network,

Figure 2 illustrates a creation environment of an intelligent network service in the first preferred embodiment of the invention,

Figure 3 shows examples of instruction logics of the first preferred embodiment of the invention, and

Figure 4 shows a flow chart of service provision of the first preferred embodiment of the invention.

DETAILED DESCRIPTION OF THE INVENTION

In the following, the invention and its background will be described using the terms of the ETS 300 374-1 CorelNAP standard and the present structure of intelligent networks, but the invention can also be used in intelligent networks implemented according to other intelligent network standards (such as ANSI, AIN or WIN) or on corresponding execution platforms (such as OSA). In this application, an intelligent network generally refers to a solution in which a node switching a call, a session or packet data contacts a service control function which provides the node in question instructions affecting the switching of the call, session or packet data. The contact by the node in question to the service control function is based on the triggering data of the service in the node. Thggerings, state models and a protocol providing controls or an API (application protocol interface) between a control function and the switching node of a network characterize an intelligent network. A call refers not only to a conventional call, but also to other, possibly virtual, connection states which include user data transmission, such as a data session or transmitting packet data. Examples include a packet radio session (such as a GPRS session), a VoIP (Voice IP) session and a multimedia session according to H.323.

One example of the physical architecture of an intelligent network IN is shown in Figure 1. Figure 1 shows the elements and functions essential for intelligent network services. The functions can be located in network elements in other ways, too.

Network elements which contain a service switching function SSF and a call control function CCF are called service switching points SSP. The SSF interprets instructions sent by a service control function SCF and forwards them to the CCF which initiates the call control functions they require. Correspondingly, the CCF uses the SSF to request instructions from the SCF. The SSF is fixedly connected to the CCF and acts as its interface. Thus, each SSF is in the same switching centre with the CCF. Network elements which contain a service control function SCF are called service control points SCP. The service control function is a centralized authority in the intelligent network, containing, for instance, service logics and an execution environment for service logic programs and handling service- related processing. In connection with an intelligent network service, a service logic program is initiated in the service control point SCP, the operation of the program defining the instructions which the SCP sends to the SSP at each call phase. A service logic program of the invention comprises an execution part, an instruction logic and values of parameters controlling the service. The service control point SCP shown in Figure 1 depicts a service control point at its simplest, since it only contains the service control function SCF and the necessary connections.

A service data function SDF is a database which the SCF uses. The SDF handles access to service-related data, for instance control data of the service logic and network data, and provides a coherent data check. Control data according to the first preferred embodiment of the invention include an identifier of the execution part used by the service logic and a fetch instruction for parameter values controlling the service. Control data can also include information on where to find information on the instruction logic(s) to be used or it can itself contain an identifier of the instruction logic. The invention is not restricted to the above solution, but the execution part, for instance, can be determined from the service identifier in the triggering data or the execution part can be fetched on the basis of a subscriber number from the service data function. The SDF hides from the SCF the actual data implementation and provides to the SCF a logical view of the data. Service logic programs can request and update the data in the SDF. Subscriber-specific or service number-specific data, for instance, can be stored in the SDF. The SDF can either be a database management system in the service control point SCP or it can, as shown in Figure 1 , be a separate service data point SDP which supports the SCF-SDF interface and contains a database DB.

A specialised resource function SRF of an intelligent network is an interface to the network mechanisms which involve interaction with the subscriber. The SRF can be connected to intelligent peripherals IP containing more advanced speech processing functions than switching centres or it can reside in the service switching point SSP. Additional services provided by an intelligent peripheral IP are audio messages, synthetic sound and speech recognition apparatuses and sound generation, for instance.

Functions related to management are a service creation environment function SCEF, service management function SMF and service management access function SMAF. The SMF comprises service management, maintenance and location monitoring, the SMAF provides an interface to the SMF and the SCEF enables definition, development, testing and feeding of intelligent network services to the SMF which stores the services for the SCF to use. An intelligent network point comprising the functions related to management is a service management point SMP which controls the management, provision and execution of the service. The SMP for instance manages the database, monitors and tests the network, manages network traffic and collects network data. The SMP can connect to all other physical entities.

A service creation environment point SCEP is used to define, develop and test intelligent network services and to feed the service to the service management point SMP. In other words, creating the services takes place through the SCEP.

A service management access point SMAP is a physical entity which provides certain users access to the service management point SMP. Through it, it is possible to define subscriber-specific service data. The network elements shown in Figure 1 are usually connected to each other through a signalling network SS7. Other networks, such as the ATM and IP, can also be used. The SCP and/or the SMP can use the services of the SDP directly or through a signalling network using the INAP protocol.

The system also comprises a special subscriber data management logic created in the service control point SCP. The database resides physically in the service data point SDP. In general, an operator creates and deletes subscriber records of the subscriber database through the service management point SMP, but they can also be created and deleted through a telephone network connected to the intelligent network. Subscriber data can contain information for at least some intelligent network services on which instruction logic(s) to fetch for this subscriber to provide the service.

A telecommunications system implementing the functionality of the present invention comprises not only means required for prior art service implementation, but also means for maintaining the execution part and the instruction logics and for combining them in such a manner that the execution part produces the service in the order of execution of functions shown by the instruction logic. The execution part either contains the functions or the addresses of the functions with which to call them. In creating a service in the first preferred embodiment of the invention, the execution part is selected, for whose functions instructions are defined, from which instructions the service instruction logic is formed. The instruction logic is stored in the database of the SMP and SCP, i.e. in the SDP which can also be called a service database. A started up execution part of the service logic program then interprets the control data found in the SCP database, fetches the correct instruction logic and the parameter values, calls functions in the order defined by the instruction logic and forwards to the functions the fetched parameter values. In other words, the execution part executes the functions of the service logic in the desired order. In the first preferred embodiment of the invention, the execution part fetches the parameter values in advance before the execution of any of the functions, and the execution of the instruction logic may be preceded by fetching parameter values for the parameters indicated in the instruction logic. In a second preferred embodiment of the invention, the parameter values are fetched during the execution of the instruction logic before executing each function.

Figure 2 illustrates a creation environment SCEP of a intelligent network service in the first preferred embodiment of the invention. It comprises a user interface Ul, an application part AP and a database DB2 or a connection to a database and a connection to the SMF. In the first preferred embodiment of the invention, the database contains information on the enabled functions (not shown in Figure 2) and execution parts. In the first preferred embodiment of the invention, the information on the execution parts SI comprises an identifier (SK1 , SK2) of the execution part and a function list (F1 , F2, F3, F4; F1 , F3, F5) of each execution part. In addition, in the first preferred embodiment of the invention, the database of the invention contains information on the defined instructions V1 and their definition M1 as shown in table T1 , for instance. Through the user interface, a creator of a service can attach to the functions a required number of instructions and create the service in such a manner that a service logic containing the same functions is executed with different instructions. Examples of instruction logics related to the execution part SK1 are shown in Figure 3. The instructions are typically logical operators (AND, OR, XOR), skip instructions (SKIP n, OVERR) or instructions related to the order of execution (CHAIN, PRIORITY). A service logic providing calling instructions, for instance, can be such that it skips a function which provides an audio message on the area code when the caller calls within the area of the area code. It should be emphasized that the instructions are in no way restricted to the examples shown in the figure, but other kinds of instructions, such as a logical NOT, can also be defined. In the service creation environment, it is also possible to create new execution parts by means of the functions.

Figure 3 shows a few very simplified examples of the contents of the instruction logics according to the first preferred embodiment of the invention for the execution part SK1 shown in Figure 2, whose function list is F1 , F2, F3, F4. The instruction logics have been created in the creation environment and then stored in the service database SDP. In the first preferred embodiment of the invention, instructions are attached to the instruction logic in the order that the functions are in the execution part. One function can also be given several instructions, even though in Figure 3 only one instruction is given for simplicity's sake. Instructions can also be given subscriber or group-specifically by creating sub-routines or sub-classes for the instruction logic. In the first preferred embodiment of the invention, the same number of instructions is always attached to each function. In other preferred embodiments of the invention, it is possible to attach a different number of instructions and/or one instruction can be defined as a default instruction which the execution part uses when there is no instruction attached to a function. Regardless of how the instruction logic is formed, it is a kind of a code which is interpreted by the execution part of the service and which defines which functions to execute and in which order. In the example shown in Figure 3, the service according to the instruction logic OL1 is produced by executing the functions in the following order: function F2, function F4, function F3 and function F1. Correspondingly, the service of instruction logic OL2 is produced by executing first the function F1 and then the function F3. In the instruction logic OL2, the function F2 is not executed, because the instruction of the function F1 is to skip one function. Correspondingly, the function F4 is not executed in instruction logic OL2, because the instruction of the function F3 is not to execute the remaining functions. What instructions the instruction logic OL2 has for the functions F2 and F4 does not matter. If the embodiment supports default instructions, they can be used as instructions for the functions F2 and F4 when creating the instruction logic OL2.

In a preferred embodiment of the invention, no separate instructions are used, but the instruction logic contains a function list in which the identifiers of the functions, for instance the identity numbers of the functions, are in the order in which the functions are to be executed. In addition, skip instructions, such as "move to step X" can be attached to conditional functions. For instance, the instruction logic OL1 shown in Figure 3 could be F2, F4, F3, F1. In this embodiment, too, it is possible to create sub-routines or sub-classes for the instruction logic by making subscriber or group-specific function lists for at least a part of the functions. Instruction logics using the same execution part may all be associated with a different service. It is then preferable to use the same identifier for the instruction logic as for the service. It is also possible associate a service and an instruction logic with each other in other ways. If different instruction logics using the same execution part are associated with the same service, i.e. they are different versions of the service, the instruction logic can be selected on the basis of additional information: for instance the version is selected on the basis of the caller's area code or the version of the subscribed service is indicated in the subscriber data of the caller.

Figure 4 shows a flow chart on how an intelligent service is provided according to the first preferred embodiment of the invention. In the first preferred embodiment of the invention, the execution part of the service corresponds to a service logic program SLP which also contains functions and can execute them by means of the instruction logic and the parameters controlling the operation of the service. Thus, in the first preferred embodiment of the invention, the execution part is an interpreter, for instance a Java virtual device. In addition, the execution part is itself a program to be interpreted in the execution environment of the service control point. The execution environment is thus in the first preferred embodiment of the invention an environment interpreting the execution part. In a preferred embodiment of the invention, the execution part is a compiled code program communicating with protocol stacks and service database programs. In another embodiment of the invention, the service execution part can contain the addresses of the functions. In yet another preferred embodiment of the invention, the functions and the execution parts of the service are made up of one single executable code module. With reference to Figure 4, the intelligent network service is triggered in step 401 from the service switching point to the service control point. As a result of this, in step 402, information on the service execution part is fetched from the control data of the service logic on the basis of the service data in the trigger message. In step 403, the execution part is "started up" to handle the execution of steps 404 to 410 below. The execution part is "started up" by providing it with an input and the information in the service trigger message. In step 404, the service execution part fetches from the trigger message information, the required service identification, such as the identifier of the calling subscriber and/or the service. In step 405, the execution part fetches from the subscriber data of the subscriber triggering the service in the service database information on which instruction logic to select for this subscriber for this service. In other words, the identifier of the instruction logic to be selected is fetched. There may be several instruction logics to select, but there is always at least one. When the required identifiers are known, the required instruction logic(s) is (are) fetched from the service database in step 406. Similarly, the required values of the parameters controlling the service are fetched from the service database in step 407. In the first preferred embodiment of the invention, the value of the parameter controlling the service can be a general, group-specific or subscriber-specific value. A general value is the same for all subscribers using the service. A group-specific value is the same for all subscribers in a certain group. In subscriber-specific parameters, each subscriber is defined his own parameter value. The parameters are specific for each function.

The execution part can now construct the service logic program in step 408, i.e. it interprets the instruction logic in step 408 and forms a call order of functions according to the instruction logic. After this, it calls the functions in the order defined in the instruction logic in step 409, and transmits the parameter values for the functions in step 410. The functions are then executed in step 411 in the order indicated by the instruction logic. In practice, steps 409 to 411 form several sequentially repeating patterns, because the functions are called one at a time, the parameter(s) is (are) transmitted for one function at a time and only one function is usually executed at a time. Transmitting the parameters is preferably done in such a manner that the execution part calls the functions using the parameter values attached to them. The steps presented above in connection with Figure 4 are not in an absolute time order and some of the steps can be performed simultaneously or differing from the presented order. Other functions for producing the service can also be executed between steps. Some of the steps can also be left out, such as step 407 in the embodiments which only use general parameters whose values are known by the execution part as part of a function address, for instance. In embodiments which use a default instruction logic, it is possible to check in step 405 if the instruction logic identifier was found and if not, to fetch a default instruction logic in step 406. In addition, in embodiments where the functions are in the order of execution in the instruction logic, the service logic need not be constructed (step 408), since the functions are called in them step by step one at a time. Step 402 can be skipped in the execution platforms of the service control function in which only one execution part is used.

In another preferred embodiment of the invention, the instruction logic to be used is stored elsewhere than in the subscriber data, for instance in the group-specific data or service-specific data. In such a case, the information on the instruction logic is fetched from there in step 404.

Even though to illustrate the invention, the above states that one execution part can be controlled by several different instruction logics, the solution of the invention can be applied even if one execution part was controlled by only one instruction logic.

It will be understood that the above description and the related figures are only intended to illustrate the present invention. It will be obvious to those skilled in the art that variations and modifications can be made to the invention without departing from the scope and spirit of the invention disclosed in the attached claims.

Claims

1. A method of producing a service of an intelligent network, which intelligent network uses functions which can be attached to each other as components to produce the service and which can receive values of parameters controlling the service as input, characterized in that the method comprises the following steps: defining at least one execution part which contains at least all the functions required by the service logic of the service or addresses to them, defining at least two different instruction logics which both indicate both the functions required by the service according to the instruction logic and the order of execution of the functions, forming the service logic of the service by defining the execution part to be used, the instruction logic and the values of the parameters controlling the service, and producing the service in such a manner that the execution part calls the functions in the order shown by the instruction logic indicated by the service logic of the service.

2. A method as claimed in claim 1, characterized in that the method also comprises a step in which one single executable code module is formed of the execution part and the functions for the execution environment of the intelligent network service.

3. A method as claimed in claim 1 or 2, characterized in that the method also comprises the following steps: storing in subscriber data an identifier of the instruction logic to be used in the service for this subscriber, and fetching from the subscriber data information on the instruction logic to be used when the service is triggered.

4. A method as claimed in claim 1,2 or 3, characterized in that the method also comprises a step in which an instruction logic is formed in such a manner that it comprises a general part common for all and a subscriber-specific part.

5. A method as claimed in claim 1,2 or 3, characterized in that the method also comprises a step in which an instruction logic is formed in such a manner that it comprises a general part common for all and a group- specific part.

6. An intelligent network (IN) which comprises a service execution environment (SCP) for executing the service logic of the service, the service logic comprising one or more functions, to which values of parameters controlling the service can be given as input, characterized in that the intelligent network (IN) is arranged to maintain at least one execution part which contains at least all the functions required by the service logic of the service or addresses to them, at least two different instruction logics which both indicate both the functions required by the service according to the instruction logic and the order of execution of the functions, and to form the service logic of the service from the execution part, one instruction logic and the values of the parameters controlling the service, the service execution environment (SCP) is arranged in response to the triggering of the service to start up the execution part of the service, and the execution part is arranged to fetch the instruction logic of the service, to interpret it, to call the functions in the order indicated by the instruction logic and to give, when necessary, the values of the parameters controlling the service as input to the functions.

7. An intelligent network (IN) as claimed in claim 6, characterized in that the execution part resides in the execution environment (SCP) of the intelligent network service control function and the instruction logic resides in the service database (SDP) of the intelligent network service.

8. An intelligent network (IN) as claimed in claim 6 or 7, characterized in that the service execution environment (SCP) is an interpreting environment and the execution part of the service itself is a code to be interpreted.

9. An intelligent network (IN) which comprises a service creation environment (SCEP) for creating a service logic of a service from one or more functions which can receive values of parameters controlling the service as input, characterized in that the intelligent network (IN) is arranged to maintain at least one execution part which contains at least all the functions required by the service logic of the service or addresses to them, the service creation environment (SCEP) is arranged to define at least two different instruction logics which both indicate both the functions required by the service according to the instruction logic and the order of execution of the functions, and to form the service logic of the service from the execution part, one instruction logic and the values of the parameters controlling the service.

10. A service logic of an intelligent network service, which produces the service by executing at least two functions which can be given values of parameters controlling the service as input, which parameter values the service logic comprises, c h a r a c t e r i z e d in that the service logic also comprises an instruction logic which indicates the functions to be used in the service and their order of execution, and an execution part which contains at least all the functions required by the service logic of the service or addresses to them and which execution part is arranged in response to the triggering of the service to fetch the instruction logic of the service, to interpret it, to call the functions in the order indicated by the instruction logic and to give, when necessary, the values of the parameters controlling the service as input to the functions.

11. A service logic of an intelligent network service as claimed in claim 10, c h a r a c t e r i z e d in that the execution part is arranged to fetch the values of the parameters controlling the service in response to the triggering of the service.

12. A service logic of an intelligent network service as claimed in claim 10 or 11 , c h a r a c t e r i z e d in that the execution part and the functions form one executable code module.