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
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
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?
"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:
This feature interaction is entirely intentional and desirable.
This feature interaction
is a by-product of the modularity that allows us to add
busy treatments to the system without changing existing busy treatments.
Without the special composition operator, when B2 is
added to the system, the enabling condition E1 of B1
must be changed to (E1 and not E2).
- This feature interaction is produced by a specific composition
operator, and would not occur without the presence of that operator.
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
This vision is far, far beyond the complexity of anything ever attempted with
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.
- 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.
Do you have examples of bad feature interactions?
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.
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.
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
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.
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).
Carol has Call Blocking, and is blocking all calls from Alice. This
call is not blocked, however, because it appears to be from Bob.
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.
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.
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:
If a subscriber has Parallel Ringing enabled, an incoming call to the
subscriber rings his phone and a number of other phones
simultaneously. If one of them is answered, the other attempts are
aborted. If one of the attempts fails, it is aborted. If all
attempts have been aborted, Parallel Ringing sends a busy signal.
If a subscriber has Quiet Time enabled, an incoming call to the
subscriber activates an IVR dialogue with the caller, saying that the
subscriber wishes not to be disturbed, and asking whether the call
is urgent. If the call is urgent, Quiet Time allows it to ring
normally. Otherwise, Quiet Time disconnects the caller.
If a subscriber has Call Blocking enabled, and if there is an
incoming call from an address on the blocked list, Call Blocking
sends a ringback signal without ringing any phone.
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:
Call Blocking blocks a call from a particular caller. Voice Mail
is activated by the unanswered call, so that the unwelcome caller can
leave an unwelcome message.
Selective Call Forwarding forwards a call. The forwarded call is not
answered, yet Voice Mail has been disabled by the forwarding so that
it is not available to take a message.
Quiet Time is activated by an incoming call, the caller does not feel
that the call is urgent enough, and the call is disconnected by
Quiet Time. Yet the subscriber wanted this call to get through, and
specified Selective Call Forwarding of the call for that purpose.
The problem is that QT is applied and SCF is not, although it should
have been the other way around.
The subscriber's phone is busy and this triggers Voice Mail, even
though Parallel Ringing is ringing other phones.
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.
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.
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.
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.
Check (or learn) that the phone of a particular party is idle.
Check that the subscriber's phone is idle.
Call the subscriber.
Call the particular party, and connect the two people.
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.
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.
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.
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.
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?
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
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.
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.