FEATURE INTERACTION

What is a feature? In a software system, a feature is an increment of functionality, usually with a coherent purpose. If a system description is organized by features, then it probably takes the form B + F1 + F2 + F3 . . . where B is a base description, each Fi is a feature module, and + denotes some feature-composition operation.

In telecommunications, features became possible in the 1960s, with the advent of computer-controlled telephone switches. Telecommunication software has been conceived in terms of features ever since. Features are often optional, so that different customers can subscribe to the features they need. Many features can be enabled or disabled dynamically by their subscribers.

For example, the plain old telephone service (POTS) is a telephony application feature at one level, but itself is composed of originating features and terminating features. The originating features may in turn include the provide dial tone feature, digit collection feature and so on. Other examples of features are call forwarding capability, or ring back when free. Features are popular because they are easy to add and change. However, there is a dark side of features and is called feature interaction.

What is Feature Interaction?

Feature interaction is a software engineering concept. It occurs when the integration of two features would modify the behavior of one or both features. Feature interactions are especially common in telecommunications, because all features are modifying or enhancing the same basic service, which is real-time communication among people.

What is the feature interaction problem?

When several features are added to a service, there may be interactions (i.e. behavioral modifications) between both the features offered within that service, as well as with features offered in another service. While particular interactions may be benign, in general, interactions can be severely damaging to system development and to user expectations. Busy treatment in telephony is an example for feature interaction. In a busy situation where two busy treatments B1 and B2 are both enabled, with B2 having higher priority, these features will interact: the action of B1 will not be applied, even though its stand-alone description of B1 says that it should be applied. As examples of interactions, consider the following. If a user who subscribes to call waiting (CW) and call forward when busy (CFB) is engaged in a call, then what will happen when there is a further incoming call? If the call is forwarded, then the CW feature is clearly compromised, and vice versa. In either case, the user will not have their expectations met.

What are the causes of feature interaction?

Some features create particular exceptions to more general features. Communicating parties have conflicting goals, and use their features to pursue

them. There are many possible treatments for the same condition. A feature that fills a role interacts with a feature that refers to it. Protocols designed for two parties are used for multiple parties. Features are based on assumptions about technology, which changes. There is conflict over a shared resource, such as the voice channel to a user. Signals are overloaded, being used to mean more than one thing.

Can we make a formal characterization of feature interaction? This is difficult to do in general, for many reasons. If feature composition results in an inconsistency, that is always a bad feature interaction. However, inconsistencies cannot be characterized precisely without knowing the feature-description language and composition operator. There are other potential formal problems, such as incompleteness, nondeterminism, and lack of associativity, which can arise from some composition operators and not others. If feature composition violates a well-established global principle, that is also a bad feature interaction. In telecommunications at least, such principles are few and far between. Some feature interactions are good as they are helpful synergies between features. This point cannot be overemphasized. Most of the literature on feature interaction assumes that all feature interactions are bad. Finally, the boundary between good and bad interactions is often subjective. The interaction is good if it results in desirable behavior, and bad if it results in undesirable behavior. What are the characteristics of feature interaction? Feature interaction is sometimes intentional and sometimes not. Feature interaction is a by-product of the modularity that allows us to add busy

treatments to the system without changing existing busy treatments. Feature interaction is produced by a specific composition operator, and would not

occur without the presence of that operator.

Practical examples of Bad Feature Interactions

1. Bob has Call Forwarding, and is forwarding all calls to Carol. Carol has Do Not Disturb enabled. Alice calls Bob, the call is forwarded to Carol, and Carol's phone rings, because Do Not Disturb is not applied to a forwarded call.

2. Bob has Three-Way Calling. If he picks up his phone and dials Alice, he can use Three-Way Calling to add Carol to the conversation. However, if he uses Click-

to-Dial to reach Alice from a Web-based mailbox, address book, or call log, he does not have Three-Way Calling, even though he is talking to her on the same telephone.

3. A new Mobility service is offered to office workers. When Alice signs up, her office phone number is forwarded to the Mobility service. On receiving a call for Alice, the Mobility service forwards it to wherever Alice's personal data dictates. However, whenever the data indicates that Alice is in her office, an incoming call enters a forwarding loop.

4. Alice@host1 and Bob@host2 correspond by electronic mail. Because Bob wishes to remain anonymous in this correspondence, he is known to Alice as anon@remailer, and the Remailer feature retargets electronic mail for anon@remailer to Bob@host2. However, Bob@host2 also has an Autoresponse feature set to notify his correspondents that he is on vacation. When electronic mail arrives with source address Alice@host1 and target address Bob@host2, it immediately generates a response with source address Bob@host2 and target address Alice@host1. When Alice receives the response, she learns Bob's identity.

5. Alice has a personal address A with a Find Me feature. She is scheduled to

participate in a voice conference at 2 p.m., and asks the Conference Server to call her at A. When the Conference Server calls A, Find Me begins to search for Alice. This takes some time, so Find Me plays an announcement "please wait while I locate Alice for you." This causes the Conference Server to act as if its call had been answered by a person, and begin prompting for a PIN. The authentication prompt times out, and the call is disconnected, before Alice can answer.

6. A traveler is using a Credit Card Calling feature to access his Voice Mail. He needs to enter the DTMF tone "#", which is a command for many Voice Mail servers. However, when he presses "#", the Credit Card feature interprets it as a command to end the current call and start another one on the same account.

7. Family members need to change their travel plans at the last minute. They use N-Way Calling to form a voice conference, then call their travel service and join it to the conference so everyone can participate. However, N-Way Calling absorbs DTMF tones (which are used by individuals to mute, unmute, etc.), so the family cannot use the IVR system that answers the travel-service phone, and probably have no idea what is wrong.

8. Bob has Call Forwarding, and is forwarding all calls to Carol. Alice calls Bob, the feature forwards the call to Carol, and also changes the source address of the call to Bob's address (on the grounds that Bob is responsible for this leg of the call).

One scenario: Carol has Call Blocking, and is blocking all calls from Alice. This call is not blocked, however, because it appears to be from Bob. Another scenario: Carol misses the call, but later uses a Call Return feature to return it. The feature places a call to Bob's address, which is forwarded back to Carol.

Practical examples of Good Feature Interactions

1. A physician has a personal address used only for his role as a physician. At home, an Identification feature enables him to call patients and to have this role address as the caller identification, rather than the number of his home phone. This protects the physician's privacy and provides identification that is more recognizable to patients. Also, if a patient is not available and calls the physician back later, when the physician is no longer at home, the call will go through the physician's Find Me feature and reach the right place. This would not be possible if the return call were dialed to the physician's home phone number.

2. A person uses a personal phone number with a Phone GUI feature. The Phone

GUI feature enables him, whenever he is near a computer with Internet access, to use a Web-based GUI as a phone controller. The Phone GUI feature should compose with the Personal Mobility feature of the personal phone number so that the GUI is available on every call received or placed by this person, at any phone.

The feature-interaction problem is associated with the old circuit-switched telephone network. Won't voice-over-IP and other new technologies make it go away?

Not a chance. The current vision of IP telecommunications is that it will be multimedia, multimodal, highly mobile, highly personalized, data-intensive, and feature-rich. This vision is far, far beyond the complexity of anything ever attempted with circuit-switched telephony.

So, how do we manage/control feature interactions???

To manage interactions among features, it is necessary to detect potential interactions, to distinguish between the good and bad ones, to prevent the bad ones, and to enable the good ones.

Most of the research on feature interactions has been focused on telecommunication software, and has been published in the series "Feature Interactions in Telecommunications and Software Systems" by IOS Press. The series of Feature Interaction Workshops (FIW) and the International Conferences on Feature Interaction (ICFI) are the primary venues devoted to this problem. The latest ICFI was organized in 2009 at Lisbon in Portugal.