Damien Charlet
email: damien.charlet@inria.fr

Valérie Issarny
email: valerie.issarny@inria.fr

Rafik Chibout
email: rafik.chibout@inria.fr

Service Discovery in Multi-radio Networks: An Assessment of Existing Protocols *

Keywords: C.2.4 [Computer Systems Organization]: Computer -Communication Networks-Distributed Systems Measurement, Performance Service discovery, B3G networks, energy consumption

The wide deployment of mobile networks and the emergence of powerful portable devices has given core to pervasive computing. As particularly addressed by Beyond 3G (B3G) networks, the recent evolution of mobile networks introduces the convergence of wireless technologies, where several radio interfaces are to be used concurrently. Thus, B3G-aware applications shall make the most effective use of this connectivity. In pervasive environments, mobile users may discover and access services offered on the networks using Service Discovery Protocols (SDPs). Several SDPs are currently in use, each one designed for specific target network architecture and setting. Thus, in a multi-radio environment, each SDP does not equally suit each radio interface. In order to provide effective service discovery in multi-radio networks, the most resource efficient interface shall be chosen with respect to two main criteria: the adequacy of the radio interface against the SDP to be used, and energy saving, which is crucial for battery-powered devices. Toward this goal, this paper assesses how to exploit multiple radio interfaces from the standpoint of service discovery and access with respect to energy consumption, and the adequacy of the legacy SDPs with the various networks, so as to classify the most appropriate networks for each SDP.

INTRODUCTION

While wireless networking technologies were developed autonomously, and sometimes in direct concurrence with each other, recent evolution of mobile networks outlines a new trend: several radio technologies are to be used concurrently and complementarily. This new trend, called convergence of mobile networks, is more particularly addressed in Beyond 3G (B3G) networks. B3G-capable devices then hold several radio interfaces, and switching from one radio interface to another, e.g., upon disconnection (vertical hand over). Thus, effective deployment of distributed applications over several heterogeneous radio networks appears as a key challenge for distributed systems.

We more specifically focus on the concept of smart spaces [START_REF] Akyol | Smart office spaces[END_REF] surrounded by B3G networks. That is, a user is evolving in an environment where many networked objects (e.g., PCs, PDAs, CE devices, smartphones, sensors) provide services and information via one or more of the available wireless networks. The user further has at its disposal a handheld device with several radio interfaces, and is thus able to move around and access the services offered on all the networks. When services may be accessed via several radio interfaces, B3Gcapable applications shall communicate through the most appropriate interface according to criteria such as energy consumption, which is a crucial constraint for embeded devices [START_REF] Pering | Exploiting radio hierarchies for power-efficient wireless device discovery and connection setup[END_REF] [START_REF] Bahl | Reconsidering wireless systems with multiple radios[END_REF]. Still, in order to be accessed, services must first be discovered. Over the years, many academic and industry supported service discovery protocols (SDPs) have been proposed for specific networks (e.g., Jini [START_REF] Waldo | The Jini architecture for network-centric computing[END_REF] for intranets, UPnP [START_REF]Universal Plug and Play Forum. Universal Plug and Play Device Architecture[END_REF] for home networks). While efficient for the targeted environment, existing SDPs prove to be inefficient (e.g., communication cost overhead) or not applicable (e.g., filtered multicast) in different network settings. Meanwhile, when an application may use several radio interfaces, the least power consuming interface may not be the most effective choice, if the SDP to be used does not suit the interface's properties and settings.

In the above context, our objective is to support effective service discovery in multi-radio networks so as to offer energy efficient, integrated service discovery. The solution shall exploit the various networks on the mobile, wireless devices, while overcoming SDPs heterogeneity, in a way that both minimizes resource consumption and offers response time comparable to that of legacy SDPs. Towards this goal, this paper assesses the impact of multi-radio networking on service discovery together with the adequacy of existing SDPs. Next section is dedicated to the assessment of the various radio interfaces in use today with respect to energy consumption for typical services discovery and access scenario. In Section 3, we inspect the bindings between the SDPs features and the multiple radio interfaces in order to sort out incompatibilities and rate the usage efficiency of each SDP on the different radio networks. This study results in a matrix of values rating the adequacy of use of each SDP against each radio interface. Finally, we conclude by a summary of our contribution in Section 4.

ASSESSING MULTI-RADIO BASED SER-VICE DISCOVERY WITH RESPECT TO ENERGY CONSUMPTION

It is a known fact that all radio interfaces do not consume the same amount of energy during transfer. In particular, several studies of the power consumption of the Bluetooth and Wifi interfaces may be found in the literature [START_REF] Lorchat | Power performance comparison of heterogeneous wireless network interfaces[END_REF] [START_REF] Qadeer | Heterogeneous wireless network management[END_REF]. However, all these studies concern measurements done while transferring large files at a sustained rate, whereas SDPs are not based on this type of sustained exchange. SDPs rather use short and cyclic transfers for active discovery, and sniffing for passive discovery.

The goal of this study is to measure the power consumed on handheld devices (namely HP Ipaq HX4700 and HP Ipaq H6340) during active ( § 2.1) and passive ( § 2.2) service discovery, and service access through their radio interfaces (Wifi and Bluetooth). The Wifi and Bluetooth interfaces are further studied according to their various operating modes: the Wifi interface is divided into the ad hoc and infrastructure modes, and the Bluetooth interface in the Bluetooth piconet and Bluetooth NAP modes. We simulate passive discovery by putting the interfaces in a listening state during a defined period of time. Active discovery is simulated by executing several short transfers cyclically. Next, we also measure power consumption during sustained transfers to simulate services access and infer a model of consumption for each interface, in order to compare our measures with the ones that may be found in the literature ( § 2.3). Finally, these results are interpreted and discussed in the framework of energy-efficient service discovery and service access in multi-radio networks ( § 2.4).

In all the tests, we measure the relative power consumption after half an hour of operation. The curves of discharge of the devices not being linear, all measurements are started when the battery is fully loaded. All the measurements are reiterated several times and the mean value is given as final result, as we obtained low coefficient of variation. We first perform a base measurement consisting in letting the Ipaq switched on for half an hour with all the radio interfaces down, in order to be able to discriminate the consumption of the radio interfaces with that of the other peripheral elements. This base result is given in Table 1. Next results are given in percentage of battery consumed in addition to the base measurement.

Measurements for passive discovery

The first test-bed consists in simulating service discovery following the passive model as with, e.g., UPnP. In this mode, clients never send requests but are continuously listening on the network interface for service advertisements. To simulate this operating mode we force one radio interface at a time in an "always on" state and measure the power consumed after half an hour of listening. In the Wifi ad hoc mode, the device is bound to an existing group. In the Wifi infrastructure mode, the device is associated with an access point and in the Bluetooth PAN Mode it is linked with a network access point. We make sure the device obtains an IP address and is fully network-operational before starting the measurements. The consumption of each radio interface after half an hour of passive discovery is given in Table 2.

For passive discovery, the most consuming radio interface is Wifi in the ad hoc mode with 5% of the battery consumed by the interface after half an hour. This result explains by the amount of signaling messages exchanged between the devices to manage the group, forbidding hardware optimization mechanisms (idle mode) to operate. Signaling being greatly reduced when an access point manages the associations, these optimizations take place in the Wifi infrastructure mode, which is the least consuming interface with only 1.5% of the battery consumed. The Bluetooth interface is commonly known as being more energy efficient than Wifi. This assertion may be verified when comparing the Bluetooth consumption with the measurements in the Wifi ad hoc mode. In its two modes, Bluetooth has a better efficiency with 2.5% of the energy used in the piconet mode and 3% in the PAN mode. Nevertheless, this assertion is no longer true when comparing Bluetooth with Wifi in the infrastructure mode. Indeed, optimizations at the hardware level consisting in putting the interface in an energy saving mode when idled seem to be more efficient on the Wifi interface in the infrastructure mode than on Bluetooth.

As a conclusion, the most energy-efficient medium for passive discovery is the Wifi interface when used in the infrastructure mode. On the other hand, switching this interface to the ad hoc mode renders passive discovery very power consuming and should thus be avoided. When Bluetooth is used for passive discovery, both modes consume almost the same amount of energy.

Measurements for active discovery

We now measure the energy consumption of the different radio interfaces when used to cyclically perform active discovery in order to maintain knowledge of service offers in the course of time as with, e.g., SLP. We simulate a typical real life scenario where a user carrying a handheld device is walking slowly along a corridor. The device cyclically emits discovery requests in order to discover services offered by the devices in the surrounding. The scenario is depicted in Figure 1. In order to simulate this behavior, request/response sequences are processed cyclically on the device. Further- 3.

We may first notice that when small transfers occur periodically, the energy consumption of Wifi and Bluetooth is not influenced by the mode in which they operate. Therefore, even if the volume of data transferred is small, the hardware optimizations in the Wifi infrastructure mode are not able to take place and the measured consumption of the infrastructure mode catches up with the one of the ad hoc mode. Indeed, both modes of the Wifi interface are more consuming than the ones of the Bluetooth interface, with respectively 6.5% and 5.5% of the battery consumed after half an hour. According to these results, active service discovery should be performed via Bluetooth interfaces, in order to optimize energy consumption.

Measurements for services access with sustained transfers

The aim of the last simulation is twofold: to compare consumption of the network interfaces when accessing services where sustained data flows are exchanged, and to verify that our results are congruent with those found in the literature [START_REF]Bluetooth Specification Part E. Service Discovery Protocol (SDP)[END_REF] [START_REF] Akyol | Smart office spaces[END_REF]. In this simulation, we make the handheld device exchange large sets of data back and forth, fully filling its bandwidth during half an hour. More precisely, the device sends a 10 MB file, and then receives back a 10 MB file. The cycle reiterates without delay during half an hour. The measured consumption values are reported in Table 4, along with the volume of data transferred on each interface.

After 30 minutes of data exchange at full rate, the Wifi interface has consumed 8.5% of the battery power, the Blue- tooth interface in the PAN mode has consumed 5.5% and the piconet mode is the most frugal with a consumption of 4.8%. Nevertheless, when looking at the different volumes of data transferred across each interface, it is clear that these measurements cannot be compared as is. As Bluetooth and Wifi have very different bandwidth capacities, the volume of data exchanged during a defined time lapse is disproportioned: the Wifi ad hoc bandwidth is 5 times larger than the Bluetooth piconet bandwidth. It is thus not fair to compare the interfaces by comparing the measured consumptions at full rate. This is a well known problem in the literature.

Work has been undertaken to model the energy consumption of the Bluetooth and Wifi interfaces [START_REF]Bluetooth Specification Part E. Service Discovery Protocol (SDP)[END_REF], and also faced the need to define comparison equivalencies with respect to the asymmetrical bandwidths of the radio interfaces. Nevertheless, no well recognized solution has emerged.

A basic comparison equivalency consists in converting the consumptions of each interface reported in Table 4 into a 100 MB base by applying a golden rule. These values are gathered in Table 5. On the golden rule basis, the cost per megabyte is at least twice lower for the Wifi interface than for Bluetooth. The Wifi interface seems thus much more attractive than Bluetooth for data-intensive applications. Nevertheless, this type of comparison implies that the only source of energy consumption that must be taken into account comes from the emission and reception of packets. The results outlined in the previous section about measurements done after passive discovery show that even when almost no communication occurs on the interfaces, their power consumption is not negligible. We call this value base consumption. Therefore, the energy consumption of an interface is made up of the constant base consumption and of the per-packet consumption relating to the bitrate of the transmission. When comparing the measured consumptions when the interfaces are idle (Table 2) with the measured consumptions at full rate (Table 4), we can see that base consumption represents a large part of the interface's total consumption. Moreover, the golden rule applied on the consumptions at full rate to obtain the power consumptions per 100 MB (Table 5) does not take into account the fact that the global consumption arranges with the base consumption, which is not dependant on the volume of data transmitted. Therefore, in order to refine the approximation operated in Table 5, we must differentiate base consumption and perpacket consumption from the consumptions given in Table 4 before applying the golden rule. Because of hardware optimizations for energy saving, the values measured in Table 2 cannot be used as is as base consumption values. This is particularly true for the Wifi infrastructure mode, as outlined in Table 3, where even if a small amount of data is transmitted, power consumption increases significantly. The base consumption should be measured by transmitting a sufficient volume of data not to let the radio interfaces idle, in order to overcome hardware optimizations, but small enough to negligibly alter the measured consumption with per-packet consumption. These measurements have been obtained by using the same test bed as the one used in the active discovery simulation, but sending only one ping packet every 30 seconds. A ping packet being 84 bytes long, 5 kilo bytes have been sent after half an hour. This is 18 times smaller than the volume of data exchanged for active discovery, and negligible compared to the amount of data exchanged at full rate. The results of this experiment are given in Table 6. The small amount of data periodically exchanged is sufficient to prevent the use of hardware optimizations, as may be seen with the value measured for the Wifi infrastructure mode. This value increases from 1.5% in Table 2 to 5% in Table 6. The alteration of the consumption of the other interfaces is so negligible that it does not affect the other (rounded) values reported in Table 6. This hints that in this simulation the per-packet consumption is negligible; hence the measured consumptions reported in Table 6 are quite precisely the base consumption values of each interface. Once base consumption is known, we may substract it from the consumption measured at full rate in order to obtain the transmission cost. This remaining value may be correlated with the volume of data transmitted from Table 4 to approximate the per-packet consumption.

Finally, by adding the base consumption value from Table 6 with the estimated per-packet consumption, we obtain the global energy consumption given in Table 7. When 100 MBytes are transmitted in 30 minutes, all the estimated global consumption values lie between 6.1% and 6.7% (Table 7, right most column). When taking into account the error rate due to the approximation of the formula, we can conclude that those values are almost identical. The value chosen for comparison (100 Mbytes/30 min., which converts into 450 kbit/s) is the bitrate around which Wifi becomes more energy efficient than Bluetooth. More precisely, the results gathered in Tables 6 and7 characterize the consumption models of the radio interfaces. The base consumption values in Table 6 show that the Bluetooth interface, in the two modes, has a lower base consumption than the Wifi interface, while the per-packet consumption values in the second column of the Table 7 show that the energy consumption of Bluetooth increases faster than the one of Wifi, when the transmission rate increases. According to this model, the power consumption of each interface according to the bitrate may be plotted by a line starting at the base consumption value and whose slope is the per-packet cost. The power consumption curves for each radio interface are depicted in Figure 2. Figure 2(a) shows that the Bluetooth interface is more efficient than the Wifi interface for low bitrates, as outlined by the base consumption values. Nevertheless, as the per-packet cost of the two modes of Bluetooth is more important than the ones of the two modes of Wifi, the consumption lines of the Bluetooth interface abruptly increase and thus the power consumption of the Bluetooth interface quickly overtakes the consumption of the Wifi interface. Moreover, the plot of the Bluetooth curves has been stopped at 1 Mbit/s, as this is the theoretical maximal bandwidth of the Bluetooth interface, whereas Wifi curves go much further, as 802.11b's theoretical limit arises at 10 Mbit/s. The same graphic, zoomed around the cross points, may be found in Figure 2(b). Figure 2(b) clearly shows that the Bluetooth interface is only preferable over the Wifi interface for bitrates up to 380 kbits/s in the piconet mode and 520 kbits/s in the PAN mode. For larger bitrates, the Wifi interface is less consuming than the Bluetooth interface. Of course, the Wifi interface also becomes the sole practical solution when the Bluetooth interface cannot cope with the required bandwidth any more. Globally, even if for very small bitrates the Bluetooth interface is less consuming than the Wifi interface, its high per-packet cost quickly renders the Wifi interface more attractive. Therefore, the Wifi interface should be preferred for services access, as the required bandwidth will most of the time be larger than this cross point. Moreover, if while using the Bluetooth interface, the required bitrate increases over time, one may quickly face hardware non feasibility whereas Wifi could sustain a much larger bandwidth.

Energy-efficient service discovery and access in multi-radio networks

Globally, the most energy efficient operating mode consists in using the Bluetooth interface for discovery, and the Wifi interface for service access. This scenario requires that gateways between the Bluetooth network and the Wifi network be available in the environment, or that all the devices use both interfaces concurrently. These usages are not currently widespread, but are conceivable in specific cases such as enterprise deployment. Nevertheless, such a scheme assumes that every SDP can be used adequately with every radio interface. However, SDPs are designed with a specific networking environment in mind, and thus do not behave the same way on different radio networks. According to its intrinsic specifics, such as its discovery model or networking protocol, a SDP may be technically unusable on a specific radio interface. The next section assesses the features of existing SDPs with respect to the wireless network interfaces composing the multi-radio network in order to rate the adequacy of each SDP against each radio interface.

ASSESSING EXISTING SDPS IN B3G NET-WORKS ENVIRONMENT

Service Discovery Protocols (SDPs) enable finding and using networked services without any previous knowledge of the services' specific location. To provision exhaustive knowledge of the services offered on the reachable wireless networks, a client may need to use several SDPs, which are not identically suited for every radio interface. Some combinations are even technically unbound. Beyond these incompatibilities, a device may offer connectivity to the same part of the network through two different interfaces. SDPs can thus use one or the other to discover available services. A discovery protocol optimized for multi-radio networking should be able to choose the best suited interface according to the SDP to be used. Therefore, it is crucial to rate the adequacy of each SDP against each radio interface.

The Wifi technology has been designed to operate in two different modes: ad hoc and infrastructure. The infrastructure mode may also be split into a "pure" infrastructure mode (access to the local area network) and a hybrid infrastructure + gateway mode (access to the LAN and beyond).

Bluetooth may also be configured into two different operating modes: the "master-slave" piconet mode (the default Bluetooth configuration belongs to this mode), and the IPbased PAN (Personal Area Network) mode. Each of these two modes may also be divided into two. In the piconet mode, a device may provide the "LAN Access" profile, in which case it allows the other devices of the piconet to access the local area network. A node of a PAN can offer the same function, called NAP (Network Access Point). Our analysis thus treats 8 cases of radio interfaces: Wifi infrastructure, Wifi gateway, Wifi ad hoc, Bluetooth piconet, Bluetooth Lan-ap, Bluetooth GN, Bluetooth NAP and GPRS.

Many academic and industry-supported SDPs are available, each with its own features and use case. Among these SDPs, a few ones are more widely deployed and adopted: the second version of IETF's SLP has been standardized in RFC 2608 [START_REF] Guttman | Service Location Protocol, Version 2 . RFC 2608[END_REF]; UDDI (Universal Description, Discovery, and Integration) [START_REF] Clement | UDDI Version 3.0.2[END_REF] is one of the core Web services standards; while Sun Microsystems develops and maintains Jini [START_REF] Waldo | The Jini architecture for network-centric computing[END_REF]; and Microsoft bases its strategy on UPnP [START_REF]Universal Plug and Play Forum. Universal Plug and Play Device Architecture[END_REF]. In an open environment, these SDPs might be often met and should therefore be studied in the context of multi-radio networking. SLP having two different operating modes/architectures, it is divided into two distinct protocols: SLP with Directory Agent (called SLP with DA) and SLP without DA. Bluetooth being one of the studied radio interfaces, the service discovery protocol defined in the Bluetooth standard (Bluetooth-SDP [START_REF]Bluetooth Specification Part E. Service Discovery Protocol (SDP)[END_REF]) is also studied. It is the only SDP that cannot function on IP at all. Finally, even if JXTA [START_REF] Dengler | JXTA v2.0 protocols specification[END_REF] is not just a SDP, but rather a set of open protocols that allow any connected device on the network to communicate and collaborate in a P2P manner, its resource discovery needs be studied as it brings different discovery paradigms and possibilities. We also study the lightweight devices version of JXTA, called JXME [START_REF] Arora | JXTA J2ME Implementation Project[END_REF], whose discovery architecture slightly differs from JXTA's : a JXME peer only addresses one single peer (its proxy), which carries out the discovery and forwards the results. Our analysis thus takes into account 8 SDPs: SLP with or without DA, Jini, UDDI, UPnP, Bluetooth SDP, JXTA and JXME.

We first itemize and describe the SDP features that impact upon SDPs' adequacies against the different radio networks ( § 3.1) and outline the relevant properties of the radio interfaces ( § 3.2). We then present our study, which results in a matrix of values rating the adequacy of each SDP against each radio interface. We carry out this analysis by isolating each feature of the SDPs and by checking its adequacy with the relevant properties of each radio interface ( § 3.3). The aggregation of these results concludes this analysis by providing for each SDP a global adequacy against each radio interface, so that a technical incompatibility with only one of the features gives a null value of adequacy ( § 3.4).

SDP features

The major architectural difference between SDPs concerns the existence of a central repository, and the way service offers are handled. When a central repository exists, the offers are stored and retrieved from this repository, which may possibly be distributed. The architecture is then known as "centralized". When no central repository exists, two cases arise: requests and offers may be directly exchanged from one to all in a peer-to-peer scheme, or discovery is done solely via unicast communications between two devices. In the former scheme, each peer is in charge of caching the received results. We call this architecture peer-to-peer (or P2P). In the latter case, no broadcasting of requests or announcement takes place. Service discovery consists in a single requester directly requesting a specific provider its service offers. Therefore, this architecture is called client/server. SDPs are also aimed at a specific networking environment defined by its size (i.e., small, enterprise or large-size network) and network protocol used. SDPs may or may not allow scalability in terms of number of users and network size. SDPs are further often strongly coupled with some middleware solution forbidding service discovery and access with other middleware.

The features of the studied SDP are characterized in Table 8. It is noticeable that, even if JXTA was designed with the aim of being executed without any dependency on a particular network technology, the porting of the JXTA framework on the Bluetooth stack not being yet operational, the network protocol independence is still theoretical. The SDPs features we have just elicited are the variables rendering the use of each SDP more or less effective with respect to each radio interface. In order to evaluate this level of adequacy, the relevant features of the radio interfaces are discussed in the next section.

Properties of the radio interfaces

Wireless networks appeared in the late 90s, where each radio technology had been designed for a specific usage. Bluetooth was created with "personal area network" in mind, in order to avoid wires between peripherals, Wifi networks were designed in order to replace wired local area networks, and GPRS technology to offer dial-up wide area network access over the GSM network. In the course of time, these technologies have evolved, providing different possibilities than what they were formerly designed for. Nowadays, radio networks even advertise overlapping usages. This characteristic is addressed by beyond 3G networks, where convergence of radio networks should take place in a way that users becomes unaware of the actual radio technology in use. Nevertheless, radio interfaces still have their own specificities, mostly inherited from their previous usage. Table 9 gathers the specifics of the Wifi, Bluetooth and GPRS interfaces that are of interest in the comparison of SDPs, by modifying their behaviors: network scope (vicinity, local area network or beyond), standard network protocol, bandwidth, and financial cost when their use is not free of charge.

As presented in Table 9, GPRS is the interface that has the least evolved from its originating function, as it still gives access to WAN solely, by using IP. Its bandwidth is still very limited (170 kbit/s) and the user must pay while using it according to the volume of data transferred. The Wifi bandwidth continuously increases, ranging nowadays between 11 and 54 Mbit/s. It uses the IP protocol in all its operating modes. In the ad hoc mode, the device has access to the devices in its vicinity, while in the infrastructure mode the interface gives access to the local area network. In these usages, the communications are free of charge. The addition of a gateway allows Internet access (WAN) in the infrastructure mode, but may render the communications lucrative (case of the hotspots where the user is charged according to time). Bluetooth usage is always free of charge and offers a bandwidth of 1 Mbit/s. In the piconet mode, devices in the vicinity are the only reachable ones, using a particular protocol. If one of these devices offers the LAN access profile, it can be used as a gateway in order to reach the machines on the local area network using IP. Although the piconet mode is the default Bluetooth mode, it is however possible to create an IP network between Bluetooth devices in order to create a "personal area network" (PAN). A Network Access Point (NAP) may reside in the PAN network to thus offer to Bluetooth clients an access to the LAN/WAN.

Assessing adequacy of SDPs against radio interfaces

In order to obtain a global level of adequacy for each combination of SDP with radio interface, the correlation of the aforementioned SDPs features with radio interfaces properties must be studied. These observations are translated into numerical values, gathered in matrices, one for each SDP feature, where one cell represents the level of adequacy of one SDP against one radio interface with respect to this feature. These matrices are then aggregated in order to provide each SDP with a global level of adequacy against each radio interface, so that a technical incompatibility with only one of the features gives indeed a null value of adequacy.

Table 10 assesses for each SDP its adequacy with the radio networks of interest, according to the type of network and scope assumed for the underlying network. For each pair (protocol, interface) a note of feasibility is given: 2 if the binding is adequate, 1 if operation is possible but imperfect and 0 if it is impossible. JXTA and JXME being designed to function on networks of any size, all the interfaces are adequate. SLP without DA, UPnP and Bluetooth-SDP functioning on small networks, are suited to Wifi in the ad hoc mode and to Bluetooth piconet and PAN. They can also function in a degraded manner on LAN-type networks (Wifi infrastructure, Bluetooth LAN AP and NAP without gateway) but cannot be used on wide-area networks (GPRS, Wifi with gateway). SLP with DA and Jini function perfectly on average sized networks like LAN (Wifi infrastructure, Bluetooth LAN AP and NAP) and can scale if these networks extend (with a gateway). However, they badly function with interfaces offering only WAN access (GPRS). In the same way, it could be possible to use these protocols on proximity interfaces, even if this case is not adequate (Wifi ad hoc, piconet, PAN).

Table 11 assesses the adequacy of SDPs with radio interfaces according to the supported network protocols. All the SDPs are IP-based, except Bluetooth-SDP, which is based on L2CAP. Even if JXTA, JXME and Jini claim network protocol independence, they currently do not have any usable implementations apart from IP-based. Therefore, all the SDPs except Bluetooth-SDP can be used with GPRS and Wifi in all its operating modes, as they offer IP connectivity. Bluetooth in the PAN mode also offers IP connectivity, while in the standard piconet mode it can only use Bluetooth-SDP. Finally, when Bluetooth is switched in the LAN-AP mode, L2CAP being used to reach the devices in the vicinity and IP to reach the local area network, all the SDPs can be used even if none makes it possible by itself to traverse the whole set of reachable devices. As mentioned in § 3.1, we can classify the studied SDPs into three distinct families according to their architecture: central directory based (SLP with DA, Jini, UDDI, JXME), peer-to-peer directory based (SLP w/o DA, UPnP, JXTA) and directory-less (Bluetooth SDP). The architecture of the SDPs, associated with the location of the directory, may be assessed with respect to the topology of the radio network.

2 w/o DA 2 1 2 1 1,5 1 1,5 1 Jini 2 2 1 1,5 2 1,5 2 2 UDDI 2 2 1 1,5 2 1,5 2 2 UPnP 2 1 2 1 1,5 1 1,5 1 Bluetooth SDP 2 2 2 2 2 2 2 2 JXTA 2 1 2 1 1,5 1 1,5 1 JXME 2 2 1 1,5 2 1,5 2 2
SLP with DA 1 1 1 1 1 1 1 1 w/o DA 1 1 1 1 1 1 1 1 Jini 1 1 1 0,75 0,75 0,75 0,75 0,5 UDDI 1 1 1 1 1 1 1 1 UPnP 1 1 1 1 1 1 1 1 Bluetooth SDP 1 1 1 1 1 1 1 1 JXTA 1 1 1 1 1 1 1 1 JXME 1 1 1 1 1 1 1 1
The centralized architecture of the SDPs with directory is particularly suited to asymmetrical networks (i.e., all the links of these networks do not share the same characteristics, in particular considering bandwidth limitation) such as GPRS, Wifi infrastructure with gateway, BT-LAN AP and BT-NAP. On these networks, the wireless edge link on the device side typically has a lower bandwidth than the network to which it is inter-connected (GPRS/Internet, Bluetooth/LAN). The centralized architecture limits the volume of communication on this link, as only messages relevant for the client are exchanged between the device and the repository. Moreover, there exists a "logical" optimal location for the directory: on the gateway (offering the LAN-AP service or NAP, on the GPRS proxy or on the Wifi gateway). Operating centralized SDPs on peer-to-peer type networks (Wifi ad hoc, BT piconet, BT GN) is possible but less suitable. There is indeed no logical location for the directory, since by definition all peers are equal and no device should have a particular role. Bluetooth SDP, which belongs to the client/server family, is a case apart since this protocol neither stores the offers in a directory nor performs peer-topeer exchanges of the advertisements. The only authorized discovery is done by unicast communication between one client and one provider. This simplistic discovery model, particularly suited to the mode of communication used by Bluetooth, does not induce nor is based on any architecture or particular network topology. The only need is that the two devices can reach each other. This protocol is thus appropriate to all the cases. Finally, the Wifi interface in the infrastructure mode is also apart. At first sight, the infrastructure type architecture seems asymmetrical, since an access point acts as a gateway between wired and wireless networks. Thus, SDPs with centralized directory find there a logical location. Nevertheless, nowadays, the characteristics of the wired and Wifi wireless networks are generally rather close. Moreover, the aim of this operating mode is to combine wireless sub-networks with the local area network. From this point of view, the network appearing homogeneous, SDPs with peer-to-peer directory find there a logical operation land. The Wifi infrastructure interface is thus adapted, from the architectural point of view, to both centralized and peer-to-peer SDPs.

Meanwhile, it is necessary to refine the former assessment by also taking into account the broadcasting models and protocols of the SDPs and radio interfaces. If a packet emitted on an ad hoc Wifi network is inevitably received by all the other devices in range, the Bluetooth standards only allow one-to-one communications. Therefore, a "one-to-all" communication must be simulated by several successive unicast transmissions, multiplying the cost of communication. This reveals that directory-less SDPs are better suited to ad hoc Wifi networks, while directory-base SDPs are preferable for the Bluetooth "proximity" scope (piconet and GN). In the case of Bluetooth LAN-AP and NAP, multicast and broadcast cannot be realized between Bluetooth devices, but can be initiated between the gateway and its connected networks. Table 12 presents the refined assessments with respect to the broadcasting models.

Bandwidth is not a de facto discriminating factor in the field of services discovery, as discovery only requires low bandwidth. Bandwidth may however be determinant for service access. All the protocols do not propose a particular access mechanism, and thus cannot be compared on this point. Nevertheless, a particular case arises: Jini. Indeed, as Jini replies to discovery requests by using a code mobility mechanism, service discovery may become expensive in terms of volume of data to be transferred. Jini is thus not indicated when the user has to pay according to the volume of data transferred (GPRS) or when the bandwidth is restricted (GPRS, to a lesser extent Bluetooth). Therefore, the bandwidth factor does not exactly represent the adequacy according to access mechanism. Its aim is rather to operate a decrease in the global rating reflecting the preceding remarks. Table 13 reflects this observation, as default adequacy values according to bandwidth are set to 1, and a small decrease is operated for Jini against GPRS and Bluetooth values.

Matching SDPs against radio interfaces

In order to obtain a global quantitative rating, providing for each SDP its adequacy against each radio interface, we aggregate all the adequacy values from Tables 10 to 13 by operating the scalar product of these matrices, so that a technical incompatibility with only one of the features gives indeed a null value of adequacy. We thus obtain a matrix of global adequacy represented in Table 14. Each value indicates the level of suitability between a SDP and a radio interface. The higher the value is, the more relevant the use is. The pairs evaluated with the maximum rating (maximum is 8) have a perfect adequacy and should be privileged when their use is possible. Finally, the intermediate values greater than 0 indicate that the use is technically possible, although not being perfectly appropriate.

On the 64 (SDP, radio interface) pairs, 18 obtain the maximal adequacy value and 13 are totally incompatible. The SDP obtaining the best average adequacy is JXME, since it has a perfect adequacy with half of the interfaces. Its operating mode being based on JXTA with added optimizations for embedded devices, it supersedes this one in the context of this study. JXTA logically ranks in second position. JXTA and JXME are the only two SDPs that do not present incompatibility with any radio interface at all. Among the other SDPs, SLP with DA obtains the best adequacy rating, but is incompatible with Bluetooth in the piconet mode. Bluetooth-SDP is logically found as the least adequate, since it is not IP-based and is thus incompatible with the Wifi and GPRS interfaces. It is nonetheless notable that if SLP obtains a very good adequacy when used in the directory mode, this protocol used without directory decreases its rank to penultimate, with the same rating as UPnP.

The SDPs adequacy against radio interfaces matrix characterized in Table 14 may also be read the other way round, in order to estimate the adequacy of the radio interfaces when they are to be used with several SDPs. The interface having at the same time the strongest global adequacy and the largest count of maximal adequacy cases is Wifi in the infrastructure mode. It is closely followed by Bluetooth NAP, which has less SDPs with perfect adequacy (3 against 5) but more homogeneous results: on this interface, no SDP is rated with a null adequacy. Bluetooth piconet has at the same time the worst average adequacy and the greatest number of total incompatibility. It is followed by GPRS for which 3 SDPs are incompatible, and only one SDP (JXME) offers a perfect adequacy. When taking into account the physical radio interface by combining the operating modes, Wifi is the interface with the greatest number of perfect adequacy cases. This interface is thus the least expensive to carry out discovery with a large set of SDPs. However, we can also notice that Wifi does not authorize discovery with Bluetooth-SDP at all. From this point of view, Bluetooth is the only radio interface that allows discovery with all the SDPs, since 3 out of its 4 architectures are compatible with the full set of SDPs, even if the adequacy is not perfect. However, the default Bluetooth architecture (piconet) is the interface with the greatest number of incompatibilities since only Bluetooth SDP and JXME (with a weak adequacy for the latter) functions. Moreover, piconet is the default Bluetooth mode and switching the Bluetooth interface to one of the 3 other modes rather depends on the availability and capabilities of the other devices in the vicinity than on the client device itself.

CONCLUSIONS

B3G networks combine multiple wireless networking technologies in order to benefit from their respective advantages and specificities. The increase in computing and communication capacities of portable devices, as well as their mass marketing, allows envisaging the widespread deployment of multi-networks pervasive environments. The emergence of such ambient networks opens new challenges and issues in the development and deployment of distributed systems. A user having a multi-radio capable device benefits from such an ambient network by increasing the perimeter of reachable service providers, at the expense of a higher network management complexity. This complexity, induced by the heterogeneity of the wireless technologies, should be hidden to the user and, to be effective, to the application (e.g., by a middleware solution). In a pervasive environment, services must first be discovered using SDPs. Several SDPs are currently in use, and each one has been designed with specific target network architecture and mode of operation. This leads to another important heterogeneity which must be taken into account. This paper presents two studies needed for multi-radio service discovery in order to exploit the various networks while overcoming SDPs heterogeneity. These two studies assess the two main criterias to be taken into account in order to optimize multi-radio service discovery: energy saving, which is a major issue for battery-powered devices, and the adequacy of SDPs against multi-radio networks. To the best of our knowledge, no other work about energy consumption of radio interfaces has taken into account the specific case of service discovery, and SDPs have never been assessed with multi-radio networking in mind.

Our first study, which measures the power consumption of wireless interfaces during service discovery and access, has shown that the most appropriate case would consist in discovering services via the Bluetooth interface, and access them via the Wifi interface. Meanwhile, this perfect case is not always feasable as: (i) both connectivities are not always available, (ii) when they exist, they do not always reach the same networks and devices, (iii) most of the SDPs have been designed with one networking technology or architecture in mind and may thus be so inefficient when operated on another radio interface that the most efficient solution would be to use another more energy consuming radio interface. Thus, the second study takes into account the specificities of the main SDPs and discussed how they behave when operated on each wireless interface. In order to transpose these qualitative observations into parameters usable by an adaptive algorithm, we inferred quantitative values reflecting the adequacy of use of each SDP against each radio interface.

We are currently using the results of these two studies for the development of a middleware solution for embedded devices. This middleware integrates an adaptive service discovery, which effectively exploits the various networks and SDPs found in the pervasive environment, while hiding the network complexity. It continuously provisions services and stores a list of the retrieved offers on the client in order to minimize the response time of the client's discovery requests, and also takes care of updating the local knowledge over time to reflect the dynamicity in the services offer.

Figure 1 :

 1 Figure 1: Scenario for active service discovery

  (a) Power consumption of the radio interfaces after 30 min. according to bitrate. Scale : Wifi bandwidth (b) Power consumption of the radio interfaces zoomed around Bluetooth bandwidth

Figure 2 :

 2 Figure 2: Power consumption of Bluetooth and Wifi interfaces according to bitrate

Table 1 : Base consumption without radio interface

 1

	Interface	Consumption (%)
	Without radio interface	7.5

Table 2 : Consumption of each radio interface for passive discovery

 2

	Interface		Consumption (%)
	Wifi	Ad-hoc	5
	Infrastructure	1.5
	Bluetooth	Piconet	2.5
		PAN	3

Table 3 : Consumption of each radio interface for active discovery

 3

	Interface		Consumption (%)
	Wifi	Ad-hoc	6.5
	Infrastructure	6.5
	Bluetooth	Piconet	5.5
		PAN	5.5
	more, the volume of data exchanged is in the order of mag-
	nitude of the mean volume of data transferred by the leading
	SDPs (i.e., 1.5 kilo byte). Indeed, request weights 500 bytes
	and response messages are 1 kilo bytes long. The period be-
	tween two sequences lasts 30s, which allows effectively tak-
	ing into account the dynamicity of the service offers in an
	evolving environment, and also represents for a slowly walk-
	ing human about 16 meters traveled, which corresponds to
	the emission range of Bluetooth emitters placed in desks as
	in, e.g., smart spaces. Like the previous measurements, we
	let the simulation run for half an hour. Results are given in
	Table

Table 4 : Power consumption and data transfer.

 4

	Interface		Consumption Volume
	Wifi	Ad-hoc	8.5 % 270 MB
	Infrastructure	8.5 % 250 MB
	Bluetooth	Piconet	4.8 %	54 MB
		PAN	5.5 %	80 MB

Table 5 : Power consumption per 100 megabytes

 5

	Interface		Consumption (%/100 MB)
	Wifi	Ad-hoc	3.1
	Infrastructure	3.4
	Bluetooth	Piconet	8.8
		PAN	6.9

Table 6 : Base consumption for each interface

 6

	Interface		Consumption (%)
	Wifi	Ad-hoc	5
	Infrastructure	5
	Bluetooth	Piconet	2.5
		PAN	3

Table 7 : Transmission and global consumptions per 100 MBytes for each interface

 7

				Per-packet	Global
			Transmission consumption consumption
	Interface		overhead (%)	(%/100MB)	(%/100MB)
	Wifi	Ad-hoc	3.5	1.3	6.3
	Infrastructure	3.5	1.4	6.4
	Bluetooth	Piconet	2.3	4.2	6.7
		PAN	2.5	3.1	6.1

Table 11 : SDPs vs. Network protocol

 11

			Wifi			Bluetooth		GPRS
		Infrastructure Ad hoc		piconet	PAN
			gw			LAN-AP GN NAP
	SLP with DA 2	2	2	0	1	2	2	2
	w/o DA 2	2	2	0	1	2	2	2
	Jini	2	2	2	0	1,5	2	2	2
	UDDI	2	2	2	0	1	2	2	2
	UPnP	2	2	2	0	1	2	2	2
	Bluetooth SDP 0	0	0	2	1	2	1	0
	JXTA	2	2	2	0,5	1,5	2	2	2
	JXME	2	2	2	0,5	1,5	2	2	2

Table 12 : SDPs vs. Architecture -refined

 12

		Wifi			Bluetooth	GPRS
	Infrastructure Ad hoc		piconet	PAN
		gw			LAN-AP GN NAP
	SLP with DA 2	2	1	1,5	2	1,5	2

Table 13 : SDPs vs. bandwidth usage

 13

	Wifi	Bluetooth	GPRS
	Infrastructure Ad hoc	piconet	PAN
	gw	LAN-AP GN NAP

Table 14 : Global SDPs / radio interfaces adequacy

 14

			Wifi			Bluetooth		GPRS
		Infrastructure Ad hoc		piconet	PAN
			gw			LAN-AP GN NAP
	SLP with DA 8	8	2	0	4	3	8	4
	w/o DA 4	0	8	0	1,5	4	3	0
	Jini	8	8	2	0	4,5	2,25	6	2
	UDDI	8	8	2	0	4	3	8	4
	UPnP	4	0	8	0	1,5	4	3	0
	Bluetooth SDP 0	0	0	8	2	8	2	0
	JXTA	8	4	8	1	4,5	4	6	4
	JXME	8	8	4	1,5	6	6	8	8

* This work is supported by Alcatel Research & Innovation France


Marcus Nóbrega
email: marcusnobrega@usp.br

Eduardo Mario Mendiondo

César Marina Batalini De Macedo

Ambrogi Ferreira

Do Lago

César Ambrogi

Marcus Nóbrega Gomes Júnior

Marina Batalini De Macedo

César Ambrogi Ferreira Do Lago

Bioretention sizing criteria for synthetic storms by hydrologic and hydraulic simulation

Keywords: Bioretention sizing, Chicago hyetograph, Flood routing, Green-Ampt, Unit Hydrograph

come

INTRODUCTION

A common problem in unplanned cities is to the growth in imperviousness. River rectification has been usually done diminishing concentration times and improving the drainage capacity. This risk-transfer solution does not solve the problem. An alternative solution is to use compensatory techniques (CTs) to reestabilish the previous natural condition. For instance, detention ponds can be placed downstream to diminish peak flow. Usually, once detention ponds are considered for big catchment areas, more complexity is added due to needed geologic, structural, environmental hydrologic and hydraulic projects, which could make it a punctual and expensive solution. (MIGUEZ, 2016).

Other kinds of compensatory techniques are described in the literature, as Low Impact Development (LID) used in several countries like in the United States, Canada and New Zeeland, according to [START_REF] Fletcher | SUDS, LID, BMPs, WSUD and more-The evolution and application of terminology surrounding urban drainage[END_REF]. Those incorporate infiltration retention and detention techniques such as infiltrations ponds, rain gardens, green roofs, detention and infiltration swales and other types of infiltration/detention structural measures. These techniques aim to diminish the impact of increasing peak flow generated by the post urbanization and to improve the quality of storm water. These approaches improve runoff quality and quantity and can be used in non-consumptive purposes.

Regarding bioretention cells, there is no clear manual for methods, criteria or regimentations for sizing and projects in Brazil. On the other hand, countries as Australia, United States and United Kingdom, have sizing manuals for LID practices including rain gardens or bioretention cells since the 90's. (PRINCE GEORGE'S COUNTY DEPARTMENT OF ENVIRONMENTAL RESOURCE, 2002; VIRGINIA DEPARTMENT OF CONSERVATION AND RECREATION, 1999).

However, apply worldwide developed criteria, which its majority has been made for different climate conditions, land use occupation patterns and different weight in objectives could not be the best approach. For example, in Brazil, maybe is more important a peak flow reduction than in other countries with more developed cities designed to have more resilience to flood mitigation.

Therefore, this work aims to develop a sizing method for bioretentions considering rain patterns of subtropical climate. This method has been used to design a bioretention in a lot-scale for actual experimental objectives. From monitoring, modelling and calibration, it will be possible to evaluate the sensitivity of key-parameters to objectives, such as the outflow peak and time.

HYDROLOGIC AND HYDRAULIC BIORETENTION SIZING CRITERIA

It is necessary develop a hydrologic and a hydraulic model to evaluate the performance of a bioretention cell. Metrics such as the quantity of water that passes through the filter media and the spill, the maximum outflow peak and time could be indicators of efficiency. Usually, bioretention cells are used for relative small catchment areas, e.g roofs catchments. So, rational method as a rain-flow model is feasible for hydrologic method. On the other hand, temporal variation of precipitation could be evaluated with an adapted Chicago hyetograph (main intensity in the half of the rainfall, which can be applied for subtropical climate) method combined with Soil Conservation Service method and unit hydrograph to assess the possible bioretention efficiency.

Before the start of the hydraulic model, its necessary calculate infiltration rates and volumes in every time-step which is data entry for hydraulic simulation. The model used to estimate infiltration rate was the Green-Ampt, a physically based model. [START_REF] Green | Studies on Soil Phyics[END_REF].

For hydraulic simulation, a modified flood routing was used, based on [START_REF] Akan | Urban stormwater hydrology: a guide to engineering calculations[END_REF]. The difference is the necessity to develop an auxiliary table relating the storage and the outflow for each height of saturation zone. Figure 1 shows a schematic flowchart to develop the hydrologic and hydraulic models.

P f TR, IDF, t

(1)

Q f CN, P, A (2)
T min C f θ , θ , K , ω, P ; ∆P ∆h , ∆t

(3)

Q f Q , T , h, h , ϕ (4)
Where Ci is the infiltration capacity, ∆Pi is the rainfall variation in a time step i, ∆hi is the ponding depth variation.

Figure 1 -Flowchart of bioretention simulation model for a design storm. S is the real storage in a control volume in red, A is the surface area in yellow, h is the height considering the referential in the technique bottom, hs is the spill elevation, cyan continuous line is the hole outflow, blue dashed line is spill outflow, Tx is infiltration rate per time in brown continuous line, Qin is the inflow modelled through a hydrologic synthetic model, ∆t is the step-time assumed for the simulation, Qout is the sum of spill and hole outflow in the time t, Qh and Qs is the outflow of hole and spill respectively, ∆Q is the decrease of peak flow and ∆tp is the increase of peak time.

CASE STUDY

In order to size a bioretention cell to catch a roof with 94m², CN = 98, C = 0.95, were used in the designed model to size a 6m² bioretention cell, receiving stormwater. The outflow hydrographs were compared to pre-development maximum flow rate. A 1-meter height bioretention was set and composed by 0,4m of gravel and 0,6m of sand with an average saturated conductivity of 24cm/h. A 0,6m ponding depth located in the top of sand layer was defined to retain more water during intense storm events. The matric pressure was estimated as 4.9 cm of water. We considered 0,47 for the saturated soil moisture and 0.06 for the initial soil moisture. The spill elevation is defined in the top of ponding depth and is considered as a triangular spill. The perforated pipe in the technique's bottom presented 32mm of diameter.

Considering the technique initially 50% saturated it is possible do the simulation for a 2 hour 10-year storm using Chicago adapted hyetograph. The SCS-CN hydrograph was used as an input to PULS method modified with Green-Ampt.

SIMULATION

Figure 2 shows the simulation results. It shows that the system was filling up in the first 80 minutes due to the initial 50% saturated conception. The maximum inflow did not match with maximum outflow and seems proportional with the volume in the control volume. It implied in more hydraulic head in the perforated pipe, which caused a peak flow nearby 100min. Table 1 shows the sizing indicators of the bioretention efficiency.

CONCLUSIONS

The proposed method needs to be calibrated with real data to evaluate its capacity to predict outflow. The accuracy of outflow is important to verify its reduction and the technique's capacity to reestablish pre-urbanization flow. The results showed that a smaller bioretention could be designed for this case, however the ponding depth was almost in the limit (60cm). We recommend simulate a 2 hour-15,20,25 year-storm and assess the outflow hydrographs for further research. The comparison with the preurbanization hydrograph of extreme events are important to evaluate the impacts and resilience of a lot scale LID.


Damien Fournier

Sonia Ben Mokhtar

Nikolaos Georgantas

Valérie Issarny
email: valerie.issarny@inria.fr

Val Érie Issarny

Sonia Ben Fournier

Nikolaos Mokhtar

Georgantas

Towards ad hoc contextual services for pervasive computing

Keywords: H.1 [Information Systems]: Models and Principles; D.2.11 [Software Engineering]: Software Architectures Context-awareness, Pervasive Computing, SOA

come

INTRODUCTION

Context awareness and management are challenging requirements for pervasive computing decisively affecting the user's experience [START_REF] Saha | Pervasive computing: A paradigm for the 21st century[END_REF]. Nowadays, many applications using context information are proposed (e.g., healthcare monitoring, personalized service delivery). Context management gives to applications the aptitude to be aware of user characteristics, system behavior and state of the physical environment [START_REF] Dey | Providing architectural support for building context-aware applications[END_REF]. These applications, qualified as context-aware, are able to adapt dynamically their behavior according to user requirements and/or environment.

Emergence of service-oriented computing as a well-serving paradigm for pervasive environments has indicated a tight association between pervasive context and services. To this end, several service-oriented middleware architectures have been proposed dealing with one or more of: context identification and description; context retrieval, processing and storing; reasoning on context; context-aware service description, discovery and selection; and context-aware service adaptation (e.g., see [START_REF] Baldauf | A survey on context-aware systems[END_REF] for a survey). In these architectures, a number of functional entities have been identified participating in the generation, management and use of context. Context sources (e.g., sensors) provide a specific type of context information. Context aggregators and interpreters compile and process context information to make it available in an elaborated, added-value form. Context repositories organize and make context information accessible, further supporting reasoning for answering complex context-related queries. Context-aware services and their clients are matched andif needed -adapted to each other by context-aware service discovery and adaptation mechanisms.

A key point to all aforementioned functionalities is the description of context, where the paradigm of choice in most approaches is ontologies coming from the knowledge representation domain. Ontology languages are employed to enable common understanding of context semantics and reasoning on complex relations between contextual concepts. Further, of major interest is the distribution of contextaware architectures. We observe two directions for managing context information. First, context management support may be limited to a specific physical environment, such as home or office. We define these physically delimited environments as pervasive spaces. In this case, context information is conveniently managed by a (logically) centralized system, while mobile devices (PDAs, smart phones) supporting user applications are consumers of such information. The second approach lies in delegating context management to (end-user) devices so that devices have access to context information in any environment. In this case, each pervasive device is responsible of its context. Each device then supports local context management, independent of any infrastructure, possibly collaborating in an ad hoc way with peer devices to enrich its context knowledge. Accordingly, context-aware service discovery, selection and adaptation may be executed in a centralized or decentralized way, where the former asks for a context management infrastructure provided by the pervasive space, and the latter relies on the individual pervasive devices. Architectural and functional distribution further affects consumption of context information. RPC or event-based interaction may be employed for retrieving specific context information and for invoking context-aware services, while ontology-oriented query languages may be employed for conveying complex context-related requests (e.g., see [START_REF] Pawar | Ontology-based context-aware service discovery for pervasive environments[END_REF]).

Understanding context-aware architectures for pervasive computing with respect to all the above discussed features is the main focus of this paper. First, we briefly survey related research approaches, summarizing key aspects underlying context awareness, from context sources to context management (Section 2). A major outcome of our survey is that all reviewed approaches commonly assume -each -a homogeneous context-aware architecture, where immediate compatibility of functional and knowledge-related entities assured by design. However, the openness and high dynamics of pervasive environments make such an assumption too restrictive. In these environments, heterogeneity may arise in any of the above discussed features of context-aware architectures. Hence, we envision a service-oriented middleware approach allowing for ad hoc context-awareness in pervasive environments, where context-related entities -all taking the form of contextual services -dynamically self-organize and self-adapt to optimally exploit available, possibly heterogeneous, contextual resources at the specific time and place. Major challenges in this approach are adequate semantic description of contextual services and principally of their role in context awareness (i.e., from context source to context consumer), and, based on this description, self-organization including contextual service discovery, composition, adaptation and interaction. As a first step towards this objective, we elaborate a conceptual model in UML representing key context-aware system concepts as elicited from our survey; we further inject in this model our vision of ad hoc contextawareness (Section 3). We finally conclude in Section 4 presenting our plan of ongoing and future work.

CONTEXT AWARENESS

A context-aware pervasive environment is made of software applications that execute opportunistically according to user presence and networked resources. Applications are further able to adapt to the physical space and to available hardware and software resources, always aiming at providing best user experience. Devices of the context-aware pervasive environment then exchange diverse context information through the network.

Taxonomy of Context Information

Context information is usually classified in three subsets, called context domains [START_REF] Schilit | Context-aware computing applications[END_REF]: user domain, system domain and physical domain. The user domain provides knowledge enabling applications to adapt their behavior according to the profile of their users. For example, if the user is blind, applications can sense this information by getting the description of the user handicap and then adapt their user interface so that speech is chosen as the interaction modality. As another example, a context-aware video player can read the user profile to check if the user is allowed to watch the video content according to the user's age. User-related context information further subdivides into subjective and objective user context. The former defines the user's personality and psychology, corresponding to user mood and feeling (fear, anger). The latter includes the following information:

• Personal information provides data allowing identification of, and communication with, the user such as, first name, last name, birth date, home address, etc. Communication-related information accounts for the various communication networks (providing, e.g., phone number, email address, instant messaging nickname), further enabling to choose the most appropriate communication means according to network connectivity and other relevant context data.

• Physiology and condition information defines height, weight, eyes color, health (ill, tired, stress), etc., which may in particular be exploited by healthcare or diet coach applications. • Finally, agenda-related information defines user activities over time, enabling the system to adapt communication/interaction modalities (e.g., switching off ring tone while attending a meeting), and in general inferring various information and actions (e.g., knowing about the user's location).

The system domain describes digital, software and hardware resources available to users. Applications use description of devices features and resources characteristics to adapt system behavior, alter content, or modify user interfaces [START_REF] Chaari | Service-oriented context-aware application design[END_REF]. For example, a video player application can display content on the largest screen available in the room where the user is located but once another user enters the room, the content is displayed on the user's mobile device and adapted according to screen resolution. In order, to adapt application behavior according to devices, the system domain usually combines description of hardware and software components available in the context-aware environment. Typically, this description specifies:

• Processing power (e.g., CPU type and frequency, RAM available, energy source and autonomy).

• Hardware components, including input/output peripherals attached to the device. Typically, their description provides information about screen quality, printer and scanner resolution, etc.

• Network interfaces to connect the device to the various networks, both wired and wireless. This description includes network interface name, network type, available protocols, hardware and logic address, and bandwidth.

• Storage system (e.g., partitions, files system, capacity).

• Software components like operating system and virtual machines.

Finally, the environmental domain deals with the description of location and of conditions of the physical environment. User mobility or natural variation of physical conditions (e.g., brightness or temperature) can impact application behavior within a context-aware environment. The environmental domain describes locations where users and devices are physically situated. It allows retrieving the user and possibly adapting the physical environment (with physical actuators) according to the user's preferences. The environmental domain subdivides into three sets of context information:

• Physical geography provides description of locations with room name, building type, postal address, absolute coordinate, for indoor environment, and GPS coordinate, road, for outdoor environment.

• Physical conditions provide description of outdoor weather condition (wind, sun, rain, temperature), and of sensing conditions such as brightness, ambient noise, humidity.

• Chronology defines timing information such as time zone and time of the day.

Context Representation

To be effectively managed, context information need be modeled in a uniform way so that it can be unambiguously interpreted and further combined. Six models dominate in the literature for context representation [START_REF] Strang | A context modeling survey[END_REF]:

• Key-Value models represent context information using a set of attributes and their associated values. It is the most simple data structure used in context-aware applications.

• Markup models enable structuring context information into a hierarchy. Tags describe context attributes and associated values. Using tags recursively permit classifying context into data subsets.

• Graphical models are suitable for expressing relationships between context entities, as illustrated in [START_REF] Henricksen | A software engineering framework for context-aware pervasive computing[END_REF].

• Object models take benefits of the object-oriented paradigm to represent context information as object variables, and structure this information into object classes [START_REF] Hofer | Context-awareness on mobile devices -the hydrogen approach[END_REF]. Object oriented models add the possibility to mix context processing with context data.

• Logic models represent context in terms of facts and rules. They are used to infer new statements about context information.

• Ontologies benefit of both logic and object orientation. They enable representing context using classes and explicit relationships among them.

Basically, to structure sensed values into context information, each piece of context data must be precisely characterized. Context values are usually described with metadata [START_REF] Korpipaa | Managing context information in mobile devices[END_REF]. Main attributes associated with a context value are: (i) the context domain (see §2.1), and (ii) the context type that refers to subsets belonging to the context domain. Sometimes, the context type is written with a path expression, to describe the "type" attribute within a hierarchy [START_REF] Korpipaa | Managing context information in mobile devices[END_REF][START_REF] David | Wildcat: a generic framework for context-aware applications[END_REF]. In order to add precision to context information, more sensing details are needed such as:

• The context source attribute refers to the sensing service that gives context values related to, e.g., physical sensor, device or application.

• Related to the context source, the quality attribute gives details about sensing mechanisms, usually related to accuracy, timeliness or confidence of context source. It can be used to adapt context processing and exclude inaccurate sources.

• The metric attribute defines the data type and unit of context values, enabling applications to instantiate and process context information.

• The timestamp attribute is essential to capture history of context values and infer information over a time period, or to check up-to-datedness.

• The relationship attribute enables linking correlated context information, making explicit impacts of sensed values on other context information, or defining interaction between users, devices and the physical environment. For example, when a user turns on his mobile phone, interaction of the user with the mobile device can be specified by the relationship "use".

Associated with values, metadata gives details about the nature of context information. Metadata is used by the context management system to process and deliver context information to applications. The context manager hides details of sensing to applications and provides valued context attributes according to application requests.

Context Management

Initial research on context-aware systems focused on building applications for a specific scenario or a specific context, leading to develop application-specific context manager. This approach is often illustrated by location-aware systems. For example, the Active Badge system forwards phone calls according to the user location in the Olivetti research laboratory [START_REF] Want | The active badge location system[END_REF]. Some of these applications are also implemented as tourist guide, such as Cyberguide [START_REF] Abowd | Cyberguide: a mobile context-aware tour guide[END_REF] and the GUIDE project [START_REF] Cheverst | Experiences of developing and deploying a context-aware tourist guide: the guide project[END_REF]. Due to their specific nature, these solutions provide limited support to generic context management that can be reused across context-aware applications.

To ease the development of context-aware applications, dedicated frameworks have been proposed. Those frameworks provide reusable context components that are responsible of data acquisition, aggregation and interpretation. Context components provide a public interface for accessing context data, while they hide details of context sensing. For example, the Context toolkit introduces context components, called context widget [START_REF] Dey | Providing architectural support for building context-aware applications[END_REF]. The contextor infrastructure further assists the composition of context components [START_REF] Rey | The contextor: a computational model for contextural information[END_REF]. Specifically, the context information is managed by contextor components, which provide communication channels for the exchange and control of context data. The assembly of contextors is ruled by a data-flow model. The composition of contextors may be static (specified at design-time), semi-static (specified at run-time), or transient. In general, framework-based approaches for context management greatly ease development of context-aware applications. They abstract details of sensing and transform observables into values that are processable by applications. Still, making applications context-aware requires developing applications with the specific frameworks and further having the specific context components actually deployed in the environment.

Availability of context information may greatly be improved through the deployment of context servers within the network(s). Context servers may be requested for context information by any networked client application. Typically, this solution is based on an infrastructure for sensing and reporting context to the context server. The context server then stores and interprets context information reported by sensing applications deployed into a physical environment (such as home, office, hospital). This approach eases sharing of context information among applications, as illustrated by [START_REF] Gu | A service-oriented middleware for building context-aware services[END_REF] and Cobra [START_REF] Chen | Semantic Web in in the Context Broker Architecture[END_REF]. The COntext Broker Architecture (CoBra) is composed of a context server and modules responsible of data acquisition [START_REF] Chen | Semantic Web in in the Context Broker Architecture[END_REF]. Similarly, the Service-Oriented Context-Aware Middleware (SOCAM) introduces an infrastructure to manage context; it further undertakes a service-oriented approach with context acquisition and interpretation being deployed on an OSGI-based residential gateway [START_REF] Gu | A service-oriented middleware for building context-aware services[END_REF].

We notice that more recent solutions extend the serveroriented approach to context management to a P2P architecture. Every computing device (PDA as well as desktop) becomes responsible of managing part of context information and peering with others to enrich the context knowledge base. This approach is illustrated by the AWARE-NESS project 1 , where mobile and desktop devices are able to acquire, interpret and exchange context data. Compared to the base server-oriented approach, this empowers mobile terminals with the ability to support context-aware applications even when no context server is available in the networked environment.

CONTEXTUAL SERVICES

As surveyed above, context-awareness requires dealing with diverse sources of context information and making available related knowledge to applications. Then, developing context-aware applications can be tractable only if provided with adequate middleware support for managing context information, from acquisition to storage. Also, key middleware functions shall be made context-aware (e.g., contextaware service discovery [START_REF] Pawar | Ontology-based context-aware service discovery for pervasive environments[END_REF][START_REF] El-Sayed | Semantic-based context-aware service discovery in pervasive-computing environments[END_REF] as well as context-aware interaction). However, context-awareness shall not be bound to a specific software infrastructure or physical environment. Context-awareness shall be made available in most environments, thanks to the ad hoc networking of context sources and consumers. Such open networking is enabled by the service-oriented architecture paradigm, further backed by semantic Web technologies for making services interoperable. In addition, semantic services may be conveniently exploited in the pervasive computing environment through adequate lightweight middleware for wireless, resource constrained devices [START_REF] Mokhtar | Efficient semantic service discovery in pervasive computing environments environments[END_REF]. Building upon the above effort, we are investigating the development of contextual services for pervasive computing. Specifically, we call contextual ser-1 AWARENESS Consortium. Context AWARE mobile NEtworks and ServiceS, http://awareness.freeband.nl/ vice, a semantic service that realizes a context source and/or a context consumer. A contextual service further opportunistically networks/composes with other contextual services to offer a richer context knowledge base, as network connectivity allows. Towards the development of a contextual service-oriented architecture, and in particular related middleware support, this section elicits key architectural elements underpinning context-awareness, i.e., context sources ( §3.1), context consumers and related communication protocols ( §3.2), and context-aware services ( §3). Elements are further introduced using UML models so as to highlight the relationships among them.

Context Sources

Figure 1 models major context sources, as identified in Section 2.1. Specifically, context sources may provide information relevant to the user, system and physical domains.

The physical domain is dependent upon physical sensing of the environment by sensors, which may possibly be organized into dedicated networks. Sensed values related to the same physical data (e.g., temperature in a building sensed in various rooms) may further be aggregated (e.g., sum, average, . . . ). Given some sensed value, the interpreter service encodes it as a structured context data according to a target/reference ontology (see §2.2).

The context repository is the service responsible for the storage of context information. It typically stores information from the various context sources networked in the environment. Additionally, the context repository possibly manages a rich knowledge base by inferring new context information from the known context, thanks to the context reasoner. Typically, a context reasoner uses logic inference and reasoning mechanisms to deduce new context information. In general, services implementing context sources shall network and cooperate opportunistically so as to make the knowledge base available to applications as rich as possible. This may be coordinated by context repositories -if anyfor the sake of resource savings. However, the actual cooperation protocol among context sources shall be determined dynamically according to various non-functional attributes, like availability, performance and privacy. All the context sources, i.e., user profiling, system profiling, interpreter, context repository, and context reasoner services, handle context requests. Such requests may simply provide context types as input. Alternatively, they may express complex queries over the knowledge base using, e.g., SPARQL2 .

Context Consumption

As modeled in Figure 2, context sources may be accessed by context consumers using various protocols:

• RPC-based interaction is the most basic type of interaction, with the consumer requesting for a given context information. As such, it favors reactive contextawareness. In this case, the dynamics of the context information need be specified, using, e.g., timestamp attributes ( §2.2).

• Event-based interaction allows for both reactive and proactive context-awareness, with the consumer being notified of requested context information upon given conditions (e.g., at regular time intervals, update since last notification).

• P2P interaction allows for advanced distributed context management, favoring ad hoc composition of context sources.

Context Aware services

By accessing context sources, services of both the application and middleware layers may be made context-aware. This is modeled in Figure 3, which highlights context-awareness of the three base architectural components of SOA, i.e., service client and provider, and Service Discovery Protocol (SDP). Note that although we abstract each component as a single entity, they may be distributed as is in particular the case of the SDP.

We distinguish two complementary approaches to contextaware service discovery: explicit and implicit. In the former case, the request for the service specifies contextual requirements for the service provision, hence leading to select services according to applications requirements, as specified by the service client and/or provider [START_REF] Broens | Context-aware, ontology-based, semantic service discovery[END_REF][START_REF] Pawar | Ontology-based context-aware service discovery for pervasive environments[END_REF][START_REF] El-Sayed | Semantic-based context-aware service discovery in pervasive-computing environments[END_REF]. Typical example of explicit context-aware service discovery is the case where users request to print their documents on the closest printer. In the implicit case, the context-aware SDP selects services according to functional and non-functional properties specified by the client, and further tunes the selection according to context knowledge. In both cases, the SDP needs to have access to context sources relevant to the client and/or service provider, which is to be enabled by the middleware. Then, this knowledge may be obtained reactively, proactively or Context-adaptive service adapt their behavior according to context. We then distinguish 3 types of context-adaptive services: (i) the context-specific service can only be correctly provisioned in the specified context, (ii) the contextdependent service may be provisioned in various contexts but is bound to a specific context during a session, i.e., the service adapts its behavior at binding time, and (iii) the context-aware service continuously adapts its behavior according to context evolution. The third type of service relates to the development of dynamically adaptive software [START_REF] Zhang | Model-based development of dynamically adaptive software[END_REF]. In all cases, the service interface must be enriched with the specification of the context in which the service can be correctly provisioned, which has to be matched against by the SDP through access to relevant context sources. Furthermore, the context may be monitored during the service session by the middleware, for triggering adaptation -if supported-or enforcing robustness of the system by detecting that the service can no longer be provisioned as expected. A context-adaptive service may be composite, in which case it is able to compose services according to the context of composition in addition to the functional and non-functional properties of composed services [START_REF] Mokhtar | Context-aware service composition in pervasive computing environments[END_REF]. For example, if the user requests for a travel service, he can add constraint on the global composition in order to select the cheapest travel, or add constraint on composite flight services in order to select only best ranked companies worldwide.

Note that being a service, a context source may itself be developed as a context-adaptive service, possibly composite. For instance, a context repository uses a context-aware SDP for maintaining its knowledge base according to the context sources that join and leave the network(s) in reach. Finally, a context-adaptive client is dual to the context-adaptive service; it makes explicit the context in which the requested service is to be provisioned.

CONCLUSIONS

Service-oriented computing has emerged as a promising paradigm for pervasive computing. In particular, semantic services together with supporting lightweight middleware enable abstracting and composing on the fly networked resources, either wireless or wired, resource-constrained or resource-rich, mobile or stationary [START_REF] Mokhtar | Efficient semantic service discovery in pervasive computing environments environments[END_REF]. As such, semantic services enable a true interoperable, open network of ser-vices that leave and join according to their mobility pattern. However, several challenges remain towards fully pervasive service-oriented computing. One such challenge is making services contextual, so that the pervasive computing environment gets knowledge about the context and the services adapt their behavior accordingly. In this direction, this paper has surveyed key architectural elements and in particular middleware-related ones that need be deployed in the environment for context-aware pervasive service-oriented computing. These take the form of contextual services that may be composed in an ad hoc way through opportunistic networking and combination of functionalities. We are now refining the proposed SOA style so as to develop a serviceoriented context-aware middleware, which will enrich our current interoperable middleware for pervasive services [START_REF] Mokhtar | Cocoa: Conversation-based service composition in pervasive computing environments[END_REF].

Figure 1 :

 1 Figure 1: Context Sources

Figure 2 :

 2 Figure 2: Context Consumption

Figure 3 :

 3 Figure 3: Context-aware Services

http://www.w3.org/TR/rdf-sparql-query/ sparql-defns.html

ACKNOWLEDGMENTS

This work is supported by the IST PLASTIC Projecthttp://www.ist-plastic.org