Ferretti, Ghini, Panzieri - 2015 - A Survey On Handover Management in Mobility Architectures

JID: COMPNW
ARTICLE IN PRESS [m3Gdc;November 27, 2015;16:34]
Computer Networks xxx (2015) xxx–xxx
Contents lists available at ScienceDirect
Computer Networks
journal homepage: www.elsevier.com/locate/comnet
A survey on handover management in mobility architectures

Q1 Stefano Ferretti∗, Vittorio Ghini, Fabio Panzieri
Department of Computer Science and Engineering, University of Bologna Mura Anteo Zamboni 7, 40127 Bologna, Italy
a r t i c l e i n f o a b s t r a c t
Article history: This work presents a comprehensive and structured taxonomy of available techniques for
Received 9 February 2015 managing the handover process in mobility architectures. Representative works from the ex-
Revised 14 October 2015
isting literature have been divided into appropriate categories, based on their ability to sup-
Accepted 5 November 2015
port horizontal handovers, vertical handovers and multihoming. We describe approaches de-
Available online xxx
signed to work on the current Internet (i.e. IPv4-based networks), as well as those that have
Keywords: been devised for the “future” Internet (e.g. IPv6-based networks and extensions). Quantita-
Mobility management tive measures and qualitative indicators are also presented and used to evaluate and compare
Handover the examined approaches. This critical review provides some valuable guidelines and sugges-
Mobile applications tions for designing and developing mobility architectures, including some practical expedients
Multi-homing (e.g. those required in the current Internet environment), aimed to cope with the presence of
Cross-layer protocols NAT/firewalls and to provide support to legacy systems and several communication protocols
working at the application layer.
© 2015 Elsevier B.V. All rights reserved.
1 1. Introduction employed to send data. If a WiFi network is available, the ter- 18

minal switches to WiFi; otherwise a cellular network is uti- 19
2 Over the last few years, several architectural solutions lized, if the latter is available too. During the handover, com- 20
3 have been proposed to support users that connect to the In- munications are interrupted. While the widespread use of 21
4 ternet through a Mobile Node (MN). The main objective is current smartphones confirms that in general such a simple 22
5 to provide seamless communications, i.e. ensuring that if a approach may be a viable solution, in some cases this strat- 23
6 MN changes its point of attachment to the Internet, while egy has some severe limitations. Just as an example (which is 24
7 in movement, no communication interruptions are perceived actually a true story), let us consider the case of a researcher 25
8 at the application level, and if such interruptions occur, they working in an university campus composed of several build- 26
9 do not significantly degrade the Quality of Service (QoS) de- ings, all covered by a WiFi network. He is a commuter and, 27
10 livered at the application level. While throughput remains a just before leaving to go home, he receives an important 28
11 major goal of system design, the main concern of mobility Voice over IP (VoIP) phone call. Since he is leaving to take 29
12 architectures is how to best manage situations where a MN the last train home, he decides to answer the call using his 30
13 changes network. This event is currently referred to as han- mobile phone; today, there are plenty of smartphone apps 31
14 dover (or handoff). that offer very efficient VoIP services. At that moment, the 32
15 By default, current operating systems installed on smart- device is connected through a WiFi network, but as he comes 33
16 phones adopt the following strategy for data transmission: out of the building, the WiFi signal is lost; thus, the smart- 34
17 one Network Interface Card (NIC) at a time is configured and phone automatically switches to 4G without any handover 35
management at the application level; this causes a first com- 36
∗ munication interruption. While moving, he passes through 37
Corresponding author. Tel.: +39 051 2094845.
E-mail addresses: s.ferretti@unibo.it (S. Ferretti), vittorio.ghini@unibo.it other buildings (hence, within their WiFi coverage); as a 38
(V. Ghini), fabio.panzieri@unibo.it (F. Panzieri). consequence, the smartphone switches back to WiFi (i.e. a 39
http://dx.doi.org/10.1016/j.comnet.2015.11.016
1389-1286/© 2015 Elsevier B.V. All rights reserved.
Please cite this article as: S. Ferretti et al., A survey on handover management in mobility architectures, Computer Networks
(2015), http://dx.doi.org/10.1016/j.comnet.2015.11.016
JID: COMPNW
2 S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx
40 second communication interruption occurs), and then back the main architectural solutions proposed in the literature, 101
41 to 4G (i.e. yet another communication interruption) and so and come up with a classification that arranges solutions 102
42 on. One might suggest that the employee should turn off the according to their design principles. We also discuss as- 103
43 WiFi NIC before leaving, thus using the cellular NIC only; yet, pects that have an impact on their deployment in real sce- 104
44 a full 3G/4G coverage may not be available in all the various narios and limit their applicability. It is worth mentioning 105
45 buildings he goes through. Indeed, when moving, there are that, while this paper was being written, new studies have 106
46 cases where one needs to change NIC without breaking the been published on the same topic, e.g. [22]. However, these 107
47 communication at the application layer. works mainly focus on the aforementioned future gener- 108
48 Handovers may actually require that a MN changes its ation Internet and on locator-identifier separation mecha- 109
49 connection from its current AP to another one (cell or WiFi nisms. Instead, our approach emphasizes multihoming, mo- 110
50 AP), thus causing a reconfiguration at the datalink layer of bility, the possibility of easily switching from one NIC to an- 111
51 the NIC in use (horizontal handover). However, the MN can other, the compatibility with the existing Internet and prob- 112
52 also change the network technology, switching from one NIC lems strictly concerned with the limitations of the current 113
53 to another, which causes a reconfiguration at higher network applications and the architectural solutions employed (e.g., 114
54 layers (vertical handover). Changing network means that the presence of NATs, firewalls, violations of the protocol strat- 115
55 IP address associated to the MN changes as well; this has ification). Moreover, in this paper we focus on host centric 116
56 repercussions on the application layer, since in the current networks, i.e. the traditional host-based conversation model 117
57 Internet, the IP address of a node usually plays the twofold that is exploited in the current Internet. Thus, we do not 118
58 role of MN locator and MN identifier. This “change of iden- consider neither information-centric networks [23] nor user- 119
59 tity” causes a service interruption that requires more time centric networks [24,25]. 120
60 than a simple network reconfiguration at the operating sys- The main contributions of this work are the following. 121
61 tem level.
1. We provide a comparative overview of the main ar- 122
62 Various proposals have been put forward to deal with
chitectural solutions for mobility support in wireless 123
63 this problem. Some approaches described in these proposals
networks. All the considered systems are classified 124
64 suggest a decoupling of the node identifier from its address
based on their main characteristics, offered features, 125
65 (locator), e.g. GLI-Split [1], HIP [2,3], Hi3 [4], ILNP [5], LISP
and based on the level of network protocol stack they 126
66 [6], MILSA [7], NIIA [8,9], RANGI [10]. These approaches usu-
operate. 127
67 ally comply with future Internet visions, requiring some rad-
2. We provide some valuable guidelines for developing 128
68 ical changes in the network architecture. Other approaches
mobility architectures in the current Internet, sum- 129
69 address the above mentioned “change of identity” issue by
marised as follows. Firstly, proxies used in many ap- 130
70 exploiting (and enhancing) protocols of the current Inter-
plications (VoIP, Session Initiation Protocol (SIP)-based 131
71 net stack, e.g. ABPS [11], DCCP [12], SIP-IAPP [13,14], I-TCP
applications, and optionally HTTP-based applications 132
72 [15], MMUSE [16], MPTCP [17,18], m-SCTP [19], MSOCKS [20],
[26]) should be upgraded/extended to cope with mo- 133
73 TCP-migrate [21]. These latter approaches can be classified
bility issues. Secondly, NATs and firewalls have to 134
74 based on their ability to support the use of a single NIC at a
be handled carefully. Thirdly, multihoming solutions 135
75 time, or the (possibly concurrent) use of multiple NICs. They
should take into account that many widespread ap- 136
76 may work at various levels in the network stack, or even use
plications and their related protocols (e.g. applications 137
77 a cross-layer strategy employing different functionalities at
based on (SIP)) do violate the layered structure of the 138
78 different levels.
Internet protocol stack. Solutions to this problem re- 139
79 The plethora of available proposals reveals that there are
quire the use of an external proxy and/or the modifi- 140
80 many technical issues concerned with the main problem of
cation of application messages. 141
81 mobility management, as well as different technologies that
3. We describe the main quantitative measures and qual- 142
82 need to be supported, and several alternative ways of solv-
itative indicators for evaluating mobility architecture, 143
83 ing these issues and using the technologies available. There
and classify all the presented approaches accordingly. 144
84 are solutions which are effective in principle, but that cannot
85 be deployed in practice because, for example, (i) the proto- The remainder of this paper is structured as follows. 145
86 cols they use do not comply with the current Internet im- Section 2 provides the background information and the ba- 146
87 plementation, (ii) they cannot deal with the presence of Net- sic definitions related to this topic. Section 3 presents the 147
88 work Address Translation (NATs)/firewalls, and (iii) they are existing architectural solutions working with single NICs, 148
89 not able to cope with problems introduced by those (popular) while Section 4 discusses solutions that exploit multiple 149
90 existing applications that do not respect the Internet protocol NICs. Section 5 gives a qualitative comparison of the host mo- 150
91 stack stratification. Thus, there is a significant need to iden- bility architectures discussed in the paper. Finally, Section 6 151
92 tify and state the main issues making up the whole problem, provides some concluding remarks and the main guidelines 152
93 and to classify the possible approaches for mobility manage- for developing mobility architectures. 153
94 ment. This paper illustrates these main issues, as well as ex-
95 periences and lessons learned from systems and proposals 2. Main definitions and concepts 154
96 available in the literature, and eventually provides a critical
97 discussion that might help practitioners in devising a holistic The aim of a host mobility architecture is to ensure that a 155
98 solution for mobility management support. MN can move seamlessly across different access networks, 156
99 In the rest of the paper, we give some background in- without any interruptions of the active network services. 157
100 formation on host mobility management services, review Before going into the details of such architectures, in this 158
JID: COMPNW
S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx 3
Fig. 1. Horizontal Handover: a MN changes access network using the same Fig. 2. Vertical Handover: a MN changes access network and the NIC used,
NIC, while moving. while moving.
159 section we need to introduce some concepts and terminology Soft handover 201
160 that will be used throughout the whole paper. Then, we will With a soft handover, the connection between the MN 202
161 describe how handover is executed when a MN changes its and its AP (base station) is retained until a connection is es- 203
162 AP within the same Internet Service Provider (ISP). We will tablished with another AP. This mechanism is also known as 204
163 also discuss how MNs are identified and localized in a net- “make before break”. In that way, the MN may be connected 205
164 work. We will clarify the notion of proxies and relays, which with two (or even more) APs at a given moment in time. 206
165 are useful distributed entities for supporting mobility. After
166 that, we will propose a classification of handover manage- Vertical handover 207
167 ment schemes to support mobility. From the discussion pro- Vertical handover occurs between points of attachment 208
168 vided, it will be clear that dealing with NATs and firewalls (for supporting different datalink-layer network technologies 209
169 systems working on the current Internet) is absolutely crucial (Fig. 2). The switch from WiFi to a cellular network, and vice 210
170 and that several implications arise from the use of session versa, are examples of vertical handovers. 211
171 and application layer protocols that cannot be ignored.
Multihoming 212
172 2.1. Definitions Today, a MN is equipped with multiple NICs (and corre- 213
sponding IP addresses). Multihoming refers to the possibility 214
173 Handover that a MN is connected simultaneously to more than one net- 215
174 Handover (or handoff) is the process of transferring a work (Fig. 3). 216
175 network communication when a mobile terminal changes Various sophisticated approaches exploit multihoming as 217
176 its connection point to the access network (called “point of a basic solution to increase reliability and offer seamless 218
177 attachment”). communications. Ideally, a seamless mobility architecture is 219
responsible for: 220
178 Seamless handover 1. identifying each given MN univocally; 221

179 A seamless handover occurs when the handover is per- 2. allowing each MN to communicate with its Correspon- 222
180 formed with no user perceivable interruptions, hence guar- dent Node (CN), (for the purposes of this discussion, a 223
181 anteeing that the user communication session remains CN might be a fixed or mobile node communicating 224
182 active. with the MN); 225
3. monitoring the QoS provided by different networks, 226
183 Horizontal handover predicting the need of a handover and selecting a new 227
184 A horizontal handover takes place between points of at- preferred NIC (and the related access point); 228
185 tachment supporting the same datalink-layer network tech- 4. performing the handover seamlessly, i.e. ensuring the 229
186 nology (Fig. 1). A user moving from one UMTS cell to another continuity of the communications without any per- 230
187 UMTS cell is an example of a horizontal handover. ceivable interruptions for the end users. 231
188 It is worth mentioning that there are different types of
189 horizontal handovers. For example, in cellular and WiMAX 2.2. Intra-ISP handovers 232
190 networks, the horizontal handover can be hard or soft.
This work focuses on systems that deal with the change 233
191 Hard handover of network domain, while moving. Thus, we examine mech- 234
192 A hard handover is (a horizontal handover) designed to anisms that allow the connectivity to be maintained when a 235
193 first break off the initial connection with an AP (base sta- MN changes its Internet Service Provider (ISP). Before going 236
194 tion), before switching to another one. Thus, the MN com- into the details of such systems, it is important to understand 237
195 municates with one AP at a time only. Connection with the how handovers are handled in current cellular networks and 238
196 old AP is broken before the new connection is established. WLANs, when a MN changes its AP within the same ISP. Re- 239
197 A hard handover is also referred to as “break before make” configurations take place at the physical and data link levels 240
198 handover, and it should result in a non-perceptible and short only, while the IP address of the MN remains unchanged. 241
199 interruption (i.e. even if it is a hard handover, it should be These mobility management schemes involve the same 242
200 seamless). NIC and the same carrier/network, i.e. they are horizontal 243
JID: COMPNW
Fig. 3. Multihoming: a MN has different active NICs available, ready to be used.
244 handovers. It is worth mentioning, however, that some works This is done to avoid packet losses, even between radio ac- 285
245 refer to the change between 3G and 4G as a vertical handover, cess systems such as LTE and 3G, which cannot be used 286
246 since, even though the MN employs the same NIC to commu- simultaneously. 287
247 nicate, there is a change in the type of connectivity used to
248 access a supporting infrastructure [27]. 2.2.2. WLANs 288
Here we focus on the horizontal handover performed 289
249 2.2.1. Cellular networks when a MN switches from an AP of a given WLAN to an- 290
250 A cellular network architecture consists of a set of base other AP of the same network, i.e. between APs using the 291
251 stations and a core network. The base stations are the APs same Service Set Identifier (SSID). The IEEE 802.11 does not 292
252 that provide radio access to MNs, whereas the core net- specify how to handover from one AP to another one. How- 293
253 work connects them to the wired Internet or the public ever, the IEEE released a recommendation called Inter-Access 294
254 telephone network. The core network has a very differ- Point Protocol (IAPP) [13], according to which the handover 295
255 ent structure depending on the type of cellular network. between different APs follows four steps: (i) when a MN finds 296
256 For example, 3G networks such as UMTS support both cir- an AP with a signal which is better than the one it is cur- 297
257 cuit switched services, used to carry traditional voice com- rently attached to, it breaks the connection with the cur- 298
258 munication, and packet switched services for data traffic. rent AP and sends a reconnection request to the target AP; 299
259 The new 4G Long-Term Evolution (LTE) networks, on the (ii) the target AP establishes a new connection with the MN 300
260 other hand, have been designed to offer packet switched and sends a notification to the current AP; (iii) on recep- 301
261 data services only. Voice services should be delivered as tion of this notification, the current AP transfers the MN in- 302
262 data flows over LTE (Voice over LTE – VoLTE). However, formation to the target AP; (iv) finally, the MN switches to 303
263 due to the high deployment cost and complexity of mak- the target AP. This is done transparently to the application, 304
264 ing such a transition, most 4G operators currently adopt and no changes are required at the end points (however, APs 305
265 Circuit-Switched Fallback (CSFB), which switches 4G users to must run an implementation of the IAPP protocol). It is worth 306
266 legacy 3G and accesses the circuit switched voice service in mentioning that this protocol has been extended to support 307
267 3G [27]. handovers in different subnets [28] and between different 308
268 A detailed description of the cellular communication ar- WLANs [14]; the latter solution relies on the use of the (SIP) 309
269 chitecture is out of the scope of this paper. In a few words, a protocol. 310
270 handover performed within the same ISP consists of an in- There are alternative (and in some cases proprietary) so- 311
271 teraction between the MN and the core network to select lutions to this approach, e.g. the Fast Secure Roaming of- 312
272 the base station employed to transmit and receive data. In fered by Cisco, and other scientific proposals such as [29– 313
273 UMTS, for instance, handovers are managed through the Uni- 31]. Amongst others, it is worth mentioning the IEEE 802.11r- 314
274 versal Terrestrial Radio Access Network (UTRAN), while LTE 2008, also called Fast Transition, which is an IEEE stan- 315
275 uses an Evolved UTRAN (EUTRAN), which simplifies the han- dard for performing a soft horizontal handover [32]. It is an 316
276 dover management, thus ensuring lower latencies for han- amendment of the IEEE 802.11 for fast roaming, where the 317
277 dovers and connection setup. initial handshake with the new AP is done before the MN 318
278 A different procedure is required when the MN switches roams to the target AP. IEEE 802.11r redefines the security key 319
279 between 3G and 4G. This procedure is divided into two parts, negotiation protocol executed when a MN decides to con- 320
280 i.e. preparation and execution. During the handover prepa- nect with a new AP. In essence, both the negotiation and 321
281 ration, resources are reserved in the target network. In the the request for wireless resources occur in parallel. This will 322
282 execution phase, the MN is handed over to the target net- remove much of the handshaking overhead while roaming, 323
283 work from the source network. Thus, only the network path thus reducing the handover time between APs while provid- 324
284 needs to be switched, reducing handover processing time. ing security and QoS. 325
JID: COMPNW
326 2.3. Node localization Proxy 380

It is a software entity that is in charge of routing 381
327 In IP-based communications, the MN’s IP address plays data/information towards a given host, typically in compli- 382
328 the twofold role of MN identifier and locator, as it distin- ance with an application level protocol. 383
329 guishes the MN uniquely and identifies its position in the
330 network. When a MN joins a network, it is assigned an IP 2.5. Mobility support and network layers 384
331 address that is valid within that network only. When that
332 MN moves to a different network, it acquires a new IP ad- The architectural solutions we will examine in the rest of 385
333 dress, thus losing its identity. Hence, it needs to inform CNs this survey are implemented at different levels of the ISO-OSI 386
334 of its new identity and location. In general, it is not possible reference model, as illustrated in Fig. 4. This figure illustrates 387
335 to exclude that a CN will move while communicating with the positioning of the considered systems, in the ISO-OSI ref- 388
336 the MN; for that reason, a mobility management architecture erence model, starting from the physical layer (see “PHY” in 389
337 must ensure that two hosts can communicate even when the bottom part of the figure), datalink layer (“DL”), network 390
338 they both move and change their addresses simultaneously. layer (“NET”), solutions between the network and transport 391
339 The above problem arises because the IP protocol and layers, solutions working at the transport (“TRAN”) and ses- 392
340 its related addressing scheme were originally developed for sion (“SESS”) layers. It is worth pointing out that the (brown) 393
341 wired (non-mobile) networks. A number of approaches ad- circles, placed in the physical and datalink layers in Fig. 4, 394
342 dress this problem by adding and/or modifying services at are not mobility management systems; rather, they are crite- 395
343 the network level. In particular, different solutions proposed ria/tools exploited to implement mobility management sys- 396
344 in the literature attempt to overcome the above problem by tems. Their description is provided in Section 2.6. 397
345 separating the node identifier from the node locator [6,7,33–
346 37]. The mobile node will therefore have a single identifier
347 that may change over time, regardless of its location. 2.5.1. Architecture classification 398
348 To summarize, all mobility management architectures The architectures reported in Fig. 4 can be classified de- 399
349 adopt some mechanism that: pending on where the localization service is deployed (in 400
Fig. 4, a shaded box groups all systems belonging to the same 401
350 1. defines a MN identifier uniquely, no matter what the class): 402
351 location of the MN is, and
• pure end-to-end solutions distribute the localization ser- 403
352 2. provides a localization service that maintains a map-
vice on both the end systems involved in a communica- 404
353 ping between the MN identifier and the current MN
tion (i.e., MN and CN); 405
354 location, even when the MN moves.
• home network-based solutions deploy the localization ser- 406
355 The localization service is based on a location registry, vice inside the home network to which the MN belongs; 407
356 a service that is assumed to always be available. When a • access network-based solutions (or border gateway-based 408
357 MN changes its IP address, it passes the information to the solutions) deploy the service inside a border gateway 409
358 registry, that is thus informed of the change (registration (placed at the edge of each network domain), which the 410
359 phase). When a CN wants to initiate a new communication MN exploits as its own access point to the Internet; 411
360 with the MN, or when it wants to continue a communication • hybrid end-to-end solutions manage the reconfiguration 412
361 with the MN that just changed its address, the CN starts a on both the end systems involved in the communication, 413
362 lookup phase, asking the location registry for the MN’s cur- but place the localization service in a separate server; 414
363 rent address, and then uses the obtained address to contact • external relay/proxy solutions integrate both the local- 415
364 the MN directly. ization service and the packet relay service at separate 416
365 This is the general principle employed by different archi- servers, which are independent from both the home and 417
366 tectures; it may be implemented within different network access networks. This allows the mobility management 418
367 entities and use very different algorithms and protocols. service to be deployed with no impact on the network 419
infrastructures, and overcomes the presence of firewalls 420
and NAT systems. 421
368 2.4. Presence of third distributed software entities
Another important classification relates to the granularity 422
369 With the aim of managing handovers and the different IP of the service, i.e. to the target (node, channel, packet) to be 423
370 addresses that a MN can obtain while moving, several archi- assigned to a selected NIC. (In Fig. 4, systems with the same 424
371 tectural solutions exploit some distributed software compo- level of granularity are grouped in the same column.) When 425
372 nents in charge of routing data between the MN and its CN. triggered, per-node solutions migrate every active flow by 426
373 In the literature, both the term relay and the term proxy are adopting a coarse-grained approach and exploiting one NIC 427
374 used to refer to these modules. For the sake of precision, we only, according to the requirements of the whole node. Con- 428
375 will use both terms, but not as synonyms, in order to empha- versely, per-channel solutions allow only one flow to be mi- 429
376 size a (maybe subtle but nevertheless important) difference. grated at a time (from one NIC to another) in a finer-grained 430
way compared to the previous approach; this enables each 431
flow to exploit its most suitable NIC. Finally, per-packet so- 432
377 Relay lutions route each single IP datagram through the most suit- 433
378 It is a software entity, which is mainly used to deal with able NIC, allowing fine-grained load-balancing and recovery 434
379 symmetric NATs or firewalls [38–40]. policies. 435
JID: COMPNW
Fig. 4. Mobility management architectures.
436 In the following sections, we shall examine these solu- Finally, the Transmission Error Detector (TED) is a soft- 467
437 tions individually, according to the ISO-OSI reference layer to ware tool that provides the MN with information about suc- 468
438 which they belong. We will make a distinction between the cessful (unsuccessful) datagram reception at the AP [11]. This 469
439 systems that focus on the use of a single NIC, and those that information can be delivered to software modules working 470
440 exploit multihoming and the simultaneous use of multiple at higher (i.e. application) layers of the protocol stack. In this 471
441 NICs to enable MNs to connect to the network. way, it is possible to devise cross-layer strategies for manag- 472
ing NICs and performing vertical handovers. 473
442 2.6. Tools and criteria for mobility management

2.7. Coping with NAT and firewall systems 474
443 As already mentioned, there are some criteria and tools
444 available at the physical and datalink layers that can be uti- Before going into the details of the systems available in 475
445 lized to implement mobility management schemes. This sub- the literature, we shall discuss the possible presence of fire- 476
446 section will give a brief outline of each of them. wall and NAT systems placed in between end-nodes involved 477
447 The Received Signal Strength Indicator (RSSI) is a mea- in a communication. This is a fundamental issue and one that 478
448 surement of the power level being received by the antenna is often ignored by many mobility management solutions. 479
449 of the NIC. Thus, the higher the RSSI the stronger the signal. Network Address Translators (NATs) are common devices 480
450 Signal strength is one of the main metrics a MN can use in or- that “hide” private networks behind public IP addresses. A 481
451 der to discriminate amongst different APs and select the best NAT device works by associating a public address and port 482
452 one to connect to. with a private destination address and port. In essence, the 483
453 Another important criterion is the number of frame re- host has a private (and local) transport identifier, which is 484
454 transmissions needed at the lower (Data-Link) layers to de- different from the one that is seen outside the private net- 485
455 liver a frame from the MN to its AP. Mobility management work. The NAT is responsible for translating the private ad- 486
456 systems can use this metric as a handover decision criterion. dress into the public address (for outgoing messages) and 487
457 802.21 is an IEEE standard for dealing with seamless vice versa (for incoming messages). As a consequence, hosts 488
458 handovers in heterogeneous networks. It has been devised within a private network behind a NAT are allowed to initiate 489
459 for supporting vertical handovers or, as called in the stan- a communication with a host outside the private network, 490
460 dard, Media Independent Handovers (MIH). It defines a set of but quite often the reverse is not possible. Indeed, the CN 491
461 handover-enabling functions to assist MNs during the han- may not know the public transport identifier (that can be cre- 492
462 dovers and handover decision making. Thus, these primi- ated in real-time by the NAT and change in time). Similarly, 493
463 tives offered at the operating system level can be exploited many firewalls allow connections to be initiated from the pri- 494
464 to build mobility management architectures. ODTONE is vate network only, with the effect that these nodes cannot be 495
465 an IEEE 802.21 implementation that is operating-system- contacted from other nodes outside the private network to 496
466 independent and open source [41]. initiate a new communication. 497
JID: COMPNW
498 This common practice represents an important limitation and it is used in several works, e.g. SIP-based approaches [42– 559
499 for the support of mobility. To cope with this possible situa- 46], ABPS [11]. As to other approaches, such as MIPv6-based 560
500 tion, the applications can resort to services offered by exter- approaches (see Section 3.1.1), the proxy in the figure repre- 561
501 nal Session Traversal Utilities for NATs (STUN) [38], Traversal sents the Home Agent (HA). 562
502 Using Relays around NAT (TURN) [39] and Interactive Con- As shown in Fig. 6, a MN and its CN can communicate di- 563
503 nectivity Establishment (ICE) [40] systems. These are proto- rectly when there is no NAT/firewall constraining the com- 564
504 cols that allow a host (a MN in our case) to learn its public munication (Fig. 6(a)). Then, the figure reports the impracti- 565
505 address, as it is seen outside the private network in which it cal case when the proxy is behind a symmetric NAT/firewall 566
506 is located. In this way, the MN can activate procedures that (Fig. 6(b)). In this case the MN and the CN cannot contact the 567
507 enable external hosts to contact it directly, e.g. it can expose proxy; as a result, no communications can be established. In- 568
508 its public address in some discovery service. serting a relay for the proxy might be a solution (Fig. 6(c)), 569
509 Unfortunately, the TURN, STUN, ICE protocols do not work but this would certainly be an unusual situation: if we install 570
510 correctly when both the end systems (MN and CN) are pro- a proxy in a network, we should be aware that this entity 571
511 tected by (the most common and restrictive) symmetric NATs must be reached by hosts outside the private network. Hence, 572
512 and firewalls. In this case, each connection of a MN with other the system designer must take this factor into account. 573
513 nodes is treated separately; moreover, a node does not have A more realistic scenario is when the MN connects to the 574
514 a bijective mapping between a local transport-layer address Internet via a private network, which is behind a NAT/firewall 575
515 and a public address. This represents a problem, since a typ- (Fig. 6(d)). In this case, the MN node can contact the proxy 576
516 ical approach in network programming is to have nodes that that would act as a relay if the CN asks to connect to the MN. 577
517 employ the same IP address, port transport address for es- The opposite occurs when the CN is behind a NAT/firewall 578
518 tablishing different transport-level communications (e.g., a (Fig. 6(e)). In this case, a relay is required to let the MN es- 579
519 node exposes its transport address IP address, port waiting tablish a communication. Indeed, the MN cannot connect to 580
520 for new connections). the CN directly, because of the NAT/firewall. The same occurs 581
521 However, the symmetric NAT/firewall maps every com- if a proxy is running for the MN. Moreover, the CN has to de- 582
522 munication that has the same internal IP address and port clare that a connection is possible through a relay, at a certain 583
523 number, locally at the MN, to a different external transport transport address. This is necessary, otherwise the MN is not 584
524 id. Thus, it is not possible to expose a IP address, port pair able to initiate a communication with the CN. However, it is 585
525 to all possible CNs, since only the CN that receives a packet important to point out that in the two last cases, the appli- 586
526 from a given external transport id representing the MN can cation must be aware that a relay node has to be contacted; 587
527 send a packet back. The problem is that if each end-system is thus, support at the application level is needed to enable the 588
528 behind a symmetric NAT, then each system cannot obtain an two nodes to interact. 589
529 address to connect to its remote correspondent, as the nec- Finally, a further case arises when both MN and CN are be- 590
530 essary external transport id of this correspondent has not yet hind a NAT/firewall (Fig. 6(f)); then, both end-systems must 591
531 been created by its relative NAT/firewall. employ a relay to allow their correspondent to contact it. 592
532 Basically, these restrictive firewalls require an intermedi-
533 ate application-layer relay server, outside any firewall and
2.8. Implications on the use of session and application 593
534 NAT systems, that receives and forwards the packet ex-
layer protocols 594
535 changed between the MN and its CN for the entire dura-
536 tion of the communication (see Fig. 5). The relay rewrites the
The considerations reported in the previous subsection 595
537 transport and network datagram header so as to appear as
suggest that, under certain circumstances, if we want to add 596
538 the peer node for both MN and CN. In some cases, it is even
mobility and multihoming to current Internet applications, 597
539 necessary to rewrite some data inserted into the payload at
some implementation tricks are needed at the session and 598
540 the application-level. For instance, SIP inserts information on
application layer protocols. (Hereinafter, we will refer to all 599
541 the end point, related to the network and transport levels,
protocols working over the transport layer as “application 600
542 within the application payload (e.g., the INVITE message con-
protocols”). There are in fact application-level protocols that 601
543 tains the IP address and port of the end-point). Thus, when
544 an end-point is behind a NAT, this information must be mod- 1. do not respect the protocol stack stratification. They 602
545 ified (we discuss this issue in Section 2.8). The problem is typically insert some network and transport layer data 603
546 that, as already mentioned, if the MN is behind a symmetric into the application payload. There are numerous ap- 604
547 NAT/firewall, the external IP address and port are assigned plications included in this group. For instance, all ap- 605
548 only when the application data transmission begins; thus, plications exploiting SIP have these characteristics; 606
549 the INVITE message cannot contain such information unless 2. respect the separation of roles of protocols in the net- 607
550 an external transport id is inserted (i.e. the one offered by the work stack. Thus, each application message implicitly 608
551 relay). exploits ports and IP addresses specified in the lower 609
552 Fig. 6 shows the possible cases that may arise during a level protocols. HTTP-based applications are examples 610
553 communication between a MN and its CN. The main conclu- of this type. 611
554 sion is that a relay node is needed if we want to guarantee
555 mobility support in any given case. In Fig. 6, the proxy repre- The presence of lower level data in the application pay- 612
556 sents the software entity which is in charge of managing the load (first case) represents a problem, firstly, when end- 613
557 MN mobility, provided that the system under consideration points are behind a NAT or firewall, and secondly, for building 614
558 uses such a software component. The name “proxy” is generic a mobility architecture that supports multihoming. Indeed, 615
JID: COMPNW
Fig. 5. The data relay allows the undirected communication between two nodes behind different firewalls or NAT systems.
Table 1 belongs. The HA plays the role of the location registry, and 649
Single NIC-based Architecture – Protocol Stack Level Classification.
routes datagrams towards the MN when this node is outside 650
Level Approaches its “home network”. In addition, if the MN wishes to register 651
its binding with a CN, so as to communicate directly with it, 652
Session SIP-IAPP [14]
Network MIPv6 [47], FMIP [48], HMIP [49], PMIP [50], GPMIP [51],
without the interposition of the HA, that MN must perform 653
[52], NEMO [53], LISP [6], ROAM [54] return routability operations [47]. In order to work properly, 654
MIPv6-based approaches need all the end-systems to have 655
IPv6 capabilities so as to insert some extension headers that 656
616 in the latter situation, there are multiple IP addresses (refer- transport both the MN’s identifier (the home address) and 657
617 ring to different NICs) to be managed at the network and at the current MN address into the IP datagrams. 658
618 the application layers. The CN might receive different appli- A clear limitation is that these architectural solutions only 659
619 cation messages from the MN through multiple IP addresses. work on infrastructures with IPv6 capabilities. Moreover, the 660
620 Mobility architectures need to cope with this issue. MIPv6 specification does not allow the simultaneous use of 661
621 There are basically two kinds of solutions, which will be the multiple MN NICs. For each given MN, the address of 662
622 presented in the next sections. One refers to the idea of a single NIC is registered at the HA. In addition, as demon- 663
623 separating the notion of “node identifier” from the “loca- strated in [55], the handover latency is very high due to the 664
624 tor” of that node. This type of solution is devised for the so numerous authentication messages, which causes a service 665
625 called “Future Internet”. Another type of solution requires disruption time that is not compatible with strongly interac- 666
626 a proxy. Examples of this second kind are ABPS [11] and tive services such as VoIP. 667
627 all MIPv6-based approaches [47], where the HA (which is
628 a proxy) is responsible for routing messages between the 3.1.2. NEMO 668
629 MN and its CN; hence, the CN sees the address of the HA Network mobility Basic Support Protocol (NEMO BSP or 669
630 only as its interlocutor. When applications exploit proxies al- simply NEMO) is concerned with managing the mobility of 670
631 ready (e.g. HTTP and SIP-based applications), this solution an entire network. NEMO aims at providing seamless Inter- 671
632 has a simpler implementation, since the proxy can be up- net connectivity of the whole mobile network that consists 672
633 graded to incorporate the functionalities needed to support of Mobile Routers (MRs) and MNs. The application scenario is 673
634 multihoming. public transportation, such as trains and buses [53]. The net- 674
work moves around as a whole, along with vehicles. NEMO 675
635 3. Single NIC-based architectures BSP is based on MIPv6 with minimal extensions. Therefore, 676
the handover mechanism of a MR is essentially the same as 677
636 This section focuses on architectural solutions based on that of MN in MIPv6. In NEMO BSP, a MR serves as a gateway; 678
637 the use of a single NIC to manage mobile communications. a permanent address called Home Address (HoA) is obtained 679
638 Table 1 summarizes all the techniques described below, clas- on the home link as an identifier of the MR. When the MR 680
639 sified according to the protocol layer they operate on. moves away, it acquires a Care of Address (CoA) from the ac- 681
cess router in the foreign network. MR sends a “binding up- 682
640 3.1. Solutions at the network layer date” message to its HA proxy located in the home network, 683
binding the CoA with the HoA. After the binding process, a 684
641 3.1.1. Mobile IPv6 bi-directional tunnel is established between the MR and the 685
642 Amongst the architectural solutions working at the net- HA proxy. Packets from the CN with the destination of MR’s 686
643 work layer, it is worth citing the efforts in the Mobile IP HoA are directly routed to the HA, and the HA is in charge 687
644 version 6 (MIPv6) [47] and its optimizations, e.g. the Fast of rerouting all packets to the CoA of the MR through a tun- 688
645 Handover Mobile IPv6 (FMIP) [48], Hierarchical Mobile IPv6 nel. MNs in the mobile network have permanent addresses 689
646 (HMIP) [49], Proxy Mobile IPv6 (PMIP) [50], GPMIP [51], and taken from the mobile network prefix advertised on the MR’s 690
647 [52]. All these approaches employ a Home Agent (HA), i.e. a ingress interface, and packets intended to or originated from 691
648 proxy working inside the access network to which the MN the MNs are encapsulated in the tunnel. 692
JID: COMPNW
Fig. 6. Presence of symmetric NATs/firewalls and need for a relay/proxy. The proxy refers to hosts that enable MNs to communicate while moving (e.g. the Home
Agent in MIPv6).
693 3.1.3. LISP maps the sender address (the location) to the sender ID, en- 703
694 Another noteworthy architecture that belongs to the capsulates these datagrams in LISP packets and routes them 704
695 border-gateway class is the Location/ID Separation Protocol through the LISP routers towards the destination. When a 705
696 (LISP) [6] proposed by Cisco. This is a first solution that pro- LISP packet reaches the ETR at the edge of the destination do- 706
697 duces the aforementioned separation between the identifier main, the ETR extracts the IP datagram from the LISP packet, 707
698 of a node, and its current location in the network. As depicted maps the destination ID to the destination locator and routes 708
699 in Fig. 7, LISP makes use of an overlay network of LISP routers, the IP datagram to the destination. In that way, LISP does not 709
700 located at the edge of the network domains and classified as require changes to the end systems. 710
701 Ingress Tunnel Router (ITR) and Egress Tunnel Router (ETR). The main drawback of LISP is shared with all other 711
702 The ITR intercepts the IP datagrams coming from the MNs, architectures that introduce functionalities at the edge of 712
JID: COMPNW
Fig. 7. The LISP architecture [6].
713 the network domains, i.e. they need all the domains to be 3.2. Solutions at the session layer 753
714 LISP enabled by deploying Ingress/Egress tunnel routers at
715 their edges. Indeed, this architecture needs all the paths When solutions are devised to let nodes communicate 754
716 between each MN and the Internet to flow through at through different networks, a key role might be played by 755
717 least a LISP-enabled border router. If a MN’s NIC connects session protocols that control the dialogue between end- 756
718 to a network domain that has no LISP-enabled router at points and incorporate functionalities used by the localiza- 757
719 its edge, the LISP architecture fails to provide network tion service. Today, Session Initiation Protocol (SIP) is the 758
720 continuity to the MN. Recent proposals have been pub- main protocol employed for controlling multimedia, multi- 759
721 lished that provide functionalities for NAT traversal for LISP homed communication sessions [42,45]. We now review its 760
722 MNs [56,57]. main characteristics. 761
723 3.1.4. ROAM 3.2.1. Session Initiation Protocol (SIP) 762

724 Some proposals at this level exploit the service provided SIP is a session-layer text protocol that uses a mes- 763
725 by Internet Indirection Infrastructure (i3) [58]. i3 builds a sage/response handshake for signaling purposes. In particu- 764
726 rendezvous-based communication abstraction. The system lar, it is used to establish or change communication param- 765
727 extends point-to-point communications by decoupling the eters such as IP addresses, protocol ports and audio/video 766
728 act of sending and the act of receiving messages. The main codecs between the end-systems. The SIP specification is ex- 767
729 aim is to provide an approach to ease the development of tensible and allows application-defined fields to be added to 768
730 multicast communications. the SIP messages. 769
731 In i3, a logical identifier is associated to each node. This The SIP messages worthy of mention here are REGISTER, 770
732 identifier can be mapped to the current IP address by means INVITE and re-INVITE. The REGISTER message allows a given 771
733 of an indirection point. In this way, when we want to send a node to declare that it is available for communications; it is 772
734 message to a CN, the message passes through an i3 server to usually sent to a SIP server that works as the localization ser- 773
735 locate the destination current address. vice. The INVITE message is used to establish a communica- 774
736 ROAM [54] exploits and extends i3 to support node mo- tion session between two nodes. Typically, this message is 775
737 bility. In substance, the indirection point is exploited to man- sent from the user to the SIP server that replies with the ad- 776
738 age handovers. A proxy-based solution is adopted to trans- dress of the other end node, together with some communica- 777
739 parently support unmodified applications on mobile nodes. tion parameters. Then, the two end nodes can communicate 778
740 Moreover, the use of an i3 server guarantees that communi- directly. A re-INVITE message may be used when communi- 779
741 cation is established also in the event of simultaneous han- cation parameters (such as the IP address) change. 780
742 dovers of the two mobile nodes. Another important aspect is that the SIP protocol allows 781
743 Support for legacy applications is guaranteed by the intro- the presence of SIP proxies, that can be transparent to the ap- 782
744 duction of a proxy. However, any application host is required plication (proxy agent) or can masquerade the end-systems 783
745 to have a related proxy. Hence, each server should deploy an (Back-to-Back (B2B) user agent) working as an opaque relay. 784
746 i3 proxy in order to communicate with the MN. This repre-
747 sents an obvious limitation for the deployability of the sys- 3.2.2. SIP and IAPP-based proposals 785
748 tem in the current Internet. A SIP-based mechanism that focuses on WiFi technolo- 786
749 Finally, it is worth pointing out that this solution needs gies has been proposed that extends the already mentioned 787
750 a non-negligible amount of additional information to be in- IAPP [14]. This approach (hereinafter called SIP-IAPP) pro- 788
751 serted into packets. Thus, header compression is needed to poses a cross-layer approach that modifies the IAPP to speed 789
752 reduce the packet header overhead. up the handover in WLANs. This allows direct forwarding of 790
JID: COMPNW
Table 2 This approach shares the same limitations as the other 831
Multihoming Architecture – Protocol Stack Level Classification.
MIPv6-based approaches: it needs the network infrastruc- 832
Level Approaches tures to be modified in order to add IPv6 capabilities. More- 833
over, the handover latency is very high, due to the large num- 834
Cross-Layer ABPS [11], CLW2A [26]
Session IHMAS [43], TMSP [59], [46], [44], MMUSE
ber of authentication messages. Finally, as mentioned for 835
[16] other IPv6 based strategies, this approach does not provide 836
Transport DCCP [12], m-SCTP [19], TCP-migrate [21], solutions for symmetric firewalls, and thus requires an exter- 837
MPTCP [17,18], MSOCKS [20], I-TCP [15], nal relay to be used. 838
ECCP [60]
Between Network HIP [2,3], Hi3 [4], LIN6 [61], MILSA [7], NIIA
and Transport [8,9], RANGI [10], Shim6 [36] 4.1.3. Separation between locator and identifier; ILNP 839
Network monami6 [62,63], FlowMob [64], GSE [65], A completely different scheme refers to the already men- 840
ILNP [5], GLI-Split [1], hidden proxy [66], tioned idea of modifying the Internet architecture to perform 841
UPMT [67], FRHP [68] the mapping between the identifier and the locator of a node. 842
One of the first proposals in this direction was the Global, 843
Site, and End-system address elements (GSE) [65]. A promi- 844
791 messages addressed to the MN, from an old AP to the new nent example of approaches devised to support mobile nodes 845
792 one, while the MN is still reconfiguring its SIP network is the Identifier Locator Network Protocol (ILNP), where the 846
793 setting. DNS and ICMP protocols are modified/updated in order to 847
794 This enhancement speeds up the SIP registration, increas- support the possible changes of the locator for a given identi- 848
795 ing the speed of the handover process as well. However, these fier [5]. The approach requires a novel implementation of the 849
796 approaches again require modifications in the infrastructure, network and transport layers at the nodes, while it is com- 850
797 and focus on a single networking technology. patible with the IPv6 backbone. 851
Basically, when a MN is moving between two distinct 852
798 4. Architectures that enable multihoming networks, it updates its locator record in the DNS. Thus, if 853
new sessions are established, they are established directly to 854
799 This section reports solutions that cope with han- the node’s current location. As regards active sessions, the 855
800 dovers by resorting to the possible use of multiple NICs. approach enables the MN to inform its CN directly of the 856
801 These schemes work at different levels of the network changes, using newly defined ICMP Locator update messages. 857
802 stack. Table 2 summarizes all the techniques described in This approach enables multihoming. Moreover, the pres- 858
803 this section, classified based on the protocol layer they ence of NATs does not represent a problem, provided 859
804 operate on. that applications employ identifiers only, and no locators, 860
which means that they employ some Application Program- 861
ming Interface (APIs) that do not exploit lower level infor- 862
805 4.1. Solutions at the network layer
mation (to be implemented in accordance with the new 863
protocols) [74]. 864
806 4.1.1. Monami6
Although simple and elegant, these solutions have been 865
807 An extension of MIPv6, called Multiple Care of Address
devised to work in future Internet scenarios. Thus, this type 866
808 registration (monami6) [62,63,69–71] has been proposed for
of approach requires modifications of the infrastructure and 867
809 supporting host mobility and multihoming. If a MN config-
its protocols. Moreover, updates of locators at the DNS are 868
810 ures several IPv6 global addresses on one or more of its NICs,
not instantaneous; in addition, given the amount of mo- 869
811 it can register these addresses with its HA as CoAs. This en-
bile nodes that are on the Internet nowadays, this solution 870
812 ables the HA to forward messages to the MN.
presents some scalability problems (that can be easily solved, 871
813 As for many other solutions, this extension does not over-
but which do have some cost). Hence, this approach may 872
814 come firewall and NAT systems, since according to IPv6 based
cause some service unavailability, when message updates are 873
815 approaches, with the advent of IPv6 there will be no need
lost and both end-points are mobile. 874
816 to employ NAT technologies anymore. In addition, the re-
817 turn routability operations cannot be easily extended to ver-
4.1.4. GLI-Split 875
818 ify multiple CoAs and, as usual, if the CN is protected by a
The “Global Locator - Local Locator - Identifier Split” (GLI- 876
819 firewall (or NAT system), the return routability operation fails
Split) is a system that adds a global mapping service to the 877
820 [72].
IPv6 architecture. Locators are distinguished between local 878
ones, employed for local routing within an edge network, and 879
821 4.1.2. FlowMob global ones [1]. The mapping system tracks changes for the 880
822 The Flow Mobility technique (FlowMob), described in locators, thus enabling mobility and multihoming. The archi- 881
823 [64], uses a multiple CoA to enable the MN to register its mul- tecture employs border routers at the edge networks that are 882
824 tiple IP addresses with its HA. This extension allows the MN in charge of modifying the address information (from local 883
825 to separate its outgoing traffic into different flows based on to global and vice versa) contained in packets traversing dif- 884
826 the protocols, port numbers and IP addresses, and forward ferent edge networks. The system has been designed to work 885
827 each given flow using a selected NIC. This technique allows with the existing IPv6 architectures. This solution shares the 886
828 a flow-based switching through the MN’s NICs. In [73], the same drawback mentioned for ILNP, i.e. when the two end- 887
829 problem of assigning traffic flows to available interfaces is points move simultaneously and direct updates get lost, a 888
830 optimized using a heuristic algorithm. service unavailability can occur. 889
JID: COMPNW
890 4.2. Solutions between the network and transport layers 4.2.3. Shim6 947
In Shim6, locators are IPv6 addresses, while an upper 948
891 Approaches have been presented in literature that insert layer identifier (which is described also as an IPv6 address) is 949
892 an intermediate layer between the network and transport employed to identify end points [36]. As in other approaches, 950
893 layers of the protocol stack. This layer works on all the end- a layer is added in between the network and transport lay- 951
894 nodes involved in the communication, i.e., MN and CN (in a ers. Communication between two end points is performed 952
895 one-to-one communication). Notable examples in this class through a 4-way handshake that allows nodes to determine 953
896 of solutions are the Host Identity Protocol (HIP) [2,3], Hi3 the locators and upper-level identifiers. To enable mobility, 954
897 [4], Location Independent Addressing for IPv6 (LIN6) [61,75], update messages are exploited to change the locators, as in 955
898 MILSA, [7] and Level 3 Multihoming Shim Protocol for IPv6 HIP. In case of outage, Shim6 performs an end-to-end explo- 956
899 (Shim6) [36]. Based on these solutions, the location registry ration of the available addresses using the Reachability Proto- 957
900 is a DNS-like mapping function that operates as a service out- col (REAP) [77], and then updates the locators. This approach 958
901 side the access networks and associates host identifiers to is not suitable for highly dynamic environments as it is re- 959
902 host locations. lated to timer expiration and not to movement detection. 960
903 A limitation of these approaches is the requirement to
904 modify the protocol stack in all the end-nodes involved in a 4.2.4. MILSA 961
905 communication. While it is reasonable to require that a MN MILSA employs the sublayer (added on top of the network 962
906 installs additional software to support its mobility, the CN layer) to map identifiers exploited at the application layer 963
907 can be a fixed node that may not be interested in support- with network-level locators [7]. Mobility and multihoming 964
908 ing the mobility of the MN. might be supported, since the mapper makes changes to the 965
MN’s locator which are transparent to the applications. How- 966
ever, some kind of global manager is required for node iden- 967
909 4.2.1. HIP, Hi3
tifiers. Moreover, no algorithm for the management of han- 968
910 In the Host Identity Protocol (HIP), IP addresses are lo-
dovers is specified. 969
911 cators used for packets forwarding only, while the concept
912 of host identity is employed as the identifier of a node
4.2.5. NIIA 970
913 [2,3]. The protocol introduces an “UPDATE” message that can
Node Identity Inter-networking Architecture (NIIA) em- 971
914 be sent by a MN making a handover to its CN. As men-
ploys a node identity layer between the network and trans- 972
915 tioned for other approaches, this mechanism fails when both
port layers that is exploited to perform routing [8,9]. The ar- 973
916 end points are mobile and perform a handover simultane-
chitecture defines two basic components: locator domains 974
917 ously. To overcome this limitation, a rendezvous server is ex-
and node identity routers. A locator domain is the abstrac- 975
918 ploited that can be queried to map identifiers to their related
tion of some kind of local network, having a consistent in- 976
919 locators.
ternal addressing and routing system. Node identity routers 977
920 The Host Identity Indirection Infrastructure (Hi3) is a net-
perform routing between nodes in different domains. Each 978
921 working architecture for mobile nodes, derived from the i3
node registers to one node identity router. Then, node iden- 979
922 and the Host Identity Protocol (HIP) [4,76]. The basic idea
tity routers are in charge of modifying the headers enter- 980
923 is to allow an IP-based communication while using an indi-
ing/leaving the local domain, changing the locators so that 981
924 rection infrastructure to route the HIP control messages. The
inter-domain routing is made possible. Moreover, they act 982
925 advantages of using i3 as a control plane for HIP in Hi3 in-
as proxies, hence enabling node mobility and multihoming. 983
926 clude protection from Denial of Service attacks, support for
When a node changes its local domain, a registration phase 984
927 simultaneous mobility, and providing an initial rendezvous
is executed, and the node identity router of the original local 985
928 service. However, in order for Hi3 to be effective, i3 proxies
domain of the MN is informed. Hereinafter, that router will 986
929 are required in the network.
act as a proxy for the MN. In the designed architecture, lo- 987
cal domains can be organized in a hierarchical manner. Thus, 988
930 4.2.2. RANGI inter-domain messages can pass through a sequence of local 989
931 Similarly to HIP, the Routing Architecture for the Next domains; this can introduce additional latencies. 990
932 Generation Internet (RANGI) separates location and identi-
933 fier, adopting an ID/Locator mapping system [10]. In RANGI 4.3. Solutions at the transport layer 991
934 host locators are ordinary IPv6 addresses and consist of two
935 parts: the first part represents the locator domain, such as As for previous approaches, the use of solutions working 992
936 the organization affiliation, while the second part is the lo- at the transport-layer may require modifications of the appli- 993
937 cal host identifier, which is represented as an IPv4 address cations on both the MN and CN to invoke the services offered 994
938 (included within the IPv6 address). The mapping system is by these solutions. An overview of the existing proposals 995
939 implemented as a distributed hash table. A node can have follows. 996
940 multiple locators at the same time with the same identifier
941 (i.e. the IPv4 address) thus enabling multihoming. In this last 4.3.1. MN as proactive location registry 997
942 case, border routers are responsible for modifying the loca- The common approach of the protocols working at the 998
943 tors, thus enabling multipath delivery strategies. As to mo- transport-layer, such as the datagram-oriented Datagram 999
944 bility, no detailed solutions have been proposed. Similarly to Congestion Control Protocol (DCCP) [12], the stream-oriented 1000
945 HIP, it is suggested that some update messages can be ex- Mobile Stream Control Transport Protocol (m-SCTP) [19], 1001
946 ploited to inform the CN of handovers or rehoming. the TCP enhancements TCP-migrate [21] and MultiPath TCP 1002
JID: COMPNW
1003 (MPTCP) [17,18], is as follows. Each given end-system plays the access networks, that maps a user identifier (e.g. vitto- 1060
1004 the role of a proactive location registry that directly informs rio.ghini@unibo.it) to the current user location (i.e. the IP ad- 1061
1005 the CN whenever its configuration changes. Unfortunately, dress of his/her MN). Each MN has a SIP user agent that sends 1062
1006 this approach may fail when both the end-systems are mo- REGISTER messages to the SIP server in order to update its 1063
1007 bile. Indeed, if they change their IP configuration simultane- current location. INVITE messages are sent to establish com- 1064
1008 ously, leaving their current network access point, they would munications with other nodes. 1065
1009 become mutually unreachable. The mentioned schemes sup- Similarly, [46] presents an architecture capable of man- 1066
1010 port multihoming. While DCCP was originally designed with- aging vertical handoffs, by using a SIP-based approach. The 1067
1011 out support for multihoming, some improvements have been scheme complies to the IP Multimedia Subsystem (IMS), a 1068
1012 proposed to add this feature [78]. standardized overlay architecture for session control, au- 1069
thentication, authorization and accountability in all-IP net- 1070
1013 4.3.2. MSOCKS, I-TCP works. Another related proposal is the one presented in [44] 1071
1014 MSOCKS uses an external proxy that performs TCP con- that only supports vertical handoffs from 3G networks to a 1072
1015 nection redirection [20]. Such an external proxy is employed WiFi network. 1073
1016 to split the end-to-end communication into two communi- Session-layer solutions might not be efficient as they in- 1074
1017 cations: namely MN-proxy and proxy-CN. This solution is re- voke an external localization service when an IP address re- 1075
1018 ferred to as TCP Splice. Hence, MSOCKS uses TCP Splice to configuration occurs. In particular, the SIP-based services in- 1076
1019 migrate a connection when the MN changes its IP address troduce an additional delay due to their message/response 1077
1020 (and potentially when it changes network interface). Since behavior; in case of reconfiguration, the MN interrupts the 1078
1021 the connection between its CN and the proxy remains un- communication, sends a SIP signaling message to the CN and 1079
1022 changed, the connection will not be interrupted and the CN waits for the response before resuming the transmission. 1080
1023 will not be aware of the mobility. TCP packets are modified With this in view, the IHMAS work presented in [43] min- 1081
1024 by the external proxy to create the illusion of a single, direct imizes handoff delays by exploiting a SIP-based, IMS com- 1082
1025 TCP connection between the end-points. pliant, proactive mechanism that performs registration and 1083
1026 Another example of this kind of approach is I-TCP, that renegotiation phases for new connections, while keeping 1084
1027 splits the communication into two paths, using an external the media flows active over old connections, if these are 1085
1028 relay to route messages [15]. available. 1086
1029 4.3.3. ECCP 4.4.2. Coping with NAT and firewall systems 1087
1030 The End-to-end Connection Control Protocol (ECCP) is an An example of a system that takes into account the pos- 1088
1031 end-to-end approach that modifies the transport protocol sible presence of firewall and NAT systems is MMUSE [16]. 1089
1032 into two sublayers, i.e. (i) a connection control, which man- This system requires an auxiliary SIP server (namely, the 1090
1033 ages connections, their constituent flows, and their associ- Session Border Controller, SBC) to be located at the edge of 1091
1034 ated addresses, and (ii) a data delivery functionality that is the autonomous system where the MN is entering. This au- 1092
1035 responsible for the typical management of the transport flow tonomous system may be composed of several subnets using 1093
1036 once a connection is established, like congestion control, flow heterogeneous network technologies. While the MN moves 1094
1037 control, reliability [60]. Thus, functionalities are introduced across the subnets, each subnet provides the MN with a dif- 1095
1038 so that once a node wants to change its NIC, it informs the ferent IP address. The SBC combines the functionalities of SIP 1096
1039 other node. During the communication, end-points can add and RTP proxies, firewall and NAT systems, and intercepts the 1097
1040 flows to an existing connection in order to spread traffic over communications that enter and leave the network, in partic- 1098
1041 multiple NICs. ular the SIP messages between the MN and its CN outside the 1099
1042 We mentioned that no end-to-end signaling protocol can, network edge. The SBC sets up the firewall rules that allow 1100
1043 by itself, handle the case when both hosts reconfigure or the subsequent SIP, RTP and RTCP communications between 1101
1044 change simultaneously the NIC in use. To sort out this prob- MN and CN based on the outgoing SIP messages. Moreover, 1102
1045 lem, the authors propose the use of a lightweight redirection when the MN moves to a different subnet and changes its IP 1103
1046 cache in the local network of either communicating hosts. address, the SBC modifies the outgoing datagram, in order to 1104
1047 This cache should keep short-lived redirection state pointing hide the current location of the MN from the CN. 1105
1048 to the new locations of hosts that have recently migrated out The main limitation of MMUSE is that the MN traffic al- 1106
1049 of its network. When a MN moves, it sends a message to the ways needs to flow through a given SBC that resides in the 1107
1050 redirection box of its old network to add a pointer to its new edge of the network. This implies that the MN may only move 1108
1051 location. This additional scheme requires the modification of inside a given autonomous system, but it cannot move across 1109
1052 the network infrastructure and violates the end-to-end phi- different networks administered by different organizations. 1110
1053 losophy of the protocol.
4.5. Zero impact on existing network infrastructures 1111
1054 4.4. Solutions at the session layer
To limit the need for modifying the network infrastruc- 1112
1055 4.4.1. SIP-based approaches ture, the external relay/proxy solutions deploy the local- 1113
1056 Several proposals exist that employ SIP to control the ization service at an external proxy, independent from both 1114
1057 session of a multi-homed communication. For instance, the home and access networks, with no impact on the net- 1115
1058 Terminal Mobility Support Protocol (TMSP) [59] exploits work infrastructures. This external proxy also incorporates 1116
1059 an auxiliary SIP server, as location registry placed outside the functionality of data relay to overcome NATs/firewalls. 1117
JID: COMPNW
Fig. 8. The ABPS-SIP/RTP architecture.
1118 This class of solutions requires some modifications to the (Fig. 8). In contrast with the previously presented ap- 1155
1119 MN. Moreover, it splits the communications in two consec- proaches, ABPS-SIP/RTP (or simply, ABPS) enables the trans- 1156
1120 utive paths, from the MN to the proxy and from the proxy mission of each datagram through the most appropriate NIC 1157
1121 to the CN (as in all other solutions employing an additional among those which are active at the MN. The ABPS-SIP/RTP 1158
1122 relay to overcome the presence of firewalls). architecture operates at the session-layer using a so called 1159
1123 The external relay/proxy class of host mobility solutions “proxy client” on the MN and an auxiliary “proxy server” in 1160
1124 may be divided into two sub-classes: the visible class sup- an external server, allowing the MN to move across differ- 1161
1125 ports only those applications and protocols (such as Web and ent autonomous systems. (The proxy acts as a relay as well, 1162
1126 VoIP) that define the concept of proxy. It operates using a pair thus overcoming problems due to the presence of NATs and 1163
1127 of explicit proxy software components, the one placed inside firewalls.) A cross-layer technique is employed to monitor all 1164
1128 the MN and the another on the relay/proxy external server. the concurrent NICs which are available, their performances 1165
1129 The application at the MN only needs to be configured to use and those that become active (or inactive); based on their 1166
1130 the proxy running on the local host. current status, an automatic reconfiguration is performed at 1167
1131 On the other hand, the invisible class groups those solu- the MN. This is accomplished by exploiting an implementa- 1168
1132 tions that operate as a tunnel between the MN and the ex- tion of the previously mentioned TED software module (see 1169
1133 ternal proxy; thus, applications running in the MN are not Section 2.6). 1170
1134 aware of these software entities. This sub-class does not de- This solution uses SIP-compliant proxy servers which in- 1171
1135 pend on the application, but handles IP datagrams in differ- teract with additional software modules, installed on the 1172
1136 ent ways, based on the transport protocols. Similarly to the proxies working between the network and the transport 1173
1137 visible class, local proxy (at the MN) and external proxy soft- layer; these modules are responsible for managing the 1174
1138 ware components are used. However, in this case, the appli- application-layer data flows, enabling their transmission 1175
1139 cation in the MN is unaware of the two proxies; in fact, the through different NICs. In practice, an ABPS proxy decides on 1176
1140 CN recognizes the external proxy server as its correspondent a per-packet basis which is the best NIC to use to transmit 1177
1141 node (i.e., the MN). the data. Moreover, each proxy adds a digital signature in the 1178
packet so that the proxy server may identify the sender, in 1179
1142 4.5.1. Visible relay/proxy services and early packet spite of its possible different IP addresses. The use of such a 1180
1143 loss detection signature technique transparently avoids the typical delays 1181
1144 These approaches exploit some additional software com- introduced by the two way message/response handshake of 1182
1145 ponents on the network that act as proxy and/or relay. Since the SIP signaling phase. 1183
1146 proxies need to manage application level data, these solu- It is important to note that all the approaches we intro- 1184
1147 tions are application-dependent. Thus, each system supports duced earlier usually consider the problem of changing a NIC 1185
1148 some specific application or, stated differently, each applica- in use as soon as it becomes unavailable. Thus, the decision 1186
1149 tion protocol requires a specific implementation of the proxy to change communication technology is not taken based on 1187
1150 that manages and routes application data. some particular QoS metric; rather, it is taken based on the 1188
1151 The highest-developed system within the visible relay failure of the currently adopted NIC. In contrast, ABPS takes 1189
1152 class is the Always Best Packet Switching (ABPS-SIP/RTP) into consideration QoS metrics to identify the best NIC to 1190
1153 architecture, designed to support applications based on use at any given moment. In particular, a cross-layer mech- 1191
1154 SIP/RTP such as VoIP and Video on Demand (VoD) [11] anism provides the applications with information about the 1192
JID: COMPNW
1193 successful (or unsuccessful) datagram transmissions through Universal Per-application Mobility management using Tun- 1252
1194 a given wireless access point. nels (UPMT), extends to the above mentioned hidden proxy 1253
1195 In essence, the advantages provided by the ABPS-SIP/RTP to provide support for UDP-based applications [67]. Both 1254
1196 system are the following: these architectures consider the problem of changing a NIC 1255
in use as soon as it becomes unavailable. 1256
1197 • it works perfectly over all IP based networks and does not
Actually, it is conceivable that some solution can be de- 1257
1198 require any modification of the current network infras-
vised that combines the use of an invisible external proxy 1258
1199 tructures;
with the features of early packet loss detection (in Fig. 4 1259
1200 • it is SIP compliant;
and in the following discussion we refer to such a kind of 1260
1201 • it avoids delays occurring in classic SIP-based approaches
approach as Fast Reactive Hidden Proxy – FRHP). While at 1261
1202 when the MN changes its preferred NIC or its con-
the time of writing, there are no available implementations 1262
1203 figuration. Indeed, in this case other schemes employ
of this strategy to support mobility management, this ap- 1263
1204 reconfiguration phases based on the exchange of INVITE
proach has been utilized in other contexts, such as vehicular 1264
1205 messages, while the ABPS-SIP/RTP approach avoids this
networks [68]. 1265
1206 additional message exchange;
1207 • it supports RTP-based applications such as VoIP and VoD
1208 services; 5. Comparison among host mobility architectures 1266
1209 • it can cope with vertical handoffs, without introducing
1210 any additional delay during the passage from the use of Tables 3–4 summarize the discussion presented in this 1267
1211 a NIC to the next one since, as soon as this becomes avail- paper by providing a concise comparison of the different 1268
1212 able, it is promptly configured to work; host mobility architectures we have presented. In both tables, 1269
1213 • it optimizes the use of NICs by deciding on a per-packet each column refers to one system (or more systems with sim- 1270
1214 basis which is the best interface to be used, based on the ilar properties). Systems are organized based on the classes 1271
1215 monitored performances of the available networks and identified in the previous sections. Thus, we have pure end- 1272
1216 on the employed QoS metrics; to-end systems, hybrid end-to-end systems, systems em- 1273
1217 • it overcomes the presence of NATs and firewalls. ploying some software entity placed within the MN’s home 1274
network, systems that modify the access network, those em- 1275
1218 The principal limitation of this solution is that the ABPS- ploying some invisible external relay and, finally, those em- 1276
1219 SIP/RTP architecture is strictly dedicated to SIP/RTP-based ploying a visible external relay. 1277
1220 applications and cannot be exploited for other applications. This qualitative comparison takes into account different 1278
1221 Another approach that exploits an external proxy-based criteria: Table 3 focuses on deployability, systems require- 1279
1222 distributed approach to support HTTP-based Web 2.0 ser- ments, and issues concerned with the need to modify the 1280
1223 vices has been presented in [26]. In Fig. 4 it is referred as applications, nodes or the network. Table 4 focuses on per- 1281
1224 CLW2A (Cross Layer architecture for Web 2.0 Applications). formance issues. Rows display the criteria or features that 1282
1225 These approaches are considered as working on a per- each solution may have. At a first glance, it can be observed 1283
1226 packet basis. Indeed, they work at a level of granularity that systems of the same class have similar properties. At 1284
1227 which is finer than channel flows. However, they do not de- the time of writing, there are no available real implementa- 1285
1228 cide which NIC to use for each packet, since they sched- tions for some approaches, whereas for others, the related 1286
1229 ule the NIC to use information that is available on top of papers/documentation do not provide enough details and 1287
1230 the transport layer. But they can easily switch from one NIC do not allow us to retrieve complete information on some 1288
1231 to another without wasting time in network and system performance parameters. Systems for which we do not have 1289
1232 reconfigurations. enough information are not ranked according to those spe- 1290
cific performance metrics, and are instead marked with an 1291
1233 4.5.2. Invisible relay/proxy services “U” (i.e., it is unclear how the system would work in certain 1292
1234 The visible relay/proxy service solutions are not suitable conditions). 1293
1235 for applications that are not designed to work with prox- Tables 3–4 are described in detail as follows. Table 3 is 1294
1236 ies, or more generally for legacy applications. To overcome structured in three principal subtables named “General”, “Re- 1295
1237 this limitation, the invisible relay/proxy service class oper- quirements” and “Need Modifications”. Table 4 is structured 1296
1238 ates transparently from the application standpoint by inter- in a single subtable labeled “Performance”. These subtables 1297
1239 cepting messages sent by the applications in the MN and are described below individually. 1298
1240 redirecting them to a local proxy. The local proxy delivers
1241 each message to the external relay/proxy using all the avail-
1242 able NICs of the MN. In the MN, a virtual Ethernet interface is 5.1. General 1299
1243 used (i.e. an Ethernet interface not linked to a physical one),

1244 and a particular routing table configuration causes the ap- This subtable of Table 3 contains two criteria, i.e., “deploy- 1300
1245 plications to bind their outgoing connections to that virtual ability” and “implementation”. 1301
1246 interface.
1247 The earliest representative of this class was the “hid- 5.1.1. Deployability 1302
1248 den proxy” [66], developed on Linux systems and based The deployability criterion ranks systems that can be ef- 1303
1249 on the iptables/netfilter mechanism and on the tun/tap vir- fectively deployed on the current Internet. This feature is 1304
1250 tual interface. This proxy was dedicated to TCP-based ap- derived from the characteristics analyzed in the rest of the 1305
1251 plications [66]. More recently, a similar architecture, called table. 1306
16
JID: COMPNW
Table 3
ARTICLE IN PRESS
Comparison among host mobility architectures: requirements and general issues on the deployability.
S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx

Classes Pure Hybrid Home Access Invisible Visible
E2E E2E Network Network Proxy Proxy
Criteria TCP-migrate DCCP [12] – HIP [2,3] – LIN6 MSOCKS [20] Shim6 TMSP [59], HIMA MIPv6 [80], Monami6 FlowMob SIP-IAPP LISP ILNP GLI-Split MILSA RANGI NIIA MMUSE ROAM Hidden UPMT FRHP ABPS [11]
[21] – MPTCP ECCP [60] – Hi3 [4] [61] – I-TCP [15] [36] [46], [44], [79] [48], [49], [63] – Nemo [64] [14] [6] [5] [1] [7] [10] [8,9] [16] [54] Proxy [66] [67] [68] – CLW2A
[17] m-SCTP [19] IHMAS [43] [50], [51], [53] [26]
[52]
General Deployability Y Y Y Y Y Y Y Y Y Y Y Y Y
Implementation Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
Requirements Requires IPv6 Y Y Y Y Y Y Y Y Y Y Y
Requires MIPv6 Y Y Y
Requires IPSec Y Y Y Y Y
Needs Protocol stack in Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
modifications MN
Protocol stack in Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
CN
Applications in Y Y Y Y Y Y Y
MN
Applications in CN Y Y Y Y Y Y Y
Access networks Y Y Y Y Y Y Y Y
Border gateways Y Y Y Y Y Y Y Y
Requires external Y Y Y Y Y Y
relay/proxy
Symbols – Y: yes.
[m3Gdc;November 27, 2015;16:34]

JID: COMPNW
Table 4
Comparison among host mobility architectures: performance.
Classes Pure Hybrid Home Access Invisible Visible
E2E E2E Network Network External Proxy Proxy
Criteria TCP-migrate DCCP [12] – HIP [2,3] – LIN6 MSOCKS [20] – Shim6 TMSP [59], HIMA MIPv6 [80], Monami6 FlowMob SIP-IAPP LISP ILNP GLI-Split MILSA RANGI NIIA MMUSE ROAM Hidden UPMT FRHP ABPS [11]
[21] – MPTCP ECCP [60] – Hi3 [4] [61] I-TCP [15] [36] [46], [44], [79] [48], [49], [63] – Nemo [64] [14] [6] [5] [1] [7] [10] [8,9] [16] [54] Proxy [66] [67] [68] – CLW2A
ARTICLE IN PRESS
[17] m-SCTP [19] IHMAS [43] [50], [51], [53] [26]
[52]
S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx

Performance Support to SIP/RTP Y Y Y Y Y Y Y Y Y Y Y E Y Y
Support to TCP Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
Support to UDP Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
Support to legacy Y Y Y Y Y Y Y E Y
App
Sender identification Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
Exploit Y Y Y Y Y Y Y Y E Y Y
simultaneously
multiple NICs
Granularity C C N N N N N N N N C N C N N N N N C N P P P P
Overcome FW and Y Y Y Y Y
NAT
Unavailability M M M M M M H H H H H L M M M U U U H M M M L L
interval
due to handover ∞ ∞ ∞ ∞ ∞ ∞
Continuity L L L L M L L L L H H L M M M U U U M M H H H H
interval
E2E L L L L M L L L L L L M M L U U U U M M M M M M
latency H H H H H H H H H H H
(best case) ξ ξ ξ
E2E latency with H H H H M H H H V V V M V U U U U U M M M M M M
symmetric FW H H H H H H H H H H H H
(common case)
Symbols – Y: yes; E: can be extended to support it; C: channel; N: node; P: packet; L: low; M: medium; H: high; VH: very high; U: unclear.
(ξ ) the E2E latency becomes high if the return routability fails due to firewall presence.
() the E2E latency becomes high when it is necessary an external relay to overcome firewall.
[m3Gdc;November 27, 2015;16:34]

() the E2E latency becomes high if the relay server is far from the MN.
17
JID: COMPNW
1307 In substance, system architectures are considered as de- operating systems, plus some tools for experimenting with 1362
1308 ployable when they work over IPv4 networks, and do not re- HIP (e.g., network analyzers). 1363
1309 quire modifications to the backbone. In general, pure end- Another IPv6 based implementation of HIP for Linux sys- 1364
1310 to-end solutions and those that resort to an external proxy tems is presented in [84]. 1365
1311 are deployable. Some hybrid end-to-end approaches are de- Finally, Hip4Inter.net was another effort for implement- 1366
1312 ployed (MSOCKS, I-TCP, TMSP, HIMA), as well as some pro- ing the base HIP (whose Web site was unreachable at the mo- 1367
1313 posals that modify the access network only (however, one ment of writing). FreeBSD and Linux were supported. 1368
1314 might argue that this requirement prevents the deployability
1315 of the systems in the real world), i.e. SIP-IAPP, [14], MMUSE, I-TCP 1369
1316 ROAM. The paper presenting the I-TCP also provides a descrip- 1370
tion of a prototype implementation [15]. This implementa- 1371
1317 5.1.2. Implementation tion includes modifications to the TCP and Mobile-IP code 1372
1318 The implementation feature indicates whether or not on the routers and MNs. Authors state that no modifications 1373
1319 some real prototype implementation is available. Implemen- are needed in the Unix kernel in the MN. In the MN, the I- 1374
1320 tations or descriptions of implementation can be found for TCP library provides the API for the I-TCP functions which are 1375
1321 the following systems: ABPS [11]; DCCP [81]; FLowMob [82]; similar to the socket related system calls in Unix. A further 1376
1322 Hi3 [83]; Hidden Proxy [66]; HIP [84,85]; I-TCP [15]; LIN6 description of the implementation and a performance evalu- 1377
1323 [61,75]; LISP [86,87]; MCoA (monami6) and NEMO [88–90]; ation are reported in [96]. 1378
1324 MIPv6 [80,88–90]; MMUSE [91]; MPTCP [17,18]; MSOCKS
1325 [20]; NIIA [92]; Shim6 [85,93]; SIP-IAPP [13]; TCP-migrate LIN6 1379
1326 [94]; TMSP [59]; UPMT [67,95]. In [61,75], a prototype implementation of LIN6 on 1380
1327 Below, we provide a brief description of the implementa- NetBSD/i386 is presented. The main goal of this effort was 1381
1328 tion software projects, for the mentioned architectures, avail- to validate the described system architecture. 1382
1329 able at the time of writing. The systems described are or-
LISP 1383
1330 dered alphabetically.
OpenLISP is an open source implementation of the LISP 1384
Protocol running in the kernel of the FreeBSD Operating Sys- 1385
1331 ABPS
tem [86]. It implements a new type of sockets, called Map- 1386
1332 A detailed description of the implementation of the ABPS
1333 system is reported in [11]. The software is available upon ping Sockets, providing an API that can be used by any user 1387
space process. 1388
1334 direct request to the authors. Current versions of ABPS are
LISPmob is another open-source LISP implementation for 1389
1335 available for Linux and Android systems.
Linux, Android and OpenWrt [87]. 1390
1336 DCCP
MIPv6, MCoA monami6 and NEMO 1391
1337 DCCP-TP is an implementation of DCCP optimized for
There are several available implementations of MIPv6 1392
1338 portability [81]. The site provides source code downloads and
[80,88–90]. However, only some examples taken from semi- 1393
1339 documentation. Such implementation includes many DCCP
nal articles will be presented here, together with their related 1394
1340 features, including IPv4 NAT encapsulation. It has been im-
projects. 1395
1341 plemented in C language, for Linux systems, and released un-
UMIP is an open source implementation of Mobile IPv6 1396
1342 der the GNU Lesser General Public License (GPL) v2.1.
and NEMO Basic Support for Linux. It is released under the 1397
GPL v2 [89]. 1398
1343 FLowMob
The Nautilus6 working group provided Linux and BSD ref- 1399
1344 In [82], an implementation for Linux operating systems
erence implementations of IPv6 related libraries and IPv6 ap- 1400
1345 of PMIP and its FlowMob extension was built to validate the
plications [88]. In particular, this working group developed 1401
1346 proposal.
SHISA (an implementation of Mobile IPv6 and NEMO), NEPL 1402
1347 Hi3 (a NEMO platform for Linux), and ATLANTIS (a NEMO Basic 1403
1348 In [83], a prototype implementation of the Hi3 software Support implementation for NetBSD). 1404
1349 architecture is described. It has been conceived as a layered The TAHI project was concluded at the end of 2012 by pro- 1405
1350 agent based architecture to separate the different function- viding implementations of several protocols and test tools, 1406
1351 alities of the system. The main result of such a development e.g., IPv6 core, IPsec, DHCPv6, MIPv6, NEMO [90]. 1407
1352 process was the validation of the Hi3 model architecture.

MMUSE 1408
1353 Hidden proxy An implementation of MMUSE is available in [91]. The 1409
1354 A prototype implementation for Linux systems of the Hid- prototype is written in Java language (which makes it a multi- 1410
1355 den Proxy is described in [66]. The aim of the implementa- platform solution) and uses mjsip as SIP stack. The source 1411
1356 tion was to assess the viability of the proposal. The software code is released under the GPL v2. 1412
1357 is available upon direct request to the authors.
MPTCP 1413
1358 HIP Implementations of MPTCP for Linux systems are de- 1414
1359 The OpenHIP project is developing free, open source soft- scribed in [17,18]. The source code is available in [17]. Three 1415
1360 ware implementing the HIP protocol [85]. The aim is to de- modes of operation are available, i.e. (i) the regular MPTCP, 1416
1361 velop client software for Linux, BSD, Mac OS X, and Windows where all active NICs (and thus multiple TCP flows among 1417
JID: COMPNW
1418 two nodes) are used concurrently, (ii) a backup mode, that other approaches, that have been devised to work over IPv6 1471
1419 uses only a subset of possible communication flows, (iii) a nets, require a separation between the identifier and locator, 1472
1420 single-path mode where a single sub flow is used; when the i.e. GLI-Split, ILNP, LISP, MILSA, NIIA, RANGI. 1473
1421 NIC goes down, a hard handover (break-before-make) is per- MIPv6 is needed by systems belonging to the Home Net- 1474
1422 formed and a new TCP sub flow is created. work class. These systems make use of IPsec, too. IPsec is used 1475
by MILSA and Hidden Proxy. 1476
1423 MSOCKS
1424 The implementation of a MSOCKS library is described in 5.3. Needs modifications 1477
1425 [20]. It is a shim library that sits between the application and
1426 the kernel on the mobile node. Its task is to provide an in- This subtable in Table 3 summarizes the changes that 1478
1427 terface to the application, which is identical to that of the need to be introduced in the network entities of the exam- 1479
1428 Berkeley Sockets API, while internally using the normal TCP ined architectures (e.g. infrastructures, protocols, terminals, 1480
1429 stack of the kernel to provide mobility functions. On Win- applications) so that they can be deployed in real scenarios. 1481
1430 dows platforms, the MSOCKS library was designed to be a These criteria are particularly important since they allow us 1482
1431 DLL that fits between the application and the WinSock DLL. to measure the applicability of a solution. In this way, the re- 1483
1432 Moreover, the paper mentions a BSD OS implementation, quirement for modifying a given entity prevents the simple 1484
1433 using the shared library support, but no further details are deployment of the solution and its practical use. 1485
1434 given. The need for modifying the protocol stack at a MN (see 1486
the row “Protocol Stack in MN”) is not a major limitation be- 1487
1435 NIIA cause the MN exploits the advantage of mobility, which is a 1488
1436 In [92], the authors describe a prototype implementation valid reason for users to install some additional software in 1489
1437 of NIIA, built based on the hip4inter.net code base. their MN. Indeed, almost all the considered systems do re- 1490
quire some particular changes to the MN, and if they do not, 1491
1438 Shim6 they still require the applications running on the MN to be 1492
1439 The OpenHIP project mentioned above also provides an modified (i.e. TMSP [59], HIMA [79], see the row “Applica- 1493
1440 implementation of Shim6 [85]. The idea was to provide an tions in the MN”), or the access network to provide specific 1494
1441 open-source Linux implementation of Shim6 that borrows features and some border gateway to be present (i.e. SIP-IAPP, 1495
1442 from (and can later integrate with) the HIP implementation. [14], see rows “Access Network” and “Border Gateways”). 1496
1443 This would lead to an eventual evolution towards a combined Conversely, modifying the CN to ease the mobility of other 1497
1444 Shim6/HIP implementation. nodes (i.e. the MN) is not a convenient practice and it is very 1498
1445 LinShim6 (and its variant, MipShim6) is another project likely that those changes will never be deployed in real con- 1499
1446 that implements Shim6 [93]. texts. The list of systems that require such changes is re- 1500
ported in the row labeled “Protocol Stack in CN”. Basically, 1501
1447 TCP-migrate systems that do not have this requirement, assume the pres- 1502
1448 A Linux-based implementation of TCP-migrate has been ence of an additional relay/proxy or a border gateway that 1503
1449 released as free software, under the GPL v2 [94]. manage packets to be sent to the CN. 1504
Analogous considerations refer to those changes which 1505
1450 TMSP are needed in the applications executed in the MN and in the 1506
1451 In [59], an implementation on Linux kernel of TMSP is CN (see rows “Applications in the MN” and “Applications in 1507
1452 described, followed by a performance evaluation. The sys- the CN”). Legacy applications cannot be modified. Owing to 1508
1453 tem was tested with video streaming and video conferencing the above observations we can conclude that it would be dif- 1509
1454 applications. ficult to see pure or hybrid end-to-end host mobility archi- 1510
tectures being deployed in real, current scenarios. Moreover, 1511
1455 UPMT we mentioned that systems in the access network class, that 1512
1456 UPMT has been implemented for mainstream Linux and employ the identifier- locator distinction, are not designed 1513
1457 then ported on the Android OS [67,97]. The source code for IPv4 networks. 1514
1458 is available under the GPL. For demonstration purposes, a Modifications to the network infrastructures require 1515
1459 UPMT Linux Live distribution is provided where both UPMT labour-intensive work, as well as reconfiguration and mod- 1516
1460 mobile and anchor nodes can be set up. ification of the networks. This is particularly true when a 1517
solution needs to modify all the access networks or border 1518
1461 5.2. Requirements gateways. As mentioned, rows “Access Network” and “Bor- 1519
der Gateways” report those systems that have such require- 1520
1462 The requirements subtable describes what protocols and ments. They basically fall in the home network–based and ac- 1521
1463 features are necessary for each given architecture. In par- cess network–based host mobility classes. Thus, the deploy- 1522
1464 ticular, we mark systems that require the presence of IPv6, ment of home network–based and access network–based 1523
1465 MIPv6 or IPSec. As shown in Table 3, all solutions that ex- host mobility architectures suffers from a massive inertia, 1524
1466 ploit a software entity in the home network do require an due to the difficulties of deploying them in the existing In- 1525
1467 IPv6 approach. Indeed, these solutions are designed to work ternet. 1526
1468 with IPv6 or the like, and do exploit a HA. Solutions that rely on an external relay/proxy server are 1527
1469 Some systems in the hybrid end-to-end class, i.e. LIN6 and deployable because they do not impact on the existing infras- 1528
1470 Shim6 (as their names suggest), employ IPv6 as well. The tructures (see the “Require External Relay” row in the table). 1529
JID: COMPNW
1530 The above considerations represent an important claim. to perform the return routability operation. However, if dur- 1589
1531 We are indeed arguing that it is quite unlikely that the great ing the re-configuration of the preferred NIC, the MN exploits 1590
1532 majority of well known systems will be employed in real sce- a different NIC, the unavailability interval decreases. For this 1591
1533 narios, at least over a short or medium time period. reason, all the solutions employing multihoming on a per- 1592
packet basis limit the unavailability interval length. 1593
1534 5.4. Performance In addition, it is very important to note that, commonly, 1594
the unavailability time interval does not include the han- 1595
1535 The Performance subtable in Table 4 consists of criteria dover time only. When a network becomes unavailable (and 1596
1536 that describe the QoS provided by the considered architec- thus a handover is required) there is a time interval during 1597
1537 tures. In particular, these criteria include: the ability of pro- which the NIC appears to be functioning (at the MN), but 1598
1538 viding support to different applications and the protocols packets are lost [98]. Then, the MN only detects that the con- 1599
1539 commonly employed to build them (i.e. SIP/RTP, UDP, TCP or nection with its access points has been lost after a while and 1600
1540 legacy applications), characteristics in terms of service con- eventually the handover begins. If the MN is able to detect 1601
1541 tinuity, service unavailability, end-to-end latency, security, these losses and can retransmit packets immediately, by ex- 1602
1542 ability to exploit simultaneously all the available NICs and to ploiting a different, already configured and properly working 1603
1543 switch granularity. When we refer to the support provided to NIC (as it may happen when a multihoming solution is em- 1604
1544 some communication protocols (e.g. SIP, RTP, TCP), we mean ployed), then the unavailability interval decreases. For that 1605
1545 that the considered system copes with the typical problems reason, the solutions that adopt some “early packet loss de- 1606
1546 arising at that protocol level during a handover. It is thus ev- tector”, such as ABPS and FRHP, significantly reduce the un- 1607
1547 ident that a particular scheme may provide support only to availability interval. For the sake of completeness, in the row 1608
1548 protocols working at a higher level of the network stack. labeled “Unavailability Interval Due to Handover” in Table 4, 1609
1549 Of course, only multihoming systems (described in the symbol ∞ means that the architecture may fail to com- 1610
1550 Section 4) may allow exploiting multiple NICs simultane- plete the handover: as concerns pure end-to-end solutions, 1611
1551 ously (“Exploit simultaneously multiple NICs” row). this happens when both MN and CN change their IP ad- 1612
1552 The row “granularity” reports whether or not a system dresses at the same time; in access network–based solutions, 1613
1553 works by considering (i) the MN as a whole (N), (ii) a channel this happens when the MN enters an access network whose 1614
1554 where a communication flow occurs between the MN and border gateway is not able to support the host mobility. 1615
1555 its CNs (C), or (iii) even when the communication manage- The “continuity interval” row in Table 4 ranks the time 1616
1556 ment occurs on a per-packet basis (P). Again, systems in the during which the MN may communicate with the CN. In par- 1617
1557 same class work in a similar way. Thus, pure end-to-end sys- ticular, it measures the distance between two consecutive 1618
1558 tems work at the level of communication channels. Hybrid unavailability intervals, in intermittent communication sce- 1619
1559 end-to-end systems and those that employ software on the narios. This metric rewards those systems capable of switch- 1620
1560 home network operate at the level of the node (with the ex- ing seamlessly from the NIC in use to another NIC already 1621
1561 ception of FlowMob that work with channels). Systems em- working. Conversely, all the host mobility solutions that do 1622
1562 ploying specific features at the access network work at node not allow the simultaneous use of multiple NICs, would incur 1623
1563 or channel levels. Finally, solutions that employ some (visible severe service interruptions; this corresponds to a low con- 1624
1564 or invisible) relay work on a per-packet basis. tinuity of service level. Similarly, those architectures where 1625
1565 It is worth noting that few systems are able to overcome handovers may fail (see the discussion of the unavailability 1626
1566 the problems which may arise when NATs and firewalls are interval above) may provide a low level of service continuity. 1627
1567 in the network. This is a typical feature of proxy-based ap- Finally, the maximum continuity interval is provided by so- 1628
1568 proaches. However, the solutions that separate locators and lutions based on the early packet loss detection; this is due 1629
1569 identifiers, do not take into consideration the presence of to the fact that these approaches may recover from packet 1630
1570 NAT, since it is assumed that IPv6 is employed, thus NAT losses by switching to (and retransmitting through) a differ- 1631
1571 would not be used anymore. Moreover, the use of identifiers ent NIC [98]. 1632
1572 enables firewalls to have access control rules that are based The “end-to-end latency” row measures the time needed 1633
1573 on identity, rather than address or location. However, this re- to deliver a packet from the MN application to the CN ap- 1634
1574 quires further work and costs to the firewall; in the case of plication. This metric is very important for interactive appli- 1635
1575 symmetric firewalls, every time an end-node creates a con- cations. The lowest bound of this latency corresponds to a 1636
1576 nection using a new identifier, the firewall must be instructed direct communication between the MN and its CN, as in the 1637
1577 properly. case of pure and hybrid end-to-end host mobility solutions. 1638
1578 The unavailability interval measures the length of the in- The access network–based solutions do not introduce addi- 1639
1579 terval time during which the MN is not able to communi- tional delays because the packets transit through an entity 1640
1580 cate with the CN, due to the handover. This metric is very (the border gateway) that is already in the path between MN 1641
1581 important when some interactive application (e.g. VoIP) and CN. In home network-based solutions, on the other hand, 1642
1582 is executed. This unavailability interval includes the time the situation is more complex. Indeed, if the return routabil- 1643
1583 needed to re-configure all the network entities involved in ity operation is successful, then the communication between 1644
1584 the end-to-end MN-CN communication. For this reason, all MN and CN is direct, with a consequent minimum latency. 1645
1585 the solutions based on MIPv6 suffer from a high unavailabil- However, if this operation fails, then packets transit through 1646
1586 ity interval (around 1–3 seconds, typically) because they re- the home network, hence increasing the average latency, de- 1647
1587 quire an intense packet exchange between the MN, the home pending on the distance between the CN and the home net- 1648
1588 network and the CN to register the new CoA on the HA and work, and between the home network and the MN. Solutions 1649
JID: COMPNW
1650 based on an external relay/proxy obviously add a delay, de- supported by MIPv6 solutions. Note that this is true when 1709
1651 pending on the distance of the relay/proxy server. However, only one network interface is used by the MN. As regards 1710
1652 it is worth pointing out that in the real scenario there are multihoming, the approaches may be subjected to poor per- 1711
1653 often firewalls and NAT systems that block direct communi- formances in terms of introduced latencies and connection 1712
1654 cation and impose the interposition of a relay. Thus, in this continuity intervals. 1713
1655 common situation there is a latency increase, except for the In conclusion, the above considerations suggest that it is 1714
1656 external relay–based solutions that already utilize a relay. quite unlikely that many of these proposals will be adopted 1715
1657 The last two rows in Table 4 report the end-to-end latency in real life scenarios, at least on a short- or medium- term ba- 1716
1658 in the best scenario (with no firewalls) and in the most com- sis. Our claim is that future proposals should deal with issues 1717
1659 mon scenario (with symmetric firewalls), respectively. In the concerned with the presence of NATs and firewalls natively. 1718
1660 most common scenario, all the solutions are almost equiva- A good solution is to resort to dedicated services such as ex- 1719
1661 lent in terms of end-to-end latency. ternal proxies, that can be easily distributed on the Internet. 1720
As a matter of fact, many applications and their related pro- 1721
1662 6. Conclusions tocols include the use of external proxies, although they are 1722
usually exploited for application purposes only. Some exam- 1723
1663 This work presents an overview of the main architectural ples include VoIP applications, SIP-based applications and, in 1724
1664 solutions for managing the handover process in mobile wire- certain cases, HTTP-based applications [26]. We suggest that 1725
1665 less communications. All the examined schemes have been their use may be extended, in order to cater for issues con- 1726
1666 grouped and categorized according to their main character- cerned with mobility, as has already been proposed in the 1727
1667 istics, the features they offer and the level of network stack literature [11,66]. 1728
1668 in which they operate. As a concluding remark, it should be mentioned that 1729
1669 This survey highlights that a number of issues need to be cloud computing environments can be used as the infrastruc- 1730
1670 addressed when designing an architecture for mobile com- ture to dynamically set up (and release) the proxies on the 1731
1671 munications, even though the same issues may not be as ob- server-side, in accordance with the pay-as-you-go principle 1732
1672 vious as it first appears. Our discussion focuses on the key of cloud based services [99]. 1733
1673 issue of handover management, and concludes that, firstly,
1674 the best solution to this issue has not yet been identified. In- References 1734
1675 deed, all the schemes investigated in the literature present
1676 some advantages and drawbacks. [1] M. Menth, M. Hartmann, D. Klein, Global locator, local locator, and 1735
1677 Secondly, at the time of writing, the most widespread ap- identifier split (GLI-split), Futur. Internet 5 (1) (2013) 67–94. 1736
[2] L. Bokor, L.T. Zeke, S. Nováczki, G. Jeney, Protocol design and analy- 1737
1678 proach for building software architectures that support users sis of a hip-based per-application mobility management platform., in: 1738
1679 mobility is based on the use of MIPv6. The solutions that W. Li, A.Y. Zomaya, A. Al-Jumaily (Eds.), Proceedings of the Seventh 1739
1680 adopt this approach are not deployable in current IPv4 net- ACM International Workshop on Mobility Management & Wireless Ac- 1740
cess, MOBIWAC 2009, ACM, 2009, pp. 7–16. 1741
1681 works. Moreover, these solutions cannot coexist with sym- [3] R. Moskowitz, P. Nikander„ Host identity protocol (hip) architecture, 1742
1682 metric firewalls. RFC 4423 (Informational)(may 2006) (2006). http://www.ietf.org/rfc/ 1743
1683 Thirdly, we have shown that many techniques are not able rfc4423.txt. 1744 Q2
[4] A. Gurtov, D. Korzun, A. Lukyanenko, P. Nikander, Hi3: an efficient and 1745 Q3
1684 to cope with some problems due to the presence of sym-
secure networking architecture for mobile hosts., Comput. Commun. 1746
1685 metric NATs (this is a main issue for strategies that might be 31 (10) (2008) 2457–2467. 1747
1686 deployed on the current IPv4 Internet) and symmetric fire- [5] R. Atkinson, S. Bhatti, Identifier-Locator Network Protocol (ILNP) Archi- 1748
tectural Description, RFC 6740 (Proposed Standard) (November 2012) 1749
1687 walls placed in front of two end-systems, which prevents the
(2012). 1750
1688 two end-systems to communicate. Drawing on these con- [6] D. Saucez, L. Iannone, O. Bonaventure, D. Farinacci, Designing a de- 1751
1689 siderations, we can say that the approaches that solve the ployable internet: the locator/identifier separation protocol, IEEE Inter- 1752
1690 problem through the use of external relays seem to be more net Comput. 16 (6) (2012) 14–21. http://doi.ieeecomputersociety.org/ 1753
10.1109/MIC.2012.98. 1754
1691 promising. [7] J. Pan, R. Jain, S. Paul, C. So-in, Milsa: a new evolutionary architecture 1755
1692 Fourth, there are many popular applications and proto- for scalability, mobility, and multihoming in the future internet, IEEE 1756
1693 cols that violate the protocol stack stratification, since they J. Sel. Areas Commun. 28 (8) (2010) 1344–1362, doi:10.1109/JSAC.2010. 1757
101012. http://dx.doi.org/10.1109/JSAC.2010.101012 1758
1694 add information regarding the network and transport lay- [8] B. Ahlgren, J. Arkko, L. Eggert, J. Rajahalme, A node identity internet- 1759
1695 ers within application data payloads. A prominent example is working architecture, INFOCOM 2006. 25th IEEE International Con- 1760
1696 SIP. These applications and protocols introduce several com- ference on Computer Communications, 2006, pp. 1–6, doi:10.1109/ 1761
INFOCOM.2006.51. 1762
1697 plications in the design of an effective mobility architecture. [9] S. Schütz, H. Abrahamsson, B. Ahlgren, M. Brunner, Design and imple- 1763
1698 Indeed, to make the underlying system application/protocol- mentation of the node identity internetworking architecture, Comput. 1764
1699 transparent, it is necessary to update the application pay- Netw. 54 (7) (2010) 1142–1154, doi:10.1016/j.comnet.2009.10.015. 1765
[10] X. Xu, R. Jain, Routing Architecture for the Next Generation Internet 1766
1700 loads included in the transmitted packets. This is done to en-
(RANGI), Internet-Draft draft-xu-rangi, IETF Secretariat, 2009. 1767
1701 sure that the IP address and port contained at the transport [11] V. Ghini, S. Ferretti, F. Panzieri, The “always best packet switching” 1768
1702 and network layers match those included within the applica- architecture for sip-based mobile multimedia services, J. Syst. Softw. 1769
84 (11) (2011) 1827–1851, doi:10.1016/j.jss.2011.06.025. http://www. 1770
1703 tion data. This task can be more easily accomplished by ex-
sciencedirect.com/science/article/pii/S0164121211001506 1771
1704 ploiting two proxies, a local one and an external one, working [12] E. Kohler, M. Handley, S. Floyd, Datagram Congestion Control Protocol 1772
1705 on top of the transport layer, rather than some network-layer (DCCP), RFC 4340 (Proposed Standard), updated by RFCs 5595, 5596 1773
1706 solutions. (March 2006), 2006. http://www.ietf.org/rfc/rfc4340.txt. 1774
[13] IEEE Recommended Practice for Multi-Vendor Access Point Interoper- 1775
1707 On the other hand, those applications and protocols ability via an Inter-Access Point Protocol Across Distribution Systems 1776
1708 that do not violate the protocol stratification can be easily Supporting 802.11 Operation (Jan. 2002), 2002. 1777
JID: COMPNW
1778 [14] C.-S. Wu, M.-T. Yang, K.-S. Hwang, Fast-handoff schemes for inter- [34] A. Gladisch, R. Daher, D. Tavangarian, Survey on mobility and 1855
1779 subnet handoff in IEEE 802.11 WLANs for SIP/RTP applications, in: multihoming in future internet, Wirel. Personal Commun. 74 (1) 1856
1780 M. Guizani, H.-H. Chen, X. Zhang (Eds.), Proceedings of the Interna- (2014) 45–81, doi:10.1007/s11277-012-0898-6. http://dx.doi.org/10. 1857
1781 tional Conference on Wireless Communications and Mobile Comput- 1007/s11277-012-0898-6 1858
1782 ing, IWCMC 2007, ACM, 2007, pp. 146–151. [35] W. Ramirez, X. Masip-Bruin, M. Yannuzzi, R. Serral-Gracia, A. Martinez, 1859
1783 [15] A. Bakre, B.R. Badrinath, I-tcp: indirect tcp for mobile hosts, in: Dis- M.S. Siddiqui, A survey and taxonomy of id/locator split architectures, 1860
1784 tributed Computing Systems, 1995., Proceedings of the 15th Inter- Comput. Netw. 60 (2014) 13–33, doi:10.1016/j.bjp.2013.12.006. http:// 1861
1785 national Conference on, 1995, pp. 136–143, doi:10.1109/ICDCS.1995. dx.doi.org/10.1016/j.bjp.2013.12.006 1862
1786 500012. [36] E. Nordmark, M. Bagnulo„ Shim6: Level 3 Multihoming Shim Protocol 1863
1787 [16] S. Salsano, A. Polidoro, C. Mingardi, S. Niccolini, L. Veltri, Sip-based mo- for IPv6, RFC 5533 (Proposed Standard) (June 2009), 2009. http://www. 1864
1788 bility management in next generation networks, IEEE Wirel. Commun. ietf.org/rfc/rfc5533.txt. 1865
1789 15 (2) (2008) 92–99. [37] H. Tuncer, A. Kwasinski, N. Shenoy, Performance analysis of virtual 1866
1790 [17] Multipath tcp - linux kernel implementation, http://multipath-tcp.org/ mobility domain scheme vs. ipv6 mobility protocols, Comput. Netw. 1867
1791 [18] C. Paasch, G. Detal, F. Duchene, C. Raiciu, O. Bonaventure, Exploring Mo- 57 (13) (2013) 2578–2596, doi:10.1016/j.comnet.2013.05.004. http:// 1868
1792 bile/Wifi Handover with Multipath TCP, in: Proceedings of the 2012 dx.doi.org/10.1016/j.comnet.2013.05.004 1869
1793 ACM SIGCOMM Workshop on Cellular Networks: Operations, Chal- [38] J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy,a, STUN - simple 1870
1794 lenges, and Future Design, CellNet ’12, ACM, New York, NY, USA, 2012, traversal of user datagram protocol (UDP) through network address 1871
1795 pp. 31–36, doi:10.1145/2342468.2342476. http://doi.acm.org/10.1145/ translators (NATs), RFC 3489 (March 2003), 2003. 1872
1796 2342468.2342476 [39] J. Rosenberg, R. Mahy, C. Huitema, Traversal using relay NAT (TURN), 1873
1797 [19] L. Budzisz, J. Garcia, A. Brunstrom, R. Ferrús, A taxonomy and survey Internet-Draft (September 2005), 2005. 1874
1798 of sctp research, ACM Comput. Surv. 44 (4) (2012) 18:1–18:36, doi:10. [40] J. Rosenberg, Interactive Connectivity Establishment (ICE): A Protocol 1875
1799 1145/2333112.2333113. http://doi.acm.org/10.1145/2333112.2333113 for Network Address Translator (NAT) Traversal for Offer/Answer Pro- 1876
1800 [20] D. Maltz, P. Bhagwat, Msocks: an architecture for transport layer mobil- tocols, Tech. Rep. 5245, RFC Editor, Apr. 2010. http://www.rfc-editor. 1877
1801 ity, in: Proceedings of the Seventeenth Annual Joint Conference of the org/rfc/rfc5245.txt 1878
1802 IEEE Computer and Communications Societies INFOCOM ’98., 3, IEEE, [41] D. Corujo, C. Guimaraes, B. Santos, R.L. Aguiar, Using an open-source 1879
1803 1998, pp. 1037–1045, doi:10.1109/INFCOM.1998.662913. ieee 802.21 implementation for network-based localized mobility 1880
1804 [21] A. Snoeren, H. Balakrishnan, F. Kaashoek, Reconsidering Internet Mo- management, Commun. Mag. IEEE 49 (9) (2011) 114–123, doi:10.1109/ 1881
1805 bility, in: Proceedings of the 8th Workshop on Hot Topics in Operating MCOM.2011.6011742. 1882
1806 Systems, Elmau/Oberbayern, Germany, 2001. [42] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. 1883
1807 [22] A. Gladisch, R. Daher, D. Tavangarian, Survey on mobility and Sparks, M. Handley, E. Schooler, SIP: Session initiation protocol, 2002, 1884
1808 multihoming in future internet, Wirel. Personal Commun. 74 (1) [43] P. Bellavista, A. Corradi, L. Foschini, Ims-compliant management of ver- 1885
1809 (2014) 45–81, doi:10.1007/s11277-012-0898-6. http://dx.doi.org/10. tical handoffs for mobile multimedia session continuity, IEEE Commun. 1886
1810 1007/s11277-012-0898-6 Mag. 48 (2010) 114–121. http://dl.acm.org/citation.cfm?id=1824609. 1887
1811 [23] B. Ahlgren, C. Dannewitz, C. Imbrenda, D. Kutscher, B. Ohlman, A survey 1824623 1888
1812 of information-centric networking, IEEE Commun. Mag. 50 (7) (2012) [44] C. Kalmanek, J. Murray, C. Rice, B. Gessel, R. Kabre, A. Moskal, A 1889
1813 26–36, doi:10.1109/MCOM.2012.6231276. network-based architecture for seamless mobility services, Commun. 1890
1814 [24] H. Tuncer, Y. Nozaki, N. Shenoy, Virtual mobility domains - a mobility Mag. 44 (6) (2006) 103–109, doi:10.1109/MCOM.2006.1668427. http: 1891
1815 architecture for the future internet, in: 2012 IEEE International Confer- //dx.doi.org/10.1109/MCOM.2006.1668427 1892
1816 ence on Communications (ICC), 2012, pp. 2774–2779, doi:10.1109/ICC. [45] H. Schulzrinne, E. Wedlund, Application-layer mobility using sip, SIG- 1893
1817 2012.6363872. MOBILE Mob. Comput. Commun. Rev. 4 (3) (2000) 47–57, doi:10.1145/ 1894
1818 [25] Y. Wang, J. Bi, C. Peng, H. Hu, Una: a new internet architecture for 372346.372369. http://doi.acm.org/10.1145/372346.372369 1895
1819 user-level multi-homing and mobility, Proceedings of the 6th Interna- [46] A. Udugama, K. Kuladinithi, C. Gorg, F. Pittmann, L. Tionardi, Netcape: 1896
1820 tional Conference on Future Internet Technologies, CFI ’11, ACM, New Enabling seamless ims service delivery across heterogeneous mobile 1897
1821 York, NY, USA, 2011, pp. 13–18, doi:10.1145/2002396.2002400. http:// networks, Commun. Mag. 45 (7) (2007) 84–91, doi:10.1109/MCOM. 1898
1822 doi.acm.org/10.1145/2002396.2002400 2007.382665. http://dx.doi.org/10.1109/MCOM.2007.382665 1899
1823 [26] S. Ferretti, V. Ghini, A web 2.0, location-based architecture for a seam- [47] D. Johnson, C. Perkins, J. Arkko, RFC 3775:Mobility Support in IPv6, 1900
1824 less discovery of points of interests, in: The Fifth Advanced Interna- 2004, http://www.ietf.org/rfc/rfc3775.txt. 1901
1825 tional Conference on Telecommunications, AICT 2009, 2009, pp. 226– [48] N.V. Hanh, S. Ro, J. Ryu, Simplified fast handover in mobile 1902
1826 231. ipv6 networks, Comput. Commun. 31 (15) (2008) 3594–3603, 1903
1827 [27] G.-H. Tu, Y. Li, C. Peng, C.-Y. Li, H. Wang, S. Lu, Control-plane protocol doi:10.1016/j.comcom.2008.06.009. http://dx.doi.org/10.1016/j. 1904
1828 interactions in cellular networks, SIGCOMM Comput. Commun. Rev. 44 comcom.2008.06.009 1905
1829 (4) (2014) 223–234, doi:10.1145/2740070.2626302. http://doi.acm.org/ [49] H. Soliman, C. Castelluccia, K. Malki, L. Bellier, Hierarchical Mobile IPv6 1906
1830 10.1145/2740070.2626302 mobility management (HMIPv6), RFC 4140, IETF (August 2005), 2005. 1907
1831 [28] C.-T. Chou, K.G. Shin, An enhanced inter-access point protocol for uni- [50] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, B. Patil, Proxy 1908
1832 form intra and intersubnet handoffs, IEEE Trans. Mobile Comput. 4 Mobile IPv6, RFC 5213 (Proposed Standard) (August 2008), 2008 1909
1833 (4) (2005) 321–334. http://doi.ieeecomputersociety.org/10.1109/TMC. http://www.ietf.org/rfc/rfc5213.txt. 1910
1834 2005.49. [51] H. Zhou, H. Zhang, Y. Qin, H.-C. Wang, H.-C. Chao, A proxy mobile ipv6 1911
1835 [29] V. Ghini, S. Ferretti, F. Panzieri, A strategy for best access based global mobility management architecture and protocol, Mobile 1912
1836 point selection„in: Wireless Days (WD), 2010 IFIP2010, 1–5, Netw. Appl. 15 (4) (2010) 530–542, doi:10.1007/s11036-009-0185-2. 1913
1837 10.1109/WD.2010.5657762. http://dx.doi.org/10.1007/s11036-009-0185-2 1914
1838 [30] S. Pack, J. Choi, T. Kwon, Y. Choi, Fast-handoff support in ieee 802.11 [52] W. He, I.-R. Chen, D.-C. Wang, Cross-layer integrated mobility and ser- 1915
1839 wireless networks, Commun. Surv. Tutor. IEEE 9 (1) (2007) 2–12, doi:10. vice management utilizing smart routers in mobile ipv6 systems, Pro- 1916
1840 1109/COMST.2007.358968. ceedings of the 8th International Conference on Advances in Mobile 1917
1841 [31] I. Ramani, S. Savage, Syncscan: practical fast handoff for 802.11 infras- Computing and Multimedia, MoMM ’10, ACM, New York, NY, USA, 2010, 1918
1842 tructure networks, Proceedings of the IEEE INFOCOM 2005, 24th An- pp. 140–147, doi:10.1145/1971519.1971545. http://doi.acm.org/10.1145/ 1919
1843 nual Joint Conference of the IEEE Computer and Communications Soci- 1971519.1971545 1920
1844 eties, 1, 2005, pp. 675–684, doi:10.1109/INFCOM.2005.1497933.vol. 1 [53] E. Perera, V. Sivaraman, A. Seneviratne, Survey on network mobility 1921
1845 [32] Ieee standard for information technology– local and metropolitan area support, ACM SIGMOBILE Mobile Comput. Commun. Rev. 8 (2) (2004) 1922
1846 networks– specific requirements– part 11: Wireless lan medium ac- 7–19, doi:10.1145/997122.997127. http://doi.acm.org/10.1145/997122. 1923
1847 cess control (mac) and physical layer (phy) specifications amendment 997127 1924
1848 2: Fast basic service set (bss) transition, IEEE Std 802.11r-2008 (Amend- [54] S. Zhuang, K. Lai, I. Stoica, R. Katz, S. Shenker, Host mobility us- 1925
1849 ment to IEEE Std 802.11–2007 as amended by IEEE Std 802.11k-2008), ing an internet indirection infrastructure, Wirel. Netw. 11 (6) (2005) 1926
1850 2008, 1–126, 10.1109/IEEESTD.2008.4573292. 741–756, doi:10.1007/s11276-005-3528-3. http://dx.doi.org/10.1007/ 1927
1851 [33] R. Atkinson, S. Bhatti, S. Hailes, Evolving the internet architec- s11276-005-3528-3 1928
1852 ture through naming, IEEE J. Sel. Areas Commun. 28 (8) (2010) [55] K.-S. Kong, W. Lee, Y.-H. Han, M.-K. Shin, H. You, Mobility management 1929
1853 1319–1325, doi:10.1109/JSAC.2010.101009. http://dx.doi.org/10.1109/ for all-ip mobile networks: mobile ipv6 vs. proxy mobile ipv6, Wireless 1930
1854 JSAC.2010.101009 Commun. IEEE 15 (2) (2008) 36–45, doi:10.1109/MWC.2008.4492976. 1931
JID: COMPNW
1932 [56] D. Klein, M. Hartmann, M. Menth, Nat traversal for lisp mobile node, [76] P. Nikander, J. Arkko, B. Ohlman, Host identity indirection infrastruc- 2010
1933 Proceedings of the Re-Architecting the Internet Workshop, ReARCH ture (Hi3), in: Proceedings of the Second Swedish National Computer 2011
1934 ’10, ACM, New York, NY, USA, 2010, pp. 8:1–8:6, doi:10.1145/1921233. Networking Workshop (SNCNW), Karlstad, Sweden, 2004. 2012
1935 1921243. http://doi.acm.org/10.1145/1921233.1921243 [77] J. Arkko, I. van Beijnum, Failure Detection and Locator Pair Exploration 2013
1936 [57] R. Whittle, S. Russert, TTR Mobility Extensions for Core-Edge Separa- Protocol for IPv6 Multihoming, RFC 5534 (Proposed Standard) (2009). 2014
1937 tion Solutions to the Internet’s Routing Scale Problem, Technical report, http://www.ietf.org/rfc/rfc5534.txt 2015
1938 2008. http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf [78] E. Kohler, Datagram Congestion Control Protocol Mobility and Multi- 2016
1939 [58] I. Stoica, D. Adkins, S. Zhuang, S. Shenker, S. Surana, Internet indirection homing, IETF, [Internet Draft] (2004). http://www.icir.org/kohler/dcp/ 2017
1940 infrastructure, IEEE/ACM Trans. Netw. 12 (2) (2004) 205–218, doi:10. draft-kohler-dccp-mobility-00.txt 2018
1941 1109/TNET.2004.826279. http://dx.doi.org/10.1109/TNET.2004.826279 [79] N. Shenoy, A framework for seamless roaming across heteroge- 2019
1942 [59] T.M. Lim, C.K. Yeo, F. Lee, Q.V. Le, Tmsp: terminal mobility support pro- neous next generation wireless networks, Wirel. Netw. 11 (6) (2005) 2020
1943 tocol, IEEE Trans. Mob. Comput. 8 (6) (2009) 849–863. 757–774, doi:10.1007/s11276-005-3529-2. http://dx.doi.org/10.1007/ 2021
1944 [60] M. Arye, E. Nordstrom, R. Kiefer, J. Rexford, M. Freedman, A formally- s11276-005-3529-2 2022
1945 verified migration protocol for mobile, multi-homed hosts, in: Network [80] Q. Li, T. Jinmei, K. Shima, Mobile IPv6: Protocols and Implementation, 2023
1946 Protocols (ICNP), 2012 20th IEEE International Conference on, 2012, Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2009. 2024
1947 pp. 1–12, doi:10.1109/ICNP.2012.6459961. [81] Dccp-tp home page, http://www.phelan-4.com/dccp-tp/tiki-index. 2025
1948 [61] F. Teraoka, M. Ishiyama, M. Kunishi, LIN6: a solution to mobility php. 2026
1949 and multi-homing in IPv6, in: Internet-Draft draft-teraoka-ipng-lin6- [82] T. Melia, C.J. Bernardos, A. de la Oliva, F. Giust, M. Calderón, Ip flow 2027
1950 02.txt, IETF Secretariat, Fremont, CA, USA, 2003. http://www.rfc-editor. mobility in PMipv6 based networks: Solution design and experimental 2028
1951 org/internet-drafts/draft-teraoka-ipng-lin6-02.txt evaluation, Wirel. Personal Commun. 4603–627. 2029
1952 [62] J.-L. Lin, J.-Y. Pan, Hand-around: a handoff evolution with monami6, [83] G. Varela, A. Paz-Lpez, S. Vazquez-Rodriguez, R. Duro, Hi3 project: De- 2030
1953 in: Wireless Communications, Networking and Mobile Computing, sign and implementation of the lower level layers, IEEE Symposium on 2031
1954 2007. WiCom 2007. International Conference on, 2007, pp. 1775–1778, Virtual Environments, Human-Computer Interfaces and Measurement 2032
1955 doi:10.1109/WICOM.2007.445. Systems, 2007. VECIMS 2007, 2007, pp. 36–41, doi:10.1109/VECIMS. 2033
1956 [63] T. Narten, E. Nordmark, W. Simpson, H. Soliman, Neighbor Discovery 2007.4373924. 2034
1957 for IP version 6 (IPv6), in: RFC 4861 (Draft Standard), updated by RFC [84] M. Komu, M. Kousa, J. Lundberg, C. Candolin, An implementation of hip 2035
1958 5942, 2007. http://www.ietf.org/rfc/rfc4861.txt for linux, in: Proceedings of Ottawa Linux Symposium, Ottawa, Canada, 2036
1959 [64] U. Toseef, A. Udugama, C. Goerg, C. Fan, F. Pittmann, Realization of mul- 2003. 2037
1960 tiple access interface management and flow mobility in ipv6, in: Pro- [85] Openhip on sourceforge, http://sourceforge.net/projects/openhip/ 2038
1961 ceedings of the 1st international conference on MOBILe Wireless Mid- files/. 2039
1962 dleWARE, Operating Systems, and Applications, MOBILWARE ’08, ICST [86] The openlisp project [cited 2015]. http://www.openlisp.org/. 2040
1963 (Institute for Computer Sciences, Social-Informatics and Telecommuni- [87] The lispmob project [cited 2015]. http://lispmob.org/. 2041
1964 cations Engineering), ICST, Brussels, Belgium, Belgium, 2007, pp. 1–26. [88] Nautilus6 - network mobility website (2005) [cited 2014]. http://www. 2042
1965 http://dl.acm.org/citation.cfm?id=1361492.1361524 nautilus6.org. 2043
1966 [65] M. O’Dell„ GSE: An Alternate Addressing Architecture for IPv6, Internet- [89] Umip - mobile ipv6 and nemo for linux [cited 2014]. http://umip.org/. 2044
1967 Draft draft-ipng-gseaddr-00.txt, IETF Secretariat (Feb. 1997), 1997. [90] Tahi project web site [cited 2014]. http://www.tahi.org/. 2045
1968 [66] V. Ghini, S. Cacciaguerra, F. Panzieri, P. Salomoni, A hidden proxy [91] Mmuse: Mobility management using sip extensions web site [cited 2046
1969 for seamless and abc multimedia mobile blogging, in: Proceedings of 2015]. http://netgroup.uniroma2.it/twiki/bin/view.cgi/Netgroup/ 2047
1970 the 3rd IEEE Consumer Communications and Networking Conference MMUSEProject. 2048
1971 (CCNC), [92] S. Schütz, H. Abrahamsson, B. Ahlgren, M. Brunner, Design and 2049
Q4
1972 [67] M. Bonola, S. Salsano, A. Polidoro, Upmt: Universal per-application implementation of the node identity internetworking architec- 2050
1973 mobility management using tunnels, Proceedings of the 28th IEEE ture, Comput. Netw. 54 (7) (2010) 1142–1154. http://dx.doi.org/ 2051
1974 Conference on Global Telecommunications, IEEE Press, Piscataway, NJ, 10.1016/j.comnet.2009.10.015. http://www.sciencedirect.com/science/ 2052
1975 USA, 2009, pp. 2811–2818. http://dl.acm.org/citation.cfm?id=1811681. article/pii/S1389128609003363 2053
1976 1811847 [93] S. Barré, J. Ronan, O. Bonaventure, Implementation and evaluation 2054
1977 [68] E. Giordano, L. Codecà, B. Geffon, G. Grassi, G. Pau, M. Gerla, Movit: The of the shim6 protocol in the linux kernel, Comput. Commun. 34 2055
1978 mobile network virtualized testbed, Proceedings of the Ninth ACM In- (14) (2011) 1685–1695, doi:10.1016/j.comcom.2011.03.005. http://dx. 2056
1979 ternational Workshop on Vehicular Inter-networking, Systems, and Ap- doi.org/10.1016/j.comcom.2011.03.005 2057
1980 plications, VANET ’12, ACM, New York, NY, USA, 2012, pp. 3–12, doi:10. [94] The migrate internet mobility project, http://nms.lcs.mit.edu/software/ 2058
1981 1145/2307888.2307892. http://doi.acm.org/10.1145/2307888.2307892 migrate/index.html. 2059
1982 [69] R. Wakikawa, V. Devarapalli, G. Tsirtsis, T. Ernst, K. Nagami, I. Netcore , [95] Upmt project homepage [cited 2014]. http://netgroup.uniroma2.it/ 2060
Q5
1983 Multiple Care-of-Address Registration, Technical report., 2003. twiki/bin/view.cgi/Netgroup/UpMT. 2061
1984 [70] J.-Y. Pan, J.-L. Lin, K.-F. Pan, Multiple care-of addresses registration and [96] A. Bakre, B. Badrinath, Implementation and performance evaluation of 2062
1985 capacity-aware preference on multi-rate wireless links, in: Advanced indirect TCP, IEEE Trans. Comput. 46 (3) (1997) 260–278, doi:10.1109/ 2063
1986 Information Networking and Applications Workshops, International 12.580423. 2064
1987 Conference on, 0, 2008, pp. 768–773. http://doi.ieeecomputersociety. [97] Upmt web site: http://netgroup.uniroma2.it/upmt. 2065
1988 org/10.1109/WAINA.2008.154. [98] S. Ferretti, V. Ghini, M. Marzolla, F. Panzieri, Modeling the always 2066
1989 [71] B. Sousa, M. Silva, K. Pentikousis, M. Curado, A multiple care of ad- best packet switching mechanism, Proceedings of the 6th International 2067
1990 dresses model, in: 2013 IEEE Symposium on Computers and Commu- Conference on Next Generation Mobile Applications Services and Tech- 2068
1991 nications (ISCC), 0, 2011, pp. 485–490. http://doi.ieeecomputersociety. nologies (NGMAST2012), IEEE, 2012. 2069
1992 org/10.1109/ISCC.2011.5983884. [99] S. Ferretti, V. Ghini, F. Panzieri, E. Turrini, Seamless support of multi- 2070
1993 [72] X. Chen, H. Zhang, Y.-C. Chang, H.-C. Chao, Experimentation and media distributed applications through a cloud, in: Cloud Computing 2071
1994 performance analysis of multi-interfaced mobile router scheme, (CLOUD), 2010 IEEE 3rd International Conference on, 2010, pp. 548– 2072
1995 Simul. Model. Pract. Theory 18 (4) (2010) 407–415. http://dx.doi.org/ 549, doi:10.1109/CLOUD.2010.16. 2073
1996 10.1016/j.simpat.2009.09.005. http://www.sciencedirect.com/science/
1997 article/pii/S1569190X09001294 Stefano Ferretti is an Associate Professor at the 2074
1998 [73] V. Zafeiris, E.A. Giakoumakis, Optimized traffic flow assignment in Department of Computer Science and Engineer- 2075
1999 multi-homed, multi-radio mobile hosts., Comput. Netw. 55 (5) (2011) ing of the University of Bologna. He received the 2076
2000 1114–1131. Laurea degree (with honors) and the Ph.D. in 2077
2001 [74] R. Atkinson, S. Bhatti, S. Hailes, A proposal for unifying mobility with Computer Science from the University of Bologna 2078
2002 multi-homing, nat, & security, Proceedings of the 5th ACM Interna- respectively in 2001 and in 2005. His current 2079
2003 tional Workshop on Mobility Management and Wireless Access, Mo- research interests include distributed systems, 2080
2004 biWac ’07, ACM, New York, NY, USA, 2007, pp. 74–83, doi:10.1145/ computer networks, complex networks, wireless 2081
2005 1298091.1298105. http://doi.acm.org/10.1145/1298091.1298105 networks, mobile communications. 2082
2006 [75] M. Kunishi, M. Ishiyama, K. Uehara, H. Esaki, F. Teraoka, Lin6: a new
2007 approach to mobility support in ipv6, in: Proceedings of the Third In-
2008 ternational Symposium on Wireless Personal Multimedia Communica-
2009 tions, 2000, p. 43.
JID: COMPNW
2083 Vittorio Ghini received both the “Laurea” degree Fabio Panzieri received the “Laurea” degree in 2092
2084 in Computer Science (1997) and the Ph.D. degrees “Scienze dell’ Informazione” from the University 2093
2085 (2002) in Computer Science from the University of Pisa (Italy), and the Ph.D. degree in Computer 2094
2086 of Bologna. Since 2011 he is an associate profes- Science from the University of Newcastle upon 2095
2087 sor at the Computer Science Department of the Tyne (U.K.). He was appointed a professor of Com- 2096
2088 University of Bologna. His research interests in- puter Science at the University of Bologna (Italy) 2097
2089 clude distributed multimedia systems, middle- in 1990. His research interests span many areas of 2098
2090 ware protocols for QoS over IP networks, and dy- distributed computing, including fault-tolerance, 2099
2091 namic multi-homing management. real-time, and middleware and communication 2100
support for large scale distributed applications. 2101

Ferretti, Ghini, Panzieri - 2015 - A Survey On Handover Management in Mobility Architectures

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ferretti, Ghini, Panzieri - 2015 - A Survey On Handover Management in Mobility Architectures

Transféré par

Droits d'auteur :

Formats disponibles

JID: COMPNW

ARTICLE IN PRESS [m3Gdc;November 27, 2015;16:34]

Computer Networks xxx (2015) xxx–xxx

Contents lists available at ScienceDirect

A survey on handover management in mobility architectures

1 1. Introduction employed to send data. If a WiFi network is available, the ter- 18

2 S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx

S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx 3

178 Seamless handover 1. identifying each given MN univocally; 221

4 S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx

Fig. 3. Multihoming: a MN has different active NICs available, ready to be used.

S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx 5

326 2.3. Node localization Proxy 380

6 S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx

Fig. 4. Mobility management architectures.

442 2.6. Tools and criteria for mobility management

S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx 7

8 S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx

S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx 9

10 S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx

Fig. 7. The LISP architecture [6].

723 3.1.4. ROAM 3.2.1. Session Initiation Protocol (SIP) 762

S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx 11

12 S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx

S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx 13

14 S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx

Fig. 8. The ABPS-SIP/RTP architecture.

S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx 15

1243 used (i.e. an Ethernet interface not linked to a physical one),

S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx

[m3Gdc;November 27, 2015;16:34]

S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx

[m3Gdc;November 27, 2015;16:34]

18 S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx

1352 process was the validation of the Hi3 model architecture.

S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx 19

20 S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx

S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx 21

22 S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx

S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx 23

24 S. Ferretti et al. / Computer Networks xxx (2015) xxx–xxx

Vous aimerez peut-être aussi