A feature interaction benchmark for the first feature interaction detection contest

A feature interaction benchmark for the ®rst featureinteraction detection contest

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

a Lucent Bell Laboratories, 101 Crawfords Corner Road, Holmdel, NJ 07733, USAb Daewoo Telecom, Middletown, NJ, USA

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

Abstract

The feature interaction problem is an inherently di�cult problem that a�ects the entire software life cycle for de-

velopment of new features for reactive systems. A considerable body of work has been created over the last 10 years

addressing this problem. To encourage testing and comparing di�erent approaches to the problem, a feature interaction

detection contest was held for the Fifth International Workshop on Feature Interactions in Telecommunications and

Software Systems. The contest required the participants to use automated tools to address the feature interaction

problem in the requirements phase of feature development. The participants were required to discover the pair-wise

feature interactions inherent in the requirements for a collection of features. This special issue of COMNET contains

the best papers from the participants in that contest. Although there could be only one winner of the contest, all of the

approaches represented here provide useful insight into how to approach the feature interaction problem as it a�ects the

requirements phase of feature development. We hope that subsequent contests will provide opportunities to re®ne these

approaches and to address other phases of feature development. Ó 2000 Published by 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 feature interaction problem is the mostdi�cult aspect of developing features for reac-tive systems, especially telecommunicationsswitching systems. We say that a feature in-

teraction occurs between two features if onefeatureÕs behavior changes when the secondfeature is active. This is not a problem in itself,but the potential occurrence of such interac-tions raises a sequence of inherently intractableproblems for feature development. A consider-able body of work has been created over thelast 10 years addressing the problem of e�-ciently developing new features for existingsystems [4,7,8,19].

The crux of the problem is that feature inter-actions consume huge amounts of time and re-

Computer Networks 32 (2000) 389±418

www.elsevier.com/locate/comnet

* Corresponding author.

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

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

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

sources at each phase of feature development. Inthe requirements phase, the feature requirementswriter must determine whether the individual fea-ture requirements are completely compatible, sothat no interaction occurs, or whether there is aninteraction that will occur in any implementationof those requirements. Then the requirementswriter must decide whether to allow a change inbehavior. Finally, she must describe what thecombined behavior should be. In the implemen-tation phase, the combined behavior must be im-plemented. Further, extraneous featureinteractions must not be introduced in the imple-mentation. In the testing phase, the behavior ofeach combination of features must be tested. Be-cause the number of combinations of features isexponential in the number of features, the featureinteraction problem refers to the growth of theproblem as the number of features grows. Devel-opment activities associated with feature interac-tions will apparently require exponentiallyincreasing time and resources. This is a signi®cantpractical problem, since switching systems likeLucentÕs 5ESS switching system can include morethan 3000 features. Many authors have proposedautomated approaches[1±3,5,9±18,20,21,23,24,27±31] for determining whether a feature interac-tion occurs between two features, but it has beendi�cult to compare di�erent approaches. First,authors have not used the same features, and thefeatures they have used have not been preciselyde®ned. Second, di�erent authors look at auto-mated detection of interactions in di�erent devel-opment phases.

The goal of the contest was to comparedi�erent feature interaction detection tools ac-cording to a single benchmark collection offeatures. The contest had two phases. In Phase1, 10 feature de®nitions were provided. Con-testants had ®ve months to convert the featurede®nitions to the languages of their tools and®nd the feature interactions. In Phase 2, twoadditional feature de®nitions were provided.The contestants had two weeks to ®nd the in-teractions between these two additional featuresand the original 10. The contest instructionsappear as a separate paper in this issue [14].We hope that subsequent contests will address

other parts of the problem ± for example, au-tomated validation of an implementation of aset of features against their feature interactionrequirements.

Section 2 of this paper de®nes the interactionsthat the committee used to judge the contest en-tries. A table summarizing the interactions be-tween the contest features appears in Section 2.1.In Section 2.3, we give detailed explanations ofthe interactions between the contest features, us-ing the format described in Section 2.2. In Section3, we present our conclusions from this ®rstcontest.

2. The contest interactions

In this section, we present the collection ofinteractions that the committee believed to occurbetween the de®ned contest features. These in-teractions are a crucial reference point for re-searchers wanting to understand the basis of thecontest and the remaining papers in this issue.Section 2.3 is of a daunting length. This length isrequired to de®ne precisely all the interactionsbetween the 66 pairs of features, most of whichhave multiple interactions. The reader will ®ndSection 2.3 necessary, at least as a reference, tounderstand the contest and the subsequent papersin this issue.

However, an even more important use of thissection will be for evaluating new approaches tothe feature interaction problem.

Many more interactions would arise than aredescribed here if we considered it an interac-tion when one feature changes the behaviorthat another feature inherits from plain oldtelephone service (POTS). We regard this kindof interaction as spurious, because it arisesfrom the change that the feature makes toPOTS rather than from its e�ect on the otherfeature. Saying that a feature A interacts withfeature B only because A changes POTS doesnot seem appropriate. As a consequence, we donot list any spurious interactions here. Thisproblem is also addressed by [15] elsewhere inthis journal.

390 N. Gri�eth et al. / Computer Networks 32 (2000) 389±418

2.2. Format of interaction description

This subsection de®nes the format used to de-scribe interactions. For each feature pair and in-teraction the following information is given:1. An English language description of the interac-

tion. This should be viewed only as a guide tointuition about the interaction, and a way of re-ferring to the interaction, but not as a de®nitivestatement as to the reason or the cause of theinteraction (instead, see the scenario, describedin point 3 below).

2. A table specifying for each participant the fea-ture assignments, roles, and initial status inthe following format:

3. A scenario (i.e., the sequence of events) that re-sults in the interaction. The scenario presentsthe incompatible event sequences that indicatethe presence of the interaction, and thus is thede®nitive statement of the nature of the interac-tion.

2.1. Summary table of interactions

This subsection contains a summary table of in-teractions between each pair of features. Eachentry in the table has the form x or x(y), where xrepresents the number of interactions and, if pre-sent, y represents interactions between real-worldanalogs of the features that are not interactionsbetween the contest features.

Most of the features de®ned for the contesthave real-world analogs, but naturally the featurede®nitions have been simpli®ed for the contest. Asa result, the feature interactions between contestfeatures are not always the same as those betweentheir real-world analogs. (We have used the Bell-core feature requirements [26] as our reference forthe `real-world analogs' of our features, althoughwe note that some implementations do not meetthese requirements. For brevity, we refer to fea-

tures ìn the network' when we mean features ac-cording to the Bellcore requirements.)

We include these interactions in the interactiondescriptions and in the table because they are quitewell-known. Thus we felt it important to describethem in the interaction catalog of section 2.3, evenwhile noting that they are not interactions in thecontest model.

The most frequently-arising di�erence betweenthe real-world feature interactions and those of themodel occur when call forwarding is involved andtwo features are trying to send the call to di�erentlines. This may not cause an interaction in the real-world features. In the contest model, each featureapplies to the entire call (both caller and callee andother legs if they are present). But most real-worldswitching software decomposes a call into two halfcalls: an originating half-call and a terminatinghalf-call. Features a�ect one half-call or the other.

N. Gri�eth et al. / Computer Networks 32 (2000) 389±418 391

4. Real world notes. This section may or may notbe present. If present, it contains comments onhow the features are usually implemented andhow the interaction is typically resolved. `Thenetwork' referenced here is the network mod-eled by the AIN and IN requirements for SSPÕs[25]. The feature interactions in this networkare those de®ned in the various Bellcore featureinteraction documents.The following conventions are used in the table

described in point 2 above:· Each row provides information about one par-

ticipant (i.e., a telephone and its user) which isidenti®ed by a letter (e.g., A, B, C, or D).

· The second column lists the features assigned tothe participant. None means that no feature is as-signed to that participant. The acronyms usedfor the features are listed below. Certain featuresrequire the identi®cation of another participant;these are indicated in parentheses following thefeature name. For example, CFBL (B) meansthat the CFBL feature is assigned and when theparticipant is busy calls are forwarded to B. Sim-ilarly, TCS (B) means that means that the TCSfeature assigned and B is in the screening list.

The role the participant has in the scenario may be:

The initial status of a participant may be:

· The status of a participant does not change un-less explicitly identi®ed in the scenario.

2.3. Descriptions of the interactions among thecontest features

This section contains descriptions of the indi-vidual interactions among the benchmark features.These are the interactions that the contestantswere trying to ®nd. While it is long, it provides anecessary reference to explain what are the featureinteractions among the contest features. The sub-sequent papers in this issue refer to some of theseinteractions.

2.3.1. Call forwarding-busy line interactions

2.3.1.1. CFBL and CFBL: no interactionsForwarding loop (not an interaction): This is not aninteraction in the contest model, but in othermodels it is an interaction [6]. Because it is in factone of the best known of all interactions, we ®nd itnecessary to explain why it is not an interaction inthis model. The important point is that the pres-ence of the CFBL feature at two lines, forwardingto each other, does not a�ect the behavior of thefeature. The Chisel feature de®nition requires theoriginator to receive LineBusyTone if the for-warding and the forwarded-to line are both busy.If the callee is forwarding to the originator, theoriginatorÕs line is obviously busy and hence willreceive LineBusyTone whether the originator hascall forwarding or not.1. There is no forwarding loop, because CFBL (as

de®ned for the contest) tests the forwarded-toline for busy, and returns LineBusyTone if itis busy.

2.

3. O�-hook A; DialTone A; Dial A B; [CFBL atparty A] LineBusyTone A.


4. In today's network, the call would be forward-ed with a counter. When the counter reaches athreshold, forwarding stops and ReorderToneis sent (a distinct, faster busy-like tone).

2.3.1.2. CFBL and CND: one interactionNumber not displayed:1. CFBL makes a connection to C without having

dialed C, so that a number is not displayed at C.2.

3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A C ||| Start Ringing C A . . .. Thissequence violates the CND requirement be-cause the `Start Ringing C A' event must be ac-companied by the `Display C A' event. Since`Dial A C' has not occurred the display eventis not triggered.

4. This interaction is resolved in today's networkbecause the CND display is triggered by an `ter-minate call' message, ignoring any forwardingthat may have occurred.

2.3.1.3. CFBL and INFB: two interactionsCall termination con¯ict:1. The features con¯ict because INFB expects to

give LineBusyTone when the line is busy butCFBL expects to forward the call.

2.

3. INFB: O�-hook A; DialTone A; Dial A B;LineBusyTone A con¯icts with CFBL: O�-hook A; DialTone A; Dial A B; Start Audibl-eRinging A B ||| Start Ringing B A.

Billing con¯ict:1. On forwarded calls, INFB billing does not occur.2.

3. CFBL: O�-hook A; DialTone A; Dial A B;Start AudibleRinging C A ||| Start Ringing AC; O�-hook C; Stop AudibleRinging C A |||Stop Ringing A C ||| LogBegin A B A Time |||LogBegin B C B Time con¯icts with INFB:O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging C A ||| Start Ringing A C; O�-hook C; Stop AudibleRinging C A ||| StopRinging A C ||| LogBegin A C C Time.

2.3.1.4. CFBL and INFR: three interactionsForwarding con¯ict:1. When B has both features, forwarding to di�er-

ent places, it must choose only one.2.

3. O�-hook A; DialTone A; Dial A B Con¯ict onevents `Start AudibleRinging A C' (CFBL) vs`Start AudibleRinging A D' (INFR).

4. This interaction is resolved in today's networkby giving routing features precedence over ter-minating features. IN routing features triggerin the originating half-call and CFBL occursin the terminating half-call. An interaction be-tween INFR and another originating featurewould be dealt with on a case-by-case basis.

Forwarding con¯ict:1. When B has CFBL and C has INFR, C's INFR

may over-ride B's forwarding to C.2.

3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A C ||| Start Ringing C A. . . Therequirements for INFR are violated, becauseCFBL requires ringing at C, whereas withINFR C never rings during the time that INFRis active.

4. This interaction is resolved in today's networkbecause CFBL places a `call' from B to C rather


than `connecting' directly to C. In the specialcase that D has the value `B' there is an interac-tion: looping occurs. The network protectsfrom this by having a special feature `limit onnumber of forwards'.

Forwarding con¯ict:1. When B has INFR and C has CFBL, C's CFBL

may over-ride B's routing to C.2.

3. O�-hook A; DialTone A; Dial A B; LineBusy-Tone A; . . . This sequence violates the CFBLrequirement

4. This interaction is resolved in today's networkbecause INFR routes the call to C rather than`connecting' directly to C. In the special casethat D has the value `B' there is an interaction:looping occurs. The network protects from thisby having a special feature `limit on number offorwards'.

2.3.1.5. CFBL and INTL: an interaction in thenetwork but not in the contest model1. The features do not con¯ict, because CFBL at

B simply connects to C; no call is originatedand INTL is not invoked.

2.

3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A C ||| Start Ringing C A.

4. In today's network, if a line has both INTLand CFBL, during teen `restricted' time all for-warded calls hit the INTL feature and areasked for a PIN. That is, there is an interac-tion because INTL applies to ìnitiated' callsand IN requirements say that any forwardedcall should hit all features that apply to newcalls.

2.3.1.6. CFBL and TCS: two interactionsCall termination con¯ict:1. CFBL at B expects to connect to C whereas

TCS at B would block the call and give an an-nouncement to A.

2.

3. O�-hook A; DialTone A; Dial A B Con¯ict onevents `Start AudibleRinging A C' (CFBL) vsÀnnounce A Screened Message' (TCS)

4. This interaction is resolved in today's networkby giving TCS precedence over CFBL. Thenonly screened calls get forwarded. TCS is mod-eled to occur in the Authorize Termination PICand CFBL in the T_Busy DP.

Call termination con¯ict:1. CFBL at B expects to connect to C whereas

TCS at C would block the call and give an an-nouncement to A.

2.

3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A C ||| Start Ringing C A Con¯icton events `Start AudibleRinging A C' (CFBL)vs Ànnounce A Screened Message' (TCS)

4. This interaction is resolved in part in today'snetwork because CFBL places a `call' from Bto C rather than `connecting' directly to C.However, TCS uses the Calling Party Number(B is this case) and not the Original Calling Par-ty Number (A in this case).

2.3.1.7. CFBL and TWC: four interactionsSignaling con¯ict:1. A TWC subscriber calls a busy CFBL subscrib-

er as a second leg. The reactions of the featuresto the `Flash' event con¯ict. TWC tries to con-nect the legs, CFBL interprets the Flash as adisconnect.


2.

3. Flash B; DialTone B; Dial B C; LineBusyToneB. This sequence violates the CFBL require-ments.

4. This interaction is resolved in part in today'snetwork because TWC places a `call' from Bto C rather than `connecting' directly to C.

Disconnect con¯ict:1. A TWC subscriber originates a call with a party

forwarded-to by CFBL, then ¯ashes to start athree-way call. If the TWC party disconnectswhile the ®rst leg is still on hold, the reactionsof the two features con¯ict. TWC gives specialringing to warn of the party on hold, but CFBLwould terminate the call.

2.

3. O�-hook A; DialTone A; Dial A B; Start Ring-ing C A ||| Start AudibleRinging A C; O�-hookC; Stop Ringing C A ||| Stop AudibleRinging AC ||| LogBegin A B A Time ||| LogBegin B C BTime; Flash A; DialTone A; Dial A D; StartRinging D A ||| Start AudibleRinging A D;On-hook A. At this point, TWC would givespecial ringing to A, since A left C on hold.However, CFBL interprets the on-hook as ter-minating the call. (The same interaction occursanytime from Flash A until O�-hook D).

4. This interaction is resolved in part in today'snetwork by giving TWC precedence over otherfeatures in processing a disconnect.

Disconnect con¯ict:1. A TWC subscriber is on a call with a party for-

warded-to by CFBL, then ¯ashes to start athree-way call, as above. If the disconnect oc-

curs after the ®rst and second legs are joined,there's a con¯ict on billing. Since TWC thinksthe call is continuing but CFBL thinks it hasterminated, the problem manifests itself initiallyas a disagreement on whether to log the termi-nation time for that leg of the call.

2.

3. O�-hook A; DialTone A; Dial A B; Start Ring-ing C A ||| Start AudibleRinging A C; O�-hookC; Stop Ringing C A ||| Stop AudibleRinging AC ||| LogBegin A B A Time ||| LogBegin B C BTime; Flash A; DialTone A; Dial A D; StartRinging D A ||| Start AudibleRinging A D;O�-hook D; Stop Ringing D A ||| Stop Audibl-eRinging A D ||| LogBegin A D A Time; FlashA; On-hook A. At this point, TWC will executeonly LogEnd A B and LogEnd A D but CFBLrequires also LogEnd B C.

Disconnect con¯ict:1. A CFBL subscriber forwards to a TWC sub-

scriber. TWC subscriber starts a three-way callbut leaves the ®rst leg on hold when disconnect-ing. This is the same as the second CFBL/TWCinteraction, above, except that the TWC sub-scriber is the terminating party to the ®rst legof the call rather than the originating party.

2.

3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A C ||| Start Ringing C A; O�-hook C; Flash C; DialTone C; Dial C D; Star-tRinging C D ||| Start Audible Ringing D C;O�-hook D; Stop Ringing D C ||| Stop AudibleRinging C D ||| LogBegin C D C Time; On-


hook C; Start Ringing C A 2. Con¯ict on events`Start Ringing C A 2' (TWC) vs `Disconnect AC' (CFBL).

2.3.1.8. CFBL and INCF: three interactionsForwarding con¯ict:1. When a party has both features, forwarding to

di�erent parties, it can choose only one.2.

3. O�-hook A; DialTone A; Dial A B Con¯ict onevents `Start AudibleRinging A C' (CFBL) vs`Start AudibleRinging A D' (INCF).

4. This interaction is resolved in today's networkby giving forward all call features (INCF) pre-cedence over features that activate only if theline is busy (CFBL). In IN, INCF is modeledto take place in the Authorize TerminationPIC and CFBL is modeled to take place inthe T_Busy DP.

Forwarding con¯ict:1. When B has CFBL and C has INCF, C's INCF


3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A C ||| Start Ringing C A. The re-quirements for INCF are violated, becauseCFBL requires ringing at C, whereas withINCF C never rings during the time that INCFis active.

4. This interaction is resolved in today's networkbecause the originating half-call redirects thecall from a terminating half-call at B to a termi-nating half-call at C. In the contest model, A

connects directly to C once the feature sees thatB is busy. In the special case that D has the val-ue `B' there is an interaction in the network aswell: looping occurs. The network protectsfrom this by having a special feature `limit onnumber of forwards.'

Forwarding con¯ict:1. When B has INCF and C has CFBL, C's CFBL


3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A C ||| Start Ringing C A This se-quence violates the CFBL requirement

4. This interaction is resolved in today's networkbecause INCF routes the call to C rather than`connecting' directly to C. In the special casethat D has the value `B' there is an interaction:looping occurs. The network protects from thisby having a special feature `limit on number offorwards'.

2.3.1.9. CFBL and CW: one interaction; also, aninteraction in the network but not in the contestmodelCall termination con¯ict (busy treatment):1. CFBL forwards the call, but CW accepts it.2.

3. CFBL: O�-hook A; DialTone A; Dial A B;Start AudibleRinging C A ||| Start Ringing AC con¯icts with CW: O�-hook A; DialToneA; Dial A B; Start AudibleRinging B A ||| StartRinging A B

4. In current networks, CFBL and CW ìnter-work' in the sense that (a) if B is busy talking


to D, then CW occurs; (b) if E calls B while acall is being waited or held at B, then E gets for-warded by CFBL to C. A ÔCall Waiting Deluxe'feature plays a voice message when A calls abusy subscriber B. The voice message providesthe calling number and gives B a choice of wait-ing it or forwarding it.

Feature inhibition (not an interaction):1. There are no events belonging to event sequenc-

es of C that would activate Call Waiting at C.2.

3. O�-hook A; DialTone A; Dial A B; LineBusy-Tone A

4. In current networks, Call Waiting would be ac-tivated at C when the call is routed to C.

2.3.1.10. CFBL and INCC: one interactionCall termination con¯ict (busy treatment):1. When INCC encounters busy, it gives Line-

BusyTone, but CFBL would forward the call.2.

3. O�-hook A; DialTone A; Dial A 0 + B; TriggerINFO_COLLECTED A A 0 + B Time; Re-sponse SEND_TO_RESOURCE A A Enter-PhoneNumber; Announce AEnterPhoneNumber; Dial A D; Resource AD; Response SEND_TO_RESOURCE A AEnterPIN; Announce A EnterPIN; Dial A P;Resource A P; Response ANALYZE_ROUTEA A B D; LineBusyTone A.

4. In current networks, CFBL and INCC do notcon¯ict. INCC is an originating feature, anddoes not a�ect the determination of whetherto give LineBusyTone or forward the call.

2.3.1.11. CFBL and RC: one interaction; also, aninteraction in the network but not in the contestmodelFeature fails to activate:1. The features con¯ict, because CFBL causes C

to ring without having dialed C so that an at-tempt by C to activate RC fails.

2.

3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A C ||| Start Ringing C A; On-hook A; Stop AudibleRinging A C ||| StopRinging C A; O�-hook C; DialTone C; DialC *69. This violates the RC requirement be-cause the `Start Ringing C A' event must bepreceded by the `Dial A C' event, but since `Di-al A C' has not occurred RC fails.

4. This interaction is resolved in today's networkbecause the RC feature considers a `terminatecall' message, ignoring any forwarding thatmay have occurred. There is also a related issue.Should the returned call be to A or B? This isresolved by having RC use the Calling PartyNumber and not the Redirecting Number.

Forwarding a returned call (not an interaction):1. The features do not con¯ict, because RC at B

connects to A only if A is idle. No call is orig-inated and CFBL is not invoked.

2.

3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A B ||| Start Ringing B A; On-hook A; Stop AudibleRinging A B ||| StopRinging B A; O�-hook A; O�-hook C; Dial-Tone C; Dial C *69.

4. In today's network, if RC places a call to A, thecall will be forwarded to C when A is busy. This


could lead to customer confusion since no oneat C called B. However, most implementationscheck the busy/idle status of A ®rst so thatthe forwarding only occurs if A becomes busyin the brief interval after the busy/idle statuscheck. Some implementations have feature spe-ci®c software that may prohibit RC from beingactivated if the target has a forwarding feature.

2.3.1.12. CFBL and CELL: two interactionsBilling con¯ict:1. CELL should start billing for airtime after A

dials B and C (the forward-to party) goes o�-hook, but that never happens.

2.

3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging C A ||| Start Ringing A C; O�-hook C; Stop AudibleRinging C A ||| StopRinging A C ||| LogBegin A B A Time ||| LogBe-gin B C B Time.

Billing con¯ict:1. CELL should start billing for airtime after A

dials B and C (the forwarded-to party) goeso�-hook, but it does not.

2.


Not an interaction:1. B's cellular feature is not invoked on this call,

since B neither originates nor terminates it.Since the cellular feature is never active, therecan be no interaction.

2.


4. In current networks, is a mobile phone billedairtime for forwarded calls? If so, I believe thisis an imposed interaction rather than a naturalone.

2.3.2. Calling number delivery interactions

2.3.2.1. CND and CND: no interactions

2.3.2.2. CND and INFB: no interactions

2.3.2.3. CND and INFR: two interactions

Call termination con¯ict (number display):1. If one party has both features, the possible se-

quences of events are incompatible.2.

3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A B ||| Start Ringing B A ||| Dis-play B A vs O�-hook A; DialTone A; Dial AB; Start AudibleRinging A C ||| Start RingingC A.

Call termination con¯ict (number display):1. If a forwarded-to party has Calling Number

Delivery, the originating number cannot be dis-played.


2.

3. The sequence of events begins O�-hook A;DialTone A; Dial A B; Start AudibleRingingA C ||| Start Ringing C A with no number dis-play.

2.3.2.4. CND and INTL: no interactions

2.3.2.5. CND and TCS: one interactionCall termination con¯ict (number display):1. If one party has both features, the possible se-


3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A B ||| Start Ringing B A ||| Dis-play B A vs O�-hook A; DialTone A; Dial AB; Announce A ScreeningAnnouncement.

2.3.2.6. CND and TWC: one interactionCall termination con¯ict (number display):1. The event sequence on a second call is not rec-

ognizable as a CND sequence.2.

3. [A and C are talking]; Flash A; Dialtone A; Di-al A B; Start AudibleRinging A B ||| Start Ring-ing B A; . . .

4. In current networks, both features will work to-gether. The call to B arrives as a connection

from A to B, just as a POTS call does, andhence CND works ®ne at B.

2.3.2.7. CND and INCF: two interactions (same asINFR)Call termination con¯ict (number display):1. If one party has both features, the possible se-


3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A B ||| Start Ringing B A ||| Dis-play B A vs O�-hook A; DialTone A; Dial AB; Start AudibleRinging A C ||| Start RingingC A.

Call termination con¯ict (number display):1. If a forwarded-to party has Calling Number

Delivery, the originating number cannot be dis-played.

2.

3. The sequence of events begins O�-hook A;DialTone A; Dial A B; Start AudibleRingingA C ||| Start Ringing C A with no number dis-play.

2.3.2.8. CND and CW: one interactionCall termination con¯ict:1. If one party has both features, Calling Number

Delivery expects a busy tone while Call Waitingrings the line without displaying the number.

2.


3. O�-hook A; DialTone A; Dial A B; LineBusy-Tone A vs O�-hook A; DialTone A; Dial A B;Start AudibleRinging A B ||| Start CallWaiting-Tone B A.

2.3.2.9. CND and INCC: one interactionCall termination con¯ict (number display):1. Failure to display number, because the dialed

number was 0 + B.2.

3. O�-hook A; DialTone A; Dial A 0 + B; TriggerINFO_COLLECTED A A 0 + B Time; Re-sponse SEND_TO_RESOURCE A A Enter-PhoneNumber; Announce A EnterPhoneNumber; Dial A C; Resource A C; ResponseSEND_TO_RESOURCE A A EnterPIN; An-nounce A EnterPIN; Dial A P; Resource A P;Response ANALYZE_ROUTE A A B C; StartAudibleRinging A B ||| Start Ringing B A |||LogBegin A B C Time.

2.3.2.10. CND and RC: one interactionCall termination con¯ict (number display):1. Failure to display number, because the dialed

number was *69.2.

3. [B has just called A] O�-hook A; DialTone A;Dial A *69; Start AudibleRinging A B ||| StartRinging B A.

2.3.2.11. CND and CELL: no interactions

2.3.3. Intelligent network-freephone billing interac-tions

2.3.3.1. INFB and INFB: no interactions

2.3.3.2. INFB and INFR: two interactionsCall termination con¯ict:1. When the called party has both features, the

billing feature will ring that party and bill thecalled party whereas the routing feature will billthe originator and ring a third party.

2.

3. O�-hook A; DialTone A; Dial A B Con¯ict onevents `Start AudibleRinging A B' (INFB) vs`Start AudibleRinging A C' (INFR).

4. These features do not occur separately in to-day's network.

Billing con¯ict:1. When B has INFR and C has INFB, no recog-

nizable event sequence for INFB occurs be-cause C is never dialed.

2.

3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A C ||| Start Ringing C A; O�-hook C; Stop AudibleRinging A C ||| StopRinging C A ||| LogBegin A B A ||| LogBeginB C B.

2.3.3.3. INFB and INTL: no interactions

2.3.3.4. INFB and TCS: one interactionCall termination con¯ict:1. When the called party has both features, the

billing feature will ring that party and bill theoriginator whereas the screening feature will re-ject the call.


2.

3. O�-hook A; DialTone A; Dial A B Con¯ict onevents `Start AudibleRinging A B' (INFB) vsÀnnounce A ScreeningAnnouncement' (TCS).

2.3.3.5. INFB and TWC: one interactionBilling con¯ict:1. Con¯icting billing commands when adding sec-

ond leg to call.

2.

3. INFB: [A is talking to C]; Flash A; DialTone A;Dial A B; Trigger INFO_ANALYZED B A BTime; Response ANALYZE_ROUTE B A BB; Start AudibleRinging A B ||| Start RingingB A; O�-hook B; Stop AudibleRinging A B |||Stop Ringing B A ||| LogBegin A B B Time con-¯icts with TWC: [A is talking to C]; Flash A;DialTone A; Dial A B; Start AudibleRingingA B ||| Start Ringing B A; O�-hook B; Stop Au-dibleRinging A B ||| Stop Ringing B A ||| LogBe-gin A B A Time.

4. In current networks, INFB will do the billingwhile TWC determines only the connection.

2.3.3.6. INFB and INCF: two interactionsCall termination con¯ict:1. When the called party has both features, the

billing feature alone would ring that party andbill the called party whereas the forwarding fea-ture alone would bill the originator and ring athird party.

2.

3. O�-hook A; DialTone A; Dial A B Con¯ict onevents `Start AudibleRinging A B' (INFB) vs`Start AudibleRinging A C' (INCF).

Billing con¯ict:

4. When B has INCF and C has INFB, no recog-nizable event sequence for INFB can occur be-cause C is never dialed.

5.

6. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A C ||| Start Ringing C A; O�-hook C; Stop AudibleRinging A C ||| StopRinging C A ||| LogBegin A B A ||| LogBeginB C B vs Stop AudibleRinging A C ||| StopRinging C A ||| LogBegin A C A.

2.3.3.7. INFB and CW: one interactionBilling con¯ict:1. Con¯icting billing commands when accepting

second call.2.

3. INFB: [A is talking to B]; O�-hook C; Dial-Tone C; Dial C B; Start AudibleRinging C B||| Start CallWaitingTone B C; Flash B; StopAudibleRinging C B ||| Stop CallWaitingToneB C ||| LogBegin C B B Time con¯icts with


CW: [A is talking to B]; O�-hook C; DialToneC; Dial C B; Start AudibleRinging C B ||| StartCallWaitingTone B C; Flash B; Stop AudibleR-inging C B ||| Stop CallWaitingTone B C ||| Log-Begin C B C Time.

4. In current networks, INFB will do the billingwhile CW determines only the connection.

2.3.3.8. INFB and INCC: one interactionBilling con¯ict:1. INFB cannot interpret the dialed number.2.

3. INCC: O�-hook A; DialTone A; Dial A0 + B; Trigger INFO_COLLECTED A A0 + B Time; Response SEND_TO_RE-SOURCE A A EnterPhoneNumber; An-nounce A EnterPhoneNumber; Dial A C;Resource A C; Response SEND_TO_RE-SOURCE A A EnterPIN; Announce A En-terPIN; Dial A P; Resource A P; ResponseANALYZE_ROUTE A A B C; Start Audibl-eRinging A B ||| Start Ringing B A; O�-hookB; Stop AudibleRinging A B ||| Stop RingingB A ||| LogBegin A B C Time. This event se-quence rings the phone at B without billing toB, a violation of INCC.

2.3.3.9. INFB and RC: one interactionCall termination con¯ict:1. If a Return Call subscriber calls an INFB

subscriber, INFB would give LineBusyTonewhen the called subscriber is busy whereasReturn Call will give the `Retry Return Call'message.

2.

3. [B has just called A, then made a second call];O�-hook A; Dial A *69; LineBusyTone A (forINFB) vs Announce A RetryReturnCall.

2.3.3.10. INFB and CELL: two interactionsBilling con¯ict:1. Cellular tries to bill normally, but INFB chang-

es the billing.2.

3. INFB: O�-hook A; DialTone A; Dial A B;Trigger INFO_ANALYZED B A B Time; Re-sponse ANALYZE_ROUTE B A B B; StartAudibleRinging A B ||| Start Ringing B A;O�-hook B; Stop AudibleRinging A B ||| StopRinging B A ||| LogBegin A B B Time con¯ictswith CELL: O�-hook A; DialTone A; Dial AB; Start AudibleRinging A B ||| Start RingingB A; O�-hook B; Stop AudibleRinging A B |||Stop Ringing B A ||| LogBegin A B A Time |||AirBegin A Time.

Billing con¯ict:1. Cellular tries to bill normally, but INFB changes

the billing.2.

3. INFB: O�-hook A; DialTone A; Dial A B;Trigger INFO_ANALYZED B A B Time; Re-sponse ANALYZE_ROUTE B A B B; StartAudibleRinging A B ||| Start Ringing B A;O�-hook B; Stop AudibleRinging A B ||| StopRinging B A ||| LogBegin A B B Time con¯ictswith CELL: O�-hook A; DialTone A; Dial AB; Start AudibleRinging A B ||| Start RingingB A; O�-hook B; Stop AudibleRinging A B |||Stop Ringing B A ||| LogBegin A B A Time |||AirBegin B Time.


2.3.4. Intelligent network-routing interactions

2.3.4.1. INFR and INFR: two interactionsForwarding con¯ict:1. INFR at B expects to connect to C whereas

INFR at C expects a connection to D.2.

3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A C ||| Start Ringing C A. The re-quirements for INFR are violated, becauseINFR at B requires ringing at C, whereas withINFR at C, C never rings during the time thatINFR is active.

4. This interaction is resolved in today's networkbecause INFR routes the `call' from B to Crather than `connecting' directly to C. In thespecial case that D has the value `B' there isan interaction: looping occurs. The networkprotects from this by having a special feature`limit on number of forwards.'

Forwarding con¯ict:1. Suppose B has two instances of INFR that ap-

ply at di�erent times. The features con¯ict, be-cause they both use the same trigger.

2.

3. O�-hook A; DialTone A; Dial A B; Trigger IN-FO_ANALYZED BA B Time. Both featuresuse the same trigger.

4. This interaction is resolved in today's networkbecause some implementations support triggerprecedence. A better way to do this would be

to have one trigger and to have the SCP pro-gram decide what happens at di�erent times.

2.3.4.2. INFR and INTL: no interactions

2.3.4.3. INFR and TCS: two interactionsCall termination con¯ict:1. INFR at B expects to connect to C whereas


2.

3. O�-hook A; DialTone A; Dial A B. Con¯ict onevents `Start AudibleRinging A C' (INFR) vsÀnnounce A Screened Message' (TCS).

4. This interaction is resolved in today's networkby giving all routing features precedence overterminating features. IN routing features trig-ger in the originating half-call and TCS occursin the terminating half-call.

Call termination con¯ict:1. INFR at B expects to connect to C whereas


2.

3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A C ||| Start Ringing C A. Con¯icton events `Start AudibleRinging A C' (INFR)vs Ànnounce A Screened Message' (TCS).

4. This interaction is resolved in part in today'snetwork because INFR places a `call' from Bto C rather than `connecting' directly to C.However, TCS uses the Calling Party Number(B is this case) and not the Original Calling Par-ty Number (A in this case).


2.3.4.4. INFR and TWC: three interactionsCall termination con¯ict:1. TWC expects a connection to B, whereas INFR

expects all calls to be routed to C.2.

3. [A and D are talking]: Flash A; DialTone A;Dial A B; Start Ringing C A ||| Start AudibleR-inging A C vs Start Ringing B A ||| Start Au-dibleRinging A B.

4. In the network, when TWC places a call to B,INFR reroutes the call to C.

Disconnect con¯ict:1. If a TWC subscriber leaves a call on hold,

INFR interprets the on-hook as disconnectingthe call, whereas TWC tries to ring the sub-scriber. This disagreement on whether the callis still active manifests itself initially as a billinginteraction.

2.

3. O�-hook A; DialTone A; Dial A B; StartRinging C A ||| Start AudibleRinging A C;O�-hook C; Stop Ringing C A ||| Stop Audibl-eRinging A C ||| LogBegin A B A Time ||| Log-Begin B C B Time; Flash A; DialTone A; DialA D; Start Ringing D A ||| Start AudibleRin-ging A D; On-hook A. At this point, TWCwould give special ringing to A, since A leftC on hold. However, INFR interprets theon-hook as terminating the call. (The same in-teraction occurs anytime from Flash A untilO�-hook D).

4. In the network, TWC gets precedence.

Disconnect con¯ict:1. If a TWC subscriber leaves a call on hold,

INFR interprets the on-hook as disconnectingthe call, whereas TWC tries to ring the sub-scriber.

2.

3. O�-hook A; DialTone A; Dial A B; Start Ring-ing C A ||| Start AudibleRinging A C; O�-hookC; Stop Ringing C A ||| Stop AudibleRinging AC ||| LogBegin A B A Time ||| LogBegin B C BTime; Flash A; DialTone A; Dial A D; StartRinging D A ||| Start AudibleRinging A D;O�-hook D; Stop Ringing D A ||| Stop Audibl-eRinging A D ||| LogBegin A D A Time; FlashA; On-hook A. At this point, TWC will only ex-ecute LogEnd A B and LogEnd A D. However,INFR requires also LogEnd B C.

2.3.4.5. INFR and INCF: three interactionsForwarding con¯ict:1. INFR at B should forward to C whereas INCF

at B should forward to D.2.

3. O�-hook A; DialTone A; Dial A B. Con¯ict onevents `Start AudibleRinging A C' (INFR) vs`Start AudibleRinging A D' (INCF).

4. This interaction is resolved in today's networkby giving all routing features precedence overterminating features. IN routing features trig-ger in the originating half-call and INCF occursin the terminating half-call.


Forwarding con¯ict:1. INFR at B expects to connect to C whereas

INCF at C expects a connection to D.

2.

3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A C ||| Start Ringing C A. The re-quirements for INCF are violated, becauseINFR requires ringing at C, whereas withINCF C never rings during the time that INCFis active.

4. This interaction is resolved in today's networkbecause INFR places a `call' from B to C ratherthan `connecting' directly to C. In the specialcase that D has the value `B' there is an interac-tion: looping occurs. The network protectsfrom this by having a special feature `limit onnumber of forwards.'

Forwarding con¯ict:1. INCF at B expects to connect to C whereas

INFR at C expects a connection to D.2.

3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A C ||| Start Ringing C A. This se-quence violates the INFR requirement.

4. This interaction is resolved in today's networkbecause INCF routes the call to C rather than`connecting' directly to C. In the special casethat D has the value `B' there is an interaction:looping occurs. The network protects from thisby having a special feature `limit on number offorwards.'

2.3.4.6. INFR and CW: one interactionCall termination con¯ict:1. INFR forwards the call, but CW accepts it.

2.

3. INFR: O�-hook A; DialTone A; Dial A B;Start AudibleRinging C A ||| Start Ringing AC. con¯icts with CW: O�-hook A; DialToneA; Dial A B; Start AudibleRinging B A ||| StartCallWaitingTone A B.

4. In current networks, routing features are givenpriority over terminating features.

2.3.4.7. INFR and INCC: two interactionsCall termination con¯ict:1. INCC expects a connection to B, whereas

INFR expects all calls to be routed to C. SinceINFR cannot interpret the dialed number, norouting can be performed.

2.

3. O�-hook A; DialTone A; Dial A 0 + B; StartRinging B A ||| Start AudibleRinging A B. Thisevent sequence causes B to ring, violatingINFR.

4. In the network, the call is sent to B's service,which routes it to C.

Call termination con¯ict:1. INCC expects a LineBusyTone, whereas INFR

expects all calls to be routed to C.

2.


3. O�-hook A; DialTone A; Dial A 0 + B; StartRinging C A ||| Start AudibleRinging A C vsLineBusyTone A B.


2.3.4.8. INFR and RC: two interactionsNumber delivery failure:1. INFR causes C to ring without having dialed C

so that an attempt by C to activate RC fails.2.

3. O�-hook A; DialTone A; Dial A B; StartAudibleRinging A C ||| Start Ringing C A;On-hook A; Stop AudibleRinging A C |||Stop Ringing C A; O�-hook C; DialToneC; Dial C *69. This violates the RC require-ment because the `Start Ringing C A' eventmust be preceded by the `Dial A C' event,but since `Dial A C' has not occurred RCfails.

4. This interaction is resolved in today's networkbecause the RC feature considers a `terminatecall' message, ignoring any routing that mayhave occurred. There is also a related issue.Should the returned call be to A or B? This isresolved by having RC use the Calling PartyNumber and not the Redirecting Number.

Termination con¯ict:1. RC would connect to A, but INFR would redi-

rect the call.

2.

3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A B ||| Start Ringing B A; On-

hook A; Stop AudibleRinging A B ||| StopRinging B A; O�-hook B; DialTone B; Dial B*69; Start Ringing A B ||| Start AudibleRingingB A vs Start Ringing C B ||| Start AudibleRin-ging B C.

4. In today's network, if RC places a call to A, thecall would be routed to C.

2.3.4.9. INFR and CELL: two interactionsBilling con¯ict:1. INFR will not charge airtime, whereas CELL

will charge the airtime.2.

3. O�-hook A; DialTone A; Dial A B; Start Ring-ing C A ||| Start AudibleRinging A C ; O�-hookC; Stop Ringing C A ||| Stop AudibleRinging AC ||| LogBegin A B A Time ||| LogBegin B C BTime vs. Stop Ringing C A ||| Stop AudibleRin-ging A C ||| LogBegin A B A Time ||| AirBegin ATime.

Billing con¯ict:1. INFR will not charge airtime, whereas CELL

will charge the airtime.

2.

3. O�-hook A; DialTone A; Dial A B; Start Ring-ing C A ||| Start AudibleRinging A C ; O�-hookC; Stop Ringing C A ||| Stop AudibleRinging AC ||| LogBegin A B A Time ||| LogBegin B C BTime vs. Stop Ringing C A ||| Stop AudibleRin-ging A C ||| LogBegin AC A Time ||| AirBegin CTime.

2.3.5. Intelligent network-teen line interactions

2.3.5.1. INTL and INTL: no interactions


2.3.5.2. INTL and TCS: no interactions

2.3.5.3. INTL and TWC: one interactionOver-ride PIN:1. When a TWC/INTL subscriber starts a second

TWC leg, TWC simply provides dialtone with-out asking for the PIN, while INTL asks for thePIN.

2.

3. [B has called A and they are talking]; Flash A;DialTone A; Dial A C; . . .

2.3.5.4. INTL and INCF: an interaction in thenetwork but not in the contest model1. The features do not con¯ict, because INCF at B

simply connects to C; no call is originated andINTL is not invoked.

2.

3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A C ||| Start Ringing C A.

4. In today's network, if a line has both INTL andINCF, during teen `restricted' time all forward-ed calls hit the INTL feature and are asked fora PIN. That is, there is an interaction becauseINTL applies to ìnitiated' calls and IN require-ments say that any forwarded call should hit allfeatures that apply to new calls.

2.3.5.5. INTL and CW: no interactions

2.3.5.6. INTL and INCC: one interactionPIN con¯ict:1. The features con¯ict on the requests for PINs.

2.

3. O�-hook A; Announce A AskForPIN; Dial AP is an unexpected sequence for INCC. Similar-ly, Ò�-hook A; Dial A 0 + B; Announce A En-terPhoneNumber; Dial A P' is an unexpectedsequence for INTL.

2.3.5.7. INTL and RC: one interaction; also, aninteraction in the network but not in the contestmodelPIN con¯ict:1. During teen `restricted time', the features con-

¯ict because RC at B expects to connect to Awhereas INTL at B would give an announce-ment to B and request a PIN.

2.

3. During teen `restricted time': O�-hook A; Dial-Tone A; Dial A B; Start AudibleRinging A B |||Start Ringing B A, On-hook A; O�-hook B,DialTone B; Dial B *69. Con¯ict on events`DialTone B' (RC) vs Ànnounce B AskFor-PIN' (INTL).

4. This interaction is resolved in part in today'snetwork because RC places a `call' from B toA rather than `connecting' directly to A. Whenthe call arrives at B, it will encounter the INTLfeature.

No restriction on incoming calls (not an interaction):1. The features do not con¯ict, because RC at

B connects to A and INTL at A is not in-voked.

2.


3. During teen `non-restricted time': O�-hook A;DialTone A; Dial A B; On-hook A; Later, dur-ing teen `restricted time': O�-hook B; DialToneB; Dial B *69.

4. In today's network, the RC call would be com-pleted. This violates the intention of INTL, thatduring teen `restricted time' calls from A to Bshould not be completed without a PIN.

2.3.5.8. INTL and CELL: no interactions

2.3.6. Terminating call screening interactions

2.3.6.1. TCS and TCS: no interactions

2.3.6.2. TCS and TWC: one interactionCall termination con¯ict:1. When a TWC subscriber calls a TCS subscriber

on the second call, TWC rings through, whileTCS screens the call.

2.

3. [A and B are talking]; Flash B; DialTone B; Di-al B C; ... At this point, TWC requires StartRinging C B ||| Start AudibleRinging B C whileTCS requires Announce B ScreenedMessage.

4. In the PSTN, a call is routed to C and thus isscreened.

2.3.6.3. TCS and INCF: two interactionsCall termination con¯ict:1. INCF at B expects to connect to C whereas


2.

3. O�-hook A; DialTone A; Dial A B. Con¯ict onevents Ànnounce A Screened Message' (TCS)vs `Start AudibleRinging A C' (INCF).

4. This interaction is resolved in today's networkby giving the Termination Attempt trigger pre-cedence over terminating features includingTCS that are modeled to occur in the AuthorizeTermination PIC.

Call termination con¯ict:1. INCF at B expects to connect to C whereas


2.

3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A C ||| Start Ringing C A. This vi-olates the TCS requirement `StartAudibleRinging A C' (INCF) vs Ànnounce AScreened Message' (TCS).

4. This interaction is resolved in part in today'snetwork because INCF places a `call' from Bto C rather than `connecting' directly to C.However, TCS uses the Calling Party Number(B is this case) and not the Original Calling Par-ty Number (A in this case).

2.3.6.4. TCS and CW: one interactionCall termination con¯ict:1. When a second call is placed to a busy subscrib-

er to CW and TCS, the two features di�er onthe handling of the call.

2.

3. [A and B are talking]; O�-hook C; DialTone C;Dial C B;. . . At this point, CW requires Start


CallWaitingTone B C ||| Start AudibleRingingC B while TCS requires Announce C Screened-Message.

4. In the PSTN, a call is routed to B and thus isscreened.

2.3.6.5. TCS and INCC: one interactionCall termination con¯ict:1. INCC expects a connection to B, whereas a

connection is made to B without checking thecaller since TCS does not recognize Dial A0 + B.

2.

3. O�-hook A; DialTone A; Dial A 0 + B; StartRinging B A ||| Start AudibleRinging A B isnot a valid event sequence for TCS.

4. In the network, a `send call' message invokesTCS on the terminating line.

2.3.6.6. TCS and RC: one interactionCall termination con¯ict:1. RC at B connects to A whereas TCS at A

would block the call and give an announce-ment to B.

2.

3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A B ||| Start Ringing B A; On-hook A; O�-hook B, DialTone B; Dial B *69.Con¯ict on events `Start AudibleRinging B A'(RC) vs Ànnounce A Screened Message'(TCS).

4. This interaction is resolved in part in today'snetwork because RC places a `call' from B toA rather than `connecting' directly to A.

2.3.6.7. TCS and CELL: no interactions

2.3.7. Three-way calling interactions

2.3.7.1. TWC and TWC: one interactionDisconnect con¯ict:1. If a TWC subscriber leaves a second party on

hold, and that party is also a TWC subscriberthat has the ®rst party on hold, the ®rst partywill be rung back while the second party consid-ers itself disconnected.

2.

3. [A and B are talking]: Flash A; DialTone A;Flash B; DialTone B; On-hook A. A's TWCwill result in Start Ringing B A 2 whereas B'sTWC delivers Disconnect B A.

2.3.7.2. TWC and INCF: three interactionsCall termination con¯ict:1. TWC expects a connection to the dialed party,

whereas INCF expects all calls to be routed tothe forwarded party.

2.

3. [A and D are talking]: Flash A; DialTone A;Dial A B; Start Ringing C A ||| Start AudibleR-inging A C vs Start Ringing B A ||| Start Au-dibleRinging A B.

4. In the network, TWC places a call to B. Thiscall is routed to C by INCF.

Disconnect con¯ict:1. If a TWC subscriber leaves a forwarded-to par-

ty (the ®rst leg of the three-way call) on hold,


TWC will ringback whereas INCF interpretsthe on-hook as a disconnect.

2.

3. O�-hook A; DialTone A; Dial A B; Start Ring-ing C A ||| Start AudibleRinging A C; O�-hookC; Stop Ringing C A ||| Stop AudibleRinging AC ||| LogBegin A B A Time ||| LogBegin B C BTime; Flash A; DialTone A; Dial A D; StartRinging D A ||| Start AudibleRinging A D;On-hook A. At this point, TWC would givespecial ringing to A, since A left C on hold;but INCF interprets the on-hook as terminat-ing the call. (The same interaction occurs any-time from Flash A until O�-hook D).

4. In the network, TWC gets precedence.

Disconnect con¯ict:1. If a TWC subscriber leaves a forwarded-to par-

ty (the second leg of the three-way call) on hold,TWC will ringback whereas INCF interpretsthe on-hook as a disconnect. This disagreementon whether the call is still active manifests itselfinitially as a billing interaction.

2.

3. O�-hook A; DialTone A; Dial A B; Start Ring-ing C A ||| Start AudibleRinging A C; O�-hookC; Stop Ringing C A ||| Stop AudibleRinging AC ||| LogBegin A B A Time ||| LogBegin B C BTime; Flash A; DialTone A; Dial A D; StartRinging D A ||| Start AudibleRinging A D;O�-hook D; Stop Ringing D A ||| Stop Audibl-eRinging A D ||| LogBegin A D A Time; FlashA; On-hook A. At this point, TWC will only ex-ecute LogEnd A B and LogEnd A D but INCFrequires also LogEnd B C.

2.3.7.3. TWC and CW: nine interactionsFlash con¯ict:1. Three-Way Calling subscriber B is involved in a

call when a second call is made to B. If B alsosubscribes to Call-Waiting, there is a con¯ictbetween the features on what can happen afterthe `Flash B' event.

2.

3. TWC: O�-hook A; DialTone A; Dial A B; StartAudibleRinging A B ||| Start CallWaitingToneB A; Flash B; DialTone B (note that sinceTWC has not been activated when the call ar-rives, the CW behavior is used) con¯icts withCW: O�-hook A; DialTone A; Dial A B; StartAudibleRinging A B ||| Start CallWaitingToneB A; Flash B; Stop CallWaitingTone B ||| StopAudibleRinging A B ||| LogBegin A B A Time.

4. In current networks, Call-Waiting gets prece-dence after the call-waiting tone.

Disconnect con¯ict:1. If B has a second leg with C, not yet joined

when A calls, then when B goes onhook, whois involved in the special ringing?

2.

3. TWC: [B is talking on a two-party call withD]; Flash B; DialTone B; Dial B C; Start Au-dibleRinging B C ||| Start Ringing C B; O�-hook C; Stop AudibleRinging B C ||| StopRinging C B ||| LogBegin B C B; O�-hook A;DialTone A; Dial A B; Start AudibleRingingA B ||| Start CallWaitingTone B A; On-hookB; Start Ringing B D 2 con¯icts with CW: [Bis talking on a two-party call with D]; Flash


B; DialTone B; Dial B C; Start AudibleRin-ging B C ||| Start Ringing C B; O�-hook C;Stop AudibleRinging B C ||| Stop Ringing CB ||| LogBegin B C B; O�-hook A; DialToneA; Dial A B; Start AudibleRinging A B |||Start CallWaitingTone B A; On-hook B; StartRinging B A 2.

4. In current networks, Call Waiting is disabledwhile a three-way call is active.

Flash con¯ict:1. If B has a second leg, with C, not yet joined

when A calls, then what is the meaning of`Flash B'? It could be either drop the secondleg or make the call with A active.

2.

3. TWC: [B is talking on a two-party call withD]; Flash B; DialTone B; Dial B C; Start Au-dibleRinging B C ||| Start Ringing C B; O�-hook C; Stop AudibleRinging B C ||| StopRinging C B ||| LogBegin B C B; O�-hook A;DialTone A; Dial A B; Start AudibleRingingA B ||| Start CallWaitingTone B A; Flash B;Disconnect C B ||| LogEnd B C con¯icts withCW: [B is talking on a two-party call withD]; Flash B; DialTone B; Dial B C; Start Au-dibleRinging B C ||| Start Ringing C B; O�-hook C; Stop AudibleRinging B C ||| StopRinging C B ||| LogBegin B C B; O�-hook A;DialTone A; Dial A B; Start AudibleRingingA B ||| Start CallWaitingTone B A; Flash B;Stop AudibleRinging A B ||| Stop CallWaiting-Tone B A ||| LogBegin A B A Time.

4. In current networks, Call Waiting is disabledwhile a three-way call is in progress.

Call termination con¯ict:1. Con¯icting signals: Call Waiting requires Call-

WaitingTone, Three-Way Calling requiresbusy.

2.

3. TWC: [A and C are talking]; Flash A; DialToneA; Dial A B; LineBusyTone A con¯icts withCW: [A and C are talking]; Flash A; DialToneA; Dial A B; Start AudibleRinging A B ||| StartCallWaitingTone B A.

4. In current networks, Call Waiting will handlethe terminating signaling.

Disconnect con¯ict:1. Held party thinks call has been disconnected

when holding party goes on-hook.2.

3. TWC: [A and B are talking]; Flash A; DialToneA; O�-hook C; DialTone C; Dial C B; StartAudibleRinging C B ||| Start CallWaitingToneB C; On-hook A; Start Ringing A B 2 con¯ictswith CW: [A and B are talking]; Flash A; Dial-Tone A; O�-hook C; DialTone C; Dial C B;Start AudibleRinging C B ||| Start CallWaiting-Tone B C; On-hook A; Disconnect B A.

4. In current networks, Three-Way Calling willcontrol A's end of the call, and B will be un-aware of any activity while A's telephone getsspecial ringing.

Disconnect con¯ict:1. Held party thinks call has been disconnected

when holding party goes on-hook.2.

3. TWC: [A and B are talking]; O�-hook C; Dial-Tone C; Dial C B; Start AudibleRinging C B |||


Start CallWaitingTone B C; Flash B; On-hookB; Disconnect A B con¯icts with CW: [A and Bare talking]; O�-hook C; DialTone C; Dial C B;Start AudibleRinging C B ||| Start CallWaiting-Tone B C; Flash B; On-hook B; Start Ringing BA 2.

4. In current networks, Call Waiting will controlthe ringing at B and A will not be aware ofany activity.

Flash con¯ict:1. Call Waiting does not recognize the Flash event

as terminating the second leg of a three-waycall.

2.

3. TWC: [A and C are talking]: Flash A; DialToneA; Dial A B; Start AudibleRinging A B ||| StartRinging B A; O�-hook B; Stop AudibleRingingA B ||| Stop Ringing B A ||| LogBegin A B ATime; O�-hook D; DialTone D; Dial D B; StartAudibleRinging D B ||| Start CallWaitingToneB D; Flash A; Disconnect B A ||| LogEnd A Bcon¯icts with CW: [A and C are talking]: FlashA; DialTone A; Dial A B; Start AudibleRin-ging A B ||| Start Ringing B A; O�-hook B; StopAudibleRinging A B ||| Stop Ringing B A |||LogBegin A B A Time; O�-hook D; DialToneD; Dial D B; Start AudibleRinging D B ||| StartCallWaitingTone B D; Flash A; Flash B;Flash B.

4. In current networks, the Flash from A will ter-minate the call and the Call-Waiting Flash fromB would give DialTone (behaving as On-hookfollowed by O�-hook, once there is no heldparty).

Flash con¯ict:1. Call Waiting does not recognize the Flash event

as terminating the second leg of a three-waycall.

2.

3. TWC: [A and D are talking, B and C are talk-ing]: Flash A; DialTone A; Dial A B; Start Au-dibleRinging A B ||| Start CallWaitingTone BA; Flash A; Disconnect B A ||| LogEnd A Bcon¯icts with CW: [A and D are talking, Band C are talking]: Flash A; DialTone A; DialA B; Start AudibleRinging A B ||| Start CallWa-itingTone B A; Flash A; Flash B; Flash B.

4. In current networks, the Flash from A will ter-minate the call and the Call-Waiting Flash fromB would give DialTone (behaving as On-hookfollowed by O�-hook, once there is no held par-ty).

Disconnect con¯ict:1. Di�erent interpretations of on-hook.2.

3. CW: [A is talking to B]: Flash A; DialTone A;Dial A C; Start AudibleRinging A C ||| StartRinging C A; O�-hook C; Stop AudibleRingingA C ||| Stop Ringing C A ||| LogBegin A C ATime; O�-hook D; DialTone D; Dial D B; StartAudibleRinging D B ||| Start CallWaitingToneB D; Flash B; On-hook B; Start Ringing B A2 con¯icts with TWC: [A is talking to B]: FlashA; DialTone A; Dial A C; Start AudibleRin-ging A C ||| Start Ringing C A; O�-hook C;Stop AudibleRinging A C ||| Stop Ringing CA ||| LogBegin A C A Time; O�-hook D; Dial-Tone D; Dial D B; Start AudibleRinging D B |||Start CallWaitingTone B D; Flash B; On-hookB; Disconnect A B.


4. In current networks, special ringing will beapplied at B and no disconnect will be gener-ated.

2.3.7.4. TWC and INCC: two interactionsPIN con¯ict:1. When A tries to call B, TWC does not recognize

the phone number, whereas INCC asks for aPhone Number and PIN.

2.

3. O�-hook A; DialTone A; Dial A 0 + B is not avalid event sequence for TWC.

PIN con¯ict:1. The ®rst call is a call from A to B. When B tries

to add a party to the call, the event sequence forINCC is not valid for TWC because of the di-aled number.

2.

3. [A and B are talking]: `Flash B; DialTone B; Di-al B 0 + C; Announce B EnterPhoneNumber' isnot a valid event sequence for TWC.

2.3.7.5. TWC and RC: one interactionFeature inhibition:1. A cannot use Return Call to call C on the sec-

ond leg of the Three-Way call.2.

3. [A and B are talking]; `Flash A; Dial *69; StartRinging C A ||| Start AudibleRinging A C' isnot a valid event sequence for TWC.

2.3.7.6. TWC and CELL: four interactionsBilling con¯ict:1. When A tries to add second leg to C, airtime is

not charged to A.2.

3. [A and B are talking]; Flash A; DialTone A; Di-al A C; Start Ringing C A ||| Start AudibleRin-ging A C; O�-hook C; Stop Ringing C A ||| StopAudibleRinging A C ||| LogBegin A C A Time(no AirBegin A Time).

Billing con¯ict:1. When A tries to add second leg to C, airtime is

not charged to C.2.

3. [A and B are talking]; Flash A; DialTone A; Di-al A C; Start Ringing C A ||| Start AudibleRin-ging A C; O�-hook C; Stop Ringing C A ||| StopAudibleRinging A C ||| LogBegin A C A Time(no AirBegin C Time).

Billing con¯ict:1. When A tries to drop second leg to C, airtime is

not terminated for A.2.

3. [A has conference to B and C]; Flash A; Dis-connect C A; LogEnd A C Time (no AirEndA Time).


Billing con¯ict:1. When A tries to drop second leg to C, airtime is

not terminated for C.2.

3. [A has conference to B and C]; Flash A; Dis-connect C A; LogEnd A C Time (no AirEndC Time).

2.3.8. Intelligent network-call forwarding interac-tions

2.3.8.1. INCF and INCF: one interaction.Forwarding con¯ict:1. INCF at B expects to connect to C whereas

INCF at C expects a connection to D.2.

3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A C ||| Start Ringing C A. The re-quirements for INCF are violated, becauseINCF at B requires ringing at C, whereas withINCF at C, C never rings during the time thatINCF is active.

4. This interaction is resolved in today's networkbecause INCF places a `call' from B to C ratherthan `connecting' directly to C. In the specialcase that D has the value `B' there is an interac-tion: looping occurs. The network protectsfrom this by having a special feature `limit onnumber of forwards.'

2.3.8.2. INCF and CW: one interactionCall termination con¯ict:1. INCF forwards the call, but CW accepts it.

2.

3. INCF: O�-hook A; DialTone A; Dial A B;Start AudibleRinging C A ||| Start Ringing AC con¯icts with CW: O�-hook A; DialToneA; Dial A B; Start AudibleRinging B A ||| StartCallWaitingTone A B.

2.3.8.3. INCF and INCC: one interactionCall termination con¯ict:1. `Dial A 0 + B' in the INCC event sequence does

not contain a number recognizable by INCF.2.

3. Ò�-hook A; DialTone A; Dial A 0 + B; StartRinging B A ||| Start AudibleRinging A B' isnot a valid event sequence for INCF.


2.3.8.4. INCF and RC: two interactionsNumber delivery failure:1. INCF causes C to ring without having dialed C

so that an attempt by C to activate RC fails.

2.

3. This interaction is resolved in today's net-work because the RC feature considers a `ter-minate call' message, ignoring any routingthat may have occurred. There is also a relat-


ed issue. Should the returned call be to A orB? This is resolved by having RC use theCalling Party Number and not the Redirect-ing Number.

Termination con¯ict:1. RC would connect to A, but INCF would redi-

rect the call.

2.

3. O�-hook A; DialTone A; Dial A B; Start Au-dibleRinging A B ||| Start Ringing B A; On-hook A; Stop AudibleRinging A B ||| StopRinging B A; O�-hook C; DialTone C; DialC *69.

4. In today's network, if RC places a call to A, thecall will be forwarded to C. This could lead tocustomer confusion since no one at C calledB. Some implementations have feature speci®csoftware that may prohibit RC from being acti-vated if the target has a forwarding feature.However, this generally does not apply to INforwarding features.

2.3.8.5. INCF and CELL: two interactionsBilling con¯ict:1. When a cellular subscriber calls an INCF sub-

scriber, there is a con¯ict between INCF andCELL on billing.

2.

3. O�-hook A; DialTone A; Dial A B; Start Ring-ing C A ||| Start AudibleRinging A C ; O�-hookC; Stop Ringing C A ||| Stop AudibleRinging A

C ||| LogBegin A B A Time ||| LogBegin B C BTime vs Stop Ringing C A ||| Stop AudibleRin-ging A C ||| LogBegin A B A Time ||| AirBegin ATime.

Billing con¯ict:1. When an INCF subscriber forwards calls to a

cellular subscriber, there is a con¯ict betweenthe features on billing.

2.

3. O�-hook A; DialTone A; Dial A B; Start Ring-ing C A ||| Start AudibleRinging A C ; O�-hookC; Stop Ringing C A ||| Stop AudibleRinging AC ||| LogBegin A B A Time ||| LogBegin B C BTime vs. Stop Ringing C A ||| Stop AudibleRin-ging A C ||| LogBegin B C B Time ||| AirBegin CTime.

2.3.9. Call waiting interactions

2.3.9.1. CW and CW: no interactions

2.3.9.2. CW and INCC: one interaction

Billing con¯ict:1. When a charge call subscriber calls a busy

call-waiting subscriber, call waiting wouldnot recognize the dialed number; as a result,no action occurs at B and A receives Line-BusyTone.

2.

3. INCC: [B is talking]; O�-hook A; DialTone A;Dial A 0 + B does not belong to any valid CallWaiting sequence, so that the continuation is togive LineBusyTone A.

4. In current networks, the originating featurecontrols charging but the terminating feature


controls the signaling at the terminating end.As a consequence, the call will be billedto D.

2.3.9.3. CW and RC: no interactions

2.3.9.4. CW and CELL: three interactionsBilling con¯ict:1. Airtime charging is not initiated when a call is

accepted with a Flash event.2.

3. [B is talking]; O�-hook A; DialTone A; Dial AB; Start AudibleRinging A B ||| Start CallWait-ingTone B A; Flash B; Stop AudibleRinging AB ||| Stop CallWaitingTone B A ||| LogBegin AB A Time. Part of the sequence including air-time is present, but not all.

Billing con¯ict:1. Airtime charging is not initiated on Flash to an-

swer call.2.

3. CW: [A is talking to C]; O�-hook B; DialToneB; Dial A B; Start CallWaitingTone A B; StartAudibleRinging B A; Flash A; Stop CallWait-ingTone A B || Stop AudibleRinging B A || Log-Begin A B A time; . . .

Billing con¯ict:1. Airtime billing on the ®rst call is not terminated

when the ®rst call is terminated before the sec-ond one, and is not initiated on the second callwhen answering the special ringing.

2.

3. [B is talking to C]; O�-hook A; DialTone A; Di-al A B; Start AudibleRinging A B ||| Start Call-WaitingTone B A; On-hook C; Disconnect B C||| LogEnd B C Time; On-hook B; Start RingingB 2; O�-hook B; Stop Ringing B 2 ||| LogBeginB A B Time.

2.3.10. Intelligent network-charge call interactions

2.3.10.1. INCC and INCC: no interactions

2.3.10.2. INCC and RC: one interactionFeature inhibition:1. RC cannot return a call initiated with INCC.2.

3. O�-hook A; DialTone A; Dial A 0 + B does notbelong to any valid RC event sequence.

2.3.10.3. INCC and CELL: no interactions

2.3.11. Return call interactions

2.3.11.1. RC and RC: no interactions

2.3.11.2. RC and CELL: no interactions

2.3.12. Cellular interactions

2.3.12.1. CELL and CELL: no interactions

3. Conclusions and future work

The contest submissions led the committee toseveral conclusions:· The results from di�erent tools using di�erent

de®nitions of feature interaction were surpris-ingly similar. We believe this was because eachcontestant used the same de®nition of the fea-tures and the same level of detail. This veri®esthe utility of having a standard, precise bench-mark of features.


· Di�erences among the contestants appeared tobe due to the choice of scenarios to analyzeand interpretation of the requirements. Choos-ing the right scenarios to test for feature interac-tions is an important part of solving the featureinteraction problem. This is a hard problem insystem testing [22].

· The model used for the contest was a simpli®ca-tion of real world networks in many respects.While this is necessary in any model, we con-cluded that the model over-simpli®ed by usinga `full-call' rather than a `half-call' model andomitting the message sending a call from theoriginating to the terminating side [25]. This in-troduced a number of feature interactions thatdo not occur in real networks. There are also in-teractions that occur in real-world networks thatdid not occur in the model. We include descrip-tions of these, labeled as `non-interaction' or`not an interaction', below.Future benchmarks should be based on a half-

call model, such as de®ned in [25]. This model istoo complicated to be used for comparisons ofresearch tools, but even a simpli®cation of thatmodel could provide a test of the tools against amuch more realistic network model. Also, futurework on benchmarking should address how fea-ture interactions a�ect other phases of the featurelife cycle.

References

[1] P.K. Au, J. Atlee, Evaluation of a state-based model of

feature interactions, in: P. Dini, R. Boutaba, L. Logrippo

(Eds.), Feature Interactions in Telecommunications Net-

works IV, IOS Press, Amsterdam, 1997.

[2] J.W. Bergstra, L. Bouma, Models for feature descriptions

and interactions, in: P. Dini, R. Boutaba, L. Logrippo

(Eds.), Feature Interactions in Telecommunications Net-

works IV, IOS Press, Amsterdam, 1997.

[3] J. Blom, R. Bol, L. Kempe, Automatic detection of feature

interactions in temporal logic, in: K. Cheng, T. Ohta

(Eds.), Feature Interactions in Telecommunications III,

IOS Press, Amsterdam, 1995.

[4] L.G. Bouma, H. Velthuijsen (Eds.), Feature Interactions in

Telecommunications Systems, IOS Press, Amsterdam,

1994.

[5] K. Braithwaite, J. Atlee, Towards automated detection of

feature interactions, in: L. Bouma, H. Velthuijsen (Eds.),

Feature Interactions in Telecommunications Systems, IOS

Press, Amsterdam, 1994.

[6] E. Cameron, N. Gri�eth, Y.-J. Lin, M. Nilson, W. Shnure,

A feature interaction benchmark for IN and beyond, in: L.

Bouma, H. Velthuijsen (Eds.), Feature Interactions in

Telecommunications Systems, IOS Press, Amsterdam,

1994.

[7] K. Cheng, T. Ohta (Eds.), Feature Interactions in Tele-

communications III, IOS Press, Amsterdam, 1995.

[8] P. Dini, R. Boutaba, L. Logrippo (Eds.), Feature Interac-

tions in Telecommunications Networks IV, IOS Press,

Amsterdam, 1997.

[9] R. Dssouli, S. Some, J.-W. Guillery, N. Rico, Detection

of feature interactions with REST, in: P. Dini, R.

Boutaba, L. Logrippo (Eds.), Feature Interactions in

Telecommunications Networks IV, IOS Press, Amster-

dam, 1997.

[10] L. du Bousquet, F. Ouabdesselam, J.-L. Richier, N.

Zuanon, Incremental feature validation: a synchronous

point of view, in: K. Kimber, L. Bouma (Eds.), Feature

Interactions in Telecommunications and Software Systems

V, IOS Press, Amsterdam, 1998.

[11] M. Faci, L. Logrippo, Specifying features and analysing

their interactions in a LOTOS environment, in: L. Bouma,

H. Velthuijsen (Eds.), Feature Interactions in Telecommu-

nications Systems, IOS Press, Amsterdam, 1994.

[12] M. Frappier, A. Mili, J. Desharnais, Detecting feature

interactions on relational speci®cations, in: P. Dini, R.

Boutaba, L. Logrippo (Eds.), Feature Interactions in

Telecommunications Networks IV, IOS Press, Amsterdam,

1997.

[13] J. Gibson, Towards a feature interaction algebra, in: K.

Kimber, L. Bouma (Eds.), Feature Interactions in Tele-

communications and Software Systems V, IOS Press,

Amsterdam, 1998.

[14] N. Gri�eth, R. Blumenthal, J.-C. Gregoire, T. Ohta,

Feature interaction detection contest of the 5th Interna-

tional Workshop on Feature Interactions, Comput. Net-

works 32 (2000) 487±510.

[15] R. Hall, Feature combination and interaction detection via

foreground/background models, in: K. Kimber, L. Bouma

(Eds.), Feature Interactions in Telecommunications and

Software Systems V, IOS Press, Amsterdam, 1998.

[16] J. Kamoun, L. Logrippo, Goal-oriented feature interaction

detection in the Intelligent Network model, in: K. Kimber,

L. Bouma (Eds.), Feature Interactions in Telecommunica-

tions and Software Systems V, IOS Press, Amsterdam,

1998.

[17] Y. Kawarasaki, T. Ohta, A new proposal for feature

interaction detection and elimination, in: K. Cheng, T.

Ohta (Eds.), Feature Interactions in Telecommunications

III, IOS Press, Amsterdam, 1995.

[18] A. Khoumsi, Detection and resolution of interactions

between services of telephone networks, in: P. Dini, R.

Boutaba, L. Logrippo (Eds.), Feature Interactions in Tele-

communications Networks IV, IOS Press, Amsterdam, 1997.

[19] K. Kimbler, L.G. Bouma (Eds.), Feature Interactions in

Telecommunications and Software Systems V, IOS Press,

Amsterdam, 1998.


[20] T. Laporta, D. Lee, Y.-J. Lin, M. Yannakakis,

Protocol feature interactions, Proceedings FORTE/

PSTV, 1998.

[21] F.J. Lin, Y.-J. Lin, A building block approach to detecting

and resolving feature interactions, in: L. Bouma, H.

Velthuijsen (Eds.), Feature Interactions in Telecommuni-

cations Systems, IOS Press, Amsterdam, 1994.

[22] G. Myers, The Art of Software Testing, Wiley, New York,

1979.

[23] M. Nakamura, Y. Kakuda, T. Kikuno, Feature interaction

detection using permutation symmetry, in: K. Kimber, L.

Bouma (Eds.), Feature Interactions in Telecommunica-

tions and Software Systems V, IOS Press, Amsterdam,

1998.

[24] T. Ohta, Y. Harada, Classi®cation, detection, and resolu-

tion of service interactions in telecommunications net-

works, in: L. Bouma, H. Velthuijsen (Eds.), Feature

Interactions in Telecommunications Systems, IOS Press,

Amsterdam, 1994.

[25] Telcordia, AIN Generic Requirements Switching Systems

(A Module of AINGR, FR-15), GR-1298-CORE, Issue 4,

10/1/1998.

[26] Telcordia, LATA Switching Systems Generic Require-

ments (LSSGR), GR-512-CORE, 1989±1985.

[27] J. Thistle, R. Malhame, H.-H. Hoang, S. Lafortune,

Feature interaction modeling, detection, and resolution: a

supervisory control approach, in: P. Dini, R. Boutaba, L.

Logrippo (Eds.), Feature Interactions in Telecommunica-

tions Networks IV, IOS Press, Amsterdam, 1997.

[28] M. Thomas, Modeling and Analysing user views of

telecommunications services, in: P. Dini, R. Boutaba, L.

Logrippo (Eds.), Feature Interactions in Telecommunica-

tions Networks IV, IOS Press, Amsterdam, 1997.

[29] K. Turner, An architectural foundation for relating

features, in: P. Dini, R. Boutaba, L. Logrippo (Eds.),

Feature Interactions in Telecommunications Networks IV,

IOS Press, Amsterdam, 1997.

[30] K. Turner, Validating architectural feature descriptions

using LOTOS, in: K. Kimber, L. Bouma (Eds.), Feature

Interactions in Telecommunications and Software Systems

V, IOS Press, Amsterdam, 1998.

[31] T. Yoneda, T. Ohta, A formal approach for de®nition and

detection of feature interactions, in: K. Kimber, L. Bouma

(Eds.), Feature Interactions in Telecommunications and

Software Systems 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 origi-nal Bellcore e�ort to de®ne the featureinteraction problem, applying intelli-gent agent technology to the problemand helping to develop an earlybenchmark list of feature interactions.

She was also instrumental in forming a world-wide group ofresearchers and developers to address feature interactions. Inaddition, she was co-chair of the First and Third InternationalWorkshops on Feature Interactions and co-editor of jointspecial issues of IEEE Computer and IEEE Communicationson the feature interaction problem. She also worked on thedesign and development of the Touring Machine platform forbroadband services. In conjunction with her work on TouringMachine, she developed and subsequently patented a negoti-ating mechanism based on the use of agents to address multi-user feature interactions. In 1995, she was chosen one of theTop 100 Women in Computing by McGraw-Hill's Women inComputing Newsletter for her work in feature interactions intelecommunications systems, distributed systems, and data-bases. She has published numerous papers on distributed sys-tems and databases. She received her M.S. in 1972 and Ph.D. in1978 from the University of Chicago. She taught in the KelloggSchool of Management from 1976±1979 and at Georgia Techfrom 1979±1987. She was a visiting associate professor atPrinceton University in 1987±1988, an MTS at Bellcore from1988±1997, and is now at Bell Labs.


Documents

A feature interaction benchmark for the first feature interaction detection contest