project number: ist-2000-25394 project title: moby dick...

CEC Deliverable Number 1 / 80

Project Number: IST-2000-25394

Project Title: Moby Dick

Deliverable Nature: Specification

Security Class: Program Participants

Document Type: Deliverable

CEC Deliverable Number: ....

Contractual Date of Delivery to the CEC:

Actual Date of Delivery to the CEC:

Document Title: D0301Source Workpackage/Activity:

Editor: (Author) M. Liebsch

Authors: The WP3 consortium

Status / Issue: Milestone M3.1

Date Last changes: 26.10.01

File: M3.1-D0101-AppendixB.doc

Abstract :

Specification of the Moby Dick Mobility Architecture

Keywords: (Keywords)

Mobile IPv6, Seamless Handover, Inter-technology handover, Paging Support, Simulative study

M3.1-D0101-AppendixB.doc M3.1 1.11.2001


Executive Summary This document specifies the Moby Dick architecture, components and protocols for IP based mobility management. The generic mobility management covers global as well as local mobility management. It is based on the basic Mobile IPv6 protocol and uses enhancements wherever the basic protocol is insufficient for the required functions. Furthermore, handover is specified for the access technologies covered in the project. This includes the specification, modification and enhancement of the access technologies as supported within the framework of the Moby Dick project.

To support the requirements specified for the Moby Dick architecture, well-proven networking technologies like Ethernet or wireless LAN IEEE802.11 are taken over for wired and wireless access provision. These may require modification and enhancement for the implementation in the project. The W-CDMA access technology as specified within the framework of 3GPP is not optimised for IP traffic, but rather allows IP transport in a complex and proprietary way. The project consortium will need to solve additional challenges of optimising the W-CDMA access technology and the respective radio protocol stack for IP traffic. All interface technologies have to be integrated with the Moby Dick network infrastructure in a way that they perform well and support the mechanisms for optimised mobility management and paging as specified within the framework of the project.

While specifying the support of mechanisms for inter- and intra-technology mobility as well as inter- and intra administrative domain mobility with a given handover quality, the mobility Work Package cannot ignore Quality of Service and security related mechanisms. Common areas must be co-ordinated and managed to appropriately integrate all solutions with the entire Moby Dick infrastructure.



Authors

Partner Name Phone / Fax / E-mail

01 T-Nova Serge Tessier Phone: +49 (0)30 – 3497 -3114 Fax: +49 (0)30 – 3497 -3199 E-mail: [email protected]

02 NEC Marco Liebsch Phone: +49 (0)6221 – 13708 – 19 Xavier Pérez Fax: +49 (0)6221 – 13708 – 28 Amardeo Sarma E-mail: [email protected] Ralf Schmitz

03 UC3M Ignacio Soto Phone: + 34 91 624 5974 Fax: + 34 91 624 8749 E-mail: [email protected]

05 USTUTT Marco Boldt Phone: +49 (0)711 685 7991 Wenhui Zhang Fax: +49 (0)711 685 7983 E-mail: [email protected]

07 PTIN Victor Marques Phone: +351 234 403654 Rui Aguiar Fax: +351 234 420722 E-mail: [email protected]

08 CRM Christophe Janneteau Phone: +33 (0)1 69 35 25 48 Alexis Olivereau Fax: +33 (0)1 69 35 25 01 E-mail: [email protected]

09 EURECOM Michelle Wetterwald Phone: +33-493.00.26.31 Fax: +33-493.00.26.27 E-mail: [email protected]



Table of Contents

1. ABBREVIATIONS ........................................................................................ 7

2. ABSTRACT.................................................................................................. 8

3. TERMINOLOGY........................................................................................... 8

3.1 Definitions....................................................................................................................................8 3.1.1 Network Components ...........................................................................................................8 3.1.2 Handover Terminology.........................................................................................................9

3.1.2.1 Scope of Handover..........................................................................................................10 3.1.2.2 Technologies and Network Interfaces.............................................................................10 3.1.2.3 Handover Control............................................................................................................11 3.1.2.4 Simultaneous connectivity to Access Routers.................................................................11 3.1.2.5 Performance and Functional Requirements ....................................................................11

3.1.3 Micro diversity, Macro diversity and IP diversity ..............................................................12 3.1.4 Mobile Host States and Modes ...........................................................................................12 3.1.5 User, Personal and Host Mobility .......................................................................................13 3.1.6 Macro and Micro Mobility..................................................................................................13

4. INTRODUCTION ........................................................................................ 14

5. OVERVIEW ................................................................................................ 15

5.1 General architecture integrating mobility ..............................................................................15

5.2 Relation to standardisation bodies ..........................................................................................16 5.2.1 IETF....................................................................................................................................17

5.2.1.1 Seamoby IETF Working Group ......................................................................................17 5.2.1.2 Mobile IP ........................................................................................................................18

5.2.2 3GPP and 3GPP2 ................................................................................................................27 5.2.2.1 Introduction.....................................................................................................................27 5.2.2.2 3GPP2 overview .............................................................................................................27 5.2.2.3 Relation between 3GPP2 and the IETF...........................................................................29 5.2.2.4 Relation with Moby Dick................................................................................................30

5.2.3 MWIF..................................................................................................................................30 5.2.3.1 Introduction.....................................................................................................................30 5.2.3.2 Relation to Moby Dick....................................................................................................31

6. REQUIREMENTS AND RELATED COMPONENTS.................................. 32

6.1 Overview of requirements ........................................................................................................32 6.1.1 Mobility Management.........................................................................................................32 6.1.2 Handover support ................................................................................................................32 6.1.3 Access technology issues ....................................................................................................33

6.1.3.1 General requirements ......................................................................................................33 6.1.3.2 IEEE802.3.......................................................................................................................35 6.1.3.3 IEEE802.11.....................................................................................................................35 6.1.3.4 W-CDMA .......................................................................................................................35

6.1.4 Idle Mode Support ..............................................................................................................36 6.1.5 Diversity..............................................................................................................................37 6.1.6 QoS related areas of Mobility .............................................................................................37 6.1.7 AAAC related areas of Mobility.........................................................................................40



6.2 Overview of related components .............................................................................................42 6.2.1 General components............................................................................................................42 6.2.2 Global Mobility Management .............................................................................................42 6.2.3 Localised Mobility Management ........................................................................................43

7. EVALUATION AND SPECIFICATION OF COMPONENTS ...................... 44

7.1 Integration of Access technologies...........................................................................................44 7.1.1 IEEE802.3...........................................................................................................................44 7.1.2 IEEE802.11.........................................................................................................................44 7.1.3 W-CDMA ...........................................................................................................................46

7.2 Simulative study of the mobility architecture.........................................................................46 7.2.1 Specification of the micro-mobility simulation environment .............................................46

7.2.1.1 Micro-mobility specification...........................................................................................47 7.2.1.2 Identification of parameters ............................................................................................47

7.2.2 Simulation for Macro-Diversity Usage in Moby Dick........................................................48 7.2.2.1 User Mobile Behaviour ...................................................................................................48 7.2.2.2 Network Topology ..........................................................................................................48 7.2.2.3 Service Scenario..............................................................................................................49 7.2.2.4 Macro-Diversity Scenario ...............................................................................................49 7.2.2.5 Problem of Interest and Future Work..............................................................................50

7.2.3 Evaluation via simulation....................................................................................................50

7.3 Mobility Management ..............................................................................................................50 7.3.1 Inter-administrative domain mobility .................................................................................50

7.3.1.1 Fast Handover Support....................................................................................................50 7.3.2 Intra-administrative domain mobility .................................................................................51

7.3.2.1 Fast Handover Support....................................................................................................51

7.4 Care-of Address Acquirement .................................................................................................56 7.4.1 Assumptions........................................................................................................................56

7.4.1.1 System information broadcast.........................................................................................56 7.4.1.2 System information scanning..........................................................................................56

7.4.2 Overview and comparison of mechanisms..........................................................................57 7.4.2.1 Stateful care-of address configuration.............................................................................57 7.4.2.2 Stateless care-of address configuration ...........................................................................59 7.4.2.3 Proposal comparison and evaluation...............................................................................60

7.4.3 Conclusion ..........................................................................................................................61

7.5 Paging support ..........................................................................................................................62 7.5.1 General overview of the mechanism...................................................................................62 7.5.2 Design goals........................................................................................................................63 7.5.3 Design specifics ..................................................................................................................65

7.5.3.1 Classification of access technologies ..............................................................................65 7.5.3.2 Implication on Access Routers........................................................................................65 7.5.3.3 Specification of the Paging Agent...................................................................................66 7.5.3.4 Addressing idle Mobile Nodes........................................................................................68 7.5.3.5 Distribution of Paging Request messages .......................................................................68 7.5.3.6 Protocol specifics ............................................................................................................69

8. ASPECTS ON SOFTWARE AND OPERATING SYSTEM ........................ 69

8.1 Mobile Terminal........................................................................................................................69 8.1.1 Functions.............................................................................................................................69 8.1.2 Mobile Terminal Software Architecture .............................................................................69

8.1.2.1 Functional elements ........................................................................................................71 8.1.2.2 Interface definitions ........................................................................................................72

8.1.3 Mobile Terminal IPv6 stack and Operating System ...........................................................73



8.2 Radio Gateway ..........................................................................................................................73 8.2.1 Functions.............................................................................................................................73 8.2.2 Radio Gateway Software Architecture................................................................................73

8.2.2.1 Functional elements ........................................................................................................74 8.2.3 Radio Gateway IPv6 stack and Operating System..............................................................74

8.3 Access Router ............................................................................................................................74 8.3.1 Functions.............................................................................................................................74 8.3.2 Operating System................................................................................................................75

8.4 Wireless LAN Access Router ...................................................................................................75 8.4.1 Functions.............................................................................................................................75 8.4.2 Operating System................................................................................................................75

8.5 Router ........................................................................................................................................75 8.5.1 Functions.............................................................................................................................75 8.5.2 Operating System................................................................................................................75

8.6 Home Agent ...............................................................................................................................75 8.6.1 Functions.............................................................................................................................75 8.6.2 Operating System................................................................................................................76

8.7 Paging Agent .............................................................................................................................76 8.7.1 Functions.............................................................................................................................76 8.7.2 Operating System................................................................................................................76

8.8 Paging Agent Local ...................................................................................................................76 8.8.1 Functions.............................................................................................................................76 8.8.2 Operating System................................................................................................................76

8.9 AAAC server .............................................................................................................................76 8.9.1 Functions.............................................................................................................................76 8.9.2 Operating System................................................................................................................76

8.10 QoS Broker ................................................................................................................................77 8.10.1 Functions.............................................................................................................................77 8.10.2 Operating System................................................................................................................77

8.11 Correspondent Node.................................................................................................................77 8.11.1 Functions.............................................................................................................................77 8.11.2 Operating System................................................................................................................77

9. REFERENCES ........................................................................................... 78



1. Abbreviations

Abbreviation Full Name AAAF(domain) Foreign AAA server AAAP Private/Personal AAA server AR Access Router AS Access Stratum BMC Broadcast / Multicast Control CN Correspondent Node CoA Care-of Address CT Context Transfer DoS Denial of Service GMA Gateway Mobility Agent HA Home Agent HMIP Hierarchical MIP IMSI International Mobile Subscriber ID MAC Medium Access Control MAP Mobility Anchor Point MN Mobile Node MT Mobile Terminal NAI Network Access Identifier NAS Non Access Stratum ODMA On Demand Multiple Access PA Paging Agent PDCP Packet Data Convergence Protocol PDU Protocol Data Unit PLMN Public Land Mobile Network QoSB (domain) Quality of Server Broker including a policy server RB Radio Bearer RG Radio Gateway RLC Radio Link Control RNS(domain) Radio Network Server RR(subnet) Radio Router for a specific sub network RRC Radio Resource Control SAR Serving Access Router SIB System Information Block UE User Equipment UMTS Universal Mobile Telecommunications System



2. Abstract The architecture to be specified within the framework of the IST-2000-25394 project Moby Dick defines an environment providing mobility for end-devices and end-users having access to the infrastructure through different interfaces. These interfaces are wired Ethernet IEEE802.3 as well as wireless access technologies, in particular wireless LAN IEEE802.11 and UMTS-like W-CDMA for this project test-environment and field trial. The infrastructure for user-data and signalling packet transport is entirely based on the new generation Internet protocol IPv6 and makes use of possibly enhanced standard IP equipment rather than keeping specific equipment as specified for instance within the framework of 3GPP for building up the UMTS architecture. For access to the infrastructure, the architecture provides end-to-end Quality of Service as well as security enabled access with charging functionality for data packet transport. This document focuses on the project’s mobility management specifics with respect to the architecture, which covers the end devices, wired and wireless access technologies, the intermediate nodes building up the access network and the backbone, as well as on the related protocols for mobility management and enhancements. Based on related work going on especially in the IETF, but also having other standardisation groups issues in mind, the protocols for IPv6-based mobility management in the back-bone as well as for local mobility management, for provision of paging service and for fast handoff support are evaluated and enhanced in order to meet the requirements of the project.

3. Terminology This section presents a terminology to be used for documents and discussions within the Moby Dick project regarding Mobility activities (WP3). Other Work Packages may also take advantage of this terminology in order to create a common terminology for their area. Some other forums or projects are currently working over common terminology (IST BRAIN) (IETF SEAMOBY WG). In order to avoid Moby Dick re-inventing the wheel, this document is indeed a simple collection of what has been produced so far in those or other areas. It is not only for facility reasons that we re-use almost entirely the job done in [1] but also because it was not so easy to consider other sources. It is indeed difficult to mix different sources when trying to build a language since one source only uses its own material to build its definition and is therefore auto-sufficient. If other sources are mentioned they are in bold. The work achieved in [1] was also adopted among different forums and seems to be a rather non-partisan solution.

3.1 Definitions

3.1.1 Network Components Note: The fundamental new concept to be introduced is that of the Access Network (AN), which supports enhanced mobility. It is a working assumption that to support routing and QoS for mobile devices, we need specialised routing functions (i.e. not OSPF or other standard IGPs) which are used to maintain forwarding information for these devices as they move physically. These functions are implemented in IP routers with this additional capability. We can distinguish three types of these: Access Routers (AR), which handle the last hop to the mobile; Access Network Gateways (ANG), which form the boundary on the fixed network side and shield the fixed network from the specialised routing protocols; and (optionally) internal Access Network Routers, which may also be needed in some cases to support the protocols. The Access Network consists of the equipment needed to support this specialised routing, i.e. AR/ANG/ANR. Mobile Node (MN) An IP node capable of changing its point of attachment to the network. The Mobile Node may have routing functionality. Mobile Host (MH) An IP node capable of changing its point of attachment to the network. The Mobile Host only refers to an end-host without routing support. Access Link (AL) A facility or medium over which a Mobile Host and an Access Point can communicate at the link layer, i.e., the layer immediately below IP.



Access Point (AP) An Access Point is a layer 2 device that is connected to an Access Router and offers the wireless link connection to the Mobile Host. Access Points are sometimes called 'base stations' or 'access point transceivers'. An Access Point may be a separate entity or co- located with an Access Router. Access Network Router (ANR) An IP router in the Access Network. An Access Network Router may include Access Network specific functionality, for example, on mobility and/or QoS. This is to distinguish between ordinary routers and routers that have Access Network-related special functionality. Access Router (AR) An Access Network Router residing on the edge of an Access Network and connected to one or more access points. An Access Router offers IP connectivity to MHs. The Access Router may include intelligence beyond a simple forwarding service offered by ordinary IP routers. Access Network Gateway (ANG) An Access Network Gateway that separates an Access Network from other IP-networks. An Access Router and an Access Network Gateway may be the same physical node. The Access Network Gateway looks to the fixed network like a standard IP router. Access Network (AN) An IP network which includes one or more Access Network Routers. The terms Access Network and (administrative) domain are often used interchangeably (e.g., "intra-AN" is "intra-domain") since often an Access Network has its own administration. Serving Access Router (SAR) The Access Router currently offering the connectivity to the Mobile Host. This is usually the point of departure for the Mobile Host as it makes its way towards a new Access Router (then Serving Access Router takes the role of the Old Access Router). There may be several Serving Access Routers serving the Mobile Host at the same time. Old Access Router (OAR) An Access Router that offered connectivity to the Mobile Host prior to a handover. This is the Serving Access Router that will cease or has ceased to offer connectivity to the Mobile Host. Another term is Previous Access Router. New Access Router (NAR) The Access Router that offers connectivity to the Mobile Host after a handover. Candidate Access Router (CAR) An Access Router to which the Mobile Host may move next. A handover scheme may support several Candidate Access Routers.

3.1.2 Handover Terminology These terms refer to different approaches to supporting different aspects of mobility. - Roaming refers to a particular aspect of user mobility. Roaming is an operator-based term involving

formal agreements between operators that allow a mobile to get connectivity from a foreign network. Roaming includes, for example, the functionality by which users can communicate their identity to the local AN so that inter-AN agreements can be activated, and service and applications in the MH's home network can be made available to the user locally.

- Handover (also known as handoff) is the process involved when an active MH (in the Active State, see section 2.4) changes its point of attachment to the network, or when such a change is attempted. The access network may provide particular capabilities to minimise the interruption to sessions in progress. There are different types of handover classified according to different aspects involved in the handover. Some of this terminology follows the description of [6].



The following figure presents a basic IP handover [10]

Figure 1

3.1.2.1 Scope of Handover - Layer 2 Handover: When a MH changes APs (or some other aspect of the radio channel) connected

to the same AR's interface then a layer 2 handover occurs. This type of handover is transparent to the routing at the IP layer (or it appears simply as a link layer reconfiguration without any mobility implications).

- Intra-AR Handover: This is a handover, which changes the AR's IP- layer's interface to the mobile. This causes routing changes internal to the AR. The IP-address by which the MH is reachable does not change.

- Intra-AN Handover: When the MH changes ARs inside the same AN, then this handover occurs. Such a handover is not necessarily visible outside the AN. In case the ANG serving the MH changes, this handover is seen outside the AN due to a change in the routing paths. The IP- address by which the MH is reachable does not change. Note that the ANG may change for only some of the MH's data flows.

- Inter-AN Handover: When the MH moves to a new AN then this handover occurs. This requires some sort of host mobility across ANs, which has to be provided by the external IP core. Note that this would have to involve the assignment of a new IP address to the MH.

In Moby Dick, Inter AN Handover is a special matter of interest when considering the case of ANs belonging themselves to different domains. The handover is then also labelled inter-domain handover and it needs associated registration procedures to be completed. Those additional procedures are not stricto sensu mobility specific, but Moby Dick's further work will be focused on this aspect (see Moby Dick deliverable [D0101] for a larger picture).

3.1.2.2 Technologies and Network Interfaces - Intra-technology Handover: A handover between equipment of the same technology. Layer 2

handovers are necessarily intra-technology. - Inter-technology Handover: A handover between equipment of different technologies.

- Inter-technology Handover: A handover between equipment of different technologies. - Horizontal Handover: from the IP point of view a horizontal handover happens if the MH

communicates with the OAR and NAR via the same network interface. Horizontal handover is typically also an intra-technology handover, but it can be an inter-technology handover if the MH can do a handover between two different technologies without changing the network interface seen by the IP layer.

- Vertical Handover: in a vertical handover the MH's network interface to the Access Network changes. Vertical handover is typically an inter-technology handover, but it may also be an intra- technology handover if the MH has several interfaces of the same type. The different handover types defined in this section and in section 3.1.2.1 have no direct relationship. In particular, a MH can do an intra-AN handover of any of types defined above.

IP Network

MN

MN

OAR

NAR

CN



3.1.2.3 Handover Control A handover must be one of the following two types (a): - Mobile-initiated Handover: the MH is the one that makes the initial decision to initiate the handover. - Network-initiated Handover: the network makes the initial decision to initiate the handover. A handover is also one of the following two types (b): - Mobile-controlled Handover (MCHO): the MH has the primary control over the handover process. - Network-controlled Handover (NCHO): the network has the primary control over the handover

process. A handover may also be either of these two types (c): - Mobile-assisted handover: information and measurement from the MH are used to decide on the

execution of a handover. - Network-assisted handover: a handover where the AN collects information that can be used in a

handover decision. A handover is also one of the following two types (d): - Backward handover: a handover either initiated by the OAR, or where the MH initiates a handover

via the OAR. - Forward handover: a handover either initiated by the NAR, or where the MH initiates a handover

via the NAR. The handover is also either proactive or reactive (e): - Planned handover: a proactive (expected) handover where some signalling can be done in advance

of the MH getting connected to the new AR, e.g. building a temporary tunnel from the old AR to the new AR. Generally this is a result of a backward handover. –

- Unplanned handover: a reactive (unexpected) handover, where no signalling is done in advance of the MH's move of the OAR to the new AR. Generally this results from a forward handover.

The five handover types (a-e) are orthogonal. Type 'c' may be present in a handover, the other types are always present.

3.1.2.4 Simultaneous connectivity to Access Routers - Make-before-break handover (MBB): During a MBB handover the MH can communicate

simultaneously with the old and new AR. This should not be confused with "soft handover" which relies on macro diversity. The communication with the new Access Router can be done through the access provided by the old AR in order to prepare and pre-configure new link communication specifics in advance.

- Break-before-make handover (BBM): During a BBM handover the MH does not communicate simultaneously with the old and the new AR.

3.1.2.5 Performance and Functional Requirements - Handover Latency: Handover latency is the time difference between when a MH is last able to send

and/or receive an IP packet by way of the OAR, until when the MH is able to send and/or receive an IP packet through the NAR. Adapted from [6]

- Smooth handover: A handover that aims primarily to minimise packet loss, with no explicit concern for additional delays in packet forwarding.

- Fast handover: A handover that aims primarily to minimise delay, with no explicit interest in packet loss.

- Seamless handover: A handover that is both, smooth and fast, thus provides fast handover between two ARs with the extra requirement not to introduce additional packet loss. This is in order to make connections not less reliable when having a handover than connections without a handover.



- Context-aware Handover: A handover that is governed by a certain specific requirement to be fulfilled while handing the connection between two ARs.

3.1.3 Micro diversity, Macro diversity and IP diversity Certain air interfaces (e.g. UTRAN FDD mode) require or at least support the concept of macro diversity combining. Essentially, this refers to the fact that a single MH is able to send and receive over two independent radio channels ('diversity branches') at the same time; the information received over different branches is compared and that from the better branch passed to the upper layers. This can be used both to improve overall performance, and to provide a seamless type of handover at layer 2, since a new branch can be added before the old is deleted. See also [5]. It is necessary to differentiate between combining/diversity that occurs layer 1/2 (physical and radio link layers) where the relevant unit of data is the radio frame, and that which occurs at layer 3, the network layer, where what is considered is the IP packet itself. In the following definition micro- and macro diversity refers to L1/L2 and IP diversity refers to L3. - Micro diversity is the term used for the case where, for example, two antennas on the same

transmitter send the same signal to a receiver over a slightly different path to overcome fading. - Macro diversity takes place when the duplicating / combining actions take place over multiple APs,

possibly attached to different ARs. This may require support from the network layer to move the radio frames between the base stations and a central combining point.

- IP diversity means the splitting and combining of packets at the IP level.

3.1.4 Mobile Host States and Modes Mobile systems may employ the use of MH states in order to operate more efficiently without degrading the performance of the system. The term 'mode' is also common and means the same as 'state'. A MH is always in one of the following three states: - Active State is when the AN knows the MH's SAR and the MH can send and receive IP packets. The

AL may not be active, but the radio layer is able to establish one without assistance from the network layer. The MH has an IP address assigned.

- Idle State is when the AN knows the MH's Paging Area, but the MH has no SAR and so packets cannot be delivered to the MH without the AN initiating paging. This state is also sometimes defined as Dormant Mode [10] - a state in which a mobile can not receive IP packets, but may still be able to receive L2 signalling related to tracking the mobile's location. A mobile may transition out of dormant mode due to a lower layer interface message (possibly triggered by receipt of an IP packet) or a timer expiration. A dormant terminal may signal to the network when it changes paging area, but may delay the signal until the next time it wakes up (if, for example, the mobile is using a time-slotted dormant mode algorithm). Note that a terminal, which is continuously listening to L2 for receipt of L3 packets is not in dormant mode.

- Detached State is when the MH is in neither the Active nor Idle State. The MH does not have an IP address from the AN.

- Paging is a procedure initiated by the Access Network to move an Idle MH into the Active State. As a result of paging, the MH establishes a SAR and the IP routes are set up.

- Location updating is a procedure initiated by the MH, by which it informs the AN that it has moved into a new paging area.

- A Paging Area is a part of the Access Network, typically containing a number of ARs/APs, which corresponds to some geographical area. The AN keeps and updates a list of all the Idle MHs present in the area. If the MH is within the radio coverage of the area it will be able to receive paging messages sent within that Paging Area.

Note: in fact, as well as the MH is in one of these three states, the AN also stores which state it believes the MH is in. Normally these are consistent; the definitions above assume so.



3.1.5 User, Personal and Host Mobility Different sorts of mobility management may be required of a mobile system. We can differentiate between user, personal and host mobility. - User mobility: refers to the ability of a user to access services from different physical hosts. This

usually means that the user has an account on these different hosts or that a host does not restrict users from using the host to access services.

- Personal mobility: complements user mobility with the ability to track the user's location and provide the users current location to allow sessions to be initiated by and towards the user by anyone on any other network. Personal mobility is also concerned with enabling associated security, billing and service subscription authorisation made between administrative domains.

- Host mobility: refers to the function of allowing a mobile host to change its point of attachment to the network, without interrupting IP packet delivery to/from that host. There may be different sub- functions depending on what the current level of service is being provided; in particular, support for host mobility usually implies active and idle modes of operation, depending on whether the host has any current sessions or not. Access Network procedures are required to keep track of the current point of attachment of all the MHs or establish it at will. Accurate location and routing procedures are required in order to maintain the integrity of the communication. Host mobility is often called 'terminal mobility'.

3.1.6 Macro and Micro Mobility Macro and micro mobility refer to host mobility in wide and local geographical area. Correspondingly, macro- and micro-mobility management refers to the scope of protocol operations in mobility management. - Macro mobility refers literally to 'mobility over a large area'. This includes mobility support and

associated address registration procedures that are needed when a mobile host moves between IP domains. Inter-AN handovers typically involve macro-mobility protocols. Mobile-IP can be seen as a means to provide macro mobility.

- Micro mobility refers to 'mobility over a small area'. Usually this means mobility within an IP domain with an emphasis on support for active mode using handover, although it may include idle mode procedures also. Micro-mobility protocols exploit the locality of movement by confining movement related changes and signalling to the access network.

From a pure IP point of view and historically, micro mobility movements refer to the ones happening when the HA is not involved in the location update. [10] gives therefore the following definition: Micro mobility is the ability for a Mobile Node to move without notifying its Home Agent. For the purposes of this draft, macro mobility is when the Mobile Node's Home Agent is notified of any movement, or simply conventional Mobile IP.



4. Introduction The architecture to be specified within the framework of the IST-2000-25394 project Moby Dick defines an environment providing mobility for end-devices and end-users having access to the infrastructure through different interfaces. These interfaces are wired access through the Ethernet IEEE802.3 interface as well as wireless access technologies, in particular wireless LAN IEEE802.11 and UMTS-like W-CDMA for this projects test-environment and field trial. The infrastructure for user-data and signalling packet transport is entirely based on the new generation IP protocol IPv6 and makes use of possibly enhanced standard IP equipment rather than keeping specific equipment as specified for instance within the framework of 3GPP for building up the UMTS architecture. For access to the infrastructure, the architecture provides end-to-end Quality of Service as well as security-enabled access with charging functionality for data packet transport. This document focuses on the project’s mobility management specifics with respect to the architecture, which covers the end-devices, wired and wireless access technologies, the intermediate nodes building up the access network and the backbone as well as on the related protocols for mobility management and enhancements. Based on related work going on especially in the IETF, but also having other standardisation groups architectures and technologies in mind, the protocols for IPv6-based mobility management in the back-bone as well as for local mobility management, provision of paging service and for fast handover support are evaluated and enhanced in order to meet the requirements of the project. Since the project wants to specify and implement a platform, which targets mobile communication platforms beyond the 3rd Generation architecture, the mobility management issue cannot be handled as a separate one in the entire architecture. Rather all the functional entities and protocols for Mobility Management, Security and Quality of Service support have to be combined in a consistent common architecture. This requires strong co-ordination between the respective Work Packages. In particular, the initial access to the network infrastructure must be authenticated and is to be granted only under explicit control of validation. Security issues must also be taken into consideration for the initial registration with functional entities for mobility management. These entities might be located within the respective administrative domain a Mobile Node is roaming in, or at the Mobile Node’s home domain (its mobility Home Agent). During a handover, the same security related issues have to be taken into account for granting access at a candidate Access Router. For local mobility management, mechanisms have to be taken into consideration for either transferring context related to mobility management, security or QoS between Access Routers or re-establishing the context in advance or after a handover. A further issue to be taken into consideration for future mobile communication architecture as it is initially built up within the framework of the Moby Dick project is the provision of compression techniques. This is important in particular on the last hop1, which is the wired or especially wireless link between Access Routers and Mobile Nodes. The importance of compression techniques is stressed here, because in particular radio links always have scarce resources and high costs where header compression techniques might contribute to decrease the cost issue. The implementation of header compression into the respective equipment, which is basically individual Access Routers and the mobile terminals, is not a big issue from the project’s research point of view. It is rather an additional implementation task, which may be introduced in a later project phase or within the framework of a follow on project. Therefore, Work Package 3 does not focus on compression techniques, but on more research oriented work with respect to mobility management, which is to be co-ordinated with the other Work Packages.

1 Last Hop – Assumes access of mobile terminals to Access Routers. When mobile Routers are considered, the

respective link is not necessarily the ‘last hop’.



5. Overview

5.1 General architecture integrating mobility Taking the comprehensive architecture of the Moby Dick environment, this section refers to the entities that are involved in the mobility management. The set of functional entities cover appropriate agents for global and local mobility management, as well as for enhancing the basic mobility management functionality with respect to support of fast handover and for IP based paging. Basic components for IPv6 based mobility management are the entities specified for Mobile IPv6 managed networks, which are Home Agents (HA), Mobile Nodes and Correspondent Nodes. When localised mobility management is made use of, local mobility agents might be integrated into individual administrative domains. Whether or not hierarchical approaches introduce a benefit into the Moby Dick architecture is to be studied. Further support is expected from individual Access Routers or separated entities in order to support handover between two adjacent IP subnets providing wired or wireless access. These handovers should be fast when attaching to a subnet supported by the same or a different access technology within the same administrative domain. This means that further mechanisms have to support the handover procedure inter-working with the different access technologies in order to make the procedure fast, which refers to a unnoticeable interruption in a voice over IP session. A further intention is to make the handover smooth, which implies minimal packet loss. For the handover process, it might be useful to transfer session- or attachment based parameters from the old Access Router to the new Access Router during the handover. This might support the entire handover procedure with respect to speeding up re-establishment of conditions at the new Access Router as they had been established on the old Access Router before a handover. The Mobile Node, the terminal a user wants to take along while roaming, must implement appropriate functions for mobility management, which includes paging support and handover support. A special functional entity to be integrated in the Mobile Nodes is a management functional entity for controlling the use of the different access interfaces integrated with the device. Mobility management as well as paging a Mobile Node should be kept transparent to Correspondent Nodes (CN). The only additional functionality, which is implemented in Correspondent Nodes, is actually part of the Mobile IPv6 protocol and refers to route optimisation. This is when a Mobile Node notifies its Correspondent Node of its current location. This allows packets destined to the Mobile Node to be sent directly from the CN to the MN, rather than always addressing the Mobile Nodes home address and to rely on tunnelling of packets from the HA to the Mobile Nodes location. Further components to be considered within the network infrastructure are agents for provision of paging services. These should be designed in a way allowing flexible deployment of paging services within any kind of architecture. When paging is to be managed on a per administrative domain basis, these respective Paging Agents (PA) should be integrated with individual administrative domains. When paging is to be made use of beyond the scope of an administrative domain, then there will be the need for Paging Agents located somewhere outside the respective administrative domains. For the latter case, additional security considerations have to be taken into account. It is to be analysed how far the different access technologies and the Access Routers are involved in mobility support. For paging idle mobile terminals, it might be reasonable to make use of Layer 2 specifics, which could be mapped from a technology independent protocol to Layer 2 specifics at individual Access Routers. Furthermore, for handover decision, individual Access Routers and Access Points might be involved in the decision process. This is to be evaluated for the individual technologies in the project. The mobility management architecture, which covers the protocols and the entities, shall be optimised on IP packet transport and make use of appropriate management protocols. The IP based protocols shall replace protocols as they are specified and used in 3rd Generation architectures like UMTS and its standardisation bodies. The entities involved in the mobility architecture shall be based on conventional hardware equipped with the appropriate technology for wired or wireless networking. Modification of or extensions to the TCP-IP protocol suite are according to the support expected from the functionality of the respective node. These improved architecture entities are intended to replace expensive and equipment as it is currently used in 2nd and 3rd Generation mobile communication architectures. The overall goal is to initiate research and to aim at the specification and development of an architecture, which at least supports the same functions with a comparably or even better platform functionality and quality as it is provided by current mobile communications platforms. This is related to the functionality



for Mobility, Security and Quality of Service. Results of this project are expected to be valuable input for further research and specification of mobile communication architectures beyond UMTS. The following Figure 2 illustrates the location of these respective functional entities for mobility management within the Moby Dick architecture.

Figure 2: Illustration of mobility management relevant components within the Moby Dick architecture

5.2 Relation to standardisation bodies Especially in the IETF there is a lot of work going on related to IP-based mobility management, the integration of enhancements like improved handover provision, integration of an architecture and protocols for security and charging (AAAC), and considerations on Quality of Service provision, to the common IP-based platform. But also other groups like the 3rd Generation Partnership Project, specifying the UMTS architecture, is increasingly considering IP for the transport of 3G protocols for mobility management and other purposes. This section tries to introduce the work achieved in Moby Dick with respect to the international standardisation movements. It goal is twofold: On one hand, it shortly presents the context and trends of some relevant Standard Defined Organisations (SDOs) like IETF, 3GPP2 or MWIF. On the other hand it attempts to evaluate how the work performed till now and the intentions that will lead us up to the end of the Moby Dick project could be integrated in a clever way in the previous décor, providing also Moby Dick with a possible dissemination of results area.



5.2.1 IETF The Internet Engineering Task Force (IETF) is a community of people concerned by the good working, the evolution and the improvement of the Internet as a whole [11]. Basically, the IETF is a large, open, international community formed by network designers, operator, vendors and researchers. It is open to any interested individual.

5.2.1.1 Seamoby IETF Working Group Seamoby Motivation Seamoby is an IETF working group (WG) that originated from the Mobile IP WG. The WG first met during the 49th IETF meeting (December, 2000). The reason for that spin off was the fact that Mobile IP experienced some limitations and that those limitations could possibly be addressed outside the scope of the Mobile IP WG itself, thus without the need of Mobile IP protocol enhancements but rather through independent, innovative solutions. Seamoby was thus idealised as the “working piece” for the provision of the real-time services in mobile IP environments. Its results should allow for real-time services to work with minimal disruption across heterogeneous wireless and wired networks. Originally, Seamoby was designed to address three problems: � Micro-mobility � Context transfer � IP Paging The first issue, micro-mobility, was moved after a first evaluation stage to the Internet Research Task Force (IRTF) area, a research organisation within the Internet Society, to which the IETF belongs. Seamoby’s context transfer activities try to develop a new protocol that would allow state information to be transferred between edge mobility devices. There was no clear idea on this “state information” that could be transferred; examples at the time were AAA information, security, QoS properties, Robust Header Compression information, specific routing protocols information, etc. “Context Transfer” concerns arise due to the fact that changes of communications path due to roaming sometimes includes a change in communications media between the mobile terminal and the network (e.g. in Moby Dick, changing from wireless to wired LANs) – and, in the case of cellular networks, these changes can occur very fast. Mobile IP does handle the change of attachment point, but active IP flows need to be kept, in the same “context”. The IP flow context that might be useful to transfer could include issues such as security context, policy, QoS information, header compression, and accounting/AAA information. Seamoby aims to analyse the requirements and trade-offs of such a context change, and eventually develop a protocol to transfer this information with real-time applications constraints. This is associated to the so-called “fast-handover” notion, under development in the Mobile IP working group. The latest working item, IP Paging, or Dormant Mode Host Alerting (DMHA) Protocol is now, at the time of writing, in an advanced stage, since candidate protocols have been submitted and should be now evaluated with regard to the requirement draft. “IP Paging” (Dormant Mode Host Alerting) is typically used in networks that support mobile devices that periodically enter dormant mode to reduce power consumption. Seamoby will develop a protocol to enable network devices to track a mobile that has moved from its last point of attachment, while in dormant mode, allowing the mobile's packets to be delivered. Moreover, it should be mentioned that since its creation, the Seamoby charter has been rephrased and that a subsidiary working issue, Handoff Candidate Discovery, has been identified. “Handoff Candidate Discovery” is the natural complement of the context transfer work. The mechanisms under development for handover (within the Mobile IP WG framework) assume that a set of candidates has already been chosen and that handover should be initiated to all of them. However, "seamless" handover may be best achieved by considering multiple handoff candidates and selecting one or more of them as targets for context transfer. Thus, Seamoby will define this work in a problem statement, and if needed, will define the requirements and the protocol for a handoff candidate discovery protocol, which could be used with any mobility management protocol.



A short summary of the published key objectives of Seamoby can be found starting from the IETF home page [11]. Seamoby in Moby Dick It is still uncertain whether Seamoby is a good candidate for Moby Dick outputs. Due to the late start of its work, Seamoby protocols will only be lightly, if at all, implemented within the Moby Dick framework. There is a common agreement within the project team that the work in Seamoby is too immature to be reasonably and exhaustively evaluated. Nevertheless, the on-going Seamoby discussions will be attentively monitored since the scenarios mentioned in this forum are very close to the one discussed in Moby Dick, especially regarding the inter-technology handover problematic. The only exception to this is Paging. The Moby Dick Mobility Work Package intends to implement a solution that could possibly be picked up among the pool of the already existing proposals [14], [15] and [16]. Please refer to section 7.5 for more details about this issue.

5.2.1.2 Mobile IP 5.2.1.2.1 Mobile IP IETF Working Group The Mobile IP Working Group of the IETF is the culmination of efforts by many individuals interested in the problem of mobile routing of hosts. The first meetings were in the form of BOF (Birds of a Feather) sessions held at the Atlanta (July, 1991), Santa Fe (November, 1991), and San Diego (March, 1992) IETF meetings. In June 1992, a proposed charter for a formal Working Group was submitted to the IETF and at the same time a mailing list was set up for conduct of the group's business. Following a revision of the charter, the Working Group was officially formed in June 30, 1992. The Mobile IP WG is the place where Mobile IPv6 is standardised and improved. Among other identified activities, the WG works on (taken from the Mobile IP WG home page from [11]): � Use of NAIs to identify mobile users/nodes. � Specifying how Mobile IP should use AAA functionality to support inter-domain and intra-domain

mobility. � Develop solutions for IPv4 private address spaces for the scenarios needed for deployment. � Documenting any requirements specific to cellular/wireless networks. In the longer term, the WG needs to address: � QoS in the Mobile IP environment using DiffServ and/or IntServ/RSVP. � Location Privacy. The Mobile IP WG develops solutions for these problems for IPv4 as well as for IPv6. 5.2.1.2.2 Mobile IP in Moby Dick Mobile IPv6 First of all, as the Moby Dick contract states it, the project only focus on IPv6 related activities within the Mobile IP WG. It reduces the numbers of documents that should be examined and compared to nearly one half. Nevertheless, as the next sections underline, the activity around Mobile IPv6 is turbulent and the core document concerning mobility in IPv6 [13] has not yet been standardised. Security Concerns The biggest issues recently raised in the Mobile IP WG deals with security in Mobile IPv6, more precisely with the authentication and scalability limitation of the Binding Updates (BU). After the 50th IETF crisis, some proposals have already been made to overcome this problem but the feeling within the



WG is that this issue need dialogue and should be tackled by the WG as a whole. A document has already been produced by a team to identify the requirements for security in IPv6 [12]. The project team has not yet dealt with this issue, but it is likely that for the sake of the project only old-fashioned security mechanisms (i.e. AH) would be implemented (version 13 and before of the non-finalised Mobile IPv6 specification [13]). The version 13 relies on IPSec with AH in transport mode and by default IKE for SA establishment. Anyway, as the project is still in an early stage, no final decision has been taken for the time being. We would also not preclude the possible use of a ‘non IPSec’ solution. FMIP The Fast Handover in MobileIPv6 (FMIPv6 or FMIP) [18] approach is able to enhance the Mobile IP protocol by adding fast handover functionality, but there is no improvement over standard Mobile IPv6 with respect to the handover signalling. Each handover requires location updates to the Home Agent and Correspondent Nodes and, beyond it, even more signalling to the access router is necessary. Introducing a hierarchy could prevent the overhead of location updates for intra-domain handover by localising the handoff management. At the same time, a hierarchical approach could also enhance handover performance – always keeping the disadvantage of the increased complexity to the network topology in mind. Whether a hierarchy is needed or not, or whether a combination of hierarchical and non-hierarchical approaches is useful and practicable, requires further analysis, which is the next step within the Moby Dick framework. A comparison of hierarchical and non-hierarchical approaches is expected to lead to a specification of handover scenarios with certain parameters, as input for the following step, the simulations. The simulation results are intended to specify the best suitable handover mechanism for the Moby Dick project. FMIP was primarily designed to support real time applications in a mobility context. As opposed to other solutions like Hierarchical Mobile IPv6 mobility management (HMIPv6 or HMIP) or Cellular IP, FMIP does not make any assumption on the nature, the architecture and the design of the access network. It is possible to use a MIP-HMIP-FMIP combination (in this order), but no concrete proposition has been made so far in this sense. FMIP is an extension to basic Mobile IPv6 [13] deployed in case where fast handover is needed (whatever fast could mean). The FMIPv6 document is still work on progress and it is noticeable that it lacks of interoperability between implementations. BETH An optional proposal to improve the FMIP concept is to replace the forwarding mechanism of the old access router by a bicasting mechanism, i.e., the OAR duplicates packets destined for the Mobile Node and send them to the old and the new point of attachment for the handover time period. This scheme allows a more flexible reaction to the movement direction of the user and could interoperate with a layer-2 based movement detection algorithm. A mobile device may decide and prepare to handover, but due to a change in the direction of the user movement, a handover could become unnecessary. In this case, the bicasting mechanism ensures the continuous connection to the old access router and the MN is able to cancel the handover (e.g., by sending a BU to the OAR containing the old care-of address) without any performance degradation. This option is described in the Internet Draft Bidirectional Edge Tunnel Handover for IPv6 [17] and still has the status of work on progress, so, if used in Moby Dick, it will not be used as a standard. HMIP The Moby Dick Mobility protocol interaction is not completely defined at this point and it is doubtful whether it will integrate hierarchical solution like [19]. Hierarchical approaches have advantages to deal with micro-mobility and with QoS issues and so it is interesting to consider their use in Moby Dick. Micro-mobility is an important scenario in Moby Dick where Radio Access Networks are considered (WCDMA or IEEE 802.11). Hierarchical approaches do not assume anything about the layer two technologies or inter-technology handovers, so they are valid for the Moby Dick scenario. Also, the Moby Dick architecture plans to support QoS and use AAA to do access control. Hierarchical approaches have advantages, as explained before, for QoS support and AAA use. It is still not clear whether the integration of HMIP and FMIP will be advantageous. HMIP (or other local mobility management (LMM) scheme i.e. Mobile IPv6 Regional Registrations [20]) may provide added value by defining a framework or an architectural hierarchy in the network rather than just a sequence of optional messages, as it is the case in FMIP.



A recent informally agreed requirement identified for LMM is: „Regional registration shall support fast handover“. Or: „Regional registration shall be compatible with fast handover“. There is also a tacit agreement within the WG about the following sequence of events: 1. Mobility 2. Localisation of mobility and subsequent speedups (LMM) 3. Speedup optimisations by applying fast handover techniques over that LMM. On the other hand, it may turn out to be problematic to integrate HMIP and FMIP and there is no evidence that this could produce any remarkable gain. Since the benefit of hierarchical approaches is to be evaluated within the framework of the Moby Dick project making use of appropriate simulation tools, the two candidate hierarchical architecture protocol proposals, which are discussed in the IETF, are elaborated on in more detail within the next sections. This is in order to understand and estimate additional components and protocol specific signalling load before an evaluation given by the simulative study is available. There is the general perception that although Mobile IPv6 (MIPv6) [13] is a good protocol for macro-mobility issues, it has certain deficiencies when dealing with micro-mobility issues. But micro-mobility is a potentially usual and important case (for example, in the Moby Dick environment): a mobile node is away from its home network and moving across different IP subnets in the visited domain. For this reason, there are several proposals to complement Mobile IP to improve its efficiency when dealing with micro-mobility. Examples are cellular IP, HAWAII, and hierarchical Mobile IP. In this section we focus on hierarchical Mobile IPv6 proposals. We will describe HMIPv6 [23] [24], and a related approach Mobile IPv6 Regional Registrations [20]. In particular, we will study their relationship with Moby Dick architecture. Both approaches propose a hierarchical mobility management model to deal with micro-mobility issues with the aim of minimising the latency due to handover and reduce the amount of mobility signalling. Hierarchical means that at least two routers are involved in managing the MN mobility (the HA as in MIPv6 and at least one more in the visited domain). We do not include a detailed description of protocols and procedures, which can be found in the references. We give here the basic idea on how these approaches work and what their advantages and requirements are. HMIPv6 A hierarchical mobility management model has been proposed to complement MIPv6 [23][24]. In MIPv6, mobility management is done by the Home Agent (HA) (no hierarchy). In HMIPv6, at least one level of hierarchy is introduced and a new function called Mobility Anchor Point (MAP) is added in a router at the visited domain. The MAP is not constrained to be in the same subnet as the Mobile Node (MN). In fact, any physical location for the MAP is possible within the visited domain, although better performance is achieved by connecting the MAP to the border router of the network is serving. Thus, a MAP is not needed in each subnet, although there can be more than one MAP in a domain, allowing the use of more than one level of hierarchy in mobility management of MNs. A MAP provides an address or a prefix to form addresses that can be used as a global CoA by MNs visiting the domain. The HA or CN (after route optimisation) uses this address to send packets to the MN. The MAP will tunnel these packets to the MN within the MAP domain using a Local CoA (LCoA). The LCoA is an on-link IPv6 address in the subnet where the MN is. If the MN moves to another subnet within the MAP domain, the global CoA does not change, only the MAP must be informed of the new LCoA of the MN. Compare this with MIPv6, in the case of a handover, the HA and all the CNs must be informed of the new MN CoA. Now we can see the advantages of HMIPv6 for micro-mobility. The handover latency is reduced because mobility is managed locally. Besides, the MAP can support Fast Handover [25] (both proposals are compatible). Also, mobility signalling load is reduced. No mobility signalling is sent out of the MAP domain in case of an intra-domain handover, and only the MAP (perhaps more than one if the MN is using a multi-level hierarchy) must be informed of the change (in MIPv6 the HA and all the CNs must be informed). HMIPv6 architecture is shown in Figure 3.



Figure 3: HMIPv6 architecture

HMIPv6 is an extension to MIPv6. A MN that is HMIPv6-aware can use the MAP or can use the standard MIPv6 implementation (ignoring the MAP and registering the LCoA in the HA). Moreover, the MN can use the LCoA with certain MNs (for example, those in its same subnet to avoid going through the MAP) and the global CoA with the rest. There are two MAP modes in HMIPv6. In Basic Mode, the MN forms an IPv6 address in the MAP subnet (Regional CoA or RCoA), using the MAP announced prefix. The MN uses the RCoA as the global CoA. In Extended Mode, the MN uses the MAP IPv6 address as an alternate-CoA. The decision of which mode to use is a network administration one. Each MAP can support only one mode at a time. To use HMIPv6, a MN must discover the MAPs serving the domain it is visiting. To do this, a new MAP option for Router Advertisement messages is proposed. This option includes the distance to the MAP in number of hops, a level of preference in using this particular MAP, the MAP global IPv6 address, and an indication about the mode of operation (basic or extended) of the MAP. If the MAP is operating in basic mode, the MAP option includes also the MAP’s subnet prefix. To propagate the MAP option from the MAP to the MN there are different possibilities. For example, the routers in the domain, including the MAP and the Access Routers (ARs) can be manually configured to propagate the MAP option on certain interfaces. The result is that the MN receives router advertisements from its AR including a MAP option for each MAP that it is serving the subnet where the MN is. It is up to the MN to choose one or more (more than one level of hierarchy) MAPs to use. A MAP domain is defined as the subnets where the MAP option of a particular MAP is received. The domains of different MAPs can overlap. After discovering the MAP, the MN must register in it. This is done using an extended Binding Update (BU) option that allows to indicate a MAP registration, differentiating it from a HA registration or a BU sent to CNs.

IPv6Core NetworkHA

IPv6

IPv6

CN

MN

MAP

AR

IPv6Core NetworkHA

IPv6

IPv6

CN

MN

MAP

AR



Basic Mode: When a MN moves to a new MAP domain, and after MAP discovery, it creates two addresses, a LCoA and a RCoA as explained before. Then the MN sends a BU to the MAP specifying the RCoA in the Home Address Option. This will bind in the MAP the RCoA to the LCoA of the MN. The MAP acts exactly like a HA in MIPv6. It will perform Duplicate Address Detection (DAD) for the RCoA, it will send a Binding Acknowledge (BAck) to the MN, and it will intercept all packets addressed to the RCoA and will tunnel them to the corresponding MN. The MN will de-capsulate the packets and deal with them in the normal MIPv6 manner. If necessary, the packets come from a CN through the HA, it will send a BU to the CN indicating it the RCoA to do route optimisation. When the MN receives the BAck from the MAP, and if it indicates a successful MAP registration, it will send a BU registering the RCoA in its HA. In this BU option, the Home Address field is set to the MN’s Home Address, an alternate-CoA sub-option is included and set to the RCoA, and the source address of the packet with the BU option is set to the LCoA. The HA will intercept the packets addressed to the MN’s Home Address and will tunnel them to the RCoA. The MAP will intercept these and tunnel (double encapsulation) them to the MN’s LCoA. This double encapsulation, for packets in their way from the MAP to the MN and that were sent from the CN without route optimisation (i.e. through the HA), is shown in Figure 4.

Figure 4: Double encapsulation in Basic Mode

If the MN changes its subnet but not its MAP, it has only to register its new LCoA in its MAP. A MN discovers that it has changed its MAP domain because it doesn’t receive the corresponding MAP option in the router advertisements. Then, it has to choose another MAP according the received MAP options, and do a MAP registration. It can also register its new LCoA in its old MAP to avoid losing packets. Extended Mode: When a MN moves to a new subnet where the MAP options in the router advertisements indicates MAPs working in extended mode, the MN creates a LCoA. Then it sends a BU to the MAP with the LCoA as source address of the packet, and the Home Address option set to the MN’s Home Address. This allows the MAP to do a binding between the Home Address of the MN and its LCoA. If the registration is successful, the MAP will send a BAck to the MN. After receiving the BAck, the MN can start sending BU’s to the HA and CNs indicating the MAP IPv6 address as an alternate-CoA. To create a hierarchy of MAPs, the MN can choose to send a BU to a MAP higher in the hierarchy, binding the MN Home Address with the IP address of the MAP (alternate-CoA) immediately below in the hierarchy. The HA will intercept all packets addressed to the MN and will tunnel them to the MAP’s address. In extended mode there is a small modification in the procedures of the HA. Namely, if a packet is received to a destination address different from those used by the MN in its HA registration (for example, a site local address), the HA includes a routing header in the outer packet with the registered MN home address. This allows the MAP to find the right binding entry for the packet (it is indexed by the registered Home Addresses).

Source address: Destination address: Source address: Destination address: Source address: Destination address: MAP IP address LCoA HA address RCoA CN IP address MN’s home addressSource address: Destination address: Source address: Destination address: Source address: Destination address: MAP IP address LCoA HA address RCoA CN IP address MN’s home address



The packets directed to the MN will be received by the MAP. The MAP will de-capsulate the packets and will tunnel them (a new encapsulation) to the MN. This encapsulation, for packets in their way from the MAP to the MN, is shown in Figure 5.

Figure 5: Encapsulation in Extended Mode

The MN must recognise when a packet from a CN is received through the HA, because in this case a BU must be sent to the CN to do route optimisation. The normal procedure is to see in the packet the encapsulation by the HA. But now, all the packets arrive encapsulated by the MAP. The solution is a new procedure to discover if a packet has gone through the HA. It must be noticed that this procedure will also be valid in normal MIPv6 and in HMIPv6 basic mode. The procedure consists of checking in the encapsulated packet (the one with the CN as source address) the existence of a routing header with the Home Address of the MN as final address. If this routing header exists, the packet was route optimised, if it doesn’t exist, the MN Home address is in the destination address of the packet and the packet was sent without route optimisation. In this last case, the MN must send a BU to the CN. Comparing extended and basic modes of operation: The extended mode is the only one that can be used to support mobile networks. In this case MNs will be served by an AR that is mobile too. The MNs cannot use the AR network prefix because the resulting addresses will be topologically incorrect. A solution is that the mobile AR acts as a MAP in extended mode. The MNs will use the MAP (AR) LCoA as their alternate-CoA to register with their HA. If the AR changes its subnet, its LCoA will change, and then the MNs will have to register again (with the new LCoA) in their HA’s (i.e. we are not having the advantages of HMIPv6). The solution is that the MNs must build a new level of hierarchy of MA’s. They must register its LCoA, associated to its home address, in the MAP AR. And then, they must register the AR LCoA in a MAP higher in the hierarchy. In the HA, the MN will register the IP address of this MAP higher in the hierarchy (or a RCoA formed with its prefix). When the AR changes its subnet, its LCoA changes, but now the MN only has to register this new CoA in the MAP higher in the hierarchy. This is the only situation identified in [23] in which can be interesting to use more than one level of hierarchy of MAPs. This doesn’t mean that only one MAP must be provided in a domain, on the contrary, it is interesting to have more than one for robustness and to allow the MNs to choose the MAP (according to the number of routers between it and the MN) more appropriated to its kind of mobility. The basic mode has as advantage that it is very simple: the HA implementation is not affected and the MAP implementation is just a HA implementation. A disadvantage is that, when a packet is received from the HA, an additional encapsulation is used between the MAP and the MN (two encapsulations against only one in the extended mode) because the HA encapsulation is conserved (in extended mode the HA packet is de-capsulated before encapsulating it to send it to the MN). Another disadvantage is that when there is a change of MAP domain, DAD must be done in the new MAP for the RCoA formed by the MN. This can increase significantly the latency of inter-domain handovers. Regional Registrations Regional registration [20] is a proposal to complement MIPv6 with a hierarchical management of mobility. The latency of handover is reduced because the handover is managed locally in the visited domain, and the signalling load is reduced by using a regional-aware router to offer a CoA that is what is seen by hosts outside the visited domain. In the Regional Registration proposal the regional CoA is provided by the Gateway Mobility Agent (GMA). This CoA can be the IPv6 address of the GMA or an IPv6 address from a set of addresses

Source address: Destination address: Source address: Destination address: MAP IP address LCoA CN IP address MN’s home addressSource address: Destination address: Source address: Destination address: MAP IP address LCoA CN IP address MN’s home address



controlled by the router. There can be more than one GMA serving a domain, the MN decides which GMA to use. The GMA is then similar to a MAP of the HMIPv6 proposal. The main differences between both proposals are in the communication between the MN and the GMA-MAP. The Regional Registrations architecture is shown in Figure 6.

Figure 6: Regional Registrations architecture

In Regional Registrations there is a hierarchy of regional-aware routers between the GMA and the MN, although it is possible the existence of no regional-aware routers between pairs of regional-aware ones. When a MN enters a Regional domain, it will create a LCoA and it will send a BU to the chosen GMA. This BU will have the LCoA as source address, the home address option set to the Home Address of the MN, and an alternate-CoA set to the chosen regional CoA. The BU will be received by the AR, and it will be sent up through the regional-aware routers hierarchy, hop by hop, until it will arrive to the GMA. Each regional-aware router that receives the BU establishes or updates its regional binding cache entry for the MN, associating the MN’s home address with the address of the next lower router in the hierarchy, and then re-sends the BU to the next higher regional-aware router in the hierarchy. A packet sent to the MN is received by the GMA, and then is forwarded hop by hop downwards the hierarchy of regional-aware routers. Each of these routers de-capsulate the packet and encapsulates it again to send it to the next lower regional-aware router in the hierarchy (as indicated in its binding cache). A procedure to avoid de-capsulating and encapsulation the packets in all the routers is proposed in [26]. If the MN changes its subnet, it will send a new BU to the GMA. This BU will be propagated again, hop by hop, by the regional-aware routers. This BU includes also a previous access router sub-option (an extension to the BU option). This sub-option allows a MN to indicate the AR it was using before the change of subnet. Each regional-aware router that receives the BU can know if it is a router common to the previous path and the new path (the previous AR is a descendant of this router). To do this, a regional-aware router must keep a list of all its descendants. How this list is configured is not specified in [20], but one example is statically. The lower router common to both paths is called crossover router. Only the routers that are lower in the hierarchy than the crossover router, and the own crossover router, have to change their binding caches. After a successful regional binding update, a BAck is sent down the hierarchy to the MN. After receiving the BAck the MN can send BU’s to nodes outside the visited domain with the regional CoA as alternate-CoA. The MN recognises the use of route optimisation in packets received from CNs because the presence of a routing header with the HA address as final destination. If this routing header is not present, the MN must send a BU to the CN with the regional CoA as alternate-CoA.

IPv6Core NetworkHA

IPv6

IPv6

CN

MN

GMA

AR

Regional-aware routers

IPv6Core NetworkHA

IPv6

IPv6

CN

MN

GMA

AR

Regional-aware routers



The GMA domain is identified by an anycast address and it is announced in router advertisements with a new regional CoA sub-option. The anycast address is formed from the prefix in the regional CoA extension and a host number 0. The anycast address represents the GMA and can contain several regional CoA’s in the visited domain (those managed by the GMA). The MN can send the BU’s directed to the GMA to this anycast address, and can use this anycast address as a unique identifier of the GMA domain. This allows the MN to discover when it has changed its GMA domain. No modification is needed to the procedures of the HA or the CNs comparing it with normal MIPv6. As in HMIPv6, a MN can choose to ignore regional registrations and use normal MIPv6. A MN that doesn’t understand regional registrations can use normal MIPv6 from a domain supporting regional registrations. Comparison between HMIPv6 and Regional registration The HMIPv6 and Regional Registration proposals both share the aim of introducing the hierarchical mobility management in order to enhance the network performance while minimising the impact on IPv6 protocols. The basis is to introduce a new mobility agent, namely MAP or GMA, which can be located in any level in the hierarchy, and reduces the signalling outside the domain and improves handover performance. Both solutions are independent from the underlying access technology and fully compatible with MIPv6. However, there are some differences in the approaches. The HMIPv6 approach supports mobile networks in one of the two modes of operation (extended mode) while this feature is not possible in the Regional Registration approach. Notice that this (not supporting mobile networks) is a limitation of Mobile IPv6 [27] and not of the Regional Registrations approach in particular. A solution to this problem in Mobile IPv6 (as proposed in [27]) will probably allow also support of mobile networks with the Regional Registrations approach. Besides, the extended mode implies minor changes in the HA in contrast to basic mode of the Hierarchical and the Regional Registration proposals which are totally transparent for the HA and the CN’s. In terms of scalability, the Regional Registration solution implies a de-capsulation and an encapsulation in every level of the hierarchy, which increases the end-to-end delay mainly due to the processing delays. Furthermore, the bandwidth of the air interface (which is a scarce bandwidth medium anyway) is burdened by the encapsulation overhead of every packet. On the other hand, the HMIPv6 solution supposes a double encapsulation (in basic mode without route optimisation) or an encapsulation (in extended mode or in basic mode optimised packets) which suppose an increase in the end-to-end delay due to the bandwidth consumption on the wireless link, but there is not a dependence with the number of hierarchy levels because rarely more than one is used. There is a proposal [6], which could be used in Regional Registrations and perhaps also in HMIPv6, to avoid the encapsulation in the path between the MAP-GMA and the MN, and the corresponding overhead in the wireless link. Regional Registration requires more changes in the architecture than the HMIP concept, because this approach assumes a hierarchy of ‘mobile aware routers’ below the agent for Mobile IP handoffs. In HMIP the migration from Mobile IPv4 will be simpler, because the foreign agents in Mobile IPv4 can be enhanced to become MAPs for the Mobile IPv6 HMIP extension. Security Considerations Both hierarchical proposals do not introduce new security problems to normal MIPv6, but considering a mobility hierarchy transfers the problem of key distribution to Mobile IP, which is currently under discussion (e.g. in the IETF Public-Key Infrastructure WG) outside the scope of MIP WG and not yet solved. IPsec authentication headers are used to authenticate BU’s sent to the HAs, MAPs, GMAs, or CNs. This requires a key shared by the MN and the visited domain. AAA servers are proposed to distribute these keys. Considerations about hierarchical approaches Besides the above named disadvantages (e.g., end-to-end delay, overhead on the wireless link), both hierarchical approaches provide necessary micro-mobility functionality to Mobile IPv6: Mobile IPv6 signalling load is reduced in case of intra-domain handover, because these handovers are transparent to HA and CNs.



Handover delay is improved by localising the mobility management. Location privacy may be provided. The changes to the Mobile IPv6 protocol and the related nodes are minimal, but the complexity, which is added to the network, is not to be neglected, especially if several levels of hierarchy are allowed. This raises the question of network design for the administrative domain, which is served by a MAP or GMA: topological situation and typical roaming behaviour may interfere with network topology, e.g., in terms of different providers supplying adjacent areas. Therefore, one mobility agent supporting different domains of different providers may be useful for certain user behaviour. Such a scenario would require information sharing between these providers, whereas it is unclear if the providers would come to an agreement. For this kind of scenarios further analysis is needed to prove the benefit of this approach compared with the added complexity to the network. Hierarchical approaches and Moby Dick Mobility Architecture Hierarchical approaches have advantages to deal with micro-mobility and with QoS issues and so interesting to consider their use in Moby Dick. Micro-mobility is an important scenario in Moby Dick where Radio Access Networks are considered (WCDMA or IEEE 802.11). Hierarchical approaches do not assume anything about the layer two technologies or inter-technology handover, so they are valid for the Moby Dick scenario. Also, Moby Dick architecture plans to support QoS and use AAA to do access control. Hierarchical approaches have advantages, as explained before, for QoS support and AAA use. The interaction between hierarchical approaches, and QoS and AAA issues, is commented in the hierarchical or QoS related drafts, but it is far from clearly defined. This will require extensive study if the use of a hierarchical approach is decided within the Moby Dick framework.



5.2.2 3GPP and 3GPP2

5.2.2.1 Introduction Since 3GPP mandates IPv6 but not Mobile IPv6, the related 3GPP architecture is not considered as relevant for mobility management in the Moby Dick project. Please refer to Figure 7 for an overview on the 3GPP All-IP Architecture. 3GPP2 is a Standard Developing Organisation (SDO) founded by Chinese, Japanese Korean and North American national SDOs to specify IS-41 based 3rd Generation cellular system, often referred as cdma2000. Currently, 3GPP2 is working on All IP Network specifications for cdma2000 networks. In the rest of this chapter we present an overview of the 3GPP2 All IP Reference Architecture. Please note that the work in this area is still on going. Thus things mentioned here are subject to change before the specification is completed.

5.2.2.2 3GPP2 overview There are a lot of similarities between the 3GPP and the 3GPP2 All IP architecture. The simplified 3GPP All IP Reference Architecture is summarised in Figure 7. Please refer to [33] for more details.

Figure 7: 3GPP All IP Reference Architecture [31]

The All IP architecture currently discussed in the 3GPP2 is illustrated in Figure 8. This is a schematic vision. Please refer to [32] for more details. The architecture is described in 3GPP2 Network Architecture Model (NAM) document. The basis of architecture is in the evolution of the cdma2000 specifications. Like the 3GPP architecture, also 3GPP2 All IP network architecture can be split into several domains:



Figure 8: 3GPP2 All IP Reference Architecture [31]

Access Network and Access Gateway together equals roughly to combination of RAN and GPRS of the 3GPP architecture. They provide IP bearers from Mobile Station to the IPT core network. However, the functional split is slightly different; e.g. user authentication is done in the cdma200 Access Network, while in 3GPP those are GPRS network functionality (register and attach functionality). The Session Control Manager (SCM) and the Media Resource Function (MRF) of the 3GPP2 are very similar to the CSCF and MRF of the 3GPP. Also in 3GPP the SCM has several identified roles: Interrogating SCM (I-SCM), Serving SCM (S-SCM), and Visited SCM (V-SCM). The roles of those are practically the same as the respective CSCFs for the 3GPP. While the 3GPP has incorporated all databases into HSS (Home Subscriber Server), the 3GPP2 architecture has a block called ‘Databases’. The different databases of the 3GPP2 architecture in turn are similar to the HSS of the 3GPP. While in 3GPP the QoS management functionality is incorporated into RAN and GPRS network entities, in 3GPP2 architecture we can see separate QoS management functions. The subscription QoS manager (SQM) makes policy decisions on the QoS allowed for user session based on the subscriber profile and on the current QoS allocation for users. On the other hand, the core QoS manager (CQM) makes decisions on the use of the QoS resources within one core network. The 3GPP2 All IP architecture relies on Mobile IP (MIP) infrastructure for roaming between different access gateways. Thus, MIP Home Agent and Foreign Agent are introduced in the reference architecture. Please note that MIP is used for mobility management across Access Gateways and 3GPP2 proprietary protocol is used for mobility within one Access Gateway’s area. The Gateways of 3GPP2 strongly resemble the Gateways of the 3GPP. Media Gateway Control Function, Media Gateway, and Trunk Signalling Gateway of 3GPP2 are similar to the MGCF, MGW, and T-SGW of 3GPP respectively. However, the 3GPP2 also introduces the Network Capability Gateway (NCGW), whose main task is to authorise the servers’ use of network resources. In 3GPP, the architecture functionality of NCGW is embedded into the CSF.



5.2.2.3 Relation between 3GPP2 and the IETF IETF is not actually concerned with architectures in general and ‘All IP Architectures’ in particular, but rather specifies several protocols that are or will be essential for All IP Network. It is not yet clear which Internet protocol will be used in a future cellular network and work is still on going. Nevertheless, the current protocol addressing Security, Quality of Service, Mobility, Discovery, Transport and Policy will play a role in the future even if they need to be enhanced, replaced or modified and at least standardised. The IETF works very closely with 3GPP2. As a general philosophy, 3GPP2 uses IETF protocols whenever possible to minimise the number of new protocols required and to maximise the utilisation of well accepted standards and hence the time to market. Please refer to [34] for more information on this co-operation and related issues, and to chapter 4 of the working document RepIETF-03-2001va1 of WP3 for some opinion inside the IETF on the relationship with 3GPP2. In the rest of this chapter we mention some (and indeed very few) Internet protocols that will be involved in the 3GPP2 All IP reference architecture (and indeed in other ones). 5.2.2.3.1 IPv6 IPv6 has already been declared mandatory by 3GPP as the Core Network routing protocol. The most important benefit of IPv6 is the extended address space. Of course, a transition phase between IPv4 and IPv6 is expected, the length of which cannot be foreseen. However, it is assumed that IPv6 is the long-term solution. IPv4 is mandatory in the 3GPP2 context, although it is claimed that "the All-IP architecture shall be designed in such a way that a migration from IPv4 to IPv6 is feasible and that IPv4 and IPv6 based All-IP networks may interoperate." . 5.2.2.3.2 Mobile IP Mobile IP is mandatory as the Mobility Management protocol in the CN of the 3GPP2 reference architecture. Mobile IPv4 and only Mobile IPv4 is considered. 5.2.2.3.3 AAA AAA is not a protocol but a family of protocols, a feature provided by protocols like RADIUS or DIAMETER. For references to these protocols, please be referred to the Moby Dick deliverable [D0401]. Concerning AAA, both 3GPP and 3GPP2 have standardised the IETF AAA architecture for their All IP network. 3GPP2 defined the use of AAA for Mobile IPv4 with RADIUS in their current IOS v4.x and will move to DIAMETER in their next IOS release (version C to be standardised this summer). 5.2.2.3.4 SIP This protocol was specified by the IETF in the year 1999 as one element of the multimedia protocol set. 3GPP2 will integrate a priori SIP. 5.2.2.3.5 ROHC There has been some guidelines and input published from the IETF regarding the 3GPP2 requirements in order to simplify incorporation of the robust header compression algorithms into the 3GPP2 cellular system, and also into specific link layer protocols such as PPP. The technical details are out of the scope of this document. Please refer to [35] or to the ROHC working for more information.



5.2.2.4 Relation with Moby Dick The Moby Dick architecture is still to be defined, but the use of IPv6, Mobile IPv6 and DiffServ could be a reason to say that the Moby Dick architecture fit in an all IP concept. But the essential attribute of an All-IP network is not only the end-to-end connectivity, but also the distributed control and services and the gateways to legacy networks. All those latest things are not (yet) addressed by the Moby Dick vision. Nevertheless, the Moby Dick architecture simply concatenates RAN and Core Network and then bypasses all interfaces between them. In other words, even if in the 3GPP2 Architecture, IP connectivity reaches all the way to the BTS, it is impossible to compare the 3GPP2 approach with the Moby Dick one. It is the first truly all IP vision and it fits well in the IETF vision (all IP ≠All IP). Moby Dick fits in a 4G or beyond vision.

5.2.3 MWIF

5.2.3.1 Introduction The Mobile Wireless Internet Forum (MWIF) is an international non-profit industry association. Its mission is to drive acceptance and adoption of a single mobile wireless and internet architecture that is independent of the access technology.

MWIF Layered Architecture:

Communication Session Management

Resource Manager

Policy Server

Control

Access Gateway

Accounting

Authorisation

Authentication

Mobility Management

Directory Services

Global Name Server Location Server

Access Network

Terminals

SignallingGateway

Legacy2G Networks

Services

Applications

ExternalIP Networks

PSTN / ExternalCS Networks

MediaGateway

bearer signalling

SignallingNetworks

Core

API

Security

API

Inter/IntranetGateway

Address Management

Applications/Services

3rd PartyApplications

OAM&P

Network Gateways

API

Access SpecificCore

Transport

API

Figure 9 : MWIF Layered Architecture (taken from [40])



5.2.3.2 Relation to Moby Dick There are some similarities between the MWIF and the Moby Dick architecture, but Moby Dick does not distinguish between RAN and Core as done within the framework of the 3G standardisation. We consider a Gateway Router with some additional functionality (AAA and possibly some local mobility management functionality) for separation of individual administrative domains and enclosing local mobility management areas. One of the most relevant issues where Moby Dick and MWIF architectures meet each other is the use of IP in the Radio Access Network (RAN). The MWIF technical report [21] proposes indeed IP in the RAN as a transport option and “considers how IP networks and protocols can be applied as a transport option for Radio Access Networks within 3rd Generation mobile systems and the benefits which might be provided. Within this work IP is only considered as a transport option over the RAN internal interfaces and RAN interfaces to the core network, without any changes to the RAN architecture or radio control protocols “.

The intention of report [21] is to influence and support input to 3GPP and 3GPP2 as well as to the IETF. According to [21], the main motivation of IP in the RAN is ‘cost reduction’ (which is also an intention of the Moby Dick IP-based architecture and protocols but with some more latitudes on the architecture and the protocols to be applied). With respect to 3G investigations on Open RAN, many discussions on IP-transport within the RAN is going on as well, but (until now) the architecture is still the same, which assumes controlling multiple Node-B’s from a centralised Radio Network Controller (RNC). IP is taken as a transport option in order to replace ATM (and expensive ATM equipment). The W-CDMA supporting node (the Radio Gateway) considered within the Moby Dick project resembles a future Release-x Node-B of 3G investigations, where radio specific protocols are terminated already within the W-CDMA node rather than within the RNC. With respect to the Radio Access Network, MWIF refers to protocols and models specified within the framework of 3G. This is the consideration of Interfaces like [Iub] and [Iur], as well as 3GPP2 related interfaces respectively. Other systems such as IEEE802.11 wireless LAN and Bluetooth are not considered due to the different background and assignment of complexity. These technologies include an excessive MAC protocol at Layer 2, which removes the need for specialised Radio Access Networks. This allows IP to be deployed up to the wireless Access point and across the wireless link. For appropriate QoS within the RAN, techniques like MPLS, DiffServ and IntServ are considered within the framework of MWIF’s IP in the RAN activity, but always with respect of transporting Radio Packets over the IP protocol through the RAN between wireless Access Points (Node-B’s) and the respective RNC. With respect to IP security, the document refers to RADIUS, which supports endpoint authentication using encrypted passwords. Diameter [AAA] is a backward compatible extension of RADIUS that allows definition of application profiles supporting different kinds of access control and authentication. IPSEC [IPSEC] supports secure tunnels between endpoints with and without encryption.



6. Requirements and related Components

6.1 Overview of requirements

6.1.1 Mobility Management The Moby Dick architecture intends to provide mobility by evaluating and enhancing different mobility management proposals of recent Internet Drafts within the IETF’s Mobile IP (and SEAMOBY) Working Group(s). Mobility management can be deployed at different levels, which distinguishes between global and local mobility management. In this distinction, Mobile IPv6 is based on global mobility management, since signalling to the Home Agent, as the central mobility management anchor, is required for EVERY handover (i.e., inter- and intra-domain handover). The deployment of mobile agent hierarchies, as proposed in HMIP, localises mobility management since intra-domain handover is transparent to the Home Agent (and correspondent nodes in case of route optimisation). The benefit of this approach (in terms of handover delay, minimised bandwidth consumption, reduction of packet loss, etc.) versus the costs (like added network complexity) in comparison to ‘standard’ Mobile IPv6 and a non-hierarchical approach as proposed in FMIP will be evaluated by means of simulation within the framework of this project. As long as the additional benefits of a hierarchy are not validated by the simulation results, the first implementation phase will deploy the non-hierarchical FMIP approach, which is able to provide fast intra-domain handover with lowest added network complexity. This can be extended easily to a hierarchy if the simulation results prove the benefit of localised mobility management. For inter-domain handover, global mobility (i.e., signalling to the Home Agent) is necessary, since a mobile agent, serving two different administrative domains / providers will not be considered for security and trust model reasons. Nevertheless, an inter-domain handover may be fast by combining global mobility management and FMIP, depending on the network design: The communication (i.e., signalling) between the old access router and new access router has to be fast. Therefore, assuming the knowledge of the surrounding point of attachments, different network providers of different administrative domains who have a roaming and service level agreement are able to provide fast routing between these different access routers and prevent sending packets all the way via the domain gateway. At this point in time, the combination of the global mobility management of Mobile IPv6 in combination with the non-hierarchical FMIP fast handover approach seems to be most appropriate within the framework of Moby Dick, because it fulfils the requirement for fast intra-domain handover for sure and for fast inter-domain handover most probably (assuming careful network design at the domain borders).

6.1.2 Handover support In order to provide uninterrupted services for roaming mobile terminals, even for real-time conversations during a handover, Mobile IPv6 needs to be enhanced, as proposed by recent Internet Drafts of the Mobile IP and Seamoby Working group of the IETF. The user is just interested in continuing the session without interruption and does not care about the deployed mechanisms or techniques or the handover scenario. Therefore, extensions for fast handover support should consider all possible handover scenarios, like inter-technology and intra-technology handover, as well as inter-domain and intra-domain handover. Assuming for the inter-technology handover that the mobile node provides two different access technologies at the same time (e.g., two different PCMCIA cards in a laptop) and that the mobile node is able to use them simultaneously, seamless handover is trivial, since the mobile node can continue the reception of packets via the old interface, while establishing a new binding via the new interface (for the duration of the handover). Intra-technology handover needs to speed up the handover (by recent mechanisms as proposed in FMIP or HMIP), since the mobile terminal is not able to send or receive any data during a handover for a certain amount of time, which needs to be minimised. This project focuses on the handover scenario within an administrative domain, since we assume that this kind of handover occurs much more frequently. At this point in time, it is not sure that inter-domain handovers for mobile nodes that are ‘far away’ from home can be fast anyway, since global mobility management is involved or a complex hierarchy within the Internet has to be established. Following the



FMIP proposal, handovers MAY be fast if a fast link for signalling between the old and the new access router is available, but if this assumption is not valid, the approach fails.

6.1.3 Access technology issues

6.1.3.1 General requirements Since the Moby Dick architecture implements several access technologies, the information to be transmitted over the wired or the air interface and the respective interface requirements (Software API) has to be studied and to be defined. These definitions must cover requirements from multiple areas, which are considered within the framework of the Moby Dick project. We assume Access Networks that are comparable to cellular networks (e.g. GSM). A Layer 3 Mobility Management protocol is used, which is (in general) independent of the access link technology. Therefore, referring to the entire access network architecture, we distinguish individual cells via the IPv6 subnet prefix address. We do not consider a handover between two cells on a Layer 2 mechanism only, as already covered in a IEEE802.11 wireless LAN environment set up in infrastructure mode, where a L2-handover can be performed between different wireless LAN Base Stations without changing the IP subnet. IEEE802.11 is a well-defined standard with a lot of hardware components and drivers available. The drivers and TCP/IP protocol suite connect the hardware to standard IP socket programming interface and additional tools allow the configuration of many parameters related to the air interface and to get parameters such as the current signal quality. This is different for UMTS W-CDMA technology. While IEEE802.11 is a technology keeping the shared medium character for transmission of data packets (with some modification on the collision handling compared to wired Ethernet and the introduction of L2 management and control frames), UMTS defines a rather complex channel structure with W-CDMA systems. Within the 3G UMTS standardisation, a central node, which is the Radio Network Controller (RNC), has control over a set of Node-B’s (Base-Stations within the UMTS radio access network infrastructure). As an example, the RNC’s responsibility is on radio channel establishment, measurement and processing of several parameters requested by and sent back to the RNC, integration of the functional entity for diversity of user data (distributing and combining), initiation of paging and management of local mobility. Since, within Moby Dick, the WCDMA Access Router is different from a 3G Node-B controlled by a centralised RNC, several issues related to the assignment of the current RNC functionality to the WCDMA related equipment or partially to an external controller need to be clarified. This is to be evaluated for functions supporting the mobility management as well as for radio resource control. The following architectural assumptions are based on the current specification of the Moby Dick architecture and can help to derive and specify requirements for the different access technologies: � A location supported by one W-CDMA interface represents one IP subnet. � Mobility Management is based on Mobile IPv6 – basic functionality may be enhanced where

required � The Access Router has at least two interfaces with IPv6 addresses, one towards the core network, the

other one towards the access link � Support for dynamic and static home address assignment for Mobile IPv6 terminals � Support of seamless handover between Access Routers providing the same access technology Wired and wireless access to the network infrastructure is provided by Access Routers, each having at least one interface connecting to the wired radio access network infrastructure, and at least one interface to the access link, which is either wired or wireless. With Ethernet as access technology, the AR supports normal IP routing with some modifications implemented for handover support and further features. This is similar to IEEE802.11, which might work in ‘independent’ mode, which is a direct communication between wireless interfaces or in ‘infrastructure mode’ (with an IEEE802.11 Access Point). When the ‘independent mode’ is considered, the respective AR implements an Ethernet interface on the network side and an IEEE802.11 wireless interface on the radio side to support the assigned cell. Further modifications might be necessary in order to support handover, paging or initial attachment procedures. The AR characteristic is somewhat different for the WCDMA technology. The respective Access Router machine, implementing an Ethernet interface on network side and the WCDMA hardware on radio side, does not perform normal IP routing anymore. We rather see additional functionality assigned to this Access Router, which might inter-work with some Radio Resource Controller/Server. This additional functionality might be necessary for supporting the mobile terminal’s acquirement of a co-located care-of



address during a handover or an initial attachment to the respective interface of the Access Router. The Access Router for W-CDMA wireless access might be considered as a distributed architecture, which has an Access Router separated from the W-CDMA Radio Gateway. The latter mentioned structure is similar to IEEE802.11 Access Points setting up the wireless LAN infrastructure. The following considers the W-CDMA interface as being integrated within the Access Router. For a discussion of a separated structure, we explicitly point to a distinct infrastructure using a Radio Gateway and an Access Router Mobility: In order to provide the MN with general information on the system, a downlink Broadcast channel, listened to by all MN’s, is a requirement. According to [36], the mapping between a logical Broadcast Control Channel and a physical Broadcast Channel is 1:1. An appropriate programming interface, which allows sending of information and configuration of this channel, should be provided on AR side. In case of having the AR separated from the wireless technology supporting Access Point (e.g. W-CDMA Radio Gateway), the Access Router should broadcast information as for an IEE802.3 Ethernet link. The responsibility of intercepting and mapping the broadcast information to the wireless interface should be on the Access Point or the Radio Gateway respectively. An interface for adjusting the channel and receiving info should be provided on the MN side. As an example, this information could be individual Access Router identifiers, Paging area identifiers and the global IPv6 address of the Access Router. Furthermore, information on the architectural environment could be broadcast in order to support the handover procedure. An appropriate mechanism should allow the MN to derive a co-located CoA. When the W-CDMA interface of the AR is not IP addressable, it has to be decided, which mechanism is used to provide the MN with a co-located CoA, since a cell-specific IP subnet would be of ‘virtual’ nature only and stateless auto-configuration with Duplicate-Address-Detection (DAD) is hard to realise. In order to attach to the network, initial information has to be exchanged between an individual MN and the W-CDMA AR. For this purpose, the bi-directional Common Control Channel or the bi-directional Shared Channel Control Channel (SHCCH), which exists only in TDD mode, could be a candidate. The same is required for a separated access infrastructure, where the W-CDMA Access Point has to provide the appropriate wireless channels. The information source could be distributed as well between the Access Router and the Access Point. Interaction between the Access Point and the Access Router might be necessary. In order to support handover, it should be possible to initiate the attachment to a New Access Router (NAR), while the old connection is still active. This is a requirement, which might not be provided by all access technologies. It may be possible when the handover implies switching the access interface on mobile terminal’s side, but this might be a problem for intra-technology handover with W-CDMA as interface technology. Some technologies allow scanning information of surrounding cells on a low-level basis, which might be restricted to scanning neighbouring cell power levels. At least a mechanism is required that allows for scanning Candidate ARs (CAR) and to carry out appropriate actions in advance. These actions should prepare the handover in advance by contacting the CAR while the existing connection is still active. Paging: The functional requirement for paging is the provision of a mechanism, which allows mobile terminals in idle mode to receive paging information. This could imply a reduced functionality in sending and receiving data while ensuring the reception of paging information. For shared medium access technologies, this could be either a Link-Layer channel or an IP-based mechanism for addressing wither a set of nodes or individual ones. For W-CDMA based systems, a specific paging channel should be available. Since the mapping of the logical Paging Control Channel (PCCH) to the physical transport Paging Channel (PCH) is 1-to-1 [36] and downlink only, no co-ordination between two or more transport channels to one logical channel is required. The AR should be able to receive L3 paging request messages from network side, generate or derive an appropriate paging message plus information and send it through the WCDMA paging channel. On the MN side, the lower layers should process info received on the paging channel and be able to compare subscriber identifiers (IMSI or even IPv6 home address). This mechanism depends on the support of ‘dormant-mode’ and the planned ‘wake-up’ procedure. As a result of the paging request destined to an individual MN, the MN has to ‘wake-up’ and to register as active with the network (possibly through the Common Control Channel (CCCH). The following sections refer to individual technologies the project has to implement in the test-bed. Additional information is provided on the technology specifics with respect to the individual items addressed above.



6.1.3.2 IEEE802.3 Since the Ethernet standard technology has the shared medium character, broadcast of system information can be handled by making use of mechanisms coming with the IPv6 over Ethernet transport specification. This uses IPv6 addresses in order to address individual nodes or groups of nodes. Mapping L3 addresses to technology dependent L2 addresses is handled by IPv6 Neighbour Discovery. Mechanisms for addressing individual nodes by a Solicited Node Multicast Address are specified within the framework of IPv6 transport over Ethernet. Here MAC address specifics are mapped to the IPv6 address and Ethernet Network Interface Cards (NIC) listen to this special kind of MAC address on a L2 basis. A requirement to be considered with Ethernet access is to allow local communications only through a switching point, which could be integrated with the respective Access Router or with a separate entity. For general system information broadcast, Router Advertisement mechanisms can be made use of. Having a separate switching point, this entity could broadcast system information as well, which is relevant for getting access especially with the switching point. In general, network system information broadcast should be initiated from the individual Ethernet Access Routers. For Paging, mechanisms like the Link-local Multicast Address as well as the Solicited Node Multicast Address can be made use of as it is specified within the IPv6 transport over Ethernet. Furthermore, authentication of broadcast messages should be considered, since there is no respective mechanism implemented as it is for the IEEE802.11 standard working in infrastructure mode.

6.1.3.3 IEEE802.11 For IEEE802.11 we have to distinguish the two modes the standard specifies. This can be either the independent mode (Ad-hoc), which allows direct communication between wireless nodes without going through an Access Point. This eases the handling of access provision, since the Access Router implements a WLAN card directly and communication beyond the scope of the local IP subnet is going through the Access Router anyway. This is different for local communication. The Ad-hoc mode allows direct communication between nodes located within the same subnet. This requires special effort in specifying a switching mechanism in order to force local traffic to be routed through this switching point. Implementing the infrastructure mode as specified in IEEE802.11, all the traffic, whether it is local or beyond the scope of the local subnet, goes through the WLAN Access Point. These Access Points broadcast WLAN specific system information independent of Access Router originated Router Advertisements. Whether or not it is useful to consider modifications in the management and control mechanisms running in the IEEE802.11 Access Point as well as within Mobile Nodes implementing a WLAN interface remains to be studied. As mentioned for Ethernet, general system information broadcast should be initiated from the Access Router, while link-specific information could be sent separately, originated by the Access Point. For idle mode support and paging, L2 specifics can be made use of with IEEE802.11, since the standard specifies a dormant mode, which saves power and can be entered by mobile nods. Appropriate mechanisms for paging information transport can be the same as it is for Ethernet, since WLAN keeps the shared medium character. How the paging protocol and mechanism can make use of the dormant mode as it is specified for IEEE802.11 remains to be studied. The standard also specifies L2 control and management frames for authentication and encryption over the air link. How to integrate these mechanisms and protocols with the Moby Dick architecture remains to be studied. When L2 security is deployed in the Moby Dick scenario, the L3 authentication and encryption should be independent and non-interfering with the mechanisms of the access technology standard.

6.1.3.4 W-CDMA For the integration of the W-CDMA technology into the Moby Dick system the same requirements have to be met. Access technology as specified within the framework of 3GPP does not have a shared medium character, as for IEEE802.11 and IEEE802.3. Here, dynamically established individual channels are used in order to transmit user data. For initial access, control and notification services, some contention based shared channels for uplink transmission or broadcast channels into the downlink direction are specified. For system information broadcast, the same as described above has to be considered, which is broadcasting network specific system information into the local cell from Access Routers, while access technology specific information might be originated by a W-CDMA specific Access Point (Radio Gateway). If the W-CDMA Access Point and the Access Router are separated, the Access Router should see the outgoing link as a shared medium and make use of broadcast and paging addressing and transport mechanisms as described above for the other technologies. The Access Point should take care of intercepting all relevant packets coming from the Access Router, to identify packets and to map to the



respective outgoing channel respectively. Since there are multiple specific channels on the W-CDMA link, there might be some kind of interaction necessary between the Access Router and the W-CDMA Access Point. By specifying appropriate mechanisms and discrimination rules for identifying individual packets, a proprietary protocol for Access Router and W-CDMA Access Point could be avoided. Having the W-CDMA equipment implemented with the Access Router avoids the need of interaction between the two entities, but implies building up a more complex composite W-CDMA Access Router node, which is responsible for Routing as well as for control of and mapping to W-CDMA specifics.

6.1.4 Idle Mode Support Within the framework of the IST Moby Dick project, IP-based mobility management is deployed. In order to allow mobile terminals to enter an idle state, where sending of frequent location updates to the network can be avoided, a mechanism has to be applied to notify idle mobile terminals of incoming traffic. The idle mode is used to reduce drain of battery energy due to superfluous signalling overhead. Notification to wake-up an idle mobile terminal is called paging. We investigate several paging mechanisms and strategies for IP-based Mobile Communication Networks, in particular for Mobile IPv6 managed networks. Furthermore, we propose an architecture for Mobile IPv6 managed networks with a respective mechanism, which allows paging of mobile terminals from inside or outside an administrative domain and to specify static paging areas as well as individual adaptive paging areas. Static paging areas are mandatory and are intended to be realised first. The concept itself should be flexible enough in order to allow future extensions for individual paging area assignment as well as different paging strategies. To allow mobile terminals to enter a power saving idle mode by reducing frequent location update signalling to the network, we have been working on analysing available draft mechanisms for IP-based paging and several paging strategies. Our intention is to specify an architecture and a mechanism for Paging support within Mobile IPv6 managed Communication Networks. With Paging, a mobile terminal can roam within a paging area, which is a cluster of multiple individual wireless access areas (cells), without the need to register the entered cell location with the network (Figure 10). For further description of these smallest indivisible units at which a mobile terminal might be located we use the term ‚location‘ rather than ‚cell‘. Only in case of crossing the borders of the registered Paging area requires to notify the network of the new Paging area. Incoming traffic for a mobile terminal is managed by some entity, which knows about the current state of individual mobile terminals roaming within the respective environment. This entity initiates paging the idle mobile terminal in order to solicit a precise location registration with the network. As soon as the mobile terminal has notified the network of its location, respective traffic can be forwarded to the terminals exact location. Recent proposals for paging support in IP-based networks restrict the assignment of cells to an individual paging area to cells belonging to the same administrative domain. Assignments of cells, which belong to the same domain, to a cluster, represent the paging area. Many proprietary paging protocol extensions for local re-addressing-based mobility management protocols like hierarchical Mobile IPv6 [43] or routing-based mobility management protocols like Cellular IP. These extensions consider paging areas not exceeding the borders of the respective administrative domain. A protocol extension like P-MIP [44], which proposes a paging extension for Mobile IPv4 managed networks, considers a non-hierarchical architecture. In P-MIP, paging is initiated from the last registered Foreign-Agent (FA) of the respective idle mobile terminal. Since there are no Foreign-Agents available within Mobile IPv6 based networks, we intend to design a concept of an external agent responsible for paging support; a Paging agent (PA). This Paging Agent should be integrated to the Mobile IPv6 platform without requiring modification of the Mobile IPv6 protocol, the Home Agent or the Correspondent Node entities. In the Mobile IPv6 managed Mobile Communication Network as we have it Moby Dick, a mobile terminal can decide to switch to an idle state in order to reduce signalling overhead on the air interface by avoiding frequent location update messages to be sent to the network. Our intention is to keep paging and a specific idle mode transparent to Correspondent Nodes (CN) communicating with a mobile terminal (MT) and to the mobile terminal‘s Home Agent (HA). The only entities, which should be aware of the mobile terminal‘s current state, are the Paging Agent and the respective mobile terminals. Within the framework of the IST Moby Dick project, we refer to an architecture as described in section 5.1 and specify an appropriate signalling mechanism based on investigations of several paging schemes. This includes an analysis of different paging schemes, which is the way of conveying the paging relevant information to the mobile terminal, the specification of the messages itself and furthermore the required modifications within Access Routers supporting several wireless access technologies.



Figure 10: Illustration of Paging Area construction

6.1.5 Diversity The main characteristic of macro-diversity is the simultaneous connection of the mobile terminal to several access routers and sending/receiving the same data packets over these links. As the radio link quality on these links is different at the same instance of time, a combination of the received signals results mostly in a better quality than each separate signal. Even if one of the links fails the connection is most likely to remain undisturbed by using the signals of the auxiliary connections. Another advantage of using macro-diversity besides the increase in link quality is the reduction of necessary transmission power of each radio gateway and still maintaining the original quality. Macro-diversity can be easily established in W-CDMA systems where the receiver already has the functionality to combine signals arriving within a certain time span (micro-diversity due to different propagation paths, Rake receiver). Also the necessary mechanisms in the fixed part of the access network are readily adaptable because the soft handover mechanisms like bicasting can be used. Problems resulting in the introduction of macro-diversity in an IP-based access network will be the synchronisation of the radio gateways for a simultaneous transmission on the downlink, finding the optimal location for the combination/splitting point of the simultaneous data flows, the additional traffic generated and thus the charging models applied.

6.1.6 QoS related areas of Mobility QoS provisioning in a shared wireless environment using IP transport is a new mater that we have to look at with special attention. The solutions to provide QoS in wireless IP networks may be similar to the ones used in wired networks, e.g. Integrated Services or Differentiated Services, but if we consider mobility on top if this, the complexity of the solution may rise exponentially. As Moby Dick addresses both intra- and inter-domain mobility in a QoS-aware context, the mobility impact on QoS must be carefully studied so that some solutions can be proposed to perform roaming and handover without excessive (and possibly no) QoS disruption in different mobility scenarios. Basically, QoS can be affected both during the handover and after the handover. It is expected that a few packets are lost when performing Mobile IP, although complementary mobility protocols such as FMIPv6 or HMIPv6 are intended to make the handover as smooth as possible. On the other hand, there is really no guarantee for the MN to be provided with the same QoS level after it has roamed to another Access Router. Even if the MN-CN path remains mostly unchanged (handover between locally close Access Routers), available resources from one router to another may be rather different. Moreover, the same physical handover can create functionally different handover situations to different mobile node flows.

In addition to these points, it must be kept in mind that a variation in QoS parameters can also be the cause of a handover: the MN is expected to be able to detect the QoS level it is given (e.g. radio bearer intensity) and then decide to perform a handover whenever these parameters are thought to be insufficient.

Paging Area 2 Paging

Area 1



• QoS change during the handover In both intra- and inter-domain mobility, the following general steps are expected to occur: 1. Physical roaming 2. AAAC re-authentication / re-authorisation 3. QoS session resume

Note that AAAC re-authentication is required to happen before any QoS re-negotiation occurs to prevent denial of service (DoS) or even theft-of-resources attacks. The AAAC re-authentication process is likely to last a significant time (especially in case of inter-domain mobility). Its impact on mobility and possible solutions are studied in the next section of this document.

Clearly, step 2 (at least the authorisation part) and 3 are closely linked since AAAC is responsible for granting access and charging a user for dedicated QoS services whose availability is expected to vary dynamically. Moreover, availability of resources is expected to directly affect the cost a mobile user will need to pay for access. This negotiation process, which is likely to slow down the handover, thus affecting QoS, is out of the scope of this document and is addressed in D0201 (QoS and AAAC interaction).

We also should look at the QoS level when the handover is being done. We may want a fast handover which is more susceptible to loss, for instance, to rapidly fulfil the SLA needed or, on the other hand, we may want a slower handover that guarantees a minimum loss, but may have other constrains in terms of delay or any other characteristic. Current MD ideas place the decision of if and when to do a handover, and to which domain/cell to handover, on the client – the requirement to be able to interact with different technologies and with different administrative domains does not allow other possibilities if one seeks a general solution. Furthermore, these same objectives lead to a design decision to perform level 3 handovers, which imply getting a new IP address and maybe a full negotiation of all network parameters. All these may potentially be dependent (although this should not be the direction of a sensible architecture, due to the inherent system complexity…) on the existing user SLA, and may have to be evaluated in real time! Those are just some variables to be taken into account in the complex scenario of QoS provision over shared wireless IP access.

After the Mobile Node has performed IP handover and has been re-authenticated and re-authorised (most of the handover time), some QoS messaging is required to resume the pending session, e.g. in the form of context transfer from the former access router to the new one.

• QoS change after the handover

When a mobile terminal with a specific SLA goes from one domain to another, there are no guaranties that the new domain will have enough resources to comply with the SLA. Also, when we consider that this new domain may belong to another Service Provider, the cost for the same SLA may be higher and the customer may not want to continue with the same SLA (that is, he may want to reduce the SLA to maintain the cost at an acceptable level).

Before the session can recover the QoS level it had before the handover, end-to-end QoS paths from MN to each CN with the corresponding QoS parameters must be retrieved. This process is expected to be initiated during the handover, possibly just after re-authorisation has occurred. It is however largely dependent on the handover scale: in case of intra-domain mobility, only the last segment(s) of the path have to be reserved. In case of inter-domain, the whole path is to be redesigned, which may take much longer without guarantee of success.

Note that some domain partnership can be used to address QoS-aware inter-domain mobility, in the form of inter- Bandwidth Brokers messaging for instance.

QoS problems in this environment can be structured around five levels of complexity: I) physical layer; ii) cell; iii) network, iv) management, and v) administration.



The issue of handover (changing the Access Point in the MT connection2) illustrates the network changes in heterogeneous mobile environments. An analysis on the issues of QoS provision in a mobility environment has to consider these multiple context switches (CS) also. Context changes in the connection can be caused by:

CS I. mobile host changing wireless cells – a MH crosses the border between two wireless cells (either UMTS or WLAN). This should ideally not lead to more AAAC traffic.

CS II. mobile host changing IP Autonomous Domain (AD) – a MH becomes connected to a different AD

(its wireless provider can have its network partitioned in different AD for management considerations, e.g.). This will require AAAC traffic.

CS III. mobile host changing wireless provider – a MH switches wireless provider. This will require

AAAC traffic, as different providers correspond to different AD also, in our network model3.

CS IV. mobile host changing transport technology (either wireless or wired) – a MH switches from wired to wireless connections or between different wireless technologies (this does not necessarily imply changes in the AD, e.g. moving from the corporation LAN to the WLAN). This may, or may not, require AAAC traffic.

Depending on the network architecture, and on the specific network connections, these changes may impact in several of the levels of complexity referred to above. Note that some of these changes may happen simultaneously. MD will have to support the ability to question the MH for instructions in order to take some decisions to some of these problems. Fault management is a central problem in all QoS environments, but in MD it is especially important: it is still not clear which level of seamless handover will be supported inside MD (“voice quality level”).

Type Characteristics Advantage Problems No CT The whole context is re-

established by the MN in the new router.

“What we have now” (Possible) interruption of service during HO Requires applications HO-aware

MH updates The MH updates the NAR with its context

No protocol needed between routers

Required synchronisation between MH and routers CT has to be done previous to the HO Security problems

Router-CT Access Routers exchange CT information on HO

Low (no?) service interruption during HO (Possible) elimination of latency

Protocol to be developed Method for choosing AR required

Central Repository

The CT is controlled by a “central” server, which keeps a copy of the context for each MH

Low (no?) service interruption during HO (Possible) elimination of latency One central decision point

Protocol to be developed Method for choosing AR required Required synchronisation between repository and routers Scalability

Application-Based

Applications are responsible for moving state between routers

CT under application control

Every protocol requires CT additions Applications have to be rewritten

Table 1: Context Transfer Strategies

2 This may be a physical or a logical change. 3 Note however that this is not strictly necessary. E.g. theoretically two UMTS providers can have a contract with the

same ISP provider, for transporting their IP traffic… and this provider may treat both networks as a common radio link, handling both wireless networks by the same transport network.



In addition to these considerations, it must be noted that a means should be found to release QoS resources after the handover when they are no longer used. In case of intra-domain mobility, terminal mobility is detected when MN roams to a new access router; resources that were reserved in the old access router can then easily be released. In case of inter-domain mobility, either the MN can inform the access router before leaving, or a timer-based mechanism can guarantee that QoS resources are not reserved for an absent user. Anyhow, interaction with AAAC is required because the mobile user should be charged for the QoS resources s/he reserves, used or not.

Transfer of context is to be taken into consideration, no specific mechanisms for the implementation into the Moby Dick environment have been evaluated and specified yet. In case of proving the requirement of CT for QoS related support, an appropriate mechanism is to be specified. Some mobility mechanisms in Moby Dick (Mobile IPv6 and its enhancements like IP Paging or BETH) uses tunnels during handover to forward packets between some old and some new access routers for the mobile device. This helps to solve routing issues introduced by the mobility but the packets must be allocated an appropriate QoS to ensure that the packets reach the mobile within the confines of the QoS contract. Therefore, as an additional option and consideration, support of DiffServ specifics might be integrated with a Mobile IPv6 Home Agent as well as with a Paging Agent in order to ensure equal handling of user-data packets when they are tunnelled. This could be just referring to the same DiffServ Code Point within the outer IPv6 header of respective tunnelled packets. Furthermore, it is to be studied, whether or not it is reasonable to have DiffServ-like queue management implemented with a Home Agent and a Paging Agent.

• Taking advantage of hierarchical Mobile IP enhancements for QoS support while on the move Besides some general considerations and proposals around IP QoS implementations [28][29][30], we here do want to indicate the characteristics of hierarchical MIPv6 approaches that are useful for QoS support. The advantage for QoS support of using a hierarchical mobility management model is that QoS related signalling can be sent only to the branches of the network affected by the change of point of attachment of the MN to this network. In particular, in a intra-domain handover, no QoS signalling is needed farther than the MAP (HMIPv6) or the crossover router (Regional Registrations). The hierarchy of regional-aware routers of the Regional Registrations proposal is especially useful to send the QoS signalling exactly to the affected routers (those up to the crossover router). All the state in routers beyond the MAP (HMIPv6) or the crossover router (regional registrations) is kept between intra-domain handover. This also avoids the possibility that a MN that changes its subnet is denied the requested QoS because of lack of resources in the core network, just because these resources are reserved to the old point of connection to the network of the MN. Using a hierarchical approach, the common resources between the old path and the new path are not requested again. The MAP entity could therefore play a dedicated role when acting together with some counterpart QoS central entity.

6.1.7 AAAC related areas of Mobility

Appropriate interworking of mobility management with AAAC framework is required to enable true support of mobile users/terminals roaming between different networks possibly belonging to different operators/ISP.

AAAC additional messaging is largely dependent of the kind of handover. It is also expected to be possibly largely reduced if any kind of commercial agreement exists between the 2 domains.

•

Re-authentication for inter-domain mobility If handover occurs between two administrative domains that do not have any mutual trust agreement, the whole re-authentication process, which involves MN's home AAAC server, is to take place again, thus leading to an increased latency. If any partnership exists, the situation may vary from this basic level to enhanced, fast, re-authentication schemes like those exposed below.



• Re-authentication for intra-domain mobility AAAC architecture requires that an IPsec tunnel be established between the MN and the AAA client (Attendant) once the MN has been correctly authenticated in order to prevent impersonation (filtering on source address would clearly be insufficient). A security context with the new Attendant / AR can easily be derived from the previous one; the fact that the MN possesses the key used to encipher / decipher packets to / from the previous Attendant is a strong proof of its identity and the former key itself constitutes a shared secret that can be used either to re-exchange an IPsec key or as is, as the new one. We assume here however that the new Attendant must know the key that the MN used with the previous Attendant (e.g. it can have been passed from one Attendant to the other during the handover).

Mobile IPv6 security specifies that its signalling (Binding Update, Binding Acknowledge, Binding Request…) must be authenticated. This is a hot topic as lightweight authentication mechanisms are currently under investigation at the IETF to solve this issue. It is worth mentioned however, that when available an AAA infrastructure can help in solving some part of this problem. In particular, AAA can be used as a Key Distribution Centre (KDC) to distribute shared keys between the Mobile Terminal and its Home Agent. A similar approach should be also investigated in order to provide a security framework for IP paging. Dependent on the location of a Paging Agent, additional investigation of related security considerations is to be done. In general, three paging related scenarios have to be looked at, which is � paging service advertisement, � idle state registration with a Paging Agent, � signalling related to the paging process. A Paging Agent, offering services to Mobile Nodes, should be authenticated in order avoid offer of paging related service from a malicious node pretending to be a Paging Agent. In case of offering this service from outside an administrative domain implies more critical security considerations as it is for having a paging service integrated into a local administrative domain. The same is to be considered, when a Mobile Node registers as idle with a Paging Agent. The Mobile Node is to be authenticated by the Paging Agent, which is easier to handle, when the Paging Agent is located in the local administrative domain the respective Mobile Node is roaming in and has already been authenticated by the domains security architecture mechanisms. In this case, the Paging Agent could access local AAA architecture and use it as KDC, as referred to above. Additional establishment of security associations is to be taken into consideration when having the Paging Agent located outside a local administrative domain. For the paging process, which intends to wake up a dormant Mobile Node, respective signalling messages are to be authenticated in order to avoid that malicious nodes are able to wake up a Mobile Node, which has registered as idle before. • Taking advantage of hierarchical Mobile IP enhancements for AAA support while on the move In parallel to what was said about QoS and HMIPv6 in the previous section, hierarchical MIPv6 approaches and a AAA infrastructure could take benefits from each other in a mobile scenario. In particular, the MAP or GMA can store the MN’s security credentials (a session key common to the MN and the visited domain) after this MN is allowed network access. After an intra-domain handover, the MAP or GMA can pass these credentials (the key that the MN is using for authentication in the visited domain) to the new AR to avoid performing again the AAA process. This can speed up the handover. Alternatively, in the case of regional registrations, the security credentials (the session key) can be stored in the AR, and the new AR can get them from the old AR (it knows it from the previous access router sub-option of the BU, this is not in principle the case in HMIPv6). This avoids the overloading of the GMA with all the security credentials of its MNs. All the nodes (ARs, MAPs, GMAs, regional-aware routers) belonging to the same domain are supposed to have their own security associations.



6.2 Overview of related components This section will give an overview on related components within the Moby Dick architecture where the Mobility Work Package 3 focuses on. These components are related to nodes, which might be Servers, Agents, end-terminals or Routers with enhanced functionality in order to support meeting WP3 requirements. These nodes might implement more than one of the described functional entities. If functional entities for an individual service are distributed in the system (decomposed architecture), these details are not described in this section. Of course, functional entities might be distributed within a system on multiple nodes for several reasons. What’s described here is the WP3 related individual architecture components for mobility management and paging support.

6.2.1 General components In general, the architecture is set up with standard IP based equipment for user data transport as well as for control data transport. From mobility point of view, signalling traffic as it is used for SIP or H.323 session setup, is user-data. Mobility should be transparent to these application specific control and management layers. Standard IPv6 Routers are used of for packet forwarding. Enhanced forwarding mechanisms as specified within the framework of the QoS Work Package are not described in this section, but might be implemented in Routers. The Mobile Node, which is the mobile terminal device a user carries along while roaming, can either be attached to its home sub-network, to a different sub-network assigned to its home administrative domain provider or to a foreign sub-network assigned to a foreign administrative domain provider. In all cases, the Mobile Node is assigned an IPv6 home address. In case of being attached to its home subnet, in general only the home address is used for communication purposes. Since more than one IPv6 address might be assigned to a MN's interface, alternative addresses might be made use of. In case of roaming, only one dedicated home address will be kept and used as home identifier for IP mobility management purposes (e.g. Mobile IPv6 registration). When the Mobile Node leaves its home subnet, it acquires a temporary care-of address identifying its foreign location. The binding between the Mobile Node's home address and its care-of address is to be registered with its Home Agent. In this case, the Mobile Node keeps its home address, and has at least one foreign subnet care-of address configured with its (active) network interface. Special Routers are to be deployed at the edges of radio access networks, which provide wired or wireless access to Mobile Nodes through at least one interface oriented towards the access link. These Access Routers might implement the access technology directly or have an appropriate Radio Access Point connected, which is responsible of supporting the respective access technology. In case of IEEE802.11 standardised wireless LAN access, this Access Point can be the standard Base Station as it is defined for wireless LAN infrastructure mode or an enhanced one, providing additional features for support of meeting the requirements. These enhancements might be defined within the framework of the Moby Dick project. A realisation of implementing the protocol enhancements into the Access Point does not appear feasible at this stage, since there is no access provided to the IEEE802.11 component’s firmware. If an enhancement is proved as reasonable, it will be proposed by the project, but it either will not be part of the field trials architecture or it will be implemented in a feasible alternative way. This is different for the W-CDMA equipment. Since the equipment and related protocol implementation is developed from scratch, the project can influence and propose protocol extensions and enhancements. The W-CDMA equipment might be integrated into the Moby Dick platform in a distributed manner, which is having the W-CDMA access technology not directly integrated with the related Access Router. Since the external node implementing the W-CDMA has advanced functionality including appropriate protocol stacks and furthermore complex management and control functional entities, this node refers to a Radio Gateway, rather than to a more lightweight L2 Access Point. As already addressed in the requirements section of this document, the Ethernet based access has to provide some switching functionality nearby or within the related Access Router in order to allow local communication control and monitoring from Access Routers. Practical realisation of monitoring in the test-bed is to be studied, but might be based on just monitoring the shared medium access. In general, the Access Routers will implement not only mobility related functional entities. Since this node is the candidate for last-hop control mechanisms, it will implement several functional entities and attendant functions.

6.2.2 Global Mobility Management For global mobility management, the basic component will be the Home Agent as specified in the Mobile IPv6 proposal. This node is responsible for forwarding of user data packets destined for the Mobile Node’s home address if the Mobile Node has registered information on its foreign location with the Home Agent. The foreign location is identified by a temporarily assigned IPv6 address that the Mobile Node



acquires when entering a foreign domain’s subnet. This foreign temporary IPv6 address is called the care-of address. The packet forwarding is transparent to the originator of the packets. For incoming traffic, the Home Agent performs Proxy Neighbour Discovery on behalf of the respective Mobile Node and intercepts user data packets. The Home Agent makes use of IPv6-in-IPv6 tunnelling to forward traffic to the Mobile Node’s final destination. When the Mobile Node enters a new subnet, it acquires a different care-of address and re-registers its new location with its Home Agent. Mobile IPv6 integrates the route optimisation approach, which allows direct communication between a Correspondent Node and a mobile terminal. When initial packets are intercepted at the Home Agent and tunnelled to the mobile terminals current location, the mobile terminal can contact the Correspondent Node and request it to send packets directly to the Mobile Node. The notification of the care-of address is the same as it is for a registration with the Home Agent, which is called the Binding Update message. When the respective Correspondent Node maintains a binding cache, it makes an entry of its communication partners care-of address into the binding cache and sends user-data packets directly to the mobile terminal’s current location making use of the routing header extension. If no route optimisation is supported by the Correspondent Node, the Binding Update is rejected and further packets are still sent through the mobile terminals home network. Paging a Mobile Node can be initiated from outside an administrative domain. If the architecture supports this, a Paging Agent might be located either in the home network (personal Paging Agent) or in another domain. This requires additional security considerations when allowing a node from outside to poll a paging area specified within the scope of a different administrative domain. Security associations (SA) are to be established between Mobile Nodes and Paging Agents as well as between Paging Agents and respective administrative domains. The authentication of paging relevant signalling and information broadcast is to be considered in the design of the paging architecture. Having a personal paging agent within the home network allows easier handling of a SA between a mobile terminal and its Paging Agent, while authenticating the Paging Agent is to be studied and specified thoroughly. Even hierarchies of Paging Agents might be considered, where agents located outside a domain can communicate to local agents.

6.2.3 Localised Mobility Management When no hierarchy of mobility management agents is deployed, the Home Agent is notified of every movement, which implies changing the care-of address. The benefit of introducing a hierarchy depends on multiple parameters, which is to be examined within the framework of this project. This is done in a simulative study. Without a hierarchy, signalling between a mobile terminal and its Home Agent might take enough time in order to let an open communication session (e.g. Voice over IP) appear interrupted and to cause loss of packets. This definitely requires additional mechanisms for handover support in order to make a movement between adjacent subnets fast and smooth. Handover support within an administrative domain can be handled at Access Routers, implementing respective additional functional entities. Having a hierarchy within an administrative domain supports switching between adjacent IP subnets as well, which might make Fast-handover support at Access Routers unnecessary. Hierarchical approaches introduce one or multiple additional levels of local mobility management agents and attendant nodes. The highest level functional entity is located in the Gateway Router of an administrative domain or in a separate node attached to the Gateway Routers subnet link. The IETF proposals for hierarchical approaches mainly refer to Hierarchical Mobile IPv6 (HMIPv6), which specifies a Mobility Anchor Point (MAP) node, and to Mobile IP Regional Registrations, which specifies a Gateway Mobility Agent (GMA) node. One could also think of having a combination of both, a hierarchy together with Fast-handover support implemented in Access Routers. For paging within an administrative domain, this should be the responsibility of a local Paging Agent. This node should be integrated into the domain without the need to modify the existing mobility management architecture and protocols. The paging process could be initiated by user-data packets coming from local entities (e.g. a local mobility management functional entity) or from outside an administrative domain (e.g. Home Agents). In general, functional support for Fast-handover and paging is expected to be implemented in Access Routers or is appropriate attendant nodes physically separated from Access Routers. How far Access Points and Radio Gateways implement functional entities supporting handover and paging is to be studied and to be specified. Separation of functional entities may be reasonable in some cases and depends on the architecture for access provision.



7. Evaluation and Specification of Components

7.1 Integration of Access technologies

7.1.1 IEEE802.3 The IEEE802.3 interface standard has no mobility specific function.

7.1.2 IEEE802.11 The IEEE 802.11 standard is the world’s first wireless LAN standard for packet data applications operating in the 2.4GHz unlicensed frequency band supporting data rates between 1 and 11 Mbps (with an extension to the physical layer, resulting in 802.11b). Two radio physical layers are possible within the standard: FHSS (Frequency Hopping Spread Spectrum) and DSSS (Direct Sequence Spread Spectrum). There are two classes of wireless local networks:

1. Ad-hoc networks: all the stations are within mutual communication range of each other, communication is direct between stations without using other communication devices. These networks are called IBSS (Independent Basic Service Set) in the IEEE 802.11 standard.

2. Infrastructure networks: networks that use access points to allow their associated stations to communicate among themselves and to distribution systems. Using a distribution system is possible to interconnect several BSSs to form an Extended Service Set (ESS).

The IEEE 802.11 uses a shared medium for transmission (radio channels in the 2,4 GHz band). So some MAC protocol is needed to regulate the access to the medium of the different stations in a wireless network. There are two modes to do this:

� Carrier-sense multiple access with collision avoidance (CSMA/CA): A mandatory contention-based protocol similar to IEEE 802.3 Ethernet. The 802.11 specification refers to this mode as the distributed co-ordination function (DCF).

� Priority-based access: An optional contention-free access protocol usable on infrastructure network configurations containing a controller called a point co-ordinator within the access points. The 802.11 specification refers to this mode as the point co-ordination function (PCF).

As the name implies, the access mechanism for DCF is entirely distributed. This can result in two workstations transmitting simultaneously since each node is responsible for determining if it is safe to transmit. To determine if it is safe to transmit, a station must:

� First sense the medium for a required time interval to ensure that no other station is transmitting or plans to transmit.

� If not then it can proceed with transmission � If the node senses that another node is transmitting then it will go into a back off mode. � In back off mode the station, selects a random interval to use for its back off timer

The station decrements its back off timer only when the medium is idle. Once the station’s back-off timer reaches zero, it transmits. DCF also supports the use of Request To Send (RTS) and Clear To Send (CTS.) IEEE 802.11 requires that all devices support RTS and CTS. However, their use is optional. By using an RTS/CTS/DATA/ACK sequence of transmissions, the effects of a “hidden node” can be mitigated. It should be noted that Acknowledgement (ACK) packets and CTS packets are given higher priority than DATA frames. This means that a workstation needing to send an ACK or a CTS packet once it receives a DATA or RTS packet, can do so without going through the contention phase presented above. This priority is implemented through the use of different Inter-Frame Space (IFS) intervals. For DCF, two such intervals are specified. The first is DIFS, or DCF IFS, which is the mandatory time for sensing the channel prior to data transmission. DIFS is used when transmitting DATA or an RTS packet. The second interval, Short IFS (SIFS), is the time for sensing the channel prior to sending a CTS or ACK frame. Because SIFS is much shorter than DIFS, a station receiving a packet will always be able to send



an ACK or CTS before any other station can send data because it only has to wait 1 SIFS while the other stations must wait at least 1 DIFS. PCF supports both asynchronous and time-bounded services such as voice traffic, and would be used in a WLAN with an existing infrastructure (access-points). In this type of system there is a Point Co-ordinator, generally an access point, that uses a poll-response scheme and provides nearly isochronous operation. If stations have time sensitive data to transmit, they will request that the PC add them to its polling list. Periodically, the PC will gain access to the medium to begin a contention-free period (CFP) These CFPs are limited so that contention (DCF) periods are able to occur. To gain access to the medium, the PC uses DCF and then transmits a beacon to mark the beginning of the CFP and advertises the expected length. All stations mark the expected duration in their Network Allocation Vector (NAV) After the beacon, PCF IFS (PIFS) is used when transmitting so stations using DCF will not get to transmit since PIFS is shorter than DIFS. During this CFP, the PC can send data to a station (or multiple stations), a Contention-Free poll (CF-Poll), or a Contention-Free ACK (CF-ACK.) This can be done in single or multiple frames. The stations during this period can CF-ACK a data frame from the PC or send data to the PC in response to a CF-Poll. At the end of the CFP, the PC will send a Contention-Free End (CF-End) to let all station know that the CFP has ended an that the DCF contention period has begun. All these concepts are illustrated in figure below (taken from the ANSI/IEEE Std. 802.11, 1999 edition). However, it is important to realise that available products only implement the DCF mode of operation.

Figure 11

Three classes of frames are used in the MAC layer of the IEEE 802.11 standard: management frames, control frames, and data frames. Management frames are used to establish initial communications between stations and access points. Control frames are used to assist in the delivery of data frames. We have already seen several examples: RTS, CTS, ACK, CF-End, etc. Data frames are used mainly to carry information of upper layers. One especially interesting management frame is the beacon frame. It is used by stations to discover 802.11 networks. In an infrastructure network the access points periodically sends beacon frames. In an ad-hoc network all stations periodically send beacon frames. This allows new stations to discover, synchronise and join the IEEE 802.11 network. It is possible to actively look for a IEEE 802.11 network by sending a management frame called Probe request. A beacon frame has enough information for a station to join the corresponding network, for example service set identity, supported rates, information for timing synchronisation, etc. As it is a frame, potentially other information could be included there (for example, some vendors use this frame to send proprietary extensions to the protocol). One possibility is using this frame to send information that can facilitate layer-3 mobility management, but this is currently under analysis in the project. There are also proposed mechanisms to increase efficiency of PCF ([50]), studies about supporting voice services over 802.11 ([51], [52]), introduction of service differentiation for DCF ([49]), and many others.



7.1.3 W-CDMA The W-CDMA provides the following components that can be used by the mobility procedures. • Radio Gateway (RG) broadcast service

The Radio Gateway broadcasts on a regular basis some System Information to all the UEs in the cell. This system information can contain for example IP Router Advertisement messages, encapsulated in a System Information Block 1 (SIB1), or a list of suitable neighbouring cells, encapsulated in a SIB 18. We plan to modify the format of this last block to include the list of neighboring RGs with their IP addresses instead of the PLMN identities.

• RRC Connection Establishment

The UE entities enter the connected mode via the Connection Establishment procedure. The decision is taken by the NAS (upper layers), which must keep track of the UE state: idle or connected. This procedure triggers the establishment of the signalling radio bearers RB0 to RB3. RB3 is reserved for the RRC messages carrying NAS Signalling Data Transfer. This Connection Establishment procedure must be performed each time the UE joins the cell of a new RG.

• Radio Bearer Establishment Prior to data transmission, a Radio Bearer must be established by the NAS. A signalling message is sent from the UE to the RG transparent to AS entities. The network checks if resources are available to set-up the session (congestion, QoS,…). If the answer is positive, it triggers the establishment of a Radio Bearer with the requested QoS.

• Handover The AS can provide some measurements (like neighbouring cell power levels) to the upper layers in order to help for handover decision.

• Notification and Paging When it needs to page a Mobile Terminal, the NAS of the RG provides the paging message to the AS control entity. This data is forwarded to the UE Access Stratum, which delivers it transparently to the NAS.

7.2 Simulative study of the mobility architecture This chapter specifies the simulation environment and parameter specifics for micro-mobility related simulation as well as for macro-diversity related simulation. Since the simulation tool used for the two areas to be evaluated is different, the simulation of micro-mobility is handled separately from the macro-diversity simulation.

7.2.1 Specification of the micro-mobility simulation environment As already mentioned in chapter 5.2.1.2, where the relation between Moby Dick and Hierarchical Approaches in MIPv6 is described, there is a common agreement in the idea that Mobile IP is a suitable protocol to face macro-mobility. To enhance the protocol for micro-mobility scenarios recent proposals have been made. However, these assumptions have to be corroborated via simulations in order to obtain and indication of which are the real problems that we could face in an implementation and to decide whether an extension of MIPv6 should be introduced. The specification of the simulations has been divided in macro- and micro-mobility scenarios due to their intrinsic differences. The goal for the micro-mobility simulations is to obtain figures relative to the end-to-end delay, signalling overload, latency, scalability, processing delay, etc, in order to compare the performance of the basic MIPv6 compared to the one with hierarchy. The simulations should give and idea of the improvements versus the cost for the deployment of a hierarchical MIPv6 extension. For our simulations the tool ns, network simulator [45], will be used. The ns Network Simulator is an event driven simulator for computer networks and network protocols. It has been chosen as the simulation



tool because of its modular and open architecture. Since it is widely used in the research community, a large number of network components are available for ns. By reusing these components, the development of complex architectures can be considerably facilitated.

7.2.1.1 Micro-mobility specification In the Moby Dick project we are focusing on MIPv6 and currently ns does not support MIPv6, as a previous phase, an extension of the ns libraries for supporting IPv6 and MIPv6 should be developed. The extensions will include:

� Route optimisation � Routing header � IPv6 header � Anycast address � Neighbour Discovery � Binding cache � Binding Update list � Home Agents list � CN implementation � MN modification

Recently Thierry Ernst has contributed ns-2 code for MIPv6 developed working in a project called PLANETE from Motorola and Inria. The study of this code is needed to decide whether is what we need or not. If the code is useful for Moby Dick this will simplify the work to be done for the simulations.

The implementation of HMIPv6 or Regional Registration for ns is also not available so in order to test the performance of a hierarchy approach compared to the original MIPv6 an implementation for ns is necessary. For the simulations in principle the version 6 of ns-2 will be used. The steps will be the following: decide whether to use the code from Thierry or to implement new one for MIPv6, implement the code of a hierarchy proposal for ns, choose the simulation scenarios and the parameters more interesting to simulate, perform the simulations and finally analyse the results.

7.2.1.2 Identification of parameters There are some proposals for the resolution of the so-called micro-mobility problem via the introduction of a hierarchy, Hierarchical MIPv6 [46] and Regional Registration [20], before there were CIP and HAWAII. An overview of these proposals can be found in chapter 5.2.1.2. The goal of the simulations is to provide an evaluation of the performance of MIPv6 with and without hierarchy extension under different scenarios and considering different parameters:

� End-to-end delay � Processing delay � Link delay � Wireless delay � Different kind of sources: UDP/CBR, UDP:ON/OFF, TCP/FTP, VoIP � Movement patterns of the MS � Real-time applications requirements � Handover latency � Signalling load � Scalability � Number of levels of hierarchy � Impact of the wired delay vs the wired delay � Impact of the position of the CN



7.2.2 Simulation for Macro-Diversity Usage in Moby Dick In the Simulation for macro-diversity usage in Moby Dick, the benefits of using macro-diversity in Moby Dick environment are investigated. The first step is to simulate mobile users moving around in different network areas on a session level. The performance improvement by using macro-diversity in the network is being evaluated. IND (Institut für Nachrichtenvermittlung und Datenverarbeitung, University of Stuttgart) Simulation library (SimLib) is being used in the simulation. It is a C++ library, which is mainly used for the event-driven simulations of complex systems in the area of communication engineering. It is a flexible and powerful tool which is developed at IND, and a lot of simulations have been done using SimLib at IND for communication systems, Internet, and real time systems.

7.2.2.1 User Mobile Behaviour A certain number of mobile users’ behaviours are simulated, they request service from the network, while moving around in network areas covered by different radio gateways. A mobile user requests service on a session basis. A session from a mobile user is characterised by the uplink bandwidth, the downlink bandwidth and the time duration. When a user starts a session, he will register with the network, if there is enough bandwidth in the network, the required bandwidth will be allocated to the user and the session will start, otherwise the session is blocked. In this case, the user will wait a random time to start another session. The duration of a session is a random time, when a session finishes, the user will de-register with the network and the bandwidth used in the network will be de-allocated from the user. A user will stay in an area for a random time and then move to the next area covered by a different radio gateway. If a user has an on-going session while changing the area, there will be a handover between these two radio gateways. This handover is on a time basis. To handover a session, a user first de-registers with the old radio gateway, then registers with the new radio gateway, if the registration is successful, the session will continue, otherwise, the session is lost.

7.2.2.2 Network Topology There are many possible network topologies. The first step of the simulation is to use a simple hierarchical topology, which is composed of a number of nodes and fixed links between them. They are used to simulate the radio gateways and routers. The routing in this topology is also fixed. In future simulations, more complicated topology and routing protocols can be used. The topology used in the simulation is shown in Figure 12. There are 19 nodes in this topology, the nodes are interconnected by directional links. There are two kinds of nodes: radio gateways and routers. Node 5 to 18 are radio gateways, they have radio links for uplink and downlink data traffic. Each radio gateway’s radio links geographically cover an area as indicated in the figure. Mobile users in the coverage area of a radio gateway can use radio links for data transmission. Each of the radio links has a certain amount of bandwidth, which can be shared by some mobile users. Node 0 to 4 are routers between radio gateways and the core network, they do not have any radio links, but only fixed links between each other, which are used to transfer data between radio gateways and the core network. The links between the routers are directional links, each of them has a certain bandwidth which can be shared by many users. Some of the radio gateways also work as routers, in this case, they have both radio links and network links, for example, node 5, 6, 10, 14, 15 and 16. In this simple topology, the links between nodes are fixed, the routing from one node to the other is also fixed. Node 0 is the gateway router, which connects all the other nodes to the core network, all the other nodes have a top node that leads themselves to it. For example, node 9’s top node is node 5, node 5’s top node is node 2. If a mobile user wants to have a session in the coverage area in node 9, the uplink data from the user will be routed from node 9 to 5, 2, 1 and 0, the downlink data will use the reverse route.



Figure 12: Network Topology

Each radio gateway geographically covers an area, and has some neighbouring radio gateways, for example, radio gateway 5 has radio gateway 6, 7, 8, 9 and 11 as its neighbouring radio gateway. It is assumed that two neighbouring radio gateways have overlapping areas in which users can have access to the radio resource from both radio gateways.

7.2.2.3 Service Scenario If a mobile user requests a session from a radio gateway, the radio gateway will first check whether there are enough bandwidth in its radio links, if there are, it will check with the routers if there are enough bandwidth in the fixed links, only when there is enough uplink bandwidth from this radio gateway to the core network and also enough downlink bandwidth in the reverse route, will the radio gateway register the user, otherwise the session is blocked. The reason that a mobile user is blocked could be either there is not enough bandwidth in the radio gateway, or there is not enough bandwidth in the fixed links to core network. If a mobile user is registered with a radio gateway, the radio gateway will allocate to the user the required uplink and downlink bandwidth in the radio links, the uplink bandwidth from the radio gateway to the core network is also allocated to the user together with the downlink bandwidth from the core network to the radio gateway. When a session finishes, a user will de-register with the radio gateway and the bandwidth in the radio links and the fixed links will be de-allocated. When a user moves from the coverage area of one radio gateway to another, if there is an ongoing session, there will be a handover between the old radio gateway and the new radio gateway. In the first step of simulation, the handover is only based on time. A user will stay in the coverage area of a radio gateway for a random time, when the time reaches, the user will move to the coverage area of the next radio gateway. The handover is successful if there is enough bandwidth in the radio links of the new radio gateway, and also enough bandwidth from the new radio gateway to the core network. If the handover fails, all the bandwidth allocated to user will be released, and the session is lost. A mobile user can take advantage of the overlapping areas to reduce the block probability and loss probability of sessions, this is the usage of macro-diversity.

7.2.2.4 Macro-Diversity Scenario Macro-diversity can improve coverage and linkage quality in mobile communication systems. Here the improvement of performance in the network by using macro-diversity is evaluated. When a mobile user requests a session in an area, the user can use any radio gateway that has radio coverage in that area to start a session. A mobile user can also take advantage of the overlapping areas during the handover of a session.



The scenario of macro-diversity usage is depicted in Figure 13. In this figure, each of the triangle areas is covered by three radio gateways, mobile users in a triangle area can have service from any one among the three radio gateway. Moving between the triangle areas may lead to handover if the new area is not covered by the radio gateway that provides the service any more.

Figure 13: Macro-diversity scenario

7.2.2.5 Problem of Interest and Future Work Simulations will be run based on the above mentioned scenario and topology. The session block and loss probability is measured. The blocked sessions are the sessions that cannot start up, the lost sessions are the sessions that are lost during handover. The data loss probability is also measured, it is the percentage of data that are lost in all the blocked and lost sessions. The link usage and loss probability on a link are measured, the link usage is the integral value of the percentage of bandwidth usage on a link, and the loss probability is the number of refused requests divided by the total number of requests on a link. Simulations without macro-diversity and with macro-diversity will be run to evaluate the performance improvement. The above mentioned scenario works as the start point of the simulation. In future simulations, the topology of the network may be changed according to Moby Dick architecture. And the macro-diversity scenario will be changed accordingly. The simulation will also be done on a packet level. Different handover strategies maybe adapted. All these changes will be done in accordance with the requirement of Moby Dick.

7.2.3 Evaluation via simulation [Open]

7.3 Mobility Management

7.3.1 Inter-administrative domain mobility

7.3.1.1 Fast Handover Support Inter-administrative domain mobility requires global mobility management, i.e., message exchange with the Home Agent or a mobile agent entity outside the respective administrative domains, which is difficult to realise due to security constraints. The focus of this project is on intra-domain handover, because in the Moby Dick field trial scenario this kind of handover is expected much more frequently. The deployed fast handover mechanism is described in the next chapter. This non-hierarchical handover approach may speed up the inter-administrative domain mobility, as well, depending on the design / topology of the network: The proposals requires a fast signalling link between the OAR and the NAR, in order to provide fast and seamless handover. Considering the communication of OAR and NAR, which are located in different administrative domains, the delay (i.e., Round Trip Time) is expected to be high, since the packets have to go ‘all the way up’ to the gateway router of the old administrative domain and way back in the new administrative domain. Assuming that the two administrative domains have roaming or service level agreements and know about the neighbourhood of the access points of the different domains, the network design could take care to provision a fast link between the access routers, e.g., by simply adding an additional domain gateway. This kind of network design would allow fast handover even for inter-administrative domain mobility under the assumption of a recent roaming agreement between the different providers.



7.3.2 Intra-administrative domain mobility

7.3.2.1 Fast Handover Support This section considers fast handover mechanisms in Mobile IPv6 without introducing hierarchical concepts by summarising and evaluating the recent Internet Draft Fast Handovers for MIPv6 [47] and proposes further improvements. This draft specifies protocol enhancements to Mobile IPv6 [48] that minimises handover latency, i.e., the time during which the Mobile Node is unable to send or receive data. Therefore, communication between the old access router (OAR) and the new access router (NAR) is established by the definition of four new messages. Furthermore, a forwarding mechanism from the OAR to the NAR for data destined for the Mobile Node (MN) is supposed to be implemented. An extension of the proposal mentioned above replaces this forwarding by a bicasting mechanism, i.e., packets are duplicated by the OAR and delivered to both possible access points. This Draft and the evaluation do not introduce a hierarchy and this report does not intend to provide a solution or comparison of hierarchical vs. non-hierarchical approaches or specify combination possibilities. The report aims to give the non-hierarchical fast handover basis input for such an analysis, which is considered as the next step in future work. Summary Fast Handover for MIPv6 Draft Constrains Basic assumption of this Draft is that scenarios in which the handover cannot be initiated until the MN has layer-2 connectivity to the new access router are not considered. The Mobile Node acquires all necessary layer three information for the IP handover via the previous, currently used access router. This preparation phase includes new care-of address (COA) configuration, Duplicate Addressing avoidance and Neighbour Discovery. The proposal supports network initiated and Mobile Node initiated handover scenarios. The Draft is in full compliance with Mobile IPv6 and intends to be considered as a MIPv6 protocol enhancement. Protocol Overview The Mobile IPv6 protocol is enhanced by this approach to minimise handover latency, i.e., handover interruption time, by enabling access routers to support IP handover: four newly defined messages allow the old access router to contact the new access router prior to the handover and gather necessary information for the Mobile Node’s new care-of address. Furthermore, the old access router forwards packets destined for the Mobile Node to the new point of attachment, which moves the necessary sending of the Binding Updates (BU) to the Home Agent (HA) and Correspondent Nodes (CN) (i.e., assuming route optimisation) out of the handover interruption phase. The location can be updated after the handover without losing packets or increasing the handover interruption time. The following messages are used in this specification:

Message Short form Direction Router Solicitation for Proxy RtSolPr MN to OAR Proxy Router Advert PrRtAdv OAR to MN Handover Initiate F-HI OAR to NAR Handover Ack F-HAck NAR to OAR Binding Update F-BU / F-BACK As defined in MIPv6 [48] + some flags Fast Neighbour Advertisement F-NA MN to NAR

Table 2: Messages

The following Figure 14 (extracted from the Draft itself) intends to give a brief overview on the signalling framework without the pretension of completeness, which would go beyond the scope of this summary (i.e., for detailed information concerning the messages, see [47]).



MN oldAR newAR| | ||------RtSolPr------->| ||<-----PrRtAdv--------|--------HI--------->||------F-BU---------->|<------HACK---------|

Disconnect <--F-BACK--|--F-BACK--> || | || forward || packets===============>|

Connect | ||----------------F-NA-------------> || | Deliver|<=====================================Packets

Figure 14: General message framework, i.e., Mobile determined handover.

This general signalling flow varies for network initiated and Mobile Node initiated handover scenarios, which are both supported by the framework of this Draft. The main differences are outlined in the following sub-sections. Mobile determined handover scenario In this scenario the Mobile Node itself has to define and initiate the handover, by means of its movement detection mechanism, which may include layer-2 signalling measurement for this purpose, as improvement to standard Mobile IP movement detection. Figure 15 illustrates the Mobile determined handover and the respective message flow between the Mobile Terminal, the OAR and the OAR. The following description of the fast handover mechanism refers to the numbering of messages in Figure 15. To indicate and initiate a fast handover the Mobile Node sends a Router Solicitation for Proxy (RtSolPr) to the old access router [(1)], which already contains some identifier to indicate the new point of attachment (NAR_ID). The OAR replies with a Proxy Router Advert (PrRtAdv) indicating the status of the request (e.g., point of attachment unknown or information about the new prefix / COA) and announces the handover to the new access router by using the Handover Initiate message (F-HI). Alternatively, the OAR can keep back the Proxy Router Advert message until the signalling handshake with the candidate NAR, using the F-HI message expecting an appropriate F-HAck message as a reply, has been completed successfully [(2)]. Before executing the handover, i.e., reconfiguring the interface, the MN sends a Binding Update, which contains the new COA, to its old access router to set up the forwarding mechanism [(3)]. In order to attach to the new access router, the MN sends the Neighbour Advertisement to initiate the flow of packets, which should be already waiting there. The MN may receive the Binding Acknowledgement (F-BACK) either through the OAR or the NAR, indicating that the handover is completed. When the MN has completely attached to the NAR, the new COA can be registered with the MN’s HA through the NAR [(4)].



Figure 15: Signalling message flow for a mobile determined handover using Fast-MIPv6

Network determined handover scenario The network initiated handover scenario consists of the same message and signalling flow, apart from the fact that the initialisation is performed by the OAR. To indicate the necessity of a handover the old access router sends a PrRtAdv with a new prefix / COA to the Mobile Node. The ultimate decision, i.e., the exact handover point in time, is still performed by the MN, because it has to send the F-BU containing the new prefix / COA to continue the handover. Security considerations The Fast MIPv6 handover proposal assumes that a security association exists between the old access router and the Mobile Node, as well as between the old and the new access routers, which is not a trivial requirement. Provided the above is true, security aspects relate to standard Mobile IP requirement, e.g., BUs must be authenticated. It is highly recommended that RtSolPr and PrRtAdv messages are also authenticated. Layer-2 considerations This approach is layer-2 independent, but may use layer-2 hints, if available. The Mobile Node has to become aware of another present access router, e.g., by listening to layer-2 beacons of a new access router on layer-2, while still connected to the old access router on IP-layer (e.g., by means of frequency scanning). This router advertisement has to identify the new point of attachment. For different access technologies, there may be different kinds of identifier in the recent layer-2 beacons, which have to be resolved. The router advertisement may contain:

OAR

INET

HA CN

NAR

Handover Initiate

Handover Ack

BindUpdate (start forward) + ACK

1

2

3 4

BindUpdate (to HA) + ACK

4

Router Solicitation for Proxy (NAR_ID) Proxy Router Advert (Result, CoA, NAR-MAC, NAR-IP)

1



• Identifier, which has to be resolved by a certain network service (e.g., like DNS) • MAC-address • IP address of the new access router, itself

The last item is desirable, but cannot be assumed for all access technologies. Enhancement proposal An optional proposal to improve this concept is to replace the forwarding mechanism of the old access router by a bicasting mechanism, i.e., the OAR duplicates packets destined for the Mobile Node and send them to the old and the new point of attachment for the handover time period. This scheme allows a more flexible reaction to the movement direction of the user and could interoperate with a layer-2 based movement detection algorithm. A mobile device may decide and prepare to handover, but due to a change in the direction of the user movement, a handover could become unnecessary. In this case, the bicasting mechanism ensures the continuous connection to the old access router and the MN is able to cancel the handover (e.g., by sending a BU to the OAR containing the old care-of address) without any performance degradation. The following Figure 16 illustrates the change in the signalling framework.

MN oldAR newAR| | ||------RtSolPr------->| ||<-----PrRtAdv--------|--------HI--------->||------F-BU---------->|<------HACK---------|

Disconnect <--F-BACK--|--F-BACK--> || | || bicast ||<==================packets===============>|

Connect | ||----------------F-NA-------------> || | Deliver|<=====================================Packets

Figure 16: Signalling framework, including the bicasting mechanism.

Note: the bicasting mechanism does not waste bandwidth on the wireless link, because packets on the air interface are only transmitted when a physical connection is established. Conclusions The Fast Handover in MIPv6 approach is able to enhance the Mobile IP protocol by adding fast handover functionality, but there is no improvement to standard Mobile IPv6 with respect to the handover signalling. Each handover requires location updates to the Home Agent and Correspondent Nodes and beyond it, even more signalling to the access router is necessary. Introducing a hierarchy could prevent the overhead of location updates for intra-domain handover by localising the handover management. At the same time, a hierarchical approach could also enhance handover performance – always keeping the disadvantage of the increased complexity to the network topology in mind. A solution whether a hierarchy is needed or not and if a combination of hierarchical and this non-hierarchical approaches are useful and practicable, requires further analysis, which is the next step within the Moby Dick framework. A comparison of hierarchical and non-hierarchical approaches hopefully will lead to a specification of handover scenarios with certain parameters, as input for the following step, the simulations. The simulation results are intended to specify the best suitable handover mechanism for the Moby Dick project.



How to introduce FMIP in Moby Dick We focus in this discussion on the phase called ‘Intra-Domain Handover’ since it is the one in which FMIP typically applies. It could also be interested to see what happens, when OAR and NAR belong to different domains but this scenario is not addressed here.

Figure 17: Intra Domain Hand-Over Signalling in Moby Dick

It is clear that this phase is very similar to FMIP. Instead of comparing both methods that follow the same philosophy, I would like to point out the improvements and problems introduced by both solutions. Simplification of the problematic First, there is a lot of assumption that could be made in order to simplify the problematic of FMIP. Making them will also help us in defining more accurately the Moby Dick philosophy. This section gives a short list that could be considered. Once again these are personal comments. A simplified case could be considered in Moby Dick where: 1. HO is Mobile Determined 2. Expecting the case of route or hardware failure, the point of attachment is always known (meaning

that we are managing a test-bed architecture, not the whole Internet, and that we know exactly towards which AR the MN is moving when performing a HO)

MTOAR

MT-CN Data transfer1. MT receives Beacon NAR (radio power increases)

2. Hand-over request to OAR, CAa2

3. Forwarding of Hand-over request: Authentication, QoS profile, CAa2

4. Hand-over ok5. Hand-over forwarding ok

6. Hand-over message: “Bye” toOAR

7. New binding to CN and HA (in Data packet).8. Binding confirmation

HANARCN

L2L3



3. We should clarify if we will use AR with only one or with multiple wireless interfaces. If the first case is assumed, what we think is realistic, it will mean fewer option to implement (i.e. code 1 does not need to be supported in Proxy Router Advertisement)

Similar to the particular case mentioned in (3.) there could be other possible option that could ease implementation or alternatively improve the code when paying more attention to the Moby Dick assumptions (e.g. type of L2 considered). Using L2 trigger and HO algorithm The points left in shadow in FMIP could be usefully considered and defined in Moby Dick to help us in the achievement of fast HO. Those points are L2 triggering and HO algorithmic. As previously said, FMIP is L2 independent. I think there is a good chance here to take advantage of the Moby Dick restricted problematic since we consider only a restricted number of L2 technologies. On the same level of reflection, using a reactive HO algorithm could help in minimising L3 or better coupling IP layer signalling and L2 establishment delay. Concatenation of events: MIP-HMIP-FMIP As previously mentioned, it is still not clear weather this integration has a sense or not. The motivation for answering yes is that HMIP (or other local mobility management (LMM) scheme i.e. RegRegv6) defines more a framework or an architectural hierarchy in the network rather than a sequence of optional messages as it is the case in FMIP. It is namely one of the latest informally agreed requirement identified for LMM: „Regional registration shall support fast handover“. Or: „Regional registration shall be compatible with fast handover“. There is also a tacit agreement about the following sequence of events: 1. Mobility 2. Localisation of mobility and subsequent speedups (LMM) 3. Speedup optimisations by applying fast handover techniques over that LMM... Alternatively, it could be problematic to integrate HMIP and FMIP and there is no evidence that this could produce any remarkable gain.

7.4 Care-of Address Acquirement This chapter proposes some mechanisms for a mobile terminal to acquire a valid care-of address when either attaching initially to one of the specified access technologies or initiating a handover between two access routers. The mechanisms proposed are to be further evolved.

7.4.1 Assumptions

7.4.1.1 System information broadcast It is assumed that all access technologies have system information broadcast mechanism. Information is sent using the IPv6 Router Advertisement (RA) format. Additional information like Paging Area identifiers can be added to the Router Advertisement, while other information, like the Link-Layer address option, might be taken away dependent on the access technology.

7.4.1.2 System information scanning It is assumed, that a MT can scan system information in the following two cases: (1) MT is connected to interface 1 (IF1) and is able to receive Router Advertisements (or equivalent

messages) on IF2. This advertisement is to be passed to the IPv6 protocol stack in order to trigger the handover. It seems to be reasonable not to pass every advertisement to the MIPv6 stack, but to apply some filter rules (e.g. through an appropriate handover algorithm) which evaluate the ‘best’ (in terms



of signal quality) advertisement and therefore perform a first, simple movement detection algorithm below the IP-layer.

(2) MT is connected to IF2 and is able to receive Router Advertisement (or equivalent messages) on IF2 originated by nearby ARs.

In both cases it is assumed (proposed), that a received advertisement can be correlated with the respective interface again. These RA should then be processed at the IPv6 protocol stack, although the handover decision is done below the IP layer.

7.4.2 Overview and comparison of mechanisms This section describes the alternative mechanisms of care-of address acquirement, in order to evaluate an appropriate approach within the framework of Moby Dick. There are mainly two different proposals, as there are stateless auto-configuration versus stateful configuration, which are described in the following sections and will be evaluated in chapter 7.4.2.3. Common IETF wisdom classifies address auto-configuration in IPv6 in two main categories: stateless and stateful auto-configuration, the main difference between the two being that stateful auto-configuration uses a central server that manages addresses while stateless doesn’t use any central entity and the auto-configuration is of a more distributed nature. An often overlooked element of stateless auto-configuration is the “creation of link-local addresses”. This should be considered in itself as a third category of address auto-configuration. While a link-local address can only be used for communication on the link with direct neighbours, it has the advantage that its configuration mechanism is potentially very simple, not requiring any message exchange (DAD can be eliminated for link-local addresses based on certain types of interface ID’s). The above three categories of address auto-configuration are currently standardised by IETF (the corresponding RFCs have Standards Track status). Additionally, there are other address auto-configuration mechanisms that are implicitly proposed by certain I-D’s but are not necessarily named as such. For example, in Hierarchical Mobile IPv6 a MN is required to form an RCoA (regional CoA) out of a prefix obtained from a remote off-link entity: the Mobility Anchor Point. This mechanism is clearly different from the stateless auto-configuration, where the prefix used to form an address is obtained from Router Advertisements broadcast by on-link routers. Similarly, in Fast Handovers for Mobile IPv6 a Mobile Node can configure its address from a prefix obtained from an immediate off-link (next-hop) router that sends Proxy Router Advertisements. This again is different from stateless auto-configuration. In addition to these “exotic” IETF address auto-configuration mechanisms there are others being developed by other standards development organisations. For example 3GPP defines a Dynamic IPv6 Address Allocation in the context of GPRS (see http://www.3gpp.org/ftp/Specs/latest/Rel-4/23-series/23060_420.doc). While this method claims to be stateless auto-configuration it has one notable peculiarity: The interface unique ID is provided to the mobile by GGSN, while in stateless auto-configuration it’s assumed that this unique ID is implicitly known by the node. This adds a trait of stateful auto-configuration since only in stateful auto-configuration a central entity (GGSN in this case) manages addresses and ensures their uniqueness.

7.4.2.1 Stateful care-of address configuration There are two possibilities related to stateful care-of address acquirement, which are

(i) Definition of a new mechanism, e.g., by the deployment of the IPv6 Destination Option header or explicit ICMPv6 signalling

(ii) Deployment of DHCPv6 The first proposal would allow maximum flexibility and adaptation to the requirements of the current scenario, but bring along more workload, since the mechanism is new and has to be defined and implemented. The following chapters will describe the recent mechanisms, in order to allow a comparison and evaluation in chapter 7.4.2.3. The main objective of the stateful CoA address configuration approach is to avoid Duplicate Address Detection (DAD) for global care-of address acquirement in case of a handover since this is time consuming and ruins the benefit of the fast handover. Assumption is for all stateful address acquirement



proposals the ‘make before break’ philosophy: The CoA should be acquired before the handover via the old, currently used connection. An additional benefit of the stateful approach could be the fact that the previous communication with the new domain could include other necessary information exchange, such as authentication, authorisation or context transfer. 7.4.2.1.1 Definition of a new mechanism

7.4.2.1.1.1 General message format issue In order to allow an explicit CoA request signalling message to be applied separately or to have the request together with Fast Handoff or AAA related signalling, the idea is to specify the CoA related signalling as IPv6 Destination Option header format. The message can then be associated with any other protocol we desire, for performance reasons. This further allows processing in the kernel space (integrated with IPv6 protocol stack) and to keep the entire process scalable. It allows the signalling to be piggy-packed and to be carried either in a link-local or a globally addressed packet (to the NAR through the wired system). This CoA request message may be requested to convey MAC address information (or some other identifier), which might support the derivation of CoA. In this approach, some changes at the MT-side are required for issuing such a message directed to the OAR, which will then process it. Addition: As a further approach, ICMPv6 message definition could be used of in order to convey appropriate CoA request signalling between the OAR and the NAR (as discussed in IETF Mobile-IP WG for Fast-HO). However, because traditional CoA assignment methods use link-layer multicast for some of its services, it is required in Moby Dick that on W-CDMA link type alternative protocols or mechanisms implement those services. 7.4.2.1.1.2 CoA request approach This method describes a mechanism where the MT explicitly requests a valid CoA from he NAR. The actual determination and validation is kept in a separate section below. This should be independent of the request mechanism. Initial attach The MT listens for Router Advertisements on the all nodes on this link multicast address (shared medium access) and on the broadcast channel (W-CDMA). The MT gets a link-local as well as a global address prefix of the respective router on each interface (or one of them. Dependent on the decision algorithm (link-quality, costs, etc), one interface is selected. The CoA request message is sent to the respective AR, addressing its link-local address. This valid CoA is then sent back to the MT in the appropriate CoA reply. The AR can make an entry to its (Radio) Resource Table if a table of attached MT and their corresponding CoA is maintained. This is equivalent to DHCP usage, and in fact the AR could rely on such structures for managing the addresses. The acceptance of this CoA might be additionally acknowledged from the MT (or, preferably, the rejection of this address can be made by another CoA request). Handover While connected to an interface 1 (IF1), Router Advertisements might be received on alternate interfaces. This might be an interface of a different technology or of the same technology. The decision algorithm (handoff decision entity and interface manager closely coupled) notifies a change of AN: This is given to the IPv6 stack as a notification. The IP stack is notified in order to proceed with a CoA request, for a given address, but it never sees what is below this (e.g. it does not know how many ARs it has available). In case of inter-technology HO, the CoA request can be either sent directly through the new interface working in parallel, or backward, through the already existing connection to the OAR In the latter case, the CoA request is sent to the NAR through the OAR. In this case we have the following possibilities: (1) Router Advertisement of the NAR has its full global IPv6 address referenced. This allows the MT to

address the NAR through the existing connection from system side. (2) Router Advertisement of the NAR has an AR identifier encapsulated, where the OAR can derive the

global IPv6 address of the NAR from. Then this requires another layer inside the transport network,



with the distribution of this information through all the routers: Note however that limitations in the 802.11 networks may imply this option to be chosen.

Note that some optimisation can be performed at the technology layers, and we should rely on similar mechanisms at the IP layer, regardless of the supporting technology. Furthermore, this message from the MT to the network can go through two different paths: (1) The CoA request might be sent separately, passing through the OAR: The message addresses the

global address of the NAR in the IPv6 basic header. In this case a DHCP-like configuration could be used from the point of view of the MT. The OAR needs to add any other information required by the NAR (eventually Context Transfer), using e.g. the Options field.

(2) The CoA request is conveyed in a message to be sent to the OAR in order to initiate a Handoff. As an example: IPv6 destination option for CoA request included, signalling packet addressed to the OAR (link-local). In this case either the Fast-HO message (or an alternative signalling message respectively) has to refer to the NAR global address, or the CoA request message carries an IPv6 Destination Sub-Option referring to the NAR global address (preferred, because this approach keeps CoA request entirely separate to other signalling).

The NAR determines the CoA and send it back in an appropriate reply message. The reply packet addresses the global, currently valid CoA of the MT, going through the OAR. 7.4.2.1.2 DHCPv6 DHCPv6 requires a central server for the maintenance of available (i.e., valid and unused) care-of addresses. Considering the handover scenario, it seems quite natural that the new Access Router performs this task. The NAR can be contacted via the OAR, which requires resolving the beacon/address of the Router Advertisement for this communication (note: logical distribution! Does not require physically that each AR performs DHCP server functionality!). The MT would send a DHCP request to the NAR through the OAR. The OAR would need to see into the packet and treats this message as a special message concerning handover (which could trigger other actions inside the OAR).

7.4.2.2 Stateless care-of address configuration Stateless address auto-configuration is defined for IPv6 in RFC 2462. That document presents a method that comprises three steps. In the first step, a node needs to create a link-local address from an interface unique identifier and a constant prefix (0xfe80). This address can be used only for communicating with direct neighbours. In a second step, a node requires IP parameters assigned to the current link by way of broadcasting a Router Solicitation. Once a Router Advertisement is received, a node can compute an IPv6 address with scope larger than link-local, by appending the IP prefix (from the RA) to its host identifier deduced from its unique interface identifier. Before assigning this address to an interface, and as a third step of stateless address auto-configuration, a node initiates the Duplicate Address Detection procedure, to ensure it’s the only node on the link trying to use that address. During a DAD, a node periodically and for a finite time broadcasts requests for same address and listens to other nodes potentially claiming same address (Neighbour Solicitation/Neighbour Advertisement). The RFC specifies that, depending on the type of the unique identifier used for generation of the host identifier, it is possible to eliminate the DAD procedure (the third step). For example, in the case of Ethernet and 802.11b, since all vendors guarantee the uniqueness of the MAC address, it’s reasonable to eliminate the DAD. In the case of W-CDMA, the decision of which unique identifier attached to the W-CDMA interface is used for generation of an address, should lead to an answer to whether the DAD should be performed or not. However, in the case of W-CDMA, it seems reasonable to assume that a unique identifier can be assigned to a W-CDMA interface (this is even truer since the W-CDMA stack used in Moby Dick may differ from 3GPP standard in some way). Such identifier could be in some way similar to the “UE-Identifier” used in GSM to uniquely identify equipment (i.e. a cellular phone). Such W-CDMA unique identifier could be hard-coded (as it is for Ethernet or 802.11b) or even obtained dynamically from the W-CDMA Radio-Gateway at radio connection setup time (Personal note CJ: “I think something similar is done in HiperLAN/2…to be checked”). Of course, if not assigned by IEEE, such W-CDMA identifier could conflict with Ethernet or 802.11b ones and, as a consequence, DAD should be performed. However, in the particular case of the Moby Dick architecture, where different technologies are deployed in separated IPv6 subnets (i.e. different prefixes), DAD could be to some



extend avoided since uniqueness of an interface identifier within the scope of a single technology will ensure uniqueness of the derived IPv6 address (with the prefix).

7.4.2.3 Proposal comparison and evaluation When compared to stateful address auto-configuration mechanisms (of which DHCPv6 is but an example, see the background section), stateless mechanisms generally exhibit the following characteristics:

• Distributed nature: The entities participating in the message exchanges are the mobile node, any on-link routers (could be several) as well as any neighbours that might happen to claim same address.

• Stateless auto-configuration doesn’t require the presence of any additional server entity other than the IPv6 routers.

• Stateless auto-configuration uses ICMPv6 messages while DHCPv6 uses UDPv6 messages. Since ICMP is traditionally treated in the kernel of an operating system while DHCPv6 runs as userspace servers (on top of UDPv6 sockets), it’s safe to assume that stateless auto-configuration happens faster than stateful.

7.4.2.3.1 Advantages and Disadvantages of stateful auto-configuration

7.4.2.3.1.1 New mechanism Advantages:

� Very flexible. Could be adapted to the requirements of Moby Dick. � Possibility to give more network or link related information back to the requesting MN

Disadvantages: � Mechanism not yet implemented in current IP architecture.

7.4.2.3.1.2 DHCPv6 Advantages:

� Rely on a existing mechanism (IF AVAILABLE) � Possibility to give more network or link related information back to the requesting MN � Available CRM implementation is based on Linux (binary form).

7.4.2.3.1.3 Both Advantages:

� Avoid DAD - or at least let the AR perform DAD on behalf of the MN in advance of the handover. However, current IETF specs state that DAD SHOULD be performed both for stateless and for stateful.

� Communication between OAR and NAR could include other tasks (e.g., context transfer, authentication, etc.)

� Deployment of ‘make-before-break’ philosophy possible, which provides fast handovers � Allows network control the IPv6 CoA

7.4.2.3.2 Advantages and Disadvantages of stateless auto-configuration Advantages:

� Easier to handle; no additional implementation for IEEE 802.11, but for W-CDMA � Distributed nature of the stateless protocol. No new entity (other than an access router)

needs to be deployed. � Stateless auto-configuration is ICMPv6 messages, faster than UDPv6 (DHCPv6 uses

UDPv6). Disadvantages:

� DAD is time consuming (as long it is not performed in advance) and therefore the disconnection time during a handover increases to a value which is not tolerable for real time connections.



� Makes DoS attacks easier for malicious nodes, since a Mobile Node could allocate more than one CoA for the respective link, which could cause failure in other nodes CoA acquisition process (IP address conflict).

7.4.3 Conclusion An evaluation of different mechanisms for the CoA acquirement procedure as well as their advantages and disadvantages have been discussed in the section above. A final decision on one of the mechanisms needs further evaluation, since much more input parameters are to be taken into account for this decision like different business models, time-constraints and technology related parameters (e.g. unique MAC identifiers for W-CDMA equipment).



7.5 Paging support

7.5.1 General overview of the mechanism This section summarises the motivation of paging and basic design goals on how paging is intended to be integrated with the Moby Dick architecture. This assumes first static paging area construction. System enhancements are described and proposed, but not planned for implementation at the beginning. In order to allow mobile terminals to enter an idle state, where sending of frequent location update messages to the network can be avoided, a mechanism has to be applied to notify the respective mobile terminal of incoming traffic and to request its exact location. In idle mode, a mobile terminal’s location is known to the network with the granularity of a paging area, which is a cluster of two or more wireless access areas (cells). Since the expression cell refers more to the terminology of 3G cellular networks, we refer to this area as a location, which is the smallest, indivisible area in which a mobile terminal can be located. Within the framework of Moby Dick, each location represents an IPv6 subnet and is interfaced to the wired network through an Access Router. With respect to Mobile IPv6 as mobility management protocol, it is intended to keep paging and the specific state maintenance transparent to Correspondent Nodes and to the mobile terminal’s Home Agent. The only nodes, which should be aware of the mobile terminal’s current state, active or idle, are a dedicated Paging Agent (PA) and the respective mobile terminal. The Paging Agent entity integrates modularly with the Mobile IPv6 environment and is responsible of localising a registered idle Mobile Node in case of incoming data destined to the respective end-device. A mobile terminal, which decides to switch to idle mode in order to avoid superfluous location update signalling to the networks and to support reduction of battery power drainage, notifies the Paging Agent of its intention to enter the idle state. The PA maintains the state of the mobile terminal and can derive the mobile terminal’s Paging Area, in which it is currently roaming in, from this information. This is done by sending a paging area identifier with the idle-registration message. Alternatively, the MN sends it’s current co-located care-of address with the registration message, where the PA can derive the paging area information from. Furthermore, the mobile terminal registers the PA’s address with its Home Agent making use of a Mobile IPv6 Binding Update message carrying the ‘Alternate Care-of Address Sub-Option’. This additional option allows a mobile terminal to register an IP address, which is different to the mobile terminal’s care-of address, as a binding with its Home Agent. This registration causes packets, which are destined to the respective mobile terminal and intercepted by the Home Agent, to be tunnelled to the Paging Agent instead of to the mobile terminal. Now the mobile terminal can switch to idle state and is allowed to roam within a registered paging area without the need to send location update information to the network when entering a new location assigned to the same paging area. The mobile terminal is required to scan paging area information while roaming in idle state. This can be realised by processing periodically broadcast system information from Access Routers or to process L2 beacons conveying paging area information implicitly. As soon as the mobile terminal becomes aware of that it has entered a new paging area, it notifies the Paging Agent of this movement. A state transition from idle to active can be triggered actively, which is caused by a mobile terminal initiated communication, or passively by receiving a notification of the network in case of incoming traffic destined to idle the mobile terminal (paging request). The latter case describes paging the mobile terminal initiated from the Paging Agent. This notification refers to a Paging Request message, sent from the Paging Agent to all locations assigned to the registered paging area. Since the Mobile IPv6 Home Agent’s binding for the idle mobile terminal refers to the Paging Agent’s IPv6 address, initial incoming packets are tunnelled from the Home Agent to the respective Paging Agent. The PA has to buffer tunnelled data packets and initiates paging the mobile terminal. The Paging protocol intends to be transparent to L2 specifics of last hop access technologies. It is up to the Access Router to make use of L2 specifics and to map paging protocol details to L2, if this is required and supportive. Advanced L2 support might be necessary in future systems when hardware supported power saving modes are deployed in idle mode.



After the reception of a Paging Request message, the mobile terminal, which is addressed and has entered a dedicated idle mode before, has to reply by first registering its current location with its Home Agent and furthermore with its Paging Agent. The PA can now register the respective mobile terminal as active and knows it’s exact location, which allows to forward buffered packets. The Home Agent has now registered the mobile terminals current co-located care-of address and tunnels further intercepted packets directly to the new location. As an option, a MIPv6 Binding Update message can be sent to the packet originator (CN), in order to allow route optimisation.

CN: Correspondent Node, MT: Mobile Terminal, HA: IPv6 Home Agent, PA: Paging Agent, AR1: Access Router 1, AR2: Access Router 2

Figure 18: Paging an Idle Mobile Terminal

A mobile terminal, which intends to enter the idle mode, has to be aware of Correspondent Nodes still having a valid binding entry of the terminal’s care-of address. This is in order to allow route optimised direct communication between a CN and a MT. A Mobile IPv6 terminal maintains a table of Correspondent Nodes where it has sent a Binding Update message to. This table maintains also timers referring to the respective binding cache entries validity. Depending on the mobile terminal’s activity (currently in a session or not), the terminal can switch to idle mode, after the longest timer value for such a binding cache entry has expired and not been updated in between. This is in order to avoid notifying all Correspondent Nodes, which still have a valid binding entry for the respective mobile terminal entering the idle mode.

7.5.2 Design goals The following refers to generic concept ideas for implementing paging support into the Moby Dick mobility management architecture: When a mobile terminal registers as idle with the network, its primary intention is to avoid sending frequent and superfluous location updates to the network, as it is required for mobile terminals roaming in an IP based mobile communication network. This supports saving power on mobile terminal’s side as well as relieves scarce radio bandwidth from superfluous signalling. Of course, having a benefit with idle mode support and paging depends on multiple parameters. These are probabilistic parameters of incoming call frequency and well as a user’s movement pattern, its roaming velocity and the cell size of individual IP subnets. The implication of individual parameters to the benefit of paging is not evaluated here. The

MT

AR1

1. Idle mode registration with the PA

2. Binding update (PA registration)

3. PA buffers data packets andinitiates paging the MobileTerminal

4. Connection establishingBinding Update (CoA registration)Terminal active notification to PABinding update for route optimisation

HAAR2

PA CN



overall goal is to specify a flexible architecture and mechanism for paging support in a Mobile IPv6 managed platform. Furthermore, support of dormant mode and wake-up mechanisms for hardware, implementing one or several power save modes is not considered to be part of first evaluations and implementation. The concept described here should be flexible enough to allow future enhancements on these specifics. The transition from active state to idle state is to be determined on mobile terminal’s side and depends on several parameters. When a mobile terminal has entered idle state, the network knows the terminal’s location with a coarse granularity. The location is known with the granularity of an IP paging area, which is a cluster of two or more IP subnets. Since Moby Dick specifies that each individual IP subnet is supported by one Access Router integrating one wired or wireless interface for access provision, a paging area is comprised by a set of IP subnets. Since this signalling is primarily related to IP mobility management location updates, the mobile terminal can save power by avoiding superfluous signalling when entering the idle mode. Therefore, the support of L2 paging areas is not considered first. On mobile terminals side, saving of battery power might be improved by hardware supported mechanisms. When a mobile terminal is to be notified to enter active mode due to an incoming packet destined to a mobile terminal, which has registered as idle before, paging is initiated from network side from a separate Paging Agent. This agent uses solely IP as signalling layer. The mapping of protocol signalling to layer-2 specific signalling takes place at individual Access Routers assigned to a Paging Area. It is the only node where the specifics of a L2 medium are taken into account. This mapping, if needed at all, is provided by a medium-specific mapping function. Since the Access Router can make use of L2-specifics in order to support paging a mobile terminal, respective mechanisms can be applied on the access link for different dormant modes. As the performance of a paging implementation depends on the specific strategy it deploys, further emphasis is placed on how to make paging more efficient. A good paging strategy should therefore comply with the following objectives: • minimise paging signalling load, i.e. the total number of locations that are polled • perform successfully under given delay constraints • minimise paging delay, i.e. the number of polling cycles • reduce activity of an idle Mobile Node related to updating location information As mentioned in the generic design of the paging concept, modifications or extensions of Access Routers are required. No changes are however intended to Correspondent Nodes and Home Agent, i. e. only the Mobile Node and the paging service are aware of the idle Mobile Node’s state. Regarding binding lifetimes in Mobile IPv6, the Lifetime field of the Binding Update is 32 bit long. If the Home Agent puts no limitation on the maximum binding lifetime, a long-time idle state is enabled at the Paging Agent and there is no need for a refresh of the Home Agent binding for a long time. Otherwise, more frequent refreshes of the Home Agent binding will become necessary during the idle state of the Mobile Node. The role of paging strategies Most paging proposals only support one single paging strategy, classified below as Blanket Polling. A cost analysis of this strategy shows that it is only sub-optimal [54]. We argue that it is important to support different paging strategies. Some are listed and briefly described below. Blanket Polling This strategy uses predefined paging areas, made up by the radio coverage area of one or more Access Routers. The network knows only the current Paging Area of the MN, possibly using paging area Identifiers (PA_ID). When paging idle Mobile Nodes, all cells of a paging area are polled simultaneously. Shortest-Distance-First [55] This requires cartographic information at the Paging Agent. Paging starts in the cell that was last registered by the Mobile Node, then all neighbouring cells of this cell are polled, after that the neighbouring cells of the neighbouring cells are polled and so on. Sequential (Group) Paging A list of user location probabilities is used, sorted in decreasing order of probability. The list elements, pointing to paging areas or single Access Routers, are polled sequentially, hence the name. The analysis in [53] has proven that sequential paging minimises the signalling cost over all choices of a set of



locations. Sequential group paging is an optimisation that reduces the paging delay, still resulting in signalling cost reductions of at least 50%, even under delay constraints. Adaptive Individual Paging The Mobile Node dynamically generates a working set of Access Routers it considers as the best possible current paging area. The Mobile Node communicates the members of this individual paging area to its Paging Agent. This dynamic paging area will be used to page an idle Mobile Node. As an option, the generation of the individual paging area can be derived on a server or another node assigned to the wired network infrastructure on behalf of the Mobile Node. Other Paging Strategies An idea not fully specified is paging based on global co-ordinates determined by GPS (Global Positioning System), an idea is mentioned in [RFC 2009]. Several other different paging strategies are discussed in [55]. Optimization Group Paging (or 'Ensemble Polling [54]') can be used as an optimisation, whereby several idle Mobile Nodes are paged simultaneously. This allows a better multi-user performance and load control. Also, paging delay can be reduced. Group paging has successfully been employed by GSM.

7.5.3 Design specifics

7.5.3.1 Classification of access technologies In order to get an overview on how the different access technologies might cooperate with paging and support the paging process, we can classify the technologies to be used within the framework of the Moby Dick project as follows: Medium, which specifies neither the support of an idle mode nor paging - Ethernet Medium, which supports an idle mode but specifies no mechanism for paging - IEEE802.11 Medium, which specifies mechanisms for idle mode and paging - UMTS/W-CDMA The wireless LAN technology IEEE802.11 supports a ‘dormant’ mode, where L2 specifies control frames for waking up the mobile device are specified. Within the framework of the Moby Dick project, it is not the overall goal to specify paging with respect to optimising power saving mode on a technology basis. It is referred to these modes in order to take into consideration an additional support for idle mode in a paging architecture coming from individual technologies. It is not explicitly relied on these additional modes, rather on the specification of a flexible IP paging architecture and protocol, which allows the deployment of further technology specific support. For W-CDMA, we make use of a common Paging Channel (PCH), as it is specified within the framework of 3GPP for UMTS. Support of a power saving mode on W-CDMA interface basis is not considered in this specification phase. It might be considered for future enhancements of efficiency, but is considered as an independent evaluation and development. This kind of support might imply additional signalling on L2 basis, which should be allowed by the concept specified within the framework of the Moby Dick project.

7.5.3.2 Implication on Access Routers The Paging Agent uses IP for paging purposes. To page a Mobile Node, a mapping of layer-3 signalling to layer-2 might be necessary to take L2-specific details into account. This is provided by a mapping function in the Access Router. The simplest possible mapping function is that of a Neighbour Cache entry, mapping IP addresses to link-layer addresses. If paging is already supported on layer-2, this fact SHOULD be taken into account by the specific mapping function. The paged Mobile Node receives either a layer-2 paging signal or an IP paging request packet, both must cause re-entering active state followed by the establishment of a routable L3 link. The Access Router is assumed to provide at least two interfaces. One is connected to the wired part of the access network infrastructure, the other interface provides wired or wireless access to mobile terminals. As described above, the concept proposes that a Paging Agent addresses all Access Routers assigned to the paging area a mobile terminal has registered with. This has multiple reasons: Paging on the local link (wired or wireless), which makes use of link-local multicast addresses, cannot be addressed from outside the link location when the concept does not rely on mechanisms like setting up an IP multicast tree for



respective paging areas. Furthermore, the paging protocol is intended to be kept independent of the last hop wired or wireless link. In order to allow making use of access technology specifics, this mapping is allowed to be done at individual Access Routers. Since system information broadcast into the direction of mobile terminals includes identifiers of the access link directed interface (e.g. IP address), this information can be used to support paging area construction from mobile terminal’s point of view (individual paging area construction). That’s why the access link directed interface is addressed by the Paging Agent. The addressing of individual nodes as well as signalling flow for paging is illustrated in the following Figure 19.

Figure 19: Interface addressing in a paging process

7.5.3.3 Specification of the Paging Agent As paging is initiated from an entity, which is separated from mobility management entities like Mobile IPv6 Home Agents or local mobility agents, this section specifies functionality and characteristics of the Paging Agent node to be integrated with the Moby Dick architecture. Based on the design goals, the Paging Agent has to perform the following general core tasks: (1) The Paging Agent has to maintain the current state of the Mobile Node, which can be idle of active.

In active state, the Paging Agent is not involved in the mobility management and can see the Mobile Node’s location as registered with the network. It is kept open, whether or not the Paging Agent has to distinguish a further state, which could be inactive.

(2) For Mobile Nodes registered as idle, the Paging Agent has to maintain a table with Mobile Node and

architecture related information. The following list specifies some of these parameters:

� Home address of the registered Mobile Node � Further terminal identifiers, like an IMSI or a NAI, if supported by the network � Current state of the Mobile Node [active / idle (/inactive)] � Registration lifetime value � Paging area identifier (for static paging area support) � Dynamic list of Access Router identifiers (for individual adaptive paging areas) � Paging strategy specific information

(3) The Paging Agent has to provide enough buffer space for incoming user-data packets initiating paging Mobile Nodes, which have been registered as idle before.

(4) Paging the idle Mobile Node on L3 basis. (5) Updating of individual information in the database when a paged Mobile Node has re-entered the

active state. When a routable L3 link is re-established, the Paging Agent must forward the respective buffered packets to the Mobile Nodes current location

Mobile Terminal

Access Router

PagingAgent

Home Agent

User data packet

Tunnel ing of user data packet

to the PA

IP paging, addressing the access interface of

Access Routers

Paging on the local

link



For support of different paging strategies, additional functionality might be assigned to the Paging Agent or to a separated Paging Server. This could be for storage and processing of Mobile Node’s movement patter as well as on statistical information derived from movement pattern. Further support for security related issues (paging relevant key management) could be specified. All functionality might be implemented in a centralised or in a distributed manner, where the last architecture characteristic refers to a de-composed kind of architecture. For a first implementation within the framework of the Moby Dick project, a composite architecture is considered and will be implemented. Paging area identification and maintenance of paging areas within Paging Agents For static paging area construction, paging area identifiers (PA_ID) can be made use of in order to describe a set of Access Routers, building the paging area. This implies the design goal not to setup specific L2 paging areas, but to build L3 paging areas out of one or multiple IP subnets, where each subnet is connected through one individual interface integrated with an Access Router. This requires the following mapping in the table: Mobile terminal identifier ( home address || IMSI ) → PA_ID PA_ID → {AR_1, AR_2, AR_3, …} For individual paging area assignment, adaptive lists have to be maintained on a Mobile Node individual basis. This requires the construction of individual lists of Access Routers. In this case, a paging area cannot be identified by a PA_ID, but is to be identified by the appropriate Access Router identifier on Mobile Node side. This identifier is either an individual identifier or the global IPv6 address of the access network interface belonging to the respective Access Router. Dependent on the paging strategy, a list of probability values, a Mobile Node might currently be located in the access area supported by the respective Access Router, can be assigned to the list of identifiers. This probabilistic distribution is for example required for the sequential paging strategy. Paging Algorithm of the Paging Agent The paging procedure at the Paging Agent is entered when packets for a Mobile Node arrive, which are allowed to wake up the respective Mobile Node. These can be in one of two formats: � Packets sent via the Home Agent will be tunnelled, the destination address of the inner packet is the

home address of the Mobile Node � Route optimised packets from Correspondent Nodes or packets sent by the Home Agent itself

contain a Routing Header, whose last destination is the home address of the Mobile Node The Paging Agent first checks the message format. If an error occurs or the packet does not pass the predefined filtering function of packets, which are allowed to wake up a mobile terminal, packets must be discarded; the Paging Agent should send an ICMP error message. Within the IETF it is considered to specify paging relevant ICMP error messages. Currently, it is kept open which kind of error message will be sent. After message validation, the home address (or an appropriate user terminal identifier) contained in the packet is retrieved and used to look up the entry for the Mobile Node in internal data tables. If no valid entry exists, the Paging Agent must discard the packet and send an ICMP Destination Unreachable message [RFC 2463, sec. 3.1] to the originator. In the successful case, a message queue is allocated to buffer incoming packets while the Mobile Node is in the process of being paged. The maximum buffer size for incoming data is configured by the parameter MAX_BUFFER, an error function has to be provided for the overflow case. The Paging Agent generates the Paging Request message and, depending on the paging strategy, distributes the request to the Access Routers. A timer is then set to the configurable value PAGING_TIMEOUT. If a Paging Reply as specified below arrives before the timeout, this timer is stopped and the Paging Agent validates the Paging Reply message. If the validation fails, the



Paging Agent must send back an ICMP error message and restart the timer. If the validation succeeds, the Mobile Node’s state is updated in the internal data tables and the buffered packets are forwarded to the Mobile Node. The Paging Agent uses IPv6-in-IPv6 encapsulation [RFC 2473] to forward buffered packets, as the Mobile Node needs the original packet headers to determine the original sender of the message. After the timeout for the Paging Reply occurred, the Paging Request is retransmitted and the timer restarted. Because retransmissions of Paging Requests, each time distributed to a number of Access Routers, can accumulate high bandwidth consumption, a binary exponential backoff mechanism should be applied to the timer value. The Paging Agent discards buffered data after MAX_PRQ_RETRY retransmissions, issues an ICMP Destination Unreachable message to the originator and inhibits new paging processes. New paging processes are inhibited by locking the data entries of the Mobile Node, for a configurable time of LOCK_TIME seconds. During this time, a new paging process for the Mobile Node shall not be started.

7.5.3.4 Addressing idle Mobile Nodes The following refers to addressing idle Mobile Nodes. Addressing Mobile Nodes in a technology specific way on lower layers is not covered in this section. In case of making use of paging a group of idle Mobile Nodes, a link-local multicast address can be used. The groups’ individual multicast identifier is to be negotiated before entering the idle mode. The format of the link local address is as follows: The flags (`0') indicate `well-known' permanent use, the scope identifier (`2') is set to link-local [RFC 2373]. For paging individual idle Mobile Nodes, the Solicited Node Multicast address is used [RFC 2373]. The format is as follows. This requires the knowledge of the Mobile Node’s MAC address, at least the last three bytes should be notified to the Paging Agent. Notification of MAC address specifics should be part of the idle state registration with the Paging Agent.

7.5.3.5 Distribution of Paging Request messages Two modes can be identified for distributing Paging Request messages from Paging Agents. Tunnelling mode: The Paging Agent uses IPv6-in-IPv6 encapsulation, where the outer header addresses the Access Routers interface, while the inner header addresses the paging multicast address. Direct mode: The Paging Agent addresses the access link interface of individual Access Routers, where all Paging Request messages are interpreted and mapped to an appropriate L3/L2 paging message to be sent on the local access link.

FF02:000A:0000:0000: xxxx:xxxx:xxxx:xxxx

Prefix Group ID

FF02:0000:0000:0000:0000:0001:FFxx:xxxx

104 bits prefix 24 bit Identifier



7.5.3.6 Protocol specifics Generic TLV-encoded format will be used for idle state registration and de-registration as well as for paging relevant signalling messages. First approach might implement user-space daemons and makes use of UDP transport for paging relevant signalling. Later approaches might map TLV-encoded paging messages to IPv6 specifics, carrying signalling in IPv6 Destination Options, as it is done with Mobile IPv6 signalling.

8. Aspects on Software and Operating System

8.1 Mobile Terminal

8.1.1 Functions This is the initial (maximum) list of functions that are associated with the Mobile Terminal. Each function includes handling the associated message flows. • Handover • Paging • MIPv6 incl. Alternative CoA support • Awareness of Context Transfer • Network Access procedure including Authentication and Authorisation • DiffServ-Aware • Authentication and authorisation • Charging advice, and approve charging • IP-Sec support • W-CDMA support • Wireless LAN support • Ethernet support

8.1.2 Mobile Terminal Software Architecture The software architectures for the mobile terminal (MT) is illustrated in the following figure



RCM

RCFWCDMA

ASWCDMA

Ethernet Network Device Driver

802.11b Network Device Driver

Enhanced TCP/IP Protocol Stack

MTNM

NCP

Unmodified Applications

Enhanced Applications

Extended Socket Interface

Radio Service Interface

Standard Socket Interface

Standard Network Device Interface

WCDMA Network Device Driver

Networking Management Interface

Radio Management Interface

ASWCDMAInterface

Figure 20: Mobile Terminal Software Architecture

Essentially: • The Extended Socket Interface provides extension to the conventional Socket interface to support

QoS-aware applications and invocation of IP signalling. • The Networking Management Interface provides a means for setting of user networking preferences

and obtaining networking status. • The Radio Management Interface provides a means for obtaining radio information. • The enhanced TCP/IP stack will incorporate the necessary protocol extensions and enhancements to

support the mobility, QoS and AAA functions required by Moby Dick. Thus, in additional to the conventional Socket interface, it will support the Extended Socket Interface.

• The Networking Control Panel (NCP) provides a user interface to allow a user to manage his networking activities.

• The Mobile-Terminal Networking Manager (MTNM) does not implement any protocol; it complements the enhanced TCP/IP protocol stack to provide additional assistance in managing the mobile terminal’s handover process.

• A radio network device driver for the mobile terminal is made of 3 components: the Radio Channel Manager, a specific Radio Convergence Function and a specific Radio Modem Support.

• The Radio Service Interface is a connection-oriented abstraction of the radio interface for QoS-enabled wireless technologies.



• A Radio Modem Support (RMS) is concerned with the support of the peripheral interface to the radio modem. In Moby Dick, the W-CDMA stack refers to a modified Access Stratum of the 3GPP UTRAN access. It is labelled ASWCDMA.

• A Radio Convergence Function (RCF) supports the Radio Service Interface, and implements the necessary convergence mechanism to map between the Radio Service Interface and the native radio interface (via the RMS) of a specific wireless technology.

• The Radio Channel Manager (RCM) supports the conventional network device interface to the TCP/IP stack and the Radio Management Interface to facilitate handover operations. It manages the establishment and release of abstract radio channels, and separate IP traffic into them according to the different QoS requirements.

8.1.2.1 Functional elements

8.1.2.1.1 Enhanced TCP/IP stack The enhanced TCP/IP stack will be based on the LIVSIX release of IPv6 and MIPv6 implementation. It will • Incorporate the necessary extensions and enhancements to support the mobility, QoS and AAA

functions required by Moby Dick • Support the conventional Socket interface • Support the Extended Socket Interface

- Extended version of certain conventional primitives to carry QoS - New primitives for indication of change in QoS - New primitives to allow invocation from outside the protocol stack of certain IP signalling, such

as Router Solicitation, User Registration, etc 8.1.2.1.2 Networking Control Panel (NCP) The NCP manages the user’s networking activities. It will • Provide a user interface to

- Obtain user’s preferences in network selection - Allow the user to invoke a manual handover between access networks - Provide feedback and information about the networking environment, such as the status of

802.11b and WCDMA • Make use of the Networking Management Interface to

- Set user network selection preference - Set configuration of handover strategy: manual, automatic, both - Invoke a manual handover between access networks - Obtain feedback and information about the networking environment, such as the status of

802.11b and WCDMA 8.1.2.1.3 Mobile-Terminal Networking Manager (MTNM) The MTNM manages the mobile terminal’s handover process. It will • Support the Networking Management Interface to

- Get user preferences in network selection from the NCP - Obtain configuration of handover strategy: manual, automatic, both - Execute the manual handover initiated via the NCP

• Support automatic handover decision-making based on user preferences and intra-administrative-domain handover rules



• Dynamically reconfiguring and administering the enhanced TCP/IP stack and the network device drivers in the co-ordination of handover process, such as switching on and off network interfaces, initiating relevant mobility, QoS and AAA signalling, etc

• Use the Radio Management Interface to - Monitor the availability of the access networks and radio quality condition by obtaining

information from the RCM • Use the standard network device interface to

- Switch on and off network interfaces during handover • Use the Extended Socket Interface to

- Initiate relevant Mobility, QoS and AAA signalling during hand-over • Use the standard Socket Interface to

- Get intra-administrative-domain handover rules 8.1.2.1.4 Radio Modem Support for WCDMA (ASWCDMA) The ASWCDMA layers provide the ASWCDMA interface to upper layers (e.g. RCFWCDMA). 8.1.2.1.5 Radio Convergence Function for WCDMA (RCFWCDMA) The RCF maps between the RSI and the native WCDMA radio interface. If will • Support the Radio Service Interface to

- Map the abstract radio channels onto the real radio channels and vice versa - Provide information about the availability and quality of WCDMA access

• Access the WCDMA radio modem via the ASWCDMA 8.1.2.1.6 Radio Channel Manager (RCM) The RCM serves to provide an abstraction of the radio interface. It will • Support the standard network device interface • Support the Radio Management Interface to

- Provide information about the availability and quality of the radio • Use the Radio Service Interface to

- Initialise control channels - Establish and release abstract data channels - Separate IP traffic according to different QoS requirements and RSI’s QoS definition associated

with the abstract data channels

8.1.2.2 Interface definitions The following interfaces are defined: • Extended Socket Interface (ESI) • Networking Management Interface (NMI) • Radio Management Interface (RMI) • Radio Service Interface (RSI) • Access Stratum W-CDMA Interface (ASWCDMA): The W-CDMA Access Technology (Access

Stratum) layers provide an API to interface with upper layers such as the RCM (usually called Non Access Stratum). This interface is pictured in Appendix F.

These different interfaces will meet requirements of the functional elements previously described.



8.1.3 Mobile Terminal IPv6 stack and Operating System The Mobile Terminal will run the Real-Time Linux (RTLinux) Operating System. The choice for a real-time operating system is imposed by the need to support the W-CDMA radio. In fact, the W-CDMA protocol stack, which has stringent requirements in term of real-time operation (e.g. synchronisation etc..), is implemented in software and requires thus an appropriate environment to operate. RTLinux has been chosen because it provides both the real-time support needed and the well-known flexibility and openness of the Linux OS. The Mobile Terminal will run the LIVSIX IPv6 stack from Motorola targeting mobile devices. LIVSIX is an open source IPv6 enhanced protocol stack designed for the Linux Operating System. The version 1.0 (due end of 2001) will feature basic IPv6 and Mobile IPv6 capabilities for a Mobile Node. These capabilities are specified in current IETF specifications and no added value is planned for the first LIVSIX version. The stack is controlled by a user space configuration tool (livconfig) and supports interaction with user applications via a simple socket interface not featuring TCP (for release 1.0). This allows simple experimentation mostly with ICMPv6 packet exchanges or simple file transfers. Simple existing IPv6 applications will run unmodified on top of the LIVSIX stack. LIVSIX runs entirely in the kernel space and is supported by kernels starting at version 2.4. This kernel module is integrated as well in the RTLinux architecture, in the sense that runs independently of the real-time features of RTLinux. The software architecture of LIVSIX defines most primitives that are needed by protocols and allows for easy portability. The stack is designed entirely from scratch, and not as an evolution of IPv4 (like all other IPv6 stacks are designed). This allows to easily integrate new IPv6 mobility features. The next version of LIVSIX (due in 2002) integrates interfacing towards the native Linux TCP layer and thus more application types can be used. Also, more capabilities are planned that will support many other mobility entities (Correspondent Node, Home Agent, enhanced Access Router, etc.)

8.2 Radio Gateway

8.2.1 Functions This is the initial (maximum) list of functions that are associated with the Radio Gateway. Each function includes handling the associated message flows. • W-CDMA Support • Radio Access procedure (control) • Packet forwarding support • QoS Mapping • Communication protocol AR-RG or direct support with respect to QoS and AAAC features • Paging awareness and mapping

8.2.2 Radio Gateway Software Architecture



RCM

RCFWCDMA

ASWCDMA

EthernetNetworkDeviceDriver

IP Protocol Stack

IWF

Extended SocketInterface

Radio ServiceInterface

Standard SocketInterface

Standard Network Device Interface

WCDMANetworkDeviceDriver

Radio Management Interface

ASWCDMAInterface

Figure 21: Radio Gateway Software Architecture

Essentially, the Interworking Function (IWF) manages the relay of IP traffic between the radio and the IP domains, performing the necessary QoS mapping.

8.2.2.1 Functional elements

8.2.2.1.1 Interworking Function (IWF) The IWF will • Use the Radio Management Interface to

- Monitor the availability of the access networks and radio quality condition by obtaining information from the RCM

• Perform the necessary QoS mapping between the radio and the IP domains • Use the standard Socket interface and the Extended Socket Interface to

- Relay IP traffic between the radio and the IP domains

8.2.3 Radio Gateway IPv6 stack and Operating System As the Mobile Terminal, the Radio Gateway will run the RTLinux Operating System and the LIVSIX IPv6 stack from Motorola.

8.3 Access Router

8.3.1 Functions This is the initial (maximum) list of functions that are associated with the Access Router. Each function includes handling the associated message flows. • Context Transfer



• DiffServ Support • Network Access procedure • Policy enforcement • Handover incl. Bi-Casting • AAAC Client including key handling • Metering of resource usage • IP-Sec support • Paging awareness • Communication protocol AR-RG with QoS and AAA features if necessary

8.3.2 Operating System The Access Router will run the Linux Operating system.

8.4 Wireless LAN Access Router

8.4.1 Functions This is the initial (maximum) list of functions that are associated with the Wireless LAN Access Router. Each function includes handling the associated message flows. • Wireless LAN support incl. radio access procedure • Context Transfer • DiffServ Support • QoS Mapping • Network Access procedure • Policy enforcement • Handover incl. Bi-Casting • AAAC Client including key handling • Metering of resource usage • IP-Sec support • Paging awareness and mapping

8.4.2 Operating System The Wireless LAN Access Router will run the Linux Operating system.

8.5 Router

8.5.1 Functions This is the initial (maximum) list of functions that are associated with the Router. Each function includes handling the associated message flows. • DiffServ support

8.5.2 Operating System The Router will run the Linux Operating system.

8.6 Home Agent

8.6.1 Functions This is the initial (maximum) list of functions that are associated with the Home Agent. Each function includes handling the associated messages flows. • MIPv6 • DiffServ-Aware



• Key handling • IP-Sec support

8.6.2 Operating System The Home Agent will run the FreeBSD Operating system.

8.7 Paging Agent

8.7.1 Functions This is the initial (maximum) list of functions that are associated with the Paging Agent. Each function includes handling the associated message flows. • Paging • DiffServ-Aware • Key handling • IP-Sec support

8.7.2 Operating System The Paging Agent will run the FreeBSD Operating system.

8.8 Paging Agent Local

8.8.1 Functions This is the initial (maximum) list of functions that are associated with the Paging Agent Local. Each function includes handling the associated messages flows. • Paging • DiffServ-Aware • Key handling • IP-Sec support

8.8.2 Operating System The Paging Agent Local will run the FreeBSD Operating system.

8.9 AAAC server

8.9.1 Functions This is the initial (maximum) list of functions that are associated with the AAAC server. Each function includes handling the associated messages flows. • Authentication • Authorisation • Accounting • Charging • IP-Sec support • Interaction with metering, QoS broker, HA and AAAC Client • Auditing • Profile handling • Key handling • Binding update • Database for policy management (DT)

8.9.2 Operating System The AAAC server will run the Linux Operating system.



8.10 QoS Broker

8.10.1 Functions This is the initial (maximum) list of functions that are associated with the QoS Broker. Each function includes handling the associated messages flows. • Interface with the AAA entity • Inter QoS manager interface • Mobility management interface • Network management interface (traffic statistics and router configurations) • Managing QoS of the network

8.10.2 Operating System The QoS Broker server will run the Linux Operating system.

8.11 Correspondent Node

8.11.1 Functions This is the initial (maximum) list of functions that are associated with the Correspondent Node. Each function includes handling the associated message flows. • MIPv6 support (binding cache) • DiffServ-Aware • IP-Sec support • Support for applications

8.11.2 Operating System The Correspondent Node will run the Linux Operating system.



9. References Remark on Internet Drafts, Request for Comments (RFC) documents and Web-sites. The following statements are included in Request For Comments 2026 - "The Internet Standard Process -- Revision 3" (S. Bradner, Harvard University, October 1996) and briefly describe the treatment of Internet Drafts and Internet RFCs: • Internet Drafts: "An Internet-Draft that is published as an RFC, or that has remained unchanged in

the Internet-Drafts directory for more than six months without being recommended by the Internet Engineering Steering Group (IESG) for publication as an RFC, is simply removed from the Internet-Drafts directory. At any time, an Internet-Draft may be replaced by a more recent version of the same specification, restarting the six-month timeout period."

• Internet RFC: "It is important to remember that not all RFCs are standard track documents, and that not all standard track documents reach the level of Internet Standard. In the same way, not all RFCs which describe current practices have been given the review and approval to become Best Current Practices (BCPs).“ In addition, RFC can have the attribute “informational”, so they are only for information and might not become the standard track.

Web-sites have a life-time. They might change or will disappear. Web-servers might be shut down or their IP name (server name) will not be up-to-date anymore. [1] [MaKoPe et al.01] Manner et al., "Mobility Related Terminology". Internet Draft (work in progress),

November 2000 (draft-manner-seamoby-terms-00.txt).

[2] [BlTwTh et al.00] Blair, D., Tweedly, A., Thomas, M., Trostle, J., Ramalho, M., "Realtime Mobile IPv6 Framework". Internet Draft (work in progress), November 2000 (draft-blair-rt-mobileipv6-seamoby-00.txt).

[3] [DeHi98] Deering, S., Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification". Internet Engineering Task Force, Request for Comments (RFC) 2460, December 1998.

[4] [GuJoPe00] Gustafsson, E., Jonsson, A., Perkins, C., "Mobile IP Regional Registration". Internet Draft (work in progress), July 2000 (draft-ietf-mobileip-reg-tunnel-03.txt).

[5] [KeCaRo00] Kempf, J., McCann, P., Roberts, P., "IP Mobility and the CDMA Radio Access Network: Applicability Statement for Soft Handoff", Internet Draft (work in progress), July 2000 (draft-kempf-cdma-appl-00.txt).

[6] [DoKhPa et al.00] MIPv6 Handover Design Team, "Fast Handovers for Mobile IPv6". Internet Draft (work in progress), November 2000 (draft-perkins-mobileip-handover-00.txt).

[7] [Pa95] Pandya, R., "Emerging mobile and personal communication systems," IEEE Communications Magazine , vol. 33, pp. 44--52, June 1995.

[8] [Pe96] Perkins, C., "IP Mobility Support". Internet Engineering Task Force, Request for Comments (RFC) 2002, October 1996.

[9] [RaPoTh00] Ramjee, R., La Porta, T., Thuel, S., Varadhan, K., Salgarelli, L., "IP micro-mobility support using HAWAII". Internet Draft (work in progress), July 2000 (draft-ietf-mobileip-hawaii-01.txt).

[10] [Lo00] Loughney, J., "Seamless Mobility Concerns". Internet Draft, November 17, 2000 (draft-loughney-seamoby-concerns-00.txt).

[11] [IETF] www.ietf.org

[12] [NiHaPa et al.01] P. Nikander, D. Harkins, B. Patil et al., Threat Models introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6, <draft-team-mobileip-mipv6-sec-reqts-00.txt>, http://www.ietf.org/internet-drafts/draft-team-mobileip-mipv6-sec-reqts-00.txt

[13] [JoPe00] D. Johnson, C. Perkins, Mobility Support in IPv6, <draft-ietf-mobileip-ipv6-14.txt> http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-14.txt

[14] [SaXuCh et al.01] B. Sarikaya, X. Xu, V. Choyi et al., Mobile IPv6 Hierarchical Paging, draft-sarikaya-seamoby-mipv6hp-00.txt http://www.ietf.org/internet-drafts/draft-sarikaya-seamoby-mipv6hp-00.txt



[15] [LiReSc01] M. Liebsch, G. Renker, R. Schmitz, Paging Concept for IP based Networks, <draft-renker-paging-ipv6-01.txt> http://www.ietf.org/internet-drafts/draft-renker-paging-ipv6-01.txt

[16] [OhNaZh01] Y. Ohba, N. Nakajima, T. Zhang, LH-DMHA - Last Hop DMHA (Dormant Mode Host Alerting) Protocol, <draft-ohba-seamoby-last-hop-dmha-02.txt> http://www.ietf.org/internet-drafts/draft-ohba-seamoby-last-hop-dmha-02.txt

[17] [KeCaDo et al.01] J. Kempf, P. Calhoun, G. Dommety et al., Bidirectional Edge Tunnel Handover for IPv6, <draft-kempf-beth-ipv6-02.txt>, http://www.ietf.org/internet-drafts/draft-kempf-beth-ipv6-02.txt

[18] [KoPeTr01] R. Koodli, C. Perkins, J. Trostle, Fast Handovers in Mobile IPv6, <draft-koodli-mobileip-fastv6-02.txt>, http://www.ietf.org/internet-drafts/draft-koodli-mobileip-fastv6-02.txt

[19] [SoCaMa et al.01c] H. Soliman, C. Castelluccia, K. El-Malki et al., Hierarchical MIPv6 mobility management (HMIPv6), <draft-ietf-mobileip-hmipv6-04.txt> http://www.ietf.org/internet-drafts/draft-ietf-mobileip-hmipv6-04.txt

[20] [MaLePe01] J. Malinen, C. Perkins, Mobile IPv6 Regional Registrations, <draft-malinen-mobileip-regreg6-01.txt>, work in progress, March 2001, http://www.ietf.org/internet-drafts/draft-malinen-mobileip-regreg6-01.txt

[21] [MWIF] Mobile Wireless Internet Forum, IP in the RAN as a Transport Option in 3rd Generation Mobile Systems, Technical Report MTR-006, Release V.1.0.0 (December 2000)

[22] [JoPe00] D. B. Johnson et al., “Mobility Support in IPv6”, draft-ietf-mobileip-ipv6-13.txt, work in progress, November 2000.

[23] [SoCaMa et al.01b] H. Soliman et al, “Hierarchical MIPv6 mobility management”, draft-ietf-mobileip-hmipv6-02.txt, work in progress, February 2001.

[24] [Ca98] C. Castelluccia, “A Hierarchical Mobile IPv6 Proposal”, INRIA Technical Report, November 1998.

[25] [TsYePe01] G. Tsirtsis et al., “Fast Handovers for Mobile IPv6”, draft-ietf-mobileip-fast-mipv6-00.txt, work in progress, February 2001.

[26] [MaPe01b] J. T. Malinen et al, “Mobile IPv6 Regional Forwarding”, draft-malinen-mobileip-reg6fwd-00.txt, work in progress, March 2001.

[27] [ErBeCa00] T. Ernst et al, “Mobile Networks Support in Mobile IPv6”, draft-ernst-mobileip-v6-network-01.txt, work in progress, November 2000.

[28] [CaDePu01] A. De Carolis et al, “QoS-Aware handover for Mobile IP: Secondary Home Agent”, draft-decarolis-qoshandover-02.txt, work in progress, April 2001.

[29] [ChKo01] H. Chaskar et al, “A Framework for QoS Support in Mobile IPv6”, draft-chaskar-mobileip-qos-01.txt, work in progress, March 2001.

[30] [ShSeLo01] Q. Shen et al, “Flow Transparent Mobility and QoS Support for IPv6-based Wireless Real-time Services”, draft-shen-ipv6-flow-trans-00.txt, February 2001.

[31] [PaDe00] G. Patel and S. Dennett, “The 3GPP and 3GPP2 Movements Towards an All-IP Mobile Network”, IEEE Pers. Comm, August 2000

[32] [3GPP200a] 3GPP2, 2000, ‘IP Network Architecture Model for cdma2000 Spread Spectrum Systems’, Revision 1.0.0

[33] [3GPP 23922] 3GPP, 1999, 3GPP TR 23.922, ‘Architecture for an All IP network’, V 1.0.0

[34] [Br00] Bradner S., 3GPP2-IETF Standardization Collaboration, Internet Draft, December 2000, work in progress.

[35] [Jo01] Jonsson L., 3GPP2 Requirements for 0-byte ROHC IP/UDP/RTP Header Compression, Internet Draft, March 2001, work in progress

[36] [3GPP] 3GPP Technical Specification Group RAN, 3G TS 25.301 V4.1.0, Radio Interface Protocol Architecture

[37] [MWIF006] Mobile Wireless Internet Forum, IP in the RAN as a Transport Option in 3rd Generation Mobile Systems, Technical Report MTR-006, Release V.1.0.0 (December 2000)



[38] [MWIF001] Mobile Wireless Internet Forum, Architecture Principles, Technical Report MTR-001, Release 1.0

[39] [MWIF002] Mobile Wireless Internet Forum, Architecture Requirements, Technical Report MTR-002, Release 0.6

[40] [MWIF003] Mobile Wireless Internet Forum, Layered Functional Architecture, Draft technical Report MTR-003, Version .1.0

[41] [MWIF004] Mobile Wireless Internet Forum, Network Reference Architecture, Technical Report MTR-004, Draft 0.7

[42] [MWIF007] Mobile Wireless Internet Forum, Open RAN Architecture in 3rd Generation Mobile Systems, Technical Report MTR-007, Release V.0.3.0 (March 2001)

[43] [SaHaMa et al.00] B. Sarikaya, H. Haverinen, J.T. Malinen, V. Magret, Mobile IPv6 Regional Paging, Internet Draft, draft-sarikaya-mobileip-hmipv6rp-00.txt

[44] [ZhCaCa et al.00] X. Zhang, J. Castellanos, A. Campbell, K. Sawada, M. Barry, P-MIP: Minimal Paging Extensions for Mobile IP, Internet Draft, draft-zhang-pmip-00.txt

[45] [NetSim] “Network Simulator (ns), version 2” http://www-mash.cs.berkeley.edu/ns

[46] [SoCaMa et al.00a] H. Soliman, C. Castelluccia, K. El-Malki, et al., Hierarchical MIPv6 mobility management: draft-ietf-mobileip-hmipv6-01.txt

[47] [TsYePe et al.01] Fast Handovers for Mobile IPv6, G. Tsirtsis, A. Yegin, C. Perkins, G. Dommety, K. El-Malki, M. Khalil, <draft-designteam-fast-mipv6-01.txt>, February 2001.

[48] [JoPe00] D. Johnson and C. Perkins, Mobility Support in IPv6 (work in progress), <draft-ietf-mobileip-ipv6-13.txt, November 2000.

[49] [BaCaVe01] M. Barry, A. T. Campbell, A. Veres. “ Distributed Control Algorithms for Service Differentiation in Wireless Packet Networks”. Proc. IEEE Infocom, 2001.

[50] [GaPhGa98] A. Ganz, A. Phonphoem, Z. Ganz. “Robust Superpoll Protocol for IEEE 802.11 Wireless LANs”. IEEE Military Communications Conference (MILCOM), 1998. http://www.argreenhouse.com/society/TacCom/papers98/17_03i.pdf

[51] [PeZyFi] Al Petrick, Jim Zyren, Juan Figueroa. “Delivering Voice over IEEE 802.11 WLAN Networks”. http://www.intersil.com/design/prism/papers/Voice_%20over_IEEE_802_11.htm

[52] [VeCoMo01] M. Veeraraghavan, N. Cocker, and T. Moors. “Support of Voice services in IEEE 802.11 wireless LANs”. Proc. IEEE Infocom 2001. http://uluru.poly.edu/~tmoors/

[53] [RoYa95] C. Rose / R. Yates, Minimizing the Average Cost of Paging Under Delay Constraints, ACM, Journal of Wireless Networks, vol. 1, no. 2, pp.211--219, 1995

[54] [RoYa97] C. Rose / R. Yates, Ensemble Polling Strategies for Increased Paging Capacity in Mobile Communication Networks, ACM Journal of Wireless Networks, vol. 3, no. 2, pp.159--167, 1997

[55] [WoLe00] W.-S. Wong / V.M. Leung, Location Management for Next-Generation Personal, Communication Networks, IEEE Network, Sept. 2000

project number: ist-2000-25394 project title: moby dick...

Documents