Telecommun Syst (2013) 52:1021–1031DOI 10.1007/s11235-011-9609-y

Dynamic host configuration protocol for IPv6 improvementsfor mobile nodes

Tomasz Mrugalski · Jozef Wozniak · Krzysztof Nowicki

Published online: 6 October 2011© The Author(s) 2011. This article is published with open access at Springerlink.com

Abstract In wireless networks mobile clients change theirphysical location, which results in changing point of attach-ment to the network. Such handovers introduce unwantedperiods, when node does not have communication capabil-ities. Depending on many conditions, such events may re-quire reconfiguration of layer 2 (e.g. IEEE 802.16) or both2 and 3 layers (IPv6). This paper investigates delays intro-duced in the latter type of handover. IPv6 protocol fam-ily supports two automatic configuration modes: stateless(SLAAC) and stateful (DHCPv6). Both modes may be usedin wireless networks. Once the L2 handover procedure iscompleted, the mobile node (MN) starts its IPv6 config-uration process, using stateless (router advertisements) orstateful (DHCPv6) mode. When care-of address (CoA) isassigned, its uniqueness has to be verified, using Dupli-cate Address Detection (DAD) procedure. Depending ona network type, this procedure may even take more than1000 ms. The obtained CoA can be used only when con-figuration and DAD procedures are completed for inform-ing corresponding nodes about new MN location. Such de-lay introduces unacceptable gaps in communication capa-bility. This paper proposes several new mechanisms that en-able faster IPv6 reconfiguration. First proposal allow MNto obtain its IPv6 address and other configuration optionsin advance, before completing actual handover. Such a pri-ori knowledge about configuration available at destination

T. Mrugalski (�) · J. Wozniak · K. NowickiGdansk University of Technology, ul. Narutowicza 11/12, 80-233Gdansk, Polande-mail: tomasz.mrugalski@eti.pg.gda.pl

J. Wozniake-mail: jowoz@eti.pg.gda.pl

K. Nowickie-mail: know@eti.pg.gda.pl

locations may be exploited to speed up configuration pro-cess itself and also allow initiating Mobile IPv6 operationsearlier, thus further shortening delays. Another proposal in-cludes new way of delivering routing information to MN,using DHCPv6. Mechanism itself and its verification tech-niques are discussed. Results of extensive simulations, sta-tistical analysis as well as areas of further study concludethis paper.

Keywords Autoconfiguration · DHCPv6 · DAD · MobileIPv6 · Remote autoconfiguration · Routing · WiMAX

1 Introduction

With wireless technologies reaching their maturity, moreusers are expected to use mobile devices. At the same time,the growing speed of data transfers, offered by wireless net-works causes that multimedia applications, like VoD (Videoon Demand) or VoIP (Voice over IP), are becoming increas-ingly popular among mobile users. Wireless devices requireservice continuity even when they move between points ofattachment. Thus the handover performance becomes a cru-cial factor for multimedia services support. These types ofservices are very sensitive to the channel disruption, han-dover delays or packet losses. All these factors can signifi-cantly lower the quality of multimedia services. Due to this,it is not possible to support multimedia without fast enoughand transparent handover procedures.

However, from the network point of view, two require-ments—delivery of large amounts of data and provision ofmobility—are very hard to be achieved at the same time.That is because changing a point of attachment to the net-work by a mobile station is usually complicated.

1022 T. Mrugalski et al.

Even though discussed problems are applicable to mostwireless networks supporting inter-domain handovers, au-thors choose IEEE 802.16 networks (WiMAX, [5]) as a suit-able research area, with the intent to attempt generalizationto other networks. Different network layers will producedramatically different delays during handover. The PHY andMAC layers of the WiMAX stack have been developed withmobility support and fast processing in mind. Therefore de-lays introduced are considered small (reaching a few hun-dred milliseconds range, usually slightly above 100 ms).Unfortunately, IPv6 protocols family was not designed inthis manner. Several steps necessary to be performed bymobile nodes, while changing the network domain, intro-duce delays that are very large from the mobility point ofview (in the order of one second or more). For example, theDHCPv6 server discovery phase takes exactly one secondas clients are required to wait for possible responses fromother servers, even when one or more servers have alreadyresponded (according to DHCPv6 specification [4]).

2 Problem statement

It is essential to realize that not all handover steps arecausing handover delays. From the user’s perspective, onlylack of communication capability periods are troublesome.Therefore all efforts presented in this paper are focused onminimizing or even eliminating such periods completely.IPv6 reconfiguration process during handovers in wirelessnetworks in general and IEEE 802.16 networks in partic-ular, is not optimal and it is possible to achieve improvedhandover efficiency by performing remote DHCPv6, DADand Mobile IPv6 protocol modifications. To measure impactof diverse algorithms in a uniform way, a new metric hasbeen defined for assessment purposes.

Inter-domain handover in IPv6/WiMAX networks is timeconsuming and complicated process. During certain steps,like scanning or IPv6 autoconfiguration, a subscriber stationis unable to maintain communication. To conveniently as-sess and compare radically different handover phases, met-ric called Handover Delay is proposed. It is expressed in mil-liseconds and specifies how long mobile IPv6 station doesnot have full communication capability due to the analyzedmethod. X expresses metric value, while HD() stands for itssymbolic designation:

X = HD(step) (ms)

In general, lower scored methods are considered “better”,because they introduce smaller latency. If a method allowsIPv6 node to communicate immediately, with no delay at all,its HD value is equal to 0 ms, thus it does not hinder commu-nication in any way, so—assuming no other dependencies—it does not require any optimizations or improvements. Han-

dover Latency would be a better term to describe this prop-erty as during handover packets (or traffic in general) are notdelayed. However, this metric is more often referred to usingits colloquial name—Handover Delay [15].

3 Previous work

Inter-domain handover optimization is an area of very ac-tive studies. One area of particular importance are activitiesarranged around IETF. Due to work fragmentation and var-ied approaches, there are many IETF working groups (WG)that are dedicated to solve various aspects of handover andmobility in general. Notable WGs are: mip4 (dedicated toMobile IPv4 protocol development), mip6 (concluded; ded-icated to Mobile IPv6 specification), mipshop (Mobile IPPerformance, Signaling and Handoff Optimization, focusedon Fast Handovers and Hierarchical extensions to MobileIPv6), dna (Detecting Network Attachment; created to de-velop mechanisms that reduce or avoid delays associatedwith RA and DAD mechanisms), mext (Mobility Extensionsfor IPv6, like Network Mobility or IKEv2 usage). The mostwidely accepted extensions to Mobile IPv6 protocol are Hi-erarchical Mobile IPv6 (hmipv6) [18] and Fast Handoversfor Mobile IPv6 (fmipv6) [6].

Fast Handovers for Mobile IPv6 [6], released in July2009, is a set of procedures dedicated to improve handoverlatency. Previous Access Router (PAR) and New AccessRouter (NAR) are introduced. Using Proxy Router Adver-tisements (PrRA), it is possible that MN learns prefixesavailable at potential destination locations. MN communi-cated with routers PAR and NAR using Fast Binding Update(FBU) and Fast Binding Acknowledge (FBA) messages. Byusing Handover Indication (HI) and Handover Acknowledge(HA), PAR and NAR can coordinate traffic buffering andforwarding. Signaling for handover completion is also intro-duced. Two modes of operation are introduced: predictiveand reactive. Large number of new messages requires sig-nificant modification of the protocol implementations. Also,the need to deploy mobility aware routers that in some casesneed to buffer incoming traffic are cause of significant scal-ability and deployment concerns. Also, MN may obtain ad-dress for destination location using PrRA that must be con-firmed using another message. This approach violates cleardistinction between stateless and stateful autoconfigurationmodes.

Second important work is HMIPv6 standard [18]. Mobil-ity Anchor Point (MAP), a central router handling all traf-fic to and from a domain, is defined. MN arriving at newdomain, registers MAP’s address (called Regional Care-ofAddress, RCoA) to its HA, but also registers its locally ob-tained address (Local Care-of Address, LCoA) to MAP. Byproviding two levels of indirection, user traffic needs to be

Dynamic host configuration protocol for IPv6 improvements for mobile nodes 1023

processed by MAP (which serves as a HA-MAP tunnel ter-mination point). This two level registration allows signifi-cant optimization, however. Mobility within a domain can bereported to MAP. As it is in the same domain, RTT times aremuch shorter, so expected handover delay is much shorter.

Other interesting proposals in related areas are OptimisticDAD [10] that leverages the assumption that address dupli-cates are extremely unlikely. Using modified ICMP Redirectmessages, newly obtained addresses may be used immedi-ately, before DAD procedure completes. Scope of usage ofaddresses used in this mode has certain restrictions, how-ever.

Another important development in the area of mobil-ity are Media Independent Handover services, published asIEEE 802.21 specification [1]. It introduces set of functionsand notifications that different layers of protocols stack mayuse to gather and provide information regarding handoverstate to other layers. Event, Command and Information ser-vices are defined. By leveraging such information, it is pos-sible to leverage existing indicators to optimize certain han-dover procedures, e.g. prepare for imminent handover dueto degrading signal quality.

4 Remote autoconfiguration using DHCPv6

During normal handover procedure, data link layer (e.g.802.16) initiates and performs handover procedure. Thisphase is often referred to as L2 handover. After such pro-cedure is completed, network layer (e.g. IPv6) handover isperformed. Doing so, delays introduced by each layer areadding up, resulting in a large overall delay. Using data gath-ered by IEEE 802.16, subscriber knows its target location,before actual handover occurs. This prior knowledge maybe exploited to initiate connection with a DHCPv6 server,located at the destination network. As all base stations areconnected to the Core Network (CN), it is possible to makeconnection between base stations using CN. To initiate andmaintain such communication, already existing DHCPv6 re-lays may be used, albeit in a modified form. In a classicalconfiguration, relays work as intermediaries between clientsand servers. From the client’s perspective, direct communi-cation with a server or via relays is indistinguishable. Re-lays act as representatives of the server. From the server’sperspective client is connected to the remote link. By modi-fying relay’s behavior, it is possible to use relays to forwarddata from a client to a server and vice versa. In this sce-nario, the client is aware of the relays. It sends messagesto relays and expects them to be forwarded to the remoteserver. Thus relays act as representative of the client. Fromthe server’s perspective, client is connected directly to the lo-cal link. To achieve such operation, relays and servers must

Fig. 1 Remote autoconfiguration of the mobile IPv6 nodes. MobileNode communicates with its target location, while still maintaining fullconnectivity at the old location. Communication is achieved via CoreNetwork

support this new mode. It is client’s responsibility to de-fine, which destination server it would like send DHCPv6requests to.

Client should include extra option to indicate, whichserver it would like connect to. This information will be usedby relays to forward messages to final destination. Knowl-edge about destination location identifiers is provided byWiMAX layers. “BS ID” obtained during scanning and/orL2 handover preparation is a functional equivalent of theMAC address. DHCPv6 server unique identifier (see [4]) oftype DUID-LL (DHCPv6 Unique Identifier, based on linkaddress) can be generated from such information. It is upto the relay to find actual location of the destination server.Overview of this improvement is depicted on Fig. 1.

This approach allows mobile node to communicate withtarget location before actually changing point of attachmentto the network. This ability can be used to remotely ob-tain all required configuration parameters, including IPv6address. Such a priori knowledge about target location canbe used in several ways. All parameters may be used imme-diately after reaching new location. Also those parametersmay be used to perform some additional steps, e.g. notifycorresponding nodes about new address. Proper target basestation selection may prove to be difficult. During scanning,parameters of available neighbor base stations are detectedand the best one is chosen. That base station’s ID is sent tocurrent base station as a best candidate for handover. How-ever, due to configuration or other conditions, serving basestation may forbid handover to that potential target base sta-tion and force subscriber to use another destination. Thisrenders the data gathered in scanning phase obsolete. Suchscenario is unlikely, but possible. There are 3 possible ap-proaches to deal with that problem:

(1) Cooperative—To initiate handover, Subscriber Stationsends list of desired target Base Stations. Assuming

1024 T. Mrugalski et al.

Base Station cooperation, Subscriber will receive per-mission to execute handover to desired location. In suchcase, remote DHCPv6 autoconfiguration can be initiatedbefore actual handover procedure is initiated.

(2) Conservative—This approach may be considered worstcase scenario. Subscriber station assumes that base sta-tion will not allow handover to proposed target location,but rather force subscriber station to use different desti-nation. Subscriber station can initiate remote autocon-figuration after BSHO-RSP (IEEE 802.16 message—Base Station initiated Handover Response) message isreceived from base station. This causes subscriber sta-tion to wait for base station response before actual IPv6preparation can take place.

(3) Hybrid—Once scanning is complete, subscriber stationhas list of possible destination targets. Instead of initiat-ing remote IPv6 configuration for the best target, it startsremote configuration process for all targets, before trig-gering actual handover. If base station denies requestto move to a specified target and provides other loca-tion as destination, subscriber station may already havecompleted configuration retrieval for that location. Sub-scriber station may then continue with handover processand discard configuration for remaining, not used loca-tions. Theoretically, it is possible that base station mayprovide destination target that was not previously dis-covered during scanning procedure, but such behavioris highly unlikely. It would force subscriber station toperform handover to a base station that it was unable tolisten to.

As conservative approach is considered the worst case sce-nario, it was selected for validation during simulation andmodeling.

4.1 Network layer independency

Other approaches should be considered as areas for possi-ble further improvements. Proposed method in its currentform requires WiMAX as a network layer. This functional-ity can be easily broadened to other network types, however.It is possible to generalize this mechanism to any networks,but extra mechanism for neighbor discovery is required. MNwants to obtain knowledge about potential handover targetsand configuration available at each location.

The most convenient way to obtain such knowledge isto discover and contact neighboring DHCPv6 servers. Dur-ing initial configuration at current location, MN sends So-licit messages that contain Option Request Option (ORO)with its content specifying options that client would like tohave configured. Besides usual options, client also expressesthe intent to obtain OPTION_NEIGHBORS option. Serverthat supports this proposed enhancement will include OP-TION_NEIGHBORS in its response. Server must not send

Fig. 2 Proposed format of the Neighbors DHCPv6 Option. This op-tion could be used to announce possible handover targets, thus elimi-nating the need to provide this information by network layer

OPTION_NEIGHBORS option to the MN, unless MN ex-plicitly asks for it, using ORO. Proposed format of that op-tion is presented in Fig. 2. It should be noted that such ap-proach to discovery process is backward compatible. Clientsthat do not support this enhancement will simply not askfor new option. On the other hand, servers that do not sup-port this enhancement and are being asked by clients to sendOPTION_NEIGHBORS, will simply ignore the request forunknown option, but will process remaining options nor-mally.

Once knowledge about remote DHCPv6 servers isknown, MN may initiate remote autoconfiguration for se-lected neighboring locations. After choosing one or moresuitable targets, MN sends unicast Solicit message to thedestination server’s address. To notify server that this mes-sage is used with intent of remote auto configuration, clientshould include OPTION_REMOTE_AUTOCONF option.Server responds normally, using Advertise message. Onceclient receives responses from all remote servers, knowl-edge about offered parameters at potential destination loca-tions is gained. This information may influence selection ofthe final target location. Client asks for address and param-eters using Request message, again sent to remote server’sunicast address. OPTION_REMOTE_AUTOCONF optionis also used in the message to indicate that remote modeof operation continues. Server responds with Reply mes-sage. Once client receives this message, its remote con-figuration concludes. Client now possesses all configura-tion parameters to be used once handover to destination lo-cation is complete. Details of this proposal are discussedin [13].

Dynamic host configuration protocol for IPv6 improvements for mobile nodes 1025

5 DHCPv6 routing configuration

Hosts located in a network configure their routing tables us-ing Router Advertisement (RA) mechanism from NeighorDiscovery protocol [20]. It assumes that routers periodicallytransmit RA messages that are processed by hosts. Alter-natively, hosts can explicitly request such announcementsby sending Router Solicitation (RS) message. There arelimits on maximum frequency of RA transmissions, how-ever. In densely populated network, such limit of 3 sec-onds (MIN_DELAY_BETWEEN_RAS constant) could bereached easily. Moreover, properly conducted autoconfigu-ration assumes that host will not initiate DHCPv6 configu-ration, until RA is received. This results in added delays. Assuch, it seems reasonable to conduct routing configurationusing other means, like DHCPv6.

RA mechanism for configuring routing is affected bynumber of limitations that affect other use cases, even thosenot related to mobility. The primary concern is that it is notpossible to differentiate between hosts in a network. A sim-ple example is a corporate network that has two routers—one for Internet connectivity and the other for remote site.Most hosts are using only default router. However, selectedclass of users is also using dedicated router for connectionswith remote site. It is not possible to configure routing forsuch scenario. Another limitation is the inability to moni-tor routing configuration by network operators. Hosts do notsend confirmations of any kind, so there is no way to confirmthat RA was indeed received. Route selection is also primaryconcern in multi-homing environments, where hosts receivemultiple RAs over multiple interfaces. Default router selec-tion problem is being analyzed by MIF working group ofIETF.

To solve aforementioned problems, authors propose newmechanism for routing configuration using DHCPv6. Clientsends IA_RT option in its Solicit and Request messages.Server responds with Reply message containing IA_RT op-tion, populated with one or more OPTION_NEXT_HOPoptions. Each such option represents a single router avail-able in the network. For each OPTION_NEXT_HOP option,there may be one or more OPTION_RT_PREFIX. Each sub-option defines dedicated prefix that is available via specifiednext hop. Proposed solution is designed as a minimal frame-work for conveying routing information. Its hierarchical ap-proach simplifies future extensions for delivering other rout-ing parameters, like MTU, prefix lifetimes and others. De-tails of this proposal are discussed in [3]. This proposal waspresented during several IETF meetings and gained favor-able reviews. It was decided to have it adopted as a MIFwork group item.

6 Validation

To support validity of new proposals, it is a common practiceto create theoretical models of proposed methods. By study-ing their properties, conclusions about modeled mechanismcan be deducted. Unfortunately, construction of analyticalmodel is only possible for simpler systems. Therefore it isoften not feasible to propose reliable model for more com-plex systems, like multi-subscriber 802.16 networks withadvanced IPv6 mechanisms. Commonly accepted approachto mechanism validation is to design and implement a sim-ulation. By running a simulation, various parameters andproperties of the simulated proposal can be measured. Byanalyzing simulation result, one can draw conclusions aboutproperties of the simulated system. It is essential to prop-erly process obtained results as simulation environment andmethods may introduce unwanted artifacts and errors to ob-served values.

6.1 Simulation environment

To verify correctness and evaluate efficiency of proposedmechanisms, simulator of affected systems was developed.OMNeT++ [22] was selected as the environment suitablefor that purpose. OMNeT++ is a component-based, modu-lar and open-architecture discrete event network simulator.It allows construction of arbitrary complex networks of in-terconnected modules. This environment was chosen, due tofollowing reasons:

• Open source—source code is available for use and mod-ification. This critical requirement allows modification ofany part of the code.

• Written in C++—Simulation speed is essential in compli-cated systems. The scalability of system coded in fast lan-guages (C,C++) are better, compared to slower languages(Java, tcl, perl, etc.)

• Extensive documentation—Detailed User’s Guide [22] isavailable, accompanied by extensive set of examples andtutorials.

• Free—It is free of charge for personal and academic pur-poses. OMNeT++ is distributed under Academic PublicLicense.

• Portable—OMNeT++ simulation engine runs on Linux,numerous UNIX systems and even Windows. Such broadcoverage allows better scalability. Should home PC proveto be not powerful enough to complete calculations, sim-ulation may be run on university cluster. Although simu-lation efficiency never exceeded modern home PC’s capa-bilities, possibility to use more powerful systems was notruled out before implementation was complete.

• Distributed—OMNeT++ support computation in dis-tributed environment, further increasing scalability.

1026 T. Mrugalski et al.

Table 1 Experiments summary.Most important parameters foreach experiment are presented

Experiment 1 2 3 4

# of subscribers 20 7 20 5

Simulation time (s) 60 67 1801 4800

Traffic model bursty bursty bursty bulk

Packet interval (ms) 12 12 12 11.1

Burst size 3 3 3 1

Packet sizes (min–max) 48–512 48–512 48–512 48–1500

Mobility model time trigger time trigger random random

time trigger time trigger

• Scalable—Simple modules may be connected togetherto form larger, more complex compound modules. Thisleads to an effective hermetization. As a direct effect, onemodule may be modified, without any changes to remain-ing blocks.

Neither OMNeT++, nor any of its available libraries, didnot provide support for 802.16 networks simulation, whenauthor began their research. It offers experimental supportfor IPv6 and Mobile IPv6, but this support relies on precise,but complicated and slow INET framework [21]. Thereforenew environment was developed for the purpose of mo-bile IPv6 stations simulation in the IEEE 802.16 environ-ment. This project was started in 2005 under the name Num-bat [12]. Numbat provides means for simulation of 802.16stations with advanced IPv6 stack on top.

6.2 Traffic models

The main areas of concerns are multimedia applications asthey are the most sensitive type of traffic. Therefore mostmodels are related to multimedia streaming or multimediarelated purposes. Out of wide variety of available options,following models were implemented (the most importantparameters for experiments are presented in Table 1):

• Bursty traffic—This traffic model is dedicated to gener-ation of traffic that is variable in time. Once every tIinterval, bn packets are sent. Packets have random sizefrom Lmin to Lmax. The size of packet is a truncatednormal distribution, with Lavg = (Lmin + Lmax)/2 andstandard deviation μ = 0.8 ∗ (Lavg − Lmin). Lmin = 48[bytes] was selected as lower bound as this is the small-est possible IPv6 packet with useful payload—an emptyUDP packet. Example values used in some scenarios aretI = 12 ms, bn = 3 and Lmax = 512 [bytes]. This type oftraffic may be used to simulate VoIP connections, wherecertain amount of data is created in regular intervals;

• Bulk traffic—This type of traffic is intended to reflect bulkdata transmission, e.g. FTP session or MPEG-2 or H.264video streaming. It is expected that packet sizes will usu-ally be close to maximum. Smaller packets will also be

recorded, albeit on a much smaller scale. Once every tIinterval, packet of size L is being sent. There are severaldistributions that allow modeling such conditions. Betadistribution was chosen as most suitable. It is defined as:

f (x;α,β) = �(α + β)

�(α)�(β)xα−1(1 − x)β−1

where � is defined as:

�(z) =∫ ∞

0tz−1e−t dt

Details regarding traffic models are available in [11] or [16].

6.3 Random number generators

Computer is a finite state machine and its next state is fullydetermined by the previous one. Although true randomnessis impossible, number of algorithms has been developed togenerate stream of numbers that appear to be random. Asthey are not truly random, such class is often referred to aspseudo random number generators (PRNG). Although se-quences that are closer to truly random can be generatedusing hardware random number generators, its use is lim-ited by availability of required dedicated hardware. Depend-ing on the expected area of application, there are severalproperties of a PRNG that should be taken into considera-tion:

• Period. That is considered the most important parameter.All PRNGs generate series of values. Such series are notinfinite, but rather repeat themselves. Every time a num-ber is generated, PRNG changes its internal state. Periodspecifies how many numbers are generated before PRNGreturns to its initial state.

• Weak seeds. Initial state of the PRNG is defined by a smallset of data called seed. Some PRNGs exhibit very limitedcapabilities for certain seeds (e.g. Middle-Square Methodgenerates only zeros, when 0000 is used as seed.). Ex-istence of weak seeds is considered a serious aw for aPRNG, especially from cryptographic perspective.

Dynamic host configuration protocol for IPv6 improvements for mobile nodes 1027

Fig. 3 Standard deviation of uplink traffic observations. It is used for determining initial simulation warm-up time. After stabilization (aroundlog(n) = 2.86, marked with vertical dashed line), standard deviation begins steady decrease with increasing number of samples (n)

• Computational Complexity. Some PRNGs require longercomputation for next number generation. That parameteris especially important when large quantities of pseudo-random numbers are required. That is particularly truewith long lasting simulations.

• Memory requirements. As most other algorithms do, alsoPRNGs require memory to store its internal state. Asmodern computers have significant amount of memoryavailable, this property is rarely an issue.

• Warm-up period. Each PRNG requires initial value calledseed that defines initial state. Initially generated se-quences of numbers sometimes lack required statisticalproperties and thus fail random quality tests [7, 8]. SomePRNGs begin to generate high quality number sequencesfaster than others. Such PRNG are said to be gettingstarted quicker. Such PRNGs are considered more use-ful.

Mersenne Twister PRNG [9] was found to be suitable andwas used in all simulations.

6.4 Simulation warm-up period

The proper determination of simulation warm-up time is oneof crucial steps for ensuring simulation credibility. Thereare numerous methods for choosing length of the warm-uptime. Following approach, originally proposed in [19] wasadopted and modified. Let there be a sequence of n indepen-dent and identically distributed random variables X1::Xn,

each having finite values of expected value μ and varianceσ 2 > 0. Central limit theorem [2] states that with increas-ing n, the distribution of the sample average of these ran-dom variables approaches normal distribution with a meanμ and variance σ 2 = n irrespective of the shape of originaldistribution. Following linear equation can be obtained:

log s = −0.5 logn + logσ

Therefore, if the simulation approaches steady state, thestandard deviation of samples plotted against log(n) shouldbegin steady decrease. Rate of that decrease should be tan-gential to line with −0.5 slope. This point defines end of thewarm-up period and is often referred to as cut-off point. Iffluctuations in samples are high, it may be difficult to spotcurve’s trend. Therefore moving average algorithm was usedto smooth out high frequency fluctuations. For each sample,number of previous and following values was averaged. Themoving average of length 2k + 1 is as follows:

xn ={

(2k + 1)−1 ∑n+ki=n−k xi if n ≥ k + 1

(2k − 1)−1 ∑2n−1i=1 xi if n < k + 1

Example of such analysis for uplink traffic is presented inFig. 3. Reader interested in more detailed explanation is en-couraged to read [11].

1028 T. Mrugalski et al.

Table 2 Results summary.Averaged results from allexperiments. Values arespecified in seconds

Parameter Scn1 Scn2 Scn3 Scn4 Scn5 Scn6 Scn7 Scn8 Scn9 Scn10

HO Preparation 0,101 0,101 0,103 0,101 0,103 0,103 0,101 0,318 0,319 0,320

DHCP conf. time 2,097 2,113 2,115 2,111 1,079 0,078 0,078 0,223 0,234 0,215

802.16 reentry 0,595 0,081 0,076 0,079 0,082 0,076 0,077 0,088 0,087 0,087

IPv6 conf. time 2,401 2,438 2,463 2,449 1,359 0,315 0,313 0,237 0,242 0,241

Lack of comm. 2,903 2,392 2,394 2,388 1,391 0,400 0,399 0,320 0,315 0,325

Fig. 4 Handover preparation measurements. Quantization levels of measured HO preparation times are clearly visible

7 Efficiency comparison

Seven different scenarios were assessed during experiments,with each case including additional optimization or mecha-nism. Scenarios 2 to 5 include optimizations that are allowedby standards (802.16 optimizations, preference 255, skipinitial delay and rapid-commit). Scenario 6 assumes that Du-pAddrDetectTransmits counter [20] is set to 0, effectivelydisabling DAD procedure. As this breaks Neighbor Dis-covery specification [20], it is used as a reference scenarioonly. The main purpose of DAD scenario is not to ignoreDAD, but rather assess DAD’s impact on handover delays.There are several known ways to improve DAD delays [10].Scenario 7 introduces server-side DAD [14, 17]. RemoteAutoconfiguration is introduced in scenario 8. Scenario9 introduces routing configured via DHCPv6. Final sce-nario 10 features example exploitation of knowledge gainedvia remote autoconfiguration—Binding Update procedure isstarted before L2 handover is conducted, rather than after ar-riving at destination location. Summary results of measuredparameters for each scenario are presented in Table 2.

Handover preparation time is mostly the same during first6 scenarios and differs very slightly and there is no improve-ment in this parameter. Example measurements for handoverpreparation times are presented in Fig. 4. Unfortunately,with introduction of remote address configuration, handoverpreparation is slightly increased. It should be noted that HDmetric for handover preparation is 0 ms in all cases, as sub-scriber maintains communication capability. That increasemay be considered the necessary cost of shortening other,more critical phases of the handover. If such increase by av-erage 220 ms is deemed too large, there are several optionsavailable to address this issue. Handover decision algorithmmay be modified to trigger handover earlier. If subscriber’salgorithm is not suitable for modification, base station initi-ated handover may be used instead. Nevertheless, extendingpreparation phase should not pose any impact on user’s ex-perience, as mobile node maintains full connectivity duringhandover preparation. Also, conservative mode of RemoteAutoconfiguration (that is considered the worst case) wassimulated. Assuming more optimistic approaches (hybrid oreven cooperative), better results may be obtained. Network

Dynamic host configuration protocol for IPv6 improvements for mobile nodes 1029

Fig. 5 Lack of communication capabilities. All scenarios can be easilydivided into four groups. First group (green lines, scenario 1) oscillatesaround 2.9 s. Second group (scenarios 2 to 4) provides similar blackout

period results around 2.4 s. Third group (scenario 5) decrease handoverdelays further, to 1.4 s. Final group (scenarios 6 and 7) provide evenbetter optimization with delays below 0.4 s

reentry time is only affected by IEEE 802.16 optimizationsenabled in scenario 2. Following scenarios (3–10) maintainsimilar level of roughly 80 ms as all remaining optimiza-tions focus on IP layer rather than 802.16. DHCPv6 config-uration time is not affected by any standard improvements(scenarios 2–4), except rapid-commit option introduced inscenario 5. That result can be significantly improved by overan order of magnitude by skipping DAD (scenario 6) or ex-ecuting DAD on server-side (scenario 7). Remote autocon-figuration (scenario 8) slightly degrades DHCPv6 configu-ration times, but they are still over 400% better than beststandard case.

IPv6 configuration time is part of the IPv6/802.16 han-dover that takes the most time. Impacted by only one stan-dard mechanism (rapid-commit option, scenario 5), its HDmetric varies from 2,449 ms to 1,359 in standard cases. Sim-ilar to DHCPv6 configuration time, the bigger improvementis observed with skip DAD related proposals: skip (scenario6) and server-side (scenario 7). Further improvement on asmaller scale can be achieved thanks to remote autoconfig-uration mechanism (scenario 8). Routing configuration viaDHCPv6 (scenario 9) and remote Binding Update (scenario10) have negligible impact on handover delays.

Final and most important parameter—lack of communi-cation capability—may be perceived as a logical (not arith-metic, as some parameters may overlap) sum of all previ-ously investigated parameters. Being the only one that isdirectly observable by end user, it requires special atten-tion. Being affected by essentially all improvements, it issteadily decreasing with number of enabled mechanisms.

Standard based scenarios offer a way to decrease lack ofcommunication capabilities from over 2900 ms in scenario1 to over 1390 ms in scenario 5, which may be considered agood result. Unfortunately, with HD metric around 1500 ms,the delay is still clearly noticeable by end users. Thereforefurther improvements are desired. The proposed DAD im-provements speed up handover by almost one second, downto 400 ms range. That result can be further improved by en-abling remote autoconfiguration (scenario 8 and following),down to 320 ms. Example test measurements from one ex-periment are presented in Fig. 5. Averaged results are pre-sented in Fig. 6.

8 Conclusion

Using proposed handover latency mitigation techniques, thedelay was decreased from 1390 ms to 320 ms. This offershandover delay reduction by over 76%, compared to the bestcase offered by standards. Several efficiency related mech-anisms were analyzed: Skip initial delay in DHCPv6, SkipDuplicate Address Detection, and Remote Autoconfigura-tion. According to author’s knowledge, that is the first pro-posal related to mobility efficiency in DHCPv6. The idea toperform stateful autoconfiguration remotely, before client isphysically attached to the link is new and was never ana-lyzed before. As such, it is a novel solution to a well knownproblem.

Furthermore, obtained results clearly confirm usefulnessof presented proposal. Conducted research allowed major

1030 T. Mrugalski et al.

Fig. 6 Comparison ofcommunication capabilitiesbetween scenarios. Valuesspecified in seconds

causes of handover latency to be located. Obtained exper-iment results indicate that the biggest delays are introducedin IPv6 protocol stack. Some parts of IPv6 and DHCPv6were not designed with mobility in mind. The biggest delayis caused by Duplicate Address Detection in IPv6.

It has been proved that remote autoconfiguration methodprovides useful way for further shortening of highly op-timized handover routines. Thanks to a priori knowledgegained through remote autoconfiguration, mobile node doesnot waste time on DHCPv6 configuration after changingpoints of attachment. Validated in several setups, this pro-posal offers over 20% improvement, even compared to al-ready optimized handovers.

Acknowledgements This work has been partially supported by thePolish Ministry of Science and Higher Education under the EuropeanRegional Development Fund, Grant No. POIG.01.01.02-00-045/09-00Future Internet Engineering. The work has been partially supported bythe Polish Ministry of Science and Higher Education under the grantN519 581038.

Open Access This article is distributed under the terms of the Cre-ative Commons Attribution Noncommercial License which permitsany noncommercial use, distribution, and reproduction in any medium,provided the original author(s) and source are credited.

References

1. 802.21 IEEE working group (2009). IEEE standard for local andmetropolitan networks—Part 21: media independent handover.New York: IEEE Press.

2. Brandt, S. (1998). Analiza danych. Warsaw: WydawnictwoNaukowe PWN.

3. Dec, W., Mrugalski, T., Sun, T., & Sarikaya, B. (2010). DHCPv6route option. Work in progress, draft-dec-dhcpv6-route-option-05,IETF, Sep. 2010.

4. Droms, R. (Ed.) (2003). Dynamic host configuration protocol forIPv6 (DHCPv6). RFC3315, IETF, July 2003.

5. IEEE 802.16 working group (2006). 802.16e-2004: IEEE stan-dard for local and metropolitan area networks—Part 16: air in-terface for fixed and mobile broadband wireless access systems.IEEE Standard, Feb. 2006.

6. Koodli, R. (Ed.) (2009). Mobile IPv6 fast handovers. RFC5568,IETF, July 2009.

7. L’Ecuyer, P., & Simard, R. (2009). TestU01: a software li-brary in ANSI C for empirical testing of random number gen-erators. http://www.iro.umontreal.ca/~simardr/testu01/tu01.html,April 2009.

8. Marsaglia, G. (1995). Diehard battery of tests of randomness.http://www.stat.fsu.edu/pub/diehard/, Florida State University.

9. Matsumoto, M., & Nishimura, T. (1998). Mersenne twister: a 623-dimensionally equidistributed uniform pseudo-random numbergenerator. ACM Transactions on Modeling and Computer Simu-lation, 8(1), 3–30.

10. Moore, N. (2006). Optimistic duplicate address detection (DAD)for IPv6. RFC 4429, IETF, Apr. 2006.

11. Mrugalski, T. (2009). Optimization of the autoconfiguration mech-anisms of the mobile stations supporting IPv6 protocol in theIEEE 802.16 environment. Ph.D dissertation, Gdansk Universityof Technology, Gdansk, Oct. 2009.

12. Mrugalski, T. (2010). Numbat—mobile IPv6 in WiMax environ-ment, project homepage. http://klub.com.pl/projects/numbat/, Apr.2010.

13. Mrugalski, T. (2010). Remote DHCPv6 autoconfiguration. Workin progress, draft-mrugalski-remote-dhcpv6-01, IETF, Oct. 2010.

14. Mrugalski, T. (2010). DHCPv6 server side duplicate address de-tection. Work in progress, draft-mrugalski-server-dad-dhcpv6-00,IETF, July 2010.

15. Mrugalski, T., & Wozniak, J. (2008). How to improve the effi-ciency of IPv6 handovers in IEEE 802.16 networks. In IEEE Aus-tralasian Telecommunication Networks and Applications Confer-ence, ATNAC 2008, Adelaide, Australia, Dec. 2008.

16. Mrugalski, T., & Wozniak, J. (2009). Analysis of IPv6 handoversin IEEE 802.16 environment. Telecommunication Systems, 45,191–204.

17. Mrugalski, T., Wozniak, J., & Nowicki, K. (2010). Remote state-ful autoconfiguration for mobile IPv6 nodes with server side du-plicate address detection. In Australasian Telecommunication Net-works and Applications Conference ATNAC’2010, Auckland, NewZealand, Nov. 2010. New York: IEEE Press.

18. Soliman, H., Castelluccia, C., ElMalki, K., & Bellier, L.(2008). Hierarchical mobile IPv6 (HMIPv6) mobility manage-ment. RFC5380, IETF, Oct. 2008.

19. Stankiewicz, R. (2007). Analytical models of selected DiffServnetwork elements supporting assured forwarding. Kraków: AGHUniversity of Science and Technology.

20. Thomson, S., Narten, T., & Jinmei, T. (2007). IPv6 stateless ad-dress autoconfiguration. RFC 4862, IETF, Sep. 2007.

21. Varga, A. (Ed.) (2009). INET framework for OMNeT++ 4.0.http://inet.omnetpp.org/, retrieved on June 2009.

22. Varga, A. (2009). OMNeT++ user manual, 4.0. http://www.omnetpp.org, version 3.2, retrieved Jan. 2009.

Dynamic host configuration protocol for IPv6 improvements for mobile nodes 1031

Tomasz Mrugalski received hisM.Sc. degree in computer sciencefrom Faculty of Electronics,Telecommunication and Informat-ics, Gdansk University of Technol-ogy (GUT), Poland in 2003. He ex-pects to receive his Ph.D. degree byDecember 2010. He also works forIntel Corp., where he gained prac-tical experience with experimentalWiMAX hardware. His activitiesare mainly related to DHCPv6, IPv6and open source software develop-ment. He is a member of Steer-ing Committee of Polish IPv6 Task

Force and leads several open source projects. The most notableare “Dibbler” (open source, portable DHCPv6 implementation) and“Numbat” (IPv6/Mobile WiMAX simulation environment). He is alsoauthor or co-author of 14 journal and conference papers and partici-pates in IETF activities.

Jozef Wozniak is a Full Profes-sor in the Faculty of Electron-ics, Telecom-munications and Com-puter Science at Gdansk Univer-sity of Technology. He receivedhis Ph.D. and D.Sc. degrees inTelecom-munications from GdanskUniversity of Technology in 1976and 1991, respectively. He is au-thor or coauthor of more than 200journal and conference papers. Hehas also coauthored 4 books ondata communications, computernetworks and communication pro-tocols. In the past he participated in

research and teaching activities at Politecnico di Milano, Vrije Uni-versiteit Brussel and Aalborg University, Denmark. In 2007 he wasVisiting Erskine Fellow at the Canterbury University in Christchurch,New Zealand. He has served in technical committees of numerous na-tional and international conferences, chairing or co-chairing several ofthem. He is a member of IEEE and IFIP, being the vice chair of theWG 6.8 (Wireless Communications Group) IFIP TC6 and the chair ofan IEEE Computer Society Chapter (at Gdansk University of Technol-ogy). His current research interests include modeling and performanceevaluation of communication systems with the special interest in wire-less and mobile networks.

Krzysztof Nowicki received hisM.Sc. and Ph.D. degrees in elec-tronics and telecommunicationsfrom the Faculty of Electronics atthe Gdansk University of Technol-ogy, Poland, in 1979 and 1988,respectively. He is an author orcoauthor of more than 100 scien-tific papers and an author and co-author of five books. His scientificand research interests include net-work architectures, analysis of com-munication systems, network secu-rity problems, modeling and perfor-mance analysis of cable and wire-

less communication systems, analysis and design of protocols for highspeed LANs.