OLSR based Peer to Peer

Instant Messaging for Ad-hoc Networks

Nesrine Ayed Sahloul, Lamia Ben Azzouz and Farouk Kamoun

University of Manouba, ENSI CRISTAL Laboratory, Tunisia

nesrine.ayedsahloul@ipeit.rnu.tn, lamia.benazzouz@ensi.rnu.tn, frk.kamoun@planet.tn

Abstract‒‒Instant messaging is one of the most popular

applications on the Internet. Furthermore, we assist to the

emerging of Peer to Peer systems based on a decentralized

architecture. These systems share similarities with spontaneous

Ad-hoc networks. The crossing of the Ad hoc networks and the

Peer to Peer systems opens a field of possibilities for new

spontaneous collaborative applications such as the instant

messaging. In this work, we propose a Peer to Peer instant

messaging system for Ad-hoc networks based on the IETF work

in progress. This will guarantee the opening and the viability of

the system.

Keywords-Instant messaging; P2PSIP, DHT; Ad hoc Network;

OLSR

I. INTRODUCTION

Today, instant messaging is becoming the favourite application for a very large number of users. It facilitates communications and information’s exchange between users.

These last years, we have witnessed the emergence of Peer to Peer systems. They are based on a decentralized architecture and don't require servers. All peers are equivalent and can be servers or clients. Thus, Peer to Peer architecture allows deployment and development of various applications such as voice over IP, sharing files and instant messaging.

The most existing instant messaging systems adopt a centralized architecture and use owners not standardized protocols [2,3]. However, the IETF has standardised a protocol that allow to set up applications such as voice over IP and instant messaging called SIP/SIMPLE. SIP is a protocol that can establish, modify and terminate multimedia session [17]. Its architecture is composed of two entities SIP servers (registrar server, location server, redirect server and proxy server) and SIP users' agents. Today, an IETF working group propose a version of Peer to Peer SIP protocol. This work is described in the work in progress "P2PSIP"[1,4].

Wireless Ad-hoc networks are a popular subject of research because it’s easy to deploy. Nodes connect to each other without any infrastructure. Ad-hoc networks present many similarities with Peer to Peer systems. Indeed, in Ad hoc networks, all nodes are equivalent and act as routers. Thus, a client/server architecture is not adapted for these networks and the notion of server becomes obsolete. Furthermore, as Peer to Peer system, Ad-hoc networks are formed spontaneously and not stable. Nodes leave and join the network at any time. The crossing of Ad hoc networks and Peer to Peer systems opens a field of possibilities for new spontaneous collaborative

applications such as instant messaging.

Various research works were interested to combine Ad-hoc and Peer to Peer modes to implement Peer to Peer applications or systems which facilitate the deployment of these applications as the DHT: Distributed Hash Table. However, proposed solutions define owners protocols and present many inconveniences (example: important overhead, scalability, etc).

In this paper, we propose a Peer to Peer instant messaging system for Ad-hoc networks entitled IMOLSR (Instant Messaging over OLSR). To guarantee an opening of the solution, the proposed work is based on the IETF work in progress "P2PSIP". Moreover, because IMOLSR is deployed in wireless networks where the bandwidth is limited, we opt to transport necessary informations to the IMOLSR application by exploiting Ad-hoc routing protocols. In fact, this can minimize the overhead generated by IMOLSR messages.

This paper is organized as follows: in section 2, we present a state of the art of Peer to Peer instant messaging proposed in wired networks and in Ad-hoc networks. In section 3, we describe the proposed solution IMOLSR. Section 4 presents simulations conducted to evaluate performances of IMOLSR application. Finally, in section 5, we outline future work.

II. STATE OF THE ART

In this section, we present Peer to Peer instant messaging systems proposed in the literature for wired and wireless networks.

2.1. Peer to Peer instant messaging for wired networks

Few Peer to Peer instant messaging systems are implemented such as Skype, Wengo and Waste. These systems use owners protocols and don't allow interoperability [3, 13, 5]. However, in the literature, we find various works proposing open systems that use standard protocols such as SIP/SIMPLE. These works are the SOSIMPLE solution [2, 3, 5] and the architecture proposed by the IETF P2PSIP work in progress [1, 4]. Such solutions are defined for structured Peer to Peer system based on DHT (Distributed Hash Table). In this section, we present, in a first step, the DHT system. Then, in a second step, we describe the SOSIMPLE solution. Finally, we present the IETF proposition.

2.1.1. What is DHT?

The DHT (Distributed Hash Table) is a system which allows resources location and discovery in a structured Peer to

978-1-4244-8435-5/10/$26.00 ©2010 IEEE

Peer environment. Many DHT such as CHORD, PASTRY and CAN exist. The DHT represents a virtual space: the KeyIds space [13]. Each node and each resource has a single identifier in a common space:

• Hash(IP) for a node,

• Hash (key) for a resource.

The identifier allows nodes and resources identification in the Peer to Peer environment. Each node is responsible for a zone of KeyIds space and disposes of a routing table to be able to route requests. This table allows locating a node responsible for the zone containing a resource R. A message arrives to a node responsible for the zone containing a resource R in a hops number about log (N).

2.1.2. SOSIMPLE

SOSIMPLE (Self Organizing SIMPLE) [2,3,5] is a Peer to Peer instant messaging system using SIP/SIMPLE protocol. It permits standard functionalities of instant messaging systems such as, registration, location and presence notification. It is based on a structured Peer to Peer network that uses CHORD DHT. SOSIMPLE is based on SIP where each node has a SIP URI resembling an e-mail address. Thus, the register ID is obtained by hashing the SIP URI.

The registration is done in the node having the nearest identifier of the requested node. Resources location and discovery in SOSIMPLE are based on CHORD where nodes are ordered by the ascending order of their identifiers on the virtual ring. For presence notification, a node can send a message SUBSCRIBE to a receiver already contacted asking it to send a message NOTIFY to get informations about its availability.

2.1.3. The IETF work in progress “P2PSIP”

The IETF work in progress “P2PSIP” proposes an architecture for Peer to Peer SIP systems [1].

In P2PSIP architecture there are two types of nodes: super nodes (SN: Super Node) and ordinary nodes (ON: Ordinary Node) (see Figure.1). Super nodes participate in the DHT construction and maintenance.

Figure 1. P2PSIP architecture

Each ordinary node is associated with one or several super

nodes. To discover a resource, an ordinary node sends a request message to the super node. Then, the super node routes the search request message via the DHT.

A peer in P2PSIP is composed of two layers: the SIP layer and the P2P overlay layer. The SIP layer ensure the SIP functionalities such as the initiation call, SIP inscription, and the closing call. The P2P overlay layer registers and provides the location of various SIP resources.

2.2. Ad-hoc Networks Peer to Peer instant messaging.

In the literature, we can find solutions based on clustering for Ad-hoc networks to set up instant messaging system. Others propose SIP version for Ad-hoc networks. Many works are even interested by adapting systems that allow resources discovery in such environment (DHT for Ad-hoc networks).

2.2.1. Solutions based on clustering

The clustering is used to divide an Ad-hoc network into clusters managed by leaders called Cluster Head (CH).

[10] exploits the clustered Ad-hoc networks to set up a DHT. The proposed architecture is essentially composed of:

The TT-DHT (Top-Tier Distributed Hash Table): that is a virtual network of CHs nodes. It allows data and control messages routing between nodes belonging to the separated LT-DHT.

LT-DHT (Low-Tier Distributed Hash Table): is a virtual network of nodes responsible of intra cluster communications and CHs election. (See Figure.2)

Figure 2. Clustering based on DHT architecture

In this architecture, CH acts as a gateway for Ordinary Nodes associated to it by relaying informations between clusters. The discovery of a resource is done primarily in the cluster which belongs to the requestor node. Then, the discovery request is forwarded to the TT-DHT if the resource is not found.

In [6], SIP/SIMPLE protocol is adapted for ad-hoc networks by using the clustering concept. The clustering

Cluster A

Cluster B

Cluster C

TT-DHT LT-DHT

ON

CHC

CH (Application Layed)

CH (Network Layed)

creates a virtual topology to route SIP messages allowing resources discovery and location. Each node is a SIP User Agent and CHs ensure functionalities of a SIP proxy and a SIP Registrar server. In [6], CH is distant about two or three hops to another CH. Thus, each CH maintains a connectivity with CHs neighbors through nodes called gateway.

Figure 3. SIP/SIMPLE based on clustering

To contact a node, the sender must send a request (REQUEST) to its CH. If a CH knows the target URI, it sends this request to the receiver node. Otherwise, it transmits the message to CHs neighbors. Each CH records its address in the field RECORD-ROUTE of SIP message. This field will contain the list of CHs crossed to reach the receiver node. By receiving the request, the receiver node sends a SIP OK via the opposite way specified by the field Record-route (see Figure.3). After receiving SIP OK, the node which initiates the request can communicate directly with it. The presence notification messages are sent similarly to SIP OK messages.

The clustering allows hierarchical architecture facilitating discovery and location resources in Ad-hoc networks. This method allows also scalability but remains expensive in bandwidth, and slow for an application such as instant messaging. Indeed, the initiation phase, based essentially on the clustering and the creation of virtual topology, generates an important delay and a significant overhead. Moreover, the clustering is generally adapted to large scale networks.

2.2.2. SIP/ SIMPLE in Ad-hoc networks

In this section, we present a framework which proposes a SIP/SIMPLE adaptation for Ad-hoc networks [8]. This framework allows users to participate in conferences and to exchange instant messages with participants. It is based on the broadcast and the multicast. Thus, to discover participants each UA broadcasts a REGISTER message and each node records SIP URI and IP addresses of all nodes in its cache for a limited time. In the same way, to begin a conference, the initiator node (which initiates a conference) broadcasts a REGISTER message with a Conf-ID field containing identifiers of conferences for which this initiator is the leader. On the other hand, to take part in a conference, it is enough to send a message INVITES to the leader who sends a CONF message to all participants. Finally, to leave a conference the leader sends a BYE message to all participants.

This framework [8] is simple, but it is based on a

broadcast. It is not therefore scalable. Moreover, it generates an important overhead in an environment where the bandwidth is limited.

2.2.3. DHT in mobile Ad hoc networks

The bandwidth limitation and the mobility constitute a challenge to deploy DHT in mobile Ad-hoc networks. Thus, we find in the literature works that present new systems specific to Ad-hoc networks. These systems achieve DHT functionalities. Others works, adapt existing DHT in this type of networks.

Nom [9] is a decentralized system of resources location and discovery proposed for the mobile Ad-hoc networks. For ensuring DHT functionalities, Nom uses a broadcast. This system is exploited in a framework called DAWN [11] that ensures instant messaging functionalities. Nom is a simple location and discovery system because it is based on the broadcast. However, it generates a significant traffic which depends on network density. So it is not scalable.

Other research works proposed an adaptation of existing DHT in mobile Ad-hoc networks by using routing protocol. The proposition described in [7] combines the advantages of DHT PASTRY and those of the on–demand Ad-hoc routing protocol, DSR. This solution proposes two different approaches. The layered approach implements DHT PASTRY directly on top of DSR. The integrated approach called EKTA that inserts PASTRY at the network layer. Thus, PASTRY and DSR form the same structure and allows exploiting the interactions between these two protocols and optimizes the routing performance. The two approaches have an advantage compared other solutions because they are not based on the broadcast.

The use of the DHT Pastry and routing protocol DSR minimizes the overhead generated by the various messages allowing resources location and discovery. However, the two approaches exploit simultaneously Pastry messages and DSR messages to be able to provide instant messaging functionalities. It would be interesting to transmit data that are necessary to PASTRY in DSR message.

III. THE PROPOSED SOLUTION: IMOLSR

The majority of propositions described previously present limits, because they exchange a great quantity of data and generate a significant overhead. These solutions are not scalable and owners. Thus, to define an open Instant Messaging system for Ad-hoc Networks, we chose the IETF P2PSIP protocol which is described in [1, 4]. The proposed application called, in the rest of paper, IMOLSR (Instant Messaging over OLSR) exploits OLSR Ad-hoc routing protocol and CHORD DHT. To minimize the traffic generated by the application, we propose to use OLSR messages to forward necessary informations to IMOLSR application.

In this section, we present firstly the OLSR Ad-hoc routing protocol and we justify its uses. Then, we describe the proposed IMOLSR architecture.

3.1. OLSR Ad-hoc routing protocol

OLSR is a proactive Ad-hoc routing protocol. In fact, the

CH

ON

ON

ON

ON

CH

CH

ON

ON

ON

CH

CH

ON

ON

ON

ON

ON

ON

CH

Odinary Node

Cluster Head

Req1

Req2

Req2

Res1 Res2 Req

Res

Request

Response

Req3

routing of packages is carried out by using a routing table established before any communication. OLSR is a link state protocol where each node regularly broadcasts informations about its neighbors in the network. This routing protocol optimizes the link state algorithm by flooding its neighbors intelligently [12], via "multipoint relays" (MPR). Indeed, only the MPR nodes relay messages, which significantly reduce the number of retransmissions and redundant informations. Each node of the network selects, among its neighbors, a MPR set

which can cover the two hops neighbors. To have immediate

route with all the destinations, each node maintains informations bases supplied by OLSR messages. OLSR uses four types of messages: the most important are HELLO messages and TC messages. HELLO messages are generated periodically by each OLSR node and must never be forwarded. TC messages are broadcasted and retransmitted by MPR nodes in the entire network.

3.2. Why OLSR?

OLSR is a very popular routing Ad-hoc protocol. Its code source is available in [18, 19]. Furthermore, OLSR present similarities with P2PSIP architecture. In fact, it defines two types of nodes: ordinary nodes and MPR nodes [12]. In the same way, P2PSIP architecture defines also ordinary nodes and super nodes. So, we chose to adapt P2PSIP architecture on OLSR. Thus, MPR OLSR nodes will design P2PSIP super nodes. Moreover, P2PSIP ordinary nodes are associated to one or more super nodes. This is coherent with OLSR protocol because each node has a set of MPRs.

3.3. IMOLSR architecture

In the proposed application, we have four types of nodes (See Figure.4):

• Super nodes called IMOLSR MPR: MPRs nodes which participate in IMOLSR application.

• IMOLSR ordinary nodes: IMOLSR nodes which are not MPRs and participate in IMOLSR application.

• MPR nodes: MPRs nodes which don't participate in IMOLSR application.

• Ordinary nodes: nodes that don't participate in the application.

Figure 4. IMOLSR Architecture

3.4. Protocol stack

In the proposed P2PSIP architecture, super nodes are responsible for the construction and the maintenance of the

DHT. Thus, IMOLSR MPR nodes will form the DHT virtual ring. We chose to exploit CHORD, because it is simple, available and an open protocol [20].

Furthermore, the application layer of each node is composed of two sub layers: the SIP layer and the P2P overlay layer (see Figure.5) to be conformed to draft [4]. In the network layer, we will find the OLSR Ad-hoc routing protocol.

Figure 5. Protocol stack of IMOLSR nodes

3.5. IMOLSR Instant Messaging

In the proposed solution, we define five steps: the initialisation process, the registrar process, the location and discovery process, the update process, and the presence notification process.

We chose to transport necessary informations to the various steps of IMOLSR in OLSR HELLO and TC messages. This will allow minimizing the overhead in Ad hoc networks. However, to remain in conformity with standardization, OLSR messages structure will not be modified and informations will be carried in the "Reserved" field of these messages which is not exploited.

3.5.1. Initialisation process

The initialisation process consists in the construction of the CHORD virtual ring. CHORD Ring is formed by IMOLSR MPR. Thus, each node IMOLSR MPR hashes its IP address by using a hashing function (Sha-1, MD5, etc) and obtains an identifier on m bits. IMOLSR MPR identifiers are broadcasted in the network to build CHORD virtual ring. IMOLSR MPRs are ordered, into ascending order by their identifiers on the virtual ring.

In IMOLSR application, we chose to exploit OLSR TC messages to transmit IMOLSR MPR identifiers in the network. Indeed, periodically all MPRs send TC messages. These TC messages are received by all MPR nodes of the Ad-hoc network and particularly by IMOLSR MPR. Thus, we add following fields which will be transported in the "Reserved"

IMOLSR

Ordinary node

IMOLSR

MPR

MPR

IMOLSR MPR

MPR

IMOLSR

MPR

Ordinary

node

Ordinary

node

Ordinary

node Ordinary

node

IMOLSR

Ordinary node

IMOLSR

Ordinary node

IMOLSR

Ordinary node

IMOLSR

Ordinary node

Ordinary

node

SIP Layer

P2P

Overlay

Layer SIP Layer

P2P

Overlay

Layer

SIP Layer

P2P

Overlay

Layer

SIP Layer

P2P

Overlay

Layer

SIP Layer

P2P

Overlay

Layer

SIP Layer

P2P

Overlay

Layer

SIP Layer

P2P

Overlay

Layer

SIP Layer

P2P

Overlay

Layer

SIP Layer

P2P

Overlay

Layer

IMOLSR

MPR

IMOLSR

MPR

IMOLSR

MPR

IMOLSR

Ordinary

node

IMOLSR

Ordinary

node

IMOLSR

Ordinary

node

IMOLSR

Ordinary

node

IMOLSR

Ordinary

node

IMOLSR

MPR

field (16 bits) of the TC message.

• A field called "type" (composed of two bits) to identify an initiation message for IMOLSR application.

• A field called "Idm" (of thirteen bits) containing the initiation identifier of IMOLSR MPR node.

3.5.2. Registration process

The registration process will allow a node to participate in IMOLSR application. Each IMOLSR node uses CHORD to obtain a registration identifier by hashing its SIP URI. The registration is done by storing the identifier and the corresponding IP address in an IMOLSR MPR node. The node registration is not permanent, it must be done periodically. In the proposed solution, there are two types of nodes participating in IMOLSR application: ordinary and MPR nodes. Thus, we define a registration process for an IMOLSR ordinary node and for an IMOLSR MPR node.

3.5.2.1. Ordinary node Registration

An ordinary node is registered in an active MPR IMOLSR. Furthermore, each OLSR ordinary node sends periodically a HELLO message to neighbors nodes. For that, we opt to transport registration informations in HELLO message. These informations are made of the registration identifier and the IP address. In the application, to identify a HELLO message transporting an ordinary node registration request, we define in the "Reserved" field (16 bits) of the HELLO message following fields:

• A field called "Type" (of two bits) to identify a registration message of an ordinary node

• A field entitled "Idm" (of thirteen bits) containing the registration identifier of the ordinary node.

To minimize transported informations, we exploit the "Originator Address" field of the HELLO message heading to transport the IP address of the node asking registration.

IMOLSR MPRs nodes, neighbors at one hop from the node that transmitted registration "HELLO" message, recover the registration identifier and proceed in two steps:

• Each IMOLSR MPR compares the registration identifier to its identifier and to those of nodes existing in its finger table. If its identifier is close to the registration identifier, it stores registration informations in its base.

• Otherwise, it sends a TC message to broadcast these informations to other IMOLSR MPR nodes.

We exploit the "Advertised Neighbor Main Address" field of the TC message to transmit the IP address of the ordinary node that has sent the registration request. The IP address is inserted in the first position of this TC message field and "Type" and "Idm" fields already defined will be forwarded in the TC registration message.

3.5.2.2 IMOLSR MPR node registration

Registration informations of IMOLSR MPR node are sent in a TC message which will be broadcasted in the entire network. The IP address is transported in the "Originator

Address" field of the TC message heading. The "Type" and "Idm" fields will contain the message type and the registration identifier of the IMOLSR MPR node asking registration.

The tuple formed by the IP address and the registration identifier of the node asking registration is stored, in the node having the closest identifier

3.5.3. Location and discovery process

The discovery and location process allows finding IP address of an IMOLSR receiver. This will be done independently of OLSR messages that are periodical. When a node needs to locate an IMOLSR participant, it hashes the SIPURI of this node and uses DHT CHORD to locate the contact.

If the sender is an ordinary node, it sends a request message to an IMOLSR MPR node (a node among its MPR set which participate in IMOLSR application). The selected IMOLSR MPR node routes the request according CHORD location and discovery mechanisms [14,15]. Once the receiver node is localised, the node responsible for this resource sends the receiver IP address directly to the IMOLSR MPR which initiate the request. This later forwards the result to the concerned ordinary node.

If the node is an IMOLSR MPR, location of the receiver node will be done according to CHORD mechanisms [14,15] and location result will be sent directly to the concerned node

3.5.4. Update process

The update process takes into account the system behavior when an IMOLSR node leaves, joins the network or a link breaks between an ordinary node and an IMOLSR MPR.

3.5.4.1. Update process when an IMOLSR node joins the

network

When an IMOLSR node joins the network, according OLSR, it calculates its MPRs set. Then, it identifies MPRs that participate in the application. If an IMOLSR ordinary node has become an IMOLSR MPR, it has to join the CHORD virtual ring by using TC messages.

Moreover, OLSR nodes having a bidirectional link with this new node will recalculate their MPRs [28]. This update of OLSR protocol has consequences on IMOLSR updates:

• If IMOLSR MPRs nodes are eliminated, CHORD ring will be updated.

• If IMOLSR ordinary nodes are elected as MPR, they have to join CHORD ring.

3.5.4.2. Update process when an IMOLSR node leaves the

network

When an IMOLSR node leaves the network, each node in one hop or two hops in the neighbourhood of this IMOLSR node and having a bidirectional link with it, recalculates its MPRs set [28]. As a Consequence, IMOLSR MPRs can leave the CHORD ring and a new IMOLSR MPR set will join the virtual ring. Moreover, if the leaving node is an IMOLSR MPR, an update of the CHORD ring is done. If the node is suddenly disconnected, CHORD updates algorithms, allow the

correction of inconsistencies.

3.5.5. Presence notification process

The presence notification process allows IMOLSR participants to inform other nodes of their status (connected, disconnected or unavailable). Thus, in IMOLSR, each node must notify its status periodically. Moreover, each node records, in its contacts, SIP addresses (SIPURI), the registration identifiers (hash (SIPURI)) and the status of each SIPURI.

In the proposed IMOLSR application, we define presence notification process for an ordinary node and for an IMOLSR MPR node.

OLSR HELLO messages are used to carry informations about presence status of ordinary node (registration identifier node and status). IMOLSR MPRS that receive this type of HELLO message send TC message to broadcast these informations in the entire network.

If the node that wants to notify the presence status is an MPR node, the necessary informations for this notification will be carried in TC messages

For this notification presence process we opted to add a field called "Pr" of one bit which will be transported in the "Reserved" field of HELLO and TC messages. This field will contain the presence status of an IMOLSR node. In the same way, "Type" and "Idm" fields will be exploited to transport the message type and the registration identifier.

IV. IMOLSR PERFOMANCES EVALUATION

In this section, we evaluate the registration process performances by simulation. In fact, registration process is very important for an appropriate operation of IMOLSR application. Moreover, it depends strongly on the OLSR routing protocol. Thus, we used the NS-2 simulator [16] to evaluate IMOLSR performance and we integrated the module Um-olsr 0.8.8. This module was modified to support the registration process.

We fixed as criteria the success rate of registration for various IMOLSR MPRs percentages. This criteria is studied while varying the simulation area, the transmission range, mobility, and the density of the network.

4.1. Results for a small simulation area

In this scenario, we fixed a simulation area of 100×150 m². First, we considered three different transmission ranges (10 m, 30 m and 50 m) while varying the node number in the network. Then, we considered a network of 40 nodes, fixed the transmission range and varied the mobility.

4.1.1. Simulation results while varying transmission range

In this section, the nodes number varies from 10 to 70 and the mobility is fixed to 4m/s

Figures 6, 7 and 8 show the registration success rate variation according to the number of nodes for three different transmission ranges.

0

0.2

0.4

0.6

0.8

1

10 20 30 40 50 60 70

Ta

ux d

e s

ucce

s d

e l e

nre

gis

tre

me

nt

nombre de noeuds

25% MPR_IMOLSR50% MPR_IMOLSR75% MPR_IMOLSR

Figure 6. Registration success rate for a small simulation area with a

transmission range of 10m

0

0.2

0.4

0.6

0.8

1

10 20 30 40 50 60 70

Ta

ux d

e s

ucce

s d

e l e

nre

gis

tre

me

nt

nombre de noeuds

25% MPR_IMOLSR50% MPR_IMOLSR75% MPR_IMOLSR

Figure 7. Registration success rate for a small simulation area with a

transmission range of 30m

0

0.2

0.4

0.6

0.8

1

10 20 30 40 50 60 70

Taux d

e s

ucces d

e l e

nre

gis

trem

ent

nombre de noeuds

25% MPR_IMOLSR50% MPR_IMOLSR75% MPR_IMOLSR

Figure 8. Registration success rate for a small simulation area with a

transmission range of 50m

The success rate increases slightly with the increase of the nodes number because the MPR number also increases slightly and this is due to OLSR protocol. With a percentage of 25% of IMOLSR MPRs , the registration success rate varies from 0% to 24%, with 50% of IMOLSR MPRs the rate is included between 0% and 49% and with 75% of IMOLSR MPRs, the success rate varied from 33% to 74%. We can notice that the best results are obtained for 30m transmission range where the success rate can reach 74%.

For the three fixed ranges, when the percentage of MPR participating in IMOLSR is 25%, the registration success rate does not exceed 24%. On the other side, we notice an increase of the registration success rate according to the increase in the percentage of the IMOLSR MPRs. The registration success rate reaches 74% when IMOLSR MPRs percentage is 75%.

For the three used ranges and from density of thirty nodes,

Nodes number

Nodes number

Nodes number

we notice that the variations of the registration success rate are not significant because the average of the MPR number varies slightly according to the density.

With a transmission range of 10m, the registration success rate of ten nodes is 0% when the IMOLSR MPR percentage is respectively 25% and 50% because with a very low density, the number of MPRs generated by OLSR is very small. It is not the case when we modified the transmission range. We conclude that the transmission range has an impact on the number of MPRs in the network. Therefore, it has an impact on IMOLSR registration success.

4.1.2. Simulation results while varying mobility

In this section, we fixed a transmission range of 30m because it gives best results and varied mobility.

0.2

0.3

0.4

0.5

0.6

0.7

0.8

2 3 4 5 6 7 8 9 10

Ta

ux d

e s

ucce

s d

e l e

nre

gis

tre

me

nt

vitesse maximale(m/s)

25% MPR_IMOLSR50% MPR_IMOLSR75% MPR_IMOLSR

Figure 9. Mobility impact on the registration success rate for a small

simulation area

Figure 9 shows the registration success rate variation according to the mobility for various IMOLSR MPRs percentages. We notice that the registration success rate is almost constant when we vary mobility. The instability of the network does not have impact on the success rate of the registration process. In fact, the mobility of the nodes does not modify the number of MPRs in the network. This is due to OLSR updates process.

4.2. Results for a large simulation area

In this scenario, we considered a simulation area of 1000×1500m², we fixed three different transmission ranges (110m, 180m and 250m), a mobility of 4m/s and varied the nodes number in the network. Then, we fixed the transmission range and varied the mobility.

4.2.1. Simulation results while varying transmission range

Figures 10, 11, and 12 represent the registration success rate variation of IMOLSR according to the density of the network for three different IMOLSR MPR percentages.

For low density, we can notice that the best results are obtained for transmission range of 180m. Thus, the registration success rate depends on the network density and the transmission range. Probably, OLSR gives the greatest number of MPRs for the transmission range of 180m.

With a transmission range of 250m and a very low density, the registration success rate is very low compared to the 180m one. This is due to OLSR protocol where the MPR number is very small for a low density.

From density of thirty nodes, the transmission range impact on the registration success rate is less significant because the average of MPR number generated by OLSR is almost constant.

0

0.2

0.4

0.6

0.8

1

10 20 30 40 50 60 70

Taux d

e s

ucces d

e l e

nre

gis

trem

ent

nombre de noeuds

25% MPR_IMOLSR50% MPR_IMOLSR75% MPR_IMOLSR

Figure 10. Registration success rate for a large area simulation with a

transmission range of 110m

0

0.2

0.4

0.6

0.8

1

10 20 30 40 50 60 70

Taux d

e s

ucces d

e l e

nre

gis

trem

ent

nombre de noeuds

25% MPR_IMOLSR50% MPR_IMOLSR75% MPR_IMOLSR

Figure 11. Registration success rate for a large simulation area with a

transmission range of 180m

0

0.2

0.4

0.6

0.8

1

10 20 30 40 50 60 70

Taux d

e s

ucces d

e l e

nre

gis

trem

ent

nombre de noeuds

25% MPR_IMOLSR50% MPR_IMOLSR75% MPR_IMOLSR

Figure 12. Registration success rate for a large simulation area with a

transmission range of 250m

4.2.2. Simulation results while varying mobility

In this section, we fixed a transmission range of 180m.

Figure 13 shows the registration success rate variation according to the mobility for different IMOLSR MPR percentages. On the one hand, when the mobility is equal to or higher than 4m, we observe that the registration success rate is almost constant. On the other hand, we observe an increase of the success rate when varying the mobility from 2 to 4m. This is can be explained by network topology where some nodes are isolated because the density is very low.

Nodes number

Nodes number

Maximum speed (m/s)

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

2 3 4 5 6 7 8 9 10

Taux d

e s

ucces d

e l e

nre

gis

trem

ent

vitesse maximale(m/s)

25% MPR_IMOLSR50% MPR_IMOLSR75% MPR_IMOLSR

Figure 13. Mobility impact on the registration success rate for a large

simulation area

4.3. Conclusion

The registration success rate depends on the MPR number and essentially the MPR number participating in IMOLSR application. We notice that for the simulation area adopted, the important success rate is obtained when the percentage of IMOLSR MPR reaches 75%. The registration process operates for different area size but it must be chosen an adequate transmission range because it has a significant impact on the MPR number essentially when the network density is very low.

V. CONCLUSION

Today, many works are interested in defining Peer to Peer instant messaging. The IETF work in progress "P2PSIP" proposes a version of SIP in Peer to Peer environment. Because Ad-hoc networks have many similarities with Peer to Peer systems, we were interested in defining Peer to Peer instant messaging for Ad-hoc networks based on IETF works. The proposed solution IMOLSR exploits the OLSR routing protocol to transport many SIP necessary informations to ensure Peer to Peer instant messaging functionalities. This allows minimizing the overhead generated by the application in an environment where the bandwidth is limited. The IMOLSR architecture designs MPR nodes as the super nodes defined by IETF P2PSIP architecture. Moreover, we have exploited CHORD DHT for SIP resources location and discovery. CHORD ring is made by IMOLSR MPRs.

We have conducted simulations to evaluate the registration process performances by considering as criteria the success rate. We noticed that the registration success rate is strongly related to the percentage of MPR number participating in IMOLSR. Furthermore, the transmission range has a significant impact on the registration success rate when the network density is low. This is due to the MPR number generated by OLSR routing protocol.

For future works, it will be interesting to test the solution in a real environment for example an Ad-hoc network called VANET (Ad hoc Vehicular Networks).

REFERENCES

[1] D. Willis, D. Bryan, P. Matthews and E. Shim, "Concepts and terminology for peer-to-peer SIP". IETF Internet Draft (work in progress) – March.2007

[2] D. Bryan and B. Lowekamp, ''SOSIMPLE: A SIP/SIMPLE Based P2P VoIP and IM System''. Technical Report, Computer Science Department, College of William and Mary. Williamsburg (Virginia), USA – November 2004.

[3] D. Bryan, B. Lowekamp and C. Jennings, ''SOSIMPLE: A Serverless, Standards-based, P2P SIP Communication System''. Proceedings of the International Workshop on Advanced Architectures and Algorithms for Internet Delivery and Applications (AAA-IDEA 2005) – June 2005.

[4] E.shim, S.Narayanan and G.Daley, ''An Architecture for Peer-to-Peer Session Initiation Protocol (P2P SIP)''. Internet-Draft – February 2006.

[5] D. Bryan: ''SOSIMPLE - Self Organizing SIMPLE, A Proposed P2P Instant Messaging System''. Course of P2P and Grid Systems – The College of William and Mary. Williamsburg (Virginia), USA – December 2003.

[6] N. Banerjee, A. Acharya and S. Das, ''Peer-to-Peer Instant Messaging and Presence Services over Wireless Ad Hoc Networks''. Proceeding of the 1st International Workshop on Broadband Wireless Multimedia (BroadWiM). San José(California), USA – August 2004.

[7] H. Pucha, S. M. Das, and Y. Charlie Hu, ''How to Implement DHTs in Mobile Ad Hoc Networks?''. Proceedind of the 10th ACM International Conference on Mobile Computing and Network (MobiCom). Philadelphia, USA – September 2004.

[8] H. Khlifi, A. Agarwal and J.-C. Gregoire, ''A Framework to use SIP in Ad hoc networks''. Proceeding of the Canadian Conference on Electrical and Computer Engineering - IEEE CCECE 2003. Canada – May 2003.

[9] D. Doval and D. O’Mahony, ''Nom: Resource Location and Discovery for Ad Hoc Mobile Networks''. Proceeding of the 1st Annual Mediterranean Ad Hoc Networking Workshop. Sardaigne, Italy – 2002.

[10] A. O. Driscoll, S. Rea, and D. Pesch, ''A Framework for Supporting Structured Peer-to-Peer (P2P) Overlays over Large Scale Mobile Ad Hoc Networks (MANETs)''. Proceeding of the 18th World Wireless Research Forum (WWRF). Espoo, Finland – June 2007.

[11] D. Greene and D. O'Mahony, ''Instant Messaging & Presence Management in Mobile Ad-Hoc Networks''. Proceedings of the Second IEEE Annual Conference on Pervasive Computing and Communications Workshops. Orlando (Florida), USA – March 2004.

[12] T. Clausen and P. Jacquet, ''Optimized Link State Routing Protocol (OLSR)''. IETF RFC 3626 Network working Group : Project Hipercom. INRIA – October 2003.

[13] F. Lesueur and L. Mé, ''Sécurité dans les réseaux Pair-à-Pair''. Rapport de stage – Supélec Rennes. France – June 2006.

[14] I. Stoica, R. Morris, D. Liben-Nowell, D. Karger, M. F. Kaashoek, F. Dabek and H. Balakrishnan, ''Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications''. Journal of Transactions on Networking (TON), IEEE/ACM, Vol. 11 – February 2003.

[15] S. Leggio, H. Miranda, K. Raatikainen and L. Rodrigues, "SIPCache: A Distributed SIP Location service for Mobile Ad-Hoc Networks". Proceedings of the 3rd Annual International Conference on Mobile and Ubiquitous Systems: Networks and Services (MOBIQUITOUS 2006). San Jose (California), USA – July 2006.

[16] P. Anelli and E. Horlait, ''NS-2: Principes de conception et d'utilisation''. – 1999 september http://www.sop.inria.fr/rodeo/personnel/Pierre.Ansel/Manuel_NS1.3.pdf

[17] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley and E. Schooler, ''SIP: Session Initiation Protocol''. IETF RFC 3261 – June 2002.

[18] http://masimum.inf.um.es/?Software:UM-OLSR

[19] http://www.olsr.org/

[20] http://hg.pdos.csail.mit.edu/hg/dht chord-0.1

Maximum speed (m/s)