WO2001076267A1

WO2001076267A1 - System and method for modelling system interactions

Info

Publication number: WO2001076267A1
Application number: PCT/GB2001/000876
Authority: WO
Inventors: Richard John Mellish Kett; Edmund Andrew Kirkham; Donald Fisk
Original assignee: British Telecommunications Public Limited Company
Priority date: 2000-03-31
Filing date: 2001-03-01
Publication date: 2001-10-11
Also published as: AU2001235816A1

Abstract

A method and apparatus for feature interaction detection is described in detail. It is based on a generic model of transactions between a requester and a provider. The Plain Old Telephone Service (POTS) is modelled as a set of transactions each of which represents a distinct phase in a telephone call. It is then shown how services (or their features) alter the specification of those phases. A number of rules are described that identify feature interaction between two services. This is achieved by examining the effects of the combined changes made to the same POTS phase.

Description

SYSTEM AND METHOD FOR MODELLING SYSTEM INTERACTIONS

The present invention relates to methods and apparatus for modelling the behaviour of technical systems that comprise interactions between a plurality of elements within the system. The invention is particularly but not exclusively applicable to creating models for use in the monitoring, controlling and modification of such systems.

Many technical systems exist such as telecommunications networks, software agent systems or data processing systems in which the behaviour exhibited by the system can be treated as comprising a collection of interactions between entities. For example. In a telecommunications system, the two entities might be a calling party and a called party, a calling party and the network or a called party and the network.

In order to monitor or modify such a system, the system behaviour needs to be understood and recorded so that the interactions can be compared and perhaps re- engineered. Once a model has been created its behaviour can be compared to that of the actual system and problems or differences in behaviour identified. Furthermore, the model can provide sufficient understanding of the system so as to facilitate the addition of functionality to the system. The additional functionality can be engineered firstly as a model and then the model tested before the actual system is created.

Systems exist which allow for models to be created so that the modelled system can be monitored, controlled and re-engineered. However, such systems suffer from a number of drawbacks. If the modelling technique is sufficiently detailed so as to enable all elements for the system behaviour to be recorded then the resulting model tends to be relatively complex. If, the modelling system is simplified then there is an increased chance of interactions that are present in the actual system not being demonstrated by the model.

Further drawbacks arise when attempts are made to reengineer a system using prior art modelling techniques. For example, simpler modelling techniques may not enable enough detail to be sufficiently rigorous in the design of new systems whereas highly complex techniques require great expertise to build accurate new models. Many modelling systems are relatively informal with specifications being made using natural language in a relatively unstructured manner.

According to the present invention there is provided a method of modelling an interaction between two entities in a system, the interaction comprising a plurality of states, each of the states resulting from one or more sub-interactions, the method comprising the steps of: grouping the sub-interactions and associated states for a given interaction into a plurality of phases; associating a relevant group of states and sub-interactions with each phase; and for each phase, determining one or more links with other phases, each link being arranged to indicate states that are common between phases so that phases can be linked together to model a complete interaction.

Embodiments of the invention aim to alleviate the problems associated with the prior art techniques. In particular, the system has a structured framework for the formal description of the behaviour of services that does not significantly compromise expressiveness. Yet the specification system does not overly complicate the modelling and analysis activity.

The generic framework for modelling service behaviour can be applied to any kind of communication services (e.g. a postal service), especially telecommunications services. The framework can, for example, be applied to write specifications of Plain Old Telephone System (POTS), Integrated Services Digital Network (ISDN), mobile and Telecommunications Information Networking Architecture (TINA) services.

Central to the framework is the notion of phase, each of which represents a transaction between the requester's agent and a provider. Each phase matches a template containing 1 2 action paths and 6 path aliases or states. Each action path also matches a template containing test conditions, implementation, location and consequences. The rules that classify feature interactions can be generalised to allow for their application against any set of services. The uniformity enables the service descriptions to be machine readable. An editor can be used to generate machine readable service descriptions from a GUI.

The system enables interactions to be identified with improved precision, using rules that embed more domain knowledge. The knowledge may include details about when and why interactions occur so as to increase the hit-rate and make analysis time more productive. The rule set that generates situations can be extended to add new rules (both generic and service specific rules).

Embodiments of the present invention will now be described with reference to the accompanying drawing in which: figure 1 is a schematic representation of a telecommunications system which includes a network; figures 2 to 5 are diagrams show models of elements of the functionality of the network of figure 1 ; figure 6 is a diagram showing elements similar to those of figures 2 to 5 linked together to model the functionality of a service in the network of figure 1 ; figures 7 to 14 are diagrammatic representations of editor screens and data used to create the models of figures 2 to 6; figure 1 5 is a Venn diagram illustrating areas where problems may occur between services; figures 1 6 to 18 are illustrations of problems occurring between services; and figures 19 and 20 are diagrammatic representations fo the data structures used to represent the models of figures 2 to 6.

Figure 1 is a schematic representation of a telecommunications system 101 which comprises a network 103 connecting a plurality of terminals such as telephones 105 together so as to allow communication between users via the telephones 105. The network 103 is also connected to a network management system 107 which is arranged to provide facilities for the control and monitoring of the network. In the present embodiment the network management system is connected to a monitor 109 for monitoring the performance of the network against a model of the network services stored an a database 1 1 1 .

The network management system is also connected to services editor 1 1 3 which is arranged to enable the creation and modification of network services and associated models. The editor 1 1 5 is also arranged to be able to detect interactions between a newly created elements of network functionality (or services) using a inference engine 1 17 and a set of rules stored in a rule base 1 19. Newly created services are modelled using the editor 1 13 and stored in the model store 121 for access by the inference engine 1 1 7

Service Modelling

Figure 1 is a diagrammatic representation of the generic framework for modelling transactions between two entities or agents. It is particularly applicable to communications services, especially telecommunications services but could be used to model sending a processing of data in software system. The method allows service behaviour to be modelled in a way that does not prescribe a particular call model. Instead, it provides the user with the flexibility to add additional trigger points, conditions and transitions as required. The "diamond" shown in Figure 2 represents a generic transaction or contract between two entities, called a Requester and a Provider. Sometimes the Requester may use an Agent to act on their behalf. The diamond may constitute a single phase of a service which may have one or more identifiable phases and this arrangement will be described in further detail below.

The Transaction Model

In figure 2, the six states represented by nodes A, B, C, D, E, F which exist after particular actions between the requestor and the provider. The actions that the requestor and the provider can make are represented by the arrows 1 to 1 2. The six requester actions are: request - path 1 ; cancel - path 4; restart - path 1 1 ; withdraw after accept - 10; withdraw after decline - path 6; and withdraw after suspend - path 9.

The six the provider actions are: accept - path 2; decline - path 3; accept after decline - path 5; suspend - path 7; resume - path 8; and exit - path 12.

The nodes represent the state of the system after one or more of the above actions: A - after request B - after accept C - after decline D - after suspend E - after cancel F - after exit

After a request 1 is made, there are three things that can happen. The request is accepted 2, the request is declined 3 or the requester can cancel the request 4 before the provider has had a chance to accept.

After the decline C, two things can happen the provider can withdraw the request 6 or the requester can change the decline to an acceptance 5, before the provider has had a chance to withdraw. If this occurs, it is as if the request 1 was originally accepted 2 and no decline 3 was made. After withdrawal 6, the parties are back in the state they were in before the request was made i.e. after exit F.

After acceptance B, where both parties to the transaction are in agreement, two things can occur. Firstly, provider can suspend the acceptance 7, at which point (after suspension D), two things can occur. The suspension 7 can be rescinded 8 by the provider, in which case the state arrived at is after accept B. Alternatively, the requestor can withdraw 9 from the transaction.

Secondly, the requestor can withdraw or cancel 10 after acceptance from which point (after cancel E) the requestor can restart 1 1 and return to node B or the provider can exit 12 after the cancellation by the provider.

A Grammar for Actions

There are four primitive actions, the twelve actions of the provider and the requestor in the above model are contextual variants of these. The primitive actions are:

RX - requester in favour; PS - provider in favour; RX - requester against; and PX - provider against.

φ in the 'rewrite' rules below is null, indicating that the operations on the LHS of the rewrite rule cancel each other out, so that the state before the operations are carried out is returned to. Some examples of how this may operate are as follows:

R-/ RX = > φ ( the requester can withdraw the request before the provider has had a chance to accept); PX PX = > PX (the provider can change the refusal to an acceptance, before the requester has had a chance to withdraw);

PX PX = > PX (the transaction can be resumed by the provider after they suspend it);

RX RX = > φ (the cancellation can be rescinded, in which case the state arrived at is after-accept);

RX PX RX = > φ (the requester can withdraw the request);

RX PX PX RX = > φ (the requester can withdraw from the transaction); and

RX PX RX PX = > φ (the provider can exit the transaction). The background mathematical analysis of diamond structure is summarised by the following tables. Table 1 shows each individual path in terms of the primitive action that it represents. Table two demonstrates how routes to a destination node that are represented by more than one primitive can be shown to be equivalent to other routes in terms of primitives.

Table 1

Table 2

As noted above, the modelling system can be applied to and transaction between two parties and one such case is between the user of a telecommunications system and the provider of that system. The process of making a telephone call using Plain Old Telephone System (POTS) can be divided into a number of process phases. Each distinct phase involves interaction between two parties - a user (requester) and the network (provider). Figure 3 shows a model of the access phase of the process which covers the user picking up a telephone handset (going "off-hook") and the subsequent interaction with the network with the initial goal of obtaining a dialling tone.

With reference to figure 3, the user at some location initiates a request for access directly to the network by going off-hook, represented by path 1 leading to state A. There are now three possible continuations, paths 2, 3 or 4. If the user does not withdraw the request immediately (path 4 to state F), access may or may not be provided by the network. If the request is accepted by the network, it is indicated by issuing a dial tone at path 2 to state B. If the request is declined (for example the network is providing access to a maximum number of users) it is indicated by issuing unobtainable tone at path 3 to state C. If the request is declined the user must withdraw their request by going on-hook (putting down the telephone handset) at path 6 to state F.

At state B the user is receiving a dial tone and so can dial the destination number for a call (the number entering procedure is actually another phase. The way in which the other phase is connected to access phase will be explained further below). If the user fails to enter a number before a timer expires, the network suspends access and issues a constant tone at path 7 to state D. The user must then withdraw by going on-hook, path 9 to state F.

At state B the user may also decided to cancel their access to the service by going on-hook at path 10 to state E. If this happens the network will free any resource allocated to the user at path 1 2 to state F. Note that in this example paths 5, 8 and 1 1 shown in figure 1 are not used and so omitted from the model.

Figure 4 shows the communication phase of a POTS telephone call which is the phase which the recipients telephone will ring and if answered will result in the calling party and the called party being connect. In this phase the requester is still the same user as before, but now the network is acting as their agent, and the provider is the intended recipient of the call.

The network requests a communication by sending an alert signal, path 1 to state A, as shown in figure 4. Again there are three possible continuations, paths 2, 3 and 4. If the request is not withdrawn immediately (path 4 to state F), a communication may or may not be reached with the recipient. The recipient can accept the request, by going off-hook at path 2 to state B, or decline to answer the phone at path 3 to state C. If the request is declined the network will, after a time, withdraw their request at path 6 to state F.

At state B, the communication takes place, the recipient can suspend the communication by going on-hook at path 7 to state D. While at state D, the recipient can (assuming the network provides the facility) resume the communication by going off-hook again at path 8 to state B. If the recipient takes too long to resume, the network can withdraw at path 9 to state F. At state B the recipient, by going on- hook, can instruct the network to cancel the communication at path 10 to state E. If this happens the recipient will go on-hook, path 1 2 to state F.

In the communication phase shown in figure 3, paths 5 and 1 1 are not used. The absence of path 1 1 reflects that communication ends when the caller goes on hook.

Joining Phases Together to form a Service One diamond such as those shown in figures 2 to 4 by itself may not describe a complete service. The POTS Service for example has 5 identifiable phases - from the initial request for access shown in figure 3 to the final communication shown in figure 4 with three intervening stages. Phases can be joined together using up to 6 extra paths 13 to 18 shown in figure 5. Each branch can be treated as an alias for a path within another phase of the call (in other words the paths 13 to 18 are not additional paths but copies of paths from connected phases).

Figure 6 shows the five phases of a POTS call joined to form threads of behaviour through the execution of the service. This produces a "waterfall" affect, with a path flowing from one diamond into the next. Typically branching from a phase occurs at node B (after acceptance) along path 14 or at node F (after exit) along path 18. Commonly, if the branching is along path 14, this would correspond to path 1 of the phase that was being branched to. However, modifications to the POTS behaviour can introduce new transitions into the basic call behaviour at any of the 6 states in a phase.

The Monitor Tool - Phase Forms Diagrams and Tables The network management system 101 of figure 1 as described above comprises a service monitoring tool 109. The tool 109 is arranged to hold a model of the services provided by the network (such as POTS) which can then be used to compare with the actual implemented service. The comparison enables the network designers and administrators to identify inconsistencies between the model and the actual network which might indicate faults or potential inconsistencies between how a service is designed to work and how it actual works. Furthermore, the system may be arranged to map real network performance data in to the model to provide a real time performance modelling tool.

Figures 7 to 12 provide a complete description of the POTS standard service by way of the information used by the monitor 109. Each figure shows and example of how the data stored by the monitor 109 may be presented to the user in a monitor screen or editor. Figure 7 is diagrammatic representation of the service as a whole by way of five phase diagrams linked together. Figures 8 to 1 2 each describe one of the five separate phases that make up the service. These are Access, Configure, Send, Deliver and Communicate. Where a path is not used for a given instance of a phase in figures 7 to 1 2 these are shown in grey. These five phases can be categorised into three session types in accordance with the Telecommunications Information Network Architecture (TINA) service description. The sessions are the Access, Invitation and Communication sessions. The Access session describes how a user gains access to a service. The Invitation session describes how invitations to join in a communication are handled by the service provider. The Communication session describes how entities establish, suspend, resume and terminate their communication. Each session consists of one or more phases. For example, POTS has one phase in Access (also called Access - figure 8), three in Invitation, (called Configure - figure 9, Send - figurel O and Deliver - figure 1 1 ) and one in Communication, (also called Communication - figure 1 2).

The monitor 109 stores information on each phase within a service in the form of a phase diagrams and a set of tables as shown in figures 8 to1 2. The first table in a set comprises three categories of information for each path in the phase; a test- condition, an implementation record and one or more consequences. Test-conditions specify what pre-requisites exist for the execution of a path. For example, that a user must dial a number within a pre-defined time or that the network will not accept an invalid number. The implementation records indicate how one entity relates each path action. For example, the network accepts an access request with dial tone. The consequences record the result of moving along a path. For example, when a request to connect is made the a timer is set which cuts off the user if there is no answer.

The second table comprises information that defines each phase by a set of attributes, functions and constants. Furthermore, the branches to other phases are defined along with their equivalent definition with respect to the phase being branched to i.e. their alias. The information in this table effectively duplicated that of the phase diagram. Indeed the information is such that the phase diagram need not be stored separately but can instead be derived from the information in the second table

Service Descriptions

Figure 7 includes a list of all the Types, Attributes, Constants and Functions which are used by the phases that are used by POTS. The information is entered in the tables using formal definitions that map on to the implementation language of the service. Explanations of terms used are set out below in tables 3, 4 and 5.

Types A type is a group or classifications of a collection of things. The following types have been defined.

Table 3

Constants

Certain activities are given time limits, these limits are defined by local constants in the model.

Table 4

Functions

Table 5

Network Services

Telecommunications systems are know to provide other services in addition to those of POTS which are commonly called network services. One example of such a service is called "Call Waiting" (CW) which provides a user with and indication during a telephone call that another party in trying to call them. Another example is called "Call Divert on Busy" (CDB) which causes the network to divert a call to an alternative location when the destination line is busy (this service is normally set up by the called party)

In the network management system 101 these services are modelled by modifying a service that already exists in the POTS or base line service (BLS). New phases can be added to the BLS, while existing phases can be edited to add, modify or delete paths. This can be carried out by the user editing the tables shown in figures 7 to 12. A complete description of a new service consists of three parts; the unaltered part, the modified parts (including deletions) and any new phases. To make clear where changes to the BLS had been made, a colour code systems is used in the editor 1 13. Green entries indicate something new, red indicates where something removed and blue indicates something that has been modified (such as a change to a constant, function, test-condition, implication or consequence).

Figures 13a and 13b show the data held by the network management system 101 for the Call Divert on Busy service once it has been created by modifying the delivery phase of POTS. Figures 14a, 14b and 14c show the data held by the network management system for the Call Waiting service once it has been created by modifying the delivery and communication phases of POTS. From figure14a it can be seen from the box marked "Additional with CDonB" that Call waiting makes use of and additional constant and two additional functions compared to the POTS delivery and communications phases (shown in figures 1 1 and 1 2 respectively). These additional elements are described in more detail below in tables 6 and 7.

Additional Constants

CWNATimeOut An invitation delivered to an end point, with Call Waiting and already engaged in a communication, is only available for a given time. If no response is received in this time, the attempt to deliver halts. This constant represents the time a user has to accept a request to join second communication.

Table 6

Additional Functions

CWBusy(EndPoint) ^■* Boolean Even if an end point has the Call Waiting service there are possible

Table 7

As noted above, in the CDB service, if the called party is busy then the call gets diverted to an alternative number. Creating this service can therefore be done by taking the deliver phase of POTS and modifying it as shown in figure 13b. A branch command has been added at state A (see "Action Paths in other Phases" column) so long as the function "Busy(toLocation)" is true when the call reaches state A. The branch thereby sends the call to another phase for connecting it to the alternative number. As a result of the branch 13, the path 3 which results in a busy tone to the caller is never used and the state C (after decline) is never reached. Following on from this, paths 5 and 6 will never be used. These paths 3, 5 and 6 can therefore be deleted from the deliver phase of the CDB service along with state C. In figures 13a and 13b, the deletions are shown struck though while the additions are shown in bold type. Furthermore, the entries which were not even used in the BLS are shown in grey. There are no modifications to the phase of figure 13b but if there were it would shown in italic script. In practice the editor 1 13 uses the colour scheme noted above i.e. green for new entries, red for removed entries and blue for modified entries.

As noted above, when the call waiting service is operational a called party who is already engaged will receive a warning tone while the calling party receives a wait message. The called part then has the option of swapping between the two calling parties. As shown in figure 14a this service is created by modifying the deliver and communication phases of POTS. Furthermore, an additional constant "CWNATimeOut" and two additional functions "CWBusy" and "CWService" are used.

With reference to figure 14b, in the deliver phase, path 2 (accept) has been modified so that if the called party is busy and CWB is not already in operation (see test condition) then the called party is given the hold message and CWB is noted as being in operation (see consequences). Also, path 3 (decline) has been modified so that if a third caller tries to connect to the called party, the normal busy tone is issued (see test condition). This modification ensures that only three parties can be involved in a CWB service (i.e. the two parties connected and the interrupting party). The function "CWService" has been added to the state table in figure 14b and is therefore used at each active state to check that the CWB feature remains activated during the phase.

With reference to figure 14c, in the communication phase, path 1 has been modified from the POTS communication phase so that if at state A the location being called is busy (see function added to state table in figure 14c), the called part receives and a beep interrupting their call in progress to indicate that another call is waiting. Paths 2 and 3 are modified so that the called party can either switch to the new caller (see implementation entry of path 2) or ignore the new caller who will be given a polite message after a certain time (see the implementation entry for path 3) that their call will not be accepted. Paths 7 and 8 are modified to allow the called party to toggle between the two callers using a key sequence (see the implementation entries). Path 9 has also been modified to remove the time out feature present in the standard POTS communication phase (see figure 1 2) that cuts off a calling party on hold after a predetermined period.

Situation Generation

When services such as CDNA an CW are introduced, problems can occur when the use or behaviour of one service interferes with that of another service. This problem is referred to as feature interaction. Feature interactions are most likely to occur when the same BLS phase is used in a modified form by two new services. Figure 1 5 demonstrates the area where problems occur in more detail i.e. where a POTS phase is modified or deleted by both services and where new phases are added by both services. Potential feature interactions however can be detected by examining pairs of phase diagrams that have been changed in some way. Diagrams of instances of a phases modified by different services are given in figures 16, 17 and 18.

Figure 16 - Call Waiting (CW) and Call Divert on Busy (CDB)

Both the CDB service and the CW service use a version of the deliver phase. When the destination terminal has the CDB service and is busy, i.e. the invitation cannot be delivered, the CDB service makes a new request to the network to connect to the diversion number.

However, when the destination line has the CW service and is not Call Waiting busy (i.e. not under the control of Call Waiting) an invitation can be delivered. Therefore the CW service accepts the request from the network by issuing the CW message to the calling party with the result that the destination line is Call Waiting busy i.e. under the control of CW and an invitation cannot be received. As a result, there may be non-determinism following a request from the network in the delivery phase.

Figure 17 - Call Waiting (CW) and Call Divert on No Answer (CDNA) When the destination line has the CW service, the service sends a request to the user at the terminating line by playing intermittent beeps at the destination line for a predetermined time (i.e. under the control of a timer). When the line is using the CDNA service then a POTS request results in a timer being set and when it expires a new request is made to the network to connect to the divert line. Therefore, while CDNA will divert a first call it may not act consistently to divert a second call which is delivered by the issuing of beeps in a non-POTS fashion.

Figure 18 - Call Divert on Busy (CDB) and Ring Back (RB)

When an invitation reaches a busy line which has CDB set to divert the call the invitation cannot be delivered but instead a new request is made to the network to divert the call. As a result, the POTS decline path is not executed. The RB service depends on the POTS decline path being executed so as to be able to dial 5 to invoke the RB service. Since the decline path is never reached when the CDB service is active, the user in unable to invoke the RB servcie.

From the above examples, three rules can be derived to identify these and similar situations. The rules concentrate on the area where services have modified POTS phases or have created new instances of phases, (as shown in figure15). The rules are as follows:

Rule 1

Two services S1 and S2 share the same BLS. At some point in their execution both services enter a state in any class of phase by an identical action path but leave the state along different paths. If neither of the paths by which S1 and S2 leave are described exactly by the BLS, then there will be non-deterministic behaviour (an interaction) between S1 and S2.

Rule 2

Two services S1 and S2 enter a state in any class of phase by action paths which are not identical. The action path of S1 is however identical to the corresponding path in the BLS. If S2 exits by an action path that is not described exactly by the description of the BLS, then S2 may act in an inconsistent manner with respect to the previous action path of S1 .

Rule 3 Two services S1 and S2 share the same BLS. At some phase in their execution both services leave along different branches, such that the execution of the branch in S2 is prevented by the execution of the branch in S1 , because they are linked by a nonexecutable path.

Extending the Rule Base

The three rules described are all stored in the rule base 1 19 and can be extended to provide a larger rule base by: 1 ) editing existing rules to pattern match on different paths and branches of a phase .e.g. on the suspend path rather than the request^*path;

2) formulating new generic rules based on specific feature interactions;

3) writing rules that name one service (or service type) and look for conflicts of a particular nature (e.g. a rule could check divert services against any other service which is triggered at the Deliver Phase of an Invitation Session, The change in the definition of destination line could then be considered); and

4) writing rules that pattern match modifications to different phase types (temporal rules).

The implementation of the above rules embeds the domain knowledge in a form useable by the inference engine 1 17. The rules have two main parts, a left and a right hand side. The LHS of a rule contains pattern matching elements. The rules take the following general form: (defrule rule-name

;; Collect objects used in rule. ?var1 <- (object

{slot-name- 1a slot-value- 1a) (s/ot-name- 1b slot-value- 1b)

.... ?var2 <- (object

(s/ot-name-2a slot-value-2a) (slot-name-2b s/ot-vafue-2b)

...)

;; Carry out tests (test test 7) (test test2)

= >

;; Execute actions. action 1 action2

The meaning of the rule can be paraphrased as: "whenever there are (in memory) one or more objects such that one object's attribute does/does not equal another object's attribute or a constant, then do the list actions ". The RHS of a rule contains the code that supports the consequence of the LHS being true. In the RHS one may assert new facts or print information to screen or to a file. If a rule RHS condition matches against two completely generic objects A and B, it can match against the same objects in reversed order. To avoid this duplication it is necessary to record matches and check that the same match (in different order) has not previously occurred. This is achieved by adding an extra condition (not (found r ?b ?a)) in the rule's if-part and (assert (found r ?a ?b)) in the rule's action part.

The inference engine 1 17 executes the LHS of each rule in the rule base in an iterative fashion. It therefore will identify every combination of data elements that satisfy one or more of the rules.

The system is preferably implemented using a forward chaining expert system shell such as CLIPS. CLIPS has an Object Oriented Language called COOL, for representing the objects encountered in service descriptions. In addition, the editor, is implemented so that the user can build up service descriptions through interaction with menus and dialogue boxes. The editor is preferably written in Lisp and automatically outputs service descriptions in COOL.

The CLIPS code defines the object model which is used to define services. The relationships between classes and the class hierarchy are shown diagrammatically in figures 1 9 and 20 respectively. The definitions of the various classes are set out below.

Service The slots contained on services are: type, attributes, functions constants; and phases (which is a multi-valued slot containing objects of class phase).

Phase Phases are the most complex objects represented. The slots contained on phases are:

info, type, attributes, functions, constants.

The type slot contains one of: access, configure, send, deliver, communicate.

service, session, instance.

The service slot contains the service the phase belongs to. The session is one of: access, invitation, communication (invitation contains configure, send and deliver phases - see type slot). Instance is an integer.

requester-class, provider-class.

The requester-class and provider-class slots contain a symbol denoting the type of requester and the type of provider, e.g. it might be caller and network in the case of the POTS-access phase.

- request, cancel, restart, withdraw-after-request, withdraw-after-decline, withdraw-after-suspend,

- accept, decline, accept-after-decline, suspend, resume, exit,

- branch-at-a, branch-at-b, branch-at-c, branch-at-d, branch-at-e.

The above slots contain objects of type action, state-a-info, state-b-info, state-c-info, state-d-info, state-e-info, state-f-info.

Action

The slots contained on actions are: implementation-action, implementation-param, implementation-location, condition, consequence.

There are subclasses of actions, one for each action slot on phase e.g. request, accept, but not the branch-at slots. Each service definition in COOL is contained in a separate file. It can be produced using a normal text editor such as Emacs, or using the service editorl 1 3. The editor 1 13 is specifically designed to facilitate entry of service definitions. The user browses through existing service definitions, which can be loaded from a CLIPS file in COOL format, or builds up new service definitions, through interaction with a menu and dialogue box-based user interface. Each menu displays an object's slots, and enables the value on an existing slot of an object to be selected, or a new one to be defined. If the slot holds an object, that object's menu is shown. If it is a string or symbol, then the string or symbol is displayed or entered using a dialogue box. In the process of doing this, objects are defined which mirror those used by COOL. The results of editing can be saved in a CLIPS file (* .clp).

The editor 1 13 is preferably written in a dialect of Lisp called XLispStat, which is available free and is a subset of Common Lisp with support for statistical analysis (which is not used in the feature interaction detector). Its main difference from Common Lisp is in the code for object orientation, which is somewhat rudimentary when compared with CLOS (though it is still more powerful than what is offered by Java).

As already discussed above, new services (or their features) can alter the specification of POTS phases. Actions in these phases can be:

1 ) identical to POTS actions, in which case they can be represented by the symbol pots; 2) different from POTS actions, in which case their details have to be represented;

3) an action which is present in POTS might be disabled from the non-POTS service (In this case, the non-POTS service overrides the POTS service. For example, in Call Divert on Busy, the POTS decline implemented by busy tone is not executed) and

4) completely new behaviour (new phases, sessions etc.) Threads are constructed by assigning a branch slot the value of an action path object in another phase instance. At present this is done via the editor but by code in a separate file. This file need only be loaded during the Situation Generation and must be loaded after a reset command i.e. when all phase objects are instantiated.

Situation Generation - Detecting Feature Interaction

When a new model or a service is stored in the model store 1 21 , the inference engine is arranged to compare each phase within the new service with the phases of the existing models. As noted above, the inference engine 1 1 7 uses the rules from the rule base 1 1 9 to identify interactions that may occur between two non-POTS services. If a rule is fired then the inference engine is arranged to issue an alert to that effect. Preferably, the alert is on the form of natural language such as that set out below.

The rule has overlaid the first occurrence of the deliver phase in [cdb] with the second occurrence of the deliver phase in [call-waiting]

Description:

In the invitation session, there may be non-determinism, following a request from the network service in the deliver phase.

In Call Divert on Busy, when the destination line or mobile terminal has the Call Divert on Busy Service, and the destination line or mobile terminal is busy i.e. an invitation cannot be delivered, the Call Divert on Busy service makes a new request to the network by entering a Dialled Number with the result that the network creates a new invitation. However, in Call Waiting, when the destination line or mobile terminal has the Call Waiting Service, and the destination line or mobile terminal is not Call Waiting busy i.e. under the control of Call Waiting an invitation can be delivered, the Call Waiting service accepts the request from the network by issuing a message "please hold the line ..." at the originating line or mobile terminal with the result that the destination line or mobile terminal is Call Waiting busy i.e. under the control of Call Waiting an invitation cannot be delivered.

This more readable output is obtained by calling print functions which expand terms (functions, attributes etc. ) used by the phases into more readable strings. For example, the ord function turns the instance number 1 into "first".

Once a user of the system has been alerted, steps can then be taken to modify the or each new service so as to avoid the interaction, to simply document the interaction and accept it as system behaviour or to make the conflicting services exclusive either in whole or in part

As will be understood by those skilled in the art, the monitor 109 and editor 1 13 are separable elements that can be applied alone to a telecommunications system. Furthermore, the monitoring and or the editing/creation functionality disclosed could be applied to interaction between two or more entities of many different types. The entities could be computers setting up communication, mobile terminals, software agents, people, in fact any inter-entity situation.

As will be understood by those skilled in the art, any or all of the software used to implement the invention can be contained on various transmission and/or storage mediums such as a floppy disc, CD-ROM, or magnetic tape so that the program can be loaded onto one or more general purpose computers or could be downloaded over a computer network using a suitable transmission medium.

Unless the context clearly requires otherwise, throughout the description and the claims, the words "comprise", "comprising" and the like are to be construed in an inclusive as opposed to an exclusive or exhaustive sense; that is to say, in the sense of "including, but not limited to".

Claims

1 . A method of modelling an interaction between two entities in a system, the interaction comprising a plurality of states, each of the states resulting from one or more sub-interactions, the method comprising the steps of: grouping the sub-interactions and associated states for a given interaction into a plurality of phases; associating a relevant group of states and sub-interactions with each phase; and for each phase, determining one or more links with other phases, each link being arranged to indicate states that are common between phases so that phases can be linked together to model a complete interaction.

2. A method according to claim 1 in which the states and sub-interactions that comprise each phase are predetermined in accordance with a template for that phase.

3. A method according to claim 2 in which the template for the or each phase is derived from a universal template.

4. A method for testing for conflicts between a plurality of interactions in system comprising the steps of: modelling a plurality of new phases for each interaction in accordance with the method of claim 1 ; accessing a set of predetermined phase models for the system; determining whether or not the new phases are both based on the same predetermined phase model; if, in the determining step, it is determined that each of the new phases are based on the same predetermined phase model, then testing the operation of each new phase for a predetermined set of interaction behaviours.

5. A method according to claim 4 in which said determining step only being arranged for the testing of the new phases if the new phases are each determined to comprise modifications of the same sub-interaction of the predetermined phase model.

6. A method according to claim 4 or 5 in which the predetermined set of interaction behaviour is defined by a set of rules.

7. A method according to claim 6 in which each rule in the set of rules is arranged to identify interaction behaviour when the new phases are each determined in the determining step to comprise modifications of the same sub-interaction of the predetermined phase model.

8. Apparatus for modelling an interaction between two entities in a system, the interaction comprising a plurality of states, each of the states resulting from one or more sub-interactions, the apparatus comprising: means for grouping the sub-interactions and associated states for a given interaction into a plurality of phases; means for associating a relevant group of states and sub-interactions with each phase; and means operable, for each phase, determining one or more links with other phases, each link being arranged to indicate states that are common between phases so that phases can be linked together to model a complete interaction.

9. Apparatus according to claim 8 in which the states and sub-interactions that comprise each phase are predetermined in accordance with a template for that phase.

10. Apparatus according to claim 9 in which the template for the or each phase is derived from a universal template.

1 1 . Apparatus for testing for conflicts between a plurality of interactions in system comprising: means for modelling a plurality of new phases for each interaction in accordance with the apparatus of claim 8; means for accessing a set of predetermined phase models for the system; means for determining whether or not the new phases are both based on the same predetermined phase model; means operable in response to the determination that each of the new phases are based on the same predetermined phase model, to test the operation of each new phase for a predetermined set of interaction behaviours.

1 2. Apparatus according to claim 1 1 in which said determining means is only operable to test the new phases if the new phases are each determined to comprise modifications of the same sub-interaction of the predetermined phase model.

13. Apparatus according to claim 1 1 or 12 in which the predetermined set of interaction behaviour is defined by a set of rules.

14. Apparatus according to claim 13 in which each rule in the set of rules is arranged to identify interaction behaviour when the new phases are each determined to comprise modifications of the same sub-interaction of the predetermined phase model.

1 5. A template for use in the method of claims 1 to 3 or with the apparatus of claims 8 to 10 for representing an interaction between two entities comprising means for representing: a first state resulting from a first sub-interaction; a second, third and fourth sub-interactions resulting respectively in a second third, and fourth state from the first state; a fifth sub-interaction resulting in the second state from the third state; a sixth sub-interaction resulting in the fourth state from the third state; a seventh sub-interaction resulting in a fifth state from the second state; an eighth sub-interaction resulting in the second state from the fifth state; a ninth sub-interaction resulting in the fourth state from the fifth state; a tenth sub-interaction resulting in a sixth state from the second state; an eleventh sub-interaction resulting in the second state from the sixth state; and a twelfth sub-interaction resulting in the fourth state from the sixth state.

1 6. A method of testing for conflicts between a plurality of interactions in a system, each set of interactions being between two or more parties and each set comprising one or more modifications over one or more basic interactions, said method comprising the steps of: accessing one or more models of basic interactions for the system; creating a plurality of new models based on one or more basic models, each for a new interaction; determining whether or not two or more of the new interaction models are based on the same basic interaction model; if, in the determining step, it is determined that each of the new interaction models are based on a common basic interaction model, then testing the operation of each new interaction model for a predetermined set of interaction behaviour.

17. A method according to claim 16 in which each model of each interaction comprises one or more parts, each part representing an element of the interaction and said determining step being arranged to test the new interaction models if the new interaction models are each determined to comprise modifications of the same element of the common basic interaction model.

1 8. A method according to claim 16 or 17 in which the predetermined set of interaction behaviour is defined by a set of rules.

19. A method according to claim 18 in which each rule in the set of rules is arranged to identify interaction behaviour when the new interaction models are each determined in the determining step to comprise modifications of the same element of the common basic interaction model.

20. Apparatus for testing for conflicts between a plurality of interactions in a system, each set of interactions being between two or more parties and each set comprising one or more modifications over one or more basic interactions, said apparatus comprising: means for accessing one or more models of basic interactions for the system; means for creating a plurality of new models based on one or more basic models, each for a new interaction; means for determining whether or not two or more of the new interaction models are based on the same basic interaction model; means responsive to the determination in the determining step that each of the new interaction models are based on a common basic interaction model, to test the operation of each new interaction model for a predetermined set of interaction behaviour.

21 . Apparatus according to claim 20 in which each model of each interaction comprises one or more parts, each part representing an element of the interaction and said testing means being arranged for the testing of the new interaction models if the new interaction models are each determined to comprise modifications of the same element of the common basic interaction model.

22. Apparatus according to claim 20 or 21 in which the predetermined set of interaction behaviour is defined by a set of rules.

23. Apparatus according to claim 22 in which each rule in the set of rules is arranged to identify interaction behaviour when the new interaction models are each determined by the determining means to comprise modifications of the same element of the common basic interaction model.

24. A computer program or suite of computer programs arranged to cause a computer to provide the apparatus according to claim 8 or claim 20 or to perform the method of claim 1 or claim 16.