low-latency handoff inter-wlan ip mobility with broadband network control

www.elsevier.com/locate/comcom

Computer Communications 30 (2007) 750–766

Low-latency handoff inter-WLAN IP mobility with broadbandnetwork control

Moshiur Rahman a, Fotios Harmantzis b,*

a AT&T Labs, 200 Laurel Avenue, Middletown, NJ 07748, USAb Stevens Institute of Technology, Hoboken, NJ 07030, USA

Received 4 January 2006; received in revised form 15 September 2006; accepted 15 September 2006Available online 10 October 2006

Abstract

Wide-bandwidth and low-cost Wireless LANs (WLANs) have emerged as a competitive choice, not only for wireless high-speed Inter-net access, but also for voice network access. High-speed Broadband Access Network-Controlled (BANC) mobility management greatlyfacilitates inter-WLAN IP mobility, through the integration of access technologies and higher layer mobility features. However, MobileIP (MIP), the current IP solution for mobility, cannot be optimized in obtaining seamless handoff for all cases, unlike the BANC mobilitymanagement employing IEEE 802.11b WLAN infrastructure mode that we propose in Rahman and Harmantzis [M. Rahman, F. Har-mantzis, IP mobility with high speed access and network intelligence, in: IEEE Wireless Communications and networking Conference,WCNC, Atlanta, GA, March 21, 2004]. Even with the proposed optimization techniques, the MIP is still not entirely tunnel-free. It is notefficient due to certain unavoidable data loss during handoff for time-sensitive services, such as the Voice-over-IP (VoIP). In this paper,we present a BANC-supported low-latency handoff mobility management scheme, by modifying the enhanced IAPP messaging for theWLAN infrastructure mode. We then examine main performance metrics for IP mobility management: delay, packet loss, handover exe-cution time, throughput, and signaling overload for the fast handover MIPv6 (FMIPv6) [R. Koodli, Fast handovers for mobile IPv6,IETF Internet Draft, draft-ietf-mishop-fsat-mipv6-01.txt, February 2004] and BANC-offered mobility management schemes. Simulationresults show that BANC has better performance than FMIPv6 for inter-WLAN IP mobility management. As the network server is themain component in the BANC scheme, we have evaluated the impact of the Mobile Node (MN) traffic load, the server packet forwardingrate and datagram processing schemes (central vs slot-based processing), on the CPU utilization to aid BANC service providers’ capacityand traffic planning.� 2006 Elsevier B.V. All rights reserved.

Keywords: WLAN; Broadband; Mobility; Mobile IP; Handoff

1. Introduction

Mobility management functionalities include locationmanagement and handoff management, that keep a con-nection alive during Mobile Nodes’ (MNs) mobility. Toprovide seamless IP mobility, various standardizationworks are in progress in IETF’s MIP working group, espe-cially the IPv6 [23] that is considered the next generationInternet protocol. Even with all the enhancements, e.g.,

0140-3664/$ - see front matter � 2006 Elsevier B.V. All rights reserved.

doi:10.1016/j.comcom.2006.09.007

* Corresponding author.E-mail address: [email protected] (F. Harmantzis).

HMIPv6 [28] and FMIPv6 [14], to support real-time orloss-sensitive applications is challenging. Though the cur-rent MIP enhancements are geared towards optimizinglocal (micro) mobility updates and handover speed, theseenhanced schemes are generally considered to be controlledby the Mobile Node (MN) which selects new attachmentpoints, triggers handover, and updates the path. This leadsto a non-optimized target attachment point selection, asthe MN has a limited view of available Quality of Service(QoS), given by its radio quality measurements. A moreglobal view on resources use is available at the networkside. Also, peculiarities of commercially available IEEE

mailto:[email protected]

M. Rahman, F. Harmantzis / Computer Communications 30 (2007) 750–766 751

802.11b WLAN hardware prevent existing MIP implemen-tations from achieving sub-second mobile IP handoff laten-cy, when WLANs operate in the infrastructure mode. Theinfrastructure also prevails the operating mode used in themost deployed IEEE 802.11b WLANs. As such, IP serviceproviders would prefer a mobility management alternativethat would leverage evolving access technologies and high-speed backbone network to support WLAN IP mobilitywith better QoS than what Mobile IP and its recentenhancements provide.

In [24], we proposed an IP mobility management archi-tecture with WLAN infrastructure mode that integratesWLANs with a network-controlled mobility scheme, byleveraging evolving broadband access technologies andhigh-speed backbone network. This network arrangementconnects a WLAN’s access point to a central network serv-er with high-speed connectivity, employing a PermanentVirtual Circuit (PVC) to leverage the network intelligencein facilitating Layer 3 IP mobility. The claim is that anynetwork infrastructure employing the proposed inter-WLAN BANC architecture obviates the need for MIP-likeapproaches. As the WLANs natively transport IP packets,the challenge is to merge them with an IP-based mobilityscheme to support large-scale deployments. The BANCarchitecture, implemented with IEEE 802.11 infrastructuremode, can leverage the IAPP messaging for mobilitymanagement.

The enhanced IAPP [4] prevents link-layer packet lossesby implementing a data buffering and forwarding scheme;however, it introduces delay for the forwarded traffic,which is not acceptable for time-sensitive services, such asVoIP. IAPP lacks central control capability that is neces-sary for providing QoS. Both IAPP and its enhanced ver-sion are not immediately applicable and are inadequatefor the BANC mobility management scheme.

In this paper, we propose a handoff scheme for a net-work-controlled mobility management architecture,employing an infrastructure mode based on the IEEE802.11f standard and enhanced IAPP. We then evaluateand compare the performance of the BANC IP mobilitymanagement with the one of the best enhanced mobilitymanagement alternatives of MIP, namely the FMIPv6[14], via simulation. The unique contribution of the BANClow-latency handoff scheme proposed in this paper is that itis designed specifically for IEEE 802.11 WLAN running inthe infrastructure mode, leveraging the enhanced IAPP [4]with modification. According to the results, the schemeproposed in this paper achieves the lowest handoff IP laten-cy on such networks.

The remaining sections of this paper are organized asfollows: Section 2 provides a critical review of the currentmobile IP mobility management alternatives. Section 3describes the proposed IP mobility management schemeusing BANC. In Section 4, we compare the performanceof the proposed system and the FMIPv6 mobility manage-ment alternative using OPNET tools. Section 5 providesthe concluding remarks.

2. Review of IP mobility alternatives and critical issues

This section provides a critical review on MIP’s exten-sions and enhanced IAPP’s capabilities.

2.1. MIP handoff: issues with the proposed solutions

The Mobile IP (MIP) is the only current means of offer-ing seamless mobility to mobile computers on the Internet.In order to meet the performance needs, the MIP protocolhas already gone through major enhancements, e.g., theIPv6, a next generation Internet protocol that wishes toreplace IPv4.

The MIPv6 [7,15] mechanism requires some handoveralgorithm when it changes its point of attachment in theInternet. This causes MIPv6 to incur larger signaling loadon the backbone Internet and longer end-to-end delays.This limitation is due to lack of hierarchy in the MIPv6mobility management which uses the same mechanismfor macromobility and micromobility. This is an inefficientuse of resources in local mobility. In response to this,IETF’s MIP Working group (WG) has taken twoapproaches: The first one adopts hierarchical architecture;the second approach uses Layer 2 triggers for fasthandover.

The HMIPv6 [28] is an extension of the MIPv6 that isdesigned to reduce the signaling load and to improve speedfor mobile connections by introducing a new protocolagent, called Mobility Anchor Point (MAP); MAP cansplit the mobility management into macro- and micro-mobility schemes. In HMIPv6, global mobility manage-ment is still managed by MIPv6. However, HMIPv6 is stillnot the solution to time-sensitive services as it adds delaysthat come from the Duplicate Address Detection (DAD)function at the new access point and the message exchangetransmission time during the process of the registrationoperation [7]. More problems arise when the Home Agent(HA) or Correspondent Node (CN) is located geographi-cally far away from the MN and when the MN moves ina small coverage area (micro-mobility). The messageexchange transmission time for a MN to send a BindingUpdate (BU) to HA/CN will become excessively high,causing long delays or service disruptions, in both macro-and micromobility. These control messages supportingBU, generate significant signaling traffic load in the corenetwork, even for a local movement, followed by a longinterruption during handover [2,8]. In IP micro-mobilityoffered by HMIPv6, the decision making phase of hand-over execution is excluded from the protocol specifications.The movement detection procedure is handled at the IPlevel through monitoring of router advertisements, in thesame way as it is performed at MIP. Thus, there is still asignificant delay between the physical movement (i.e., radiohandover) and its detection at the IP layer by the MNitself, which increases the handover execution delay [2].

The FMIPv6 [14,9,31] scheme optimizes handover laten-cy by allowing the MN to acquire its new IP addresses

752 M. Rahman, F. Harmantzis / Computer Communications 30 (2007) 750–766

before re-associating to the new IP subnet. This newaddress corresponds to the target attachment point forthe handover process; then it is immediately valid, oncethe MN is associated with this new attachment point atLayer 2. FMIPv6 was proposed to address the problemthat the MIPv6 procedure could not start before the Layer2 handover is completed. However, this proposal does notimpact the handoff latency significantly, as the main com-ponent of the handoff latency comes from the discoveryof a new attachment point. The FMIPv6 solution establish-es new messages between the two access routers involved inthe handover. Whenever the IP address acquisition mecha-nism is not completed before the handover, FMIPv6enables the MN to temporarily use its old IP address atthe new attachment point, until it definitely acquires itsnew one. This is supported through temporary tunnels setup between the two attachment points. This might helpreducing the packet loss but would cause delays to the redi-rected traffic.

The simple combination of HMIPv6 and FMIPv6 [8] isalso not an efficient method. In this method, packets sentfrom CNs are forwarded to MAP by Mobile IPv6 opera-tion and then forwarded to the present access router byHMIPv6 operation. Finally, the packets are forwardedonce more to the new access router and delivered to theMN by FMIPv6 operation. Accordingly, this simple com-bination induces a triangle-type routing problem. Such tri-angle routing may cause packet delivery delay and waste ofbandwidth. Also, like FMIPv6, the combination ofHMIPv6 and FMIPv6 assumes that mutual security associ-ation is already established between access routers orattachment point and they need to share their information.Access networks with hierarchical structures will have dif-ficulties to comply with such assumptions. Accordingly, ifwe want to implement fast handover in HMIPv6 architec-ture, we need to develop a more efficient solution. Themain difference of F-HMIPv6 [14] compared to the simplecombination of HMIPv6/FMIPv6 is the following: theMAP, instead of the current access point, plays a key rolefor CoA pre-configuration, establishment of bi-directionaltunnel, etc. Note that F-HMIPv6 is a complex solution,from an implementation point of view, and has similar sig-naling overhead like FMIPv6.

Mobile IP offers transparent mobility support to higherlayers with the cost of performance overhead [1,7,11].Smooth handoff [20,21] and low-latency handoff [30] alsocannot avoid tunnelling between the previous FA and thenew one. Encapsulation, de-capsulation and re-encapsula-tion are main operations for tunneling, which lead to sig-nificant increase on the average IP header size. Thisdefinitely brings extra load to the Internet. Packet headerfor security and QoS become invisible due to encapsulationin tunneling. Mobile IP needs third party HAs and FAsand this raises security issues in terms of relationship trustand association. In terms of network topology, MIP and itsextensions could be applicable in IP mobility managementfor WLAN ad hoc mode that lacks central control, to pro-

vide location management and IP address managementover the high-speed access. However, this is not directlyapplicable in the BANC which employs an infrastructuremode and has its own central control mobility managementtechnique [24].

Most of the handoff schemes investigated above invari-ably assume that MNs can anticipate link-layer handoffsand maintain connectivity with the old as well as the newaccess router or point of attachment [28,14,8]. While suchassumptions are valid for WLANs operating in an adhoc mode, they do not hold for WLANs running in infra-structure mode, where link-layer handoffs are hard and for-ward. In infrastructure mode, a MN is associated with onlyone access point at a time. Although IEEE 802.11b NIC ona MN can access the signal strength information for allneighboring access points, such information is not avail-able to mobility management software. As a result, propos-als on fast handoff that rely on the ability to anticipate animminent link-layer handoff through signal strength com-parison, cannot be applied to IEEE 802.11 WLAN operat-ing in infrastructure mode. Moreover, since the MN cannotreceive packets transmitted from other access points, it isnot possible to receive multiple foreign agents advertise-ments and maintain a list of neighboring foreign agentsfor future use. That is, a MN needs to identify the foreignagent of a new WLAN before it can switch to that WLAN.In response to the above gap, [30] proposes a low-latencyhandoff scheme for infrastructure mode by employing anadditional network entity, called the caching agent, forre-playing advertisement to the MN. Though this handoffscheme overcomes the inability of mobility software tosense the signal strength of multiple access points anddetect the link-layer handoff, it does not guarantee fast tun-nel setup time. This scheme is mainly based on the Wi-Ficard’s access point ID probing capability which wouldnot be always faster and highly reliable in a noisy environ-ment. Suggestions made in [30] still need to use MIP formacromobility management.

The SIGMA handoff scheme proposed in [29] works atthe transport layer and shows better performance thanMIP. This scheme is not directly applicable to a networkwith central control for managing the IP layer mobility.

Mobility management approaches described in[3,6,12,19] are not directly applicable to BANC networktopology. Ref. [13] describes an optimized handoverscheme for MIPv6 and faces similar issues with respect tocentral control as well.

In the Handoff-Aware Wireless Access Internet Infra-structure (HAWAII) [25], routes to the mobile hosts areestablished by specialized path setup schemes that updatethe forwarding tables with host-based entries in selected rou-ters in that domain. It is reasonable to add host-based routeentries in wireless access networks, but it is un-scalable inbackbone networks; for mobility across backbone networks,or inter-domain mobility, HAWAII defaults to traditionalMIP schemes. Mobile-specific routing methods, likeHAWAII, avoid the overhead introduced by de-capsulation


and re-encapsulation, but need specific support within theadministration domain and are less scalable due to extra bur-den on the routing table. Thus, it is not a viable alternativefor most of the service providers with high-speed backbonenetworks.

In summary, for MIP and its extensions, a certainamount of latency in data transmission appears to beunavoidable when the MN performs a handoff. This inter-ruption in data, limits the feasibility of real-time communi-cation over mobile networks. HAWAII is also not a viablesolution for mobility management because of its scalabilityissues.

2.2. IAPP enhancements

IAPP is a set of functionalities and a protocol used byan access point to communicate with other access pointson a common Distribution System (DS) in an IEEE802.11 network. In a common DS, two mobile nodeswhich cannot communicate directly with each other viawireless medium can still communicate, as long as bothmobile nodes belong to the same Extended Service Set(ESS) built with multiple Basic Service Sets (BSSs). Thefunctions of IAPP are to: (1) facilitate the creation andmaintenance of the ESS, (2) support the mobility of mobilenodes, and (3) enable access points to enforce the require-ment of single association for each mobile node at a giventime. Among the functions provided by the IAPP, we areinterested in IAPP’s support for mobile nodes’ mobility.IAPP’s MOVE-notify and MOVE-response IP packetsare used to transfer context between access points. InIAPP, frames get lost and that is not acceptable in time-sensitive services. IAPP does not have IP mobility manage-ment capability. More on the IEEE 802.11 IAPP can befound in [10].

The link-layer frame buffering and forwarding techniquedescribed in enhanced IAPP [4] prevents the link-layerframe loss. However, there exist some issues that need tobe addressed carefully. The buffering and redirecting framefunctionality might help reduce the data loss but adds extradelay to the forwarded traffic. The longer the handoff laten-cy, the larger the queue size, resulting to longer durationsof the forwarded traffic. Frame buffering and forwardingrequire resources at both APs and consume network band-width along the path between them. This solution is notcost effective and may not be desirable for both service pro-viders and end users. IAPP does not provide a completemobility solution and it relies on MIP for macromobility.IAPP also cannot guarantee shortened handoff latency,as the new AP’s discovery is not quite obvious. For exam-ple, when the MN is seeking new beacon frames in a noisyenvironment, the discovery of a new AP may be longerthan expected. This would cause longer disruption timewhich contributes more frame loss that may not be accept-able to time-sensitive services. Thus, there is more room forimprovement in IAPP to support network-assisted IPmobility, such as BANC.

3. Broadband distribution system integrating WLAN and

WAN

The distribution system that connects WLANs plays animportant role for the QoS of the BANC. The distributionsystem is formed by a Distribution System Medium (DSM)and a Distribution System Service (DSS) function in eachaccess point and central server. The implementation ofthe mobility management with any external central controlin a broadband distribution system, such as a DSL loop, acable loop, or a power line, is not specified in any currentWLAN. The coverage and performance of an inter-WLANmobility scheme would largely depend on the implementa-tion of the distribution system and the control messaging inBANC.

Ref. [2] proposes an IP-based network-controlled hand-over management for WLANs, where handover is man-aged by the network which provides target attachmentpoint selection during handovers. However, the paper doesnot specify any implementation of this approach. Thus, ourBANC mobility management approach differs from [2] inthe implementation of the broadband-supported DSM toprovide inter-WLAN mobility. Ref. [5] proposes threeimplementation options for the distribution system, includ-ing a server-controlled WLAN using the IP layer, to for-ward messages between stations in a IEEE 802.11infrastructure network. Our research focuses on both high-er mobility management and the broadband distributionsystem. Thus, our work differs from [5] in two importantways: First, our distribution implementation architectureoption uses a broadband-accessed network server residingin a high-speed backbone data network for inter-WLANcommunications and user mobility management. DSM,such as Ethernet, provides limited range in local area; abroadband DSM will provide wider range with efficientconnectivity. This integration of WLANs with a WAN(high-speed data network) using broadband access, pro-vides an efficient and cost effective mobility managementfor the WLANs. Secondly, our mobility scheme leveragesIAPP and proposes supplementary protocol proceduresfor handover; it also specifies the required additional sig-naling messages for the inter-WLAN mobility manage-ment. According to us, the key idea is to leverage IAPPas much as possible. The cellular network mobility man-agement protocol does not seem to be a good starting pointfor connection-less packet networks, such as 802.11WLAN.

The notion of our mobility scheme with broadband-ac-cessed distribution system for inter-WLAN goes beyondthe traditional WLAN mobility. Our distribution system,by integrating WLAN and high-speed WAN with a centralcontrol, would obviate multicasting and improve the over-all efficiency. The ‘always on’ high-speed broadband accessthat connects the mobile node and the central server wouldfacilitate the faster message transactions, resulting toreduced delay. With this broadband-supported distribution,all WLANs will be under the control of a single server.


This central server coordinates and maintains the locationsof the mobile nodes. Because of the server’s capability, themobile nodes in different subnets, i.e., WLANs, will beunder the same virtual network. All the WLANs’ broad-band access points that are of different broadband accessnetwork can be served by the same central server. Thiscould be achieved via some intelligent signaling technique.Such interconnecting technique, using IP and PSTN SS7signaling, is beyond the scope of this paper. More thanone distribution system can be connected via any backbonemechanism, such as IP, to form a single distribution systemthat would cover a wider geographic area. As mentionedearlier, with a typical distribution system, such as Ethernet,the inter-WLAN mobility range is limited. With a broad-band-supported distribution system, we can have fastermessage transaction and broader inter-WLAN mobilityrange with high quality for both data and voice.

3.1. BANC network topology

We propose a broadband-accessed inter-WLAN archi-tecture network arrangement (Fig. 1) that can locatemobile hosts while keeping the connection alive duringthe movement [24]. This arrangement provides an ‘alwayson’ connectivity between WLAN access points and the net-work server that manages mobility. The BANC architec-ture also allows a WLAN user to roam between differentWLANs with the same IP address. This architecture inte-grates WLAN with high-speed WAN-based network servervia high-speed broadband access (such as DSL and cable).The main four components of the BANC are: (i) WLANaccess point (termed as broadband access point – BCP),(ii) high-speed broadband access, (iii) high-speed IP back-bone, and (iv) network server off the high-speed backbone.The mobility management between WLANs in the IPlayer, is provided through the network server intelligenceof location management and direct routing.

The key here is to connect the BCPs to a central networkserver with high-speed connectivity employing a PVC toleverage the network intelligence in facilitating Layer 3 IP

Fig. 1. BANC mobility management network topology.

mobility. WLANs in different locations interconnectedvia the network server will appear to be in the same virtualnetwork, because of the server’s location management andIP address translation and mapping capabilities. The samenetwork resources will be available to all WLANs, irrespec-tive of their locations. This server-facilitated mobility man-agement capability offered in the broadband accessnetwork, obviates the need for a MIP-like mobility man-agement approach; the BANC architecture provides bettermobility management, due to its network topologyarrangement. A MIP-like network topology that lacks cen-tral QoS management does not fit the BANC system. In theBANC network configuration, as mentioned before, allthe subnets (WLANs) are in the same virtual networkand the mobility among these WLANs is managed by acentral server. The claim is that any network infrastructureemploying the proposed architecture does not need otherIP mobility management techniques, as the IP layer mobil-ity management is provided through the server. In this net-work configuration, all the incoming packets pass throughthe Gateway server. The packet routing task would begreatly mitigated with a high-performance Gateway thatemploys a fast routing table lookup technique. Investiga-tion on this fast routing table lookup mechanism is beyondthe scope of this paper. Mobile IP is not directly applicablefor the proposed BANC architecture. However, in terms ofQoS, a valid question can be asked: what is the differencebetween the mobility management offered through the pro-posed mobility management handoff scheme, and themobility management in any other network architectureemploying MIP alternatives, e.g., FMIPv6. This is theessence of this paper and this is what we are answeringhere. In the BANC IP mobility management scheme, thecentral server has a more global view of the use of bothradio and network resources for all attachment pointsand MNs. This central server performs target attachmentpoint selection in the network layer.

3.2. BANC low-latency handoff scheme

The IETF’s Mobile IP workgroup has proposed so-called low-latency handoff schemes, which are distin-guished as: pre-registration (where the network assists theMN in performing a Level 3 handoff before the Level 2handoff is completed), and post-registration (where L3occurs after the L2 has been completed) [16]. Theseschemes are difficult to apply to BANC inter-WLAN IPmobility, because their operation was originally based onthe MIP and dealt only with the registration procedure.However, considering the network and end user security,in the event of handoff between WLANs, both the registra-tion process and the authentication process must be includ-ed in the entire handoff procedure.

Our handoff scheme has leveraged the IEEE 802.11 stan-dard described in [10,18] , also known as the Inter AccessPoint Protocol (IAPP). IAPP is essentially an IP-basedprotocol. However, both the standard IAPP and the

BCPOld

Networkserver

MN BCPNew

HO_REQ

HO_REQReasso_REQ

HO_RES

Reasso_RES

WLAN

RSRC_REQ

RSRC_RES

HO_RES

HO-ACK

Extended IAPP HO procedureOver the wired part

MOVE-notify

MOVE-response

Fig. 3. IAPP modified messaging in BANC.


enhanced IAPP [4] are not adequate to support BANCmobility management, as they do no not have any centralcontrol for managing the IAPP control messages, and can-not be directly applied to the BANC mobility support.IAPP enables the IEEE 802.11 APs to communicate witheach other and facilitates context transfer for mobile nodes.BANC inter-WLAN mobility exploits this context transfer-ring capability for the authentication purpose. By usingIAPP, the re-association/re-authentication process is short-ened and so is the link-layer handoff latency. The bufferingand redirecting frame technique used in enhanced IAPP [4]reduces the data loss, but adds extra delay to the forwardedtraffic. The longer the handoff latency, the larger the queuesize, resulting in longer duration of the forwarded traffic.For real-time services, such as VoIP, the delay in voicepacket transmission is easily perceived by the end-userand must be avoided, whenever possible, to maintain betterQoS. A BANC-offered mobility scheme employing a mod-ified IAPP messaging, can offer better QoS in terms ofdelay and packet loss.

Fig. 2 shows how the BANC-employed modified IAPPreduces handoff latency. The handoff phase is shorter thanin IAPP and MIP. While still within the range of the cur-rent access point, the MN starts re-association with thenew access point at time T1 and completes at time T2. Notethat by time T2, all the required message transactionsbetween the central network server and the new accesspoint are completed over the high speed and ‘always on’broadband distribution system. By time T2, the serverknows the location of the MN and starts sending datadirectly to the MN via the new access point. No tunnelingis involved. These message transactions in the modifiedIAPP are shown in Fig. 3. In [4] the handoff ends at timeT4, after MOVE-notify/MOVE-response/MOVE-forwardmessages, hence, it takes longer than the BANC scheme.In MIP, the MN starts receiving data at time T6 whenthe binding update is completed. BANC differs from theenhanced IAPP in two ways: (1) BANC starts sending datadirectly to MN’s new location during handoff time, and (2)BANC has central control to support QoS, based on theservice needs.

Since the MN cannot receive packets transmitted fromother access points, it is not possible to receive multiple for-

LL

IPT1 T2

T5 T6

MN

BCPold

BCPNew

B-updatestarts

B-updateends

time

BANC HO latency

Enhanced IAPP HO latency

Original IP -layer HO latency

Reasso _RESMOVE -notify/MOV -response/MOVE_Forward

T4T3

Fig. 2. Reduced handoff latency with modified IAPP in BANC handoffscheme.

eign agent advertisements and maintain a list of neighbor-ing foreign agents a priori, for future use. However, theMN needs to identify the foreign agent of a new cell beforeit can switch to that cell. The IEEE 802.11 Network Inter-face Card (NIC) can access the signal strength informationfor all neighboring access points and our BANC handoffscheme makes use of this information. When the MNdetects that the radio quality is falling bellow a giventhreshold, it collects signaling quality measurements fromneighboring APs and reports them to the network server.In response, the network selects a target AP to which theMN has to handoff, by taking into account parametersstored in its database. This way, the network server con-trols the whole access network resource, while anticipatingMN handovers, which reduces handover execution timeand packet loss. The objective here is not only to reducethe handoff latency, but also to minimize the total forward-ed traffic, if possible, by starting the handoff initiationwhile the MN is still within the range of the current AP.

The proposed seam-less handoff scheme uses minimumsignaling messages to decrease latency and signaling costs.Moreover, in order to prevent packet loss during handoff,the proposed scheme allows the network server to manageMN’s Care of Addresses (CoAs) assigned by the twoWLANs’ access points (BCPs) participating in the handoff.By using this ability, the network server can buffer the datapackets destined to the MN during handoff. The networkserver also registers the CoA assigned in the newly hand-ed-off network as it allocates extra space to store theMN’s next CoA in the address table, as shown in Table 1.

Table 1Address management: address mapping scheme

Home IP address Current CoA Next CoA

IP_MN1 IP_C1 IP_N1IP_MN2 IP_C2 IP_N2� � � � � � � � �


This table shows the address mapping scheme by the serverwhen the MN moves from the home WLAN to a new one.

BANC mobility management provides central controlusing the network server of a high-speed backbone net-work. The BANC inter-WLAN handoff operation can beexplained by dividing the process into two phases: HandoffInitiation Phase and Handoff Execution Phase.

Fig. 3 shows the required signaling message flow for theproposed handoff procedure in BANC. Additional messag-es are needed in IAPP to support the mobility managementusing the proposed scheme. The flowing additional messag-es, referred to as Protocol Data Units (PDUs) in IEEE802.11, are defined in the modified IAPP: HO_ACK,RSRC_REQ, and RSRC_RES. As the MN migrates awayfrom the old BCP towards the WLAN coverage area of thenew BCP, it listens to the beacon signals from both BCPs.Based on its measurements of the BCP beacons, the MNcan suggest when to initiate handoff from the old BCP tothe new BCP. Note that these beacon measurements andHO decisions are specific vendor implementation depen-dent. As the MN detects that the radio quality is falling bellowa given threshold, it collects signaling quality measure-ments from neighboring APs. After the measurement isdone, the MN sends a Re-association Request (Reas-so_REQ), an existing IEEE 802.11 MAC message, to thenew BCP using the broadcast radio channel, specifyingall its audible frequencies and their corresponding Signalsto Interference Ratio (SIR) status. Upon receiving thisHO indication message (Reasso_REQ), the new BCP sendsa Handover Request (HO_REQ), an existing IAPP mes-sage, to the network-based server over the broadband (suchas DSL/ATM) interface. Based on this message (userdevice ID, potential handoff BCP – the new BCP – andthe call connection ID of the existing call) from the newBCP, the server establishes a correlation between the exist-ing call and the old BCP that is serving the MN. The BCPsmaintain a permanent virtual circuit with the network serv-er through the broadband access. The network serverwould maintain a connection table of all the existing calls(data or voice) using BCPs served by the server. The serverthen sends a query Resource message, RSRC_REQ, to thenew BCP asking about its resource availability. This wouldbe the first new message to IAPP. In response, the new BCPsends a RSRC_RES (the second new message), providinginformation about the resource availability (in this messageflow it is assumed that the resource is available). The net-work server could use an inter-BCP (WLAN) protocol todetermine the best possible new BCP (WLAN) for themigrating remote mobile terminal. After receiving aRSRC_RES from the new BCP, the network server sendsan acknowledgment, HO_ACK (the third new message)to the new BCP. Assured of the establishment of the datapath to the MN via the new BCP, the sever sends aHO_REQ message to the old BCP. The old BCP thensends a HO_RES to the server, and in turn the server sendsthis HO_RES to the new BCP. Then the new BCP sendsthis Reasso_RES to the MN to complete the handover ini-

tiation phase. After receiving the Reasso_RES from thenew BCP, the MN changes its operating frequency andstarts communicating through the new BCP. Now theresource allocation tables in the BCPs and the networkserver are updated. The address table in the server is alsoupdated. With MOVE_notify and MOVE_response pack-ets, the IAPP provides context transfer between BCPs. Itassumed that a single MOVE_response could carry all buf-fered data. MOVE_ forward message identified in theenhanced IAPP could also be used.

3.3. Gateway in BANC mobility scheme

The Gateway (GW) (network server) is the central partof the BANC mobility management scheme. To deploy thenetwork GW, its capacity must be sized and scaled basedon the traffic patterns and volume to maintain a specifiedQoS level. As mentioned before, the assumption is thatthe GW in this handoff will incorporate a fast routing tablelookup algorithm available today to mitigate the packetdiscriminating and forwarding task. Handoff is a criticalattribute of wireless mobility management performance.

In WLAN IP, the HO process requires the processing ofmessages by the GW. The HO delay is typically the timerequired for the processing and completion of the first fourmandatory messages. The HO delay can be calculated asdho ¼ dtr þ T

(

GW, where dho is the total delay incurred dueto handoff to different WLAN’s access points, dtr is thetotal transmission and propagation time, and T

(

GW isthe mean packet processing time at the GW. HO delay isthe main attribute of the proposed WIP GW performance.Assuming that dtr is constant, the HO delay would be thepacket processing time at the GW. Thus, the proposedGW-supported architecture can be modeled as a single ser-vice delay system with a generalized service time (M/G/1queue) [32]. There are three types of packets followingthrough the GW system: (i) HO-related messages shownin Fig. 3, (ii) packets that are re-directed by the GW, (iii)normal packets. The packets entering the GW are classifiedinto two levels of priorities: HO-related packets have highpriority and other packets have lower priority. Let usdenote the arrival rate of the packets to the GW ask = k1 + k2 + k3, where the k1 is the arrival rate of HO-re-lated packets, k2 is the arrival rate of packets to be redirect-

ed, and k3 is the arrival rate of other packets. If T GW is themean service time for all other packets, then the delay ofHO-related messages at the GW is denoted [32]:

DGW ¼k � T 2

GW

2 � ð1� q1Þþ T GW ð1Þ

where q1 is the GW server utilization of HO-related pack-ets, and q1 ¼ k1 � T GW. Here T 2

GW is the second moment ser-vice time of the GW, and T 2

GW ¼ d2GW þ ðT GWÞ2, where d2

GW

is the variance of the service time.The HO delay is mainly due to the HO-related message

processing delay at the GW. Eq. (1) shows that the HO

ig. 4. Simulation platform used to compare BANC with FMIPv6fficiency.

Table 2Link values used in simulation network’s links capacity

Links (mbps)

Wired: CN-IP Router 100Wired: P Router-HA 1.5Wired: IP Router- FA 1.5Wireless: 802.11 11


message processing delay is related to the arrival rate of thepackets, which is the portion of the HO-related packets outof all the total served packets. Since we assume that theHO-related packets are the fixed portion of all the totalpackets passing through the GW, they have a higher prior-ity over other packets, thus increasing arrival rate wouldincrease the total delay.

With this network arrangement, the GW server could bethe bottleneck of the system. One of the major functions ofGW is packet forwarding, which is basically a routing tablelookup based on the IP destination field in the packet head-er and identify the next hop to which the incoming packetshould be sent. A GW router that supports the described IPmobility scheme must have an efficient routing table look-up to maintain QoS. The implementation of the BANCinter-WLAN IP mobility scheme is assumed to be with amanaged IP network with broadband access. In this net-work arrangement, packets coming from a correspondentnode to a MN, are routed through the GW that knowsthe current location of the MN. Two issues here with theGW server: route lookup and memory storage. We assumethat with advanced fast route lookup and compressiontechniques, which are beyond the scope of this paper, thelocation update and packet forwarding tasks of the GWcould be mitigated. Packet lookups in a GW can be expe-dited by various approaches, generally classified as soft-ware-based or hardware-based ones [26]. As mentionedearlier, this GW will be off a high-speed backbone network.Some major backbone routers’ routing table trace analysisshows that these routers have ‘‘default free’’ routing tables,i.e., they are supposed to recognize all the incoming packetswith various IP destination addresses [26]. This means theydo not need to use a default route for incoming data pack-ets. Ref. [17] presents a fast route lookup algorithm andefficient update algorithm that supports incremental routeupdate. A service provider needs to assess the given MLPScapability based on the IP traffic volume. In our paper, aconfigurable processor is used to achieve fast IP route look-up (4 million lookups per second (MLPS) for a processor at200 MHz).

4. Simulation experiments and results

Fig. 4 shows the network topology that we have used inour simulation test-bed to investigate the proposed BANCarchitecture handover mechanism and compare its efficien-cy with an enhanced MIP alternative, namely FMIPv6 [14].We have compared our mobility scheme with FMIPv6, thebest mobility option among the current enhanced MIP [27].FMIPv6 conforms with the design criteria metrics of softhandoff, like BANC.

The inter-WLAN mobile simulation network consists ofeight access points and 1 to 11 MNs, roaming between theaccess points. We believe that 8 access points and 11 MNsare sufficient to demonstrate the mobility managementcomparison for the two alternatives through simulationwith respect to packet loss, throughput, delay and control

Fe

load. We change attributes such as MN’s speed to makehandoff faster (thereby, create more control load), trafficload and the system’s capacity. Table 2 shows the link val-ues used in our simulation experiments.

WLAN is configured as IEEE 802.11, with 11 Mbpsdata rate and no RTS/CTS or fragmentation (Table 2).Each WLAN radio coverage is set to 250 m; that ensuresnon-overlapping radio coverage of separate BCPs, eventu-ally requiring a sort of hard handover, upon crossing thecoverage boundaries. The mobility pattern of the mobilenode is characterized by a horizontal linear path withpedestrian speed of 1 m/s. This speed has been varied from1 to 8 m/s when needed, to observe the impact of the mov-ing speed on various performance measures. The movingspeed 8 m/s implies that the mobile node moves faster thantypical pedestrians but also slower than typical passengervehicles in a metropolitan area. Consequently, this choiceof mobility pattern would result in moderate handoverrates.

The application traffic exchanged between CN and MNis configured to represent IP telephony, where CN and MNact as clients to each other. The voice traffic exchangedbetween MN and CN can start and stop in a random man-ner. In this simulation setting, the CN and server softwarereside in the same box, but functionally they are indepen-dent entities.

We have used the IEEE 802.11 mobile IP reference mod-el provided by OPNET [22]. Our simulation model is builton this OPNET model that provides standard Mobile IProaming model. However, it has been enhanced to serveour experiment requirements. More specifically, we have

Table 3Handoff latency comparison: enhanced IAPP vs BANC

Handoffscheme

Mean(ms)

SD(ms)

Confidence interval

90% 95% 99%

IAPP 107 10 104.6–109.3 104.2–109.7 103.3–110.6BANC 101 12 98.1–103.8 97.6–104.3 96.6–105.3

Table 4Handoff latency comparison: enhanced BANC vs FMIPv6

Handoffscheme

Mean(ms)

SD(ms)

Confidence interval

90% 95% 99%

FMIPv6 115 12 112.1–117.8 111.6–118.3 110.6–119.3BANC 101 12 98.1–103.8 97.6–104.3 96.6–105.3


developed the interaction between the IP and the Mobile IPmanager to reflect the required control capabilities neededin the proposed mobility management scheme. We haveutilized 802.11b WLAN interface with roaming capabilityto simulate handoffs between mobile IP agents that are alsoWLAN access points. We have modified the OPNET 11.0MIPv6 process model code to calculate the Layer 3 handofffor BANC (control messages in Fig. 3) and the FMIpv6(control messages in Fig. 5). MIPv6 has more signalingmessages than in BANC (shown in Fig. 3) for the handoff.

In our simulation test bed, each experiment had 50 runsof 1000 min duration each. (1000 min simulation time isequivalent of 7 min real time). The parameters we exam-ined in our experiments to observe QoS performance ofthe two alternatives are:

• Packet size

• Interval rate

• Mobile node speed

• Application type

4.1. Enhanced IAPP vs BANC mobility schemes

Before comparing BANC with FMIPv6, we have com-pared the BANC reduced handoff latency with theenhanced IAPP handoff latency. The basic differencebetween the proposed and the enhanced IAPP is that theIAPP does not have any central control to assist any spec-ified QoS; secondly, the enhanced IAPP suffers from thedelay encountered in redirecting traffic during the handoffperiod. BANC mobility scheme avoids this redirect routingby using network control of location management. Hand-off latency measurement results for micro mobility areshown in Table 3. In this simulation test-bed, we havetwo mobility scenarios: one with IAPP messaging andanother with the BANC proposed messaging. In each sce-nario, we have allowed 11 MNs to move between eightWLANs with 1 m/s speed and calculated the handoff laten-

Fig. 5. Handoff control messages in FMIPv6.

cies. Table 4 shows the latency comparison between BANCand FMIPv6 for end-to-end mobility.

4.2. UDP data end-to-end delays

In order to simulate real traffic, we setup the CN as traf-fic source over a User Datagram Protocol (UDP), produc-ing fixed length packets of 200 bytes each, every 20 ms.This simulates a host that is streaming audio or VoIPtraffic. Here, we have carried out two scenarios with twodifferent MN speeds, 1 and 8 m/s, respectively. Table 5has input for end-to-end delays experiments for BANCand FMIPv6. Figs. 6 and 7 show examples of end-to-enddelays comparisons of the two alternatives for 1 and 8 m/sMN speeds. Table 6 has the output statistics of theseexperiments.

The delay in BANC is shorter due to low-latency hand-off in BANC.

From Fig. 6, that shows average end-to-end transmis-sion delays from CN to MN for 1meter/s MN speed, wecan see that BANC handover allows a MN to keep mini-mal transmission delay, about 99 ms, when the MN crossesthe current WLAN’s coverage area. When the MN usesFMIPv6, the average transmission delay is about 104 ms.The end-to-end delay is the accumulation of transmissionprocessing and queuing delays in the routers, propagationdelays, and end-system processing delays along the source-destination path. In FMIPv6, additional end-to-end deliv-ery delay is introduced by signal strength degradation ofthe MN connection when it moves away from its old accesspoint. This signal strength degradation causes successive802.11 MAC retransmission of packets before their correctreception. Those successive retransmissions are partlyresponsible for the additional average packet delivery

Table 5Simulation input data end-to-end BANC vs FMIPv6 delay experiments

Packet size Interval rate Mobile node speed (m/s) Application type

200 bytes 20 ms 1 UDP (voice)8

Fig. 6. BANC vs FMIPv6: typical end-to-end delays for 1 m/s MN speed.

Fig. 7. BANC vs FMIPv6: a typical sample of end-to-end delays for 8 m/sMN speed.

Table 6End-to-end delay simulation output statistics: 1 m/s vs 8 m/s

Mean (ms) SD (ms) Con

90%

MN speed (1 m/s)BANC 99 6 97.5FMIPv6 102 7 100.

MN speed (8 m/s)BANC 105 7 103.MIPv6 113 7 111.


delays in FMIPv6. In BANC, handover triggers withinMN when the current signal quality falls below a giventhreshold, contrary to protocols such as FMIPv6, that relyon specific link-layer triggers. Indeed, the drivers of theusual WLAN cards directly provide signal quality indica-tors and BANC server leverages this MN-provided signalquality level in the HO indication message. The pre-hand-off tunneling is also partly responsible for these increaseddelays in FMIPv6, where before the completion of thebinding update, packets destined to the MN are sent to pre-vious access router and then are directed back to the Inter-net, in order to be routed to the MN’s current location.This extra path adds extra delays.

Note that FMIPv6 aims at optimizing handover latencyby allowing the MN to acquire its new IP address before re-associating to the new IP subnet, but it does not guaranteefast and successful handoff. The fact is that, handoff inFMIPv6 is not complete, until the MN receives theresponse of the BU message from the CN; this responsemessage has to travel through the Internet which load israndom and uncontrolled. The more the delay in receivingthe BU response, the more the tunneling duration, hencethe longer the transmission delay period for the redirectedtraffic. The delay experienced by the redirected traffic isproportional to the path between the old attachment pointand the new one via Internet.

In the proposed network-assisted alternative BANC,fewer messages are needed to be transported; the server isallowed to control the whole access network resource whileanticipating MN handovers, which reduces handover laten-cy and data loss. In our simulation, the handoff latency forthe BANC is about 101 ms while for the FMIPv6 is 115 ms(Table 4). In BANC, packets are being directly routed tothe MN’s new attachment under the control of the networkcontrol server. No tunneling is needed in this central net-work control mobility management alternative. Fig. 7shows end-to-end delay for 8 m/s MN speed. Comparedto 1 m/s, end-to-end delay in 8 m/s is slightly higher dueto more handoff, resulting in longer tunneling for the redi-rected traffic.

Though the FMIPv6 end-to-end delay is not that signif-icantly higher than the BANC’s, it is important to note thatthis will vary, depending on the Internet congestion. In net-work-assisted IP mobility, packets are directly sent to the

fidence interval

95% 99%

99–100.400 97.336–100.663 96.813–101.186366–103.633 100.059–103.940 99.449–104.550

366–106.633 103.059–106.940 102.450–107.550366–114.633 111.059–114.940 110.450–115.550


MN’s current location under the central network routingmechanism. As speed increases, delay in FMIPv6 will behigh and there will be more tunneling at the beginningphase of each handover.

For highly interactive audio applications, such as Inter-net phone, end-to-end delays less than 150 ms are not per-ceived by a human listener; delays between 150 ms and400 ms could be acceptable, but not ideal; delays exceeding400 ms can seriously hinder the interactivity in voice con-versations. If we refer to the maximum tolerable delayfor voice communications, FMIPv6 and BANC both canmeet the interactive voice communication requirements,as the values of end-to-end delays, as shown in the Table6, are within the acceptable range. However, dependingon the geographical distance of the CN from the MN’s cur-rent access router, this delay could vary for FMIPv6. Thiswould be more significant for public Internet, where thecongestion level is unpredictable.

Fig. 8. BANC vs FMIPv6: data dropped for 1 m/s MN speed.

Fig. 9. BANC vs FMIPv6: data dropped for 8 m/s MN speed.

4.3. UDP data drops

UDP data loss depends on Layers 2 and 3 handoff laten-cy. The network-assisted management gives less handoverdelay compared to FMIPv6, as the FMIPv6 solution estab-lishes more messages between the two access routers (com-municating via the unmanaged public Internet) involved inthe handover. In FMIPv6, though the MN is IP-capable onthe new link, it cannot use new care of address directly withits CN, until the binding of the CN and the new accesspoint is completed, i.e., when the handover phase is overpractically.

Table 7 has input information for the data loss experi-ments. Figs. 8 and 9 show the data dropped comparisonsof the two alternatives for 1 m/s and 8 m/s MN speed.Table 8 has the output statistics of these data droppedcomparisons experiments.

FMIPv6 experiences more data loss than BANC. This isbecause BANC has less signaling messages to transportcompared to FMIPv6; that reduces handoff latency andpacket loss. By looking at the trends in Figs. 8 and 9, thefollowing consideration can be made: The higher the speed,the more the handoff, and higher the data drop. The datadrop for 8 m/s speed is larger than in 1 m/s in both cases.With buffering, this loss in BANC can be totally removed.As mentioned before, BANC has less signaling messages totransport compared to FMIPv6, which reduces handofflatency and packet loss. Since the handoff latency inFMIPv6 (115 ms in our simulation) is larger than in net-

Table 7Simulation input data for loss experiments

Packet size Interval rate Mobile nodespeed (m/s)

Application type


work-assisted handoff latency (101 ms in our simulation),the drop is higher in FMIPv6 than in BANC. Note thatthe data drop rate difference between the two schemes isnot a significant one. WLAN air interface is also partlyresponsible for the loss in both schemes (we have intro-duced external interference through wireless jammer inthe simulation).

In scenarios where users generate small packets, e.g.,VoIP sources, the additional load in the wireless channelintroduced by FMIPv6 can result in worse performancethan BANC. Another factor that plays significant role indata drops is the higher signaling overhead in FMIPv6.Though FMIPv6 is designed to minimize packet loss and

Table 8Simulation output statistics data for loss experiments

Mean (bps) SD (bps) Confidence interval

90% 95% 99%

MN speed (1 m/s)BANC 10.9 8.8 8.846–12.953 8.460–13.339 7.693–14.106FMIPv6 13 10 10.666–15.333 10.227–15.772 9.356–16.643

MN speed (8 m/s)BANC 12 5.6 10.693–13.306 10.447–13.552 9.959–14.040FMIPv6 14 10 11.666–16.333 11.227–16.772 10.356–17.643


latency during handoff, the high signaling transactionsaffect the overall performance during high load conditionin the WLAN, resulting in reaching earlier a saturationlevel on the wireless channel.

On the other hand, in BANC the network server has theintelligence to control the entire access network and thetime that the actual handoff starts and finishes, whichreduces both handoff time and packet loss. The packet lossin BANC can be completely eliminated by buffering datapackets addressed to the MN. Other QoS techniques, suchas priority queuing, could be used both in the server and inthe attachment points to address the data drop issue inBANC.

Packet loss in BANC is lower in both 5 and 8 m/s MNspeeds because of BANC’s fast handoff; also, during thehandoff period, data packets are being directly routed toMN’s current WLAN.

Fig. 10. BANC vs FMIPv6: throughput with 1 m/s MN speed.
4.4. Throughput
Table 9 provides the input information for the through-put experiments. Figs. 10 and 11 show the throughputcomparisons for two examples for the cases of 1 and5 m/s MN speed (5 m/s MN speed is an arbitrary decision).Table 10 has the output statistics of these throughput com-parison experiments for BANC and FMIPv6.

BANC has higher throughput than the FMIPv6 as thepackets still have to be tunneled for a while until the bind-ing is compete after L2 and L3 through the Internet (wherethey can be subject to unexpected delay and loss), and thataffects the overall throughput.

MIPv6 provides a solution to the triangular routing ofMIPv4 (indirect routing from CN to MN) after handoffand binding, but it is not entirely tunnel-free. The enhancedMIP (HMIPv6 and FMIPv6) reduces binding update andhandoff latency and shows improved performance; howev-er, throughput-wise, it performs worse than BANC.

Table 9Simulation input data for throughput experiments

Packet size Interval rate Mobile node speed(m/s)

Application type


Fig. 11. BANC vs FMIPv6: throughput with 5 m/s MN speed.

FMIPv6 reduces binding update and handoff latency,and has improved performance. It still shows less through-put compared to proposed BANC network-assisted IP

Table 10Simulation output statistics for throughput experiments

Mean (bps) SD (bps) Confidence interval

90% 95% 99%

MN speed (1 m/s)BANC 743 14 739.7–746.2 739.1–746.8 737.8–748.1FMIPv6 717 16 713.2–720.7 712.5–721.4 711.1–722.8

MN speed (5 m/s)BANC 722 16 718.2–725.7 717.5–726.4 716.1–727.8MIPv6 690 25 684.1–695.8 683.06–696.9 680.8–699.1

Fig. 12. BANC vs FMIPv6: Layer 3 control message load.

Table 11Simulation input data for signaling overhead experiments

Packet size Interval rate Mobile node speed Application type

200 bytes 20 ms 8 m/s UDP (voice)


Mobility, as the tunneling continues at the beginning of thehandoff, until the MN completes its binding update with itsCN. In FMIPv6, setting up a tunnel alone before Layer 3handoff, does not ensure that the MN receives packets assoon as the MN attaches to a new subnet link, unless thenew access point can detect the MN’s presence. Eventhough handoff latency in FMIPv6 is improved comparedto MIPv6 and HMIPv6, packets still have to be tunneledfor a while until the binding is compete after Level 2 andLevel 3 through the Internet, where they can be subject tounexpected delay and loss, and that affects the overallthroughput. In addition, the throughput decreases as thepath delay increases, since the higher path delay restrictsthe amount of user traffic along the HA-FA path fromthe CN to the MN that is transferred in a given time inter-val. In the proposed network-assisted IP mobility in BANC,the server knows the target access point, therefore no bind-ing and no tunneling is involved. Packets are directly routedto the current access point which in turn sends to the MN.

As seen from Fig. 11, throughput decreases in bothalternatives as MN’s moving speed increases. The overallthroughput is going down partly because of the increaseof disconnection time over the full communication timeand also partly because of the corresponding increase inthe signaling load. The higher MN speed implies higherhandover rate; that results in higher disconnected time,during which no packet can be exchanged. With higherMN speeds, the handoff frequency is increased which caus-es throughput to be decreased. It also induces larger signal-ing overhead per unit time period. But the network-assistedalternative has still better throughput than FMIPv6. This isbecause of the fact that in FMIPv6, at the beginning of thehandoff duration, all the incoming packets are being tun-neled for a while until the binding is completed with theCN; the CN would send the traffic directly to the MN’scurrent location upon completion of the handoff and thebinding phase. In the network-assisted case, packets arenot tunneled at any point of time and handoff is faster.

4.5. Layer 3 control load over the air

Fig. 12 shows an example of the impact of Layer 3 controlload for 11 MNs with 8 m/s speed for BANC and FMIPv6.Table 11 has the input and Table 12 has the output statisticsof the Layer 3 control load comparison experiments.

BANC has lower signaling data during handoff than theFMIPv6, as BANC uses a small number of signaling mes-sages than MIPv6 during handoff.

Heavier signaling load is generated by FMIPv6 com-pared to BANC (Table 12), as FMIPv6 requires more sig-naling messages (Fig. 5) than BANC (Fig. 3) to completehandoff. This factor causes worse performance for FMIPv6in high load conditions. FMIPv6 may have shorter handofflatency and packet loss than MIP’s earlier version, but itcomes with extra signaling overhead cost which is detri-mental for a lower available bandwidth situation to main-tain desired QoS. This signaling overhead would also affectthe overall throughput as we have seen in throughput anal-ysis. This would cause extra load on the Internet and in theWLAN air interface, as the inter-WLAN signaling transac-tion has to happen via the Internet between the old andnew attachment points and the MN.

Table 12Simulation output statistics for signaling overhead experiments

Mean (ms) SD (ms) Confidence interval

90% 95% 99%

MN speed (1 m/s)BANC 329 57 315.6–342.3 313.1–344.8 308.2–349.7FMIPv6 615 110 589.3–640.6 584.5–645.4 574.9–655.0

Fig. 13. End user impact on CPU utilization with single MN, 3 MNs, 5MNs and 11 MNs on server utilization.


4.6. Server CPU utilization in BANC

As the network server is the main component in BANC,we have evaluated the impact of MN’s traffic load, serverpacket forwarding rate and datagram processing schemes(central vs slot-based processing) on the CPU utilization.That could assist BANC service provider’s capacity andtraffic planning strategy.

In real world, a service provider could do detail trafficengineering and capacity planning to maintain high QoSin order to be competitive, by adapting techniques suchas priority handoff queuing and load sharing. ProperQoS is the most important step in ensuring success of theservice. As seen from (1) in Section 3.3, an increase in thenumber of HO packets would cause the CPU utilizationgo up; this impact could be mitigated by proper scalingof the server, e.g., its number of CPU resources.

Table 13 has the input data used at the CPU utilizationexperiments for the BANC alternative. Table 14 has theoutput statistics for the end user impact. These experimentsconfirm that the number of MNs affect the CPU usage.

Fig. 13 shows the impact of 1 MN, 3 MNs, 5 MNs and11 MNs on the server utilization. As the number of MNsincreases, the server utilization also increases. By addingmore resources, the capacity of the GW can increase toachieve the desired QoS objective. In real-life implementa-tions, a service provider will need to assess the servercapacity based on the end user traffic (MNs) and the appli-cation type. This is one of the classical issues that all net-work service providers are well aware.

Packet forwarding speed plays important role in server’sutilization and overall capacity. Table 15 has the simula-tion output statistics of the packet forwarding impact

Table 13Simulation input data for cpu utilization experiments

Packet size Interval rate Mobile node number Application type

200 bytes 20 ms 1, 3, 5, 11 UDP (voice)

Table 14Simulation output statistics of end user traffic impact

Number of mobile nodes Mean % SD %

1 MN 1.5 0.443 MNs 1.6 0.485 MNs 1.8 0.611 MNs 2.7 0.9

experiment. Fig. 14 shows an example of the impact ofpacket forwarding scheme with 2500 packets/s, 5000 pack-ets/s and 8000 packets/s on the server utilization. The high-er the forwarding speed, the higher the CPU power and thiscontributes to higher throughput.

Depending on the traffic size and network growth pro-jection, a service provider can decide which scheme wouldbe viable, i.e., central or slot-based. Table 16 has the outputstatistics of the packet processing scheme impact experi-ment in BANC. With multiple servers ‘‘Slot-Based Process-ing’’ will deliver greater packet throughput.

Fig. 15 shows an example of the impact of slot-based vscentral processing on the server CPU. To obtain a definedCPU utilization, a service provider can plan for slot-basedfor high volume traffic with QoS. The server processingscheme attribute controls the number of servers (proces-

Confidence interval

90% 95% 99%

1.397–1.602 1.378–1.621 1.339–1.6601.487–1.712 1.466–1.733 1.425–1.7741.659–1.940 1.633–1.966 1.581–2.0182.489–2.910 2.450–2.949 2.372–3.027

Fig. 14. The impact of packet forwarding scheme with 2500, 5000 and8000 packets/s on the server utilization.

Fig. 15. The impact of slot-based vs central processing impact on serverCPU.

Table 15Simulation output statistics of packet forwarding speed impact

Packet forwarding speed (packets/s) Mean % SD Confidence interval

90% 95% 99%

2500 19.4 7.4 17.672–21.127 17.348–21.451 16.703–22.0965000 2.7 0.9 2.489–2.910 2.450–2.949 2.372–3.0278000 1.2 0.39 1.108–1.291 1.091–1.308 1.057–1.342


sors) and queues used by IP for packet forwarding. In cen-tral processing, a single server with a single queue is used toprocess all packets. In slot-based processing, in addition toa single central server (with its own queue) N additionalservers – each with a queue – are used to process packets.N is determined by the number of slots that have been con-figured. The ‘‘slot info’’ model attribute controls the num-ber of slots used by an IP process instance. With multipleservers, slot-based processing will deliver greater packetthroughput. The slot-based processing scheme would bebetter for QoS for high traffic. But it comes with extra costcompared to the central processing scheme. The serviceprovider can choose the appropriate scheme based on thecapacity and traffic volume to be supported.

5. Conclusions

In this paper, we proposed a handoff scheme, by modi-fying the enhanced IAPP messaging with central control.

Table 16Simulation output statistics of packet processing scheme impact

Processing scheme Mean % SD Con

90%

Central 1.7 0.9 1.48Slot-based 0.03 0.003 0.02

The proposed BANC handoff scheme achieves better hand-off latency than the enhanced IAPP. We then compared theperformance of the MIP’s enhanced version, FMIPv6, withthe proposed handoff scheme. The performance evaluationfor FMIPv6 and BANC, carried out by the OPNET simu-lation tools, led to the following conclusions:

BANC performs better than FMIPv6 for all the perfor-mance metrics used in IP mobility management compari-son: end-to-end delay, packet loss, throughput andsignaling overhead. The BANC IP mobility approach hascentral coordinated control on the handover and takesadvantage of the high-speed broadband access to employLayer 3 control messages, which contributes to lower hand-over latency and lower packet loss. In the BANC IP mobil-ity management scheme, the central server has a moreglobal view of the use of both radio and network resourcesfor all the attachment points and the MN. This networkarrangement facilitates controlling the target attachmentpoint selection in the network layer and has a large contri-bution towards efficient handoff. In BANC, no tunnelingand triangle routing occur; packets are directly routed to

fidence interval

95% 99%

99–1.9100 1.4504–1.9495 1.3720–2.0279929–0.03070 0.02916–0.03083 0.02891–0.03109


the final destination via the intelligent network server.From our experiments though we observed that bothFMIPv6 and BANC IP mobility schemes can meet theinteractive voice communication requirements, as the val-ues for end-to-end delay fall within an acceptable range.However, BANC has out-performed FMIPv6 in terms ofdelay and packet loss. Depending on the geographical dis-tance of the CN from the MN’s current access router, thisdelay could significantly vary for FMIPv6. This would bemore valid for an unmanaged environment, such as thepublic Internet, where the congestion level might be uncon-trolled. FMIPv6 uses more signaling messages than BANCin performing handoff and that results to higher end-to-enddelay and packet loss. In FMIPv6, each of the access pointsuses its buffers to forward the same packets to the newaccess point during handover. Triangle routing generatedin this packet forwarding from an old access point to anew one during handoff, causes extra delay and curtailedbandwidth utilization.

The experimental and simulation results here, obtainedfrom a complete simulation test platform, confirm the ben-efits of the BANC-central control solution proposed to theusers as well as to broadband service providers.

References

[1] F. Belghoul, Y. Moret, C. Bonnet, Performance comparison andanalysis on MIPv6, fast MIPv6 bi-casting and Eurecom IPv6 softhandover over IEEE802.11b WLANs, in: Vehicular TechnologyConference, vol. 5, No. 1, 2004, pp. 2672–2676.

[2] P. Bertin, K. Guillouard, J.-C. Rault, IP based network controlledhandover management in WLAN access networks, Communications7 (1) (2004) 3906–3910.

[3] J. Cao, Z. Liang, H. Chan, K. Sajal, Design and performanceevaluation of an improved mobile IP protocol, in: Twenty-thirdAnnual Joint Conference of the Computer and CommunicationsSocieties, IEEE INFOCOM, vol. 1, No. 1, 2004, pp. 319–329.

[4] Chun-Ting Chou, K.G. Shin, An enhanced inter-access pointprotocol for uniform intra and intersubnet handoffs, IEEE Transac-tions on Mobile Computing 4 (4) (2005) 321–334.

[5] E.H. Amre, Implementation options for the distribution systems inthe 802.11 wireless LAN infrastructure network, in: IEEE Interna-tional Conference, June 18–22, vol. 7, No. 1, 2000, 164–169.

[6] A. Hasson, N. Ventura, S. Shepstone, Mobile IP movement detectionoptimizations in 802.11 wireless LANs, in: 1st International Sympo-sium on Wireless Communication Systems, 2004, pp. 393–397.

[7] M.H. Habaebi, B.M. Ali, V. Prakesh, I. Vivaldi, Fast handoveralgorithm for hierarchical mobile IPv6 macro-mobility management,in: The 9th Asia-Pacific Conference on Communications, vol. 2, No.1, 2003, pp. 630–634.

[8] J. HeeYoung, K. SeokJoo, Fast handover support in hierarchicalmobile IPv6, in: The 6th International Conference on AdvancedCommunication Technology, vol. 2, No. 1, 2004, pp. 551–554.

[9] Y. Hong, M. Shin, H. Kim, Fast handover for mobile IPv6 usingaccess router based movement detection and CoA configuration, in:Vehicular Technology Conference, vol. 4, No. 1, 2004, pp. 2442–2446.

[10] IEEE 802.11f: Recommended Practice for Multi-vendor Access PointInteroperability via an Inter-Access Point Protocol Access Distribu-tion Systems Supporting IEEE 802.11 Operation, IEEE Standard802.11f/D1, January 2002 (draft).

[11] S. Jaiswal, S. Nandi, Simulation-based performance comparison ofTCP-variants over Mobile IPv6-based mobility management schemes,in: 29th Annual IEEE International Conference on Local ComputerNetworks, vol. 1, No. 1, 2004, pp. 284–291.

[12] Ha Won Kim, Sung Je Hong, J. Kim, Adaptive location managementscheme for mobile IP, in: Third IEEE International Conference on08–12 March on Pervasive Computing and Communications Work-shops, PerCom Workshops, 2005, pp. 263–267.

[13] M.S. Kim, S.H. Lee, G. Chun, M.S. Park, Optimized fast handover inmobile lpv6 network, in: Proceedings of the 7th InternationalConference on Telecommunications, ConTEL, vol. 1, No. 1, 2003,pp. 229–234.

[14] R. Koodli, Fast handovers for mobile IPv6, IETF Internet Draft,draft-ietf-mishop-fsat-mipv6-01.txt, February 2004.

[15] W. Ma, Y. Fang, Dynamic hierarchical mobility managementstrategy for mobile IP networks, IEEE Journal Selected Areas inCommunications 22 (4) (2004) 664–676.

[16] K. Maliki, Low latency handoffs in mobile IPv4, IETF Internet Draft,draft-ietf-mobileip-lowlatency-handoffs-v4-08.txt, January 2004.

[17] H.M. Ji, R. Srinivasan, Fast IP routing lookup with configurableprocessor and compressed routing table, in: IEEE Global Telecom-munications Conference, GLOBECOM, vol. 4, 2001, pp. 2373–2377.

[18] H. Moelard, M. Trompower, Inter Access Point Protocol (IAPP),Internet Draft Standard, 1998.

[19] K. Murakami, O. Haase, S. JaeSheung, P. La, Mobility managementalternatives for migration to mobile Internet session-based services,IEEE Journal on Selected Areas in Communications 22 (5) (2004)818–833.

[20] C. Perkins, IP mobility support, RFC 3220, January 2002.[21] C.E. Perkins, I.P. Mobile, IEEE Communications Magazine 40 (5)

(2002) 66–82.[22] OPNET Version 11.0, 2004.[23] C. Perkins, C. Johnson, Mobility support in IPv6, in: IETF Internet

draft, draft-ietf-mobileip-optim-24.txt, June 2003.[24] M. Rahman, F. Harmantzis, IP mobility with high speed access and

network intelligence, in: IEEE Wireless Communications and net-working Conference, WCNC, Atlanta, GA, March 21, 2004.

[25] R. Ramjee, K. Varadha, L. Salgarelli, S.R. Thuel, S.Y. Wang, L.Porta, HAWAII: a domain-based approach for supporting mobilityin wide-area wireless networks, IEEE/ACM Transactions on Net-working 10 (3) (2002) 396–410.

[26] R. Sangireddy, N. Futamura, S. Aluru, A.K. Somani, Scalable,memory efficient, high-speed IP lookup algorithms, IEEE/ACMTransactions on Networking 3 (4) (2005) 802–812.

[27] D. Saha, A. Mukherjee, I.S. Misra, M. Chakraborty, N. Subhash,Mobility support in IP: a survey of related protocols, IEEE Network18 (6) (2004) 34–40.

[28] H. Soliman et al., Hierarchical mobile IPv6 mobility management(HMIPv6), IETF Internet draft, drfat-ietf-mipshop-hmipv6-01.txt,February 2004.

[29] S.K. Sivagurunathan, J. Jones, M. Atiquzzaman, Fu Shaojian, Yong-Jin Lee, Experimental comparison of handoff performance of SIGMAand mobile IP, in: Workshop on High Performance Switching andRouting, May 12–14, 2005, pp. 643–652.

[30] S. Sharma, N. Zhu, T. Chiueh, Low-latency mobile IP handoff forinfrastructure-mode wireless LANs, IEEE Journal on Selected Areasin Communications 22 (4) (2004) 643–652.

[31] M. Torrent-Moreno, X. Perez-Costa, S.A Sallent-Ribes, Performancestudy of fast handovers for mobile IPv6, in: 28th Annual IEEEInternational Conference on Local Computer Networks, vol. 1, No.1, October 2003, pp. 89–98.

[32] W. Wu, N. Banerjee, K. Basu, S.K. Das, Network IP mobilitysupport in wireless LANs, in: Second IEEE International Symposiumon Network Computing and Applications, vol. 1, No. 1, 2003, pp.257–264.


Moshiur Rahman received his MS in Electricaland Computer Engineering from Wayne StateUniversity, MI, in 1985. He joined AT&T BellLabs, Napperville IL, at the switching divisionin 1987. He is currently a Senior TechnicalMember in AT&T Labs, Middletown, NJ,with the voice and data services division. Heis also pursuing his Ph.D. degree at StevensInstitute of Technology, Hoboken, NJ, inTelecommunications Management. Hisresearch areas of interest include mobility

management for voice and data, WLAN, broadband and signalingprotocols.

Dr. Fotios C. Harmantzis was born in Greece,where he completed his bachelor’s and master’sdegrees in Computer Science at the University ofCrete, in 1995 and 1997, respectively. He receivedthe M.S.E. degree from the University of Penn-sylvania, Philadelphia, in 1998, focusing onapplied mathematics. In September 1998, hejoined the Communications Research Group atthe University of Toronto, as a research fellowand instructor. He worked on stochastic model-ing, pricing and simulation in computer net-

works, towards his PhD degree in Electrical and Computer Engineering(graduated in November 2002). During his academic studies, Dr. Har-
mantzis held the Connaught Scholarship and the Ontario GraduateScholarship at the University of Toronto, a Teaching Fellowship at the
University of Pennsylvania and a Research Fellowship from the Foun-dation for Research and Technology-Hellas, for outstanding academicperformance and research contributions. His research activities are inmathematics and economics of computer networks and systems, as well asin mathematics of finance and risk. His teaching interests include com-puter networks, probability, stochastic processes and simulation modelingand analysis. Since September 2002, he is with the School of TechnologyManagement, Stevens Institute of Technology, as an Assistant Professor.

low-latency handoff inter-wlan ip mobility with broadband network control

Documents