The Declarative Language STR (State Transition Rule)

Transcription

1 The Declarative Language STR (State Transition Rule) T. Yoneda and T. Ohta SOK University, Faculty of Engineering, 1-236, Tangi-cho, Hachioji-shi, Tokyo Japan. bstract. The declarative language STR (State Transition Rule) is proposed to describe service specifications and programs. Given that telecommunication service specifications can be represented in the form of a state transition diagram, STR describes conditions for state transitions in the form of a production rule. STR specifications, description examples, categories of feature interactions, examples of feature interactions, interaction detection method, and application to ctive Networks are described. 1 Introduction This paper proposes a declarative language, STR (State Transition Rule). STR was developed at TR(dvanced Telecommunication Research Institute) originally to describe telecommunication service specifications for automatically generating switching systems programs. STR has also been used to describe service specifications to automatically detect feature interactions. Now, it is also used as programming language for prototyping systems. In this paper, the birth of STR, its specifications as a telecommunication service specification description language, its application in detecting feature interactions and its recent application to ctive Networks are described. Considering that telecommunication service specifications can be represented in the form of a state transition diagram, STR was developed to describe conditions for state transitions as production rules. It exhibits a number of characteristics. mong them, because of application rules for production rules, feature interactions between service and service occur solely by combining both sets of rules for service and service. This leads formal methods for detecting feature interactions without state creations. nother characteristic is that by using STR as a programming language it is very easy to add new services to existing services. In section 2, the original objective for developing STR is described. In section 3, language specifications of STR are explained briefly. In section 4, some examples of describing services using STR are shown. In section 5, the following feature interaction issues are discussed: formal definitions of feature interactions, some examples of feature interactions, non-monotony phenomenon in adding new services, and interaction detection methods based on STR. In section 6, application to ctive Networks is reported.

2 198 T. Yoneda and T. Ohta 2 Objectives for developing STR STR was developed at TR(dvanced Telecommunication Research Institute) originally to describe telecommunication service specifications for automatically generating switching systems programs [1] (Figure 1). Potential users are those who can understand telecommunication services but are not necessarily experts on switching systems. In the Interface Process block, Diagram or Natural Language nimation Service Developer Interface Process Requirement Elicitation Detect Feature Interactions STR Database Convert to SDL Detailed Design Program Synthesis Prog. Components Object Program Detailed Design Data System Developer Fig.1. utomatic programming system specifications using diagram form or natural language are converted to STR. lso, animation for service specification input by a user is shown to a user to confirm that her or his description has no mistakes. In the Requirement Elicitation block, the set of rules described using STR for input specification is validated as a single service. In the Detect Feature Interactions block, STR for input service specification is validated if it causes feature interactions with other services specifications. In the Convert to SDL block, all rules described in STR are merged and converted to SDL (Service Description Language), which is one of standard service description languages. In this process, a detailed description of SDL, which has been stored beforehand by system developers, is added automatically. In the Program Synthesis block, the specification described in SDL is converted to a C language program automatically. In this process, program components, which have been stored beforehand by system developers, are added. Thus, in so far as input specification requires only prestored precise SDL descriptions and program components, input service specification is automatically converted to C program. qstr has also been used to describe service specifications to automatically detect feature interactions [2][3][4][5][6]. Now, it is also being used as a programming language for prototyping systems.

3 Declarative Language STR (State Transition Rule) 199 s is well known, telecommunication service specifications can be described in the form of a state transition diagram. Therefore, the service specification can be represented as a set of rules which describe conditions of the state transitions. 3 Syntax and application rules system state is represented as a set of statuses, called primitives, of terminals or relationships between terminals connected to the system. The primitive consists of a primitive name, which represents a status, and arguments which indicate real terminals (e.g.,,c). The primitives which begin with m- represent a service being activated. For example, if terminal has Call Waiting service activated it is represented as m-cw(). The primitives which begin with m- do not necessarily change during a call s state transition from initial state, (), to final state, () in the case of telecommunication services. dialtone m-cw C D E F Fig.2. System state Example 1: Terminal has Call Waiting service activated (denoted as m- cw()), terminal is hearing a dial-tone (denoted as dialtone()), terminal and C are ing with each other (denoted as (,C)), terminal D is in state (denoted as (D)), terminal E and F are ing with each other (Figure 2). Then, this system state is described as follows: {m-cw(),dialtone(),(,c),(d),(e,f)} The syntax of STR is as follows. Pre-condition event: Post-condition Pre-condition and Post-condition are represented as a set of primitives, respectively. In the rule, the arguments of each primitive are described as terminal variables (e.g. x,y,z) so that the rule can be applied to any terminals. Example 2: Suppose, Call Waiting service. Terminal y has CW service activated. Terminal x is hearing a dial-tone, and terminal y and z are ing with each other. When terminal x dials to terminal y (denoted as dial(x,y)),

4 200 T. Yoneda and T. Ohta terminal y transits to call waiting ringing state (denoted as cw-ringing(y,x)) and terminal x hears audible ringing tone (denoted as cw-ringback(x,y)). In this case, the rule is described as follows: m-cw(y),dialtone(x),(y,z) dial(x,y): m-cw(y),cw-ringing(y,x),cw-ringback(x,y),(y,z) Next, rule application and change of system state when the rule is applied are described. The states where for Pre-condition or Post-condition terminal variables are replaced by the real terminals are called the state corresponding to Pre-condition or Post-condition, respectively. When the state corresponding to Pre-condition exists in the system state, it is said that Pre-condition is included in the system state. Rule 1) asic rule application: When an event occurs in a system, a rule that has the same event and whose Pre-condition is included in the system state is applicable. Rule 2) Precedent rule application: When more than one rule is applicable, the rule whose Pre-condition includes any other rules Pre-conditions is applied. Rule 3) Change of system state: When a rule is applied, the next state of the system state is obtained as follows: The state corresponding to Pre-condition of the applied rule is deleted from the current system state and the state corresponding to Post-condition of the applied rule is added. Current state of System {m-cw(),dialtone(),(,c), (D),(E,F)} Next state of System {cw-ringing(,),cw-ringback(,), (,C),(D),(E,F)} {dialtone(),(,c)} is deleted {cw-ringing(,),cw-ringback(,), (,C)} is added Current State of System dialtone m-cw E Fig.3. System state change C F D Next State of System cw-ringback dial(,) cw-ringing m-cw E C F D

5 Declarative Language STR (State Transition Rule) 201 Example 3: Let the current system state be the same as that described in example 1, and the rule, which is the same as described in Example 2, is applied. Suppose an event, dial(,), occurs in the system. Terminal variables x, y and z in Pre-condition of the rule can be replaced by real terminals, and C. Then, the state corresponding to the Pre-condition of the rule is obtained as {m-cw(),dialtone(),(,c)}. Since the Pre-condition of the rule is included in the system state, the rule can be applied. When the rule is applied the state corresponding to the Pre-condition of the rule is deleted from the system state, and the state corresponding to the Post-condition is added (Figure 3). 4 Examples for STR descriptions 4.1 asic service STR description for basic service, normal route, is shown in Figure 4. Terminal ehavior dial-tone offhook ringback dial ringing offhook STR Description rule 1): () offhook():dial-tone () rule 2): dial-tone (), () dial (,): ringback (,), ringing (,) rule 3): ringback (,), ringing (,) offhook (): (,) Fig.4. STR description for basic service 4.2 Call forwarding service s STR descriptions for basic service are automatically used for Call forwarding service, STR descriptions to be added for Call forwarding service, normal route only, are shown as follows: rule cf1): dialtone(x),m-cfv(y,z),(z) dial(x,y): ringback(x,z),ringing(z,x),m-cfv(y,z) rule cf2): dialtone(x),m-cfv(y,z),not[(z)] dial(x,y): busy(x),m-cfv(y,z)

6 202 T. Yoneda and T. Ohta 4.3 Call waiting service In the same way, STR descriptions to be added for Call waiting service, normal route only, are shown as follows: rule cw1): m-cw(x),(x,y),dialtone(z) dial(z,x): m-cw(x),(x,y),cw-ringback(z,x),cw-ringing(x,z) rule cw2): m-cw(x),(x,y),cw-ringback(z,x),cw-ringing(x,z) flash(x): m-cw(x),hold(x,y),(x,z) rule cw3): m-cw(x),hold(x,y),(x,z) flash(x): m-cw(x),hold(x,z),(x,y) rule cw4): m-cw(x),hold(x,y) onhook(y): m-cw(x),(y) rule cw5): m-cw(x),hold(x,y),(x,z) onhook(z): m-cw(x),(x,y) rule cw6): m-cw(x),(x,y),hold(x,z) onhook(x): m-cw(x),busy(y),ringing(x,z),hold(x,z) rule cw7): m-cw(x),ringing(x,z),hold(x,z) offhook(x): m-cw(x),(x,z) 4.4 Originating call screening service For originating call screening service, if an originating terminal dials to a terminal which has been registered in the screening list as a screened terminal, the call connection is rejected (Figure 5). Not only the directory number for an individual terminal but also the special code, in order to inhibit distance call, can be registered in the screening list. To add the originating call screening dialtone m-ocs(,) dial(,) busy m-ocs(,) Fig.5. Originating call screening service service, for a normal route, only the following rule has to be added: dialtone(x),m-ocs(x,y) dial(x,y): m-ocs(x,y),busy(x) 4.5 Terminating Call Screening Service For terminating call screening service, if a call terminated from a terminal which has been registered in the screening list as a screened terminal, the call connection is rejected (Figure 6). oth the directory number for individual terminals and area codes for rejecting calls from certain areas, can be registered in the screening list. To add the terminating call screening service, for normal route, only the following rule has to be added: m-tcs(y,x),dialtone(x) dial(x,y): m-ocs(y,x),busy(x)

7 Declarative Language STR (State Transition Rule) 203 dialtone m-tcs(,) dial(,) busy m-tcs(,) Fig.6. Terminating call screening service 4.6 Feature Integration When a feature is integrated into existing features, the union of the rules forming existing features and the rules forming the feature is taken. To detect feature interactions between two features, the union of the rules forming each service is taken. 5 Feature Interactions 5.1 Formal Definitions To detect feature interactions automatically[7]-[11], formal definitions of feature interactions are needed. Given that telecommunications service specifications can be written as a form of a state transition diagram and, therefore, feature interactions can be represented as abnormal state transitions, author has proposed formal definitions of feature interactions for the following seven categories [4]. dead lock live lock non-determinacy appearance of an abnormal state disappearance of a normal state appearance of an abnormal transition disappearance of a normal transition Dead lock, live lock, and non-determinacy can be identified from the diagram. For the four other interactions, we cannot identify from whether or not interactions occur without knowing the meaning of transitions and states. Therefore, the first three interactions are called logical interactions, and the remaining four interactions are called semantic interactions. 5.2 Non-determinacy Non-determinacy is defined in such a way that for an event more than one transition is possible. In other words, for an event the sate transition cannot

8 204 T. Yoneda and T. Ohta be determined. Suppose, terminal has call waiting service and call forwarding service activated, and has registered terminal D as a forwarded terminal. When terminal C dials to terminal while terminal and terminal are ing with each other, the system cannot decide which service should be applied, call waiting service or call forwarding service (Figure 7). dial-tone C m-cw() m-cfv(,d) D CW: Call wating service CFV: Call forwarding service CW? dial(c,) CFV? cw-ringing cw-ringback C m-cw() m-cfv(,d) D ringback C m-cw() m-cfv(,d) ringing D Fig.7. Non-determinacy 5.3 Other examples ccording to formal definitions on feature interactions, some feature interactions between call waiting service and call forwarding service are shown. s described in section 5.2, if terminal D dials when terminal and terminal are ing with each other and terminal has call waiting service and call forwarding service activated, non-determinacy happens. In the same case, suppose terminal has registered terminal C as a forwarded terminal to which any calls to terminal are forwarded, and a system decides that call forwarding service takes precedence over call waiting service. Then, in this case, the call from terminal D to terminal is forwarded to terminal C. From the call waiting service s view point, two abnormal state transitions occur. One is disappearance of a normal state, and the other is appearance of an abnormal transition (Figure 8). If call forwarding service takes precedence over call waiting service, cw-calling state disappears. cw-calling(d,) state represents the state where, if the new call terminates to terminal while terminal has call waiting service activated and is ing with terminal, terminal hears the special audible ringing tone which indicates a new call terminates to terminal. The state cw-calling(d,) can be transited only from the state (,). Therefore, if call forwarding service takes precedence over call waiting service, cw-calling(d,) never appears. Moreover, a transition from (,) to cw-calling(d,) is an intention of call waiting service. Therefore, from the call waiting service s view point,

9 Declarative Language STR (State Transition Rule) 205 {,,C,D} has CW and CFV activated ppearance of abnormal transition.. (,) Disappear D dials Disappearance of normal state cw-calling(d,) (,) calling(d,c) Fig.8. Interactions in case that CFV takes precedence over CW transition to the new state transited by call forwarding service is abnormal, appearance of an abnormal transition. On the other hand, the system decides that call waiting service takes precedence over call forwarding service. In this case two interactions can be seen, appearance of abnormal transition and disappearance of normal transition (Figure 9). If call waiting service takes precedence over call forwarding service while terminal and are at the state (,), a new call to terminal is never forwarded to terminal C. ut, the state {(,),calling(d,c)} can be reached via another route as shown in Figure 9. Therefore the state {(,),calling(d,c)} does not disappear. Therefore, this is not a case for disappearance of a normal state but disappearance of a normal transition. nother interaction occurs in a transition from (,) to {(,),cw- D dials {,,C,D} has CW and CFV activated calling(d,c) dials calling(,) calling(d,c) makes offhook.. (,) (,) calling(d,c) ppearance of abnormal transition D dials Disappearance of normal transition (,) cw-calling(d,) Fig.9. Interactions in case that CW takes precedence over CFV

10 206 T. Yoneda and T. Ohta calling(d,e)} in Figure 9. From the call forwarding service s view point, the transition from (,) to {(,),calling(d,c)} is an intention. ut, in a transition from (,) to {(,),cw-calling(d,e)}, the intention is not realized. Therefore, from the call forwarding service s view point, the transition from (,) to {(,),calling(d,c)} is abnormal. 5.4 Non-monotony s shown in the previous section, 5.3, when adding new services to existing services, some states or/and some transitions may disappear. This shows non-monotony phenomenon in adding a new service. We can say that feature interactions cause a non-monotony phenomenon in adding new services. 5.5 Interaction detection method based on STR input spec. conventional methods generating all states testing all states explosion of the number of states explosion of computation time to detect interactions detect interactions Fig.10. Comparison of detecting methods input spec. our method rule analysis dramatical reduction of computation time detect interactions We have proposed formal methods for detecting feature interactions under the condition where service specifications are described using STR[5][6]. They deals with semantic interactions. Though they are now under evaluation, the proposed methods are at present efficient and effective. Since the proposed methods do not require the generation of any states, they do not cause an explosion of the number of states no matter how many terminals are connected to the network. This results in a dramatic reduction of computation time for detecting feature interactions. See Figure 10. brief explanation of our method is given. For detailed descriptions, please refer to paper [5] and [6]. Semantic interactions can be considered as follows: Suppose two services are activated. When either specification of the services is applied, a state transition according to the specification contradicts the specification for the other service. Feature interactions are then detected as follows: From each service, select a rule, respectively, which is applicable to the same system state. pply either rule to the system state. Check if the state transition by the rule causes abnormal state transition from the view point of the other service, whose rule is not applied.

11 Declarative Language STR (State Transition Rule) 207 ccording to conventional detection methods, all possible states must be generated by one way or another and all state transitions should be checked to detect feature interactions. This causes an explosion of the number of states causing an explosion of computation time to detect feature interactions. ccording to our method, however, interactions are detected solely by analyzing Pre-conditions, events, and Post-conditions of selected rules. This method does not require any state creation and does not cause an explosion of computation time for detection of feature interactions. 6 pplication to ctive Networks We used STR to describe a program up-loaded to VoIP gateway which adopts ctive Networks architecture[12][13]. The following are experimental results. 6.1 ESTR ESTR was developed as a programming language for users to describe their programs which are up-loaded to ctive Networks. It was developed by enhancing STR. More precisely; as a condition for rule application, conditions for state transitions are applied in the same way as STR, and a description part of conditions for system controls required for the state transition is added. ESTR has the form of Pre-condition, event and Post-condition. It is a rule for defining a condition for state transition, state change while the rule is applied, and system control required for the state transition. Pre-condition consists of status description elements called primitives. Primitives are statuses of terminals or relationships between terminals which are targets of the state transition. n event is a trigger which causes the state transition, e.g. a signal input to the node and some trigger occurs in the node. Post-condition consists of two parts. One is the state description part which also consists of primitives. The other is the system control description part which indicates the system controls required for the state transition. The system control description part is described in {} which follows after state description part separated by, (see Figure 11). When no system controls are required, the content of {} is empty. n example of ESTR is shown in Figure 11. The call(x,y) connotify(y,x): (x,y), Send(con,y,x),Con(x,y) Fig.11. n example of ESTR example in Figure 11 is explained. Terminal x and y are in calling state, denoted by call(x,y). If terminal y makes offhook, denoted by connotify(y,x), a signal Connect is sent to terminal x, denoted by Send(con,y,x), and terminal

12 208 T. Yoneda and T. Ohta x and y transit to state, denoted by (x,y). call(x,y) and (x,y) are called status primitives. ll arguments in status primitives are described as variables so that a rule can be applied to any terminals. 6.2 Experimental System Execution Environment Service programs described using ESTR ESTR Interpreter Input processing part System control executing part Platform provided by a vendor Fig.12. Experimental system The software structure of an experimental system for the proposed system is shown in Figure 12. n execution environment program, which consists of ISDN Telephone Gateway Gatekeeper Gateway ISDN Telephone Setup Call Proceeding lert Connect voice Location Request Location Confirm dmission Request dmission Confirm lert Notify Connect Notify H.245 dialog RTP voice packet Setupnotify dmission Request dmission Confirm Setup lert Connect voice Fig.13. H.323 Protocol an Input processing part, an ESTR Interpreter and a System control executing part, is implemented on top of an IP Gateway Platform purchased on the market. user program described using ESTR is executed on the Execution

13 Declarative Language STR (State Transition Rule) 209 environment program. The protocol between terminals and the IP Gateway is ISDN. The system control description part shows conditions for controlling the IP Gateway based on protocol H.323[14]. H.323 protocol is shown in Figure 13. ESTR Interpreter The ESTR Interpreter is initiated by receiving an event from the Input processing part, the interpreter selects a rule in a rule data base, and interprets the rule. The interpreter sends the system control description part of the rule to a system control executing part. When the interpreter receives execution results from the system control executing part, a state corresponding to the Pre-condition of the rule is deleted from the system state, and a state corresponding to the Post-condition of the rule is added to the system state. Input processing part When the Input processing part receives a signal from the Platform, the Input processing part translates it to an event defined in ESTR Interpreter, and the event is sent to the Interpreter to initiate the Interpreter. System control executing part When the System control executing part receives a signal (system control description part of the rule) from the Interpreter, it analyzes the signal and calls the appropriate PI provided by the Platform to send signals to terminals or other nodes. asic service The ESTR description of a normal route in basic service of VoIP Gateway is shown in Figure 14. In Figure 14, wtalert(x,y) represents that terminal x is awaiting alert signal from terminal y. called(x,y) represents that terminal y is called by terminal x. call(x,y) represents that terminal x is calling terminal y. (x,y) represents that users of terminal x and terminal y are ing with each other. wtrelcomp(x) represents that terminal x is awaiting release completion signal from the network. wtrel(y) represents that terminal y is awaiting release signal from the network. In the same rule, the same terminal variables represent the same terminal. etween different rules, the same terminal variables, x in rule 1 and x in rule 2, are not necessarily the same terminal. On the other hand, different terminal variables in the same rule represent different terminals. ut, between different rules, different terminal variables, x in rule 1 and y in rule 2, are not necessarily different terminals. setup(x,y), alert(y,x), disc(x,y), rel(x) and relcomp(x) are events. setup(x,y) represents receiving a setup signal from terminal x to terminal y. alert(y,x) represents receiving an alert signal from terminal y to terminal x. disc(x,y) represents receiving a disconnect signal from terminal x to terminal y. rel(x)

14 210 T. Yoneda and T. Ohta represents receiving a release signal from terminal x. relcomp(x) represents receiving a release complete signal from terminal x. Send(s,x,y) represents sending terminal y a signal s from terminal x. Con(x,y) represents connecting terminal x and terminal y. Disc(x,y) represents releasing a connection between terminal x and terminal y. signal flow (x) setup(x,y): wtalert(x,y),{send(calp,x),send(setupnotify,x,y)} (y) setupnotify(x,y): wtalert(y,x),{send(setup,x,y)} wtalert(y,x) alert(y,x): called(y,x),{send(alertnotify,y,x)} wtalert(x,y) alertnotify(y,x): call(x,y),{send(alert,y,x)} called(y,x) con(y,x): (y,x),{send(connotify,y,x),send(conack,y,x)} call(x,y) connotify(y,x): (x,y),{send(con,y,x),con(x,y)} (x,y) disc(x,y): wtrelcomp(x),{disc(x,y),send(rel,x),send(discnotify,x,y)} (y,x) discnotify(x,y): wtrel(y),{send(disc,x,y)} wtrel(x) rel(x): (x),{send(relcomp,x)} wtrelcomp(x) relcomp(x): (x),{} Fig.14. Examples of ESTR Descriptions from a receiving setup signal to a sending setup signal to a Gatekeeper is shown in Figure 15. Interpreter pplied rule: (x) setup(x,y): wtalert(x,y),{send(calp,x),send(setupnotify,x,y)} setup(,) Input processing part Setup(,) Send(calp,x),Send(setupnotify,x,y) System control executing part CreateCall() Platform provided by a vendor Fig.15. n example of signal flow 7 Summary The declarative language STR (State Transition Rule) was proposed to describe service specifications and to program a telecommunications system. Objectives and specifications of STR and some examples were described. ased on state transition model, 7 categories for feature interactions were described. ccording to the categories, some examples of feature interactions were shown. n out line of our method for detecting feature interactions were de-

15 Declarative Language STR (State Transition Rule) 211 scribed. With this method, generating system states is not required. Therefore, an explosion of computation time for the detection of feature interactions can be avoided. n experimental system for ctive Networks using STR to describe uploaded programs was shown, illustrating that by using STR as a programming language it is very easy for users to add new services to existing services. Future work will focus on evaluation of feature interaction detection methods and their application to ctive Networks, and new applications of STR. References 1. Y. Hirakawa et al., Telecommunication Service Description Using State Trnsition Rules, Int. Workshop on Software Specification and Design, Oct T. Ohta and et al., Classification, Detection and Resolution of Service Interactions in Telecommunication Services, Proc. of FIW94, pp.60-72, May Y. Kawarasaki and T. Ohta, New Proposal for Feature Interaction Detection and Elimination, Proc. of FIW95, pp , Oct T. Ohta and C. Flaviu, Formal Definitions of Feature Interactions in Telecommunications Software, IEICE Trans. on Fundamentals, vol. E-81, No.4, pp , pril T. Yoneda and T. Ohta, Formal pproach for Definition and Detection Feature Interactions, Proc. of FIW98, pp , Sep T. Yoneda and T. Ohta, utomatic Elicitation of Knowledge for Detecting Feature Interactions in Telecommunication Services, IEICE Trans. on Information and Systems, vol. E-83D, No.4, pril L. G. ouma and H. Velthuijsen (eds.), Feature Interactions In Telecommunication Networks II, IOS Press, K. E. Cheng and T. Ohta (eds.), Feature Interactions In Telecommunication Networks III, IOS Press, P. Dini et al. (eds.), Feature Interactions In Telecommunication Networks IV, IOS Press, K. Kimbler and L. G. ouma (eds.), Feature Interactions In Telecommunications nd Software Systems V, IOS Press, M. Calder and E. Magill (eds.), Feature Interactions in Telecommunications and Software Systems VI, IOS Press, K. L. Calvert, et al., Directions in ctive Networks, IEEE Com. Magazine, Vol.36 No.10, pp.72-78, Oct ctive Networks, Lecture Notes in Computer Science 1653, Springer, ITU-T Rec. H.323, Packet-based multimedia communications systems, 1998.

16 212