Peer-to-peer SIP-based Services over Wireless Ad Hoc Networks
Nilanjan Banerjee
CReWMaN, University of Texas at Arlington
[email protected]
Arup Acharya
IBM T. J. Watson Research Center
[email protected]
Sajal K. Das
CReWMaN, University of Texas at Arlington
[email protected]
∗Abstract
Session Initiation Protocol (SIP) based services, such as VoIP, Instant Messaging (IM) and Presence, depend on the Internet and SIP overlay infrastructure. Wireless ad hoc networks being devoid of any such infrastructure, require auxiliary mechanisms to support such services. In this pa-per, we have proposed an integration of the services with a cluster based ad hoc routing protocol and subsequent en-hancements to support them in ad hoc networks.
1
Introduction
The rapid development of small, cheap and computa-tionally powerful devices and major advancement in short range wireless communication technologies have increas-ingly made it possible to build scalable efficient ad hoc net-works. Extensive research in ad hoc networks is enabling several applications, including multimedia applications, to operate in the ad hoc domain. Such applications require signaling protocols in packet based networks to establish multimedia sessions by negotiating resources between the terminals and maintain them throughout the duration of the session. In order to leverage the benefit of the large body of legacy Internet applications, the signaling protocols also need to be suitably ported to ad hoc networking domain.
The two most prominent signaling protocols for IP based networks are H.323 [4] from International Telecommunica-tion Union (ITU) and Session InitiaTelecommunica-tion Protocol (SIP) [23] from IETF. It seems SIP is progressively gaining popularity over H.323, primarily because of its simplicity and flexibil-ity. Session Initiation Protocol (SIP) [23] has been devel-oped primarily for establishing multimedia sessions such as
∗This work was supported by NSF under the ORBIT testbed project,
grant# NSF NRT Project #ANI-0335244 and by NSF ITR grant IIS-0326505.
a Voice over IP (VoIP) with stringent resource requirements in the Internet. SIP is a simple scalable, text-based protocol that offers a number of benefits, including extensibility and the provision for call/session control.
Recently, SIP has been extended by IETF SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) Working Group [2] to enhance the basic protocol with In-stant Messaging and Presence (IMP) functionalities. A presence system allows users to subscribe to each other and be notified of changes in state. Instant Messaging (IM), on the other hand, is defined as the exchange of content be-tween a set of participants in near real time. The IMP ap-plications are mostly based on proprietary IMP platforms and no common standard exists. As a result the IMP ap-plications are not inter-operable, thus restricting the users to particular vendors only. Several working groups have been chartered at IETF to solve this problem. The IMPP (Instant Messaging and Presence Protocol) WG [1] defines the protocol requirements and the data format for building an Internet-wide scalable IMP system. Other WG leverage this framework for building their own IMP system. For ex-ample, the XMPP (Extensible Messaging and Presence Pro-tocol) WG [3] defines an open XML-based protocol for ex-tensible IMP applications. On the other hand, SIMPLE WG has built their IMP platform on top of session Initiation Pro-tocol (SIP) [23]. SIMPLE WG has proposed extensions to the SIP protocol, enabling it to exchange instant messages inside a SIP session and an event package mechanism for notification of presence information.
The advantages of SIP that is gaining favor for SIMPLE WG are as follows. First, SIP is a matured, widely deployed and thoroughly tested protocol to serve as the platform for IMP applications. Second, SIP provides different types of mobility support and hence is suitable for providing IMP services in mobile devices. Third, SIP was designed to provide several services which are fundamentally similar to IMP services. Thus SIP could be reused or extended
with-out any drastic change in the standard.
The main problem in deploying SIP in ad hoc domain is that SIP relies on an infrastructure heavily borrowed from the Internet (e.g. DNS resolution) and SIP proxy based overlay infrastructure for SIP service discovery and the routing of the SIP messages, which is not available in the infrastructure-less ad hoc networks. Hence some auxiliary mechanism is needed to (i) discover the SIP services in the ad hoc networks and (ii) to route the SIP messages.
In this paper, we discuss how to enable SIP based ser-vices in infrastructure-less ad hoc networks. An integrated approach where the SIP services are integrated with a clus-ter based routing protocol has been proposed. A caching scheme leveraging the SIP protocol features has also been proposed. Some IEEE 802.11 MAC layer enhancements have also been discussed to increase the efficiency of IM services. The rest of the paper is organized as follows. Sec-tion 2 provides a brief overview of SIP. The extensions of SIP for instant messaging and presence services have been described in Section 3. The issues related to the deployment of SIP services in ad hoc networks and the integration of SIP services with the routing protocol are discussed in Sec-tion 4. Preliminary simulaSec-tion results on the performance of the proposed integration is presented in Section 5. Section 6 concludes the paper.
2
Overview of SIP
SIP is a control protocol that allows creation, modifi-cation and termination of sessions with one or more par-ticipants. SIP is used for voice and video calls either for point-to-point or multiparty sessions. It is indepen-dent of the media transport which for example, typically uses Real-time Transport Protocol (RTP) over UDP [24]. It allows multiple end-points to establish media sessions with each other: this includes terminating the session, lo-cating the end-points, establishing the session and then, after the media session has been completed. In recent times, SIP has gained widespread acceptance and deploy-ment among wireline service providers for introducing new services such as VoIP; within the enterprises for Instant Messaging and collaboration; and amongst mobile carri-ers for push-to-talk service. Industry acceptance of SIP as the protocol of choice for converged communications over IP networks is thus highly likely. As shown in Figure 1, a SIP infrastructure consists of user agents, registration servers, location servers and SIP proxies deployed across a network. A user agent is a SIP endpoint that identifies ser-vices such as controlling session setup and media transfer. User agents are identified by SIP URIs (Uniform Resource Identifier), which is a unique HTTP-like URI of the form
sip:user@domain. All user agents REGISTER its IP
address with a SIP registrar server (which can be co-located
with a SIP proxy). Details of the SIP protocol can be found in [23]. SIP defines a set of messages, such as INVITE, REFER etc., to setup sessions between user agents. These messages are routed through SIP proxies that are deployed in the network. DNS Service records help in finding SIP proxies responsible for the destination domain.
User Agent User Agent Redirect Server Location Service Proxy Proxy Proxy Registrar 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Request Response Media
Figure 1. SIP architecture
A session is setup between two user agents following a client-server interaction model, where the requesting user agent acts as the client and is known as the user agent client (UAC), interacting with the target user agent known as the user agent server (UAS) acting as server. All requests from an originating UAC, such as an INVITE are routed by the proxy to an appropriate target UAS, based on the target SIP URI included in theRequest-URIfield of the INVITE message. Proxies may query location and redirect servers for SIP service discovery or in order to determine the cur-rent bindings of the SIP URI. Signaling messages are ex-changed between user agents, proxies and redirect/location servers to locate the appropriate services or endpoints for media exchange. For reasons of scalability, multiple prox-ies are used to distribute the signaling load [14]. A session is setup between two user agents through SIP signaling mes-sages comprising of an INVITE (mesmes-sages 1,2,4,7, and 8 in Figure 1), an OK response (messages 9-12 in Figure 1) and an ACK (message 13 in Figure 1) to the response [23]. The call setup is followed by media exchange using RTP. The session is torn down through an exchange of BYE and OK messages.
SIP distinguishes between the process of session estab-lishment and the actual session. A basic tenet of SIP is the separation of signaling (control) from media. Signaling messages are usually routed through the proxies while the media path is end-to-end. The session setup messages like INVITE contain user parameters using Session Description Protocol (SDP) [13] in the message body. SDP provides information about the session such as parameters for me-dia type, transport protocol, IP addresses and port numbers
of endpoints. The IP address and port numbers exchanged through SDP is used for the actual data transmission (me-dia path) for the session. Any of these parameters can be changed during an ongoing session through a RE-INVITE message, which is identical to the INVITE message except that it can occur within an existing session.
3
SIMPLE: SIP for Instant Messaging and
Presence Leveraging Extensions
According to the definition, an IMP system allows users to subscribe to each other and be notified of changes in state, and for users to send each other short instant messages in real-time.
Typically, in a presence service entities willing to receive the presence information of a given entity subscribe to the ”presence service” of that entity so that they can be notified when a presence event related to that entity, e.g. coming on-line, occurs. The presence service is a system that ac-cepts, stores and distributes the presence information to the interested parties.
SIP provides a general framework for event notifications [19], whose purpose is to allow SIP endpoints to receive notifications from remote endpoints indicating that an event has occurred. The framework does not define the nature of the events causing a notification, but is intended to be the general support on which specific events (event packages) can be built. Two SIP methods are used in the framework, SUBSCRIBE and NOTIFY. SIMPLE WG has defined in [22] the presence event package, with which SIP entities can subscribe to the presence service of a remote entity and be notified when a presence related event (e.g. entity goes on-line) occurs.
When a SIP entity (subscriber or watcher) wants to sub-scribe to the presence service of a remote SIP entity (pre-sentity), also known as the Presence User Agent (PUA), it creates a SUBSCRIBE request, carrying the URI of the de-sired entity. The request traverses normally the SIP network (it passes through chain of proxies as the other requests) un-til it reaches a SIP presence server, which will generate a response for the SUBSCRIBE request.
The presence agent (PA) is the logical entity in charge of managing the presence information of a presentity, process-ing SUBSCRIBE requests, consequently notifyprocess-ing to the subscriber changes in the presence status of the presentity, with NOTIFY requests. The PA for a given presentity must have access to the presence information of that presentity. The way how this is achieved is out of scope of the SIM-PLE framework. Upon authentication and authorization of the subscription, a PA sends a NOTIFY message to the sub-scriber including the presence information and whether the request was authorized. According to the definition given
in [19], both SUBSCRIBE and NOTIFY methods are con-sidered as SIP requests.
Subscriber authentication/authorization SUBSCRIBE OK OK OK NOTIFY NOTIFY Presence Update Subscriber PA PUA
Figure 2. SIMPLE Presence Event Package
The message exchange is reported in Figure 2. In this example, we suppose that the PA and the PUA are not co-located. The way how PA and PUA exchange information is out of the scope of the Presence Event Package specifica-tion.
The PUA has already communicated to the PA the pres-ence information of its presentity. At some point in the time, a subscriber sends a SUBSCRIBE request to the presen-tity. The presentity is identified by the URI carried in the SUBSCRIBE request. The request is routed in the SIP net-work and arrives to the PA of the queried presentity. The PA acknowledges the request and starts the authentication and authorization procedures of the subscriber (unless the sub-scriber had been previously authenticated and authorized).
After the, successful, completion of this step, the PA sends the NOTIFY request containing the presence docu-ment of the presentity. The subscriber acknowledges the message with a 200 OK SIP response. Afterwards, the PUA sends to the PA an update of the presence information of the presentity. Since the subscriber is regularly authorized, the PA delivers to the subscriber another NOTIFY message, containing the whole presence document of the presentity.
The SIP protocol has been extended for sending instant messages [9]. When one user wishes to send an instant message to another, the sender formulates and issues a SIP request using the MESSAGE method defined as an exten-sion. MESSAGE requests normally carry the instant mes-sage content in the request body. The request mesmes-sage is routed based on the Request-URI of the request header, which contains the current information about the recipient’s location. Like any other SIP request message, the MES-SAGE request traverses a set of SIP proxies, using a variety of transports, before reaching its destination. Provisional and final responses to the request will be returned to the sender much in the same way as that of any other SIP
re-quest. Normally, a 200 OK response will be generated by the user agent of the request’s final recipient.
However, this extension allows messages to be ex-changed outside a session, independently each-other, and it is better suited for short messages exchanges. This ap-proach is referred to as page-mode, as it resemble a pager-based exchange of messages. Session-mode messaging [10], where instant messages are exchanged in the context of a session, presents several advantages. Instant Messag-ing sessions in SIMPLE make use of the Message Session Relay Protocol (MSRP).
The MSRP protocol provides transport of instant mes-sages in session-mode in an end-to-end fashion, running over a reliable transport protocol such as TCP or SCTP. MSRP sessions are managed using the Session Description Protocol (SDP) offer/answer model [21] combined with SIP as message carrier. The MSRP protocol is rather simple, as it uses only two primitives: (i) SEND: for sending in-stant messages between endpoints (ii) VISIT: for establish-ing MSRP sessions. In order to establish a session, in a gen-eral use case with endpoint B, endpoint A sends in an offer message a temporary unambiguous URI, representative of the endpoint A. If B wishes to join the session, it opens a TCP connection to A, sends the VISIT message, addressed to the URI provided by A. After visiting the session, B sends the answer message for the offer received from A; the an-swer message contains a URI, where B can be contacted. After this exchange, instant messaging exchanges between A and B can begin; for each instant message sent with a SEND request, an OK reply will be sent by the interlocutor. More SEND messages can be sent even though they have not been (at SIP level) acknowledged yet. SEND requests are sent by either endpoint to the URI indicated by the peer; respectively.
Each message exchanged, shown in Fig 3, is labeled with a tag indicating whether it is a SIP or an MSRP message. Details on the exchanged messages can be found in [10].
The offerer initiates the session using the SIP INVITE method; the INVITE request contains the parameters to be negotiated for establishing the session. In this case they are the transport protocol to be used (TCP for MSRP), the con-tent type of the message bodies that can be accepted dur-ing the sessions, and the session parameter where the URI session descriptor, containing offerer address and port num-ber is given to the answerer. The answerer-visitor opens a TCP connection with the offerer-host and sends the VISIT request.
The host acks the VISIT request (MSRP 200 OK re-sponse) and the visitor acks the INVITE request (SIP 200 OK request), that is, it answers to the offer. The SIP 200 OK response is further acknowledged by the generator of the INVITE request, according to the SIP model, to com-plete the SIP three-way handshake.
SIP INVITE MSRP VISIT MSRP OK SIP OK SIP ACK MSRP SEND MSRP OK MSRP SEND MSRP OK BYE SIP OK
Figure 3. MSRP message exchange example
Host and visitor exchange one instant message each; the messages involved are two MSRP SEND requests and two MSRP 200 OK responses to acknowledge the safe receipt of the message. When the host wants to close the session, and sends a SIP BYE message, which will be answered by the visitor with a SIP 200 OK. Meanwhile, both endpoints release the local session state and the host drops the TCP connection.
4
SIP Services in Ad Hoc Networks
SIP session setup as well as the subscription to presence service and sending instant messages, involve the location of the SIP endpoint corresponding to a unique URI, using the Internet (DNS resolution) and the overlay SIP proxy based infrastructure. None of these infrastructure is avail-able in an wireless ad hoc network. So, in order to enavail-able SIP based services in ad hoc networks, we must provision for (i) SIP endpoint discovery in an infrastructure-less net-work and (ii) an efficient routing scheme for routing the SIP-based messages. Now, some of these functions, such as node discovery and routing of data packets, are already done by the ad hoc routing protocol. So, instead of going for an auxiliary mechanism which performs the same task as the routing protocol, a better option is to integrate the desired functions with the routing protocol.
4.1
Integration with the routing protocol
There are pre-dominantly two types of ad hoc routing protocols. They are proactive routing strategy [17, 11] and
reactive routing strategy [15, 18]. In a proactive strategy,
the results are computed based periodic advertisements and stored for future use. A reactive strategy, on the other hand, computes the routes when required by flooding the network with probe packets. A proactive strategy is capable of pro-ducing routes faster than the reactive strategy at the cost of maintaining pre-computed but sometimes redundant and spurious routes. A reactive strategy, however, can also suf-fer from prohibitive flooding traffic attributed to the redun-dancy factor associated with the “broadcast storm problem” [25] and unacceptable delay in route discovery process. A trade-off is generally done in such cases with cluster based routing [8, 12]. In cluster based routing, several clusters are formed with the ad hoc nodes, each with a cluster head that is fully aware of all the other members of the respec-tive cluster and is responsible for communication to them. Flooding of control packets and routing of data packets take place through the cluster heads only, thus restricting the flooding problem.
In this paper, the SIP endpoint discovery and the rout-ing of SIP messages are integrated with a distributed cluster based routing protocol. Further details on the routing pro-tocol and the integration can be found in [7]. The cluster based routing protocol creates a virtual topology with the cluster heads forming a backbone network, which is used in the routing of both SIP (the basic as well as the SIMPLE) messages and data packets. The basic assumption is that each node is equipped with a SIP user agent and is able to take the extra responsibility of acting as a SIP proxy server and SIP registrar server.
4.2
Cluster based Routing Protocol
Virtual Topology Creation: The virtual topology cre-ation involves two major steps of cluster head selection fol-lowed by cluster formation. They are described as follows.
• Cluster Head Selection Each node in the ad hoc
net-work sends a periodic HELLO message to all its neigh-bors with the list of all of its neighneigh-bors. Each node on receiving the HELLO message computes the degree, or the number of adjacent neighbors of the node. This de-gree information is then broadcasted in the subsequent HELLO messages. Another data structure, called the adjacency table is used to embed 2-hop neighbor in-formation in the HELLO messages. Thus each node gets to know about its degree, as well as that of its 1-hop and 2-1-hop neighbors. With this degree information each node selects itself as a cluster head if it satisfies any of the following two conditions.
Condition 1 The node has the highest degree in its
1-hop neighborhood.
Condition 2 The node has the highest degree in the
1-hop neighborhood of any of its 1-1-hop neighbors.
• Cluster Formation: Once the cluster heads get selected
they assume the responsibility of a SIP proxy and a registrar server [23]. The 1-hop nodes adjacent to the cluster heads join the cluster identified by the cluster head with the highest node degree and the SIP UAC of the node registers its URI with the corresponding registrar server (in case of a tie, the cluster head with the lowest node address is chosen). It can be proved that the cluster heads are either 2-hops or 3-hops away from the nearest cluster heads. Each cluster head main-tains connectivity with its neighboring cluster heads through gateway nodes selected by the following pro-cedure. The HELLO message can detect the cluster heads which are 2 hops away but not those which are 3 hops away. For detecting the cluster heads 3 hops away, a cluster adjacency table is maintained at each node. Each cluster member gets information about its 2-hop cluster heads from the HELLO messages. It cre-ates its own cluster adjacency table for its 2-hop away cluster heads with the intermediate 1-hop neighboring node, relaying the HELLO message, as the gateway node. The cluster adjacency table is then appended to the HELLO message as an extension and sent to all the 1-hop neighbors. Any cluster head in its 1-hop neigh-bor gets to know about the cluster heads which are 3 hops away and identifies the cluster adjacency table re-laying node as the gateway node. In either case, there may be more than one candidate for the gateway node. In those cases, the node with the lowest node address is selected as the gateway node.
Routing Procedure: The common feature of all the SIP based services is that, they are uniquely identified by a SIP URI. So, when a SIP UAC requests a certain service it puts the URI of the target service in theRequest-URIheader of the SIP request messages (viz. SUBSCRIBE, MES-SAGE, INVITE). In our protocol, the cluster heads act as SIP proxies and as the forwarding nodes. The request mes-sages are sent to the corresponding proxy of the requesting node. The proxy then sends this message to the neighboring cluster heads or proxies in order to discover the route to the target node. If any of the neighboring proxies has the tar-get URI registered with itself, it sends the request message to the target node, otherwise it forwards the message to its neighboring cluster heads after recording the proxy address in theRecord-Routefield of the SIP message. The tar-get node on receiving the request message sends back a SIP OK message via the reverse route specified by the list of traversing proxies in Record-Routeheader field. This is exactly the same as the typical proxy based routing of
SIP messages [23]. The requesting node on receiving the SIP OK message, gets to know about the route to the target, which is used subsequently for both SIP session establish-ment and media packet delivery. The routes are also used to send the MESSAGE or the SEND messages of the instant messaging applications, directly to the target UAS. The NO-TIFY messages of the presence applications are sent in the same fashion as that of the SIP OK response messages.
4.3
Cache Management
A cache is maintained at each of the proxies for already discovered routes corresponding to each unique URI. The cache, populated by the SIP OK message, essentially keeps a mapping of the neighboring cluster head to which the re-quest message should be forwarded corresponding to a par-ticular target URI. This saves the overhead associated with the discovery process each time a request or an instant mes-sage is sent to the same target. However, in ad hoc networks, the nodes are mobile and the cache need to be updated each time a node in the path to a target URI moves.
There can be potentially two cases of node movements: (1) the cluster member nodes or the endpoints move and (2) any of the proxies in the path between the two endpoints move. In either case the cache in the intermediate proxies need to be updated.
1. When the requesting node moves to a different cluster with a new cluster head, which does not has a mapping of the path to the target URI in its cache, a new discov-ery process is initiated. The request message, with the target URI in theRequest-URIfield is sent through the network of cluster heads until an entry correspond-ing to the target URI is found in the cache of one of the cluster heads. Otherwise, the request message reaches the target node and the routing procedure, described previously, is employed.
If the target node moves to a different cluster, it reg-isters with the registrar service of the corresponding cluster head, as well as with the previous cluster head’s registrar service with updated contact header. Thus, when the request arrives at the old cluster head accord-ing to the cache entries, a 301 (Moved Permanently) response is sent back to the requesting client with up-dated contact information. All the cache entries, cor-responding to the particular target URI in the path of the response message, are removed.The requestor, fi-nally, redirects the future requests to the address in the updated contact information.
2. When any of the proxies in the path moves, the im-mediately upstream proxy would not receive a timely response from the downstream proxy. The upstream proxy would send a 408 (Request Timeout) response
back to the requestor, thus removing all the cache en-tries for the particular target URI in the intermediate proxies. The requestor on receiving the 408 response initiates a fresh round of route discovery process.
4.4
Improving Routing Efficiency
The union of cluster heads and the gateway nodes de-fine a fixed (or relatively static) connected multihop wire-less network, where each of the nodes act as “wirewire-less IP router” forwarding both the SIP messages and media pack-ets. A forwarding node typically receives packets from the upstream nodes and then transmits them to the downstream nodes. Efficient and fast forwarding of messages is par-ticularly important in the context of instant messaging ser-vices considering the heavy load and the real-time require-ment of the instant messages. However, multihop IEEE 802.11 wireless LAN, the most dominant of the present-day multihop networking technology, pose several challenges in terms of the available system throughput due to multihop routing inefficiency. The current 802.11 Distributed Coor-dination Function (DCF) MAC algorithm has been designed implicitly for either receiving or transmitting a packet, but not for a forwarding operation (i.e., receiving a packet from an upstream node and then immediately transmitting the packet to a downstream node as an atomic channel access operation). There are two key deficiencies:
• The forwarding node is involved in two separate RTS/CTS contention-based channel access attempts during the forwarding process: once to receive the packet (from the upstream node) and again to forward it (to the downstream node), and must thus suffer the contention resolution overhead twice.
• The same packet makes an unnecessary round-trip be-tween the memory on the network interface card (NIC) and the hosts memory (accessed by the host software) to determine the next-hop MAC address. This round-trip not only loads the processor of the forwarding node, but also suffers from additional delays in trans-fers between the NIC and the host operating system. A wireless IP forwarding architecture that uses MPLS [20] with modifications to IEEE 802.11 MAC has been proposed in [6] primarily to solve this problem and significantly im-prove the packet forwarding efficiency. The overheads of separate channel accesses is eliminated by defining the Data-Driven Cut-Through Medium Access (DCMA) proto-col [6] as a simple extension of the 802.11 DCF. DCMA combines the Data ACK (to the upstream node) with the RTS (to the downstream node) in a single ACK/RTS packet that is sent to the MAC broadcast address. The problem of round-trip delay between the memory on the NIC and
the hosts memory is solved by enabling the lookup for next hop within the NIC, without needing to perform the rout-ing lookup in the host. MPLS, a well-known IP compatible technology has been used to perform next-hop lookup in-side the NIC, by setting up labels that enables fast and scal-able determination of the MAC address of the downstream node. This technology can be used in our proposed inte-grated routing protocol, when the route to a particular target has been established by populating the cache in the proxies. The system throughput of the IEEE 802.11 multihop net-works, another important parameter in the context of IM applications, can be further improved by increasing concur-rent transmissions through better spatial reuse. The 802.11 MAC protocol and its variants are primarily designed for a single-hop wireless environment, where nodes typically form a clique and communication always takes place over a single wireless hop (often to a base station providing con-nectivity to the wired infrastructure). In such a single-cell environment, the 802.11 MAC contention resolution mechanism focuses primarily on ensuring that only a sin-gle sender-receiver node pair receives collision-free access to the channel at any single instant. The 802.11 MAC does not seek to exploit the spatial diversity inherent in multihop networks, where different sets of nodes are able to concur-rently communicate with different sets of neighbors. This can be achieved potentially by three different methods: use of power control algorithms, use of directional antennas and modification of the MAC itself to relax some unduly harsh restrictions of the IEEE 802.11 MAC. One such 802.11-like protocol is called MACA-P [5] that provides synchro-nized parallel transmissions by allowing neighboring nodes to synchronize their reception periods, so that 1-hop neigh-bors switch between transmitting and receiving roles in uni-son at explicitly defined instants, and thus avoid the prob-lem of packet collisions. MACA-P can be used for efficient message routing through the cluster heads with enhanced system throughput.
5
Simulation Experiments
We have performed simulation experiments with ns2
[16]. Two types of networks have been considered. One with static or relatively static nodes and the other with ran-dom node mobility. For a static network, half the nodes are placed in a grid fashion within a1000m×1000msquare area to ensure connectivity, while the rest of the nodes are randomly distributed within the square area. The ses-sion have been setup between the farthest pair of nodes in the network. For the network with random node mobil-ity, 15 nodes have been considered to move randomly in a650m×650msquare area, following a random waypoint mobility model with a speed of 10m/s. The time interval be-tween consecutive HELLO messages for the cluster based
routing protocol has been set to 5 secs. The delay for locat-ing a SIP service and the request message reachlocat-ing the tar-get SIP endpoint, or the latency, is an important parameter in SIP session establishment as according to the SIP speci-fications [23], typical value of the latency should be within 32 seconds to avoid a timeout. Table 1 shows the latency vs. number of nodes in a static network. The initial phase cor-responds to the duration when the virtual topology is built. Following the virtual topology setup, the protocol exhibits a very robust behavior against isolated node movements, such as when the source or the destination moves towards each other or the corresponding cluster head moves.
Table 1. Notations
Number of Nodes Initial Phase Isolated Node Mobility (seconds) (seconds) 15 6.740775316 0.007174991 20 6.785696129 0.016927491 25 6.808334292 0.024362500 30 6.839076271 0.033634000
The situation however, completely changes for network with random node mobility. The corresponding latencies for different pause times is shown in Table 2. The latency results for different pause time are averaged over 10 differ-ent random mobility scenarios.
Table 2. Notations
Pause Time Latency (seconds) (seconds) 10 22.05942593 15 33.33560873 20 22.25809538 25 21.27729809 30 18.54484432
So, it is observed that the latency is acceptable for rela-tively static networks, but with the nodes starting to move randomly the integrated approach performs poorly, some-times causing timeouts, which requires the restarting of the entire SIP service discovery and session setup procedure.
6
Conclusion
In this paper, we have presented a brief overview of the SIP based services and the problems to support them in ad hoc networks. An integrated approach, where the SIP ser-vices are integrated with a cluster based routing protocol has been proposed. Caching policies and enhancement of IEEE
802.11 MAC layer have been discussed in the context of performance improvement of the integrated approach. De-tailed simulation results on performance will be provided to supplement the preliminary results presented in the paper.
References
[1] Instant Messaging and Presence Pro-tocol (IMPP) IETF Working Group. http://www.ietf.org/html.charters/impp-charter.html [2] SIP for Instant Messaging and Presence
Leverag-ing Extensions (SIMPLE) IETF WorkLeverag-ing Group. http://www.ietf.org/html.charters/simple-charter.html [3] Extensible Messaging and Presence
Pro-tocol (XMPP) IETF Working Group. http://www.ietf.org/html.charters/xmpp-charter.html [4] International Telecommunication Union, “Packet
based multimedia communications systems”, Recom-mendation H.323, Telecommunication Standardization Sec-tor of ITU, Geneva, Switzerland, Feb. 1998.
[5] A. Acharya, A. Misra, and S. Bansal, “MACA-P : a MAC for concurrent transmissions in multi-hop wire-less networks”IEEE PerCom, pp. 505–508, 2003. [6] A. Acharya, A. Misra and S. Bansal, “A
label-switching packet forwarding architecture for multi-hop wireless LANs”,WoWMoM, pp. 33-40, 2002. [7] N. Banerjee, A. Acharya, S. K. Das, “Enabling
SIP-Based Session Setup in Ad Hoc Networks”, Submitted to INFOCOM 2005.
[8] S. Basagni, “Finding a maximal weighted independent set in wireless networks,” Telecommunication Systems, Special Issue on Mobile Computing and Wireless Networks, 18(1/3), pp. 155-168, 2001.
[9] B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle, “Session Initiation Protocol (SIP) Extension for Instant Messaging”.RFC 3428, Decem-ber 2002.
[10] B. Campbell, R. Mahy, C. Jennings , “The Mes-sage Session Relay Protocol”.Internet Draft (Work in Progress) draft-ietf-simple-message-sessions-07.txt , July 2004.
[11] T. Clausen, and P. Jacquet, “ Optimized Link State Routing Protocol (OLSR)”,IETF RFC 3626, October 2003.
[12] F. Dai and J. Wu, “An Extended Localized Algorithm for Connected Dominating Set Formation in Ad Hoc Wireless Networks,”IEEE Transactions on Parallel and Distributed Systems, Vol. 15, No. 10, 2004.
[13] M. Handley, and V. Jacobson, “SDP: Session Descrip-tion Protocol”,IETF RFC 2327, April 1998.
[14] W. Jiang, J. Lennox, H. Schulzrinne and K. Singh, “Towards Junking the PBX: Deploying IP Tele-phony”, pp. 177-185,NOSSDAV2001.
[15] D. B. Johnson and D. A. Maltz, “The dynamic source routing in ad-hoc wireless networks”,Mobile Comput-ing, eds. T. Imielinski and H. Korth, chapter 5 (Kluwer, Dor-drecht, 1996)pp. 153 - 181.
[16] “The network simulator”, available at
http://www.isi.edu/nsnam/ns
[17] C. E. Perkins and P. Bhagwat, “Highly dy-namic Destination-Sequenced Distance-Vector rout-ing (DSDV) for mobile computers”, Proceedings of ACM SIGCOMM, pp. 234 - 244, 1994.
[18] C. Perkins, E. Belding-Royer, and S. Das “ Ad hoc On-Demand Distance Vector (AODV) Routing ”,IETF RFC 3561, July 2003.
[19] A. B. Roach, “Session Initiation Protocol (SIP) Spe-cific Event Notification”,.RFC 3265, June 2002. [20] E. Rosen, A. Viswanathan, and R. Callon,
“Multipro-tocol Label Switching Architecture,”IETF RFC 3031, Jan. 2001.
[21] J. Rosenberg, H. Schulzrinne, “An Offer/Answer Model with the Session Description Protocol (SDP)”.
RFC 3264, June 2002.
[22] J. Rosenberg, “A Presence Event Package for the Ses-sion Initiation Protocol (SIP)”.Internet Draft (Work in Progress), (In the RFC editor queue pending for publica-tion), draft-ietf-simple-presence-10.txt, July 2003. [23] J. Rosenberg, H. Schulzrinne, G. Camarillo, A.
John-ston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, “SIP: Session Initiation Protocol”,IETF RFC 3261, June 2002.
[24] H. Schulzrinne et al. “RTP: A Transport Protocol for Real-Time Applications”IETF RFC 1889Jan 1996. [25] Y.-C. Tseng, S.-Y. Ni, Yuh-Shyan Chen, and J.-P.
Sheu, “The Broadcast Storm Problem in a Mobile Ad Hoc Network,”ACM Wireless Networks, Vol. 8, No. 2, pp. 153-167, 2002.
