Proactive seamless mobility management for future IP radio access networks

Computer Communications 26 (2003) 1975–1989 www.elsevier.com/locate/comcom

Proactive seamless mobility management for future IP radio access networks T. Pagtzisa,*, P. Kirsteina, S. Hailesa, H. Afifib a

Department of Computer Science, University College London, Gower Street, London WC1E 6BT, UK b 2004 route des Lucioles 06802, INRIA, Sophia Antipolis, Cedex, France Received 25 June 2001; accepted 25 March 2002

Abstract Cellular communications are aligning rapidly to adopt suitable network models for supporting packet switched services over IP networks. Pure third generation (3G) wireless architectures have already adopted IP as the network layer bearer within their core network component specification. This article presents an architecture and protocol in support of proactive mobility management for future IP radio access networks. It encompasses a novel approach for seamless handoff and proactive allocation of PDP context with respect to IP roaming state. The latter establishes a generic substrate for proactive state relocation of different context classes relating to the state of IP connectivity for a mobile node (MN). To address such form of IP mobility, the proposed model identifies a tentative mobility– routing matrix (TMM), which represents an accurate mapping between a mobility neighbourhood vector (MNV), surrounding the current GPRS-attachment point of an MN and the correct underlying routing neighbourhood vector (RNV), over arbitrary routing topologies. Sustained IP connectivity is achieved by introducing a 1-neighbour-lookahead (1-NL) view of PDP roaming state derived from the established TMM component; seamlessness is pursued through mapping of the 1-NL component to some handoff care-of address onto the IP Multicast domain; this allows abstracting a plurality of candidate care-of address instantiations of the MN onto a single handoff routing identifier. q 2003 Elsevier B.V. All rights reserved. Keywords: Proactive mobility; Seamlessness; Cell bounce effects; Ping-pong effects; Context transfer; State relocation; Handoff care-of address; Multicast; Mobility neighbourhood; Routing neighbourhood; PDP roaming state; Tentative mobility matrix

1. Introduction Advances in packet-switched wireless network technologies [1,2] and portable computing terminals [3] are reaching a stage of maturity; users expect convergence in the wireless/wired IP network infrastructure, enabling true diverse access capabilities: access ‘on the move’, global span, constant connectivity, uniform performance characteristics, seamlessness, IP transparency. In this engendered paradigm shift in traditional access practices emerging as mobile networking, users in command of portable wireless computing devices envisage fast and simple access through an abstract all-IP radio access network (RAN) [4]. * Corresponding author. Tel.: þ44-20-7679-3666; fax: þ 44-20-73871397. E-mail addresses: [email protected] (T. Pagtzis), p.kirstein@cs. ucl.ac.uk (P. Kirstein), [email protected] (S. Hailes), afifi@sophia. inria.fr (H. Afifi). 0140-3664/03/$ - see front matter q 2003 Elsevier B.V. All rights reserved. doi:10.1016/S0140-3664(03)00162-2

The vision remains however, as Internet and the developments in the mobile domain have fuelled only the first stage towards an all-IP radio access paradigm shift. Radio access technologies and standards are taking a very specific view of user needs disregarding the heterogeneous composition of current networks providing mobile access, be it 802.11 [5], Bluetooth [6], GSM [7], or UMTS [8]. As a result, discontinuous connectivity is considered currently the norm rather than the exception. It becomes evident that mobility goes far beyond the ability to effect communications while wireless or on the move. Instances of such discontinuity are manifested as mobile users associated with different wireless access networks, serve by another (or no) operator, or located under a different RAN environment. This presents a need to acquire many different terminals operating under different signalling and data protocols, whereas the sample applications are not guaranteed to be available on all of them. From the perspective of both the mobile network or application

1976

T. Pagtzis et al. / Computer Communications 26 (2003) 1975–1989

services the user remains wired rather than wireless, without the unifying properties of the IP layer abstraction, as a result of cross-standardisation disparity emergent between existing, new or forthcoming wireless access technologies. Abstracting the individual wireless access technology (cellular, WLAN, bluetooth, etc.) behind the notion of a network protocol such as the Internet protocol (IP) provides an open, unifying protocol substrate for transparent operation of current as well as future application services. In this fashion, vertical integration of new wireless access technologies can be IP-embedded successfully beyond the boundaries of a typical 3G core network (CN) [9], under the horizontal integration of the application domain. This can provide the safeguards for a practical open mobile system now, without dismissing existing wireless access technologies in favour of a truly open, universal wireless access standard [10], which is bound to lead to yet another lengthy as well as costly infrastructural network evolution exemplar. The benefits from all-IP based RAN architecture become instantly apparent: realistic potentials for a service-rich mobile domain; through IP the service creation cycle across the wireless technology spectrum, is shortened significantly, thus, cultivating economies of scale in introduction of new services. Significant savings on ownership and management across RAN infrastructures as signalling and the data are abstracted as IP flows rather than control and data channels. Capacity enhancement under an IP transport is easier and cheaper. In addition, an all-IP RAN, can prove an extremely efficient transition moderator towards a truly open wireless access standard towards advanced third (3G þ ) or subsequent fourth (4G) generation wireless networks. This is so because the radio access domain can be incrementally augmented with new wireless access technologies which over IP can still claim a fair share of the application services domain, while a universal wireless access technology [11] is being developed. 1.1. IP-RANs and real-time services Coupled with the notion of ubiquitous computing [12] and nomadic communications [13], all-IP RAN infrastructures and protocols enable a wealth of opportunities for novel kinds of user-level IP services in the application domain of interactive multimedia: navigation, personal locator services, interactive audio/video, telemetry and guidance. Real-time dissemination of multimedia information becomes, thus, of major importance, as mobile devices and users integrate information retrieval as a peripheral task of their ‘primary’ activity (driving, operating, pursuing, walking, or generally ‘acting’). These activities require bounded latencies if IP communications are to sustain real-time guarantees in terms of both acted task performance and supporting communicated information. It has been

shown extensively in Ref. [14], that for one-way delays in excess of 150 ms1 the quality of interactive audio/video traffic degrades significantly, while beyond 200 ms it is rendered unacceptable [15]. Towards all-IP mobile networking practices, Perkins [16] proposed extensions to protocol considerations for network-layer host mobility, originally devised by Ioannidis and Maguire [17], known as Mobile IP. Proposed as the dominant standard for mobile networking, Mobile IP effects a transparent mapping between the home IP address of a mobile node (MN) and a care-of IP address (CoA) acquired at the visited point of attachment; it is characterized as a reactive IP mobility protocol since IP connectivity provisions at a visited link are initiated upon detection of an incoming MN. Despite its wide acceptance, Mobile IP has been found [18], to be insufficient for support of real-time IP traffic. The specification for Mobile IP version 4 [19] restricts the MN in changing points of attachment not faster than once every 1000 ms. Over IPv6 networks, Mobile IP [20], continues to lack of support for delaysensitive IP traffic, due to network layer switching latencies incurred either by core IPv6 protocol functions or due to latency externalities impacting directly its reactive character. With respect to core IPv6 protocol functions, Finney and Scott [21] verify such deficiency by showing that, irrespective of the IPv6 router advertisement interval, the allocation of an IP address requires a minimum of 160 ms;2 such delay period is accounted from the moment that the IPv6 stack of the MN3 is notified for stateless address autoconfiguration until the moment that a Binding Update is transmitted. The above imply that allocation/activation of IPv6 addressing state generates by itself enough latency to place any active IPv6 flow on the boundaries of acceptable guarantees for real-time traffic delivery. IP addressing state is only one of the types of context required to admit an MN and its active IP flows into a visited network; for instance, security context may have to be reestablished prior to any packet flow transmissions: in the case of resource reservation for the purposes of Integrate Services QoS provisioning, the entire end-to-end path needs to be re-established at the new network link. For AAAbased admission control, credential verification must be effected with the home network prior to admission of the MN at the new network link. Each of these context states requires one or more round trip times in terms of protocol interactions at the new GPRS service node (GSN), or between visited and home network, before they are established; this is clearly beyond the control of core IPv6 1

More accurately around 200 ms. Assumes no duplicate address detection hits, which can worsen latency although very rarely. 3 This is orthogonal to any hardware optimizations at the access router, but implementation dependent on the IPv6 stack of the MN. 2

T. Pagtzis et al. / Computer Communications 26 (2003) 1975–1989

or reactive mobility protocols and as such expected to induce latencies that can impede adherence to guarantees for real-time delivery of IP traffic. To this end, we establish a model that promotes proactive IP mobility management mechanisms over future IPv6 RANs. Our mobility model argues that, IP mobility control cannot rely on the reactivity of the upcoming visited network when real-time delivery/transmission guarantees must be assured for active IP flows of a MN: this is far too slow as the node considers faster and less deterministic mobility patterns, especially in the light of state relocation for multiple classes or context. Instead, we propose that the network engages in proactive management and distribution of a MNs IP connectivity (or other context) state well in advance of its handoff transition. The rest of this paper is structured as follows: Section 2 gives an overview of the proactive IP mobility model. Section 3 describes the mechanism for management of the mapping between the mobility and routing. Section 4 presents the mechanism for brokering IP connectivity state to the MN. Section 5 elaborates on the abstraction of the MNs routing identifier for the purposes of handoff; Section 6 presents related work and a brief discussion on marked differences with the proposed mobility model. We conclude with a summary of the proposed seamless mobility model and future work in Section 7.

2. Proactive IP mobility model Primary function of any mobility management component in cellular networks is one of the location managements, including addressing and identification. Currently, in the UMTS RAN (UTRAN) component architecture, the location and addressing of a mobile node (MN) is managed through multiple identifiers that require consistent mapping between a number of functional entities; the location area identifier (LAI) effected within a single location area and managed by visited/home location register (VLR/HLR); the routing area identifier (RAI) effected within a routing area and managed by the service GPRS support node (SGSN) or radio network controller (RNC); the cell identifier (CI) managed by the RNC. The packet temporary subscriber identity (P-TMSI) identifying the relative location of the MN behind a service area and its corresponding SGSN. The set of aforementioned identities requires the existence of multiple protocols and a considerable number of message interactions to maintain consistent state. What is more, state inconsistencies require additional protocols to be invoked (e.g. paging) to either resolve the location of the MN or detach it from the network. Such complexity acts as an impediment towards the integration of different wireless technologies under a unifying IP-RAN. The proposed mobility management architecture considers as fundamental requirement for an all-IP based RAN that the standard IPv6 address is used as an addressing and

1977

routing identifier at MN instead of the P-TMSI identity that was allocated thus-far by the serving GSN (SGSN). In this manner, the location and routing of traffic for the MN can be managed within the IP-RAN by dynamic routing protocols effected at the RNC. IP dynamic routing is particularly important for inter-RNC routing and so requires that an RNC is further enhanced with IP routing capabilities for both unicast as well as multicast. As a result, the number of involved protocols4 within the RAN is reduced significantly, making the connectivity between RAN and the CN, simpler (no need for transport level tunnelling) but also interface-independent. User and signalling bearers can, thus, be effected as corresponding IP flows that are label-switched through the MPLS protocol [22]. From the perspective of the CN in an advanced terrestrial mobile system beyond 3G, it is essential that the creation, activation as well as update of packet data protocol (PDP) context for an MN can be effected also by the SGSN with no referral to the allocated GGSN for that MN. This calls for a unification of the relevant GGSN PDP management functions together with the existing SGSN functions into a common routing GPRS support node (RGSN) as shown in Fig. 1. The scope of a PDP IPv6 address allocated by the RGSN, is reduced to site-local routability within the serving public land mobile network (PLMN). Hierarchical IP mobility management is preserved since allocation of a GGSN is now effected per RGSN rather than per MN. Location management within the CN can be simplified by introducing extended domain name services (DNS) for home (HDNS) and visited (VDNS) PLMN network, in place of the HLR and VLR, respectively. The DNS hostname of the MN can be represented uniquely by appropriate mapping of the ITU-T E.164 numbering plan of PSTN/PLMN networks onto a fully qualified domain name. The above functional architecture allows us to focus on mobility management at the IP layer for both IP-RAN and CN subsystems. Reaching beyond traditional reactive IP mobility protocol semantics, the proposed IP mobility model comprises of a mobility-aware routing neighbourhood, communicating proactively PDP context with respect to the IP roaming state of the MN, effected over its corresponding mobility neighbourhood. A set of geographically adjacent5 coverage areas6 referred to as IP-cells, effect network connectivity for an MN over IP. One or more IP cells controlled by a single RNC comprise an IP-macrocell or cell-cluster. A group of neighbouring IP-macrocells and their controlling RNCs identify a single mobility neighbourhood. The IP routing function assumed at an RNC effects a single subnetwork behind and IP-macrocell. Thus, handover between 4

And hence control signalling. With some minimal overlap if the handoff transition is to be effected with no disruption in link connectivity. 6 Controlled by an equal number Iu mode access points (Node-B). 5

1978

T. Pagtzis et al. / Computer Communications 26 (2003) 1975–1989

Fig. 1. Functional architecture model for proactive IP mobility management.

individual cells within a cell-cluster is assumed to be handled by link-layer control functions and thus considered transparent at the IP layer; that is, from an IP perspective, a cell-cluster is considered simply a larger, continuous IP cell. For this reason the terms (IP-)cell and cell-cluster are used interchangeably with no effect to the semantics of the proposed model. The IP-cell where the MN resides temporally, is identified as the current cell while the surrounding cells are identified as neighbouring cells. One or more RNCs are controlled by a single routing GSN (RGSN) node over IP. The RGSN is responsible for creation, allocation and distribution of PDP context to the RNCs per MN, while the RNCs are responsible for relocation of PDP context between RNCs neighbours controlled by the same RGSN. The set of RGSNs corresponding to the constituent RNCs of the mobility neighbourhood is defined as the respective routing neighbourhood, depicted in Fig. 2. IP roaming state is defined as the IP addressing/registration state provided within the PDP context generated for an MN by an RGSN, and activated at an IP-cell/RNC within some mobility neighbourhood, to maintain constant network connectivity during its mobility pattern within that neighbourhood. Proactive IP mobility management, requires that a oneto-one mapping between the routing and its respective mobility neighbourhood must be identified. In this manner, each RGSN establishes an abstraction of routing state that is essential for IP handover transitions, of a GPRS-attached MN, to neighbouring IP-cells. The mobility-aware routing state, established through this mapping, enables a new perspective of per RNC-hop routing for the purposes of IP

mobility. Departing from the conventional notion of routing state that provides the next-hop route, mobility-routing state provides next-cell-hop routing information within a mobility neighbourhood, while the corresponding RGSNs are not necessarily adjacent to each other, within the network topology. Having identified its routing neighbourhood, the CURRENT RNC within the mobility neighbourhood can initiate a proactive PDP context state request for the GPRS-attached MN at its RNC neighbours, given an initialisation state for the particular context. PDP context pre-allocation requires that the CURRENT RNC brokers a set of PDP-tentative care-of addresses (PDP-tCoA) from its neighbouring RNCs, such that, they are topologically correct in its mobility neighbourhood. Each RNC neighbour subsequently submits the PDP initialisation state and its own network prefix in a proactive PDP context request directed to its controlling RGSN. The latter responds with the generated PDP context to the RNC request originator. The proactive PDP context is optionally checked against duplicates (DAD) and is then returned to the CURRENT RNC. For the purposes of seamless IP handover transitions for the MN, the CURRENT RNC associates the set of PDPtCoA with a Handoff Care-of Address (HCoA) allocated to the MN from the IPv6 multicast domain. The association of multiple unicast MN care-of addresses with the HCoA address is effected only at the CURRENT RNC; it is transparent from the perspective of the correspondent node peers of the MN. Group membership at eh HCoA address is effected explicitly from the CURRENT RNC and implicitly from its RNC neighbours. The latter is effected by means of indirect group membership management.

T. Pagtzis et al. / Computer Communications 26 (2003) 1975–1989

1979

Fig. 2. Routing neighbourhood and its underlying mobility neighbourhood.

3. Routing neighbourhood discovery A mobility neighbourhood k is represented by its mobility neighbourhood vector (MNV) denoted as mnvk ¼ {cell1 ; cell2 ; …; celln }

ð1Þ

where n is the number of IP-cells within that neighbourhood reachable from the current IP-cell controlled by RNCk : Similarly, the underlying routing neighbourhood of the aforementioned MNV vector with respect to the CURRENT RGSN defines the corresponding routing neighbourhood vector (RNV) denoted as rnvk ¼ {ðIP; PrefLen; LLAÞRGSNn ;

;celln [ mnvk }

ð2Þ

where IP identifies the IP address, PrefLen the prefix length and LLA the link layer address, all identifying the interface of the RGSN controlling RNCk ; in a tuple representing a unique RNV element. Each RGSN maintains its own rnv as a one-to-one mapping with the respective mnv of the cell currently visited by an MN. Essential for the purposes of proactive IP mobility management, is to identify the mapping between each cellmember of mnvk and the corresponding RGSN-member of rnvk ; this enables exchange of mobility-routing state between RGSN members in the mobility-enabled routing neighbourhood according to the underlying mnvk vector of the adjacent IP-cells. However, movement of the MN between adjacent IP-cells does not assume a direct link between their respective RGSNs; this is because hopadjacency between the RGSNs of the routing neighbourhood depends highly on the topology. For this reason

the proposed model assumes spanning-tree topologies over the mobility neighbourhood. Discovery of the MNV – RNV mapping is achieved by means of dynamic learning at two different levels: at the IPcell/RNC level (RAN) and at the RGSN level (CN). It is achieved by means of extending the standard IPv6 router advertisement received by an MN, with a message option that includes both the IPv6 addresses of the RNC and its controlling RGSN. This information is then conveyed proactively by the MN as it transits between different RNCs/RGSNs. In this manner, both the RNC and RGSN entities gather incrementally knowledge about the mapping between their respective mobility and RNVs. Dynamic learning of this type fits naturally to the movement of MNs, due to their temporal existence within coverage areas, while in transit towards a destination. To aid such mapping, each RNC maintains a pre-configured RNC tuple (RNCT), which identifies the capabilities effected at the controlled IP-cell/RNC and its cell constituents. It is denoted as RNCT ¼ {ðcelli d; ri ; RNCtype ; ½li ½Li ; …Þ}

ð3Þ

where ri is the nominal radius of the IP-cell with identity celli d; RNCtype is the form of the wireless technology effected, and optionally, li the latitude and Li its longitude position if available. The latter allows the mobility neighbourhood to be technology-independent; it further enables an MN with wireless interface diversity to utilise such capability information for the purpose of proactive vertical handovers. The RNC tuple can be expanded to include other types of capabilities effective within an IP-cell.

1980

T. Pagtzis et al. / Computer Communications 26 (2003) 1975–1989

Fig. 3. Temporal dynamic learning of RNV–MNV mapping.

3.1. Incremental MNV/RNV acquisition

3.2. Mobility –routing state convergence at RAN and CN

During transition between adjacent IPv6-enabled cells, the MN is expected to receive new router advertisements from the respective new RNCs. Discovery of adjacent IPcells through receipt of router advertisements initiates at the MN an exchange of mobility-routing state at two subsequent layers: the RNCs and the RGSNs comprising the MNV – RNV mapping. On receipt of a router advertisement, the MN checks its route prefix against any existing IP roaming state. If there is no match within its roaming state cache and after a GPRSattach, the MN provides the NEW RNC with a unicast indirect7 RNV Update message. This message contains the IP addresses of the PREVIOUS RNC/RGSN. Receipt of the indirect RNV Update by the NEW RNC, signifies that the PREVIOUS RNC is currently not aware that their IPcells are neighbouring. On receipt of this message the NEW RNC contacts the PREVIOUS RNC for a bilateral update of their RNC neighbour cache with their RNC tuple, through RNCT Update messages. Upon completion of the update the NEW RNC forwards the IP address of the PREVIOUS RGSN to its controlling RGSN for a similar bilateral update of their RGSN neighbour cache through direct RNV Update messages. As a result, each RNC maintains an accurate mapping of the respective routing neighbourhood. Fig. 3 shows the RNV Update handshake between the MN, the NEW and PREVIOUS RGSNs.

For mobility– routing to be efficient within a MNV – RNV mapping it is essential that each RNC (MNV-member) at RAN layer and each RGSN (RNV-member) at the CN layer, have a complete view, not only of their own vector but also of the vector for each of their neighbours. The importance of such view stems from the fact that neighbouring IP-cells maintain common mobility, and hence routing, sub-neighbourhoods (Fig. 4), which can only be deduced if each of the RNC/RGSN is aware of the MNV/RNV vector of their neighbours. That allows convergence in mobility– routing state aggregated within MNV/RNV members prior to any efficient form of proactive IP mobility management. To accomplish such convergence, when an RNC acquires its complete8 MNV vector, it proceeds to advertise it to the constituent RNC members of that vector. Alternatively each RNC can explicitly solicit the advertisement of the MNV from the vector’s members. Similarly, as soon as the RGSN acquires the complete9 RNV vector of its controlling mobility neighbourhood, it provides it through a (solicited) advertisement it to the members of that RNV vector. To enable such functions, two new instances of neighbourhood vector discovery (NVD) are introduced; one for mobility M-NVD at the RNC-level and one for routing R-NVD at the RGSN-level. At both RNC- and RGSN-level, the NVD process allows the complete set of

7 The message is considered indirect because it does not come directly from another RGSN.

8 9

No new RNCT Updates post a convergence threshold Trnc : No new RNV Updates past a convergence threshold Trgsn :

T. Pagtzis et al. / Computer Communications 26 (2003) 1975–1989

1981

Fig. 4. RNV propagation towards the edges of the mobility neighbourhood.

MNVs/RNVs for a single mobility/routing neighbourhood to be propagated from the centre towards the edges of that neighbourhood as shown in Fig. 4. The converged mobility –routing state within each RGSN of the routing neighbourhood comprises the tentative mobility – routing matrix (Fig. 5) enabling per mobility-hop routing in that routing neighbourhood. At the RAN-layer, the converged RNCT state effects the tentative capability matrix, enabling diversity between different wireless technologies for purposes such as vertical handoffs. In a manner similar to router advertisements in IPv6 [23], an MNV/RNV Advert is transmitted periodically at the RNC/RGSN neighbours. In addition, the transmission interval is adjusted by an exponential backoff until some maximum interval threshold TmaxRNVA. To effect responsiveness on sustained solicitations the backoff value is halved per RNV solicitation up to some minimum interval threshold TminRNVA.

Fig. 5. Mobility– routing state maintained in RNV at RGSN14.

4. PDP context pre-allocation at RGSN neighbours Having identified fully its routing neighbours, the CURRENT RNC can establish proactively PDP context state for the GPRS-attached MN at its RGSN neighbours, given an initialisation state for the particular context type. In particular, upon establishment of a GPRS-attach, and subsequent IP connectivity, the MN provides its CURRENT RNC with its link-layer address (LLA). The CURRENT RNC forwards this information to its RNC neighbours retrieved from its MNV cache, for the purposes of brokering a set of unique PDP unicast care-of addresses (CoA) for IPv6, from their controlling RGSNs; each of these IPv6 CoAs must be topologically correct in the IP-cell controlled by the respective RNC neighbour; the set of brokered IP addresses per MN comprise what is termed as PDP-tCoA tuple. The PDPtCoA tuple comprises the IP roaming state for the MN that enables roaming from the current IP cell to any cell neighbour of the same mobility neighbourhood. PDPtCoAs may be used during and after a potential handover transition with no delay. The LLA of the MN is unicast to all neighbouring RNCs in a Broker PDP Context Request control message. Each of the RNC nodes submits the LLA of the MN together with their own network prefix to their controlling RGSN into a proactive create PDP context request. Each of the receiving RGSNs is empowered with the CoA generation task within some PDP context in a statefull10 manner the RGSN neighbour combines the LLA [24] of the MN together with the network prefix of the originating RNC, into an IPv6 PDP-tCoA. 10 Alternatively the unicat message may be directed to an active server or to a router plug-in with DHCP functionality.

1982

T. Pagtzis et al. / Computer Communications 26 (2003) 1975–1989

Since the address is generated in a statefull fashion the RGSN responds back to the RNC request originator with proactive create PDP context response that contains at least the PDP-tCoA address; following generation of the PDPtCoA, the receiving RNC neighbour performs optionally duplicate address detection (DAD) [24] on that PDP-tCoA address. 4.1. Distribution of the tentative CoA With DAD completed, each neighbour RNC returns the tCoA into a unicast Broker PDP context Response message back to the CURRENT RNC of the MN. Each PDP-tCoA received in response to the MNs LLA sent, is grouped together in a PDP-tCoA tuple comprising part of the IP roaming state for the MN. Note that generation of tentative CoAs is distributed in the mobility neighbourhood, while the DAD function is optionally performed at the correct RNC once the PDP-tCoA has been generated. Thus, no signalling needs to be proxied between the CURRENT RGSN and its RGSN neighbours for either CoA generation of DAD. The CURRENT RNC injects the IP roaming state established, to the admitted MN, through a PDP context state push (PDP-CS-PSH). The message includes the number of RGSN neighbours providing such state, together with a unique PDP-tCoA tuple identifier associated with a respective Context State Cache (CS-Cache) entry at the CURRENT RNC. In addition to the PDP-tCoA tuple, the particular context state entry also includes the following information per RNC neighbour: † the IPv6 address of the neighbour RNC interface that effects the IP-cell within the mobility neighbourhood. It is required to update the default router list, as default router list entries that are provisionally effected during handover. † the prefix length for the neighbour RNC interface. Essential to derive link layer information for updating the MNs neighbour cache. Required to minimise or eliminate neighbour discovery signalling when the MN handovers to some RNC – RGSN neighbour. From this information the MN can further reconstruct other routing information that complement the IP roaming state for that mobility neighbourhood. This is: † the RNC neighbour link layer address. Derived by using the prefix length together with standard EUI-64 rules for interface identifier generation; alternatively it may be explicitly provided by the CURRENT RNC as stored in its MNV Cache. It is used in the neighbour cache of the MN, marked with the P flag (PROACTIVE) and set in the PROACTIVELY REACHABLE state. † the RNC neighbour routing prefix. By using the prefix length, determine the routing prefix of the RNC neighbour and populate the prefix list of the MN (Fig. 6).

Fig. 6. The proactive set of tentative CoAs provides 1-domain lookahead network connectivity.

The proposed model does not effect PDP-tCoA tuple generation at the MN. We argue against any dependence on the response of the MN back to the CURRENT RNC since it induces excessive overhead, especially from proxied signalling interactions for the purposes of either address configuration, neighbour discovery, DAD or other contextspecific action between the MN and RNC neighbours through the CURRENT RNC: proxied approaches of control signalling for IP mobility results in increased latency between the CURRENT RNC and the MN, that may be significantly affected in cases of corrupted/lossy channels due to harsh fading conditions.

5. Abstracting the MN routing identifier Upon generation of the PDP-tCoA tuple, the CURRENT RNC abstracts the tuple’s constituents onto a short-lived, globally routable, unified routing/addressing identifier, that is allocated for the MN: it is referred to as HCoA and is a multicast IPv6 address. It is assumed that all RNCs are multicast-enabled according to the IPv6 protocol architecture [25]. The mapping of the PDP-tCoA tuple onto a referred to as Handoff Core-of-Address (HCoA) is effected only at an RNC; it is transparent from the perspective of the CN or correspondent peers of an MN. Both HA and CNs send packets towards the MN through the CURRENT RGSN with no knowledge about the existence of a HCoA address. By mapping the PDP-tCoA tuple over a HCoA address as shown in Fig. 7, the CURRENT RNC allows the MN to receive traffic through any RNC neighbour in its mobility neighbourhood that is candidate for transition. This is achieved by effecting HCoA group membership reports for the individual PDP-tCoA instantiations of the MN allocated on the respective links of the RNC neighbours. Currently, the HCoA address allocation process takes place only once at the first RNC (home or visited) hosting

T. Pagtzis et al. / Computer Communications 26 (2003) 1975–1989

1983

Fig. 7. Mapping a multicast address to unicast IPv6 CoA listeners.

the MN. The proposed mobility model assumes unique allocation of a HcoA address; this aspect is pursued by protocol recommendations [26] from the IETF Multicast Address Allocation WG (MALLOC). Thus, an analysis on multicast address allocation is not of the scope of this article11. What is critical, however, is that the scope of the multicast group is as small as possible to minimize the probability of clashes in allocated multicast addresses. The proposed mobility protocol achieves that, by localizing the scope of the allocated multicast HcoA address within the mobility neighbourhood of the CURRENT RNC.

for that HCoA on the local link. In the case of the implicit join, the CURRENT RNC transmits an MLD membership report to each of the RNC neighbours, on behalf of the MN that may be visiting its link, since the MN is visiting the CURRENT RNC or cannot be on-link with all RNC neighbours: each of them, receiving an implicit ‘join’ message, need also enable multicast forwarding for the HCoA address over the link where the PDP-tCoA generated is topologically correct. Fig. 8 shows the case where an RNC neighbour (e.g. RNC6) has to enable group membership after receiving an implicit join solicitation from the CURRENT RNC (RNC0).

5.1. HCoA membership management 5.2. Need for indirect group management Upon allocation of the HCoA address, the CURRENT RNC must inform each RNC neighbour12 participating in the support of the PDP-tCoA tuple, to enable forwarding of traffic destined to the abstracted HCoA address; this is effected on RNCs’ downstream interface for which the allocated PDP-tCoA is valid, since there will be interest in that traffic by at least one host: the transiting MN. To inform itself the CURRENT RNC solicits an explicit ‘join’ from the MN, whereas informing the RNC neighbours requires the CURRENT RNC transmitting an implicit ‘join’ to the RNC neighbours, according to the multicast listener discovery (MLD) standard [27]. In explicit join, the CURRENT RNC solicits a membership report that must be explicitly sent by the MN to join the HCoA group. This is required to ensure that the MN configures its hardware interface for the particular HCoA address. This join solicitation is piggybacked in the CS-PSH message to the MN by means of a join-bit flag. The MN responds with an MLD membership report [27], that configures the multicast filter on its hardware interface [28], while the receiving RNC enables multicast forwarding 11

We investigate multicast address allocation and management issues for the purposes of this scheme in a separate paper. 12 Including itself.

From Fig. 8 it can be seen that an MLD Membership Report sent towards some RNC, e.g. RNC1, by the MN when on-link, normally reaches RNC1 through the linklocal CoA1 (LL-CoA1). However, in proactive IP mobility, RNC1 is an RNC neighbour with respect to the current location of the MN within the routing neighbourhood; thus, such report must now come through RL6 and then through RL4, since the MN is currently residing on-link with RNC0. To achieve this, the standard MLD mechanism must be extended to handle indirect listeners at RNC neighbours within a mobility neighbourhood. In particular, on receipt of an indirect join request, the receiving RNC neighbour sets an entry in its group membership list. The entry records the HCoA group and sets a timer for the membership to the Group_Membership_interval as per Ref. [29]. The receiving RNC then generates an indirect MLD Membership Query (I-MLD Query) with destination address the CURRENT RNC, the originator of the indirect join. The I-MLD Query message is a group-address-specific query and is periodic; that is, it targets membership on a specific HCoA group and is sent by some neighbour RNC querier every Query_interval. An I-MLD Query contains the HCoA address and

1984

T. Pagtzis et al. / Computer Communications 26 (2003) 1975–1989

Fig. 8. Link-local addresses used for conventional MLD messaging.

a maximum response delay time within which the CURRENT RNC must report back. On receipt of an I-MLD Query, the CURRENT RNC sets a delay timer adjusted according to Ref. [29]. On expiry, the CURRENT RNC transmits an Indirect MLD Membership Report (I-MLD Report) with destination IP address the query-originator RNC. This is shown in Fig. 9. Periodic I-MLD Query/Reports signal interactions refresh the timer set in the group membership list of the querier RNC neighbour. They also allow for robustness in signalling since if an initial report gets lost, membership can be recovered at the next query interval. If no I-MLD Reports for the HCoA are received by the latter after expiry of response delay of the indirect query, the neighbour RNC querier concludes that group membership for that HCoA must be removed from its list (link prune).

6. IP Handoff Management During its movement, the MN reaches some overlap area between the CURRENT RNC and one or more RNC neighbours. By then, IP roaming state has been fully configured at the MN and the routing neighbourhood so that during the next handoff transition the MN does not need to configure a new CoA, but simply activate one of the tentative CoAs as the primary one. A tendative CoA alternates between a high secondary and a low secondary; ‘high’ refers to the set of PDP-tCoAs

that are prime candidates for primary PDP-CoA activation; ‘low’ is considered the set of PDP-tCoAs that remain least likely to be activated. Ideally, the MN needs to detect the high secondary PDPtCoA prior to an IP handoff transition and then inform the CURRENT RNC (soon to transit to PREVIOUS state) about it. To achieve that, the proposed model introduces a mechanism for IP disconnection avoidance (IP-DA), currently handled through a pessimistic approach. The approach is pessimistic since it considers all surrounding RNC neighbours in the signalling interactions; on the contrary an optimistic includes in its signalling exchanges only the RNC neighbours that are considered highly probable candidates for an IP handoff.13 As the MN moves away from the cell of the CURRENT RNC, it crosses some overlap area between itself and a cell neighbour. In this overlap area the MN receives a different router advertisement from the one provided by the CURRENT RNC; this triggers a check of the received network prefix against the existing PDP tCoA tuple. The match between that prefix and a single PDP-tCoA promotes the particular PDP-tCoA as a ‘high’ secondary for the MN while signalling the CURRENT RNC with a HCoA-Enable (HCoA-E) message about the start of its IP handoff transition.14 Enabling the correct tendative CoA is essential for upstream transmissions from the MN to its peers. Unless 13 14

An ‘optimistic’ mechanism is currently under investigation. Trigger is link layer stimuli such as low SNR.

T. Pagtzis et al. / Computer Communications 26 (2003) 1975–1989

1985

Fig. 9. Periodic I-MLD messaging between RGSNs.

the correct PDP-tCoA is enabled the MN has no means of identifying which IP address, and default route to employ in transmitting upstream during a handoff transition; what is important, is that configuration of a topologically correct CoA is already in effect and thus, there no latency induced by IP address configuration. The HCoA-E message allows the MN to receive transparently IP traffic that is sent downstream towards the MN. On receipt of this message the CURRENT RNC forwards any IP traffic destined for the MN by tunneling it to the HCoA address, while it stops forwarding to the primary unicast CoA of the MN. The effect of the forwarding is controlled according to the established lifetime of the IP handoff of conveyed within the HCoA-E signal. Traffic sent towards the MN, is now forwarded by the CURRENT RNC as encapsulated multicast payload at the HCoA address of the MN; the CURRENT RNC encapsulates the received packet in a new IPv6 header with destination the HCoA group of the node if a HCoA-E signal has been received; otherwise, it applies standard unicast forwarding. Since the RNC neighbours are configured to forward traffic for the particular HCoA group in their cell, traffic destined to the MN can be received over any IP link (cell) in the mobility neighbourhood of the CURRENT RNC. This is because the configuration of the hardware interface (linklayer) multicast filter at the MN, does not depend on the unicast IP CoA allocated for the MN within the PDP context, but only on the last four octets of the HCoA. Thus,

all is required between the MN and an RNC neighbour is link-layer connectivity. Traffic will be destined to the HCoA group indefinitely; that is, until explicitly requested to suspend forwarding through the HCoA address. This is because the MN may bounce multiple times between neighbouring cells, shown in Fig. 10, causing oscillations in the signalling of HCoA activation/suspension at the CURRENT RNC. The MN continues to receive traffic over its HCoA until it attaches to some RNC neighbour plus a small random time period Te ; Te is introduced for the purposes of sustaining reception of traffic through HCoA during cell bouncing effects in the MNs movement pattern between its CURRENT RNC and a neighbouring RNC; The time period Te is referred to as Extended HCoA-Rx Time. The MN maintains also a cell-bounce accumulator (CBA) that tracks the number of bounces between two RNCs; CBA increases geometrically Te for each increment of its counter for the individual MN. The delay Te is bounded by an upper delay maximum, while its initial and maximum value is conditioned by the size of the overlap area between two cells and the speed of the mobile. When the extended HCoA-Rx time elapses and CBA counter has not increased, the MN sends a standard Binding Update to its peers (CNs and HA) to inform about the new, stable and topologically correct primary CoA (Fig. 11). At the same time the MN sends a HCoA-Disable (HCoA-D) message to the PREVIOUS RNC, through its new primary

1986

T. Pagtzis et al. / Computer Communications 26 (2003) 1975–1989

Fig. 10. Bouncing effects incorporated in the movement pattern of the MN.

CoA, to request suspension of traffic forwarding through the HCoA. The HCoA-D message contains the MNs HCoA address together with refreshed lifetimes establishing the end of the IP handoff.

6.1. PDP-tCoA tracking and cell-bounce accumulator The cell bounce accumulator (CBA) operates on the PDP-tCoA bitfield maintained by the MN. In this bitfield, the CBA tracks the CURRENT RNC by assigning a parent status to its primary CoA bit. Any bit within the tCoA bitfield is set to 1 when the MN matches the network prefix in a received IPv6 router advertisement (RT-advert), with the network identifier in some allocated tentative CoA from its tCoA tuple. The parent status is reset to the new primary CoA when a Binding Acknowledgement is received by the first communicating peer of the MN. Transition over some overlap (cell) area between the CURRENT RNC and some RNC neighbour(s), causes the MN to receive one or more new RT-advert messages originating from that RNC neighbour(s). Receipt of such messages trigger a flip of the respective tCoA bit to 1 within the bitfield. Similarly, lack of receipt of RT-advert messages

trigger a flip of the respective tCoA bit to 0 within the tCoA bitfield. When the number of received RT-adverts ðRxRT_advert Þ is reduced to one, the corresponding RNC neighbour becomes the immediate handoff candidate. At this stage the CBA compares the state of the tCoA bitfield for the new RNC candidate CBAsþ1 ; with the bitfield state of the previous RNC CBAs : An equilateral bit flip between CURRENT RNC and an RNC neighbour (i.e. CBAsþ1 – CBAs ) signifies a potentially clean handoff from the PREVIOUS RNC. However, the non-determinism of the mobility pattern of the MN does not allow a clear distinction between a clean handoff and an imminent cell bounce. For this reason, forwarding over the HCoA address is sustained for time Te : If within this time Te a different (new or old) router advertisement is received then a cell-bounce candidate is established; it is, however, considered only a candidate since it is not certain whether the MN will indeed move back to the PREVIOUS RNC or it is simply stretching movement in the overlap area. Movement oscillation between two cells (i.e. cellbounce) is considered to be imminent iff it occurs within the interval Te and manifests itself by means of a bitfield

T. Pagtzis et al. / Computer Communications 26 (2003) 1975–1989

1987

Fig. 11. MN activates the correct tendative CoA.

state CBAsþ2 ¼ CBAs : In this case, the CBA triggers a binary geometric backoff in the expiry of Te with a corresponding increase of this time period. CBA increases its counter and continues to track changes in the bitfield state by iterating the process. When a potential clean handoff sustains for Te with no increase in the CBA counter, it is considered to be a definite clean handoff; this triggers a HCoA-D message to be sent by the MN towards the PREVIOUS RNC. There is no handoff effected for a cell-bounce between the CURRENT RNC and any of its neighbours in the event that the MN returns back to the cell of the CURRENT RNC; it is only required to send the HCoA-D message to the CURRENT RNC such that the latter can suspend the forwarding over the HCoA group. In a definite clean handoff, before sending the HCoA-D message to the PREVIOUS RNC, the MN must: † Configure its PDP link-local address that is valid over the new link. Effect the correct primary PDP-CoA. † Send a neighbour advertisement to remove P-flag from the neighbour cache of the NEW RNC. † Send a Binding Update to its peers; at the same time set the parent flag to the new primary CoA in its PDP-tCoA bitfield.

† Reset CBA counter to 0 and continue parent tracking of the new CURRENT RNC.

7. Related work and discussion Recently, several protocols have been proposed in support of IP mobility for next generation (IPv6) wireless networks in support of seamless mobility. One of these is the fast handovers [30] proposal; it is similar to Ref. [31] approach with respect to the concept of pre-registration of the MN with other RGSNs that may be candidates for handover. Our proactive mobility model is significantly different from the fast handovers proposal for a number of reasons. Our mobility model does not employ proxy neighbour discovery messaging since tasks like duplicate address detection mandated by IPv6 Neighbour Discovery standard, require additional signalling which also induces delays of at least one RTT between the MN and every candidate RNC. Furthermore, our model caters for a candidate access router discovery algorithm. The fast handovers proposal has no such mechanism. This is an essential part for a seamless IP mobility model. In addition, our model provides

1988

T. Pagtzis et al. / Computer Communications 26 (2003) 1975–1989

a signalling substrate for proactive context transfers from RNC neighbours; the fast handovers proposal is explicitly designed towards seamless handovers only. What is more, the fast handover proposal lacks of robustness with respect to cell-bouncing effects (a.k.a ping-pong); this is because it assumes existence of multiple tunnels towards the MN from candidate RNCs. On the contrary, our scheme employs only a single tunnel which is effected over multicast; this ensure that the MN can freely bounce between any RNC within the mobility neighbourhood. Alternative approaches in Mobile IP have also been proposed in Refs. [32 – 34]. These schemes employ IPMulticast for addressing and forwarding of packets to MNs on an end-to-end basis; i.e. the source is destined at either the CN or the HA while MN is the receiver for the purposes of minimal latency handovers. To this end a small group ‘multicast’ solution has been proposed [35,36]. Both schemes utilize principles from Ref. [37] and they employ a multiple unicast destination option at the routing header of a packet. The schemes however, rely on the provision of all CoA destinations to the peer entities from the MN. The proactive mobility model is architecturally different from all the above schemes. In the majority of the mobility proposals, IP multicast is employed either end-to-end or as a pseudo-multicast mechanism where the protocol abstracts many unicast destinations as a source at the CN or HA. In the proposed mobility model IP multicast is employed locally with respect to the location of the MN (i.e. mobility neighbourhood). As such, none of the above schemes proposes a mechanism of establishing such mobility neighbourhood. Furthermore, there is no consideration in any of the proposed mobility mechanisms for state relocation with respect to multiple mobility contexts. Out abstraction of IP roaming state as a representative class of relocatable state context allows to populate the Context State cache with multiple contexts/capabilities that neighbour RNCs may need to provide to the CURRENT RNC towards the seamless movement of the MN in its mobility neighbourhood.

8. Conclusions and future work This paper presented a novel model for proactive IP mobility with respect to seamless transitions between different GPRS-attachment points. We have argued that configuring addressing state in reaction to a handover transition as effected by current mobile IPv6 mechanisms and protocols is not sufficient for satisfying IP connectivity in the light of real-time IP traffic delivery or transmission to/from mobile modes. We are currently working on a full scale simulation model of the proposed mobility model with full compliance over IPv6 protocol specifications. It is important to identify the optimum time intervals for HCoA address activation as well as the time period that HCoA group remains valid for the purposes of cell bouncing effects. We also investigate

the added complexity of signalling at the access routers by means of splitting parts of the protocol for PDP roaming state brokering onto an active server with IPv6 DHCP capabilities. Results from implemented simulations are currently work in progress and will be the objective of a following paper. Acknowledgements The authors would like to thank Jon Crowcroft and Bill Fenneer for their feedback on issues relating to IP Multicast. This work is supported by the EU 6WINIT/6NET research projects. References [1] H. Bolcskel, A. Paulraj, K. Hari, R. Nabar, W. Lu, Fixed broadband wireless access: state of the art, challenges, and future directions, IEEE Personal Communications 39 (1) (2001) 100– 108. [2] L. Bos, S. Leroy, Toward an all-IP-based UMTS system architecture, IEEE Network 15 (1) (2001) 36 –45. [3] A. Fasbender, F. Reichert, E. Geulen, J. Hjelm, T. Wierlemann, Any network, any terminal, anywhere, IEEE Personal Communications 6 (2) (1999) 22–30. [4] J. Kempf, IP in the RAN as a transport option in 3rd generation mobile systems, MWIF WG4: IP in the RAN Technical Report MWIF 2001.084, MWIF Forum (April 2001).. [5] T. Pagtzis, P. Kirstein, S. Hailes, Operational and fairness issues with connection-less traffic over IEEE802.11b, in: Proceedings of IEEE International Conference on Communications (ICC), 2001, pp. 176– 185.. [6] B. Forum, The Bluetooth Specification Section, www.bluetooth.com (September 2001).. [7] M. Mouly, M.B. Pautet, The GSM system for mobile communications, published by the authors (1992) ISBN 2-9507190-0-7.. [8] 3GPP, TSG Services and System Aspects; GPRS; Service Description; Stage 2 (Release 5) (June 2002).. [9] 3GPP, TSG Core Network; Mobile radio interface Layer 3 specification; Core Network protocols; Stage 3 (Release 5) (March 2002). [10] H. Luediger, User and business perspectives on an open mobile access standard, IEEE Communications (2000) 160–163. [11] A. Kountouris, C. Moy, L. Rambaud, P. Le Corre, A reconfigurable radio case study: a software based multi-standard transceiver for umts, gsm, edge and bluetooth, in: Proceedings of IEEE The Semi-annual Vehicular Technology Conference (VTC-Fall), 2001, pp. 1196– 1200. [12] R. Want, B. Schilit, N. Adams, R. Gold, K. Petersen, D. Goldbery, M. Ellis, M. Weiser, Mobile Computing, The ParcTab Ubiquitous Computing Experiment, Kluwer Academic Publishers, Dordrecht, 1997, pp. 45– 101. [13] T. La Porta, K. Sabnani, R. Gitlin, Challenges for nomadic computing: mobility management and wireless communications, ACM Journal in Mobile Networking and Applications 1 (1) (1996) 3 –16. [14] G. Karlsson, Quality requirements for multimedia network services, in: Proceedings of Radiovetenskap ach kommunikation, 1996, pp. 96– 100. [15] ITU-T Series G: Transmission system and media, digital systems and networks: One-way transmission time (May 2000). [16] C. Perkins, Mobile IP, IEEE Communication (1997) 84 –99. [17] J. Ioannidis, D. Duchamp, G.Q.J. Maguire, IP-based protocols for mobile interworking in: Proceedings of ACM SIGCOMM’91, 1991, pp. 235–245.

T. Pagtzis et al. / Computer Communications 26 (2003) 1975–1989 [18] R. Caceres, L. Iftode, The effects of mobility on reliable transport protocols, in: Proceedings of 14th International Conference on Distributed Computing Systems, 1994, pp. 12–20. [19] C. Perkins, IP Mobility Support, RFC 2002. Internet Engineering Task Force (October 1996). [20] C. Perkins, D. Johnson, Mobility support in IPv6 (work in progress), Internet draft, Internet Engineering Task Force (November 2001). [21] J. Finney, A. Scott, Implementing mobile IPv6 for multimedia, in: Proceedings of GEMISIS/IEE/BCS Symposium on Multimedia Network Technology, Vol. Digest No. G/MNT/1/1998, 1998, pp. 345–351. [22] E. Rosen, A. Viswanathan, R. Callon, Multiprotocol label switching architecture, Rfc 3031, Internet Engineering Task Force (January 2001). [23] T. Narten, E. Nordmark, W. Simpson, Neighbor discovery for IP Version 6 (IPv6), RFC 2461, Internet Engineering Task Force (December 1998). [24] S. Thomson, T. Narten, IPv6 Stateless Address Autoconfiguration, RFC 2462, Internet Engineering Task Force (December 1998). [25] S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, RFC 2460, Internet Engineering Task Force (December 1998). [26] S. Hanna, B. Patel, M. Shah, Multicast address dynamic client allocation protocol (MADCAP), REC 2730, Internet Engineering Task Force (December 1999). [27] S. Deering, W. Fenner, B. Haberman, Multicast listener discovery (MLD) for IPv6, RFC 2710. Internet Engineering Task Force (October 1999).

1989

[28] M. Crawford, Transmission of IPv6 packets over ethernet networks, RFC 2464, Internet Engineering Task Force (December 1998). [29] W. Fenner, Internet Group Management Protocol. Version 2, RFC 2236, Internet Engineering Task Force (November 1997). [30] C.P.G. Tsirtsis, A. Yegin, G. Dommety, K. El-Malki, Fast handovers for mobile IPv6 (work in progress), Internet draft, Internet Engineering Task Force (October 2001). [31] T. Pagtzis, P. Kirstein, A framework for proactive mobility in mobile IPv6 (work in progress), Internet Draft, draft-pagtzis-mobileipproactivev6-00.txt (May 2001). [32] S. Seshan, H. Balakrishnan, R. Katz, Handoffs in cellular wireless networks: the Daedalus implementation and experience, Kluwer International Journal on Wireless Communication Systems. January 1997. [33] A. Helmy, A multicast-based protocol for IP mobility support, in: International Workshop on Networked Group Communication (NGC2000), 2000, pp. 234–243. [34] J. Mysore, V. Bharghavan, A new multicasting-based architecture for internet host mobility, in: Proceedings of ACM MobinCom, 1997, pp. 267–278. [35] J. Lee, SGM support in Mobile IP (work in progress), Internet Draft (October 2000). [36] Y. Ezaki, Y. Imai, Mobile IPv6 handoff by Explicit Multicast (work in Progress) (May 2001). [37] R. Boivie, N. Feldman, Small Group Multicast (work in progress) (February 2001).