Detection and Resolution of Interactions between ... - Semantic Scholar

Detection and Resolution of Interactions between Services of Telephone Networks Ahmed Khoumsi June 1996 Abstract

With the rapid increase of services for telecommunications systems, the designers of services have to resolve the feature interaction problem. The latter occurs when several services behave in an incorrect way once they are put together. In this paper, we present a methodology for the detection and resolution of such a problem. A rst interest of our approach is that the study is achieved at the formal speci cation level. Another interest is that both detection and resolution problems are tackled. An originality of the used approach is that the resolution is achieved without changing the services involved in the interaction, by adding controllers which force the services to behave in a desirable way. For that, we have determined sucient conditions on services which make such resolution possible. Several examples illustrate our method.

Key Words: Service, Interaction, Detection, Resolution, Invariant, Controllable and Coobservable Behaviour, Acceptable and Realizable Behaviour, Controller, Synthesis.

1

1 Introduction In the last years, the number of services for telephone networks has become very large. An important problem the designers have to deal with is the feature interaction problem [4]. Such a problem occurs when several services behave in an incorrect way once they are put together. In this case, we say that the services are con icting or that there is an interaction between them. Dierent researchers have studied the problem [1, 5]. Their works can be compared in function of their contributions to the three following points [1, 5] : Avoidance : The aim is to propose approaches for designing services that lead to service implementations that are intrinsically less prone to interactions. Detection : Since all interactions cannot be avoided, the aim is to propose approaches to check for the existence of interactions. The detection may be done o-line, i.e., before the implementation of the services involved in the interaction, or on-line, i.e., while the services are running. Resolution : Once an interaction is detected, one must nd a way to remove the interaction without generating a behaviour which is unacceptable by the user. Similar to detection, resolution can be done either o-line or on-line. In this paper, we propose an original method for the o-line detection and resolution of interactions between services. To simplify the problem, we consider in this paper only interactions involving two services. Therefore, in our case, the aim of the detection is to determine if an interaction exists between two given services S1 and S2. Once an interaction is detected, the aim of the resolution is to remove such interaction. A rst originality, which makes our method more general, is that we have used concepts of controllability [11] and coobservability [9] of the control theory of discrete event systems. Another originality of our method, which is also inspired from the control theory, is that the resolution is achieved by designing one or several modules, called controllers or supervisors, which must be added to the con icting services in order to prevent them from behaving in a problematic way. An advantage of this approach of resolution is that the implementations of the services involved in the interaction need not be replaced. Sucient conditions on services, which make the resolution possible, are given. Both detection and resolution are realized based on the formal speci cations of S1 and S2. An advantage of this approach is that the interaction may be detected and resolved before the implementation. The paper is organized as follows. Section 2 presents informally a few services and the interactions which occur between them. Section 3 introduces the model used to formally specify services. Section 4 details the dierent steps used for detecting an interaction. An example of detection is presented. Section 5 provides the dierent steps used to resolve an interaction which has been detected. Several examples of resolution are presented. In Section 6, we mention certain problems which are avoided by the use of our method of detection and resolution. And nally, we conclude and propose some future works in Section 7.

2

2 Two Informal Examples of Interactions With the rapid creation of services, their number has become large. Some of the best-known services and their interactions are presented in [4]. To make the problem clearer before getting to the heart of the matter, here are two examples of interactions. Each interaction and the two services involved are presented informally by the example of a scenario. 1. The two services involved in this rst interaction are Call Waiting (CW) and Answer Call (AC). Let us consider three users A, B and C of the telephone network, where A is a subscriber of both services CW and AC. Let us suppose that A and B are in a phone conversation. Service CW : If C calls A, the latter is informed by a CW-tone. A may generate a

ash-hook signal to put B on hold and to be connected to C . After that A may switch between B and C by ashing the hook, i.e., with the ash-hook signal. Service AC : If C calls A, the former is directed to an automatic answering service informing him that A is busy. Interaction CW-AC : When C calls A, should A receive a CW-tone or should C be directed to an answering service ? Another way to present the interaction is that, with CW (resp. AC), A can (resp. cannot) receive a call if he is already in a phone conversation. 2. The two services involved in this second interaction are Originating Call Screening (OCS) and Call Forward (CF). Let us consider three users A, B and C of the telephone network, where A and B are subscribers of OCS and AC, respectively.

Service OCS : If A puts a phone number X in a screening list LOCS , then any attempt of A to call X is aborted. Let us assume that A has put C 's number on LOCS .

Service CF : B may program an automatic redirection of his incoming calls towards another number X. Let us assume that B has programed a redirection towards C . Interaction OCS-CF : If A calls B, the former will be connected to C , due to the redirection programed by B. The interaction is due to the fact that A succeeds to call (indirectly) C although the latter is in the screening list LOCS . Let us mention that our method of detection and resolution has been developed after a study of seventeen real services and eighteen interactions occuring between those services. Most of those services and interactions are presented in [4].

3 The Speci cation of Services

3.1 Introduction of the Speci cation Model

We think that the best way to tackle rigorously the problem of interactions is to represent it formally by the use of a model. The latter must be convenient to represent formally services 3

and interactions. The model we have used is based on nite state automata (FSA) which are extended with discrete variables and whose events may be controllable or uncontrollable. Before introducing formally such a model, called extended FSA (EFSA), here are some necessary de nitions. De nition 3.1 (Controllable and uncontrollable event) [8, 6] Let S be a given system which is evolving with the execution of its events. An event  of S is controllable if its occurrence can be prevented once S is in a state where  is allowed by S. To the contrary,  is said uncontrollable if it is impossible to forbid its occurrence once it is allowed by S. Inputs may be considered as uncontrollable events. For instance, if S is the telephone network, input events "hang up", "pick up", "press a key" are uncontrollable. In fact, once the system is in a state where it may accept these inputs, we cannot forbid the user, i.e., the environment, to generate them. An output may be controllable or uncontrollable depending on the implementation. If the environment has a means to indicate to S that it must not generate a given output then the latter is controllable. For instance, let us consider the Call Number Delivery (CND) service which displays the number of the caller while the telephone is ringing. Event disp caller , representing the display of the number of the caller, is controllable if there is a means to forbid it, i.e., if the CND service can be disabled. Otherwise, such event is uncontrollable. This concept of controllability is necessary to avoid the design of unrealizable systems necessitating to forbid uncontrollable events. De nition 3.2 (Variables, Enabling Condition) Let V be a set of discrete variables. An enabling condition, w.r.t. V , is a boolean expression which is formed from : (a) Canonical boolean expressions u  k, where u is the current value of a variable, k is an integer and  is =,  or >. (b) Operators AND (^), OR (_) and NOT (:) on these canonical boolean expressions. The set of enabling conditions, w.r.t. V , is noted EnV . If v is a boolean variable then v = True and v = False are noted v and v, respectively (symbol = means an equality and not an assignment). For instance, we consider the boolean variables freeX , enabledXS and comXY , for X = A; B, and S = CW , where freeX = True means that subscriber X is not on the line, enabledXS = True means that service S is enabled for subscriber X , and comXY = True means that X and Y are in a phone conversation. More generally, comX1 X2


Xk = True means that X1; X2;


; Xk are in a phone conversation. An example of enabling condition is :  = freeA ^ (freeB _ enabledBCW ). Informally,  = True means that A is not on the line and that B is either not on the line or a subscriber of the Call Waiting service which is enabled. De nition 3.3 (Transformation function) Let V be a set of discrete variables. A transformation function, w.r.t. V , is a function whose aim is to change the current values of certain variables of V . The set of transformation functions, w.r.t. V , is noted TrV . If v is a boolean variable then its update to True (resp. False) is noted v (resp. v). The dierent assignments are separated by the symbol &. Let for instance  = freeA&freeB &comAB . The application of  means that freeA; freeB and comAB are set to False; False and True, respectively . 4

An EFSA A is de ned by A = (Q; co; uc ; V; ; q0; v0), where : (a) Q is the set of states and q0 is the initial state; (b) co and uc are the sets of controllable and uncontrollable events, respectively ; (c) V is a set of nV discrete variables, and v0 is an nV -tuple de ning the initial values of all the variables; (d)   Q  (co [ uc )  Q  EV  TV de nes the transitions, where EV and TV are the sets of enabling conditions and transformation functions, w.r.t. V , respectively. The semantics of a transition Tr de ned by Tr = hq; ; r; ;  i is the following. If q is the current state then : (a)  may occur only if  = True; (b) the occurrence of  leads to state r and implies the application of the transformation function  .

3.2 Example

Here is a partial formal speci cation of the Call Waiting (CW) service (Sect. 2). The aim is not to give a complete speci cation of CW, but to give a simple example of a system modeled by an EFSA. We consider three users A, B and C of the telephone network, where A is a subscriber of service CW, and we consider the system at a moment where A and B are in a phone conversation. Let us specify formally the following informal and partial speci cation :  Service CW may be enabled and disabled. When it is enabled then we may have the following scenario.  If C calls A, the latter is informed by a CW-tone.  After that, A may ash the hook to put B on hold and to be connected to C .  Then, A may switch between B and C by ashing the hook.  If C hangs up while he is on hold then A and B are in a normal conversation as they were before the call of C . For the sake of simplicity, and since the aim is not to specify completely CW, we will not represent other possibilities (A or B hangs up, CW is disabled after the call of C : : : ). The variables used are freeA , freeC , comAC , enabledACW (Def. 3.2), waitB and waitC, where waitX means that user X is on hold. The semantics of the used events is :

 enableXS (resp. disableXS ) means : Service S of user X is set in the enabled (resp.    

disabled) state. callXY means : A call of X for Y has reached the component of the network where sercices of Y are implemented. In our example, this implies that service CW of A has detected the call of C . toneXS means : User X receives an S-tone (a CW-tone in our example). flashX means : User X generates a ash-hook signal. hangupX means : User X hangs up. 5

The formal speci cation is represented in Figure 1, where transitions Tri, for i = 1;


; 9 are de ned by their ve parameters as follows : Tri q  r   A A Tr1 1 enableCW 1 enabledCW enabledACW Tr2 1 disableACW 1 enabledACW enabledACW Tr3 1 callCA 2 freeA _ enabledACW freeA&freeC Tr4 2 toneACW 3 enabledACW Tr5 2 flashA 4 enabledACW comAC &waitB A A Tr6 3 flash 4 enabledCW comAC &waitB Tr7 4 flashA 5 enabledACW waitB&waitC Tr8 5 flashA 4 enabledACW waitB&waitC Tr9 5 hangupC 1 enabledACW freeC &comAC &waitC Tr1

Tr2

1 Tr3

Tr9

2 Tr5

5

Tr8 Tr7

Tr6

4

Tr4 3

Figure 1: Partial speci cation of the CW service.

4 Detection of Interactions Our method for detecting and resolving an interaction between a pair of services may be divided into the following steps : Detection : The four following steps are introduced in the present section. 1. Specify the joint behaviour of two services by an EFSA. 2. Transform the EFSA specifying the joint behaviour into an equivalent FSA. 3. De ne the undesirable states and cycles. 4. Detect the undesirable states and cycles. Resolution : The three following steps are introduced in Section 5. 1. Remove the undesirable states and cycles. 2. Compute an acceptable and achievable behaviour. 3. Synthesize controllers which allow to realize the above behaviour. 6

4.1 Step 1 : Computation of the joint behaviour of two services De nition 4.1 (Synchronized product)

Let Ai, for i = 1; 2, be two EFSAs de ned by Ai = (Qi; ico; iuc; V i; i; qi0; vi0), where variables of each V i are local to Ai, i.e., V 1 \ V 2 = . Let i = ico [ iuc, for i = 1; 2, co = 1co [ 2co , uc = 1uc [ 2uc ,  = 1 [ 2 = co [ uc , V = V 1 [ V 2, v0 = hv10; v20i, q0 = hq10; q20i 2 Q, and  1 \ 2. The synchronized product of A1 and A2, w.r.t. , is noted A1  A2 and de ned by : A = (Q; co; uc ; V; ; q0; v0) with : Q  (Q1 [ Q2) and : De nition of  : 8q = hq1; q2i 2 Q, 8r = hr1; r2i 2 Q, 8 2 , 8 2 EnV , 8 2 TrV : 8> If ( 2 ) then P 1 >< If ( 2 (1 ? 2)) then P 2 (Tr = [q; ; r; ;  ] 2 ) , > If ( 2 (2 ? 1)) then P 3 >: If ( 2 ((2 \ 1) ? ) then P 2 _ P 3 8 P 1 : (9[q1; ; r1; 1;  1] 2 1) and (9[q2; ; r2; 2;  2] 2 2) >> < that  = 1 ^ 2 and  =  1& 2 Where > P 2 : (such 9[q1; ; r1; ;  ] 2 1) and r2 = q2 >: P 3 : (9[q2; ; r2; ;  ] 2 2) and r1 = q1 If A1 and A2 specify behaviours of two services, A = A1  A2 models the joint behaviour of the two services running together, with Rendezvous on events of . To explain such Rendezvous, we consider an event  which is interpreted by the two services, i.e.,  2 1 \2 : -  2 means that  must be interpreted by the two services at the same time (simultaneous transitions); -  62 means that  must be interpreted by one service at a time (no coupling). The choice of depends on the behaviour desired by the user. Let us mention that the computation of A1  A2 is straightforward from Def. 4.1.

4.2 Step 2 : Transforming an EFSA into an equivalent FSA

The second step of the detection consists of transforming the EFSA modeling the joint behaviour into an equivalent FSA. This transformation is necessary because the operations of the following steps are straightforward if they are done on an FSA. Let the behaviour of a system be the set of its possible sequences of events. Let A be an EFSA which models a given behaviour, and nV be the number of local variables noted v1; v2;


; vnV . An FSA B is equivalent to the EFSA A if it models the same behaviour as A. Before giving an idea of how B is obtained from A, here are some notations. Notations 4.1 (Operations on k-tuples) Let u = (u1; u2;


; uk ) and v = (v1; v2;


; vk ) be two k-tuples where k is a positive integer. (u > v) , ((ui > vi), for i = 1;


; k) and (u  v) , ((ui  vi), for i = 1;


; k) Let u(i) = (u(i)1;


; u(i)k), for i = 1;


; x, be x k-tuples where x is a positive integer. U = Max(u(1);


; u(x)) is a ktuple de ned by : U = (U1;


; Uk ) such that, for i = 1;


; k, Ui is the biggest value among u(1)i; u(2)i;


; u(x)i. The function which tranforms an EFSA A into an equivalent FSA B is noted F sa, i.e., B = F sa(A). 7

A state of B = F sa(A) is de ned by hq; vi, where q is a state of A and v is an nV tuple de ning current values of variables. In B , an event  leads from state hq; vi to state hr; wi if and only if state r of A is reached from state q of A by a transition Tr = hq; ; r; ;  i such that  = TRUE for the current value v, and w is obtained if we apply  to v. Although variables may have in nite numbers of values, B is nite. In fact, for any enabling condition  there exists an nV tuple m = (m1; m2;


; mnV ), called bound, such that  is constant for all values v1; v2;


; vnV of variables where v = (v1; v2;


; vnV ) > m. Let us therefore consider a given state q of A from which x transitions Tr(i), with enabling conditions (i) and bounds m(i), for i = 1;


; x, are executable. If M = Max(m(1);


; m(x)), then every state hq; vi such that v > M can be represented by a same state. As an example, the EFSA in Fig. 2.a is transformed into the FSA in Fig. 2.b, where one variable v is used, and Tr(1) = h1; ; 1; (v  3); v + +i, Tr(2) = h1; ; 1; (v > 2); v + +i, Tr(3) = h1; ; 2; (v > 2); v + +i (where v ++ means an incrementation of v). In this example, M = 3 and then all states h1; ni, with n > 3, are represented by only one state (h1; 4i in Fig. 2). Tr(1) 1

Tr(3)

2 σ

Tr(2)

µ

ρ

1,0

(a)

σ ρ σ

σ 1,1

1,4

1,3

2,5

µ 2,4

1,2

(b)

Figure 2: Transformation of an EFSA to an equivalent FSA : (a) A; (b) F sa(A).

Remark 4.1 Let us consider an EFSA A such that in a given state each variable has always a given value. In this case, enabling conditions are constant, and the transformation of A to an equivalent FSA simply consists of : (a) Removing transitions whose enabling conditions are equal to FALSE; (b) Removing enabling conditions and transformation functions from transitions whose enabling conditions are equal to TRUE.

4.3 Step 3 : De ning Undesirable states and cycles

Let S1 and S2 be two services modeled by A1 and A2, respectively. Our aim is to represent formally the existence of interactions in this joint behaviour.

De nition 4.2 (Invariant)

Let an EFSA A = (Q; co; uc ; V; ; q0; v0) and its corresponding FSA B = F sa(A). An invariant on A or on B is a condition depending on variables of V which is respected by all reachable states of B . Once B = F sa(A1  A2) computed, we have to choose some invariants on B , in such a way that the non-respect of any of them represents an interaction. This implies that each invariant is associated to a suspected interaction. 8

Since : - Each of the two services behaves correctly when it runs alone; - Variables used in A1 and A2 are local, that is V 1 \ V 2 = ;

- An invariant is used to detect a problem in the joint behaviour; Therefore : Any invariant corresponding to a possible interaction is formally de ned by relations between variables of V 1 and V 2. A simple invariant may be an equality between two variables having the same semantics. Let, for instance, free1A and free2A be two local variables of A1 and A2 respectively, which specify whether the user A is on the line. It is clear that we must have free1A = free2A in any state of B = F sa(A1 A2). Sect. 5.2.3 contains an example of a less simple invariant.

De nition 4.3 (Static property, Undesirable state)

A static property is a state dependent property. In other words, the respect of such a property can be checked in any state of an FSA. An undesirable state is a state where an unacceptable static property is satis ed. After a study of several interactions, we have selected the following undesirable states (but let us mention that other kinds of undesirable states may be added in the future) : Deadlock : No event is possible in this state, i.e., the system does nothing. Absorbing state : Once we are in this state, we cannot leave it even if an event is executed, i.e., the system does not evolve. Nondeterministic state : In this state, a same event may lead to dierent states. Therefore, we cannot know the next state of the system with certitude. Uncontrollable state : A state from which an uncontrollable event is forbidden. This is contradictory to Def. 3.1. Con icting state : A state where an invariant is not respected. Invariants have been introduced to de ne this kind of state.

De nition 4.4 (Cycle, Evolutive property, Undesirable cycle) A sequence of states q1; q2;


; qn is a path if qi+1 may be reached from qi with the occurrence of an event, for i = 1;


; n ? 1. A path q1; q2;


; qn is a cycle if it is closed , i.e. : ((qi = qj ) ^ (i  j )) , ((i = j ) _ ((i = 1) ^ (j = n))) An evolutive property is a cycle dependent property. In other words, the respect of such a property can be checked in any path of an FSA. To each cycle, we may associate a desirable evolutive property (DEP). If the latter is not respected, the cycle is said undesirable . We note that a DEP is de ned w.r.t. a given cycle and has therefore to be checked only in its corresponding cycle. Here are four informal examples of evolutive properties, where P, P1 and P2 are static properties : 1. P is respected in at least one state of the cycle. 9

2. P is respected in all states of the cycle. 3. If P1 is respected in a state of the cycle, then P2 is respected in another state of the cycle. 4. P1 is respected in a state of the cycle if and only if P2 is respected in all states of the cycle. We may have more complex evolutive properties involving more than two static properties.

4.4 Step 4 : Detecting interactions

If B is an FSA modeling the joint behaviour of two given services, the existence of an undesirable state or cycle in B is a formal representation of an interaction between the two services. Detecting interactions consists therefore in going through all states and cycles of B and checking if they are undesirable. The complexity to detect undesirable states is O(npq), where : (a) n is the number of states; (b) p is the number of static properties; (c) q is the maximum length of static properties, i.e., the complexity to check the respect of any static property is O(q). Parameter q depends mainly on the invariants to be checked. The complexity to detect undesirable cycles is O( ), where : (a)  is the number of cycles; (b) is the maximum length of evolutive properties, i.e., the complexity to check the respect of any evolutive property is O( ).

4.5 Example of detection

The two services considered are Call Waiting (CW) and Three Way Calling (3WC). For the sake of simplicity, services are presented in a particular case. Let us consider three users A, B and C of the telephone network, where A is a subscriber of both services CW and 3WC. Let us suppose that A and B are in a phone conversation. Service CW : (Sect. 2 and 3.2) : If C calls A, the latter is informed by a CW-tone. A may generate a ash-hook signal to put B on hold and to be connected to C . A may switch between B and C by ashing the hook, i.e., with the ash-hook signal. Service 3WC : A can ash the hook to put B on hold, and then A can call C . While A and C are in a phone conversation and B is on hold, A can ash the hook a second time to add B in the conversation. After that, if C hangs up or if A ashes the hook, then A and B are in a normal conversation. Interaction CW-3WC : Let us assume that C calls A and then the latter ashes the hook just before being informed by the CW-tone. The ash-hook signal must be interpreted by CW or by 3WC ? In the two cases, B is put on hold. But A is connected to C only in the rst case. To apply the four steps of detection, services must be formally speci ed. For the sake of simplicity, we present only partial speci cations of the two services. Such speci cations are sucient to detect the interaction between CW and 3WC. 10

We consider three users A, B and C of the telephone network, where A is a subscriber of both services CW and 3WC, and we consider the system at a moment where A and B are in a phone conversation. In this case, we use the following variables which are sucient to detect the interaction : freeiB; freeiC ; waitiB; waitiC; comiAB ; comiAC ; comiABC (Sect. 3.1), where i = 1 for CW and i = 2 for 3WC. We also use variables enabledACW and enabledA3WC (Def. 3.2). Variables which dier only by index i have the same semantics, and the invariants used consist of equalities between variables with a same semantics. For instance, free1B = free2B . Partial speci cations of CW and 3WC are represented in Figure 3, where all enabling conditions are equal to TRUE . We note that in the same given state each variable has always a same value (Table 1). We deduce therefore from Remark 4.1 that the transformation of these speci cations to equivalent FSAs simply consists in removing enabling conditions and transformation functions from the transitions. That is why transitions are represented only by their corresponding events whose semantics is given in Sect. 3.2. The four steps of detection are applied as follows : Steps 1 and 2. The FSA modeling the behaviour of CW and 3WC running together is schematized in Figure 4. We consider here the case where the two services are not synchronized on event FlashA, i.e., = . Step 3. Undesirable states have been de ned in Sect. 4.3. For the con icting states, invariants considered consist of equalities between variables with a same semantics. There is no undesirable cycle since no evolutive property is de ned. Step 4. All undesirable states are contained in Part CW&3WC (Fig. 4) and consist of nondeterministic and con icting states. Nondeterministic states are hx; yi, with x = 2; 3; 4; 5 and y = 1; 3; 4, from which event FlashA may lead to dierent states. Con icting states hx; yi in Part CW&3WC (i.e., x; y 6= 0) can be detected from Table 1 and are represented on Table 2. A CW

A 3WC

Disable

0 Enable

Disable

1

A CW

0 Enable

1

A 3WC

CA

Call C

Flash

5 Flash

A

C

2

HangUp

Flash

Flash

2

HangUp

A

Tone

Flash

A CW

A CA

Call

A

4 Flash

A

A

3

4

(a)

Flash

A

3

(b)

Figure 3: Partial speci cations of : (a) CW; (b) 3WC. 11

Variables

States

free1

0

B

free1

C B C

wait1

com1 com1

2

0

wait1

com1

1

AB AC ABC

A enabled CW

0

3 0

4 0

5 0

Variables 0

States

free2

B C

1

1

0

0

0

0

free2

0

0

0

0

1

0

wait2

0

0

1

1

0

1

1

1

1

1

0

1

B C

wait2 com2

AB AC

0

0

0

0

1

0

com2

0

0

0

0

0

0

com2

0

1

1

1

1

1

enabled

ABC A 3WC

0

1

2

3

4

0

0

0

0

0

1

1

1

0

0

0

0

1

1

0

0

0

0

0

0

1

1

0

0

1

0

0

0

1

1

0

0

0

0

1

0

1

1

1

1

(a)

(b)

Table 1: Variables used for : (a) CW; (b) 3WC. Enable

A CW

Enable

1,0

A 3WC

0,0 A Disable CW

CA

0,1 A Disable 3WC

Call

Flash

C

HangUp

Flash Flash

A

Tone

A

5,0 Flash

A 3WC

2,0

4,0 A

Flash

Disable A CW

Enable

A 3WC

(States (x,y) with x and y different from 0

A Disable CW

Enable

A CW

Part CW&3WC : Both services enabled

Flash

A

CA

Call

0,3

Part CW : Only CW enabled

C

HangUp

0,2

3,0

A

A

Flash

A

0,4

Part 3WC : Only 3WC enabled

Figure 4: Joint behaviour of CW and 3WC. Invariant free1 free1

B

= free2 B

No state

C

= free2 C

(x=1 and y=3,4) or (x=2,3,4,5 and y=1,2)

B

B

= wait2

(x=1,2,3,5 and y=2,3) or (x=4 and y=1,4)

C

= wait2C

(x=2,3,5 and y=1,2,3,4)

wait1 wait1 com1 com1 com1

States (x,y) where the invariant is not respected

AB

= com2

AC

= com2 AC

ABC

= com2

AB

ABC

(x=1,2,3,5 and y=2,3) or (x=4 and y=1,4) (x=1,2,3,5 and y=3,4) or (x=4 and y=1,2) (x=1,2,3,4,5 and y=4)

Table 2: Con icting states. We note that the large number of undesirable states informally means that the probability of interaction is not negligible. In the remainder of the paper, we study how detected 12

interactions can be resolved.

5 Resolution of Interactions After the four steps of detection, our method for resolving an interaction between a pair of services may be divided into the three following steps : Step 5 : Remove the undesirable states and cycles. Step 6 : Compute an acceptable and achievable behaviour. Such behaviour is called reasonable. Step 7 : Synthesize controllers which allow to realize the reasonable behaviour.

5.1 Step 5 : Remove undesirable cycles and states

Undesirable cycles are removed before undesirable states. Removing an undesirable cycle consists in "cutting" one of the transitions in the cycle. The transition to be removed must be preferably controllable. Removing undesirable states may be done by an iterative xed point method similar to those presented in [11, 6]. Each iteration consists of going through all states and removing those which are undesirable. Since the removal of a state may generate new undesirable states, the process must be iterated till there is no undesirable state. The method converges because the number of states is nite and decreases after each iteration. The example of Section 4.5 contains undesirable states. By applying the xed point method, the whole Part CW&3WC (Fig. 4) is removed. The obtained behaviour corresponds to a mutual exclusion between the two services CW and 3WC. This result is interesting in the sense that, although a mutual exclusion seems to be a too restrictive solution, our method shows that it is the unique solution to resolve this interaction.

5.2 Steps 6 and 7 : Compute and realize a reasonable behaviour

If the behaviour B obtained after removing undesirable states and cycles is not acceptable or realizable, the aim in Step 6 is to transform it in such a manner that it becomes both acceptable and realizable . A behaviour is unacceptable if it is contradictory with user requirements. This is the case if the user requires a minimal behaviour which is not provided by B , or if B provides more than the maximal behaviour tolerated by the user. In Step 7, the aim is to synthesize controllers to be added to the con icting services in order to realize the behaviour obtained in Step 6. Here are some de nitions which are necessary for our study.

De nition 5.1 (Projection : Informal de nition)

Let A be a formal speci cation of a given behaviour with alphabet , and be a subset of . The projection of A into , noted P (A), models the same behaviour when only events of are observable. 13

De nition 5.2 (Controllable behaviour) [11, 6]

A desired behaviour is controllable if it does not necessitate to forbid occurrences of uncontrollable events. Otherwise, it is said uncontrollable . A formal de nition of controllability is given in [11]. De nition 5.3 (Coobservable behaviour) [9] A desired behaviour of a distributed system is coobservable if decisions which have to be made by each site depend only on what the latter observes. In other words, a behaviour is uncoobservable if a site S has to make decisions which depend on events the occurrences of which are not observable by S . In our study, we assume that every site observes all and only its local events. This implies that every site does not observe events occuring in other sites. A formal de nition of coobservability is given in [9]. In [9], it is proven that a behaviour is realizable if and only it is controllable and coobservable. Behaviour B (obtained at Step 5) is controllable since uncontrollable states (Sect. 4.3) are removed during its computation (Sect. 5.1). Since B is controllable, we deduce that it is realizable if and only if it is coobservable. De nition 5.4 (Reasonable behaviour) A desired behaviour is reasonable if it is acceptable and realizable. De nition 5.5 (Filterability) A data D is lterable by a service S if : (a) D is both an input and an output of S; (b) The output is generated by S, only under certain conditions, after the reception of the input. De nition 5.6 (Priority, and prioritized product : informal de nition) We consider two services S1 and S2 where S1 is given more priority than S2. Informally, this means that the system (made up of the two services) is designed in such a manner that : (a) S1 is always running; (b) The system behaves during certain periods as if only S1 were implemented. Such periods are called priority periods . Priority periods may be arbitrarily chosed by the designer, or they may be chosed automatically in such a manner that there are no con icts between S1 and S2. In an extreme case, the system always behaves as if S2 is not implemented. In our study, the priority of S1 can be realized as follows, if inputs and outputs of services can be redirected (Fig. 5) :  An input of S2 coming originally from a system K (user, network : : : ), is ltered by S1 (if such input is lterable by S1, Fig. 5.a).  An output of S2 sent originally to a system K (user or network : : : ), is ltered by S1 (if such output is lterable by S1, Fig. 5.b).  The ltering by S2 of an output of S1 is removed (Fig. 5.c). If S1 and S2 are modeled by the EFSAs A1 and A2, respectively, the prioritized product , noted A1 A2, is an EFSA which models S1 and S2 working together such that S1 has more priority than S2. Such behaviour is called prioritized joint behaviour. In a further study, we will give more formal and accurate de nitions of priority and the prioritized product A1 A2, as a function of priority periods. 14

K K

S2

S2 S1

(a) S2 S2

K S1

(b) S1

K

S2

K

S1

S2

K

(c)

Figure 5: Priority : S1 has more priority than S2. The approach we use to obtain a reasonable behaviour depends on :  The number of components where the services involved in the interaction are implemented. Since we consider here only the case of interactions involving two services, the number of components may be one or two.  The acceptability and realizability of B (obtained at the fth step). We have therefore adopted the following decomposition to achieve Step 6 : Case 1 : One component involved : Since the two services are in the same site, behaviour B is coobservable and then realizable. We have therefore the two following subcases : Case 1.a. B is acceptable; Case 1.b. B is unacceptable. Case 2 : Two components involved : The four following cases are possible : Case 2.a. B unrealizable and unacceptable; Case 2.b. B unrealizable and acceptable; Case 2.c. B realizable and acceptable; Case 2.d. B realizable and unacceptable. The basic principle of our approach (in Step 6) consists of : (a) De ning a priority between services to resolve the unacceptability of B ; (b) Using a transfer of information between services to resolve the unrealizability of B . We deduce that the most interesting cases to study are cases 1.b and 2.a. In fact, in Case 1.b we have to resolve the unacceptability of B when services are in a same component. And in Case 2.a, we have to resolve both unrealizability and unacceptability of B when services are in dierent components. In the remaining part of Section 5, after a succinct presentation of Case 1.a, we will therefore study in detail cases 1.b and 2.a. Each of these three cases is illustrated with a concrete example. Besides, we will mention sets of concrete interactions, corresponding to cases 1.a, 1.b, 2.a and 2.b, respectively, which have been detected and resolved with our method. Before presenting in detail how Step 6 is achieved for the dierent subcases above, let us introduce Step 7 which does not depend on the above decomposition. 15

Once the reasonable behaviour RB obtained (at the sixth step), the seventh step consists of synthesizing a module, called controller, for each component involved in the interaction. The tasks of a controller are [7] : (a) To track the evolution of services implemented in the component, by observing occurrence of their events; (b) To disable some of those events when desired; (c) To communicate possibly with other controllers. For each component Ci involved in an interaction, the controller Ctrli to be added is modeled by Pi (RB ), where i is the set of events occuring in component Ci. In other words, the speci cation of a controller Ctrli is obtained from the speci cation of RB by making observable only events occuring in component Ci [7]. In particular, if only one component is involved in an interaction, then the speci cation of the controller is equal to the speci cation of RB . We note that the interaction is resolved by adding controller(s) to the con icting services instead of replacing or modifying them. Let us now study Step 6.

5.2.1 Case 1.a : One component and acceptable and realizable behaviour

Since B is reasonable, i.e., acceptable and realizable, nothing is done is Step 6. Since only one component is involved, nothing is done is Step 7. The controller to be added to resolve the interaction is therefore modeled by the speci cation obtained at the fth step.

Example 5.1 (Interaction CW-3WC)

Let us consider interaction CW-3WC (Sect. 4.5). The solution obtained at the fth step (Sect. 5.1) consists of a mutual exclusion between the two services. Intuitively, this solution is realizable because the two services can be disabled and enabled. Such a solution is therefore reasonable (Def. 5.4) if we assume that the user accepts the mutual exclusion. While A and B are communicating, the task of the controller consists of : (a) Enabling periodically the two services while none of them has been engaged, in such a manner that they are never enabled at the same time. Formally, while events CallCA or FlashA do not occur, states h1; 0i and h0; 1i are reached periodically. (b) Keeping 3WC disabled as soon as CW is engaged, when C calls A. Formally, 3WC is kept disabled while CW is in one of the states 2, 3, 4 or 5. (c) Keeping CW disabled as soon as 3WC is engaged, when A ashes the hook. Formally, CW is kept disabled while 3WC is in one of the states 2, 3 or 4.

5.2.2 Case 1.b : One component and unacceptable and realizable behaviour

If behaviour B (obtained at the fth step) is realizable but not acceptable by the user, Step 6 is realized as follows. The joint behaviour of S1 and S2, obtained in the rst step, is modi ed by assigning dierent priorities to services involved in the interaction. Formally, A1  A2 is replaced by A1 A2, if S1 is given the highest priority. Afterwards, Steps 2 to 5 are applied to the new joint behaviour. We assume that, for at least one of the two possibilities (S1 with a higher or a lower priority), the obtained behaviour is acceptable (and realizable). We note that the above solution is possible if and only inputs and outputs of the services S1 and S2 are redirectable. In other words, S1 and S2 have been designed in such a manner that the origin of each input and the destination of each output are programmable, i.e., can be changed at any moment. We also note that, in the present study, the priority periods are not selected automatically. 16

5.2.3 Example for Case 1.b : Interaction OCS-CF

The two services considered are Originating Call Screening (OCS) and Call Forward (CF). For the sake of simplicity, services are presented in a particular case. Let us consider two users A1 and A2 of a same line which are subscribers to OCS and CF, and a third user B. Service OCS : Let us assume that A1 has put number of B on a list LOCS . In this case, every call of A1 (or A2) for B is aborted. Service CF : Let us assume that A2 has programed a redirection to B. In this case, every incoming call for A1 (or A2) is automatically redirected to B. Interaction OCS-CF : If A2 calls his own number, then the call is redirected to B. Therefore, A2 succeeds to call (indirectly) B although number of B is in list LOCS . In the same manner as with interaction CW-3WC (Sect. 4.5), we present only partial speci cations of OCS and CF. These speci cations are constructed in such a manner that it is possible to answer the following question : Is it possible for A1 (or A2) to call (directly or indirectly) B ? If the answer is yes, then an interaction exists. Two variables are used : (a) ocsB which indicates whether the number of B is in the list LOCS ; (b) linkAB which indicates whether A1 (or A2) has initiated a communiation with B. Figure 6 shows partial speci cations of OCS and CF. Transitions are represented only by their corresponding events, where ocsX (Y ) means "User X has put number of Y in the screening list", and cf X (Y ) means "User X has programed a redirection of his incoming calls towards Y". The semantics of other events is given in Sect.3.2. As for variables, their values in the dierent states are represented in Table 3. A OCS

Disable

A CF

Disable

1

0 Enable

0 Enable

A OCS

1

A CF

A

A

Ocs (B )

Cf (B ) AA

AB

2

Call

Call

3

(a)

2

(b)

Figure 6: Partial speci cations of : (a) OCS; (b) CF. States Variables ocs

B

0 0

1

States Variables

2 0

1

link

(a)

AB

0 0

1

2 0

3 0

1

(b)

Table 3: Variables used for : (a) OCS; (b) CF. The invariant to be checked is : (linkAB) ^ (ocsB ) = False. The nonrespect of this invariant means that it is possible for A1 (or A2) to call (directly or indirectly) B, and then that the suspected interaction exists. 17

If we apply the four steps of detection, the above invariant is not respected in state h2; 3i of the joint behaviour. In fact, in this state linkAB = 1 and ocsB = 1. If we apply the xed point method ( fth step), the obtained behaviour corresponds to a mutual exclusion between the two services. Let us assume that such solution is unacceptable, i.e., the user would like to use OCS and CF at the same time. Step 6 consists of assigning dierent priorities to OCS and CF, before computing their joint behaviour and removing undesirable states. If OCS is given the highest priority, the obtained solution is informally as follows (Fig. 7). Incoming calls, which were originally redirected by CF to another user via the network, will be sent to OCS which processes them before possibly allowing their redirection to the other user. OCS allows a redirection to a user only if the latter is not on the screening list LOCS . In this example, priority periods (when CF must not work) are periods when the destination of redirection is in the screening list. The redirection is achieved by using a controller which interacts with the two services. User

Controller

CF Redirected call is filtered by OCS

OCS

Call redirected by CF

Incoming call

Medium

Figure 7: Resolution of interaction between OCS and CF. Informally, such a controller : (a) "forces" CF to redirect its incoming calls to OCS instead of redirecting them to the network; (b) "allows" OCS to receive calls from CF.

5.2.4 Case 2.a : Two components and unacceptable and unrealizable behaviour

If behaviour B (obtained at the fth step) is neither realizable nor acceptable, the aim of Step 6 is to : 1. De ne a priority between services before computing their joint prioritized behaviour. 2. Apply Steps 2 to 5 to the joint prioritized behaviour in order to obtain a controllable behaviour. 3. Obtain a coobservable (and then realizable) behaviour, by adding an exchange of information between the two components. This is achieved by using a method presented in [7]. We note that the aim of points 1 and 2, which have also been used in Sect. 5.2.2, is to resolve the unacceptability of B . We assume therefore that priority periods (Def. 5.6) have been 18

chosen such that the behaviour obtained after Point 2 is acceptable. The new Point 3 is used to resolve the unrealizability of B .

5.2.5 Example for Case 2.a : Interaction ACB-ARC

The two services considered are Automatic Call Back (ACB) and Automatic ReCall (ARC). For the sake of simplicity, services are presented in a particular case. Let us consider two users A and B who are subscribers to ARC and ACB, respectively, and a third user C . We assume that, while B and C are in a phone conversation, A tries to call B (who is on the line). Service ACB : Number of A is recorded by service ACB of B. As soon as B becomes free, he receives an ACB tone. If he picks up, then A is automatically called. Service ARC : Number of B is recorded by service ARC of A. As soon as B becomes free, A receives an ARC tone. If he picks up, then B is automatically called. Interaction ARC-ACB : When B becomes free, both ACB tone and ARC tone are generated. If A and B pick up at the same time, then A nds that B is on the line and the two services will be reactivated. When A and B hang up, both ACB tone and ARC tone are generated : : : An in nite loop is therefore possible. The following variables are used to detect the above interaction from a formal speci cation : AB and N AB are the number of calls of A for B which are recorded by services ARC and NARC ACB ACB, respectively. In other words, each time an ARC tone (resp. ABC tone) is generated AB (resp. N AB ) is incremented. If after an ARC tone (resp. ACB tone), A (resp. then NARC ACB AB and N AB are B) picks up and succeeds to communicate with B (resp. A), then both NARC ACB set to zero. When the two services are used conjointly, there is an in nite loop where A and B do not succeed to communicate with each other. This is formally represented by the existence of an undesirable cycle, in the model of the joint behaviour, where the following evolutive property P (Def. 4.4) is not respected. AB and N AB are equal to zero. P : The cycle contains at least one state where NARC ACB After the detection of the interaction, Step 5 is rstly used to remove the undesirable cycle. Since this removal generates undesirable states, Step 5 is also used to remove undesirable states in an iterative way. The obtained behaviour is empty, i.e., corresponds to doing nothing, and is therefore unacceptable. To resolve this interaction, let us give a higher priority to service ARC. We use the extreme case (Def. 5.6) of priority, i.e., the system behaves as if B is not subscriber to ACB when he is called by a subscriber to ARC, like A for instance. By applying Steps 6 and 7, we obtain the behaviour informally speci ed as follows, which is realized by adding two controllers CtrlARC and CtrlACB implemented with services ARC and ACB, respectively :

CtrlARC intercepts outgoing calls and adds in them information "Caller is subscriber to ARC".

19

CtrlACB intercepts any incoming call and check if it contains information "Caller is subscriber to ARC". If yes, CtrlACB does not send the call to ACB. In this case, the incoming call is not detected by ACB which is therefore not activated. If no, CtrlACB sends the call to ACB which is therefore activated.

5.3 Overview of Interactions Detected and Resolved

Our method have been used for the detection and resolution of several interactions which are informally introduced in [4] except for the TCS-CF interaction which is presented in [10]. Let us mention these interactions according to the decomposition we have adopted.

Case 1.a : CW-3WC (Sect. 5.2.1, Exp. 5.1), Example 2 in [4].

CCC-VM (Credit Card Calling-Voice Mail), Example 7 in [4]. 911-3WC (Emergency-Three Way Calling), Example 3 in [4]. Case 1.b : CF-OCS (Sect. 5.2.3), Example 9 in [4]. CW-AC (Call Waiting-Answer Call), Example 1 in [4]. TCS-ACB (Terminating Call Screening-Automatic Call Back), Example 4 in [4]. TCS-CF (Terminating Call Screening-Call Forward), Example in [10]. Case 2.a : ACB-ARC (Sect. 5.2.5), Example 18 in [4]. CW-CW (Call Waiting-Call Waiting), Example 14 in [4]. Case 2.b : OCS-OS (Originating Call Screening-Operator Service), Example 6 in [4]. OCS-LCR (Originating Call Screening-Line Customized Ringing), Example 11 in [4]. OCS-CF (Originating Call Screening-Call Forward), Example 12 in [4]. CND-UN (Call Number Delivery-Undelivered Number), Example 16 in [4]. CF-CF (Call Forward-Call Forward), Example 17 in [4].

5.4 Conditions for the possibility of resolution

Based on our method, we have found the following two conditions which make the resolution of service interactions possible. Condition 1 : It must be possible to enable and disable every service. Condition 2 : It must be possible to redirect the inputs and outputs of each service. In other words, for each service, the origin of every input and the destination of every ouptput can be changed If those two conditions are respected, the resolution is possible by the use of controllers, without changing the services involved. 20

6 Problematic Solutions and False Interactions In this section, we present two problems which may be encountered in the study of feature interactions. We note that these two problems are avoided by the use of our method for detection and resolution.

6.1 Interactions Due to Problematic Solutions

A solution which resolves an interaction, but at the same time is the cause of another interaction is called problematic. Here is an example. In order to avoid in nite loops (i.e., cycles), the authors of [2, 3] propose to restrict the number of requests to services in a given call. They use their approach to resolve for instance the CF-CF interaction (example 17 in [4]). The in nite loop due to this interaction is stopped when the tolerated (maximum) number of requests is reached. This approach is problematic since it may generate new interactions. This happens when two services can work together in a correct way but need to generate a nite number of requests which is greater than the maximum tolerated. This is the case for the OCS-ANC interaction (Example 5 in [4]) which does not exist with our method of resolution. In fact, our proposed solution to resolve the CF-CF interaction (Case 2.b) is to use transfer of information. In other words, every component receives in an incoming call the list of other components already involved in the call. If the given component is already in the list, then a cycle has occurred and the call is blocked. Our method has therefore two advantages : - We do not need to do more than one cycle to detect the interaction, - We do not generate new interactions.

6.2 False Interactions

An interaction may be apparent only and is therefore called False Interaction. In fact, in certain cases and after a super cial study, two services seem to be con icting although they can work together in a correct way. This is for instance the case the CW-ARC and CW-3WC interactions (Examples 13 and 15 in [4]). Let us consider the CW-ARC interaction. A user A subscribed to CW can receive calls even if he is in communication. In other words, the aim of A is to be detected by other users as being always free. The interaction presented in [4] can occur only if A is detected by a subscriber of ARC as being on the line. For this reason, this suspected interaction never occurs. An advantage of our method is that it does not detect false interactions.

7 Conclusion and Future Works In this paper, we present a method for the detection and resolution of con icts which may occur between services of the telephone network. These con icts are called feature interactions. Concepts such as controllability and coobservability, which have been integrated in our study, contribute to the originality of the method. We note that our method of detection 21

can be conveniently extended, just by de ning new kinds of undesirable states and cycles. As for the method of resolution, it allows to keep the con icting services. Instead of replacing those services, controllers force them to behave in an acceptable way. We have found conditions which make the resolution possible. With our method, several false interactions have been invalidated. Besides, certain interactions due to problematic solutions are removed. We recognize that many aspects remain to be studied. Some of them are : 1. To propose a systematic method of how to remove undesirable cycles. 2. To de ne more rigorously the prioritized product. 3. To generalize the method to the case where there are more than two services involved in an interaction. The method of detection can be trivially generalized and we are now investigating how to generalize the method of resolution in an optimal way. A rst approach one may thinks of, is to proceed iterately as follows. Let us for instance consider three con icting services S1, S2 and S3. We may in a rst step consider only S1 and S2 and resolve a possible interaction between them. Let S be the system made up of S1, S2 and the possible controllers which force S1 and S2 to behave in a desired way. In a second step, we may consider S as being one service and try to resolve a possible interaction between S and S3. And so on. This approach is not optimal. In fact, it is possible that an interaction exists between S1 and S2, and that this interaction is removed by the addition of S3. In this case, the rst step presented above restricts uselessly the global behaviour made up of S1, S2 and S3. Our aim is to propose a more optimal method. 4. To adapt our method to other areas besides telecommunications, such as robotics and manufacturing. 5. To develop and implement an algorithm based on our method.

Acknowledgements We thank Gregor v. Bochmann, professor at the University of Montreal, for his fruitful comments on a rst draft of this paper. We also thank Youssef Iraqi, PhD student at the University of Montreal, for the fruitful discussions which contribute for realizing this paper.

References [1] L.G. Bouma and H. Velthuijsen, editors. Second International Workshop on Feature Interactions In Telecommunications Systems (FIW'94), Amsterdam, 8-10 May 1994. IOS Press (Netherlands). [2] E.J. Cameron, N.D. Grieth, Y.-J. Lin, M. Nilson, W.K. Schnure, and H. Velthuijsen. A feature interaction benchmark in IN and beyond. Technical Report TM-TSV-021982, Bellcore, Nov. 1992. 22

[3] E.J. Cameron, N.D. Grieth, Y.-J. Lin, M. Nilson, W.K. Schnure, and H. Velthuijsen. A feature interaction benchmark for IN and beyond. IEEE Communications Magazine, 31(3), March 1993. [4] E.J. Cameron, N.D. Grieth, Y.-J. Lin, M. Nilson, W.K. Schnure, and H. Velthuijsen. A feature interaction benchmark for IN and beyond. In Feature Interactions in Telecommunications Systems, pages 1{23, Amsterdam, May 1994. [5] K.E. Cheng and T. Ohta, editors. Third International Workshop on Feature Interactions In Telecommunications Systems (FIW'95), Kyoto, 11-13 October 1995. IOS Press (Netherlands). [6] A. Khoumsi, G.v. Bochmann, and R. Dssouli. Contr^ole et extension des systemes a evenements discrets totalement et partiellement observables. In Proceedings of The Third Maghrebian Conference on Software Engineering and Arti cial Intelligence, Rabat, Morocco, April 1994. [7] A. Khoumsi and E.H. Bouyakhf. Contr^ole des systemes distribues communicants. In Colloque Francophone pour l'Ingenierie des Protocoles (CFIP), Rennes, France, May 1995. [8] P.J. Ramadge and W.M. Wonham. The control of discrete event systems. In Proceedings of the IEEE, volume 77, pages 81{98, January 1989. [9] K. Rudie and W.M. Wonham. Think globally, act locally: Decentralized supervisory control. IEEE Transactions on Automatic Control, 37(11):1692{1708, November 1992. [10] J.G. Thistle, R.P. Malhame, and H.H. Hoang. Application of supervisory control theory to the development of intelligent network services. Submitted for publication. [11] W.M. Wonham and P.J. Ramadge. On the supremal controllable sublanguage of a given language. SIAM J.Control and Optimization, 25(3):637{659, May 1987.

23