Assistive environments: Integration of heterogenous networks to support Ambient Intelligence

ASSISTIVE ENVIRONMENTS Integration of heterogenous networks to support Ambient Intelligence J. Abascal, J. L. Sevillano, A. Civit, G. Jimhez, J. Falc6 J Abascal, University of the Basque Country-EHU. Donostia-San Sebastihn, Spain. J. L Seviallano, A Civit and G Jimenez, ETSI Informatica. Universidad de Sevilla. Spain. J Falco, CPS, Universidad de Zaragoza, Spain Abstract: In the last decade, Assistive Technology researchers have studied and developed accessible and adaptable environments intended to enhance the autonomy and the quality of life of the people with disabilities and elderly people. Their efforts, technologically rooted in the Ubiquitous Computing technologies, are firmly supported by the Ambient Intelligence concept. In the assistive scenario the main problem that researchers have to face is the integration of diverse local and remote services that were previously provided through different network technologies. In this paper we identify the main issues that may influence design decisions regarding the integration of -and the interaction amongdifferent subsystems in the context of assistive technologies. Key words: Assistive technology, networks, ambient intelligence. 1. INTRODUCTION The concept of Ambient Intelligence (AmI) defines a set of both reactive and proactive properties of an environment in order to enable individuals and devices to easily interact among them [I]. Ducatel et a1 [2] foresee some scenarios for AmI where Ubiquitous access, Context awareness, Natural interactions, and also the need to support heterogeneous systems are particularly important [3]. Ad objectives are totally coincident with the aims of Assistive Technology to produce accessible smart environments in order to enhance A. Sloane (ed.), Home-Oriented Informatics and Telematics © International Federation for Information Processing 2005 3 24 J. Abascal, J. L. Sevillano, A. Civit, G. JirnCnez, J. Falcd the autonomy and the quality of life of people with physical, sensorial or cognitive restrictions due to diverse causes, such as disability or aging. In this way, many services have been developed to assist people in their diverse needs. However, a single person frequently uses diverse services delivered by means of different networks and devices. A smart environment should integrate and provide all the services by means of a single device. 2. INCLUDING SCENARIOS FOR PEOPLE WITH SPECIAL NEEDS Therefore, one of the main challenges of AmI in the context of assistive technologies is the integration of many pre-existent heterogeneous digital devices and services and their networks into everyday environments. The whole system should be able not only to support the interaction of heterogeneous networks, but also the integration of diverse services and applications. The reason is that assistive technologies are very varied when attending needs due to individual diversity and to temporal variations. In addition, the diverse devices needed by a single person are usually designed by different manufacturers using different technologies and devoted to varied applications. Individual diversity and variability increase heterogeneity in subsystem development, both in terms of applications and services, in a kind of vicious circle. We will look at this problem later on, but first let’s illustrate through a typical scenario how the AmI concept will influence assistive technologies: A wheelchair user with low vision restrictions and wearing a mobile computer enters an unknown building (let’s say the City Hall), provided with Ambient intelligent facilities. As soon as he/she gets into the building, the Ambient Intelligence System (AmIS) discovers hisher presence and announces the services that can be used. Additionally, it investigates what services the user’s system can provide to the community. Both systems also exchange information related to preferences, special needs (cognitive, sensorial, physical and communication abilities), and technological constraints (display resolution, voice, text, pixel-based, bandwidth, computing power, etc.). The AmIS offers communication with a remote information centre that appears in the display of the user, adapted to its physical and cognitive characteristics (text menu, voice, icons.. .). It also offers a video guided tour that OUT user rejects. Our user asks the information centre where he/she must go to see what had happened with hisher water bill. He/she Assistive environments 325 3. chooses the voice and video interface with the person in the information office. After knowing where to go it appears on its display the possibility of a route-guiding tool, which the user accepts. It uses a location service and gives information via text messages. The user is located and receives hisher position, together with a message of where to go now. The AmIS has calculated the best path to follow, taking into account the user constraints and the information of occupation in the building at that time of day. When he/she enters an elevator communication with the system is lost. The AmIS uses elevator information that sends the vertical position. Originally this feature was only designed and used by the technical personnel of the elevator company, but now it can be used to provide both the user and the route guiding system with the information of the floor he/she is at. The elevator doors also adapts to the especially long timing of our user, for it receives the information of this special characteristic. There is an especially narrow door he/she must cross, so the user accepts the service of semiautomatic wheelchair navigation he/she was offered at the entrance, which helps himher with that specific manoeuvre. Finally he/she arrives at the destination and solves the water fee problem by direct personal interaction. The user’s mood is better now that hisher worries about the water fee are solved, so he/she accepts some music service while leaving the building in the same way he/she entered. DESIGN ISSUES Evidently, assistive technologies present specific characteristics regarding the integration of different and heterogeneous subsystems. Note that AdSs not only need the inclusion of different existing subsystems but should also allow their interaction so that each subsystem (offering a particular service) can take advantage of the services that are included in the environment. For instance, wheelchair users who want to access assistive services through personalized interfaces fi-om different locations, even in unfamiliar environments; services for monitoring users’ location in terms of safety or support in hospitals or residences; services to provide information adapted to user needs or abilities in museums; etc. We identify three main issues with regard to the integration of -and interaction amongdifferent subsystems in this context: Mobility: There are several aspects regarding this issue. First, users should be able to interact with services and sub-systems at anytime, from 326 J. Abascal, J. L. Sevillano, A. Civit, G. Jimknez, J. Falcd any place, and using a personal (adapted) interface carried by the user. These mobile devices used to have scarce resources: bandwidth, computational and battery power, screen size, etc. However, advancements in this field are enormous and there are now commercially available handheld devices (such as PDAs, mobile telephones and portable PCs) of acceptable performance at relatively low cost. An additional problem is to provide communications across heterogeneous and dynamically changing links and networks. Wireless personal (e.g. Bluetooth) and local (e.g. Wi-Fi) area networks now permit low-cost commercial solutions for this type of communication, but there are still open problems like efficient roaming, reachability, intermittent failures, fault tolerance, etc., in order to achieve seamless access. Finally, it is not just the problem of communicating subsystems. Further issues are how to share services and information among heterogeneous sub-systems "on the move". Heterogeneity: As we discussed above, this is a major problem in this field. In fact, the current situation is characterized by what could be called "islands of functionality": solutions adapted to specific users in particular environments (such as home or collective residences). With regard to hardware devices and wireless/wired links, standardization is the norm. However, this is not the case with assistive devices and applications. In order to successfully integrate these heterogeneous subsystems, generic descriptions of devices, services andor context (location, personal, etc.) are needed in a way that is independent from the applications. In assistive technologies, one of the main issues is a generic and universal description of personal abilities and characteristics. The latter also has to do with how adapted assistive services are offered to the right persons. Excess or useless content must be avoided. For instance, audio environmental descriptions may only be required by visually impaired people. Context awareness: Mobility and environment and personal variability in these systems require a context-dependent computation, that is, computation that uses information to characterize the situation (location, time, personal) of an entity (person, place, object) [4]. This is not a constraint as such. On the contrary, it may result in one of the added values due to this interaction at all levels. From the point of view of the integration of context-aware subsystems, a common context representation is required, and also a common way to interchange this context information among subsystems. Assistive environments 327 4. DESIGN DECISIONS FOR SUB-SYSTEM INTERACTIONS In a previous paper [3], we proposed a layered architecture for the development and integration of heterogeneous sub-systems into Ambient Intelligent Systems (AmISs). Since the systems to be connected are also distributed, we identified three levels that help to model the interaction among systems with different types of interactions depending on the level. Figure 1. Interaction Scheme The interactions are named Interconnectivity, Interoperabiliiy and Inter$mctionaZity at the Internetworking, Middleware and Application levels, respectively. In the following sub-sections, we discuss our main design decisions at every level, talung into account the identified issues described in section 2. 4.1 Interconnectivity We define interconnectivity as the ability to interact at the internetworking level, including all the lower level functions (approximately equivalent to the transport, network, data link and physical OSI layers [5]). At this level of interactions, the necessary mobility implies that communications should be asynchronous. In other words, interconnectivity cannot be guaranteed at any time. Mobility requires wireless connections that may suffer frequent connection losses, what forces asynchronous communications. Clients asking for a service and devices offering it may not be connected at the same time. The communication paradigm should be connectionless (vs. connection oriented), well suited for intermittent connections. On the other hand, heterogeneity makes a Nomadic system better that an Ad-Hoc system: a backbone fixed infrastructure plus a number of mobile devices connected through wireless links is a better solution. A robust and 328 J. Abascal, J. L. Sevillano, A. Civit, G. Jimknez, J. Falcb contrasted solution is a backbone network based on the IP protocol, which has demonstrated its success in the interconnection of heterogeneous devices (a good example is the Internet). Most devices can be connected through this IP network while secondary, maybe simpler, devices (e.g. sensors) may be connected using non-IP communications. In this case a gateway is used to interconnect IP and non-IP sub-networks. This configuration allows both sensing and collecting context information (context awareness). Furthermore, it permits environmental control in a remote mode via a web page as well as direct Internet access in home automation through Residential Gateways. It may seem that the required mobility would make ad-hoc communications more appropriate. However, we think that a nomadic system presents several advantages. It simplifies connection establishment and roaming. Mobile devices usually have limited resources (computing power, bandwidth, memory, etc) so some of the complexity needed or desired for some functions can be placed in fixed systems. The infrastructure can maintain knowledge about device characteristics and manage coherent device interactions. PAN USER Figure 2. Networks interconnection in the DomoSilla system As an example, figure 2 shows the set of bridges that provide the interconnection level in the DomoSilla2' project. The user interacts with the AmIS through a mobile user interface handled with the wheelchair input system (usually a kind of joystick). Through this interface, the user controls both the wheelchair and the domotic system. The network infrastructure DomoSillu, "Study, evaluation and design of an interconnection system between local network for wheelchairs control (DXEus) and domotic network (EHS)", funded by the Spanish Ministry of Science and Technology under the grant No. TIC2000-0087-P4. Assistive environments 329 includes two wireless networks. First, there is a Bluetooth personal area network (PAN) to communicate the user interface with the computer in the wheelchair through a bridge between the radiofi-equency network and the real time bus (DX) that controls the wheelchair. Second, there is a Wi-Fi home area network to interconnect the domotic system and the wheelchair. For this purpose another bridge between the radiofrequency network and the domotic EHS bus (a Powerline-like bus used for the control of home devices) is available. In addition, it is also possible to remotely interact with domotic system through a web page. For this purpose there is a residential gateway that connects the home EHS bus to the Internet. 4.2 Interoperability The concept of interoperability is widely used to describe interaction among devices at all levels [6], including control, configuration and information sharing in different formats [7]. To distinguish this term from interconnectivity, we consider interoperability related to the sharing services at the middleware level, such as import/export services [8]. Interoperability can provide a set of services to all elements. In the literature there is a general agreement about the functions that should be related to interoperability [5, 91, including dynamic service discovering (periodically or triggered by determined events [lo]), service description (including actions that may be performed, properties that may be useful, even devices for which connection was not planned), and service control (actions and modifications of state or attributes of a service in a sub-network from another device connected to a different sub-network). A number of available architectures can support these functions, and we will now revise some of them taking into account the specific characteristics of the environments and applications for Ambient Intelligence. specification allows registration of new devices as they add to the network, so the rest of devices know what new functions they may perfom. Most common AN (AudioNideo) functions have some standard APIs (Application Programming Interfaces) to enable other devices to use them. The system allows the installation of applications and user interface software in each device in an automatic way. These MIS are specified in a generic C- like language named IDL (Interface Definition Language). Specification is independent of language although they are usually implemented in Java [ 111. A disadvantage of HAVi is that it assumes the communication channel is IEEE1394, a wired connection with enough bandwidth to transmit audio and ** http:/lwww.havi.org/ 330 J. Abascal, J. L. Sevillano, A. Civit, G. Jimtnez, J. Falcd video, and so its architecture may show limitations when used in a wide range of applications, especially nomadic systems [ 121. Another middleware described in literature is Jini23. Jini gives support for all the described structure concerning service discovery and sharing of services by different clients. Mascolo et al. point to its heavy dependency on Java and its assumption of the existence of a fixed infrastructure as its main drawbacks [5]. On the other hand, some authors think that Jini is not especially adequate for limited computational resources devices and, mainly, for mobile devices [12,13]. Nevertheless, the recent release of very small Java virtual machines opens the opportunity to the inclusion of very small embedded devices that previously could not be integrated. On the contrary, there are many devices on the market based on UPnP (Universal Plug and Play)z4, including all Windows XP-based systems. UPnP supports all mentioned functions including the dynamic connection of a device to a network, services offering and discovery, everything based on a unified description of functions and attributes of services through XML (dtended Mark-up Language) documents. There are two factors that make UPnP especially attractive from our point of view: one is the use of IP protocols at the lowest level; second is the use of open and standard protocols. As IP is used for the lowest level, the first phase of interaction among UPnP systems is Addressing. This is the mechanism that devices have to obtain an address that makes them visible in all the system. At first, all UPnP devices incorporate a DHCP (Dynamic Host Configuration ProtocoZ) client to obtain an IP address. If there is no answer from a DHCP server, it chooses an address and checks it wasn’t used through ARP (Address Resolution Protocol). In any case, once the device has an IP address, it can proceed with following phases related to discovery functions and service control, that are performed using an also open and simple protocol named SSDP (Simple Service Discovery Protocol). IP based communications are made using HTTP protocol or any of its versions. HTTP is message based (asynchronous communication), which is especially adequate for nomadic systems, that may suffer unpredictable disconnections. Particularly, UPnP considers the usage of HTTPU (or HTTPMU for multicast messages, very useful when offering services to the whole system), that is HTTP version over UDP. UDP gives functionality equivalent to the transport (TCP) but is simpler, and, most importantly, nonconnection oriented. So, the use of the set HTTPU / UDP / IP is, in our ’’ http://www.jini.org l4 http://www.upnp.org Assistive environments 33 1 opinion, an adequate solution for asynchronous communication in nomadic systems. Development of UPnP devices is greatly facilitated thanks to tools like Intel Service Author, Device Builder and Device Validator [ 141. Siemens also has some tools, and there are even some fieeware developments for Linux. A disadvantage of UPnP may be the difficulty for simple devices to interpret XML descriptions of devices and services. Moreover, these devices may find difficulties in supporting all the pile of UPnP protocol. A feasible solution for simple devices and/or slow connections is the use of SCP. This is a no TCP/P based protocol, but it uses the same schemes and models as UPnP, allowing easy interoperation among UPnP and SCP devices via simple bridges. Finally, it may be worthwhile to name other interoperability solutions, not considered here due to their limitation to a set of applications, such as Salutation in office environments, or to be limited to specific functions or technologies, as SDP (Sewice Discovery Protocol) of Bluetooth. As there are many available technologies at middleware level, and they are not compatible with each other, the heterogeneity problem remains as a major difficulty for AmISs. Already in the literature there are descriptions of efforts to overcome heterogeneity at middleware level, such as OSGi (Open Services Gateway specification) initiative [15]. It gives a common structure at application level that is independent of the middleware technology used. Actually what OSGi offers is a specification for a somehow centralized gateway that allows the use of services of different technologies, as Jini and UPnP. Something similar has been proposed using techniques already used in the Intemet, through the concept of Virtual Overlay Networks [12]. Generally speaking, this idea of a gateway is placed over the level of middleware, closer to the application level, so it differentiates somehow from the former interoperability concept. Whatever solution is chosen, several design considerations can be made according to the previous sections. If nomadic systems are used at the interconnectivity level, then the fixed infrastructure may support some interoperability functions. For instance, a central unit (Residential Gateway) may gather and distribute some services. Also, the context captured by fixed elements (for instance the closest service access point/provider in public environments like airports) can approximate that of the mobile client. Mobile devices could therefore obtain an IP address, connect to a fixed system and collectfsend services and context information in order to interoperate. This interoperation also requires abstract context representation as well as generic, common protocols, including common formats for multimedia content distribution.