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 NWay 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 featurerich. This vision is far, far beyond the complexity of anything ever attempted with circuitswitched 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.