FAQ Sheet on Feature Interaction

By Pamela Zave; Copyright AT&T, 1999, 2004.

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.

I assume we are talking about the highest-level description in which system behavior is (supposedly) defined rigorously and completely. It could be natural-language requirements, a formal specification, or an implementation.

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.

What is a feature interaction?

A feature interaction is some way in which a feature or features modify or influence another feature in defining overall system behavior. 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.

Features are popular because they are easy to add and change. The dark side of features is feature interaction, which is implicit in feature composition and therefore difficult to understand.

What is the feature-interaction problem?

Historically, developers of telecommunication software have had no effective means of understanding and managing feature interactions. As a result, feature interactions have been a notorious source of runaway complexity, software bugs, cost and schedule overruns, and unfortunate user experiences.

Developers of other software systems are beginning to realize that they, too, have a feature-interaction problem.

What does it mean to manage 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.

Can you give a more 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, that 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--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.

Can you give an example?

Consider "busy treatments" in telephony, which are features for handling busy situations by performing functions such as forwarding the call to another party, interrupting the callee, retrying the call later, or offering voice mail to the caller. Suppose that we have a feature-description language in which a busy treatment is specified by providing an action, an enabling condition, and a priority. Further suppose that a special feature-composition operator ensures that, in any busy situation, the single action applied will be that of the highest-priority enabled busy treatment.

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.

This example illustrates some of the least-understood characteristics of feature interaction:

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.

Furthermore, here are some common causes of feature interaction:

Of all these causes, only signal overloading is alleviated by IP technology. Other factors such as decentralization and deregulation will provide many new occasions for feature interaction in IP services.

Do you have 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. 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.

  6. Alice calls a sales group. A feature for the sales group selects Bob as a sales representative on duty, and forwards the call to Bob. Bob's cellphone is turned off, so his personal Voice Mail answers the call and offers to take a message. It would be much better to re-activate the sales-group feature to find another representative.
  7. A subscriber should be able to subscribe to Voice Mail, Parallel Ringing, Quiet Time, Call Blocking, or Selective Call Forwarding, in any combination, and to enable or disable them at any time.

    First, each feature must work correctly if it is the only enabled feature. Here is a summary of what the less familiar features do:

    Second, the features must interact correctly when multiple features are enabled, even though they might have been built by different people and deployed at different times. Here are some things that might go wrong:

  8. 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.
  9. 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.
  10. 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.
  11. A presence server monitors when phones in an office are busy. There is a Call ASAP feature that performs the following sequence of actions: If any of these actions fail, Call ASAP sets a timer and tries again in a short time.

    Alice and Bob are working together closely on an urgent project. At around the same time, while Alice is on the phone, both activate Call ASAP to reach the other.

    When both phones become idle, both instances of Call ASAP will perform their actions at about the same time, and both will fail because neither will succeed in calling both parties. Both will retry again at about the same time, and continue to fail, although both phones continue to be idle between retries.

  12. A Call Waiting feature is programmed to interrupt all media channels of the held party. This makes perfect sense when calls are voice-only. However, it interacts badly with a Videophone feature, because when a voice-and-video call is time-multiplexed with a voice-only call, only the voice channel of the voice-and-video call should be held. The video channel should continue uninterrupted.
  13. Carol is using an IP telephone that generates its own progress tones. She receives a call from Bob, and then activates her Three-Way Calling feature to add Alice to the conversation. After Carol dials Alice, she expects to hear ringback or busytone. However, some feature or interface absorbs the progress signal as erroneous (either because it comes after a talking connection has been established, or because it is traveling in the "wrong" direction) and Carol does not hear any progress tone. She concludes that the feature is not working, and aborts the attempt to use it.

Do you have examples of feature interactions where the line between good and bad is less clear?

In these interactions, the "correct" behavior is the desired behavior.

  1. Mid-Call Move and Call Waiting have two possible compositions. In one, a move can be initiated at any time. If Call Waiting is multiplexing two far parties, then both are maintained by the move. In the other composition, only one far party can be moved. Either moves are prohibited when there are two far parties, or if a move is allowed when there are two far parties, the selected party is moved and the held party is dropped.

    To manage this feature interaction, it is necessary to decide which of these options is the desired behavior, and to coordinate the two features so that the desired behavior is achieved.

  2. Alice is forwarding to Bob, and Bob is forwarding to Carol. If Alice is called, should the call be forwarded to Carol?

    If Alice is on vacation, and Bob is Alice's secretary, then the answer is "yes". Carol's phone is the current location of Bob, and the call will be received.

    If Bob is on vacation, and Alice is temporarily using Bob's office, then the answer is "no", because that will send Alice's calls to Bob's secretary, who is Carol. Only calls actually dialed to Bob should be forwarded to Carol.

Do you have other 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.
  3. Bob has a Personal Directory that maps nicknames to phone numbers, and is used for speed dialing. The directory contains the nickname "Alice" for his friend Alice. When Alice calls Bob, the caller identification should be changed from Alice's phone number to "Alice".

What work has been done on managing feature interactions?

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.

At AT&T Research we recommend use of the Distributed Feature Composition (DFC) architecture.