Cellular universal IP for nested network mobility · Department of Information Engineering, The...

Computer Networks 51 (2007) 3617–3631

www.elsevier.com/locate/comnet

Cellular universal IP for nested network mobility

Patrick P. Lam *, Soung C. Liew, Jack Y.B. Lee

Department of Information Engineering, The Chinese University of Hong Kong, Room 825, Ho Sin Hang Engineering Building,

Sha Tin, N.T., Hong Kong

Received 22 May 2006; received in revised form 6 February 2007; accepted 1 March 2007Available online 23 March 2007

Responsible Editor: W. Wang

Abstract

In recent years, network mobility (NEMO) has been studied extensively due to its potential applications in military andpublic transportation. NEMO basic support protocol (NBSP), the current de facto NEMO standard based on mobile IPv6,can be readily deployed using the existing mobile IPv6 infrastructure. However, NBSP’s root in mobile IPv6, such as theneed of care-of address (CoA) and tunneling, results in substantial performance overhead, generally known as route sub-

optimality, in nested NEMO environments. This paper tackles this problem by proposing a scheme based on cellular uni-versal IP (CUIP) to eliminate the need for CoA and tunneling in supporting nested network mobility. Using quantitativeanalysis, we show that the proposed scheme outperforms the existing nested NEMO schemes by multiple folds in terms ofbandwidth overhead. We also show how IP fragmentation negatively impacts route optimality, and that the proposedscheme is inherently superior to the existing schemes in this regard. More importantly, while the scalability of the existingschemes generally deteriorates with the network size, the complexity of our proposed scheme is independent of the networksize and thus is far more scalable. Our results show that the proposed scheme is particularly suitable for nested NEMOnetworks formed by mobile routers with random and ad hoc movement patterns.� 2007 Elsevier B.V. All rights reserved.

Keywords: Network mobility; IP mobility; Mobile network; Mobile router; Cellular universal IP; Universal addressing; IP fragmentationin mobile networks; Ad hoc mobile network; Scalability of network mobility; NEMO

1. Introduction

Network mobility (NEMO) has been an activeresearch area in recent years because of its impor-tance in military and vehicular applications [1,2].

1389-1286/$ - see front matter � 2007 Elsevier B.V. All rights reserved

doi:10.1016/j.comnet.2007.03.002

* Corresponding author. Tel.: +852 97311033; fax: +852 36916410.

E-mail addresses: [email protected] (P.P. Lam), [email protected] (S.C. Liew), [email protected] (J.Y.B. Lee).

NEMO basic support protocol (NBSP) [3] is thecurrent de facto standard for NEMO which enablesthe local mobile nodes, visiting mobile nodes andlocal fixed nodes (they will be collectively referredto as mobile network nodes or MNNs hereinafter)within the coverage of a mobile router (MR) tomove together as a mobile network. It also allowsmany of these mobile networks, possibly from dif-ferent home networks of different prefixes, to joineach other in an ad hoc manner and form a nestedNEMO network.

.

mailto:[email protected]

mailto:soung @ie.cuhk.edu.hk

mailto:soung @ie.cuhk.edu.hk

mailto:[email protected]

3618 P.P. Lam et al. / Computer Networks 51 (2007) 3617–3631

The tradeoff for NBSP is the route sub-optimal-ity problem which substantially lowers the efficiencyof packet delivery in terms of bandwidth and datalatency [4]. The root cause of the route sub-optimal-ity problem is the need to acquire a new care-ofaddress (CoA) after one MR moves into the cover-age of another, which in turn requires a bi-direc-tional IP tunnel to be setup between the MR andits home agent (HAMR). This route sub-optimalityproblem worsens as the number of nesting levelgrows, because each additional level of nesting addsan additional layer of bi-directional tunneling,which incurs 40-byte IPv6 header overhead to everypacket traveling between the corresponding MR-HAMR pair. For packets with small payload, suchas the VoIP example given in [4], each layer of tun-neling occupies 16 kbps of bandwidth per channelwhereas the payload occupies only 8 kbps. In otherwords, in an N-level nested NEMO, there will beN*200% header overhead in each voice packet trav-eling through the already narrow wireless linkbetween the top-level MR (also known as theroot-MR) and the access router (AR) (see Fig. 1).

On the other hand, for packets with large pay-load the additional tunneling may cause unneces-sary packet fragmentations because the additionalheader may increase the size of a packet beyondthe network’s maximum transmission unit (MTU)size, resulting in extra packet delay and bandwidthconsumption. The fragmentation problem is espe-cially significant for nested NEMO because whena packet gets fragmented at, say, the jth level ofthe hierarchy (with the root-MR being at level 1),the packet will be fragmented again and again with

Fig. 1. Illustration of Route Sub-optimality.

probability one from level j � 1 all the way up tolevel 1. This fragmentation problem and its perfor-mance impact to nested NEMO will be further elab-orated in Section 6.

Fig. 1 illustrates another problem of routesub-optimality, namely, excessive route segmentsor pinball routing effect, in a three-level nestedNEMO. Suppose MR1, MR2 and MR3 from differ-ent home networks represented by home agentsHAMR1, HAMR2 and HAMR3, respectively, joineach other in an ad hoc manner and form the nestedNEMO as shown. Assume an MNN under the cov-erage of MR3 (i.e., the MNN belongs to MR3’smobile network) is involved in an ongoing sessionwith a correspondent node (CN) located outsidethe nested NEMO. Let us also assume that the bind-ing update at the home agent has been completed,and now the MNN simply sends an uplink datapacket to the CN. The packet must then traversethe following path before reaching the CN.

1. MNN!MR3: The MNN sends the packet toMR3 in the normal way with the CN as the des-tination and the MNN itself as the source in theIPv6 header.

2. MR3!MR2: MR3 encapsulates the packetwith its HA (HAMR3) as the destination and itsCoA as the source in the outer IPv6 header.

3. MR2!MR1: MR2 repeats step (2) and encap-sulates the packet with HAMR2 as the destinationand its CoA as the source in yet another outerIPv6 header.

4. MR1! AR: MR1 repeats the step similar to (3),and then forwards the packet to the fixed AR (orthe gateway). Note that the original piece of datais now encapsulated by four layers of IPv6 head-ers (including the IPv6 header originated fromthe MNN). The outermost layer now containsthe HAMR1 as the destination and MR1’s ownCoA as the source.

5. AR! HAMR1: After receiving the packet fromMR1, the AR simply forwards it to HAMR1

according to the destination address in the outer-most IPv6 header.

6. HAMR1! HAMR2: HAMR1 decapsulates theoutermost IPv6 header. The second layer ofIPv6 header now becomes the outermost one.The destination address of this layer is HAMR2

and, therefore, HAMR1 forwards it to HAMR2.7. HAMR2! HAMR3: Similar to step (6), HAMR2

decapsulates the outermost IPv6 header fromthe receiving packet. The third layer of IPv6

1 The terms mobile host (MH) and mobile network node(MNN) all refer to the mobile terminals such as laptops or mobilephones. They appear with different labels here to reflect thedifferent terminologies usually associated with their correspond-ing architectures – MH for traditional fixed line mobilitynetworks and MNN for NEMO.

P.P. Lam et al. / Computer Networks 51 (2007) 3617–3631 3619

header now becomes the outermost header. Thedestination address of this layer is HAMR3 and,therefore, HAMR2 forwards it to HAMR3.

8. HAMR3! CN: HAMR3 decapsulates the outer-most IPv6 header from the received packet. Thepacket finally turns back to its ‘‘original shape’’as it was sent out from the MNN. Thus, the des-tination address is now the CN’s address, andHAMR3 forwards the packet accordingly.

As bi-directional tunneling is used in NBSP, thedownlink packets sent from the CN to the MNNmust traverse the same path in reverse order. Thatis, the opposite of the above eight route segmentsmust be followed. Also, Fig. 1 only considers threelevels of nested NEMO on the MNN side. In gen-eral, 2(N + M) + 2 route segments will be traversedby a packet in a nested NEMO of N layers for theMNN side and a nested NEMO of M layers forthe CN side.

Ng et al. [4] showed that additional problems, suchas susceptibility to link failure and instability of net-work connection, are also indirect consequences ofroute sub-optimality. In this paper, we propose anew scheme for nested NEMO that is based on cellu-lar universal IP (CUIP) [5]. We show that CUIP’sunique universal addressing feature allows the pro-posed scheme to outperform other approaches byreducing the overall sub-optimality substantially.

Note that the term ‘‘route sub-optimality’’ is ageneral terminology used in the literature. In prac-tice, excessive routing (i.e., pinball effect) is onlypart of the ‘‘sub-optimality’’. Later on, we willquantitatively analyze route sub-optimality in termsof bandwidth overhead and also the impact ofpacket fragmentation.

Finally, to focus our discussions on networkmobility, we will only consider MR level mobilityin this paper. That is, through prefix aggregationat the MRs [3], all the MNNs underneath a partic-ular MR are assumed to be assigned with the net-work prefix of the MR and are moving togetherwith the MR as a mobile network. We will showin Section 7 that MNN level mobility can also besupported by the proposed scheme if the MNNsare also CUIP-enabled.

2. Related work

In recent years, numerous solutions have beenproposed to tackle route sub-optimality in NEMOnetworks. Many of them only focus on solid NEMO

structure (i.e., non-nested NEMO). Examples ofthese schemes include the optimized route cachemanagement protocol (ORC) [6] and the GlobalHA to HA protocol [7]. This section, however, dealswith schemes specifically for enhancing the nestedNEMO scenario.

2.1. HMIP based route optimization method

(HMIP-RO)

HMIP-RO [8] is largely based on the originalhierarchical mobile IP (HMIP) [9] scheme designedto enable micro-mobility of mobile hosts1 (MHs).HMIP-RO employs a mobility anchor point(MAP) introduced in [9] to handle the MR mobilityinside the nested NEMO. That is, as long as theMRs are moving within the MAP controllingdomain, the HAMR’s would not be aware of themovements. Hence, the handoff/roaming signalingoverhead beyond the MAP can be significantlyreduced. Also, the MAP is capable of encapsulat-ing/decapsulating multiple levels of the IP tunnelsformed within the nested NEMO. This enables theMAP to send and receive packets directly to andfrom the corresponding HAMR. The pinball routingeffect can therefore be reduced.

2.2. IPv6 reverse routing header (IPv6-RRH)

The basic idea of IPv6-RRH [10] is to performloose source routing for the nested NEMO. Thescheme first determines the number of upper-levelMRs along the path with the tree discovery algo-rithm [11]. The CoAs of all the MRs along the pathwill then be included in the ‘‘slots’’ of the reverserouting header (RRH) of the uplink (i.e., initiatedfrom the MNN) packets. When the correspondingHAMR receives the packets containing the reverserouting header, it analyzes the routing informationprovided, and then deduces the topology of thenested NEMO. In the downlink direction, afterreceiving or intercepting packets from the CN, theHAMR constructs the most efficient multi-hop rout-ing header for the packets addressed to the MNNbased on the previously deduced topology. With


IPv6-RRH, only one layer of bi-directional tunnel isneeded between the root-MR and the HAMR.

3. Two-tier addressing vs. universal addressing

NBSP, HMIP-RO, IPv6-RRH and virtually allexisting NEMO solutions are based on the two-tier

addressing model used by Mobile IPv6 [12]. Gener-ally speaking, under such an addressing model,while away from the home network (or homeNEMO network in our context), an MH (or MR/MNN in our context) is identified by its homeaddress, but is addressed by the CoA obtained fromthe foreign network (or foreign NEMO network inour context) it is visiting. The two-tier addressingmodel allows an MH to be reached globally. Themajor drawback of it is the requirement of theCoA acquisition in the foreign network to maintainthe connectivity to the global network. In additionto the excessive handoff delay involved in acquiringthe CoA [13,14], IP tunneling between the home andthe foreign networks is also an inevitable conse-quence of adapting to the CoA concept. Hence,from the illustration given in Fig. 1, it can be con-cluded that the two-tier addressing model is themajor cause of the route sub-optimality problemin the nested NEMO environment.

Another major class of two-tier addressingschemes is often known as identifier/locator split. Arepresentative example of this class of schemes isthe host identity protocol (HIP) [15]. In HIP, a hostidentity (HI) layer is inserted between the IP andTCP layers, so that the change of IP address (i.e.,the locator) is fully transparent to the upper layers.In other words, the upper layers always see the HIas the permanent identifier of the device and aretransparent to the device’s mobility. In addition,the HI is supposed to be a public crypto key of thedevice, and both the MH and the CN must be authen-ticated before a direct connection between them canbe made. Since CoA is not necessary, the need of IPtunneling is eliminated. However, aside from theexcessive handoff delay caused by the acquisition ofa new IP address through DHCP and two roundtripsof handshaking, HIP will inevitably face the phe-nomenon known as ‘‘binding storm’’ [10] when HIPis deployed in the NEMO environment. The reasonis the following. In HIP, one HI can only serve asthe identification of one device. As a result, unlikeprefix aggregation [3], an MR being identified by itsHI cannot serve as an ‘‘aggregated address’’ for theMNNs under its coverage. Each MNN must then ini-

tiate its own HIP exchange mechanism with its CNindependently whenever the MR changes its loca-tion. When the number of MNNs is considerablylarge, a ‘‘HIP exchange storm’’, effectively identicalto binding storm, will result.

In order to avoid the route sub-optimality andbinding storm problems, the universal addressingmodel, which is the model used in [5] to representa scheme that identifies and addresses an MH withthe same IP address globally, should be considered.However, the universal addressing model is gener-ally considered to be associated with the followingproblems.

1. The model is generally thought as not scalablebecause every router along the path from theCN toward an MH must contain the ‘‘full’’ routeentry of the MH and must perform ‘‘flat routing’’(i.e., routing based on the full route entry) glob-ally along the entire path. Note that it is impossi-ble to construct a hierarchical prefix routing (orroute aggregation) structure for the mobile hostsbecause the traditional concept of prefix is simplynot applicable to IP mobility. In other words, ifuniversal addressing is to be deployed for globalmobility, flat routing is needed globally, whichcould cause a significant scalability concern tothe global core network.

2. In the traditional IP architecture, ingress filteringof source IP address [16] is normally considereda standard way to defend the networks fromattacks initiated by bogus IP addresses. With uni-versal addressing, packets from a visiting MH willbe filtered out because they contain a different pre-fix in the source address than the visiting network.

The first problem has been solved by CUIP [5],which introduces an efficient and scalable way ofdeploying universal addressing. In this paper, weextend the scheme to the nested NEMO environ-ment and prove that the new scheme can eliminatethe route sub-optimality problem regardless of thenumber of nesting levels. In CUIP, an alternativesecurity scheme is proposed to replace ingress filter-ing, which could potentially be applied to NEMOnetworks as well. The full investigation of its appli-cability, however, is left as a future work.

4. Overview of cellular universal IP (CUIP)

CUIP [5] is an IP mobility scheme that effectivelyeliminates the major source of handoff delay in IP


mobility, namely CoA acquisition, and thereforeremoves the need for IP tunneling, even under glo-bal mobility. The major characteristics of CUIPare summarized as follows.

1. All MHs are addressed universally. That is, nomatter where an MH is located, it will alwaysbe addressed and identified by the same IPv6address globally.

2. With respect to a particular MH, all foreign wire-less access networks are viewed as partitions ofthe same hierarchy rooted at the top-level router(TLR) of the home network the MH belongs to.According to [17], the tier-1 routers are all inter-connected in a mesh manner, therefore a directLayer-3 connection between any two TLRs(presumably tier-1 routers of the domains) canbe assumed. As a result, a global hierarchy isformed and an inter-domain handoff can nowbe treated as a handoff within the same hierarchy.Fig. 2 illustrates this ‘‘self-centralized’’ globalhierarchy concept. The MH A is being handedoff from its home domain to a foreign domain.In CUIP, the foreign domain is logically viewedas a partition of the global hierarchy rooted byA’s home TLR. In other words, this inter-domainhandoff is now viewed as occurring within thesame logical hierarchy, which can be handledby CUIP without the need for CoA or tunnelingat all. On the other hand, with respect to the MHB, the global hierarchy will be different (i.e., itwill be rooted by B’s home TLR). Furthermore,it is important to note that, even for inter-domainhandoff, the signaling and routing between the

Fig. 2. The self-centralized global hierarchy formed between thehome and the foreign domains of A.

two involved wireless access networks are donethrough the direct Layer-3 connection. The corenetwork, as well as the legacy CN, are completelyunaware of the handoff and therefore are not nec-essary to support CUIP.

3. In a hierarchical network structure, all roaming/handoff scenarios must consist of exactly onecross-over router (COR) between the previousroute and the new route, where the COR isdefined as the router at the forking point of thetwo routes with respect to the MH. If the CORis on the home route, it is a home COR. Other-wise, it is a new COR (see Fig. 3). After roam-ing/handoff, only the routers on the new routeand the previous route, up to the COR of thisroaming/handoff (home or new), need to beupdated by CUIP. The roaming/handoff is there-fore transparent to the rest of the networkbeyond the COR, including the Internet and theCN.

4. In [5], a home route concept is introduced. Thehome route of an MH is defined to be the entireroute, extending from the TLR all the way downto a wireless access router (WAR), assigned tothe MH during subscription to mobile service.Based on the home route, a globally uniqueaddress, called universal address in [5], is derived.The routing along the home route is hierarchi-cally prefix based and is considered to beoptimal. When an MH is away from its homeroute, it is said to be on a foreign route, whichis defined as the part of the route in the hierarchythat deviates from the home route. The routingon the foreign route is flat based (i.e., full addressrouting) and is therefore considered to be ineffi-cient. However, this inefficiency can be mini-mized by assigning the home route to each MH

Fig. 3. Network architecture of CUIP.


intelligently so that the home route of an MHwill be the route under which the MH is most fre-quently used. For example, a home route may beassigned to an MH based on the user’s home/office location or the user’s recent mobility pat-tern. Thus, when an MH is at or nearby its homeroute, the majority of the route will be along thehome route, and therefore majority of the rout-ing will be efficient. As illustrated in Fig. 3, therouting of the routers above the home COR(R2) is prefix based (optimal routing) and forthe routers below the home COR is flat based(inefficient routing).

5. In [5], a hybrid prefix/flat routing table structuretailored for mobility, called mobility routing table

(MRT), is introduced. The main idea of theMRT is to use prefix routing whenever possible,and use flat routing otherwise. The basic opera-tion of the MRT is the following. First, packetsfor an MH are always routed to and along itshome route, and then the prefix of the MH islocated. If the MH is on the home route withrespect to this router (e.g., R1 in Fig. 3), thequery is completed and the packet is forwardedto the returned interface. Otherwise (e.g., R2,R3 and R4 because the MH is away from homew.r.t. these three routers), MRT looks for theMH’s full address inside the prefixed section (asection containing only the full addresses of thissame prefix). Thus, the ‘‘full address’’ lookup ofan MH is scalable because only the entries of thisprefix are queried. This routing table lookup canbe considered as ‘‘partial prefix lookup’’. Second,along the new route (e.g., R6 and R8), the querywould quickly fail for all the prefix entriesbecause the router is not on the MH’s homeroute. The query will then look up the MH’s fulladdress in the visitor section (a section containingonly the visiting MHs’ full addresses). Thislookup is also scalable because the full addressesinside the prefixed sections are all skipped. Inshort, MRT combines the efficiency of prefix-routing and the flexibility of flat-routing toprovide highly scalable universal addressing forglobal mobility.

In [5], two signaling schemes, namely cellular uni-versal handoff update (CUHU) and cellular univer-sal roaming update (CURU), are introduced tohandle handoff and roaming, respectively. In thispaper, the differentiation of handoff and roamingis not important, hence it is sufficient to highlight

the following common key points of these twoschemes.

1. The signaling schemes only need to update thenew and previous paths up to the COR of thehandoff.

2. At the COR, the CUIP specific option header willbe removed so that the outgoing packets will beseen as normal IPv6 packets beyond the COR.This ensures the complete compatibility withlegacy IPv6 devices on the Internet.

Fig. 3 briefly illustrates the routing operation inCUIP, in which the full entries inserted by the CUIPsignaling are indicated by the rectangular boxes.Assuming the home route of the MH of IP addressaaaa::1111:2222:3333 is the thicken black lineshown on the left of the figure (R1–R2–R3–R4).Therefore, the routers along this path contain thehome prefix of this MH. After a sequence of hand-offs, the MH is now attached to R8. After the routeupdate is completed, all routers along the newroute (R2–R6–R8) and the routers on the homeroute below R2 (e.g., R3 and R4) will be updatedby the CUIP signaling. With respect to routers onthe home route above R2 (e.g., R1), however, theMH is still ‘‘at home’’ and the routing is still prefixbased. Therefore, when packets are sent toward theMH from anywhere globally, they will be routed tothe home COR (R2), from there they will be routedalong the new route to the MH.

Finally, CUIP’s inherent hierarchical networkstructure allows CUIP to architecturally fit intonested NEMO networks because nested NEMO isalso hierarchical [18] by definition. In addition, asdiscussed in Section 1, the route sub-optimality isthe indirect consequence of adapting to the CoA.By contrast, CUIP’s universal addressing schemecompletely eliminates the need of CoA even for glo-bal mobility. This further suggests CUIP to be agood enabler of nested NEMO.

5. CUIP for nested NEMO

In the CUIP-enabled nested NEMO network(referred to as CUIP–NEMO hereinafter), weassume that all the MRs support CUIP both as arouter and as an MH. An MR behaves as a CUIProuter when it receives CUIP signaling from thedownlink (i.e., from some MRs underneath itself).On the other hand, an MR behaves as a CUIP hostwhen it is initiating the CUIP roaming/handoff


signaling mechanism by itself. The MNNs, however,are not required to support CUIP unless they willmove away from their designated MR’s coverageto become a visiting mobile node (VMN) of anotherMR. Again, we assume that all the MNNs movetogether with its designated MR and we will discussthe case of VMNs as a scenario by itself. Further-more, to simplify our discussions, we assume thatwhen an MR moves, all the lower-level MRs willmove together, or they will lose connectivity.Finally, each MR is assigned a globally uniqueIPv6 prefix (referred to as universal prefix hereinaf-ter) by an operator when the MR is first assigned toa nested NEMO as its home network. Conse-quently, this universal prefix also reflects the homeroute of the MR.

In the following subsections, we will show howCUIP–NEMO handles the common communica-tion scenarios involving nested NEMO. Note thatthe functionality of the top level router (TLR) usedin CUIP is replaced by the access router (AR) inorder to better match the terminology used in theNEMO literature.

5.1. Scenario #1: Communications within the same

nested NEMO and all MRs are along their

corresponding home route

Fig. 4 shows the simplest communication scenario– both the MNN and the CN are within the samenested NEMO and are on their corresponding homeroutes. In this case, the packets initiated from the CNwill be forwarded, according to normal routingmechanism, toward the home route of the MNNformed by MR1–MR2–MR3. Once the packetsreach the home route of the MNN (i.e., reaching

Fig. 4. Communications within the same nested NEMO.

MR1 in this case), they will be routed to the MNNaccordingly through prefix based routing. That is,the packets will be forwarded along CN!MR5!MR4!MR1!MR2!MR3!MNN. Note thatpackets from MR5 will not be routed to MR6because MR6 is not the upper-level MR of MR5.While the nested NEMO is formed, a tree structureis defined among all the MRs (the way to define thistree structure, however, is outside the scope of thispaper). That is, MR4 will be configured to be theupper level MR of MR5. Uplink packets routedthrough MR5 will then always be directed to MR4,but not MR6. On the other hand, the CN is also onits home route, packets from the MNN therefore willalso be directed to it with a similar routing mecha-nism in the reverse direction.

5.2. Scenario#2: Communications across different

mobile networks

Fig. 5 depicts a scenario in which MR2 changesits network location (through roaming/handoff)from its home NEMO to a foreign NEMO. Recall-ing that when an MR changes its network location,all the MRs and MNNs logically underneath itscoverage move along with it. For example, inFig. 5, all the entities below MR2’s coverage,including MR3 and the MNNs underneath MR3,move along with MR2. We will now see howMR2 and MR3 deal with the mobility with CUIP-NEMO.

In CUIP–NEMO, all the MRs underneath amoving MR are unaware of the movement. Inour example, the prefix entry of MR3 (i.e.,aaaa::1111:5555:6666:0/112) inside MR2 remains

Fig. 5. Roaming/handoff across two nested NEMOs.

Fig. 6. Communications through MRs from different networks.


unchanged after the movement of MR2. Therefore,nothing needs to be changed at MR3 and the MRsbelow it. (Note that the prefixes after the slash (e.g.,/80) used in the examples throughout this paper arearbitrarily chosen for illustration purpose. Theymay not reflect the real prefixes allocation in the reallife deployments.)

MR2, however, is the one that initiates the move-ment. Therefore, it will behave as a CUIP-basedhost during roaming/handoff. After roaming/hand-off, MR2 initiates the CUIP signaling procedureswith its universal prefix to update the upper-levelMRs in the hierarchy up to the COR. Note thatthe scenario depicted in Fig. 5 is an inter-domainmobility scenario. According to the original CUIP,the home AR will serve as the COR for this roam-ing/handoff. As a result, packets addressed to anMNN underneath MR3 will first be routed to itshome AR, and its home AR will direct them tothe appropriate foreign AR through the directLayer-3 connection between them (i.e., no tunnelingis needed), and from there the packets will be for-warded to MR3 accordingly. Note that the interface‘‘Int 1’’ used in the routing (i.e., entries inside therectangular boxes) is only a general interface forillustration purpose. In practice, this interface maybe an interface specific to the wireless technologybeing used (e.g., MAC address for 802.11).

5.3. Scenario #3: Communications in a nested

NEMO with MRs from different mobile networks

Fig. 6 shows a nested NEMO with the MRs allbelonging to different home networks. Let usassume MR1, MR2, MR3 and MR4 all belong todifferent nested NEMO networks represented bytheir corresponding home ARs, namely AR1,AR2, AR3 and AR4, respectively, and hence theyare all prefixed according to these ARs. TheseMRs then formed the nested NEMO shown inFig. 6 in an ad hoc manner. Assuming the routingtables inside all the routers (fixed or mobile) havealready been updated through the CURU/CUHUsignaling. The downlink packets to the MNN arefist routed to AR4, which is the home AR ofMR4, and AR4 will then redirect them to AR1directly, shortcutting AR2 and AR3. The uplinkpackets are routed directly toward the CN fromAR1. It is important to note that, although Fig. 6is effectively identical to the nested NEMO shownin Fig. 1, the pinball routing and tunneling over-heads have been eliminated.

5.4. Scenario #4: Communications of a visiting

mobile node

CUIP–NEMO is fully capable of supportingmobility at the host level, as long as the MNN isCUIP-enabled. Recall that a CUIP–NEMO enabledMR can act as a host as well as a router. Therefore,when a CUIP-enabled MNN underneath an MRsends a CUIP signaling messages to the MR, theMR will simply consider itself as a router and con-figure the MRT accordingly. Let us consider the sce-nario of a VMN shown in Fig. 7 Suppose an MNNis moving from its home nested NEMO network(Home NEMO), represented by the Home AR, toa foreign nested NEMO network (Foreign NEMO)represented by the Foreign AR, so that it is nowseen as a VMN at the Foreign NEMO. Since theMNN supports CUIP, as soon as it detects from,say, Layer-2 signaling, that it has moved to a For-eign NEMO, it will initiate the CURU/CUHUmechanism to update the mobility routing tableswith the its universal address along the new routein the Foreign NEMO. The Foreign NEMO, withCUIP–NEMO support assumed, will then followthe CURU/CUHU mechanism described in [5] tonotify the Home AR with the whereabouts of theMNN. After the CURU/CUHU mechanism iscompleted, all the packets addressed to the MNN

Fig. 8. A common nested NEMO architecture for performanceanalysis of different schemes.

Fig. 7. Support of visiting mobile node in CUIP–NEMO.


will first be routed to the Home AR, and the HomeAR will redirect them to the Foreign AR throughthe direct Layer-3 connection between the twoARs (again, no tunneling is needed), which will thenforward the packets to the MNN according to theroute entries configured by CURU/CUHU.

To conserve space, we will not discuss all possiblenested NEMO scenarios here. The four scenariosabove, however, have already covered the most fun-damental ones, and other scenarios can be derivedfrom them.

6. Quantitative analysis of nested NEMO schemes

We now quantitatively analyze the impact of tun-neling overhead towards the scalability of nestedNEMO. In a nested NEMO network, all the MRsare connected to its uplink and/or downlink coun-terparts wirelessly. Since these links are character-ized by low bandwidth and high loss rate, theoverall throughput can be very limited. This is espe-cially significant at the link between the root-MRand the AR (referred to as the ‘‘bottleneck link’’hereinafter), because every uplink and downlinkpacket of the nested NEMO network will passthrough this link. As a result, the bandwidth over-head induced by each nested NEMO scheme overthis bottleneck link can directly affect the scalabilityof each scheme.

It should be noted that all nested NEMOschemes share the same hierarchical architecture.This makes performance comparisons between theschemes relatively easy. Fig. 8 depicts such a generalnested NEMO structured with a hierarchy of Nlev-

els of MRs. MR1 is considered to be the root-MRof the hierarchy and is connected to the AR wire-lessly. Inside the core network, or the Internet, ifHA functionality is needed, there can be NHAMR’scorresponding to the NMRs along the path leadingto the MNN. The analysis will be based on commu-nications between an MNN under the coverage ofMRN and a CN in the core network. We will firstevaluate the bandwidth overhead for differentschemes without considering IP fragmentation.Then we will show how IP fragmentation negativelyimpacts the results obtained.

6.1. Bandwidth overhead at the bottleneck link

(fragmentation ignored)

Within the context of nested NEMO, bandwidthoverhead increases as the number of encapsulationsincreases. The bandwidth overhead at the bottle-neck link, with IP fragmentation ignored, can begenerally expressed in (1) for any particular nestedNEMO scheme X

XðX Þ ¼ KBCðX Þ; ð1Þ

where X(X) is the bandwidth overhead at the bottle-neck link generated by encapsulations per uplinkpacket sent by one MNN when scheme X is used,KB is the bandwidth occupied per layer of encapsu-lation, and C(X) is the the number of IPv6 headerencapsulations needed for the scheme X at thebottleneck link, including the ‘‘original’’ IPv6header constructed by the MNN, to transmit thedata from the MNN to the CN.

Fig. 10. An IP packet formatted by IPv6-RRH.


6.1.1. NEMO basic support protocol

In NBSP, one extra layer of encapsulation isadded as the packet sent from the MNN travelsone level up in the hierarchy until the packet leavesthe nested NEMO network through the root-MR.Recalling that the original IPv6 header is also con-sidered in C(NBSP), the number of encapsulationsat the bottleneck link for NBSP is N + 1. Thus,(1) becomes

XðNBSP Þ ¼ KBðN þ 1Þ: ð2Þ

6.1.2. HMIP based route optimization method

According to Fig. 9 of [8] (reproduced in Fig. 9with an N-level nesting configuration), C(HMIP �RO) is equal to N + 2. As a result, we obtain

XðHMIP � ROÞ ¼ KBðN þ 2Þ: ð3Þ

6.1.3. IPv6-reverse routing header

Instead of creating multiple levels of IPv6 tunnel-ing, IPv6-RRH embeds multiple ‘‘slots’’ into theIPv6 header to carry the CoAs of upper-level MRsalong with the packets. A slot occupies 16 bytes ofpacket size whereas a full header encapsulationoccupies 40 bytes (see Fig. 10). Therefore, a factorof 16/40, or 2/5, should be taken into account whendetermining the value of C(IPv6 � RRH). Ignoringthe four-byte fixed IPv6 extension field, and takinginto account the original header from the MNN,we have

XðIPv6� RRHÞ ¼ KB 1þ 2

5ðN þ 1Þ

� �: ð4Þ

6.1.4. CUIP for nested NEMO

In CUIP–NEMO, no encapsulation is needed.Therefore, C(CUIP � NEMO) is unity (accountingfor the original IPv6 header from the MNN), and so

XðCUIP � NEMOÞ ¼ KB: ð5Þ

Note that we have only considered the X(X) in theuplink direction in (2)–(5). Since X(X) is identicalin both the uplink and downlink directions, the totalbandwidth overhead at the bottleneck link for a du-

Fig. 9. An IP packet formatted with HMIPv6.

plex communication channel will be twice of whatwe have obtained here.

6.2. Bandwidth overhead at the bottleneck link

(fragmentation taken into account)

In the IPv6 standard [19], fragmentation of IPpackets are not allowed at the intermediate routers.Due to the need for tunneling in many occasions(e.g., mobile IPv6), however, the procedures speci-fied in [20] allow fragmentation/reassembly to bedone at the entrance/exit router of an IP tunnel.This is because tunneling increases the packet sizealong the data path, hence the packet size couldexceed the fragmentation threshold (i.e., theMTU) after tunneling is performed. Fragmentationwill then be needed. Thus, with schemes such asNBSP, HMIP-RO and IPv6-RRH, all the MRsand HAMR’s must be capable of fragmenting andreassembling IPv6 packets because they are theentrances as well as exits of the correspondingtunnels.

Let us again consider the general nested NEMOstructure shown in Fig. 8. Let Pj be the probabilityof a packet being fragmented the first time at level j

of the hierarchy, where 1 6 j 6 N and the root-MRis considered to be at level 1. Note that we only needto consider the probability of the first occurrence offragmentation because, in a nested NEMO, after apacket gets fragmented the first time at level j, thefragmentation will happen again and again to thepacket with probability one all the way up to level1 of the hierarchy. This is because, according tothe IP fragmentation mechanism given in [21], onlythe excessive part of the packet is fragmentedinto the second packet. For example, consider a par-ticular network with an MTU of 1500 bytes.Assume the source sends out a packet of theMTU size (e.g., to minimize the header overhead),if the router at the next hop needs to perform tun-neling, the packet must be fragmented into twosmaller packets of size 1448 bytes and 52 bytes (notethat the size of the fragments, except the last one,


must be divisible by eight [21]), respectively, at therouter. Including the 40-byte IPv6 header in bothfragments and the 8-byte IPv6 Fragment header inthe first one, an IP packet of size 1496 bytes andan IP packet of size 92 bytes will be transmitted tothe next router. For the nested NEMO schemes thatrequire tunneling, tunneling is performed again inthe next router (which is an MR). As a result, the1496-byte packet will have to be fragmented againand the process will repeat itself all the way up tothe root MR. However, the smaller fragments gen-erated along the path (they will be 48 bytes longwhen generated) will not be fragmented againwithin a reasonably sized nested NEMO (note thatthe MTU of an IPv6 network must be at least1280 bytes). In other words, a packet that gets frag-mented at level j will eventually turn into j + 1 frag-ments when it leaves the root-MR.

Let us see how fragmentation impacts the band-width overhead at the bottleneck link. Let Pu be theprobability that no fragmentation occurs across thenested NEMO for a particular packet, then we haveP u þ

PNj¼1P j ¼ 1. Suppose an MNN sends a packet

of arbitrary size into the nested NEMO network,and let Y be the number of fragments generatedfrom this packet at the bottleneck link. Obviously,when no fragmentation occurs, Y will be unity.Then we have

E½Y � ¼ P u þXN

j¼1

P jðjþ 1Þ: ð6Þ

Denote XF ðX Þ is the average bandwidth overhead atthe bottleneck link generated by encapsulations peruplink packet sent by an MNN when scheme X isused, with fragmentation taken into account.

After fragmentation, a packet sent by the MNN,on average, will turn into E[Y] packets at the egressport of the root-MR. Therefore, with the definitionof X(X) from the previous subsection, we have

XF ðX Þ ¼ XðX ÞE½Y �

¼ XðX Þ P u þXN

j¼1

P jðjþ 1Þ !

: ð7Þ

According to [22], the IP packet length distributionon the Internet can be assumed as follows.

PrfL ¼ 40 Bytesg ¼ 0:6;

PrfL ¼ 576 Bytesg ¼ 0:25;

PrfL ¼ 1500 Bytesg ¼ 0:15:

ð8Þ

Note that 1500 bytes is the maximum size a packetcan be, and is only determined by the MTU in thenetwork, it will not be affected by the size of IPheaders being used. Therefore, although this distri-bution only considers IPv4 traffic in [22], it is stillapplicable to our analysis here because we are onlyinterested in Pr{L = 1500 Bytes}here.

Let us assume that the MTU of the networkshown in Fig. 8 is 1500 bytes. From (8), 15% ofthe packets will get fragmented when the first layerof tunneling is applied (i.e., at level N of the hierar-chy). The rest of the packets (i.e., another 85%) willhardly be fragmented within a nested NEMO of areasonable depth, because Nneeds to be greater than23 for a packet of size 576 bytes to turn into apacket of size over 1500 bytes through encapsula-tions. Therefore, we can assume that in a nestedNEMO network with N 6 23,

P j ¼0:15; j ¼ N ;

0; j 6¼ N ;

�P u ¼ 0:85:

ð9Þ

Substituting (9) into (7), we obtain

XF ðX Þ ¼ XðX Þð0:85þ 0:15ðN þ 1ÞÞ: ð10Þ

Note that (10) is applicable to all the nestedNEMO schemes that require tunneling performedat the MRs, including NBSP, HMIP-RO andIPv6-RRH. From (10), we can see that, whenN = 2 (the most common nested NEMO configura-tion), a 15% probability of fragmentation canalready add 30% of bandwidth overhead to the bot-tleneck link when compared to the results obtainedwithout considering fragmentation.

CUIP–NEMO, on the other hand, does not needtunneling and therefore fragmentation will notoccur at all. As a result,

P j ¼ 0 8j;P u ¼ 1

and therefore,

XF ðCUIP Þ ¼ XðCUIP Þ: ð11Þ

In other words, CUIP–NEMO does not suffer fromthe above-mentioned fragmentation problem.

6.3. Implication of the results

Eqs. (2)–(5), (10) and (11) show that the band-width overhead at the bottleneck link, with or


without fragmentation considered, for all nestedNEMO schemes is dependent on the network size,N, except for CUIP–NEMO. This implies that,among all the existing nested NEMO schemes weknow of, CUIP–NEMO is the most scalable one.This is an important advantage because N couldincrease quickly when the mobile routers moveand form nested NEMO networks in an ad hocmanner. When the nesting structure is formed inan ad hoc and non-uniform manner, the nestedNEMO could be very unbalanced. Fig. 11 depictsan example of such an unbalanced nested NEMOnetwork formed by non-uniform ad hoc MR move-ments. With large N, the bandwidth overhead gen-erated by schemes like NBSP, HMIP-RO andIPv6-RRH will easily overload the bottleneck linkwhich will then cause excessive packet delay orpacket loss. The bandwidth overhead of CUIP-NEMO, on the other hand, is independent of N,and therefore is more suitable for highly mobilenested NEMO networking.

7. Other design considerations in CUIP for nested

NEMO

7.1. Routing table scalability of CUIP-NEMO

As discussed in the previous section, the band-width overhead at the bottleneck link of CUIP-NEMO is a constant regardless of the size of thenested NEMO network. Therefore, the scalabilityof CUIP-NEMO is a non-problem in terms of band-

Fig. 11. An unbalanced nested NEMO network.

width overhead. However, one may see that theCUIP–NEMO mechanism is to deal with thenetwork mobility problem through updatingthe routing tables inside the hierarchical networkarchitecture. Obviously, the efficiency of data deliv-ery and bandwidth consumption are achieved at theexpense of additional routing table operations (e.g.,lookup of additional route entries for visiting MRs(VMRs)). Since the overall routing table size in therouters is usually an important measure of thescalability of a network, we now discuss how adhoc network mobility impacts the routing table sizein a CUIP–NEMO enabled MR.

As discussed earlier, the hybrid prefix/flat MRTstructure used in CUIP can enhance the scalabilityof routing-table in fixed-line mobility networks. Itturns out that in nested CUIP-NEMO networks,prefix aggregation makes MRT even more scalable.We explain this in more detail as follows, withFig. 12 as illustration.

We can see from Figs. 5 and 6 that each VMRcreates one additional route entry in the MRs alongthe new route, including the COR. As a result, forany particular MR of a CUIP–NEMO network,the number of additional route entries created byad hoc network mobility therefore grows with thenumber of VMRs underneath it. However, due tothe effect of prefix aggregation, the additional routeentries inserted into an MR along the new routeunder concern are actually route prefixes of theVMRs beneath it, for which one entry of route pre-fix can represent tens or even hundreds of MNNsunderneath the VMRs. Furthermore, a VMR isassumed to move along with all the lower-levelMRs underneath it. This can be seen as a second tier

Fig. 12. Illustration of multi-tier aggregation effect.

Fig. 13. Illustration of legacy compatibility of CUIP–NEMO.


prefix aggregation for which one additional routeentry of the VMR actually represents multiplelower-level MRs underneath it. Fig. 12 illustratesthe effect of the multi-tier prefix aggregation. WhenMR2 moves into a foreign network rooted byFMR1, only the prefix entry of MR2 is added tothe routing table of FMR1 and Foreign AR. Sincethe route entry of MR2 (i.e., aabb:1111:2222:3333:4444:5555:0/96) is the prefix of all entities below it(i.e., including the MNNs underneath MR3 andMR4), packets addressed to any of these MNNscan be routed accordingly as long as FMR1 hasthe /96 prefix of MR2 in its routing table. Afterthese packets are routed to MR2 from FMR1,MR2 will route them based on the longer prefixappropriately. Therefore, one additional route entryin FMR1 already represents many MNNs fromanother network.

Generally speaking, this multi-tier route aggrega-tion is important to universal addressing schemes(i.e., CUIP–NEMO) because it allows one routeentry to be associated with many lower-level MRsand MNNs. Therefore, routing tables inside anyMR should just contain route entries for its ownMNNs and a number of entries for the lower-levelMRs, but not the MNNs underneath these lower-level MRs. With today’s advanced routing tech-nologies, the routing table scalability will hardlybe a major issue for a CUIP–NEMO network ofany size.

7.2. Backward compatibility of CUIP for NEMO

As mentioned in Section 3, the signaling androuting of CUIP do not involve the legacy routersor devices on the core Internet at all. CUIP–NEMOinherits this feature so that it is fully compatiblewith any legacy devices on the Internet. Conse-quently, the CNs can virtually be any legacy devices,including IPv4 devices or even devices behind net-work address translation (NAT) gateways.

On the other hand, under a CUIP–NEMO basedMR, the MNNs are not required to support ofCUIP or even IPv6 at all as long as they stay withinthe MR’s coverage and move along with the MR.When necessary, the MR may serve as a NAT gate-way for its MNNs, which allows the MNNs toaccess the Internet with the minimum network con-figuration (e.g., being DHCP capable). This, ofcourse, complies with the original purpose ofNEMO that is to allow devices with basic networkconfiguration to access the Internet while moving

along with its associated MR. Extending from theexample shown in Figs. 6 and 13 illustrates thelegacy compatibility of CUIP–NEMO by addingIPv4 NAT gateway support to MR4 and convert-ing the universal addresses of the MNNs to IPv4private addresses. Note that the CUIP–NEMOoperation for all the MRs still applies withoutmodification.

Furthermore, CUIP–NEMO is backward com-patible with NBSP. Assuming that a CUIP–NEMObased MR and the corresponding home AR are alsoNBSP capable. When the NBSP mode is enabled,the universal address will serve as the home addressand the home AR will serve as the home agent ofthe MR. For example, imagine that a CUIP–NEMO enabled MR moves into a foreign networkthat supports NBSP, but not CUIP–NEMO. Allthe CUIP signaling packets will be dropped by thenon-supporting routers, but the MR will thenreceive the periodic router advertisements [23] fromthis foreign network. The MR can switch to NBSPmode and begin the CoA acquisition, home agentbinding update (with its home AR) and other NBSPprocedures defined in [3].

8. Conclusion

Route sub-optimality has been a major prob-lem of nested NEMO deployment because of the


pinball routing effect and the excessive bandwidthconsumption involved in supporting ad hoc net-work mobility. This paper has proposed a newnested NEMO scheme based on CUIP. The majorcharacteristic of CUIP is universal addressingwhich completely eliminates the major causes ofroute sub-optimality – CoA acquisition and IPtunneling. Furthermore, CUIP is based on a hier-archical architecture, which is also how nestedNEMO is structured by definition. In thispaper, we have testified how the new scheme,namely CUIP–NEMO, eliminates the pinball rout-ing effect on the common nested NEMO scenar-ios. Also, we have quantitatively shown thatCUIP–NEMO outperforms the most popularexisting nested NEMO schemes in terms of thebandwidth overhead at the bottleneck link, whichreveals scalability of the various schemes. In addi-tion, we have further investigated the negativeimpact of IP fragmentation on scalability fornested NEMO. We showed that, with just twolayers of nesting, IP fragmentation already adds30% of bandwidth overhead, on top of tunneling,to the bottleneck link. CUIP–NEMO, however, isfree of IP fragmentation and therefore is immuneto its impact. The results therefore suggest thatCUIP–NEMO is a scalable scheme to enablenested NEMO networks which are usually formedby highly mobile MRs in ad hoc manner. Last butnot least, we have discussed the routing table sca-lability and backward compatibility concerns ofCUIP–NEMO.

Acknowledgment

This work was supported by the CompetitiveEarmarked Research Grant (Project Number414305) established under the University GrantCommittee of the Hong Kong Special Administra-tive Region, China.

References

[1] D. Stewart, W. Ivancic, T. Bell, B. Kachmar, D. Shell, K.Leung, Application of mobile router to military communi-cations, in: MILCOM 2001, IEEE, 2001.

[2] T. Lim, B. Lee, C. Yeo, A. Kassler, IPv6 network mobilityon ad hoc network for transportation systems, in: TNC2005,TERENA, June, 2005.

[3] V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert,Network mobility (NEMO) basic support protocol, in:IETF, RFC 3963, June, 2005.

[4] C. Ng, P. Thubert, M. Watari, F. Zhao, Network mobility routeoptimization problem statement, IETF, Internet Draft, draft-ietf-nemo-ro-problem-statement-03.txt, September, 2006.

[5] P. Lam, S. Liew, J. Lee, Cellular universal IP: a low delaymobility scheme based on universal IP addressing, in:MSWiM’05, ACM/IEEE, 2005.

[6] R. Wakikawa, S. Koshiba, K. Uehara, J. Murai, ORC:optimized route cache management protocol for networkmobility, in: Proc. of ICT2003, November, 2003.

[7] P. Thubert, R. Wakikawa, V. Devarapalli, Global HA toHA protocol, IETF, Internet Draft, draft-thubert-nemo-global-haha-00.txt, September, 2004.

[8] H. Ohnishi, K. Sakitani, T. Takagi, HMIP based routeoptimization method in a mobile network, IETF, Internetdraft, draft-ohnishi-nemo-ro-hmip-00.txt, October, 2003.

[9] H. Soliman, C. Castelluccia, K. El Malki, L. Bellier,Hierarchical mobile IPv6 mobility management (HMIPv6),IETF, RFC 4140, August, 2005.

[10] P. Thubert, M. Molteni, IPv6 Reverse routing header and itsapplication to mobile networks, IETF, Internet Draft, draft-thrbert-nemo-reverse-routing-header-06, September, 2006.

[11] P. Thubert, N. Montavont, Nested Nemo Tree Discovery,IETF, Internet Draft, draft-thubert-tree-discovery-03.txt,April, 2006.

[12] D. Johnson, C. Perkins, J. Arkko, Mobility support in IPv6,RFC 3375, IETF, June, 2004.

[13] N. Nakajima, A. Dutta, S. Das, H. Schulzrinne, Handoffdelay analysis and measurement for SIP based mobility inIPv6, in: IEEE ICC, May, 2003.

[14] J. Vatn, Long random wait times for getting a care-ofaddress are a danger to mobile multimedia, in: IEEEInternational Workshop on Mobile Multimedia Communi-cations (MoMuC’99), November, 1999.

[15] R. Moskowitz, P. Nikander, Host identity protocol (HIP)archtiecture, RFC 4423, IETF, May, 2006.

[16] P. Ferguson, D. Senie, Network ingress filtering: defeatingdenial of service attacks which employ IP source addressspoofing, RFC 2267, IETF, January, 1998.

[17] J. Kurose, K. Ross, Computer Networking: A Top-downApproach Featuring the Internet, second ed., Addison-Wesley, 2002 (Chapter 1).

[18] T. Ernst, H-Y. Lach, Network mobility support terminalogy,IETF, Internet Draft, draft-ietf-nemo-terminology-03, Feb-ruary, 2005.

[19] S. Deering, R. Hinden, Internet protocol, version 6 (IPv6)Specification, RFC 2460, IETF, December, 1998.

[20] A. Conta, S. Deering, Generic Packet Tunneling in IPv6Specification, RFC 2473, IETF, December, 1998.

[21] W.R. Stevens, TCP/IP Illustrated, vol. 1, Addison-Wesley,1994.

[22] A. Pattavina, Architecture and performance of opticalpacket switching nodes for IP networks, Journal of Light-wave Technology, IEEE (March) (2005).

[23] T. Narten, E. Nordmark, W. Simpson, Neighbor discov-ery for IP version 6 (IPv6), RFC 2461, IETF, December,1998.


Patrick P. Lam received the B.S. degreein electrical and computer engineeringfrom University of California, Irvine,USA, in 1994, M.ASc. degree in electri-cal engineering from University of Brit-ish Columbia, Vancouver, Canada, in1998, and is currently working towardthe Ph.D. degree at the Department ofInformation Engineering, at the ChineseUniversity of Hong Kong.

In 1996 and 1997, he was the electedvice president and president, respectively, of The Association ofChinese Graduates of UBC. From 1997 to 2004, he has worked in
several start-up technology companies in Vancouver, SiliconValley and Hong Kong. His research interests include internetprotocol (IP) mobility in wireless environment and signalingprotocols for multimedia applications.
Soung C. Liew received his S.B., S.M.,E.E., and Ph.D. degrees from the Mas-sachusetts Institute of Technology. From1984 to 1988, he was at the MIT Labo-ratory for Information and DecisionSystems, where he investigated Fiber-Optic Communications Networks. FromMarch 1988 to July 1993, Soung was atBellcore (now Telcordia), New Jersey,where he engaged in Broadband Net-work Research. Soung is currently Pro-

fessor and Chairman of the Department of InformationEngineering, the Chinese University of Hong Kong.

His current research interests include wireless networks,Internet protocols, multimedia communications, and packetswitch design. Recently, he and his student won the best paperawards in the 1st IEEE International Conference on Mobile

Ad-hoc and Sensor Systems (IEEE MASS 2004) the 4th IEEEInternational Workshop on Wireless Local Network (IEEEWLN 2004). Separately, TCP Veno, a version of TCP to improveits performance over wireless networks proposed by Soung andhis student, has been incorporated into a recent release of LinuxOS.

Besides academic activities, he is also active in the industry. Heco-founded two technology start-ups in Internet Software andhas been serving as consultant to many companies and industrialorganizations. He is currently consultant for the Hong KongApplied Science and Technology Research Institute (ASTRI),providing technical advice as well as helping to formulate R&Ddirections and strategies in the areas of Wireless Internetworking,Applications, and Services.

He is the holder of three U.S. patents and Fellow of IEE andHKIE. He is listed in Marquis Who’s Who in Science andEngineering. He is the recipient of the first Vice-ChancellorExemplary Teaching Award at the Chinese University of HongKong. Publications of Soung can be found in www.ie.cuhk.edu.hk/soung.

Jack Y.B. Lee (M ’95, SM ’03) receivedhis B.Eng. and Ph.D. in InformationEngineering from the Chinese Universityof Hong Kong in 1993 and 1997.respectively. He participated in theresearch and development of videostreaming systems from 1997 to 1998where he and his team developed novelparallel video server architectures forbuilding cost-effective, scalable andfault-tolerant video-on-demand systems.

This work had resulted in numerous publications, two USPatents, and the technologies are subsequently transferred to a
spin-off technology company for commercialization. He was afaculty member at the Department of Computer Science at theHong Kong University of Science and Technology from 1998 to1999, and in 1999 he joined the Department of InformationEngineering at the Chinese University of Hong Kong to establishthe Multimedia Communications Laboratory (http://www.mcl.ie.cuhk.edu.hk) to spearhead research in distributedmultimedia systems, peer-to-peer networks, multicast communi-cations, Internet protocols and applications.
http://www.ie.cuhk.edu.hk/soung

http://www.ie.cuhk.edu.hk/soung

http://www.mcl.ie.cuhk.edu.hk

http://www.mcl.ie.cuhk.edu.hk

Cellular universal IP for nested network mobility · Department of Information Engineering, The...

Documents

Transcript of Cellular universal IP for nested network mobility · Department of Information Engineering, The...