feature interaction detection contest of the fifth international workshop on feature interactions

Feature interaction detection contest of the Fifth InternationalWorkshop on Feature Interactions

Nancy Gri�eth a,*, Ralph Blumenthal b, Jean-Charles Gregoire c, Tadashi Ohta d

a Lucent Technologies, AT&T Bell Laboratories, 600 Mountain Avenue, Murray Hill, NJ 07974-0636, USAb Daewoo Telecom, Ltd., Middletown, NJ, USA

c INRS-T�el�ecommunications, Verdun, Qu�ebec, Canadad Soka University, Hachioji, Japan

Abstract

A feature interaction detection contest was held for the Fifth International Workshop on Feature Interactions. The

contest had two phases. The ®rst phase required the contestants to analyze interactions among ten features, which were

published on 15 February 1998, and to submit their results by 15 July 1998. The second phase, begun on 15 July 1988,

required analysis of the interactions among two new features and the original 10, to be submitted by 1 August 1988. Six

contestants submitted entries, to be judged in August and September, with the winner to be announced at the work-

shop. This body of this paper outlines the contest instructions. Ó 2000 Elsevier Science B.V. All rights reserved.

Keywords: Software requirements and speci®cations; Software veri®cation and validation; Software maintenance; Communication

system software; Communication system signaling; Feature interactions

1. Introduction

The goal of this contest is to compare di�erentfeature interaction detection tools according to asingle benchmark collection of features. We havetried to describe the features both precisely andsimply. This has not been easy, but we hope thatthe result will be adequate to the purpose.

In order to de®ne the features, we model anetwork as a collection of black boxes (Section 2),communicating with each other via de®ned inter-faces (Section 3). We de®ne the plain old telephoneservice (POTS) service and the features as se-

quences of events taking place on these interfaces(Section 4).

The choice of features has been dictated by theneed for them to interact. They must have somecommonality. For this ®rst contest, we are usingversions of familiar POTS features, to ensure thatthere are plenty of interactions. To provide a bit ofa challenge for the tools, we introduce features inseveral di�erent categories. There are billing fea-tures as well as call control features, and somefeatures are switch-based whereas others are im-plemented on an IN platform.

Do not assume that because these are familiarfeatures, the interactions will be the usual ones.The features are de®ned on a simpli®ed networkmodel, their de®nitions have been changed slight-ly, and ± most important ± we have sincerely triedto de®ne each feature without thinking about the

Computer Networks 32 (2000) 487±510

www.elsevier.com/locate/comnet

* Corresponding author.

E-mail address: [email protected] (N. Gri�eth).

1389-1286/00/$ - see front matter Ó 2000 Elsevier Science B.V. All rights reserved.

PII: S 1 3 8 9 - 1 2 8 6 ( 0 0 ) 0 0 0 1 2 - 8

other features. Each feature was de®ned as if it isthe only feature that will be used and as if it will beactive on only one call at a time. As a result, theinteractions may be quite di�erent from the ex-pected ones! In particular, beware of interactionsthat are normally so embedded in the features thatthey appear to be part of them.

Our models of POTS, IN, and billing are quitesimple. We hope that more detailed models ofthese will be available for future contests. How-ever, for this ®rst contest, it seemed important tokeep things simple as is reasonable (and no sim-

pler). In future contests, we would also like to seethemes involving ISDN, wireless, PCS, and eventhe Web.

2. The network

The network consists of· End-user equipment (telephones).· A switch (fast enough to handle all telephones at

once).· A service control point (SCP) that processes IN

features like credit card calling, 800/900 num-bers, IN call forwarding, and so on.

· An operations system (OS) that does billing.There is also a global clock whose value is

represented in the variable time (Fig. 1).

3. Events on the network interfaces

The network interfaces are the interface be-tween the user and the switch (on which the tele-phone is used for signaling); the interface betweenthe switch and the SCP (on which IN messages areused); and the interface to the billing system (fortracking the beginning and end of each call).Fig. 1. Diagram of the network.

Table 1

Events on the user/switch interface

User to switch Switch to user

O�-hook X:Address DialTone X:Address [C:Cadence]

On-hook X:Address Start AudibleRinging X:Address Y:Address

Dial X:Address Y:Address Start Ringing X:Address Y:Address [C:Cadence]

Flash X:Address Start CallWaitingTone X:Address Y:Address [C:Cadence]

Stop AudibleRinging X:Address Y:Address

Stop Ringing X:Address Y:Address

Stop CallWaitingTone X:Address Y:Address

LineBusyTone X:Address [C:Cadence]

Announce X:Address M:Message

Disconnect X:Address Y:Address

Display X:Address M:Message

Table 2

Events on the switch/SCP interface

Switch to SCP SCP to switch

Trigger N:TriggerName S:Address A:Address B:Address T:Time Response R:ResponseType S:Address A:Address . . .

Resource S:Address A:Address M:Message

488 N. Gri�eth et al. / Computer Networks 32 (2000) 487±510

Fig. 2. POTS: the basic call model.

Table 3

SCP responses to switch messages

Response type Additional parameters

ANALYZE_ROUTE B:Address C:Address

FORWARD_CALL B:Address C:Address

CONTINUE B:Address

SEND_TO_RESOURCE M:Message

DISCONNECT

Table 4

Events on the interface to the billing system

to OS

LogBegin X:Address Y:Address P:Address T:Time

LogEnd X:Address Y:Address T:Time

N. Gri�eth et al. / Computer Networks 32 (2000) 487±510 489

3.1. User/switch

The telephone provides the events on the in-terface between the user and the switch. Table 1summarize the events between the user and theswitch. The format of an event is

heventi hparameteri :htypeihparameteri :htypei � � �

where heventi is an event name, hparameteri is asymbol, and htypei indicates the type of the pa-rameter. We use types Address (for a telephone

number), Cadence (for a special ring or tone), andMessage (for a string).

The ®rst parameter of an event is the addressof the telephone on whose interface the eventoccurs. A number of events have more parame-ters:· Dial A B means that the subscriber at address A

dials the address B.· Flash A is equivalent to an On-hook A followed

by an O�-hook A, unless a feature uses it other-wise. We assume that end-users have a Flashbutton.

Fig. 3. Call forwarding busy line.


· DialTone A n means that dialtone occurs at ad-dress A. The second parameter, if present, spec-i®es a special cadence for the dialtone. Weprovide stop and start events for ringing andcall-waiting tone, but for the given features, nointeresting events occur between starting andstopping DialTone or LineBusyTone, so we leftthem as single events.

· Start Ringing A B n and Start CallWaitingToneA B n mean that alerting starts at address A fora call originated at address B. If the third pa-rameter is present, it speci®es the cadence ofthe alerting. It not, the cadence is the usual ca-dence.

· Start AudibleRinging A B means that the ring-back tone is provided at address A while waitingfor the user at address B to answer the call.

· Stop Ringing A B, Stop CallWaitingTone A B,and Stop AudibleRinging A B mean to stop theringing or tone occurring at address A in rela-tion to a call to or from B.

· LineBusyTone A n means that the telephone towhich A is attempting a connection is busy.The second parameter, if present, speci®es thecadence of the tone.

· Announce A M means that announcement M isplayed to address A.

· Disconnect A B informs A that B has discon-nected a connection with A. (We use a restrictedde®nition for Disconnect. It is a signal from theswitch to a user, signaling the user that a con-nected party has gone On-hook. The On-hookevent is the signal from the user to the switchthat the user is disconnecting.)

· Display A M uses a display screen on telephoneat address A (or a Caller ID box at the same ad-dress) to display the message M concerning thecurrent call. Typically, the message is the num-ber of the calling party, but it could be anotherstring such as ``Anonymous.''We assume that the various cadences and

messages have well-de®ned implementations, butwe will just use descriptive strings to distinguishthem.

3.2. Switch/SCP

The Bellcore AIN document GR-1298-COREhas been a reference for this interface, but we use amuch simpli®ed version of the message parame-ters. A trigger message includes only the triggername, the subscriber address, the calling partyaddress, the called party address, and the time.The response messages include only the response

Fig. 4. Calling number delivery.


type, the subscriber name, the calling party ad-dress, and other necessary parameters for that re-sponse type (see Table 2).

The type TriggerName is an enumeration ofthe names of IN triggers. Some valid Trigger-NameÕs are ORIGINATION_ATTEMPT, IN-FO_COLLECTED, INFO_ANALYZED, andNETWORK_BUSY. In the trigger message, the®rst address parameter is that of the subscriber,the second of the calling party, the third of the

called party, and the last parameter is the currenttime.

The type ResponseType is an enumeration ofthe SCP responses to trigger messages. Some validResponseTypeÕs are ANALYZE_ROUTE, CON-TINUE, FORWARD_CALL, and SEND_TO_RESOURCE.

The Resource S A M message responds to theSEND_TO_RESOURCE message. The string Mis a string of collected digits.

Fig. 5. IN freephone billing.


Additional parameters (after the subscriber andcalling party addresses) for the ResponseTypes aregiven in Table 3.

ANALYZE_ROUTE S A B C means to route acall from A to B with C as the paying party (nor-mally, C will be A). S is the subscriber on whosebehalf the trigger was activated, usually A or B.

FORWARD_CALL S A B C means to forwarda call to C, originated by A, with terminating ad-dress B.

CONTINUE S A B means to continue pro-cessing the call as if no trigger had occurred.

SEND_TO_RESOURCE S A M means to playthe message M at address A and collect the re-sponse (if any).

DISCONNECT S A means to terminate pro-cessing of calls from A until after A has gone on-hook.

3.3. Interface to the billing system

We assume the existence of a billing systemrecognizing messages from the switch or the SCPand that billing is based entirely on subscriber

Fig. 6. IN freephone routing.


addresses and calls placed. These messages providethe time, the calling party, called party, and(LogBegin only) the paying party (see Table 4).

3.4. Simplifying assumptions

1. The above messages are all there are.2. User to Switch ``messages'' get an instanta-

neous response from the switch, i.e., DialTone

starts immediately after O�-hook and stops im-mediately after Dial. This means that two usermessages will not be sent one immediately afterthe other; there will always be a switch responsebetween.

3. On-hook is instantaneously followed by Dis-connect. There is no extended disconnect tim-ing.

4. There are no network busy conditions.

Fig. 7. IN teen line.


5. There is no provisioning or de-provisioning offeatures. Also, there is no feature activationor de-activation. A subscriber either has a fea-ture or does not.

6. The end-user equipment has a button for Flash.

4. Services and features

We de®ne POTS and all features of POTS assets of sequences of events on interfaces betweennetwork elements (telephones, switch, SCP, andOS). The de®nitions are expressed in the form ofChisel sequence diagrams [1]. A Chisel sequencediagram is just a directed graph, whose nodes areevents on the various interfaces. The diagram de-®nes a set of event sequences for a single call, onefor each path through the graph. Event sequencesinvolving multiple calls can be interleaved to de®neglobal system activity.

4.1. Interpreting the Chisel sequence diagram forPOTS

For illustration, a basic two-party POTS dia-gram is given in Fig. 2. It includes both telephones

in a two-party call, and also some messages for thebilling system.

A node (one of the ovals) in a sequence dia-gram contains a number, which uniquely identi®esthe node within the feature, and one or moreevents and variable assignments. The nodes areconnected by directed edges (arrows in the dia-grams). Multiple events in a node are separated byvertical bars (|||). A node containing multiple suchevents is equivalent to the sequence diagram rep-resenting any possible sequence of those sameevents (i.e., A ||| B means {AB, BA}; A ||| B ||| Cmeans {ABC, ACB, BAC, BCA, CAB, CBA};and so forth).

Variables are used in conditions on the edges, tode®ne when an edge can be followed in con-structing an event sequence from the diagram andto restrict possible interleavings of event sequenc-es. A variable de®nes one or more sequences ofevents, in the sense that Busy B de®nes the set ofevent sequences having one of the followingproperties:· An event sequence containing an O�-hook B not

followed by On-hook B.· An event sequence containing Ringing B not fol-

lowed by Disconnect B A.

Fig. 8. Terminating call screening.


Variables may be conceptually part of a featurebut we do not have any expectation that they willbe implemented (or not).

A condition next to an edge means that tocontinue an event sequence by following that edge,the condition must be true at the end of the event

sequence. C syntax is used in the conditions (� fornot, && for and, || for or).

We use two techniques to de®ne the value of avariable after an event. First, as part of a featurede®nition, we provide some rules about the valuesof the variables (to minimize the complexity of

Fig. 9. Three-way calling.


the diagram). Second, especially for variables in-troduced for the individual features, we includean assignment statement with an event to say thatthe variable takes on a new value after the event.The format of this is heventi=hvari hvaluei.

Consider the POTS diagram in Fig. 2. In thisPOTS diagram, we describe the values of severalvariables ± Busy A, Ringing A B, and Audible-

Ringing A B ± in rules in the ®gure label. Be-cause they are already de®ned in the rules, wedo not really need to set the values of anyvariables in this diagram, but for illustrationwe set the values for Busy B in nodes 4, 9, 10,and 14.

The POTS diagram represents only two tele-phones and a single call. To use a sequence todetermine all possible event sequences representing

Fig. 9. (Continued).


a single call, substitute all pairs of telephone ad-dresses for A and B (and any other symbols). Letus use O(a) to designate the set of all such se-quences with originating telephone a. Multiplecalls can be originated at a, so let U(a) be the set ofall sequences derived by concatenating any num-

ber of sequences of O(a) (U�a� � O�a��, the Kle-ene closure of O(A)). Then, to determine allpossible sequences of events in the network, wecan interleave the sets U(A), over all possible calloriginators A, in all ways allowed by the condi-tions on the edges.



4.2. Interpreting sequence diagrams for features

Each feature provides some modi®cation toPOTS, thereby rede®ning the subscribed servicefor that subscriber. We do not model service pro-visioning or activation, so if a subscriber has aservie, that service is always active.

The POTS diagram represents a single call,originated by party A. The feature diagrams rep-resent modi®cations to this POTS diagram ± sub-

diagrams that can be ``pasted'' into the POTSdiagram at given points. To specify where a featurecan be pasted in, we need to designate the node inthe POTS diagram and the relationship of thesymbols A and B in the POTS diagram to thesymbols used in the feature diagram. The desig-nation of a node in the POTS diagram looks like:POTS A X B Yn, meaning use node n fromthe POTS sequence diagram with X substituted forA and Y substituted for B. If either X or Y is

Fig. 10. IN call forwarding.


``any,'' then any telephone address is possiblethere.

A root feature node (i.e., a node with no par-ents) will be a child of a POTS node. The desig-nation of the POTS node goes above an arrow

leading into the node. If the feature node replacesone of the children of this POTS node, the desig-nation of that child goes inside the feature node.Otherwise, the feature node is an additional childof the POTS node.

Fig. 11. Call waiting.


A leaf feature node (i.e., a node with nochildren) will be a parent of one or more POTSnodes. The designation of each POTS node goesbelow an arrow leading out of the leaf featurenode.

For illustration, see Fig. 3, which is the se-quence diagram for Call Forwarding/Busy Line.Each sequence in the CFBL diagram starts with Adialing (i.e., it will follow a sequence in which thelast event was DialTone A) and ends with A and C

idle (i.e., both A and C are on-hook and neither isringing ± the next event, if taken from the POTSsequence diagram, would be an o�-hook or aringing event).

5. Variables

The following variables are used in the sequencediagrams:



Busy A: true between an O�-hook A event andthe next On-hook A event or between a StartRinging A event and the next Stop Ringing Aevent.

Other variables are:

Ringing A B: true between a Start Ringing Aevent immediately following a Dial B A event andthe next Stop Ringing A event.

AudibleRinging A B: true between a Start Au-dibleRinging A event immediately following a Dial



A B event and the next Stop AudibleRinging Aevent.

Note that Busy is true for a telephone if any ofthe other variables are. We also use Idle A to meanthat Busy A is not true.

Additional variables may be introduced by afeature. Most often, these ``variables'' de®ne fea-ture parameters (e.g., addresses of screened tele-phones or PINÕs for charging calls), and are ®xedfor each subscriber (but di�erent for di�erent



subscribers). For variables that change during acall, the convention is to describe how the variablebehaves with the unfeatured POTS service, interms of sequences of events (as above), and thento include changes in the value of the feature in thesequence diagram. For the above variables, to

keep the diagrams as simple as possible, we willnot usually show each change of value. However,if a feature a�ects the value of one of them (as CallWaiting and Three-Way Calling do the value ofBusy), the changes will be shown in the sequencediagram.



6. The phase 1 features

6.1. Call forwarding busy line

With the call forwarding busy line feature, allcalls to the subscribing line are redirected to apredetermined number when the line is busy.The subscriber pays any charges for the for-warded call from his station to the new desti-

nation. The subscriberÕs originating service is nota�ected.

See Fig. 3.

6.2. Calling number delivery

Calling number delivery (CND) is a feature thatallows the called telephone to receive a calling

Fig. 12. Charge call.


party's Directory Number (DN) and the date andtime. In the on-hook state, in a real network, thedelivery of this information occurs during the longsilent interval between the ®rst and second powerringing cycles.

For the purposes of the contest, we assume thecapability of delivering the number, and deliver itwhenever an idle called party receives the Ringingevent.

See Fig. 4.

6.3. IN freephone billing

The IN freephone feature allows the subscriberto pay for incoming calls. Call routing is normallypart of this feature, but we de®ne that in the nextfeature.

See Fig. 5.

Fig. 13. Return call.


6.4. IN freephone routing

The IN freephone feature allows the subscriberto redirect a call to various telephones, potentiallyusing the all or part of calling number and/or thetime of day.

See Fig. 6.

6.5. IN teen line

Teen line restricts outgoing calls based on thetime of day (i.e., hours when homework should bethe primary activity). This can be overridden on aper-call basis by anyone with the proper identitycode. We describe this as an IN feature.

See Fig. 7.

6.6. Terminating call screening

Terminating call screening (TCS) restricts in-coming calls. Calls from lines that appear on ascreening list are redirected to a vague but politemessage.

See Fig. 8.

6.7. Three-way calling

Three-way calling allows the connection ofthree parties in a single conversation.

See Fig. 9(a)±(c).

6.8. IN call forwarding

The call forwarding (CF) feature permits thesubscriber to have incoming calls redirected toanother number, no matter what the called partyline status is. The userÕs originating service is un-a�ected, even for charging. We describe this as anIN service.

See Fig. 10.

6.9. Call waiting

The call waiting (CW) feature allows the sub-scriber to be noti®ed that another party is trying toreach his number while her line is busy, and toaccept the new call by placing the original call onhold. Subsequently, the subscriber can switch backand forth between the calls.

See Fig. 11(a)±(e).



Fig. 14. Cellular.


6.10. Charge call

The charge call feature allows a caller to be au-tomatically charged on a di�erent telephone num-ber than the calling number. The feature is invokedby dialing a code (as de®ned in the sequence dia-gram, a pre®x ``0'' to the called telephone number.The caller is then prompted to dial the telephonenumber to be charged and a PIN. If the PIN iscorrect, the caller can proceed with the call.

See Fig. 12(a) and (b).

7. The phase 2 features

7.1. Return call

The return call feature allows a caller to returnan unanswered incoming call. After the incomingcall, the subscriber dials *69. If the (original)calling party is busy, the feature remains activeand retries until the calling party is alerted. Oncethe (original) calling party is successfully alerted,the feature is deactivated whether the call is com-pleted or not.

See Fig. 13(a) and (b).

7.2. Cellular

The cellular feature bills the subscriber for air-time on a cellular phone.

See Fig. 14.

Reference

[1] A. Aho, S. Gallagher, N. Gri�eth, C. Schell, D. Swayne,

SCF3(tm)/Sculptor with Chisel: requirements engineering.

for communications services, in: K. Kimbler, L.G. Bouma

(Eds.), Feature Interactions in Telecammunication and

Software System V, IOS Press, Amsterdam, 1998.

Nancy Gri�eth is a Member of Tech-nical Sta� at Bell Laboratories. She iscurrently building a test lab for third-party software developed for LucentNext Generation Networking prod-ucts, especially internet telephonyproducts. She has studied feature in-teractions in communications systemssince 1988. She was part of the orig-inal Bellcore e�ort to de®ne the fea-ture interaction problem, applyingintelligent agent technology to theproblem and helping to develop anearly benchmark list of feature inter-

actions. She was also instrumental in forming a world-widegroup of researchers and developers to address feature inter-actions. In addition, she was co-chair of the First and ThirdInternational Workshops on Feature Interactions and co-edi-tor of joint special issues of IEEE Computer and IEEECommunications on the feature interaction problem. She alsoworked on the design and development of the Touring Ma-chine platform for broadband services. In conjunction withher work on Touring Machine, she developed and subse-quently patented a negotiating mechanism based on the use ofagents to address multi-user feature interactions. In 1995, shewas chosen one of the Top 100 Women in Computing byMcGraw-Hill's Women in Computing Newsletter for herwork in feature interactions in telecommunications systems,distributed systems, and databases. She has published nu-merous papers on distributed systems and databases. She re-ceived her M.S. in 1972 and Ph.D. in 1978 from theUniversity of Chicago. She taught in the Kellogg School ofManagement from 1976±1979 and at Georgia Tech from1979±1987. She was a visiting associate professor at PrincetonUniversity in 1987±1988, an MTS at Bellcore from 1988±1997,and is now at Bell Labs.


feature interaction detection contest of the fifth international workshop on feature interactions

Documents