04912231

752

&

www.ietdl.org

Published in IET CommunicationsReceived on 6th May 2008Revised on 1st September 2008doi: 10.1049/iet-com.2008.0275

In Special Issue on Wireless Ad-Hoc Networks

ISSN 1751-8628

Mobile IP handoffs among multiple internetgateways in mobile ad hoc networksS. DingInstitute for Telecommunication Research, University of South Australia, Mawson Lakes, SA, AustraliaE-mail: [email protected]

Abstract: In a mobile ad hoc network (MANET) with multiple Internet gateways, efficient management of mobileIP functionality supporting seamless data services is a major challenge. The inadequacy of existing mobile IPschemes applicable to MANETs motivated the search for more efficient gateway discovery/handoff schemes.A solution for mobile IP-based gateway discovery/handoff in dynamic source routing (DSR)-based MANET isformulated. Enhanced mobile IP protocol suitable for MANET environment, i.e. the mobile IP registrationcontroller, is designed. In particular, one of the most significant contributions deals with the mobile IP handofftriggering mechanism which is adaptively assisted by the DSR route maintenance mechanism. Simulationresults are provided to support the idea.

1 IntroductionFourth-Generation (4G) wireless communication systemsaim at integrating heterogeneous networks seamlessly, tosatisfy users’ increasing demands in terms of bandwidthand coverage [1]. Recently, multi-hop techniques have beenenvisioned as an important component of 4G wirelessnetworks, in which end user terminals can communicatewith the wired infrastructure backbone via the multi-hoprelays of ad hoc nodes. Thus 4G systems will becomeconvergence platforms with widespread coverage availableby the integration of multi-hop capability. Moreover, IPmobility [2] may be available in such 4G convergencesystems, to serve the needs of globally mobile users tomaintain uninterrupted connectivity when roaming todifferent domains, including the mobile ad hoc networks(MANETs) domain.

With respect to the interesting scenario of connectingstand-alone MANETs with the Internet, if mobile nodesroam between MANETs and the Internet, IP mobilityoperations are required to maintain uninterruptedconnectivity. According to the mobility detectionmechanisms provided by standard mobile IP protocol, suchas lazy cell switching (LCS), prefix matching (PM) andeager cell switching (ECS) [3], a mobile node is capable ofdetecting whether it has roamed to a new network via one-

The Institution of Engineering and Technology 2009

hop link connectivity. However, in a MANETenvironment, a mobile node cannot detect the location of agateway by the reception of an agent advertisement,because the agent advertisement broadcast by the gatewaymay be relayed via multiple hops. Thus, the traditionalmechanisms of mobility detection provided by mobile IPare unsuitable to the MANET scenario. Thus far, mostexisting schemes [4–11] adopted proactive gatewaydiscovery, by which a gateway broadcasts advertisementswith fixed advertising interval, and the ad hoc nodesrebroadcast the advertisements flooding the entireMANET. So if multiple gateways broadcast, the floodingoverhead is very significant. Also, these researches did notconsider the issue of routing information piggybacking onadvertisements. As a result, duplicate route discovery mustbe executed, and further, bandwidth resources are wasted.

Furthermore, in a highly dynamic MANET where mobilenodes frequently change their locations, a mobile node isdesired to select an optimal gateway if multiple gatewaysexist, in order to achieve better services. Thus, mobile IPhandoffs among multiple gateways in MANET becomechallenging. In previous work, a MIP-MANET cellswitching (MMCS) [6, 7] mechanism was proposed, whichis a proactive, timer-driven handoff approach. A mobilenode passively performs handoffs relying on the receptionsof periodic agent advertisements. The proactive handoff

IET Commun., 2009, Vol. 3, Iss. 5, pp. 752–763doi: 10.1049/iet-com.2008.0275

IETdoi

www.ietdl.org

mechanisms have a limitation: the handoffs are not adaptiveto the dynamic network topology and traffic conditions.Therefore the reactive gateway handoff mechanism wouldbe a promising solution, which means that a mobile node isallowed to reactively discover a gateway when necessary.The prompt trigger and low overhead would be the majorinterests. In order to avoid severe communication gap onhandoff, the mobile node can promptly discover a newgateway as soon as it detects that it has lost connectivitywith its registered gateway. In response to the solicitation, agateway may unicast an advertisement to the mobile node,which will significantly decrease routing overheads. Thusfar, there still remains a largely unexplored research area inthe reactive gateway handoffs in MANET. The mainchallenge concerns the efficient design of handoff triggersand criteria that can optimise the handoff performance, e.g.lower delay and lower packet loss rate caused by thehandoff procedure.

This paper contributes an adaptive and intelligent gatewayhandoff mechanism designed for the MANET based onmulti-hop communications. A reactive handoff triggeringscheme, in which mobile IP may utilise dynamic sourcerouting (DSR) [12] routing information and trafficcondition to facilitate fast and seamless handoff services, isdesigned. The system is assumed to be an All-IP networktransparent to the physical layers comprising heterogeneoustechnologies, so the information from MAC layer will notbe used to assist the handoff procedures. The paper isorganised as follows: Section 2 introduces mobile IPpreliminary. Section 3 describes the system architecture.Section 4 outlines the mobile IP registration controller inMANET environment. Section 5 designs the reactivegateway handoff mechanism. Section 6 briefly presents theproactive gateway handoff mechanism. Simulation results areprovided in Section 7. Conclusions are drawn in Section 8.

2 Mobile IP preliminaryMobile IP users can seamlessly roam among IP networkswithout changing their home IP addresses. As shown inFigs. 1 and 2, the basic mobile IP operations include AgentDiscovery, Registration and Tunneling. The Agent Discovery

Figure 1 Mobile IP agent discovery and registrationoperation

Commun., 2009, Vol. 3, Iss. 5, pp. 752–763: 10.1049/iet-com.2008.0275

is the method by which a mobile node (MN) checks thereceived agent advertisements via one-hop link to detect itscurrent location on home or foreign network. When theMN moves to a foreign network, it can obtain a Care-ofaddress (CoA) from a foreign agent’s (FA) agentadvertisement and create a registration request to its HA.The HA sends a registration reply to the MN via theFA. After a successful registration, the HA maintainsreachability information for the MN in the foreignnetwork. All datagrams destined to the MN’s homeaddress will be tunneled to the MN’s CoA by the HA [3].

The procedure by which a MN disassociates with an oldFA and associates with a new FA is called Handoff. Inmobile IP protocol, three network-layer handoffmechanisms were defined [3]. LCS depends on the lifetimefield in an advertisement; PM depends on the prefix-lengths extension in an advertisement; ECS involvesimmediate gateway handoff on receiving a new CoA. Thesemechanisms are all based on the assumption that the MNand its HA/FA communicate via one-hop link.

3 System architectureThe proposed network architecture of an infrastructure-integrated MANET is shown in Fig. 3. The followingelements are comprised: ad hoc nodes; Internet gateways(FA/HA); correspondent nodes. Within the MANET,multiple gateways may advertise their presence periodically(proactive approach) or on-demand (reactive approach).Each ad hoc node has a globally unique identificationassociated with its HA.

Figs. 4a and 4b illustrate the protocol stacks on the gatewayand ad hoc node, respectively. The functions of theseprotocol modules are described as follows:

† Enhanced IP routing: The traditional IP routingalgorithm is enhanced. IP Packet Destination Computing(IPDC) is the main entry for processing IP packets inMANET/mobile IP integration system; IP PacketForwarding (IPF) module may handle the IP-in-IPtunneling and detunneling operations.

Figure 2 Mobile IP packet tunneling operation

753

& The Institution of Engineering and Technology 2009

754

&

www.ietdl.org

† Mobile IP: The Registration module works at theapplication layer, using UDP as the transport protocol, togenerate/process registration request/reply. The ICMPadvertising and soliciting module works at the IP layer, forgenerating/processing agent advertisement and solicitation.

† Ad hoc routing: DSR is extended to support the Internetrouting and mobile IP. DSR is mature and well defined adhoc reactive routing protocol, which represents typicalfeatures of almost all reactive routing protocols.

Figure 3 Network architecture


4 Mobile IP registration controllerfor MANETsThe mobile IP registration controller (MIPRC) is an enhancedmobile IP protocol that controls mobile IP registrations inresponse to events in MANETs, e.g. the received mobileIP signalling messages, timers and registration/handofftriggers.

4.1 Mobile host MIPRC

4.1.1 State transition diagram: The state transitiondiagram of MIPRC for mobile node is shown in Fig. 5.On each transit line, Event–Action is illustrated. Thecontroller has four idle states as suggested in [13]. The Loststate means the node is not registered with any agent; theForeign state means the node is currently registered with aforeign agent, FA_Current; the Pending Registration statemeans the node is waiting for a registration reply from apending agent, FA_Pending; the Home state means thenode is on its home network. The candidate agent addresscontained in a newly incoming advertisement is denoted asFA_New.

4.1.2 Mobile IP advertisement cache: If theMIPRC is used for infrastructure networks, on receiving anew advertisement, a mobile node in Foreign mustimmediately register with that FA, as it assumes it hasentered a new foreign network. However, in MANETcase, the reception of an advertisement should not becomethe triggering event for gateway handoff, as each node mayinevitably overhear advertisements from multiple gateways.

Figure 4 Protocol architecture

a Gatewayb Mobile host


IETdoi:

www.ietdl.org

Figure 5 MIPRC for mobile nodes

Hence, a hash table, mobile IP advertisement cache (MIPAC),is designed to manage the advertising information of multiplegateways in MANET environment. Newly incomingadvertisements will firstly be buffered in order of arrival,before they can be used for agent registrations.

4.1.3 Registration algorithm: As shown in Fig. 5, inthe Lost state, the node will try to register with a gatewayusing the first incoming advertisement by immediatelysending a registration request. Next, the node waits for avalid registration reply at its Pending Registration state. Ifthe Pending Timer expires, a registration request will beretransmitted. The change to Foreign means theregistration has officially completed. Otherwise, the nodegoes to Lost if the valid registration reply is not received.

4.1.4 Handoff interrupt and trigger: MANETrouting assists the handoffs. After receiving a newadvertisement, MIPRC will buffer it in the MIPAC andoriginate a handoff interrupt to MANET module. Thehandoff interrupt contains fields of current agent address,candidate agent address and handoff enquiry code. Onreceiving the handoff interrupt, MANET module willcompare the latest routing information of the two agents.In Foreign state, FA_Current and FA_New will becompared; in Pending Registration state, FA_Pending andFA_New will be compared. The handoff evaluation andtriggering mechanism implemented by MANET modulewill be explained in Section 5.

4.1.5 Agent interrupt holding time table: This tableis used to avoid frequent ping–pong handoffs to the same FAin a short period of time [13]. A mobile node will cancel aregistration attempt if it finds the previous registration witha gateway is still within the holding time.

4.2 Foreign agent MIPRC

Fig. 6 illustrates the state transition diagram of the MIPRCon FA (or HA) [13]. FA–HA listens to events in its Idlestate. An enhancement is that a solicitation interrupt will

Commun., 2009, Vol. 3, Iss. 5, pp. 752–76310.1049/iet-com.2008.0275

force the FA–HA to unicast an advertisement to theinitiator. Other functionalities follow the mobile IPstandard, including: timer for broadcasting, registrationmessages relays between HA and FA, IP-in-IP tunneling/detunneling, destroy of any overheard advertisement, etc.

5 Reactive gateway handoffmechanismThe reactive gateway handoff mechanism strongly dependson the route maintenance of specific ad hoc routingprotocol. DSR route maintenance mechanism will bedemonstrated as an example.

5.1 Soliciting advertisements

The trigger for actively soliciting advertisements (reactivegateway discovery) is: only these mobile nodes (initiators) thatintend to send packets to unknown destinations (possibly onthe Internet) can discover gateways reactively. The RREQssent by initiators will be treated as the solicitations for theunicast advertisements from gateways. Simultaneously,gateways and the initiator may still implement external routediscovery algorithm. This scheme is advantageous in fast,prompt trigger and significantly low overhead, which is a

Figure 6 MIPRC for gateways

755


756

&

www.ietdl.org

novel contribution of this paper. First, redundant mobile IPregistrations and flooding advertisements involving the entireMANET can be avoided. Second, soliciting advertisements iscombined with the external route discovery, so that the delayand overhead due to separate soliciting can be avoided.

On receiving the first advertisement, the initiator will try toregister with that gateway as an initial gateway, in order tochange its state from Lost to Foreign. Then, the initiatormay evaluate incoming multiple advertisements for gatewayhandoffs. Meanwhile, reactive external route construction(RERC) algorithm is adopted for external route discovery.A user-defined parameter, external route discovery time, isconfigured on the initiator, to discriminate whether thedestination in RREQ is on the Internet or not. The detailsof the RERC are beyond of the scope of this paper.

5.2 Propagating MIP signalling messages

Mobile IP layer is transparent to the propagation of mobileIP signalling messages. DSR is responsible for propagatingadvertisement, registration request and reply via selectedsource routes. An example of unicasting Advertisement isshown in Fig. 7. On a gateway, a source route option(SRO) is inserted into the advertisement packet; the TTLfield in the advertisement’s IP header is set to the networkdimension (hops, a user-defined parameter). Only on thedestination of a signalling message, the standard signallingmessage will be passed to MIPRC. The intermediate nodesalong the source route (SR) will just update the sourcerouting information.

5.3 Reactive handoff phases

The reactive gateway handoff may include three phases asfollows:

† Handoff solicitation triggering phase: This is the keyphase in the reactive gateway handoff scheme. A mobilenode may be triggered to send solicitation, when it detectsthat the unavailability of the routes towards its currentgateway has blocked the packet delivery to the Internet.

† Handoff evaluation phase: On receiving multipleadvertisements from multiple gateways, the mobile nodeevaluates the gateways’ services according to predefinedcriteria.

† Handoff phase: Once the mobile node selects a bettergateway other than its current gateway to register with, it

Figure 7 Advertisement unicast packet format in DSR


proceeds with a mobile IP handoff procedure by sending aregistration request and receiving a registration reply.

5.4 Handoff solicitation triggers

5.4.1 Overview: To understand the handoff solicitationtrigger principle, first we briefly describe the routemaintenance mechanism in standard DSR protocol. Whengenerating or forwarding a data packet with a SRO, a nodeis responsible for confirming the reachability of its nexthop, by sending an ACK_REQ and receiving ACK. Thenode temporarily buffers a copy of the packet in themaintenance buffer, in case of retransmissions to the nexthop when necessary. If the node fails to receive an ACKfrom the next hop after the maximum-allowedretransmissions have been reached, it will assume that thenext hop is unreachable. The node handling the datapacket may be one of the following types:

† Source node: The data packet being handled is generatedby this node. The node IP address is the data packet’s sourceaddress.

† Intermediate node: The node is one of the intermediatehops contained in the address list in the data packet’s SRO.

If a node (denoted as ‘triggering node’) detects itsunreachable next-hop node using the above routemaintenance mechanism, it will first delete all source routescontaining the unreachable next-hop node from the routecache. Subsequently, the triggering node will perform anappropriate handoff solicitation trigger algorithm,respectively, depending on which type the triggering nodeis, source node or intermediate node. In fact, only thesource node can solicit for gateways. Intermediate node justaids the source node to make a solicitation decision bysending a special RERR.

If the source node eventually detects a route error whenforwarding a packet with a SRO towards an Internetdestination, and it fails to find other valid routes to itscurrent gateway, it may be triggered to solicit unicastadvertisements from gateways by invoking an external routediscovery towards the Internet destination.

5.4.2 Source node operations: If the triggering nodehandling the data packet is a source node type, it willoperate as follows:

† Access the address list field in the SRO of the data packet.Copy the value of the last hop in the address list to atemporary variable gw_addr.

† Check the first hop external flag and last hop external flagin the SRO of the data packet.

Next, the triggering node will check whether the followingconditions are satisfied:


IETdoi

www.ietdl.org

† The source route option in the data packet being handledby this triggering node has a last hop external flag (L). Thismeans that the data packet is generated by this triggeringnode, towards an Internet destination.

† The value in the temporary variable gw_addr matches thetriggering node’s current gateway address. This means thatthe broken source route contained in the data packet’s SROis through the triggering node’s current gateway.

If the above conditions are satisfied, the triggering nodewill operate as follows:

† Access the source routes towards its current gatewayaddress, i.e. gw_addr. If such routes do not exist in theroute cache, the triggering node will clear the route cache.Consequently, if this node still generates data packets tosend to the Internet destination, an external route discoverywill be invoked as a solicitation trigger, because no routesexist in the route cache. Clearing the route cache also helpsto remove all stale routes. The advertisements fromgateways will update fresh routes.

† Otherwise, if the source routes towards gw_addr exist, theexternal routes towards the Internet destination will be rebuiltusing the routes towards gw_addr.

A timing diagram of reactive gateway handoff co-operatedwith RERC is illustrated in Fig. 8. Once the external routediscovery is invoked, the triggering node broadcasts aRREQ towards the Internet destination to solicit unicastadvertisements from gateways. The triggering node willcollect the advertisements from gateways one by one, andupdate fresh routes to gateways. If the handoff toFA_New is confirmed, a registration request will be sentand registration reply will be received. Note that theexternal route discovery time (T4 2 T2) should be definedlonger than the gateway handoff latency (T3 2 T2), to


ensure that the initiator has selected an optimal gateway toregister with before forwarding packets to the Internetdestination.

5.4.3 Intermediate node operations: If the triggeringnode is an intermediate node type, e.g. node c in Fig. 9, it willoperate as follows:

† Try to salvage this packet by selecting another route to thefinal destination.

† Proceed with the handoff solicitation trigger algorithm.This may involve a special RERR creation algorithm, asshown in Fig. 10. The special RERR message will be usedto notify the source node of the undeliverable data packetthat a handoff solicitation may be required.

The packet format of the special RERR message is shown inFig. 11. Besides the standard fields, the special RERR messagecontains a new field, CN address. In addition, a new ErrorType: FA_HANDOFF is defined. The important fields inthe special RERR message are described as follows:

† Error type (Error_Type): this indicates the type of thisRERR. Currently, there are two values representing theError type, NODE_UNREACHABLE (1) andFA_HANDOFF (3).

† Error source address (Error_Source_Addr): address of thenode sending the RERR message, i.e. the node that hasdetected the route breakage.

† Error destination address (Error_Dest_Addr): address ofthe triggering node to which the RERR must be sent.

† Unreachable node address (Unreachable_Node_Addr):the next-hop address to which the data packet cannot betransmitted.

Figure 8 Timing diagram of RERC in reactive gateway handoff

757


758

& T

www.ietdl.org

Figure 9 Handoff trigger processing in reactive gateway handoff scheme

† CN address (CN_Addr): the Internet destination address,if this packet is destined to the Internet.

The condition of proceeding with creating special RERRmessage with Error Type of FA_HANDOFF is: the

he Institution of Engineering and Technology 2009

undeliverable data packet’s SRO has an (L) flag, and this nodeis an intermediate node type. This special RERR message isused to prompt the source node of the data packet (errordestination address) to solicit agent advertisements fromgateways and commence a reactive gateway handoff evaluation.

Figure 10 Special RERR creation algorithm


IETdoi

www.ietdl.org

The creation of the special RERR message is shown inFig. 10. The definitions of samples used to denote valuesof addresses inserted into these fields are as follows:

† source_addr: the source address in the packet’s IP header.

† dest_addr: the destination address in the packet’s IPheader.

† fa_addr: the gateway address of the source node. Thisaddress is copied from the source route option, if the SROhas external flag.

† local_addr: the local address of the node sending theRERR.

† next_hop_addr: the next hop address to which the packetcannot be sent.

The creation of special RERR message with error type ofFA_HANDOFF can be described as follows:

† The error type field is set to FA_HANDOFF.

† The CN_Addr field is set to the destination address of thedata packet being processed. This is used to notify the sourcenode of the data packet (the destination of the RERRmessage, i.e. Error_Dest_Addr) about the address (CN)that is unreachable.

On the other hand, if the error type isNODE_UNREACHABLE, the creation of the RERRmessage follows the DSR standard, except for the followingmodifications:

† If the packet is being delivered from the Internet tothe MANET, the destination of the RERR message(Error_Dest_Addr) should be the gateway through whichthe packet is forwarded, rather than the original sourcenode on the Internet as normal in DSR. The CN_Addrfield is set to blank.

† If the packet does not have any external flag (L or F), theCN_Addr field is set to blank.

Finally, the RERR packet will be forwarded to theprevious hop towards the Error_Dest_Addr.

5.4.4 Processing special RERR message: Asdescribed above, a special RERR message is originated byintermediate node (e.g. node c in Fig. 9). All nodes

Figure 11 DSR special RERR option


receiving the special RERR message will first delete allsource routes containing the broken link, i.e. error sourceaddress to unreachable node address. However, allintermediate nodes just process the special RERR messageas a normal RERR. Only the source node (error destinationaddress, e.g. node d in Fig. 9) of the SRO data packet canhandle the RERR that is of FA_HANDOFF type.

On receiving the special RERR message whose error typeis FA_HANDOFF, the source node will check whether theroutes towards its current gateway FA_Old are still availablein the route cache. If such routes are available, the sourcenode will rebuild external routes towards the CN addressobtained from the special RERR, using the routes towardsthe current gateway.

In case such routes are not available, the source node willclear the route cache to remove all stale routes. As a result,if the external route to the Internet destination has beenerased, and the source node still has data packets to sendtowards the Internet destination, a new RREQ targetingthe external destination will be launched. This isconsidered a solicitation trigger. Consequently, the sourcenode will start a reactive handoff evaluation.

5.5 Handoff evaluation mechanisms

As stated in Section 4.1.4, on receiving an advertisement,MIPRC will send handoff interrupt to MANET module.The handoff evaluation mechanism for selecting an optimalgateway is an added function within the MANET module,which should be designed widely adaptable to variousMANET routings underneath, for instance, using shorterpath hops or shorter packet delivery delay as selectioncriterion. In this work, DSR will perform the handoffevaluation algorithm as follows: if a valid route towardsFA_Old is not available, or, if the hop count to FA_Newis shorter than the one to FA_Old, a Handoff Trigger willbe sent to the MIPRC for sending a registration request toFA_New using cached advertisement information. Thehandoff evaluation algorithm is shown in Fig. 12. Only thehandoff trigger allows MIPRC to start handoffs.Consequently, a handoff phase is started by expecting aregistration reply, as described in MIPRC.

5.6 Optimisation considerations

Mobile IP may utilise the following optimisations:

† Handoff postponement: The unexpected delays of unicastadvertisement may result in unnecessary handoffs, as mobilenode may not receive the advertisement from the closestgateway first. Thus, the handoff postponement allows ashort period to evaluate all unicast advertisements fromavailable gateways before making the final handoff decision.

† Advertisement filter threshold: This is a minimum delaythreshold, in order to reject these extra long-delay

759


760

& T

www.ietdl.org

Figure 12 Handoff evaluation algorithm

advertisements, as the hop count towards the gateway maynot be effective criterion in this case.

† Advertisement unicast postponement: The unicastpostponement is defined for the gateway to unicast anadvertisement with a short delay upon receiving thesolicitation (RREQ). This is to avoid the collision ofunicast advertisement with the RREQ broadcast.

The priority algorithm for sorting multiple DSR routes inthe route cache is designed as follows:

† Among all routes towards the same destination, the routewith the fewest hops has the highest priority.

† Among all routes with the same hop count towards the samedestination, the latest updated route has the highest priority.

† The routes towards the current gateway have the samelifetime as the external routes flagged with (L). After asuccessful gateway handoff, the routes towards externaldestinations via the old gateway must be removed, andthese external routes must be rebuilt to use the new gateway.

6 Proactive gateway handoffmechanismA scheme of piggybacking routing information onbroadcasting advertisements, as well as utilising MIPRCfor proactive handoff evaluation is presented.

he Institution of Engineering and Technology 2009

6.1 Mobile IP signalling messagepropagation

To enable multi-hop propagations of advertisements, everyad hoc node must rebroadcast received advertisements. Ifrouting information is not piggybacked on theadvertisements, redundant route discoveries towardsgateways in the following registration procedure will occur.Thus, piggybacking routing information on broadcastadvertisements can decrease routing overhead and delaycaused by redundant route discoveries.

The standard DSR does not allow the rebroadcasting ofdata packets other than the RREQ. In order to enablerebroadcasting of an agent advertisement, a new packetformat, DSR broadcasting advertisement (Fig. 13), iscreated. First, the mobile IP module on the gatewaygenerates a standard agent advertisement packet, andtransfers this packet to DSR. The DSR header (Fig. 14)follows the IP header of the advertisement packet, asshown in Figs. 13 and 15. The Option Type field is filledup with ‘Advertisement’; the identification field is filled upwith the same value copied from the Identification field inthe advertisement extension. The Destination field in theIP header remains unchanged (255.255.255.255); the TTLin the IP header is set to the network dimension.Subsequently, this advertisement packet is broadcast via allinterfaces. On receiving the advertisement, a node willfollow advertisement ID checking algorithm using anadvertisement forwarding table to drop duplicate


IETdo

www.ietdl.org

Advertisements. The algorithm of processing source routinginformation follows the DSR protocol specifications. Finally,an advertisement extension packet will be passed to theMIPRC for further processing, and a copy of the packetwill be rebroadcast again.

6.2 Handoff trigger

There are three options for the proactive handoff evaluationtrigger on receiving multiple periodic advertisements, asfollows:

† Compare all advertisements synchronously. This is notlikely to happen as gateways may not synchronouslyadvertise and even the same advertisement cannot bereceived by all mobile nodes synchronously because of themulti-hop relay latency.

† Compare advertisements after predefined listening period.As the gateways do not advertise synchronously, the listeningperiod can be very long, and the routing information variesduring the listening period. Thus, a mobile node may usestale routing information to make handoff decision.Therefore this option is vulnerable to changes of topologyand will not be adopted.

† Compare individually received periodic advertisementswith the current gateway address. This is a promisingchoice, which overcomes the drawbacks of the above twooptions. This option will be adopted here. The handoffevaluation algorithm is the same as in Section 5.5 andAlgorithm 1. After several consecutive handoffs, the mobilenode can associate itself with the closest gateway among allavailable gateways.

Figure 13 DSR broadcast advertisement packet format

Figure 14 DSR header

Commun., 2009, Vol. 3, Iss. 5, pp. 752–763i: 10.1049/iet-com.2008.0275

7 Simulation results7.1 Scenario

The simulation model is created using OPNET Modelerv10.5. An ultimate reason of requiring multiple gatewayhandoffs is that a mobile node needs better service from anoptimal gateway, to communicate with the Internet.Because of the handoffs among multiple gateways in theMANET, the packets from a source node may go throughdifferent gateways to arrive at the final destination on theInternet. Thus, the objective is to justify the efficiency ofthe multiple gateway handoffs by evaluating the end-to-endperformance between the MN and the Internet againstdifferent numbers of gateways. The performance metricsinclude the end-to-end delay, packet delivery ratio, mobile IProuting overhead and DSR routing overhead.

The MANET is deployed in a square area of2000 m � 2000 m; 100 ad hoc nodes are initially deployedevenly on a grid with 200 m � 200 m spacing. Only onemobile node moves at 15 m s21; other 99 nodes are static. Asegment-based trajectory is used, which defines the mobilenode’s movement using two-dimensional co-ordinates and

Figure 15 DSR advertisement option

Table 1 DSR common parameters

Parameters Value

Route expiry time, s 300

Sending buffer expiry time, s 30

Maximum request table size, nodes 64

Maximum route cache size, routes 400

Maximum request retransmissions 0

Maximum request period, s 0.2

Request holdoff time, s 0.22

Gratuitous route reply timer, s 1

Maximum maintenance buffer size, packets 50

Maintenance holdoff time, s 0.25

Maximum maintenance retransmissions 2

Maintenance acknowledgement timer, s 0.12

Cached reply disabled

Salvaging enabled

One-hop-propagating RREQ disabled

761


762

&

www.ietdl.org

traversal-time values. The segments include locations randomlyand widely spread over the simulated region. The advantage ofusing trajectory is that an accurate control and repeatability ofthe moving pattern across different simulation runs can beguaranteed. This is to ensure the simulation results are merelydifferent because of the schemes, but not because of theunpredictable factors. The mobile node maintains a peer-to-peer custom application utilising REQ/NO-RESP with

Table 2 Mobile IP common parameters

Parameters Value

Registration retry interval, s 1

Registration retry times 5

Lifetime granted, s 1800

Max supporting hosts 400

Advertisement unicast postponement, s 0.015

Handoff postponement, s 0.03

Advertisement filter threshold, s 0.2


Internet CN. The REQ packet size is 64 bytes; the packetsending rate is 20 packet/s. The simulation time is 1 h.Tables 1 and 2 show the common parameters of protocols.The varying advertising intervals used for proactive gatewayhandoff scenario are: 5 s, 20 s, 40 s. The 802.11 MAC layer ismodified to support BSS/IBSS hybrid mode; the data rate is11 Mb; the transmission range is around 300 m. Thesimulation performance is evaluated against various numbersof FAs (1–4). For all simulation experiments, RERC is usedfor external route discovery with the external route discoverytime parameter set to a fixed value, 220 ms, as this parametershould be larger than the maximum round trip time of theRREQ/RREP cycle across the MANET area.

7.2 Results

The simulation results are shown in Fig. 16. Under the proactivegateway handoff, more frequent advertising allows the mobilenode to maintain shorter paths towards its registered gateway,which ensures better end-to-end delay (Fig. 16a) and PDRs(Fig. 16b). It is obvious that the mobile IP overhead(Fig. 16d ) is the dominating overhead. The majorities ofDSR overhead are SRO packets. As SRO packet overhead is

Figure 16 Simulation results

a Average end-to-end delayb Packet delivery ratioc DSR overheadd Mobile IP overhead


IETdo

www.ietdl.org

proportional to the total path hops that all SRO packets travelthrough in the MANET, the less frequent advertising leadsto more DSR overhead (Fig. 16c) because of longer pathsestablished between the mobile node and its gateway.

With more number of serving gateways, the mobile nodeachieves more opportunities of dynamically executinggateway handoffs to select closer gateway. Hence, the end-to-end delay (Fig. 16a) and DSR overhead (Fig. 16c) canbe both decreased because of shorter paths available. Ifthere is no gateway handoffs, i.e. only one gateway, theend-to-end delay (Fig. 16a) and PDRs (Fig. 16b) are worsethan other cases of activating multiple gateways. Thisproves that dynamic gateway handoffs can efficientlyimprove end-to-end performance. Obviously, mobile IPoverhead significantly increases because of the increasingnumber of gateways, which may impact on the PDRsunder proactive gateway handoff (Fig. 16b).

The reactive gateway handoff generally outperforms theProactive-40 s scenario, but does not surpass the Proactive-5 s and Proactive-20 s scenarios, except for the significantlylow mobile IP overhead (Fig. 16d). This is becausein proactive gateway handoff, the mobile node canmaintain the connectivity with its current gateway whilesimultaneously evaluating and performing handoff to a newgateway. With shorter advertising intervals, the mobilenode may have more chances to update shorter paths.Certainly, the very high mobile IP overhead is a huge cost.On the contrary, the reactive gateway handoff can offersatisfactory end-to-end delay (Fig. 16a) at a significantlylow overhead cost. In a multiple-gateway environment, thereactive gateway handoff approach is particularlyadvantageous, as the increasing overhead caused byadditional gateways is not significant. This proves thatreactive gateway handoff is a feasible and efficient scheme.

8 ConclusionsA design for adaptive mobile IP handoffs among multiplegateways in the MANET is presented. Executing gatewayhandoffs is of great significance to reducing the end-to-enddelay, as a mobile node can always be connected with theclosest gateway. However, with multiple gateways, the highmobile IP overhead is a serious disadvantage in proactivegateway handoff. Thus, the proposed reactive gatewayhandoff scheme is more appropriate for use in resource-limited ad hoc networks with multiple gateways. Thereactive gateway handoff scheme may exhibit satisfactoryend-to-end delay with significantly low mobile IPoverhead. In summary, the reactive gateway handoff is apromising scheme worth more attention in the future.

9 AcknowledgmentsThe author thanks the ITR at UniSA to provide OPNETModeler software for education use. The author also

Commun., 2009, Vol. 3, Iss. 5, pp. 752–763i: 10.1049/iet-com.2008.0275

gratefully thanks Associate Professor Arek Dadej and Dr.Steven Gordon for helpful comments in research.

10 References

[1] FRATTASI S., FATHI H., FITZEK F., PRASAD R., KATZ M.: ‘Defining 4Gtechnology from the users perspective’, IEEE Network,2006, 20, pp. 35–41

[2] PERKINS C.E.: ‘IP mobility support’. RFC2002, IETF,October 1996

[3] PERKINS C.E.: ‘Mobile IP: design principles and practices,Addison-Wesley wireless communications series’ (Addison-Wesley, Reading, MA, 1998)

[4] TSENG Y.-C., SHEN C.-C., CHEN W.-T.: ‘Integrating mobile IPwith ad hoc networks’, Computer, 2003, 36, (5), pp. 48–55

[5] ERGEN M., PURI A.: ‘Mewlana-mobile IP enrichedwireless local area network architecture’. Proc. 56th IEEEVehicular Technol. Conf. (VTC 2002-Fall), 2002, vol. 4,pp. 2449–2453

[6] JONSSON U., ALRIKSSON F., LARSSON T., JOHANSSON P., MAGUIRE G.Q.J.:‘MIPMANET-mobile IP for mobile ad hoc networks’. FirstAnnual workshop on Mobile and Ad Hoc Networking andComputing, 2000 (MobiHOC. 2000), 2000, pp. 75–85

[7] SUN Y., ROYER E., PERKINS C.E.: ‘Internet connectivity for adhoc mobile networks’, Int. J. Wirel. Infor. Netw. special issueon MANETs: Standards, Research, Applications, 2002, 9, (2),pp. 75–88

[8] SHIN J., NA J., LEE H., PARK A., KIM S.: ‘Mobile IP support in adhoc networks with wireless backbone’. Proc. 59th IEEVehicular Technol. Conf., 2004 (VTC 2004-Spring),vol. 4, 2004, pp. 2136–2139

[9] BENZAID M., MINET P., AGHA K., ET AL.: ‘Integration of Mobile-IPand OLSR for a universal mobility’, Wirel. Netw., 2004, 10,pp. 377–388

[10] HOANG V., SHAO Z., FUJISE M., NGUYEN H.: ‘A novel solution forglobal connectivity in MANET’. Proc. 60th IEEE VehicularTechnol. Conf. 2004 (VTC 2004-Fall), vol. 4, 2004,pp. 2819–2823

[11] WAKIKAWA R., MALINEN J.T., PERKINS C.E., NILSSON A., TUOMINEN

A.J.: ‘Global connectivity for IPv6 mobile ad hoc networks’.Internet Draft, IETF, March 2006, http://www.ietf.org

[12] JOHNSON D., HU Y.C., MALTZ D.: ‘The dynamic source routingprotocol (DSR) for mobile ad hoc networks for IPv4’. RFC4728, IETF, February 2007, http://www.ietf.org

[13] Mobile IP Model: Program Documentation, OPNET,October 2005

763


Documents

04912231