Data processing: artificial intelligence – Knowledge processing system – Knowledge representation and reasoning technique
Reexamination Certificate
1999-11-15
2002-02-12
Davis, George B. (Department: 2122)
Data processing: artificial intelligence
Knowledge processing system
Knowledge representation and reasoning technique
C707S793000
Reexamination Certificate
active
06347311
ABSTRACT:
FIELD OF THE INVENTION
This invention concerns implementation of service independent building blocks (SIB). These building blocks are used for building intelligent network services.
TECHNICAL BACKGROUND
The demand for support and production of various services has directed the trend in telecommunication networks towards the so-called Intelligent Network (IN). The intelligent network can be defined as an architecture that can be applied to most telecommunication networks irrespective of the network technology. It aims at bringing about telecommunication service's providing an additional value and at control and management of these. It is a special feature of the intelligent network to provide modular functions which are independent of the service used and which may be connected to one another as components when developing new services, whereby it is easier to define and design new services. Another special feature is that the supply of services is independent of the telecommunication network. The services are separate from the lowermost physical network structure, which means that they can be distributed.
CCITT defines the Intelligent Network Conceptual Model (INCM) in the CS-1 (Capability Set 1) recommendation. The model includes four planes, each of which represents an abstract view of the possibilities offered by the intelligent network.
FIG. 1
shows the conceptual model from the viewpoint of service logic.
The top plane is called the Service Plane (SP) and it determines how the service will appear to its user. The view contains no information on the implementation of services in the intelligent network. The service includes one or several lowermost components of this plane, the Service Feature (SF). The SF is the smallest part of the service discernible to the user. They may be used in the same way as building blocks for building new complex services.
The second topmost plane of the model is the Global Functional Plane containing a view of the intelligent network as service independent standards and as Service Independent Building Blocks (SIB), from which the service characteristics and services discernible on the topmost plane are collected with the aid of service logic. The Basic Call Process (BCP) covering the entire network and the Point of Initiation (POI) and Point of Return (POR) between the BCP and the SIB also belong to this plane. For each service feature SF of the preceding service plane there are Global Service Logic (GSL) items on this plane which at the stage of service creation make use of SIBs located on the other side of the interface. The service plane SF includes one SIB or several SIBs. In principle, the SIB is a sub-programme the operation of which is well defined.
The second lowermost plane is called the Distributed Functional Plane (DFP). It is divided into Functional Entities (FE) and interactive relations between these. The SIBs of the preceding plane include Functional Entity Actions (FEA) included in the functional entities. Each entity may perform tasks of different types. Inside each functional entity most tasks may be performed as one or several sub-functions. On this plane, the SIB of the upper plane is implemented by a Distributed Service Logic (DSL) utilising the functional entities FE of this functional plane and any functions provided by the connections set up by them. One global service logic GSL of the global functional plane leads to one or several service logics X, Y, Z . . . on the distributed functional plane.
The lowest plane, the Physical Plane, is formed by Physical Entities (PE) supporting tasks of the distributed functional plane, by interfaces between these and by protocols. On this plane, the service logic may be installed and performed by any physical item including a control function of the concerned service. The behaviour of the item is determined by the functional entity on the preceding DF plane.
SIBs of the global functional plane are examined more closely in the following.
FIG. 2
is a graphic view of the SIB process. The following matters can be distinguished in each SIB:
1) the logical origin from which the SIB's function begins,
2) the input parameters used by SIB in its function,
3) the output parameters resulting from SIB's function, and
4) the logical end where SIB's function ends.
ETSI does not define different SIBs by name nor their function, but defines the exchange of messages taking place in the telephone exchange. Through it the standard also affects the SIBs.
Examined from the viewpoint of the service, the SIBs form a list wherein the names of SIBs and the parameters needed by the SIBs are listed. The service is carried out in such a way that the list is gone through and individual SIBs are performed. This is illustrated in
FIG. 3
where there are a number of n SIBs in the list. At first the instruction pointer IP points at the start of the list and after performance of an individual SIB the pointer is moved forward by one instruction to the next point or a jump is made to some other point in the list and the SIB located there is performed.
The objective is that the SIBs would be service independent, in other words, the same SIBs could be used in the implementation of different services. Validation A is an example of this kind of service. It should also be noticed that different versions may be required of the same service. One teleoperator may need such a validation A which includes a replacing number A, whereas another teleoperator wants validation A without any replacing number A.
In terms of programming technology, SIB can be implemented as a sub-programme. Firstly, the sub-programme call must hereby relay the parameters used to the sub-programme implementing the SIB and, secondly, compiling is typically associated with the fact that the number or type of parameters to be relayed in the sub-programme call can not be changed without changing the source code. The final outcome is that SIB can not be implemented service independently, if its parameters are relayed in the sub-programme call.
Service independence is prevented by the circumstance in particular that it is not possible to be sure of whether the number and type of parameters are the same in any new service programmes as in the present service programmes. It has been necessary in practice to supplement the set of SIBs and to change existing SIBs into another form and it has been especially necessary also to change the number of parameters. The problem then has been constantly to change sub-programme interfaces generally so that more information, that is, more parameters than before must be relayed to the SIB. This again has meant that as the sub-programme interface changes a new version must be made of the programme, even though the need for new versions is somewhat dependent both on the programming language and on the programming method.
If trouble occurs, corrections must be made in several programme versions. The occurrence of software versions causes a need for maintenance, which again reduces the quality of the software and increases costs. In addition, the existence of numerous different versions causes an increased need of documentation.
It is not quite simple in terms of programming technology to implement SIBs without a sub-programme mechanism. On the other hand, a sub-programme mechanism will cause occurrence of source code versions as well as the problems described in the foregoing.
It is an objective of the present invention to bring about a method making sure that implemented SIBs are really service independent. The objective is achieved with the attributes presented in the independent claims.
BRIEF SUMMARY OF THE INVENTION
According to a first characteristic feature of the invention, no SIB set is defined especially, but the SIBs are instead divided logically into two groups: assisting and performing SIBs respectively. This is done because one can be rather sure as regards some SIBs that they will remain unchanged and thus truly service independent, but there is no certainty as regards some, and this is the f
Aakula Jukka
Hartikainen Eeva
Saviranta Tapio
Altera Law Group
Davis George B.
Nokia Networks Oy
LandOfFree
Implementation of service independent building blocks does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Implementation of service independent building blocks, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Implementation of service independent building blocks will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2943729