SIP meets Slobodanka Tomic and Petia Todorova Abstract In the paper presented we put together the framework of SIP, which is the protocol of choice for Next Generation Networks (NGN) and has been gradually expanded to support context-based multimedia communication, and, an evolving standard for data dissemination and distributed control in sensor and actuator networks supporting automation and monitoring applications. Our main contribution is the proposed SIP- interworking architecture and the mapping between the binding mechanisms and publish/subscribe/notify mechanisms of SIP presence framework. Index Terms SIP,, Gateway Gateway Internet (IMS) Gateway F I. INTRODUCTION uture pervasive networks will be highly heterogeneous and will support many different types of communication between people and things [1]. In the broad spectrum of emerging applications including environment monitoring, telematics, home automation, etc., wireless sensor and actuator networks (WSAN) are envisioned to be ubiquitously embedded in the environment, to provide extended physical information and support emergence of environmental intelligence [2]. In this context there is a strong need for the seamless inclusion of wireless sensor networks into the multimedia services' framework of the existing Internet, in its transition towards the "Internet of Things". This need provides a motivation to consider the interworking architecture based on the framework of the Session Initiation Protocol (SIP) [3], which is the protocol of choice for service control in next generation networks (NGN) based on Internet Multimedia Subsystem (IMS), and the protocol stack [4], which is today a promising standardization framework for WSAN control. We investigate how SIP and could interwork in a heterogeneous networking scenario, unifying the publish/subscribe/notify concepts of the SIP presence service, and the discovery and binding concepts of. The motivating scenario for this work is the one in which many islands of WSAN have to be interconnected together through the Internet, for example, a sensor in one domain has to be seamlessly connected to an actuator in another domain. Manuscript received January 31, 2007. Slobodanka Tomic is with The Telecommunications Research Center Vienna (ftw.), tomic@ftw.at, Donau-City Strasse 1, Wien, Austria. Petia Todorova is with Fraunhofer Institute FOKUS, petia.todorova@fokus.fraunhofer.de, Kaiserin - Augusta-Allee 31, D-10589 Berlin, Germany. Figure 1: SIP/ Architecture One possible solution for this problem is to use the TCP/IP stack option and transport messages in TCP/IP packets over TCP/IP Bridges [5]. In this work, however, we are interested to go beyond the network layer interworking, because the application layer approach, in particular based on SIP, may bring additional benefits and opens new possibilities. The motivation for the application layer interworking is also given with the need to support users remotely accessing data or performing control with common SIP-enabled communicating devices, e.g., a user controls the lights in his home by using his SIP phone. In this paper, therefore, we propose architecture with /SIP Gateways. The aim of this approach is to leverage the rich concepts of SIP session establishment and management, and publish/subscribe/notify mechanisms of SIP presence framework. The proposed architecture and an interworking scenario is depicted in Figure 1. The network, registers with the SIP infrastructure through one node which acts as a gateway. Further on, can publish available data or control capability for the interested users. Another network, PAN-B, or a SIP user, can also register, and then subscribe for particular data, or notifications on events from the. At the Gateway, the format of specific data-centric queries as well as event-based notifications must be translated from and into SIP message formats. One practical scenario, in which this architecture is particularly useful, is a medical application which uses network of sensor devices and intermediate forwarding and storing devices in a hospital, as the one considered in [6]. Medical stuff may periodically get information or query such a network from their mobile devices by using a SIP-based access. Using the SIP capabilities the information sent towards users can also be forked towards devices which do some
additional processing and storing. The standard SIP mechanisms can be fully exploited without the need to configure the whole application scenario at the IP layer, i.e., to know explicit IP addresses. In this paper we are focusing on the SIP/ interworking architecture and the mapping between the application layer concepts and the SIP concepts. The structure of the paper is as follows. Section II gives a brief overview of the SIP infrastructure for session control and presence services and application layer architecture including the binding concepts for distributed control and data dissemination. Section III investigates the SIP/ interworking scenario, where isolated sensor networks, and interested users, are interconnected over the SIP infrastructure. Section IV concludes the paper. II. GENERAL ANALYSIS OF SIP AND ZIGBEE ARCHITECTURE SIP Infrastructure: SIP is a control protocol for creation, modification and termination of point-to-point or multiparty sessions with one or more participants. It is independent of media transport which for example, typically uses RTP over UDP [7]. SIP is also used for Instant Messaging and presence detection [8] SIP is getting increasingly popular due to support for services such as VoIP, Instant Messaging and collaboration and has established itself as the control core for ubiquitous multimedia services [9] in the Internet. A SIP infrastructure is illustrated in Figure 2. It consists of user agents, registration servers, location servers and SIP proxies distributed across a network. SIP User Agents (UA) register with and identify themselves with unique identifiers (SIP URI). In this way, the mapping between unique Uniform Resource Identifier (URI) and temporarily assigned IP address is always maintained. A URI can denote a person, a location, a thing or a service [10]. A set of URIs can also map into a same URI. For example with SIP location based services, a user can initiate a SIP UA-A (watcher) REGISTER/ SIP Proxy SUBSRIBE/ MEDIA SIP Proxy Presence Agent Figure 2: SIP Infrastructure Location Database SIP UA-B (presentity) REGISTER/ session with the service UA, which resolves in the spatially nearest one from the set of all registered UAs [11]. Particular URI can be resolved by SIP proxy servers by either querying the Domain Name System (DNS), a location databases, or any database that provides a mapping between the context information and the particular URI. Once registered a user can initiate sessions to other users by sending SIP control messages, e.g., INVITE, the routing of which is controlled in the overlay of SIP proxy servers. The routing based on URI is done using intermediate SIP proxies, location and redirect servers as part of the session setup process. DNS SRV records are used for finding SIP proxies responsible for the destination domain. As also shown in Figure 2, while signalling messages are routed through the proxies, the media is routed peer-topeer. The session setup messages like INVITE can contain Session Description Protocol (SDP) [12] payload in the message body, describing user parameters such as parameters for media type, transport protocol, IP addresses and port numbers. The IP address and port numbers is used for the direct media routing. Session parameters can be changed through a RE-INVITE message, which is an INVITE embedded within an existing session, and an existing session can be transferred by using a REFER message. Extensions to SIP for presence detection and Instant Messaging (SIMPLE) support publish/subscribe/notify mechanisms [13], in which user agents subscribe to certain events at another user agent and can be notified whenever that event occurs. SIMPLE provides support for Instant Messaging through the introduction of a new message, called MESSAGE. SIP presence framework enable users to either publish their presence information, showing their communication disposition with the system, or subscribe to be notified of the changes in the state of other users. The simple presence is extended with the location and other context specifying parameters [14-16]. The relationship of tracking may therefore be established on different information (context) layers beyond simple location. Indeed, today, the context-based services, as an extension of location based services, are considered most promising and most challenging SIP services. SIP support for discovery of services and context assessment enables a variety of novel communication and content delivery scenarios. Architecture: is a layered protocol stack for data dissemination and distributed control in wireless sensor and actuator networks inclusive for devices of different capabilities and types, such as RFIDs, smart sensors, active tags, and data harvesters. Zigbee supports flexible introduction of new applications, and provides a set of mechanisms which can be customized according to the sensor node constraints and application requirements. stack is illustrated in Figure 3. At the MAC and physical layer, uses IEEE 802.15.4 [17] standard, which defines mechanisms for selforganization of wireless personal area network (WPAN) in a routing/forwarding structure in which both full functional devices (FFD) and reduced functional devices (RFD) connect, as routers and end-devices respectively.
Application Framework APP Object 1 APP Object 240 End Point:1 End Pt:240 APS Layer NWK Layer MAC and PHY Layer (IEEE 802.15.4) Device Object End Point 0 Figure 3: Stack Node Discovery Network Binding Security common services An IEEE 802.15.4 WPAN is composed of one PANcoordinator and a set of FFD and RFD devices. The PAN coordinator is the primary controller of the network. It is responsible for initiating the network operations. The IEEE 802.15.4 standard supports star and peer-to-peer topologies. In the star topology each device is associated with the PAN coordinator and the direct communication between enddevices is not allowed. In peer-to-peer topology devices can associate also with other nodes which have previously joined the network and the direct communication between devices within their radio range is allowed. Hence, more complex topology structures can be established, e.g., tree or mesh topologies. networking layer (NWK) introduces mechanisms for the neighbor discovery, network formation, node addressing, and routing in the mesh or alternatively on a cluster tree rooted at the coordinator. A PAN can autonomously self-organize within its spatial areas. This organization is governed from the PAN-coordinator, which is a FFD capable to assign addresses and organize a cluster tree. The application layer consists of the Application Support Sub-layer (APS), the Device Object (ZDO) with the manufacturer-defined application objects, and the Application Framework (AF) with application objects [18]. The responsibilities of the APS include maintaining tables for binding, which is the ability to match two devices together based on their needs, and forwarding messages bound devices. The responsibilities of the ZOD include defining the role of the device within the network (e.g., coordinator or end device), initiating and/or responding to binding requests and establishing a secure relationship between devices. Another responsibility is discovery, the ability to determine which of the devices operating at the WPAN the device is associated. The application objects are associated with the device endpoints, of which a device can have up to 240 instances. Each end-point can implement one application object hence 240 active applications can be supported at one device. A particular application is identified with the application profile ID, which is the description of the messages, message formats and processing actions within the distributed application. The application is further described as a particular binding between the input clusters and output clusters of attributes which either receive or send application messages, respectively. Device Object (ZDO) resides at the end point 0, and together with APS, provides a set of common services to all applications. These common services are implemented as the functionality of the Node, Discovery, Network, Binding and Security. Discovery and Binding are particularly important in the process of application configuration. Discovery supports discovery of devices, active end-points, and application input and output clusters running on these end-points. Binding supports application configuration by establishing bindings between the corresponding input and output clusters. supports flexible binding for different types of devices. Devices of full functionality may autonomously discover the addresses of their communication pears (e.g., the device with the application output cluster discovers the device with the corresponding input cluster) and send messages directly to them. More interesting method is the one in which devices use a coordinator as a kind of a binding broker. Here a particular end-device implementing output cluster of a particular application does not have to know the address of the device with the input cluster, and vice versa. It can require binding at the coordinator by simply sending a binding message. This is illustrated in Figure 4, where we assume that for a simple application (profile ID A) which has an input cluster-c1 implemented at Device X, end-point 1, and an output clusterc1 implemented at Device Y, end-point 5, a binding should be established. In addition to the method where two devices issue binding messages and send them towards the coordinator, the coordinator can also autonomously discover active application clusters and initiate binding between them. In this case the devices should only send the message announcing their availability and support for discovery. The binding is implemented as a record in the binding table, which is created by the coordinator. In addition a PAN coordinator can either keep the binding table or distribute it at more suitable routers in the network. For example, in Figure 4, the common parent in the cluster tree can efficiently implement binding between the end-devices. Upon binding, the end-device with the output cluster send data on the cluster tree, which forwards it up the tree to the parent with the binding table, and then down the tree to the requested device input cluster device. Maintaining tables for binding at several specialized nodes, is the responsibility of the APS layer.
DeviceX Addres = X EndPoint ID = 1 APP Profile ID = A ciuster ID = 1 output Figure 4: Binding on the Cluster Tree III. "SIP MEETS ZIGBEE" SCENARIO To illustrate our SIP/ interworking scenario, we use a simple home automation application (light control) as depicted in Figure 5, in which two remote PANs are involved. The light bulbs B1-B4 can be switched "on" or "off" when the corresponding messages are received from the switches S1 and S2. The output cluster cl-1 in the network is implemented at switch S2; it sends messages for switching on/off to bulbs B1 and B2 with the input clusters cl- 1. This binding is the internal binding implemented by means of the binding table. S1 external monitor Bind_req/resp D1 S2 ep2 coordinator (Binding Table) Bind Bind_req/resp Internal Binding Table Figure 5: Distributed Application The output clusters cl-2 and cl-3 implemented at switch S2 and switch S1, respectively, send "switch on/off" messages to the input clusters cl-2 and cl-3 implemented at bulbs B3 and B4. As S1 and S2 are in and B3 and B4 in PAN-B the external bindings have to be established. Our aim is to have the external bindings for clusters cl-2 and cl-3 implemented by means of SIP. In Figure 5 the binding cl-4 with the external monitor is also shown. The external monitor is a part of the application which receives status messages of the bulbs. When the status of the bulb B4 is changed the output cluster cl-4 message is sent to cl-1 cl-2 cl-3 cl-4 external bindings DeviceY Addres = Y EndPoint ID = 1 APP ProfileID = A ciuster ID = 1 input D2 B1 B3 B4 D3 B2 ep2 D1 PAN-B the external monitor. The configuration of the application illustrated in Figure 5 is described in Table 1. We refer to the profile ID of this application as ApA. Coupling of and SIP together opens the possibility for user devices with the SIP stack to remotely control devices. For a particular application the client software at the user side can implement corresponding output or input clusters, and send/receive corresponding messages embedded in SIP messages. The SIP/ Gateways translate these messages and forward them towards the devices. The monitoring application can use rich functionality of the SIP protocol itself and the related tools for orchestration of processes; for example the status change can be sent to the user and the forking of the call will reach him where ever he is registered at that time. For the application from Figure 5 we depict the SIP/ interconnection architecture with the elements of the SIP presence architecture in Figure 6. Function Device PAN App Profile ID End Point Cluster ID switch S2 D1 ApA ep2 Output cl-3 switch S2 D1 ApA ep2 Output cl-2 switch S1 D1 ApA Output cl-1 bulb B1 D2 ApA Input cl-1 bulb B2 D3 ApA Input cl-1 bulb B3 D1 PAN-B ApA Input cl-2 bulb B4 D1 PAN-B ApA ep2 Input cl-3 bulb B3 D1 PAN-B ApA Output cl-4 bulb B4 D1 PAN-B ApA ep2 Output cl-4 monitor D1 ApA Input cl-4 Table 1: Application Description In this architecture and PAN-B are interconnected by means of the SIP/ Gateways. presentity & watcher GwA REGISTER / presence agent REGISTER GwB PAN-B presentity & watcher Figure 6: SIP/ Interconnection Architecture Watcher (external monitor)
SIP/Zigbee Gateway implements the SIP and stack and acts as both PAN coordinator, SIP UA and SIP Presence UA. In Figure 6, the SIP/ Gateway in is denoted with GwA and in PAN-B GwB. and PAN- B implement some application objects and clusters which they need to register by using the SIP notification-based publish and subscribe service. This can include following steps. 1. At the side PAN coordinators at GwA and GwB discover active end-points, applications and clusters. 2. SIP UAs at GwA and GwB register with the. The registration associates the IP address of the SIP/ Gateway with the (PAN-B) URI. 3. SIP Presence UA at GwA (GwB), publish (as presentities) URIs of active applications (e.g. ApA), its input and output clusters and the requested binding (e.g., as described in Table 1). 4. SIP Presence UA at GwA (GwB) subscribe (as watchers) with the URIs of the applications to which it can establish binding. In our example GwA and GwB both subscribe with ApA. 5. The relation between GwB and GwA in the watcher/presentity role is established at the SIP side, by the NOTIFICATION messages, and corresponding binding between input clusters behind GwB and the output clusters behind GwA can therefore also be established. 6. Switch S1 can now issue a cl-3 message to switch off the bulb B4. This message is translated at GwA, for example into the SIP MESSAGE, and sent to GwB. GwB forwards the re-translated message to the bulb B4. Again the binding can be done by means of SIP presence service. 7. Application client software at the mobile device of the user can implement a monitor and an additional switch. The mobile device has a SIP stack and a SIP UA which can register and subscribe to get the data from the over GwA, and PAN-B over GwB. It can also get the notification of the status changes and can perform control by sending SIP messages. IV. CONCLUSIONS In this paper we put the complementary worlds of SIP and together and propose the SIP- interworking architecture, which on the one hand provides ubiquitous access to networks for the SIP users, and on the other hand uses SIP to transport control and data messages between remote networks. Indeed for the vision of ubiquitous Internet of Things to realize the integration of complementary concepts is a necessary first step. We present the mapping between the application layer binding and publish/subscribe/notify mechanisms of SIP presence service. The work presented in this paper provides us with the framework within which concrete message mapping, message flows and extensions can be defined. Planned future work includes the refinement of the concepts and concrete implementation for the proof of concept. NOWLEDGMENT The work presented here is supported within the European project CRUISE (Creating Ubiquitous Sensing Environments), the EU FP6 Network of Excellence (NoE) on communication and application aspects in sensor networking. REFERENCES [1] ITU Internet Reports: The Internet of Things, 7th edition, http://www.itu.int/pub/s-pol-ir.it-2005/en, 2005. [2] D. Estrin, L. Girod, G. Pottie, and M. Srivastava, Instrumenting the World with Wireless Sensor Networks, Proc. Int l Conf. Acoustics, Speech, and Signal Processing (ICASSP 2001), May 2001. [3] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler: SIP: Session Initiation Protocol, RFC3261, June 2002. [4] Zigbee Alliance: Specification, Document 053474r06, Version 1.0, http://www.zigbee.org/en/index.asp, June 27, 2005. [5] Document: 053820r13, Bridge Device Specification, Draft Version: V 0.13, January 1, 2007 [6] A. Lakas, K. Shuaib: A framework for SIP-based wireless medical applications, IEEE 61st Vehicular Technology Conference, VTC 2005- Spring, Volume 5, 30 May-1 June 2005 pp. 2755-2759. [7] H. Schulzrinne et al. RTP: A Transport Protocol for Real-Time Applications. RFC 18893550 IETF,July 2003.. [8] A. Niemi et al., Session Initiation Protocol (SIP) Extension for Presence Publication. SIMPLE Working Group Internet-Draft, June 2003. [9] A. Cuevas, J.I. Moreno, P. Vidales, H: Einsiedler: The IMS service platform: a solution for next-generation network operators to be more than bit pipes, IEEE Communications Magazine, Volume 44, Issue 8, Aug. 2006, pp 75-81. [10] T. Berners-Lee, R. Fielding, L. Masinter, Uniform Resource Identifier (URI): Generic Syntax, RFC3986, January 2005. [11] Xiaotao Wu and Henning Schulzrinne, Location-based Services in Internet Telephony, [12] Handley, M. and V. Jacobson, SDP: Session Description Protocol, RFC 2327, IETF Apr 1998. [13] H. Schulzrinne, The SIMPLE Presence and Event Architecture, First International Conference on Communication System Software and Middleware (Comsware 2006), 08-12 Jan, pp 1-9. [14] H. Schulzrinne, RPID rich presence information data format, Internet Draft draft-ietf-simple-rpid-05, Internet Engineering Task Force, Feb. 2005. Work in progress. [15] H. Schulzrinne, Future presence: Extensions to the presence information data format (PIDF), Internet Draft draft-ietf-simple-future- 00, Internet Engineering Task Force, Feb. 2004. Work in progress. [16] J. Peterson, A presence-based GEOPRIV location object format, Internet Draft draft-ietf-geopriv-pidf-lo-01, Internet Engineering Task Force, Feb. 2004. Work in progress. [17] IEEE Std 802.15.4-2006 Part 15.4 (Revision of IEEE Std 802.15.4-2003): Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (LR-WPANs), 2006. [18] Zigbee Alliance: Document 0324429, Version 1.0, Application Support Sub-Layer Specification, december 14 th,2004.