Harald Seim
This paper describes a prototype of a service control system where object oriented techniques are combined with rule based reasoning. The background for this approach is that object oriented techniques are well suited for modelling the real world (by defining objects and properties) while heuristic rules are well suited for modelling human reasoning (by describing conditions for when actions are to be taken). In the prototype object oriented techniques are used to model the network and the subscribers, while heuristic rules are used to describe the services.
The service control system acts as a server for a telecommunication network, i.e. it receives requests and returns switching instructions. The prototype contains a graphical network simulator acting as its client. This is used for simulation and testing of services before they are introduced in the real network. The prototype may be connected to any type of network, and is today used as a service control system for an ATM broadband network at Norwegian Telecom Research.
Norwegian Telecom Research considered in an early phase of its work on intelligent networks that object oriented techniques should be used. Object orientation was found to be very well suited for modelling complex systems. This because of the advantages given by classification, instantiation, encapsulation, inheritance, dynamic binding, etc.
A telecommunication network can be modelled by objects with properties and operations. Typical objects in a network are physical entities like switches, multiplexers, trunks, subscriber lines, and more abstract things like calls and connections. Some properties of a switch may be location, type, number of lines, bandwidth, etc., while its operations may be the functions for call handling.
Services are more fuzzy things to model. What you can do is to tell how you want parts of a service to work. You can for example say: "If someone calls me on this number, I would like to pay for the call." Then you add: "If someone calls me during the office hours, the call should be routed to my office, but if someone calls me in the night or in the weekend, then the call should be routed to my home." And you go on, describing different situations and conditions and the corresponding actions you want to be taken.
This situation is very typical for many kinds of services. Most services are built up by a set of actions with conditions describing when the actions shall take place. Examples of action types are: charging, routing, call completion, authorisation, encryption, etc. Examples of condition types are: time of day, day in week, origin of call, type of terminal, type of service, etc.
How should we model services allowing you to do all these kinds of customisation, i.e. mix all kinds of conditions with all kinds of actions and action descriptions? One way is to use heuristic rules.
A heuristic rule consists of two parts: a condition part and an action part. The condition part describes when the action part may be executed. The condition part consists of a set of logical expressions (or conditions), all evaluating to true or false. If all conditions in the condition part are true, then the actions in the action part may be executed. A common syntax for rules is: IF conditions THEN actions.
The rules are normally not ordered. Instead, a generic inference engine is used to determine which rule is to be fired when. When the inference engine is started, it first tries to evaluate the conditions of all the rules in the system. Then it ends up with a set of rules that may be fired. If there is more than one rule in this set, there is a conflict. After a conflict resolution, the inference engine ends up with one single rule that is executed. This cycle goes on until there are no more rules to fire.
Using an inference engine saves the system developer from a lot of work with sequencing problems. New rules may be added without thinking of where and in what order. We get a very weak coupling between different rules, and this is something we can take advantage of when the system has to be modified. This is very important when dealing with frequently changing telecommunication services.
The service control system prototype is built on the concepts of object orientation and rule based reasoning. The main module consists of a generic inference engine, a set of rules describing the services and an object oriented model of the network and the subscribers/users. In Figure 1, this module is called "Rule Based Service Control System".
The service control system interacts with the switching network over a communication link. It receives requests for service control and reports on events in the network. When the requests have been processed, switching operations in the network are called from the service control system.
During the last year the system has been developed from a plain stand- alone prototype to an on-line real-time service control point in an ATM broadband network. The service control point communicates with a connection controller in the ATM network by TCP/IP over an Ethernet connection.
For testing purposes, a graphical network simulator may be used instead of or in addition to a real switching network. Then the operations on the network are simulated and the current network status is displayed on a graphical screen.
In addition to the network, the service control system is connected to a number of databases containing information about the network, the subscribers and the services.
The network and the subscriber databases contain the object oriented models of the network and the subscribers. The network model has access points representing the points where the service users are connected, legs representing parts of connections and connection points representing the connection of two or more legs. All legs and connection points concerning one call, are contained within one socket.
The service databases are really rule bases, containing heuristic rules and some objects used for classification of services, requests and events and for storing of temporary data.
The rules are used for reasoning about the network model. Data in the network model is used by the conditions in the rules and modified by the actions. The real world is covered behind the surface of the objects, and abstracted and simplified by the object properties and operations. This makes the service control system independent of the underlying network.
Connected to the service control system is also a service creation system. This is a development environment for both the object oriented network model and the rule based service logic. The service creation system contains editors for objects and rules, graphical displays of the object hierarchy and the rule network, compiler, etc.
As mentioned above, an object oriented network model is used internally in the service control system to abstract and encapsulate the real network. The model can be considered as a map of the real world, containing only the information necessary for the service control system, e.g. only objects related to call handling.
The prototype system is based on the "Connection Control Model" drafted in "ETSI DTR/NA-6001, version 2, 14 September 1990". This model is using objects called socket, leg and connection point to describe connection handling in the switching network. Each object is characterised by a set of properties and operations that may be accessed by the service control system.
Figure 2 shows a part of the object hierarchy used in the network model. There are circles in front of the object classes, triangles in front of the object instances and squares in front of the object properties. Operations on the objects are not shown in the figure.
The root class in the hierarchy is called cc_socket_object. The classes leg, conn_point, cc_socket_ind and cc_socket are all children of this class. Because of this, it is possible to access instances of all these classes by referring to the root class. A property (attribute) called socket_id is inherited by all objects in the hierarchy. This is used to identify object instances belonging to the same socket.
If we take a closer look at the leg class, we see that it has the following properties: id to distinguish between different leg instances, conn_id to distinguish between several legs in hold state, state to represent the connection state of the leg (e.g. free, unjoined, joined, etc.), socket_id to identify the socket it belongs to, conn_point_id to identify a possible connection point instance to which the leg is connected and access_point_id to identify a possible service access point instance in the remote end.
The possible operations on legs are: create to create an instance of a leg object, free to delete an instance of a leg object, join to connect a leg to a connection point, split to disconnect a leg from a connection point, send_receive to send or receive information on a leg, modify to modify an attribute value in a leg and poll to read an attribute value in a leg.
When the service control system receives a message from the switching network, it makes an instance of either a cc_provide_instruction object or a cc_event object, depending on the type of message received. The properties of this object instance are used to store the parameters contained within the received message. During the service execution, these property values are used to analyse and classify the message. Together with the other network objects, this information is used to make operations on the network.
The service logic is contained within the rule bases connected to the system. The rules are used for analysis of network status, incoming requests and event reports before actions are taken. If more information is needed before a decision is taken, the network is polled.
The rule bases are loaded and unloaded depending on their use. When there are no rules loaded into the system to handle a particular situation, the rule bases are searched for additional rules.
One goal with the rule based service control system is to have a service independent system, i.e. a generic system where all kinds of services can be executed. In a service independent service control system there is no service specific functionality and no reference to any particular service. This means that if a new service is to be introduced, no modification of the service control system itself should be necessary.
This problem is very difficult to solve by sequencial programming. Traditional software systems have formular-driven control, i.e. they consist of a hard coded pre-defined sequence of statements. This implies that a traditional program cannot call a routine if not a reference to that routine is hard-coded into the program before compilation.
Many object oriented systems have a capability called dynamic binding. This may partly solve the problem, since the procedure references may be changed at run-time. But there must still be a call to a routine, even if the routine itself is bound to the call at run-time.
Rule based systems have a much more powerful way of solving this type of problem, called pattern-driven control. In a rule based system there are no routines to be called. Each rule is triggered by its own conditions and independently of other rules. The connections between different rules are data rather than routine calls. The rules share a common set of data, very often an object oriented data model, and the program flow is continuously changed as the data values change.
This last technique is utilised in the prototyped system. A model of the switching network, the subscribers and the service requests are used as a common data set for the rules. The rules themselves describe how to execute services by setting conditions to the data model for when their actions are to be executed.
As a result of this, the service control system itself needs no direct references to the service specific rules to execute them. The only information the system needs about these rules, is in what rule base they are stored. For the same reason there is no need for references between different service specific rules in the system. A rule has only to know about itself and when it is to be executed.
Figure 3 shows an example of how rules can be linked together by common data. For example data used as condition in one rule can be a conclusion of another rule. The rules in the figure may be stored in different rule bases and have no direct reference to each other.
Heuristic rules may be used to describe problem solutions in a quite different way than procedures. Instead of describing a solution from the very beginning to the very end, all in the right order, you can describe a solution by "if ... then ..." rules in an arbitrary order. Rules may also be taken from different sources and put together without thinking of the connection between them.
The use of heuristic rules is very similar to much of our own reasoning process, and this may shorten the link between a service idea and a service implementation. A service designer may have an idea about how a call waiting service should work by describing it like this:
"If someone calls a busy subscriber, then both the calling and the called subscriber should be notified about this."
"If the called subscriber quits the current connection before the calling subscriber hooks on, then the calling subscriber should be notified and the called subscriber should be able to answer the new call."
This is a very simple example of how a service may be described by heuristic rules. Figure 4 shows a simplified version of how the two rules may be implemented in the system.
For a more advanced service, the number of rules may be very high, and may also be increasing after some operational experience. While this would have been difficult to handle in a traditional system, where the ordering of statements is very important, a rule based system would have taken the rules just as they are. The ordering is irrelevant, since this is solved by the inference engine.
The relatively simple way of putting rules into a rule based system makes it easy to prototype. With an inference engine, one can start implementing with only the key concepts. The system will be able to run with only a few number of rules, and through simulation and testing the rules may be changed and more rules added in an iterative "learning" process. With an object oriented data model, the rules may also work on symbolic data that are very self-describing and close to the real world.
Customisation very often means parameterisation, but many times specialisation is desired as well. Object orientation makes it possible to specialise data by defining sub-classes and sub-objects. A rule based system also makes it possible to specialise the reasoning by adding custom specific rules. These rules do not affect the existing rules, and the conditions in the customised rules can guarantee that they will only work for a particular user or a particular group of users.
In an intelligent network the service software has to change frequently to fulfill the subscriber requirements, and new service software has to be distributed in the network continuously. The service control systems should therefore have the ability to load new software and unload old software without system stop. Many rule based systems allow new rules and objects to be loaded and unloaded at run-time, and some systems allow existing rules and objects to be modified at run-time as well. It is the modularity of rule based systems that makes this possible. All rules are independent of each other and only connected via a common data model.
The prototyped system has a very flexible inference engine where adding, deleting and modification of all system parts is possible at run-time. This may be done by external routines or by loading new software from the databases.
Software maintenance is very dependent of the ease of understanding the code and the possibility to make changes without unpredictable side effects. Rules are easier to maintain than traditional code. Not only because of the syntax, but also because a rule based system is able to explain its own reasoning process. It is very helpful to understand how the system is reasoning, what conditions are satisfied and how conclusions are reached to maintain the software.
The prototype is offering a graphical representation of the network situation, so that the service designer can see the effect of the service logic on the switching system. Figure 5 shows a typical screen image during a service simulation. The largest rectangle is a display of the switching situation. It shows a connection point connecting two legs (between access point 2 and 10). In addition there is a leg not connected yet (from access point 16).
The three small displays show the status at the three access points. They also give the user the ability to send and receive messages to and from the network. Several calls can be handled simultaneously, and more access point displays may be opened if necessary.
It is possible to look at the network model at any time during a service simulation. Figure 6 shows some of the objects created during the simulation example shown in Figure 5. The first object is the provide instruction request, then follow the socket, connection point and the three legs. The (+) in front of the object names means that they are dynamic objects that will be deleted when the call is finished.
A number of telecommunication services have been developed for the rule based service control system. Examples of services that are running on the system today are:
Common service rules are stored in the rule bases, one for each service. Subscriber specific information is stored in the subscriber databases.