' 2001 Telcordia Technologies, Inc. Feature Interactions in Services for Internet Personal Appliances Mario Kolberg 1 , Evan Magill 1 , Dave Marples 2 , Simon Tsang 2 1 University of Stirling Department of Computing Science and Mathematics Stirling FK9 4LA, UK, {mko,ehm}@cs.stir.ac.uk 2 Telcordia Technologies Morristown, NJ 07960-6438, USA {dmarples,stsang}@telcordia.com Abstract- This paper investigates the Feature Interaction problem, known from traditional telephony environments, in the context of internet appliances. The results are threefold. The first part of this paper introduces a service taxonomy supported by a list of example services. The second part discusses feature interactions between services for appliances. A classification for such interactions and example interactions are presented. The final part contains an outline for an approach to handle such interactions. I INTRODUCTION Internet Personal Appliances (IPA) attract an increasing interest from industrial players and are widely seen as the next major application of the internet. Common, widely referenced examples of internet appliances include the internet alarm clock which takes into account road conditions or expected arrival times of air planes when setting the alarm time, or the internet enabled fridge which keeps an inventory of groceries and issues orders to suppliers. IPAs are dedicated consumer devices which contain at least one network processor. Because the price for these devices has to be kept to a minimum no extensive logic is located inside the device itself. Instead, the logic is handled by services. Thus the provisioning of appliances and services is separate and introduces more flexibility to the market place. Also from the two simple examples above it is clear, that appliances need to communicate. Consequently, services will be communicating with other services, either directly or via controlled appliances. Hence there is a strong potential for service interworking. A Feature Interactions From the experiences in the telephony environment it is known that the interworking of services can lead to a phenomenon called feature interactions [1]. Services (or features) which work perfectly in isolation do not exhibit the desired behaviour if other services are active in the same session or call. The services involved can be distributed in the network and be active on different endpoints. As previous work in the telephony domain has shown, feature interactions are hard to detect, and even harder to resolve [2]. It is important to note that feature interactions are not about badly written services but about broken assumptions and conflicting goals [1]. Services are usually developed in isolation, i.e. independently of each other! Thus, services will meet for the first time in the network. II THE EXPECTED ARCHITECTURE FOR IPA The overall architecture can be divided into two main parts. Firstly, the user domain or In-Home, and secondly, the service provider domain or outside world. Appliances inside the home are connected to a Local Area Network (LAN). Appliances communicate using various protocols, such as HAVI [3], VESA [4], JINI [5], UpnP [6], and X10 [7]. The home domain is connected to the Internet. Various service providers offer their services in this domain, to be used with appliances inside the home. Both domains are connected by a Residential Gateway (RGW) with Network Address Translator / Firewall functionalities. These provide protection from unauthorised access into the home and also a translation of addresses in the IP format to the format used inside the home (cf. Figure 1). Currently, more sophisticated approaches, such as the Open Services Gateway by the Open Services Gateway Initiative (OSGi) [8], are being specified. Home Network Appliance Controller Appliance Appliance Controller Controller Internet Internet Outside World In Home Protection Firewall /NAT X.10 UPnP Appliance Controller Appliance Appliance Controller Controller HAVi RGW RGW Service Provider Figure 1: Architecture to control Networked Appliances. A. Using the Session Initiation Protocol for IPA The Session Initiation Protocol (SIP) [9] has been suggested as a protocol to control networked appliances [10]. That is, the services send SIP messages to the appliances to control these. If a different protocol is used inside the home, a translation from SIP to other protocols takes place inside the home. However, increasingly, SIP enabled networked appliances will become available. For this document it is assumed that SIP is used for communicating with IPA. SIP is text-based and targeted at initiating, modifying and terminating network sessions between entities addressed in an email-like fashion. Three types of components are defined in SIP: User Agents (which either take a client or server role), Proxy Servers, and Redirect Servers. User Agents initiate requests (client) and are their final destination (server). Proxies fulfill the tasks of application-layer routers; they forward SIP request and response messages. Unlike Proxies, Redirect Servers do not forward messages directly but return the address of a SIP User Agent or Proxy Server. A typical SIP request originates from a User Agent, passes through a number of Proxy and Redirect Servers until it terminates at the remote User Agent.