mobility architecture implementation reportpacyna/deliverables/mobydick/d0302.pdf · mobility...

CEC Deliverable Number 1 / 131

IST-2000-25394 Moby Dick

D0302 Mobility Architecture Implementation Report

Contractual Date of Delivery to the CEC: December 2002

Actual Date of Delivery to the CEC: December 2002

Author(s): WP3 participants, see page 3

Participant(s): All WP3 participants

Workpackage: WP3

Est. person months: 22

Security: Internal circulation within the project

Nature: Report

Version: V2.0

Total number of pages: 131

Abstract: This document is a detailed specification and design of the mobility part of the overall system, and is intended to be a reference for the implementation work, which has started in parallel. It specifies all mobility related signalling flows, referring where necessary to the remaining flows. The document shows the details of the software architecture of all relevant physical elements, i.e. the Mobile Terminal, the Access Router, the Radio Gateway, the Home Agent and the Paging Agent. The functions of each of the mobility-related software modules are described, and an indication on whether the module is implemented in user space or kernel space. Finally, the interfaces between the modules are specified. The architecture of the physical elements also includes some non-mobility modules that are referenced only, and not specified in this document. The document contains an Appendix explaining why the ad hoc mode for wireless LAN will be used, and shows how it will be used. A draft version of this document was delivered in July 2002. The final version of this document contains the updated signalling flows and the full specification and design of the mobility-related physical elements with the exception of the specification of modules not related to mobility, which are only referred. Keyword list: Mobile IPv6, Seamless handover, Inter-technology handover, Paging support, WLAN Ad Hoc networks, W-CDMA, Access Stratum, Signalling Flows, Software Modules, Software Architecture, Ad Hoc Mode

D0302_M3-4.doc Final / M3.4 19.12.2002

CEC Deliverable Number : D0302 2 / 131

Executive Summary The Moby Dick project has set out to achieve an entirely IPv6-based solution to support mobility in telecommunications. Mobile devices should be able to have secure access to a QoS aware network via heterogeneous access technologies. Within the IETF and elsewhere, solutions exist to support mobility, Quality of Service (QoS), as well as for authentication, authorisation and accounting (AAA), but we are far from a solution that integrates these three vital aspects. After considerable delays due to security concerns not having been taken sufficiently into account, Mobile IPv6 drafts at the IETF have been delayed and are now, in their 19th version, up for renewed consideration towards an RFC.

Getting QoS support and AAA enhanced by auditing and charging to work for an Internet solution that includes mobility while using heterogeneous wireless and wired access technologies is the prime and ambitious goal of the project. Experiments and field trials will validate the developed concepts.

This document is a detailed specification and design of the mobility part of the overall system, and is intended to be a complete reference for the implementation work, which is proceeding in parallel. It specifies all mobility related signalling flows, referring where necessary to the remaining flows. The document shows the details of the software architecture of all relevant physical elements, i.e. the Mobile Terminal, the Access Router, the Radio Gateway, the Home Agent and the Paging Agent. The functions of each of the mobility-related software modules are described and contain an indication on whether the module is implemented in user space or kernel space. Finally, the interfaces between the modules are specified. If these concern interfaces with other work packages, e.g. on security, these have been done with mutual consent and considered agreed and approved.

The architecture of the physical elements also includes some non-mobility modules. These are not specified in detail in this document, but are parts of other Deliverables.

The document contains an Appendix explaining why the ad hoc mode for wireless LAN will be used, and shows how it will be used.

As a complete reference for implementations related to mobility, this document is binding for implementations across partners and, where relevant, between work packages. If some function or interface is not mentioned in this document, it will not be implemented.

D0302_M3-4.doc Final / M3.4 19.12.2002


Authors

Partner Name Phone / Fax / E-mail

02 NEC Marco Liebsch Phone: +49 (0)6221 – 90511 – 44 Ralf Schmitz Fax: +49 (0)6221 – 90511 – 55 Telemaco Melia E-mail: [email protected] Amardeo Sarma

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

05 USTUTT Wenhui Zhang Phone: +49-711-685 7964 Fax: +49-711-685 7983 E-mail: [email protected]

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

08 CRM Eric Melin Phone: +33 (0)1 69 35 25 48 Fax: +33 (0)1 69 35 25 01 E-mail: [email protected]

09 EURECOM Christian Bonnet Phone: +33-493.00.26.31 Lionel Gauthier Fax: +33-493.00.26.27 Raymond Knopp Yan Moret Michelle Wetterwald E-mail: [email protected]

D0302_M3-4.doc Final / M3.4 19.12.2002


Table of Contents

1. ABBREVIATIONS..................................................................................... 9

2. INTRODUCTION ..................................................................................... 11

3. MOBILITY GENERAL ARCHITECTURE................................................ 11

4. SIGNALLING FLOWS............................................................................. 12

4.1 Introduction.................................................................................................................................. 12

4.2 Assumptions: Security associations ............................................................................................ 13

4.3 Registration, fast intra-domain and inter-domain handover ................................................... 13

4.4 Registration .................................................................................................................................. 13

4.5 Session setup................................................................................................................................. 17

4.6 Intra-domain handover ............................................................................................................... 17

4.7 Inter-domain handover ............................................................................................................... 19

4.8 Paging............................................................................................................................................ 20 4.8.1 General information ............................................................................................................... 20 4.8.2 Service discovery and dormant mode registration ................................................................. 20 4.8.3 Paging process ....................................................................................................................... 23 4.8.4 Paging area update ................................................................................................................. 24

5. SOFTWARE MODULE SPECIFICATIONS............................................. 25

5.1 Mobile Terminal .......................................................................................................................... 26 5.1.1 Overview of the different components................................................................................... 26

5.1.1.1 Networking Control Panel ................................................................................................. 26 5.1.1.2 Mobile Terminal Networking Manager ............................................................................. 27 5.1.1.3 Radio Channel Manager..................................................................................................... 27 5.1.1.4 Radio Convergence Function............................................................................................. 27 5.1.1.5 Fast Handover module ....................................................................................................... 27 5.1.1.6 Paging module ................................................................................................................... 27 5.1.1.7 Registration module ........................................................................................................... 28 5.1.1.8 Enhanced IPv6 stack .......................................................................................................... 28 5.1.1.9 DSCP marking software..................................................................................................... 29 5.1.1.10 Monitoring Extensions to Ethernet / WLAN driver ....................................................... 29 5.1.1.11 Access Stratum............................................................................................................... 29

5.1.2 Networking Control Panel (NCP) .......................................................................................... 30 5.1.2.1 Set Network Preferences block .......................................................................................... 30 5.1.2.2 Set Handover Preference block.......................................................................................... 30 5.1.2.3 Network Environment Infos block..................................................................................... 31 5.1.2.4 Manual Handover block..................................................................................................... 31 5.1.2.5 Explicit Connectivity Request block.................................................................................. 32

5.1.3 Mobile Terminal Networking Manager (MTNM) ................................................................. 32 5.1.3.1 Set Network Preferences block .......................................................................................... 33 5.1.3.2 Set Handover Preference block.......................................................................................... 33 5.1.3.3 Network Environment Infos block..................................................................................... 33

D0302_M3-4.doc Final / M3.4 19.12.2002


5.1.3.4 Attach Procedure block...................................................................................................... 35 5.1.3.5 Manual Handover block..................................................................................................... 37 5.1.3.6 Automatic Handover block ................................................................................................ 38 5.1.3.7 Handover Execution........................................................................................................... 39 5.1.3.8 Paging block....................................................................................................................... 41

5.1.4 Fast Handover module ........................................................................................................... 42 5.1.5 Paging module ....................................................................................................................... 44

5.1.5.1 Dormant state watchdog..................................................................................................... 44 5.1.5.2 Common ID handler........................................................................................................... 45 5.1.5.3 MT dormant state manager ................................................................................................ 45 5.1.5.4 Signalling state machine .................................................................................................... 45

5.1.6 Radio Channel Manager......................................................................................................... 46 5.1.6.1 Radio Connection Manager block...................................................................................... 47 5.1.6.2 Packet Transmission block................................................................................................. 48 5.1.6.3 Packet Reception block...................................................................................................... 50

5.1.7 Radio Convergence Function................................................................................................. 50 5.1.7.1 WCDMA Connection Manager block................................................................................ 51 5.1.7.2 Paging sub-block................................................................................................................ 52 5.1.7.3 WCDMA EUI-64 identifier ............................................................................................... 52 5.1.7.4 Control Channel Management block ................................................................................. 52 5.1.7.5 Data Channel Management block ...................................................................................... 52

5.1.8 Monitoring Extensions to Ethernet / WLAN driver............................................................... 53 5.1.8.1 Monitoring Extensions to Ethernet driver.......................................................................... 53 5.1.8.2 Monitoring Extensions to WLAN driver ........................................................................... 53

5.1.9 W-CDMA Access Stratum..................................................................................................... 54 5.1.9.1 General architecture of the software platform.................................................................... 56 5.1.9.2 Physical Layer Software Architecture................................................................................ 58 5.1.9.3 MAC Services and Functions............................................................................................. 60 5.1.9.4 RLC Services and Functions.............................................................................................. 62 5.1.9.5 PDCP Services and Functions............................................................................................ 63 5.1.9.6 RRC Specification ............................................................................................................. 63

5.2 Access Router ............................................................................................................................... 68 5.2.1 Overview of the different components................................................................................... 68

5.2.1.1 Fast Handover Module / MIPL .......................................................................................... 68 5.2.1.2 Paging Attendant................................................................................................................ 68 5.2.1.3 Network Device Driver /WLAN........................................................................................ 68 5.2.1.4 Enhanced IPV6/IPSec/DiffServ packet Filter .................................................................... 69 5.2.1.5 AAA Attendant .................................................................................................................. 69 5.2.1.6 Metering............................................................................................................................. 69 5.2.1.7 QoS Manager / QoS Attendant .......................................................................................... 69

5.2.2 Fast Handover Module / MIPL .............................................................................................. 69 5.2.3 Paging Attendant.................................................................................................................... 69

5.2.3.1 Signalling relay .................................................................................................................. 70 5.2.3.2 Mapping function............................................................................................................... 70

5.2.4 Network Device Driver /WLAN............................................................................................ 71

5.3 Radio Gateway ............................................................................................................................. 72 5.3.1 Overview of the different components................................................................................... 73

5.3.1.1 Inter Working Function...................................................................................................... 73 5.3.1.2 Radio Channel Manager..................................................................................................... 73 5.3.1.3 Radio Convergence Function............................................................................................. 73 5.3.1.4 Access Stratum................................................................................................................... 73

5.3.2 Inter Working Function.......................................................................................................... 73 5.3.2.1 Info Management block ..................................................................................................... 74 5.3.2.2 IP to WCDMA relay block ................................................................................................ 75 5.3.2.3 QoS Attendant sub-block ................................................................................................... 78 5.3.2.4 WCDMA to IP relay block ................................................................................................ 80

5.3.3 IP stack................................................................................................................................... 81 5.3.4 Radio Channel Manager......................................................................................................... 81

5.3.4.1 Radio Connection Manager block...................................................................................... 81 5.3.4.2 Packet Transmission block................................................................................................. 82

D0302_M3-4.doc Final / M3.4 19.12.2002


5.3.4.3 Packet Reception block...................................................................................................... 83 5.3.5 Radio Convergence Function................................................................................................. 83

5.3.5.1 WCDMA Connection Manager block................................................................................ 83 5.3.5.2 Control Channel Management block ................................................................................. 84 5.3.5.3 Data Channel Management block ...................................................................................... 85

5.3.6 W-CDMA Access Stratum..................................................................................................... 85

5.4 Home Agent .................................................................................................................................. 86 5.4.1 MIPL...................................................................................................................................... 86

5.5 Paging Agent ................................................................................................................................ 87 5.5.1 Dormant Monitoring Agent Functional Entity (DMA).......................................................... 87 5.5.2 Tracking Agent Functional Entity (TA)................................................................................. 88 5.5.3 Paging Agent Functional Entity (PA) .................................................................................... 88

6. INTERFACE SPECIFICATIONS ............................................................. 88

6.1 MT NCP & MT MTNM .............................................................................................................. 88 6.1.1 Description............................................................................................................................. 88 6.1.2 Interface mechanisms............................................................................................................. 88 6.1.3 Interface contents ................................................................................................................... 88

6.2 MT MTNM & MT NDD.............................................................................................................. 90 6.2.1 Description............................................................................................................................. 90 6.2.2 Interface mechanisms............................................................................................................. 90 6.2.3 Interface contents ................................................................................................................... 90

6.3 MT MTNM & MT Fast Handover module ............................................................................... 91 6.3.1 Description............................................................................................................................. 91 6.3.2 Interface mechanisms............................................................................................................. 91 6.3.3 Interface contents ................................................................................................................... 91

6.4 MT MTNM & MT Registration module.................................................................................... 91 6.4.1 Description............................................................................................................................. 91 6.4.2 Interface mechanisms............................................................................................................. 91 6.4.3 Interface contents ................................................................................................................... 91

6.5 MT MTNM & MT Paging module............................................................................................. 91 6.5.1 Description............................................................................................................................. 91 6.5.2 Interface mechanisms............................................................................................................. 92 6.5.3 Interface contents ................................................................................................................... 92 6.5.4 Format of the messages.......................................................................................................... 92

6.6 MT NAS (RCF layer) / RG NAS (RCF layer) ......................................................................... 93 6.6.1 Description............................................................................................................................. 93 6.6.2 Interface mechanisms............................................................................................................. 93 6.6.3 Interface contents ................................................................................................................... 93

6.7 MT/RG NAS (RCF layer) & MT/RG AS/W-CDMA................................................................ 94 6.7.1 Description............................................................................................................................. 94 6.7.2 W-CDMA driver interface mechanisms ................................................................................ 95

6.7.2.1 Overview – environment.................................................................................................... 95 6.7.2.2 RT-FIFOs........................................................................................................................... 95 6.7.2.3 Interface triggers ................................................................................................................ 96

6.7.3 Primitives and functions......................................................................................................... 97 6.7.3.1 RG broadcast service ......................................................................................................... 97 6.7.3.2 UE in Idle mode ................................................................................................................. 97 6.7.3.3 UE transition to connected mode ....................................................................................... 97 6.7.3.4 UE in connected mode ....................................................................................................... 98 6.7.3.5 User Data Transmission ..................................................................................................... 99

D0302_M3-4.doc Final / M3.4 19.12.2002


6.7.3.6 Handover primitives........................................................................................................... 99 6.7.3.7 Notification & paging primitives ..................................................................................... 100 6.7.3.8 Format of the primitives................................................................................................... 100

6.7.4 Message Flows..................................................................................................................... 100

6.8 MT Fast Handover & AR Fast Handover ............................................................................... 102 6.8.1 Description........................................................................................................................... 102 6.8.2 Interface mechanisms........................................................................................................... 102 6.8.3 Interface contents ................................................................................................................. 103 6.8.4 Format of the messages........................................................................................................ 103

6.9 MT Paging Module & PA PA/TA/DMA .................................................................................. 109 6.9.1 Description........................................................................................................................... 109 6.9.2 Interface mechanisms........................................................................................................... 109 6.9.3 Interface contents ................................................................................................................. 109 6.9.4 Format of the messages........................................................................................................ 110

6.10 AR Paging Attendant & MT Paging Module .......................................................................... 113 6.10.1 Description........................................................................................................................... 113 6.10.2 Interface mechanisms........................................................................................................... 113 6.10.3 Format of the messages........................................................................................................ 113

6.11 AR Paging Attendant & RG IWF ............................................................................................ 113 6.11.1 Description........................................................................................................................... 113 6.11.2 Interface mechanisms........................................................................................................... 113 6.11.3 Interface contents ................................................................................................................. 114 6.11.4 Format of the messages........................................................................................................ 114 6.11.5 Flows.................................................................................................................................... 114

6.12 AR Paging Attendant & PA PA/TA/DMA............................................................................... 114 6.12.1 Description........................................................................................................................... 114 6.12.2 Interface mechanisms........................................................................................................... 114 6.12.3 Interface contents ................................................................................................................. 114 6.12.4 Format of the messages........................................................................................................ 114 6.12.5 Flows.................................................................................................................................... 114

6.13 AR Fast Handover & AR AAA attendant ............................................................................... 115 6.13.1 Description........................................................................................................................... 115 6.13.2 Interface mechanisms........................................................................................................... 116 6.13.3 Interface contents ................................................................................................................. 116

6.14 AR Fast Handover & AR QoS attendant................................................................................. 117 6.14.1 Description........................................................................................................................... 117 6.14.2 Interface mechanisms........................................................................................................... 117 6.14.3 Interface contents ................................................................................................................. 117

6.15 RG IWF / RG RCM-RCF ......................................................................................................... 117 6.15.1 Description........................................................................................................................... 117 6.15.2 Interface mechanisms........................................................................................................... 118 6.15.3 Interface contents ................................................................................................................. 118

6.16 RG IWF / QoS Broker............................................................................................................... 118 6.16.1 Description........................................................................................................................... 118 6.16.2 Interface mechanisms........................................................................................................... 118 6.16.3 Interface contents ................................................................................................................. 119

6.17 MT/AR Fast Handover with Enhanced IPv6 .......................................................................... 119

6.18 MT Paging Module / MT Enhanced IPv6 stack ...................................................................... 119 6.18.1 Description........................................................................................................................... 119 6.18.2 Interface mechanisms........................................................................................................... 120

D0302_M3-4.doc Final / M3.4 19.12.2002


6.18.3 Interface contents ................................................................................................................. 120

7. REFERENCES ...................................................................................... 121

8. APPENDIX A : WLAN INFRASTRUCTURE AND AD HOC MODE ..... 122

8.1 Introduction................................................................................................................................ 122

8.2 WLAN Basics ............................................................................................................................. 122 8.2.1 Definitions ........................................................................................................................... 122 8.2.2 Message Type ...................................................................................................................... 123 8.2.3 Services and States............................................................................................................... 123 8.2.4 MAC frame formats ............................................................................................................. 125 8.2.5 Number of operating channels ............................................................................................. 126

8.3 Differences between Infrastructure and Ad hoc Mode and relevance to Moby Dick .......... 127 8.3.1 Communication between STAs............................................................................................ 127 8.3.2 Services and States............................................................................................................... 128 8.3.3 Different Requirement on Authentication............................................................................ 128 8.3.4 Frame Formats Difference ................................................................................................... 128 8.3.5 Beacon Generation............................................................................................................... 129 8.3.6 Synchronization ................................................................................................................... 129

8.4 Handover Delay Analysis in Infrastructure Mode.................................................................. 129

8.5 Additional Work to Deploy Ad hoc Mode ............................................................................... 130 8.5.1 Configuration for working in ad hoc mode.......................................................................... 130 8.5.2 Filter Function in WLAN driver .......................................................................................... 131 8.5.3 Beacon generation................................................................................................................ 131 8.5.4 Synchronization ................................................................................................................... 131

D0302_M3-4.doc Final / M3.4 19.12.2002


1. Abbreviations Abbreviation Full Name AAAC Authentication, Authorization, Accounting and Charging AAAC.f Foreign AAAC server AAAC.h Home AAAC server AAAP Private/Personal AAA server AH Authentication Header API Application Programming Interface AR Access Router ARQ Automatic Repeat Request AS Access Stratum AVP Attribute Value Pair BACK Binding Acknowledge BE Best Effort BS Base Station BU Binding Update CBT Core Based Tree CDMA Code Division Multiple Access CN Correspondent Node CoA Care-of Address CT Context Transfer DAD Duplicate Address Detection DC Dedicated Control DHCP Dynamic Host Configuration Protocol DMA Direct Memory Access DMA Dormant Monitoring Agent DoS Denial of Service DSCP Diff Serv Code Point FDD Frequency Division Duplex FHO Fast Handover FIFO First In, First Out data structure GC General Control GMA Gateway Mobility Agent GPRS General Packet Radio Service GSM Global System for Mobile communications GUI Graphical User Interface HA Home Agent HMIP Hierarchical MIP HoA Home Address ICMP Internet Control Message Protocol ID Identifier IMEI International Mobile station Equipment Identity IMSI International Mobile Subscriber ID IP Internet Protocol IWF Inter Working Function L1 Layer 1 L2 Layer 2 L3 Layer 3 LAN Local Area Network MAC Medium Access Control MAP Mobility Anchor Point MIPL Mobile IPv6 for Linux MN Mobile Node MT Mobile Terminal MTNM Mobile Terminal Networking Manager NAI Network Access Identifier NAS Non Access Stratum

D0302_M3-4.doc Final / M3.4 19.12.2002


nAR New Access Router NCP Networking Control Panel Nt or NT Notification NVUP Network View of the User Profile oAR Old Access Router ODMA On Demand Multiple Access PA Paging Agent PBK Purpose Built Key PCH: Paging Channel PDCP Packet Data Convergence Protocol PDU Protocol Data Unit PLMN Public Land Mobile Network QoS Quality of Service QoSB (domain) Quality of Service Broker including a policy server RAR Radio Access Router RB Radio Bearer RCM Radio Channel Manager RCF Radio Convergence Function RF Radio Frequency RG Radio Gateway RLC Radio Link Control RNC Radio Network Controller RNS (domain) Radio Network Server RR (subnet) Radio Router for a specific sub network RRC Radio Resource Control RT Real Time RtAdv Router Advertisement SA Security Association SAPI Service Access Point Identifier SAR Serving Access Router SDU Service Data Unit SGSN Serving GPRS Support Node SIB System Information Block SIP Session Initiation Protocol SLA Service Level Agreement SMP Symmetric Multi-Processor SSID Service Set Identifier SWAMP Secure Wide-Area Mobility Package TA Tracking Agent TDD Time Division Duplex TFCI Transport Format Combination Indicator TLV Type-Length-Value TTI Transmission Time Interval UE User Equipment UMTS Universal Mobile Telecommunications System URP User Registration Protocol UTRAN Universal Terrestrial Radio Access Network WCDMA Wideband Code Division Multiple Access WLAN Wireless Local Area Network Xcast Explicit Multicast

D0302_M3-4.doc Final / M3.4 19.12.2002


2. Introduction The Mobility Architecture Implementation Report contains a draft detailed specification and design of the mobility part of the overall system, and is intended to be a reference for the implementation work. It specifies all mobility related signalling flows, referring where necessary to the remaining flows. The document shows the details of the software architecture of all relevant physical elements, i.e. the Mobile Terminal, the Access Router, the Radio Gateway, the Home Agent and the Paging Agent. The functions of each of the mobility-related software modules are described, and an indication on whether the module is implemented in user space or kernel space. Finally, the interfaces between the modules are specified, for which however not all message formats are fully defined at this stage. Also, some of the interfaces to modules not related to mobility are not included in the draft version. The architecture of the physical elements also includes some non-mobility modules. These are not specified in this document. It is further open whether these specifications will be part of the final document, since this may lead to a duplication of specifications, or whether there will rather be a reference to other documents.

The Deliverable is structured as follows. Abbreviations have already been covered in Chapter 1. In Chapter 3, the general Moby Dick architecture described in D0101 is specialised to focus on mobility management aspects and components of the overall system, and is aligned with a similar chapter in D0301. Chapter 4 is a collection of the signalling flows required for the mobility part of Moby Dick. The software architecture of the physical elements: the Mobile Terminal, the Access Router, the Radio Gateway, the Home Agent and the Paging Agent is illustrated in Chapter 5, which also contains the description of the individual mobility-related software modules. Chapter 6 contains the interface specifications. A list of references is contained in Chapter 7. This draft version does not include a Conclusions Chapter, which the final version will.

The Deliverable contains in addition an Appendix on the rationale for our choice of the ad hoc mode instead of the infrastructure mode for wireless LAN as a temporary solution for the project, being quite aware that the infrastructure mode is the target long-term solution.

3. Mobility General Architecture This Chapter focuses on the entities involved in mobility management within the overall Moby Dick architecture and is an abbreviated version of a similar Chapter in Deliverable D0301.

The set of functional entities covers appropriate agents for global and local mobility management, as well as for enhancing the basic mobility management functionality to support fast handover and IP based paging. The basic components for IPv6 based mobility management are those entities that are specified for Mobile IPv6 managed networks, which are Home Agents (HA), Mobile Nodes (MN) and Correspondent Nodes (CN). Local mobility agents may be integrated into individual administrative domains for localised mobility management. Individual Access Routers support (fast) handover, i.e. cutting latency and reducing data loss, between two adjacent IP subnets that provide wired or wireless access. Intra-domain handover is intended to be fast, whereas inter-domain handover is likely to require additional authentication and authorisation procedures. The fast handover procedure allows an inter-working of different access technologies. The handover process will be used to transfer session or attachment based parameters from the old Access Router to the new Access Router during the handover. This speeds up re-establishment of conditions at the new Access Router as they had been established on the old Access Router before a handover. In addition, the QoS managing entities will be informed of these changes.

The Mobile Node includes appropriate functions for mobility management, i.e. paging support and handover support. Mobility management as well as paging a Mobile Node will be transparent to Correspondent Nodes (CN). The only additional functionality implemented in Correspondent Nodes is the part of the Mobile IPv6 protocol pertaining to route optimisation. This is used for direct communication between the Mobile Node and when a Mobile Node notifies its Correspondent Node of its current location, which allows packets destined to the Mobile Node to be sent directly from the CN to the MN, rather than always going via the Mobile Node’s home address and relying on the tunnelling of packets from the HA to the Mobile Node’s location. Paging is designed to allow flexible deployment of paging services within any kind of architecture. Though paging may in principle be used both across administrative domains and within a domain, the Moby Dick project has chosen to manage paging on a per administrative domain basis only. This requires that the respective Paging Agents (PA) are entities that are integrated within individual administrative domains.

D0302_M3-4.doc Final / M3.4 19.12.2002


The mobility management architecture, which covers the protocols and the related entities, optimises IP packet transport and makes use of appropriate management protocols. The IP based protocols 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 are based on conventional hardware equipped with the appropriate technology for wired or wireless networking. Modifications 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 the expensive equipment currently used in 2nd and 3rd Generation mobile communication architectures. The overall goal is to support the same Mobility, Security and Quality of Service functions with comparable or even superior platform functionality and quality as currently provided by mobile communications platforms.

The following Figure 2 illustrates the location of these respective functional entities for mobility management within the Moby Dick architecture. A MN's home link does not have to be a physical link composed of some physical medium. Rather, the home link can be a virtual link that exists only within the MN's Home Agent. The Home Agent can be considered to have a virtual interface through which it attaches to this virtual home link. Such a MN can never 'connect' to its virtual home link and therefore will never be 'at home'. The same effect, which we consider as a drawback, also applies when the MN never 'plugs' into the home network, since this is somewhere within the provider’s domain. Multiple HAs are for resource-sharing purpose. Therefore, the home address is used for mobility management purposes only. This eliminates the requirement to provide a HA function in each AR. To distinguish an individual mobile terminal’s home domain from the foreign domains, the only HA shown is the one the MN is assigned to within the home domain, as illustrated in Figure 2. Of course, all foreign domains may implement HAs for MNs registered with the respective domain’s provider.

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

architecture.

4. Signalling Flows

4.1 Introduction This section presents the signalling and message flows for initial registration, fast intra-domain handover, inter-domain handover and paging with respect to mobility, QoS and AAA. The scenarios that exist in the Moby Dick framework but are not part of WP3 are described only briefly. The main aim is to identify the functionality, in terms of protocols related to mobility, which must be supported in the different procedures of Moby Dick operation.

D0302_M3-4.doc Final / M3.4 19.12.2002


4.2 Assumptions: Security associations The following security associations are assumed:

Static Dynamic MN - AAAC.h MN - AR AAAC.h – HA

MN – HA oAR – nAR

AAAC.f - AAAC.h AR - AAAC.f

The assumption of a security association of neighbour Access Routers within an administrative domain is also part of the fast-handover draft [draft-ietf-mobileip-fast-mipv6-03.txt].

4.3 Registration, fast intra-domain and inter-domain handover There is the need to distinguish between registration, fast intra-domain and inter-domain handover, since all the scenarios require different handling / procedures.

Intra-domain handover requires a fast handover procedure (i.e., communication between new Access Router and old Access Router), while for the registration and for inter-domain handover the involvement of AAAC.h and Home Agent is required. The reason for this distinction is the assumption that the provider of a domain a MN is about to leave, in the following called old domain, has not necessarily any contractual relationship with the provider of the domain the MN is about to join, in the following called new domain. But both providers, the provider of the old domain and the provider of the new domain, have a business relationship with the provider of the home domain of the user currently using the MN. Within the framework of Moby Dick, the focus will be on efficient intra-domain handovers, since inter-domain handovers are expected to occur more rarely and will not be seamless, since the involvement of ‘far away’ network entities is required. In order to keep this decision (about the type of procedure needed: registration, fast intra-domain or inter-domain handover) transparent to the Mobile IP stack (i.e., MIPL), this decision algorithm is placed ‘below’ Mobile IP (namely, in a module in the MT architecture called MTNM, this will be described in section 5.1.1.2).

The parameters on which the decision is based are:

• Binding cache (i.e., no entry: registration; valid entry: handover) • Analysis of the router advertisement prefix, in order to distinguish between intra and inter-

domain handover (a detailed explanation is provided in section 0)

4.4 Registration This section gives an overview of the signalling for (initial) Registration, i.e., the registration of a Mobile Terminal, which has no valid entry in its binding cache. Registration describes the process which takes place after a mobile node is e.g. switched on and the user of the mobile terminal wants to connect to the Internet. This means either the user wants to send data or being reachable for any other user in the world. So a registration takes place when a Mobile Node wants to connect first to any domain. This means that a registration process takes place as well during a mobility scenario where two administrative domains are involved. If this happens during an activity of a Mobile Node (the MN sends or receives packets), this process is called inter-domain handover as is described in section 4.7. In the case the MN is not active, this is just identical to the case a MN is switched on. The monitoring of the binding cache is part of the handover type decision algorithm (see 4.3 ) and therefore is part of the MTNM. Additionally there is a re-registration process defined, since the registration is bound to a certain period of time. This re-registration is triggered by an internal timer and does not differ principally from the registration process.

The Registration process (AAA and Mobility) is initiated after the Care of Address (CoA) is acquired by the Mobile Node via the deployment of stateless auto-configuration, avoiding Duplicate Address Detection (DAD) by using unique layer-2 identifiers to create the Interface Identifier part of the IPv6 address [2]. However, the CoA does not entitle the user to consume resources apart from the following registration messages and emergency calls. Note that in the envisaged QoS architecture, other type of services can be initially available to the user, depending on the specific network policy.

From the mobility point of view, the main result of the Registration process is registering the chosen CoA in the respective HA.

D0302_M3-4.doc Final / M3.4 19.12.2002


The registration scenario will be developed in a two step approach. In the first step AAA signalling and MIP signalling are completely separated. The advantage of this is that there is no interface required between AAA and MIP. The disadvantage is that the registration takes longer. Furthermore in the first step an existing security association is needed between MN and HA. In the second step this association is built dynamically. Furthermore in the second step the AAA architecture even could be used for dynamic HA discovery.

In the first step (Figure 2), the MN sends an AA request via the user registration protocol (URP) to the AR. The AR sends an AA request via AAA protocol to its AAAC.f which forwards the request to the AAAC.h according to the NAI. The AAAC.h authenticates and authorizes the user and sends a AAA protocol reply back to the AAAC.f. In this message the network permissions of the user are already indicated. The AAAC.f may then perform local global authorization decisions. The AAAC.f sends back a reply to the AR which forwards all relevant data to the MN via the user registration protocol. At the same time, the AAAC.f dumps on the local QoS.f the relevant network parameters for the services authorized for that user. Standard Mobile IP implementation sends out a Binding Update (BU) to the HA immediately after the CoA acquisition, and the HA replies with a BACK. These messages go through the AR without any requirement for authorization as the AR will be configured by default with a minimal bandwidth for signalling (another possibility, but this is a configuration option, is that the QoS attendant located at the AR blocks the BU until an authorization from the QoS.f is received). This also assumes that in the WCDMA case these packets will arrive via a broadcast channel. Upon receiving the AAA answer from AAAC.f the AR starts an accounting session. The metering entity at the AR collects these raw data and send is in a fixed and externally defined interval to the AAAC.f. The AAAC.f consolidates these data and forwards them to the AAAC.h. The accounting functionality is configured by the accounting policies contained in the AA response from AAAC.f. The timer interval T1 describes the interval between two forwarding processes of consolidated accounting data. T2 describes the interval for a re-registration process.

D0302_M3-4.doc Final / M3.4 19.12.2002


MN AR AAAC.f QoS.f QoS.h AAAC.h

1

2

3

4

5a 6

9

10

7

8

5b

1

2

3

4

5a 6

5b

9

109

109

10

T1

T2

HA

Figure 2 Registration Scenario Step 1

The following table specifies the messages, and describes parameters and content.

No. Message Content / Parameters Remarks 1 AA Request NAI; credentials; CoA 2 AA Request NAI; credentials; CoA 3 AA Request NAI; credentials; CoA 4 AA Response 2x key (MN, AR), Profile SubSet,

Session Timeout

5a AA Response 2x key (MN, AR), Profile SubSet, Session Timeout

5b NVUP dump MN, AR, Profile SubSet (includes timeout)

NVUP: Network View of the User Profile

6 AA Response 1x key(MN, AR), Profile SubSet (codes), Session Timeout

Dumps the proper DSCP codes to use in this network

7 BU 8 BACK

D0302_M3-4.doc Final / M3.4 19.12.2002


9 Accounting Data SrcIP, HoA, DesIP, DSCP, In/Out Byte/Packet Counter

The destination address may also be required in many network-level services (e.g. free numbers)

10 Accounting Data SrcIP, HoA, DesIP, DSCP, In/Out Byte/Packet Counter

Table 1: Registration Step 1 messages and Parameters

The setting of the timer T1 is foreseen to be in a 3 minute interval. The timer T2 for the re-registration interval is proposed to be at the range of 10 minutes. In both cases, practical experience could result in that these values might change significantly.

The key between Mobile Node and Access Router is sent twice, due to the encryption requirement: the first key is encrypted for the AR, the second is encrypted for the MN. However, it is the same key.

Messages between the MN and AR are based in URP (User Registration Protocol, defined in WP4). Messages between AR, AAAC.f and AAAC.h are Diameter messages containing the appropriate AVPs already defined. BU and BACK are standard MIP messages.

Step 2 is shown in Figure 3. In step 2 the initial BU is piggybacked on the AA request. This figure does not contain the re-registration interval and the interval for the transfer of the accounting data since this procedure is identical to step 1.

Figure 3 Registration Scenario Step 2

MN AR AAAC.f QoS.f QoS.h AAAC.h HA 1

2

3

4

5

6

7a

8 9

10

7b

D0302_M3-4.doc Final / M3.4 19.12.2002


The following table specifies the messages, and describes the corresponding parameters and content.

No. Message Content / Parameters Remarks 1 AA request usr:pwd@domain; BU 2 AA request usr:pwd@domain; BU 3 AA request usr:pwd@domain; BU 4 BU (see Mobile IP BU) 5 BACK (see Mobile IP BACK) 6 AA response 2x key(MN, AR), Profile SubSet, BACK 7a AA response 2x key(MN, AR), Profile SubSet, BACK 7b NVUP dump MN, AR, Profile SubSet (includes timeout) 8 AA response 1x key(MN, AR), Profile SubSet (codes),

BACK

9 Accounting Data CoA, HoA, DestIP, DSCP, Time, In/Out Byte/Packet Counter

10 Accounting Data CoA, HoA, DestIP, DSCP, Time, In/Out Byte/Packet Counter

Table 2: Registration Step 2 messages and Parameters The protocols used are the same as in step 1.

4.5 Session setup This scenario, part of the WP2, specifies the signalling for establishing a QoS session. It deals with authorizing a flow pass through Moby Dick’s network, providing it QoS and configuring measurement parameters. Previous phases (Authentication & Registration) are needed for the user to be allowed to send packets but are not sufficient (except in some possible cases). The further (and last) step needed, “flow authorization”, is described in this scenario. This process is done in a per service basis at session setup. Only the QoS Manager of the AR is involved in that process and is the sole part considered in this scenario. Here, we assume that registration has already been done and that the needed subset of the user profile (the NVUP) is in the QoS.f. Also user’s identity is already known to the Network and it could tariff user’s packets. But we recall that the user is not yet authorized to send packets (except for some possible exceptions)

When a new service flow enters the access router the following can happen depending on the policy decisions of the network operator.

• The service has previously been authorized, the AR forwards the packets. • The service has not previously been authorized but the flow goes to a certain IP address (e.g.

VoIP Server for emergency calls or some predefined SP’s) in the foreign domain. The AR forwards the flow.

• The service has not previously been authorized, but it has a DSCP=0 (B.E.). The AR either forwards or stops the flow, according to overall network policy.

• The service has not previously been authorized; the AR begins an authorization process. If the process succeeds the AR forwards the packets, else it drops the flow.

4.6 Intra-domain handover Within the Moby Dick mobility framework two different handover scenarios are considered. These are from an administrative point of view inter-domain handover scenarios and inter-domain handover scenarios. In order to fasten up the scenarios to minimize the timely effort for the mobility management procedure, an intra-domain handover will not involve an AAA entity during the time-critical handover phase, but inform the respective AAA entity after the handover has been completed successfully. Here AAA context is included as attributes into the fast handover specific communication between the oAR and the nAR. After the QoS resource availability on the new point of attachment is confirmed and therefore the handover is accepted, the AAA context is relayed to the AAA attendant, which is located on the new AR, and triggers the information of the respective AAA entity. As already pointed out in the previous sentence, a fast handover may be aborted due to QoS specific requirements, such as lack of QoS resources at the desired new link. Therefore, the nAR waits for the (positive or negative) QoS

D0302_M3-4.doc Final / M3.4 19.12.2002


acknowledgement before responding the Handover Initiate of the oAR. In case a handover must be aborted, the negative ACK will be sent to the MN (via the oAR) and relayed to the MTNM handover decision module, in order to choose another (i.e., the second best) AR and / or technology.

So, the focus of the Moby Dick project with respect to an integration of AAA, QoS and mobility is on intra-domain handover, mainly due to the following aspects:

• Majority of handovers will occur within an administrative domain. • Provisioning of seamless handover can be guaranteed (while inter-domain handover requires time consuming signalling to the home domain, which might cause interruptions).

The figure below shows the intra-domain handover message flow, which corresponds to what is written in the WP3 deliverable [2] and from the mobility management architectural point of view follows the IETF draft “draft-ietf-mobileip-fast-mipv6-03.txt”. However, the FHO primitives, as sketched below, are implemented as ICMPv6 messages.

10

1

MN oAR nAR nQoS.f AAAC.f HA

2

3

5

6

7 8

9

11 12 13

14

15

X

oQoS.f

A B

C

In this signalling flow and the Moby Dick implementation, the HACK message from the nAR to the oAR is blocked until the arrival of the QoS response, in order to allow the abort of the FHO due to QoS specific requirements. However, this delay is negligible, because (i) it occurs in the preparation phase of the handover, which is not time-critical, since it does not influence the handover latency and (ii) it is assumed that the QoS Broker is located ‘physically close’, i.e., the additional message time on the network and the calculation time is so small that there is no effect on the overall handover performance.

Figure 4 : Fast Handover Signalling Flow

D0302_M3-4.doc Final / M3.4 19.12.2002


The following table describes the messages and parameters for the Fast Handover Signalling:

No. Message Content / Parameters Remarks 1 Router Advertisement New Network prefix, src

address nAR (link local)

2 Router Solicitation for Proxy nARaddr, new CoA 3 Handover Initiate new CoA, AAA context CT info for AAA as message

option A QoS message NAR, oCoA, nCoA B QoS message C QoS message Configuration data, result info

(pos. or neg. ACK)

5 Handover Acknowledge QoS result 6 Proxy Router Advertisement QoS result 7 Handover Execute (FBU) 8 Start Bicasting (& Timer) 9 Handover Execute ACK

10 Leaving old link 11 Bicasting Timer expired (Forwarding still ‘active’

some more time) 12 Accounting data CoA, DSCP, Time, In/Out

Byte/Packet Counter

13 Neighbour Advertisement X Accounting Start CoA, DSCP, Time Accounting Start requires

context and is triggered on reception of 1st PDU

14 Binding Update 15 Binding ACK

Table 3: Fast Handover Signalling Messages and actions The Router Advertisement (1) indicates if the intended handover takes place within a domain or if it is inter-domain. The decision is based on the prefix structure of the IPv6 address and is performed within the MTNM:

48 bit 2001:0638:0202

16 bit 64 bit = 24 bit + FFFE (16bit) + 24 bitEthernet………………….address

Network provider address SLA EUI 64 bit

2001:0638:0202: 0 :0250:daff:fecf:c6ad

Figure 5 : IPv6 Address

In case of a change in the first 48 bits, the Mobile Terminal knows that it will enter another administrative domain, since the network provider is different. Changes of the SLA refer to a subnet change within an administrative domain.

4.7 Inter-domain handover An inter-domain handover requires message exchange with the home domain (i.e., AAAC.h and HA), because there will be no pre-established security association between different network providers. Therefore, there will be no guarantee for seamless inter-domain handover, since the interruption time depends on the round trip time to the home domain, which might be far away. Due to this reason and due to the assumption that inter-domain handover will occur more rarely than handover within a domain, the project will not focus on optimizing the inter-domain handover case.

D0302_M3-4.doc Final / M3.4 19.12.2002


Then, the signalling for inter-domain handover will be the same as in the Registration case.

4.8 Paging

4.8.1 General information This section describes a signalling flow for entering a dormant mode, initiated from mobile terminal side, as well as for the actual IP paging process according to the specified paging concept. The architecture and protocol description is in line with what is written in the WP3 deliverable [2]. However, for the Moby Dick test-bed, not all concept details will be taken into account, as the concept’s support for security.

For a more specific description of the IP paging mechanism, please be referred to [2]. This section intends to describe the integration of the concept for IP based paging into the Moby Dick platform, which takes also inter-working with the project’s security framework into consideration. The security related options of the protocol are for dynamic establishment of paging security association between a mobile terminal and its discovered Paging Agent. Furthermore, an authentication option is considered for the last-hop paging message authentication process when the mobile terminal is being paged. However, the security support of the paging concept is specified and described in [2], and will not be part of the project’s implementation of IP paging support. Therefore, as an example, the interface between the Paging Agent and the AAAC.f for key management will not be implemented; hence the NAI will not be deployed here. Assumptions for the paging concept’s security support Pre-established security associations:

• AAA.f – PA • PA – ARx (ARs inside a domain, in particular these assigned to the registered paging areas) • MN – current AR before entering the IDLE mode (since dormant mode registration requires

previous authentication with the network, which is considered to be the standard AA procedure of the Moby Dick scenario).

Dynamic SAs for registration with a Paging Agent and for a paging process:

• ARx – MN • MN – PA

4.8.2 Service discovery and dormant mode registration When a mobile terminal decides to enter the idle mode, it has to discover the responsible Paging Agent first. This agent should be a long-term PA, which is responsible to track the mobile terminal’s location beyond the scope of the current paging area. This means, the discovered PA, once having a registration for the respective mobile terminal, should be updated when the idle mode registration lifetime expires or the paging area changes. Two proposals are illustrated below, one having the idle mode registration implicit with the PA discovery procedure, the other one keeps PA discovery separated from the actual registration with this PA. The implicit registration can be requested from the MN in the registration message sent to the current AR. Messages for discovery and registration are the same, but distinguished with a flag set. Implicit registration messages carry the respective options required for the actual dormant registration. Since the mobile terminal has a previously established security association with its current AR, the AR can authenticate the incoming request. The AR generates another Dormant Mode Request message, which is to be sent to the responsible PA for dynamic security association establishment between the MN and the PA as well as for implicit registration purpose. The PA takes the decision on whether implicit registration should be allowed or the MN has to explicitly register dormant with the PA after the discovery procedure. In the reply from the PA, the appropriate keys for authentication of paging messages as well as for optional encryption of paging message parts are encapsulated. The PA either determines the keys on its own (if allowed from the provider) or contacts the AAAC.f, requesting appropriate keys. The lifetime of these individual keys terminates after a successful paging process and a mobile terminal’s active state registration. Before going dormant, the PA has to be registered with the HA, which is currently done by a BU message carrying the PA’s address within the alternate-CoA sub-option. This signalling flow for PA discovery as well as for implicit dormant registration and explicit dormant mode registration is illustrated in Figure 6 and Figure 7 respectively. Explicit registration is optional and will not be deployed in the Moby Dick test-bed. Implicit registration is more efficient and will be supported by the test-bed

D0302_M3-4.doc Final / M3.4 19.12.2002


AR1 AR2 AAA PA HAMN

1f

2

3

1c1d

1a

1b

1e

Figure 6 : Service discovery, SA establishment (preparation) and implicit Idle Mode registration

No. Message Parameters Remarks 1a Dormant Mode Request HoA, CoA, MAC address list (n *

3byte) or L3-ID, Paging area ID, Sequence #, reg. lifetime, NAI

Paging Agent discovery, implicit registration flag set.

AH carried for MN authentication at AR.

1b Dormant Mode Request HoA, CoA, MAC address list (n * 3byte) or L3-ID, Paging area ID, Sequence #, reg. lifetime, NAI

AH carried for AR authentication at PA.

1c Key Request NAI, HoA (or general: MN ID) Diameter message or proprietary approach.

1d Key Response Keys for authentication and encryption (PA-MN SA)

Diameter message or proprietary approach.

1e Dormant Mode Reply + status code, random #, paging registration keys (PA-MN SA),

paging process keys, PA address, lifetime, …

Includes AH for PA authentication at AR.

1f Dormant Mode Reply + status code, random #, paging registration keys (PA-MN SA),

paging process keys, PA address, lifetime, …

Includes AH for AR authentication at MN.

2 MIPv6 Binding Update Alternate CoA sub-option (PA address)

PA registration, possibly extended lifetime

3 BACK

Table 4: Messages for PA Discovery and Dormant Registration (implicit registration).

D0302_M3-4.doc Final / M3.4 19.12.2002


AR1 AR2 AAA PA HAMN

1f

2

4

3

5

1c1d

1a

1b

1e

Figure 7 : Discovery, SA establishment (preparation) and explicit Idle Mode registration

No. Message Parameters Remarks 1a Dormant Mode Request HoA, CoA, MAC address list (n *

3byte) or L3-ID, Paging area ID, Sequence #, reg. lifetime, NAI

Paging Agent discovery, implicit registration flag set.

AH carried for MN authentication at AR.

1b Dormant Mode Request HoA, CoA, MAC address list (n * 3byte) or L3-ID, Paging area ID, Sequence #, reg. lifetime, NAI

AH carried for AR authentication at PA.

1c Key Request NAI, HoA (or general: MN ID) Diameter message or proprietary approach.

1d Key Response Keys for authentication and encryption (PA-MN SA)

Diameter message or proprietary approach.

1e Dormant Mode Reply + status code, random #, paging registration keys (PA-MN SA), PA

address, lifetime, …

Includes AH for PA authentication at AR.

Status code indicates ‘explicit PA registration’.

1f Dormant Mode Reply + status code, random #, paging registration keys (PA-MN SA), PA

address, lifetime, …

Includes AH for AR authentication at MN.

Status code indicates ‘explicit PA registration’.

2 Dormant Mode Request HoA, CoA, MAC address list (n * 3byte) or L3-ID, Paging area ID,

Sequence #, reg. Lifetime

AH carried for MN authentication at PA.

3 Dormant Mode Reply + status code, random #, paging process keys, PA address,

reg. lifetime,…

Includes AH for PA authentication at MN.

4 MIPv6 Binding Update Alternate CoA sub-option (PA address)

PA registration, possibly extended lifetime

5 BACK Table 5 : Messages for PA Discovery and Dormant Registration (explicit registration).

D0302_M3-4.doc Final / M3.4 19.12.2002


4.8.3 Paging process A paging process is initiated from the PA on arrival of an initial user-data packet (paging trigger packet) at the PA. This (and further) initial paging trigger packets are to be buffered at the PA while the paging process re-activates a mobile terminal and initiates re-establishment of a routable link for this MN. For the paging process, the PA sends a Paging Request message to all ARs assigned to the registered paging area. The signalling message carries the paging process keys to each individual AR, which is to be used from local paging attendants to allow authentication of locally generated on-link paging messages at the MN. When a MN is being paged, it has to wake-up, re-establish full functionality to attach to the appropriate local link as well as to re-establish routing information. The acquired CoA has to be registered with the MN’s HA by means of the standard MIPv6 procedure as well as to be notified to the PA in the dormant mode registration (Dormant Registration with lifetime set to 0) to allow forwarding of buffered paging trigger packets.

AR1 AR2 AAA PA HAMN

5

4

6

1

2

3CoA acquisition and

standard attach(+ AA)

7

Polling thepaging area

Figure 8 : Paging an idle mobile terminal and active state registration

No. Message Parameters Remarks 1 Paging trigger packet ----- Initial user data packet,

buffered at PA. 2 Paging Request Random#, keys, [MAC list or

L3-ID] Include AH for PA

authentication at ARs. 3 On-link Paging Request Technology dependent format.

Assume IP paging first. No AH included, proprietary auth. and encr. mechanism

4 MIPv6 BU 5 MIPv6 BACK 6 Dormant Mode Request (0) CoA, registration lifetime=0 Dormant mode de-registration.

Notification of CoA allows packet forwarding. AH

included. 7 Dormant Mode Reply …, Status code Entry deleted. AH included.

Table 6: Messages for the IP paging process.

D0302_M3-4.doc Final / M3.4 19.12.2002


4.8.4 Paging area update When a mobile terminal has entered a dormant mode, its interface’s activity might be reduced, but scanning of paging area advertisement information must be possible to be detected, indicating that the mobile terminal has entered a new paging area. When a new paging area identifier has been received, the respective paging area ID has to be notified to the PA by means of paging area update signalling (Dormant Registration, having the paging area update flag set). This signalling is to be done on IP level when no support from access technology’s link-layers can be expected and requires that the mobile terminal sends an IP paging area update message to the PA. This IP signalling is to be allowed to go through the respective AR without previous establishment of a SA. Alternatively, the paging area update can be sent through the current AR's paging attendant. In the latter case, the temporarily acquired CoA is to be sent with the update message to allow replies to be forwarded from the current AR to the mobile terminal. In both cases, the disadvantage of not taking support from access technologies into account is that the mobile terminal has to enable full IP functionality for paging related signalling while being dormant. This procedure can be improved when getting support from access technologies by means of detecting a mobile terminal’s movement on link-layer (management/control frame messaging) and generation of the IP paging area update control messages on ARs, which are to be sent to the respective PA. This avoids IP activity on a mobile terminal for paging area update signalling to the PA while being dormant. This kind of technology specific support is allowed by the concept but to be detailed in the future for appropriate access technologies.

AR1 AR2 AAA PA HAMN

2

3

3

1

2

Paging area IDadvertisements

[RtAdv option orL2 beacon extension]

1a

No L2 interaction on acces link

With L2 interaction on acces link

L2 interaction withPaging attendant

in ARs

1b

Figure 9 : Paging Area update signalling

D0302_M3-4.doc Final / M3.4 19.12.2002


No. Message Parameters Remarks 1 RtAdv or L2 beacon …, paging area ID Paging area info

advertisement 2 Dormant Mode Request …, sequence #, paging area ID,

reg. lifetime Includes AH for PA

authentication at ARs. 3 Dormant Mode Reply …, status code, sequence #,

lifetime Status code to be checked,

paging key is the same. Not included unless requested.

1a L2 control msg. [technology specific] L2 interaction, AR generated IP Dormant Mode Request

message (paging area update). 1b L2 control msg. [technology specific] Arrival of IP Dormant Mode

Reply at AR triggers L2 interaction.

Table 7: Messages for Paging Area Updates signalling.

5. Software Module Specifications For each component listed below, part of the WP3 implementation, this section describes the module and its functionality. The interfaces and the message format are described in the next section. Unless explicitly mentioned: - everything that appears in this specifications will be implemented in the test bed, - anything that is not in the specifications will NOT be implemented.

D0302_M3-4.doc Final / M3.4 19.12.2002


5.1 Mobile Terminal This section gives the software specification of the different components of the Mobile Terminal. These include the Networking Control Panel (NCP), the Mobile Terminal Networking Manager (MTNM), the Enhanced IPv6 stack, the Fast Handover module, the Registration module, the Paging module, the WCDMA driver (Radio Channel Manager and Radio Convergence Function), the Monitoring Extensions to Ethernet and WLAN drivers and the Access Stratum. Below is a high level integrated view of the different components.

5.1.1 Overview of the different components This section splits the components identified before in sub-blocks, giving an overview of their role. The behaviour of these sub-blocks and their interactions will be detailed in the next chapter.

5.1.1.1 Networking Control Panel This module will be a graphical user interface, letting the user specify his preferences regarding Network Technologies (WCDMA, WLAN, Ethernet) and Handover execution (manual, automatic, both). The user will use it to request the beginning and the end of a network connection (AAA registration / deregistration). The user will also use it to start a manual handover. This module will also provide information about availability and quality of Network Technologies. It will be implemented as a user space program, using gtk for the GUIs. The behaviour of the different sub-blocks of the NCP will be detailed in the next chapter.

Application 1

Fast Handover module

NCP

MTNM Registration module

Application 2

Paging module

Enhanced IPv6 stack

DSCP marking software

Standard IPv6 stack

IPSec MIPL

Network device drivers

Ethernet WLAN WCDMA: RCM / RCF

Access Stratum Kernel space

User space

Protocol communication

Internal interface

AS on RG

WCDMA NDD on RG

AR

AR

AR

PA

Figure 10 : Mobile Terminal Software Architecture

D0302_M3-4.doc Final / M3.4 19.12.2002


5.1.1.2 Mobile Terminal Networking Manager This module will take the decision to execute handover (manual or automatic / fast or standard) and attach procedures; based on information received from the user (network preferences, handover preferences, manual handover request, explicit registration request) and information received from the networking devices (WCDMA, WLAN, Ethernet drivers). It will be implemented as a user space program (if needed, it will be implemented as a kernel module). The behaviour of the different sub-blocks of the MTNM will be detailed in the next chapter.

5.1.1.3 Radio Channel Manager This module will act as a generic radio driver, giving high level interfaces to open / close connections, send and receive IP packets, and get some feedback on the radio conditions. It will be implemented as a kernel module (RCM and RCF will be grouped in a same kernel module, namely a driver). The behaviour of the different sub-blocks of the RCM will be detailed in the next chapter.

5.1.1.4 Radio Convergence Function This module will act as a specific WCDMA driver, giving low level interfaces to open / close connections, manage data channels, send and receive IP packets, get some feedback on the WCDMA conditions, handle the broadcasting and paging channels. It will be implemented as a kernel module (RCM and RCF will be grouped in a same kernel module, namely a driver). The behaviour of the different sub-blocks of the RCF will be detailed in the next chapter.

5.1.1.5 Fast Handover module This Fast Handover Execution block is a stand-alone kernel module, implementing a fast handover mechanism, which follows the IETF Mobile IP WG Internet Draft ‘Fast Handovers for Mobile IPv6’. In order to obtain small handover interruption in combination with AAA and QoS, Context Transfer is considered within this module. The behaviour of this Fast Handover Module, its components and the relations to previously presented Moby Dick architectural components will be detailed in the next chapter.

5.1.1.6 Paging module The following figure illustrates the module implementing the required functions for basic IP paging support as specified for the Moby Dick environment.

IP Paging module

Dormant statewatchdog

IP Pagingengine

Figure 11 : MT IP Paging module, implementing the paging engine as well as a dormant state watchdog.

The module basically implements the IP paging engine, which is responsible for maintenance of the signalling state machine as well as for keeping the mobile terminal’s state (active or dormant) updated. Furthermore, an interface to the enhanced IPv6 protocol stack should allow suppression of Mobile IPv6 Binding Updates when being dormant as well as registration of the discovered Paging Agent with the

D0302_M3-4.doc Final / M3.4 19.12.2002


mobile terminal’s Home Agent. Since no enhanced dormant mode and paging support comes from network device drivers within this project on IP paging specification yet, the basic functionality of the IP Paging engine during a paging process with regard to the reception of paging related messages is to handle reception of IP Paging Request messages through the different interfaces. Standard interaction between IPv6 and device driver level supports the registration of IPv6 Solicited Node Multicast Addresses, which is necessary for the reception of IP Paging messages through the shared medium interfaces. For W-CDMA, the same mechanism will be deployed here, which is addressing the mobile terminal’s W-CDMA Solicited Node Multicast Address from the AR/RG. This address is to be derived out of the mobile terminal’s W-CDMA interface’s IMEI. The Dormant state watchdog is a function that should take the decision of when to enter the dormant mode. Furthermore, related signalling is initiated from this function, sending a notification to the paging engine when to enter dormant mode. For demonstration purposes, this function can be controlled manually via the NCP to allow for entering the dormant mode and active mode on request. An appropriate interface to the paging module will be implemented to allow for control from the NCP through the MTNM. Optionally, automatic dormant state and active state transition might be supported in the dormant state watchdog in future systems.

5.1.1.7 Registration module This module will take care of all the actions related to AAA, mainly the registration phase. It will also be used when a handover is required, but the Fast Handover cannot be used (inter-domain mobility, unexpected network connectivity loss).

5.1.1.8 Enhanced IPv6 stack

Enhanced IPv6 stack

Standard IPv6 stack

MIPL DSCP marking software

IPSec

Figure 12 : Enhanced IPv6 stack

The enhanced IPv6 stack will be based on the IPv6 stack of the Linux kernel 2.4.16, with the following extensions: • MIPL will be the patch 0.9.1 to the IPv6 stack, providing mobility extensions. MIPL is described in section 5.4.1 "MIPL". • SWAMP (Secure Wide-Area Mobility Package) combines IPSec and Mobile IPv6 implementations in the Linux kernel by providing kernel patches and user space programs. • DSCP marking software: will attribute a DSCP code to every outgoing IP packet, based on its type (signalling or data of type x, y, z …). It will be a patch to the IPv6 stack. • Fast handover functionality is provided by a ‘standalone’ kernel module (FHO module), including interface to the IPv6 stack of the kernel (e.g., sending of ICMPv6 packets) and to Mobile IPv6 (e.g., Binding Update management in case of FHO). The first version includes a filtering functionality in the IPv6 part of the kernel, in order to filter out WLAN Router Advertisements, which are received, because the WLAN ad-hoc mode is deployed and all Access Routers are configured to the same frequency channel. In later releases, this filtering functionality is moved to the WLAN driver; i.e., the WLAN Device Driver is modified in order to provide this filtering functionality.

D0302_M3-4.doc Final / M3.4 19.12.2002


The behaviour of the different sub-blocks of the Enhanced IPv6 stack will be detailed in the next chapter, if needed, except for the DSCP marking software which is described in the next section.

5.1.1.9 DSCP marking software

Here is a basic approach of the DSCP marking software that will have to be detailed by WP2: an application level module will communicate with the DCSP marking software, to provide a table matching DSCP codes with applications types (recognised by port numbers, and any other pertinent information). Thus every packet leaving the IPV6 stack will be marked with a DSCP code. There will be one DSCP for the signalling packets (standard IPv6 signalling packets like ICMP, and specific signalling packets, if any, used by mobility, AAA, QoS). There will be different DSCP for data packets, and the table provided by the application level module will be used to attribute them to the proper IPv6 packets.

5.1.1.10 Monitoring Extensions to Ethernet / WLAN driver For Ethernet, the purpose is to detect the presence of the Ethernet card, and to receive Router Advertisements. For WLAN, the purpose is to detect different Access Point, to retrieve the associated signal to level ratios, and to receive Router Advertisements. These behaviours should be implemented at a L2 level. The behaviour of these components will be detailed in the next chapter.

5.1.1.11 Access Stratum The Access Stratum provides services related to the transmission of data over the radio interface and the management of the radio interface.


WCDMA WLAN Ethernet

Application level module

DSCP matching

table

Application 1

Fast Handover module

Enhanced IPv6 stack

DSCP marking software

Standard IPv6 stack

MIPL

Application 2

Figure 13 : DSCP Marking Software

D0302_M3-4.doc Final / M3.4 19.12.2002


It includes the following Radio Interface protocols: the Physical layer, the data link layer, divided into 2 sub-layers: Medium Access Control (MAC) and Radio Link Control (RLC). In the user-plane, an additional service dependant protocol exists: the Packet Data Convergence Protocol (PDCP). The lowest sub-layer of the network layer consists of one protocol, called Radio Resource Control (RRC), which belongs to the control plane. The functions and services provided by the Access Stratum are detailed in section 5.1.9.

5.1.2 Networking Control Panel (NCP) The NCP has interactions only with the MTNM, as described in the figure below. It is split into the following sub-blocks.

5.1.2.1 Set Network Preferences block The user will set its preferences as follows: first choice x, second choice y, third choice z; with x,y,z in Ethernet, WCDMA, WLAN. Each time the preferences change, they will be transmitted to the Set Network Preferences block of the MTNM (to be used for automatic handover decision), via the message SET_NETWORK_PREFERENCES. These preferences will be stored in a configuration file (one per user). Each time a user requests a connection via the Explicit Connectivity Request sub-block, the data from this configuration file will be loaded and used as the default preferences. In particular, they will be used to establish the initial connection. Each time a user requests a de-connection via the Explicit Connectivity Request sub-block, the data will be saved in the configuration file.

5.1.2.2 Set Handover Preference block The user will set its preference as follows: automatic handover or manual handover or both. Each time the preference change, it will be transmitted to the Set Handover preference block of the MTNM, via the message SET_HANDOVER_PREFERENCE. This preference will be stored in a configuration file (one per user, same as previous one).

NCP

Set Network

Preferences

Manual Handover

Set Network

Preferences

Set Handover Preference


MTNM

Manual Handover

Network Environment

Infos

Network Environment

Infos

Explicit Connectivity

Request

Attach / Detach Procedure

Figure 14 : Networking Control Panel

D0302_M3-4.doc Final / M3.4 19.12.2002


Each time a user requests a connection via the Explicit Connectivity Request sub-block, the data from this configuration file will be loaded and used as the default preference. Each time a user requests a de-connection via the Explicit Connectivity Request sub-block, the data will be saved in the configuration file.

5.1.2.3 Network Environment Infos block This block will give information to the user, about the network availability. The Ethernet will be either absent or present. The WLAN will have with a certain signal to noise ratio. The WCDMA will have a certain signal level. These information will be transmitted by the Network Environment Infos block of the MTNM, via the message NETWORK_ENVIRONMENT_INFOS. If more than one WLAN or WCDMA Access Point is available, only information about the one currently in use by the IP stack, or if another technology is in use by the IP stack, the one with the higher signal level; will be transmitted by the MTNM to the NCP. At the user level, we only want a choice between different network technologies, not a choice among the same network technology. For research purpose, we may consider a choice between the same network technology for WLAN and WCDMA, to enable QoS driven handover for example, or to consider inter domain handover within the same technology. The information about network availability will be used during a manual handover, as explained in the associated block description. This block will also indicate which Network technology is currently used. This information is also transmitted by the Network Environment Infos block of the MTNM, via the message NETWORK_TECHNOLOGY_IN_USE (it will also contain the subnet prefix of the associated Access Router, to which we are currently attached). It will be updated when a change occurs, triggered by the Attach Procedure block, Manual Handover block, Automatic Handover block of the MTNM. This block will also enable the user to control the paging state. The message SET_PAGING_STATE sent to the MTNM will require entering the following paging state: either dormant or active. The MTNM will forward it to the paging module. This is the way the user is allowed to control paging state, for demonstration purpose. The message PAGING_STATE_INFO received from MTNM (originating from the Paging module) will indicate any change in the paging state, dormant or active.

5.1.2.4 Manual Handover block If the Handover preference is set to manual or both, the user can execute a manual handover, selecting among the 3 network technologies (Ethernet, WLAN, WCDMA), one that is available (but not the currently in use one). The information about the availability will be retrieved from the Network Environment Infos block. The Ethernet will always be considered as available, if present. The WLAN will be considered as available if its signal to noise ratio is higher than a predefined threshold (WLAN_threshold). The WCDMA will be considered as available if its signal level is higher than a predefined threshold (WCDMA_threshold). The user will have this information: current signal level. In a first implementation stage, the user won’t be able to execute a manual handover within the same technology. If WLAN is selected, and if a better "Access Point" than the current one is available (better signal level), the MTNM may generate (this will be detailed in the description of the MTNM) a fast handover between the two "Access Points", that is not seen by the NCP (the NCP only sees the signal level of the currently used "Access Point", which is always the best choice for this technology). The same applies to WCDMA. The order to execute a manual handover will be transmitted to the Manual Handover block of the MTNM, via the message MANUAL_HANDOVER_REQ.

D0302_M3-4.doc Final / M3.4 19.12.2002


An acknowledgement is expected from the MTNM, via message MANUAL_HANDOVER_ACK, with parameter status. As already stated, manual handover within the same technology for WLAN and WCDMA will be considered only as a research topic, and will not be implemented. In the case of automatic handover, a spontaneous acknowledgement will be sent by the MTNM, via message AUTOMATIC_HANDOVER_ACK, with parameter status. This will be used to make the user aware that an automatic handover has taken place.

5.1.2.5 Explicit Connectivity Request block The effective connection to the network (AAA procedures) will be explicitly triggered by the message START_NETWORK_CONNECTION, sent by the Explicit Connectivity Request block of the NCP to the Attach / Detach procedure block of the MTNM. The parameters will be the user login and password. An acknowledgement is expected from the MTNM, via message START_NETWORK_CONNECTION_ACK, with parameter status. The message TERMINATE_NETWORK_CONNECTION will be used to end the current network connection. It will also be sent by the Explicit Connectivity Request block to the Attach / Detach procedure block (the handling of this message will imply no AAA action). No parameters will be needed. An acknowledgement is expected from the MTNM, via message TERMINATE_NETWORK_CONNECTION_ACK, with parameter status.

5.1.3 Mobile Terminal Networking Manager (MTNM) The MTNM has interactions with the NCP, the different device drivers, the fast handover module, the registration module and the paging module. It is split into the following sub-blocks.

MTNM

Network Environment

Infos

Attach Procedure

Automatic Handover

Manual

Handover

Set Network

Preferences


Paging

Figure 15 : Mobile Terminal Networking Manager

D0302_M3-4.doc Final / M3.4 19.12.2002


5.1.3.1 Set Network Preferences block The following schema can be used to illustrate the description of the 3 first sub-blocks.

The MTNM will update its Network preferences each time it receives a request from the NCP, via the message SET_NETWORK_PREFERENCES. These preferences will be expressed as for the NCP: first choice x, second choice y, third choice z; with x,y,z in Ethernet, WCDMA, WLAN.

5.1.3.2 Set Handover Preference block The MTNM will update the Handover preference each time it receives a request from the NCP, via the message SET_HANDOVER_PREFERENCE. This preference will be expressed as for the NCP: automatic, manual or both. This information will be used to authorize automatic handover, if the preference is automatic or both.

5.1.3.3 Network Environment Infos block This block will analyse information received from the Network device drivers, store them for use by the automatic handover decision algorithm, attach procedure; and transmit them to the NCP (as already explained in the description of the corresponding block in the NCP). The messages received from the device drivers will be ETHERNET_INFO, WCDMA_INFO and WLAN_INFO. The message sent to the NCP will be NETWORK_ENVIRONMENT_INFOS. First of all, we will not consider every router advertisement or signal level indications received by the different device drivers. Instead, we will limit ourselves to a “reasonable” time interval between two consecutive messages from the device drivers to the Network Environment Infos block. This will avoid too frequent handover (backward and forward) if a user moves around the border of two radio coverage areas, in the case of WLAN or WCDMA. For the three possible network technologies, if we don’t receive an info message at the time we expect one, we will consider that the technology is not available. For Ethernet, the message INTERNET_INFO will contain the following information: absent or present, IPv6 address of the corresponding Access Router, which will be stored locally. The information absent or present will be transmitted to the NCP, if it changes, via message NETWORK_ENVIRONMENT_INFOS.

MTNM Set

Network Preferences

Network Environment

Infos


WCDMA WLAN Ethernet

Set HandoverPreference

NCP Set

Network Preferences

Manual Handover

Network Environment

Infos



Request

Figure 16 : Interactions between MTNM / NCP

D0302_M3-4.doc Final / M3.4 19.12.2002


For WLAN, the message WLAN_INFO will contain the following information: a list of [signal to noise ratio, IPv6 address of the corresponding Access Router, IPv6 subnet prefix of Access Router]. Locally, we will keep up to two entries: the current WLAN “access point” if this technology is in use, and the best candidate for handover (which can be different from the currently used “access point”). First we will erase the current best candidate for handover, and the following algorithm will be applied to each element of the list:

• If WLAN is the currently used Network technology and we receive from the WLAN device driver an update with the same identification and a different signal to noise ratio, we update the current signal to noise ratio in the MTNM and send an update message NETWORK_ENVIRONMENT_INFOS to the NCP, with the new signal level.

• If WLAN is the currently used Network technology and we receive from the WLAN device driver an update with a different identification, we compare it to the best candidate for handover and keep the one with the highest signal to noise ratio.

• If WLAN is not the currently used Network technology and we receive from the WLAN device driver an update, we compare it to the best candidate for handover and keep the one with the highest signal to noise ratio. In this case, when all candidate will have been considered, we will send an update message NETWORK_ENVIRONMENT_INFOS to the NCP, with the new signal level.

For WCDMA, the message WCDMA_INFO will contain the following information: a list of [signal level, cell Id and IPv6 address of the corresponding Access Router]. We also keep up to two entries locally: current WCDMA “access point” if this technology is in use, and best candidate for handover. And the same algorithm as for WLAN applies. By construction, the WCDMA driver will have the capability to produce the information needed (cell id / signal level / Access Router IPv6 address) and transmit them to the MTNM. An extension will be required for the WLAN driver, to retrieve the information needed (IPv6 address of Access Router - signal to noise ratio – IPv6 subnet prefix) and transmit them to the MTNM. This extension has been implemented on the Prism2 driver for the SMC WLAN cards. For Ethernet, an extension to the driver will also be needed, to monitor the Router Advertisements received on this interface (even when it is not connected to the IP stack). Here, we have two possible solutions. First one: use a specific tool to discover availability / unavailability of the Ethernet link, and retrieve router advertisements, although this facility might not be offered by all cards. Second one: connect to Ethernet driver from user space with a raw socket every N seconds, and wait until a Router Advertisement is received (with a timeout to declare the link unavailable). The specific tool proposed for the first solution has been evaluated and works fine. Therefore the first solution will be implemented. The Network Environment Infos block will also be aware of the current technology in use, and will warn the NCP when a change occurs (Attach Procedure, Manual Handover, and Automatic Handover), via the message NETWORK_TECHNOLOGY_IN_USE (this message will also contain the IPv6 subnet prefix of the currently used Access Router). This block will also have the responsibility, when possible, to detect that the layer two connectivity has been lost “unexpectedly”, for the network technology currently in use, or about to be used during a fast handover.

• For WCMDA, it means receiving the message LOST_WCDMA_CONN from the RCM, indicating that the radio connection has been lost; or receiving a message WCDMA_INFO from the RCM, with a signal level lower than WCDMA_lower value.

• For WLAN, it means receiving a message WLAN_INFO from the monitoring extension of the WLAN driver, with a signal level lower than WLAN_lower value.

• For Ethernet, it means receiving the message ETHERNET_INFO, with information “Ethernet not present”.

If the layer two connectivity has been lost for the currently in use network technology, the Automatic Handover procedure should be triggered to select a new Network Technology among those available (the current one will be marked as unavailable). But as we have lost connectivity with current Access Router, the Fast Handover procedure cannot be used. A “regular Handover” will have to be triggered, that is to

D0302_M3-4.doc Final / M3.4 19.12.2002


say a registration procedure in a first implementation approach (see Handover Execution block for more details). If the layer 2 connectivity has been lost for the target technology during a Fast Handover procedure, this procedure should be aborted via a message ABORT_HANDOVER, sent to the Fast Handover module (see Handover Execution block for more details). This will not be implemented, because it complicates the whole process, and we expect the Fast Handover to be fast enough for the target technology to stay in acceptable L2 conditions.

5.1.3.4 Attach Procedure block

The “attach procedure” block can be triggered in these three first cases:

• First case: the message START_NETWORK_CONNECTION has been received from the Explicit Connectivity Request block of the NCP, with parameters user login and user password. In this case, the message START_NETWORK_CONNECTION_ACK should be sent back to the NCP, after the attach procedure has been executed, with the status as parameter. This first case is the initial registration procedure, for a user that has not been authenticated and authorized yet.

• Second case: a handover has been decided by the Manual or Automatic Handover sub-block, but it cannot be fast (inter domain handover), so an attach procedure is requested.

• Third case: the layer two connectivity has been lost unexpectedly as explained in the Network Environment Infos sub-block, and the Automatic Handover sub-block requests an attach procedure.

In the first case, an initial step will be to wait until the Network Environment Infos block has received information from the different device drivers. Then to select a network technology, using the information

MTNM Set

NetworkPreferences

Network Environment

Infos

Registration module Network device drivers

WCDMA WLAN Ethernet

Attach Procedure


NCP Set

Network Preferences

ManualHandover

Network Environment

Infos



Request

Figure 17 : Attach Procedure block

D0302_M3-4.doc Final / M3.4 19.12.2002


stored in the Set Network preferences block. The technology associated to each preference (from the first to the third) will be analysed, based on the information from the Network Environment Infos block, and selected or rejected according to the following rules: Ethernet is selected if present, WLAN and WCDMA are selected if present and signal to noise ratio for WLAN, signal level for WCDMA, is higher than a predefined threshold (respectively WLAN_threshold and WCDMA_threshold). For example, if network preferences are first WLAN, second WCDMA and third Ethernet; and if WLAN signal to noise ratio is lower than WLAN_threshold, but WCDMA signal level higher than WCDMA_threshold and Ethernet is present: WLAN is examined first and rejected, WCDMA is examined second and selected. In the two other cases, the target network technology will already have been chosen, by the manual or automatic handover block. The next step is to assure the L2 connectivity via the device driver of the selected technology. This step will be detailed in chapter ‘Handover Execution’, for each of the 3 available technologies. One can refer to this chapter for the detailed procedure. Then link the IP stack to the device driver of the selected Network technology. The final step is to send the appropriate message to the Registration module, to trigger the AAA mechanisms involved in the Attach Procedure: the message START_REGISTRATION will be used, with parameters: Home Address and CoA of MT, Access Router IP address, user login and user password. An acknowledgement message will be sent from the Registration module to the MTNM, REGISTRATION_ACK, to give the status of the attachment. If it is negative, the global procedure can be restarted after a temporisation. The “attach procedure” block can also be triggered to end a user session, when the message TERMINATE_NETWORK_CONNECTION has been received from the Explicit Connectivity Request block of the NCP, with no parameter. No AAA mechanism is involved in this case, so the registration module will not be involved in this case. The L2 resources of the current technology in use will be released if needed (see chapter ‘Handover Execution’). Then the message TERMINATE_NETWORK_CONNECTION_ACK should be sent back to the NCP, after the detach procedure has been executed, with the status as parameter.

D0302_M3-4.doc Final / M3.4 19.12.2002


5.1.3.5 Manual Handover block

When the command MANUAL_HANDOVER_REQ is received from the Manual Handover block of the NCP (only when handover preference is set to manual and both mode), the decision to execute the Handover is taken immediately, because every necessary control have been done at the NCP level (in particular, the signal levels for WLAN and WCDMA are higher than the predefined thresholds WLAN_threshold and WCDMA_threshold). If the handover preference is set to manual, handover among two different “access point” of the same Network technology will also be automatically considered, for WLAN and WCDMA (as explained in the description of NCP). Every n milliseconds, the following actions will be taken, if the current Network Technology is WLAN or WCDMA, and only if the current signal level is lower to a predefined threshold (WLAN_threshold and WCDMA_threshold respectively: we don’t want to trigger handover too often if the current connection is good enough) : (we take the example of WLAN, but the same applies to WCDMA) we compare the information in Network Environment Infos block for the current WLAN “access point” and the WLAN “access point” best candidate for handover. If current WLAN signal to noise ratio + delta_WLAN < best candidate WLAN signal to noise ratio, a decision for handover is taken. We introduce delta_WLAN, because we don’t want to handover to a WLAN new “access point”, which signal level is not significantly better. (The same relation is introduced for WCDMA: WCDMA signal level + delta_WCDMA < best candidate WCDMA signal level).

NCP Set

Network Preferences

ManualHandover

Network Environment

Infos

MTNM Set

Network Preferences

Network Environment

Infos

Fast Handover module Network device drivers

WCDMA WLAN Ethernet

Manual Handover




Request

Figure 18 : Manual Handover block

D0302_M3-4.doc Final / M3.4 19.12.2002


When the decision to execute a handover is taken, we enter in a phase common to manual and automatic handover, which we will call Handover Execution, and that will be described later.

5.1.3.6 Automatic Handover block

Every n milliseconds, the following actions will be taken: The automatic handover will be considered if the handover preference, in the Set Handover preference block, is set to automatic or both. The automatic handover decision algorithm will consider the current Network technology used, information from the Set Network Preferences block and from the Network Environment Infos block; to decide if a handover should occur. The following table gives the different possibilities for the Network preferences, and it will be used to illustrate the decision algorithm.

Network Preferences WCDMA 1 WCDMA 2 WCDMA 3 WLAN 1 Ethernet 3 (case I) Ethernet 2 (case II) WLAN 2 Ethernet 3 (case III) Ethernet 1 (case IV) WLAN 3 Ethernet 2 (case V) Ethernet 1 (case VI)

Given the current technology in use, the Network technologies with a higher preference level will be considered from top to bottom; and if one is appropriate, the handover decision will be taken. For example, in case IV, if the current technology in use is WLAN, only Ethernet will be considered as a potential handover technology. And in case V, if the current technology in use is WLAN, WCDMA will be considered first, and Ethernet second, as a potential handover technology. In the case of WLAN and WCDMA, if no Network technology with a higher preference level is selected for handover, a handover within the same Network Technology will be considered, to a new sub-network;

MTNM Set

Network Preferences

Network Environment

Infos

Fast Handover module Network device drivers

WCDMA WLAN Ethernet

AutomaticHandover


Figure 19 : Automatic Handover block

D0302_M3-4.doc Final / M3.4 19.12.2002


but only if the signal level is lower than a predefined threshold (WLAN_threshold and WCDMA_threshold respectively). The 3 following situations can happen:

• Ethernet is the current Network Technology: higher preference level Network technologies are considered.

o For WCDMA, a decision for handover is taken if the signal level of best candidate for handover is higher than WCDMA_threshold.

o For WLAN, a decision for handover is taken if the signal level of best candidate for handover is higher than WLAN_threshold.

• WLAN is the current Network Technology: higher preference level Network technologies are considered.

o For WCDMA, a decision for handover is taken if the signal level of best candidate for handover is higher than WCDMA_threshold.

o For Ethernet, a decision for handover is taken if this technology is present. o If no higher preference Network technology is selected, current signal level is lower

than WLAN_threshold, a best candidate for WLAN “access point” handover is present in the Network Environment Infos, and the signal levels follow this relation: current WLAN signal level + delta_WLAN < best candidate WLAN signal level, a decision for handover is taken. We introduce delta_WLAN, because we don’t want to handover to a WLAN new “access point”, which signal level is not significantly better.

• WCDMA is the current Network Technology: higher preference level Network technologies are considered.

o For WLAN, a decision for handover is taken if the signal level of best candidate for handover is higher than WLAN_threshold.

o For Ethernet, a decision for handover is taken if this technology is present. o If no higher preference Network technology is selected, current signal level is lower

than WCDMA_threshold, a best candidate for WCDMA “access point” handover is present in the Network Environment Infos, and the signal levels follow this relation: current WCDMA signal level + delta_WCDMA < best candidate WCDMA signal level, a decision for handover is taken. We introduce delta_WCDMA, because we don’t want to handover to a WCDMA new “access point”, which signal level is not significantly better.

In the case of WLAN and WCDMA, if no higher or same preference level Network technology is selected, and if the current signal level is lower to the predefined threshold (respectively WLAN_threshold and WCDMA_threshold), lower preference level network technologies can be considered if we are in both mode, by executing a manual handover via the NCP (this case will not be considered in automatic mode, as it can lead to an uncontrolled succession of automatic handovers between different technologies). The same criteria per current technology in use will be considered, as when higher preference level Network technologies are considered. When a decision to execute handover is taken, we enter in a phase common to manual and automatic handover, which we will call Handover Execution, and that will be described later.

5.1.3.7 Handover Execution This mechanism is a common part of the Manual and Automatic Handover blocks. The first thing is to decide whether we are about to execute an intra or inter domain handover. The solution proposed is to use the Router Advertisements to convey this information: two bits in the IP subnet prefix will identify the domain. The MTNM memorizes the current domain, and extracts the new domain from the IP address of the target Access Router, and makes the decision by comparing them. In case we are currently in Paging Dormant mode, we will only execute a L2 handover (no FHO or registration procedure). So we will only go through the procedure executing Layer 2 handover, which is detailed below in the fast handover description. First we consider intra-domain handover, which will result in a fast-handover.

D0302_M3-4.doc Final / M3.4 19.12.2002


The MTNM sends the message START_FHO to the Fast Handover module, to request fast handover execution, with the IP address of the new Access Router, the IP address of the old Access Router, the new interface name, the old interface name, as parameters. The Fast Handover module will prepare the fast handover by contacting the old Access Router, and will receive an answer when everything is ready. For the moment, we consider the case where the FHO can be executed. The Fast Handover module will send the message L2_REQ, to request the MTNM to execute the layer 2 handover. This will require:

• If Ethernet is the new L2 technology, nothing needs to be done. • If WLAN is the new L2 technology, the message USE_WLAN_AR must be sent to the WLAN

driver, with parameters IPv6 address of new Access Router and IPv6 subnet prefix of new Access Router. The acknowledge message USE_WLAN_AR_ACK will be received from the WLAN driver, with parameter status.

• If WCDMA is the new L2 technology, the message OPEN_WCDMA_CONN must be sent to the WCDMA driver, with parameters cell Id of selected Radio Gateway, Home Address and CoA of MT. The acknowledge message OPEN_WCDMA_CONN_ACK will be received from the WCDMA driver, with parameters local_connection_reference and status.

• If Ethernet is the old L2 technology, nothing needs to be done. • If WLAN is the old L2 technology, nothing needs to be done. • If WCDMA is the old L2 technology, the message CLOSE_WCDMA_CONN must be sent to

the WCDMA driver, with parameter local_connection_reference. The acknowledge message CLOSE_WCDMA_CONN_ACK will be received from the WCDMA driver, with parameters local_connection_reference and status.

• If WCMA is the old and new L2 technology, we will use only the message OPEN_WCDMA_CONN, with a specific parameter (fho_optimisation). The WCDMA driver will first close the old connection, then open the new one, and send the acknowledge message OPEN_WCDMA_CONN_ACK.

If the L2 handover was successful, the MTNM will “link” the IP stack to the new L2 driver and send message L2_ACK to the FHO module, with status OK. If the L2 handover was not successful, the MTNM will send message L2_ACK to the FHO module, with status NOT OK; and will request an automatic handover (as we have lost L2 connectivity), that will be “slow” (new registration). If the L2 handover was successful, the MTNM will wait for the answer of the Fast Handover module, FHO_ACK, which will be either OK or NOT OK. If it is OK, we are done. If it is NOT OK, at this point, we cannot go back and the MTNM will request an automatic handover, that will be “slow” (new registration). We have to consider the case when the FHO module answers directly to message START_FHO with message START_FHO_ACK, with a negative status. This situation will happen when there are no available QoS resources on the new Access Router. In this case, we are still connected with the old Access Router, and we can try another Fast Handover manually or automatically, based on the current user preferences. For this, we will have to mark the Access Router that we have tried as unavailable for the next choice. Then we consider inter-domain handover or the case where the Fast Handover procedure cannot apply because the layer two connection has been lost, as explained in the chapter on Network Environment Infos block. In this case, a “slow” handover should be used, which for the moment is identical to the registration scenario. The attach procedure sub-block will take care of this handover procedure, which will basically consist in a registration procedure (one of the first thing to do will be to establish a L2 connection to the selected Access Router, as explained in details before, for the fast handover procedure).

D0302_M3-4.doc Final / M3.4 19.12.2002


5.1.3.8 Paging block

The Paging sub-block of the MTNM will basically perform the requests received from the Paging module. Upon reception of the message INFO_REQ from the Paging module, it will retrieve the appropriate information from the Network Environment Infos sub-block of the MTNM, and send them to the Paging module via message INFO_REPLY. These will be: the IPv6 address of the current Access Router, and the MAC address of the different available device drivers (Ethernet, WLAN, WCDMA upon availability). Upon reception of the message SET_STATE_INFO, with parameter state, it will:

• If state is dormant, forward the information to the Network Environment Infos sub-block of MTNM, so that every time a handover is needed, it will be only a Layer 2 handover (no Fast Handover or Registration signalling will be involved).

• If state is active, exit the paging dormant mode by contacting the Attach Procedure sub-block, to trigger a new Registration.

This information will also be transmitted to the Network Environment Infos sub-block of NCP, via message PAGING_STATE_INFO. The Paging sub-block of the MTNM can also receive a request from the Network Environment Infos sub-block of NCP, via message SET_PAGING_STATE, with parameter state (active or dormant). This is the way the user is allowed to control paging state, for demonstration purpose. This request will be transmitted to the paging module via message NOTIFY_MSG.

MTNM

Network Environment

Infos

Paging module

Paging

Attach Procedure

NCP Set

Network Preferences

Manual Handover

Network Environment

Infos



Request

Figure 20 : Paging block

D0302_M3-4.doc Final / M3.4 19.12.2002


5.1.4 Fast Handover module The Fast Handover module must be installed on every Access Router and Mobile Node wanting to exchange FHO messages in the Moby Dick scenario. It provides the complete Fast Handover IP mechanism and signalling for fast intra-domain handover. The module must not be triggered for inter-domain handover, since administrative domain distinction within the Moby Dick trial is provided in the MTNM by comparison of the last two bits of the IPv6 network-prefix (as described in chapter 0). The inter-domain handover will be handled like a new registration, since this kind of handoff may not be fast, because the home domain must be contacted. The following figure sketches the relations of the Fast Handover Linux Kernel Module with the related Moby Dick components on the Mobile Terminal, i.e., the MTNM, IP/MIPL stack and the network device drivers.

SetHandover Preference

Enhanced IP stack and Mobile IP stack


WCDMA WLAN Ethernet

MTNMSet

Network Preferences

NetworkEnvironment

Infos

Automatic / Manual

Handover

RCF Fast Handover Module

WCDMA Connection Manager

Wcdma Infos

Open / Close

Fast Handover Execution

Context Transfer

Figure 21: FHO module and its interfaces

The Fast Handover module has been implemented as a Linux kernel module, because this provides most possible independence from the IPv6 and Mobile IPv6 stack and at the same time provides fast message processing. The fast handover signalling messages are sent via the enhanced IPv6 stack, i.e., deploy the sending functionality of this stack, and therefore this module does not require awareness of the current access technology. Since MTNM module is in user space and FHO module is in kernel space, as specified before, to exchange messages between them we deployed the character device technology. The character device is a special device which allows the communication between user space and kernel space; the following figure depicts the behaviour of FHO module.

D0302_M3-4.doc Final / M3.4 19.12.2002


USERSPACE

MTNM

KERNELSPACE

FHO

START_FHO

L2_ACK

FHO_ACK

L2_REQ

-Sending Router Soll. Proxy-Receiving Proxy Router Adv-Sending Fast Binding Update-Receiving Fast Binding Ack

ConfiguringLayer 2 handover

-Fast Handover Execution

Figure 22: User space/Kernel space communication

The Fast Handover Module waits for the START_FHO message from the MTNM in order to trigger the fast handover mechanism (independently if the handover was triggered automatically or manually). Once the fast handover trigger is received, the following message flow is executed:

Figure 23 : FHO exchange of messages.

Mobile Node

New Access RouterOld Access Router

Router solicitation Proxy

Fast Neighbour advertisement

STARTFAST_HANDOVER message from MTNM

create new CoA

check new CoA

Diconnect

Connect disconnected time

Proxy Router Advertisement Handover Initate

Handover Acknowledgement Fast Binding Update

Fast Binding Acknowledgement

Fast Binding Acknowledgement

ICMP message

get the new CoA

D0302_M3-4.doc Final / M3.4 19.12.2002


According to what is specified in section 0, the module performs two main tasks:

• on the oldAR when the Router Solicitation Proxy message is received FHO module recovers AAA context from AAA attendant and sends it, as data attached in the Handover Initiate message, to the newAR. In parallel a request for QoS availability is send to QoS attendant.

• on the newAR, once the Handover Initiate message has been handled, FHO module waits for a response from QoS attendant about resource availability: in case of positive answer it relies the AAA context to the AAA attendant, otherwise this step is just skipped. In both conditions an Handover Acknowledgement is send back to the oldAR in order to inform the MN (MTNM) about the possibility or not to perform handover.

Mobile IPv6 messages exchanged between MN-oldAR-newAR are realized via new types of ICMP messages, which are created by the Fast Handover Module and sent via ‘standard’ IPv6 kernel functions (i.e., interface Fast Handover Module and IPv6 stack). . The “layer 2” handover is triggered via the interface with MTNM module (i.e. character device); the messages L2_req (layer 2 handover request) and L2_ack (layer 2 handover acknowledgement) are exchanged between MTNM module and FHO module after receiving the message Fast Binding Acknowledgement on the MN. The last message (FHO_ACK) informs MTNM module about the result of the handover: if all the steps described are well performed the returned status is safe, otherwise, if the handover is not possible, (e.g. a lack of resources on the new link) MTNM will try to use another technology (if available) or to access another link.

5.1.5 Paging module

IP Paging module

Dormant state watchdog

IP Paging engine

Enhanced IPv6 proto

MTNM

Common ID handler

Signaling state machine

MT dormant state manager

IPv6

MIPv6

Figure 24 : Paging module

5.1.5.1 Dormant state watchdog The dormant state watchdog block is responsible for taking the decision on when to enter the dormant mode. Basically, entering a dormant mode depends on the following parameters:

• No session should be open. • No session should have been opened for some configurable amount of time.

D0302_M3-4.doc Final / M3.4 19.12.2002


• All Binding Cache entries, maintained in remote Correspondent Nodes, should have been expired.

To check the Binding Cache entries and respective timers indicating the individual entry’s validity, this block needs to communicate to the MIPv6 related binding cache block of the enhanced IPv6 protocol stack, which might be implemented as an option. Expiration of local binding cache entries can be a basic measure that no communication is active, hence, the binding of the mobile’s CoA hasn’t been updated on a remote CN. When a configurable amount of time has been expired after all remote bindings have been expired, the dormant state watchdog initiates dormant state transition, notifying the MT dormant state manager block. However, for demonstration purposes, the dormant state transition is triggered manually from the NCP and indicated to the paging module through the MTNM and the MT dormant state manager. This allows dormant registration without waiting for expiration of remote binding entries. Optionally, automatic dormant state transition might be supported in the dormant state watchdog, based on timers and remote CNs' binding cache entries' lifetime for the respective MN. Also, in case of mobile terminal initiated active registration with the network is to be shown, this is also done via the NCP for demonstration purposes. Optionally, detection of packets to be sent from an application and automatic active registration initiation might be supported.

5.1.5.2 Common ID handler Independent of L2 identifiers for addressing or paging purposes, the IP paging concept deploys a common paging identifier, allowing the MT to be identified independent of access technology specifics. A structure for a common IP paging identifier has been proposed in [2], allowing paging attendants implemented with ARs to map the generic IP paging request messages to access technology specific addressing and to build IPv6 Solicited Node Multicast Addresses for individual access technologies and their respective interface identifiers. On IP level, this common identifier is used to address and to identify mobile terminals on IP layer. According to the specification in [2], MAC address parts of each interface implemented in the mobile terminal are included in the common paging ID, which is to be built by the common ID handler block. To gather information on each interface’s MAC address, the common ID handler block requests a list of interface addresses from the respective MTNM entity. The derivation of the common paging ID is to be done on module loading time, assuming that the interfaces do not change afterwards. An enhanced mechanism could trigger the common ID handler to build a new ID when a new interface has been brought up in the mobile terminal. To take hot-plugging of networking interfaces into consideration for future systems, the Common ID handler requests MAC addresses of available access interfaces each time the mobile enters dormant mode. This allows always for updated and valid MAC addresses to be incorporated into the common paging identifier. In addition to MAC address info of implemented access interfaces, the MTNM provides the Common ID handler with information on the current Access Router, since this information is kept updated in the MTNM.

5.1.5.3 MT dormant state manager The mobile terminal dormant state manager is the high-level entity for maintenance of dormant/active state as well as for initiation of the signalling procedure for state transition purposes. On receipt of a notification from the dormant mode watchdog to enter the dormant mode, the dormant state manager initiates the signalling procedure by contacting the signalling state machine block. After the Paging Agent discovery phase and the dormant registration procedure have been initiated, an intermediate state should be entered, indicating that the mobile is going to enter a dormant mode. Active or passive session initiation while being in this intermediate state would cause immediate re-establishment of active state behaviour. When the dormant registration has completed successfully, active session initiation would cause initiation of the normal dormant de-registration procedure. Incoming packets can reach a dormant mobile terminal, which has entered dormant state before, only after a successful paging and de-registration procedure, including re-establishment of system information. Furthermore, this block should store information on the discovered Paging Agent address.

5.1.5.4 Signalling state machine The signalling state machine block has the responsibility to handle the PA discovery and the registration procedure, therefore representing an abstraction layer between the dormant state manager and the actual signalling procedure. High granularity states should be maintained within this block. To initiate the signalling procedure for dormant mode registration, the respective notification comes always from the ‘high-level’ dormant state manager. In case of having entered the dormant mode before, an incoming paging request is directly to be processed from the signalling state machine, common paging ID matching

D0302_M3-4.doc Final / M3.4 19.12.2002


is to be checked with the common paging ID block and high-level actions are to be requested from the dormant state manager.

5.1.6 Radio Channel Manager The Radio Channel Manager is the generic part of the Radio driver. It provides a generic interface to the MTNM and to the enhanced IPv6 stack. It provides also a generic interface to the lower layer of the Radio driver: the Radio Convergence Function. It is split into the following sub-blocks.

RCM

Packet Transmission

Data Packet

Control

Packet

Packet Transmission

Data Packet

Control

Packet

Packet Reception

Control Packet

Data Packet

Packet Reception

Control Packet

Data Packet

Radio Connection Manager

Radio

Infos Open / Close

Conn


Radio Infos

Open / Close

Conn

Figure 25 : Radio Channel Manager

D0302_M3-4.doc Final / M3.4 19.12.2002


5.1.6.1 Radio Connection Manager block

Figure 26 : Radio Connection Manager Block in the Mobile Terminal

5.1.6.1.1 Radio Infos sub-block The Radio Infos sub-block transmits radio information received from the RCF to the Network Environment Infos block of the MTNM, via the message WCDMA_INFO. It could also transmit a request for radio information from the MTNM to the RCF, if this was needed (the Access Stratum provides this functionality: query proactively radio conditions). In our implementation, this service is not needed and will not be implemented. The precise format of the radio information is transparent to the RCM layer, but is defined between the RCF and the MTNM. 5.1.6.1.2 Open / Close Connection sub-block The Open / Close Connection sub-block manages the Radio Connections. It transmits a request received from the MTNM, via message OPEN_WCDMA_CONN, to open a connection, to the RCF. There will be 4 parameters: cell id of the Radio Gateway we want to connect to, Home Address of the MT, CoA of the MT, Fast Handover optimisation flag (if we are performing a fast handover between two Radio Gateways). It transmits the report status from the RCF of the open connection command, via message OPEN_WCDMA_CONN_ACK, to the MTNM. There will be two parameters: local connection reference and status. It transmits a request received from the MTNM, via message CLOSE_WCDMA_CONN, to close a connection, to the RCF. There will be one parameter: local connection reference.

RCM Packet Reception

Control Packet

Data Packet

Data Channel Mngt Send /

Receive

Data

Open / Close

Data Chanels

MTNM Administration, reconfiguration,

of drivers

Network Environment

Infos

Radio Infos

Open /

Close

Conn


Wcdma Infos

Open /

Close

Conn

RCF

AS

Data Packet

Control

Packet

Packet Transmission

Send /

Receive

Data

Control Channel Mngt


Paging

Enhanced IPv6 stack

Paging module

D0302_M3-4.doc Final / M3.4 19.12.2002


It transmits the report status from the RCF of the close connection command, via message CLOSE_WCDMA_CONN_ACK, to the MTNM. There will be two parameters: local connection reference and status. It also transmits any report from the RCF that the connection has been lost, to the MTNM, via message LOST_WCDMA_CONN. There will be one parameter: local connection reference. 5.1.6.1.3 Paging There is no specific entity in the RCM module to handle paging. The paging entity in the RCF directly transmits the IP paging packets to the Control Packet sub-block, of the Packet Reception block, of the RCM. These IP paging packets will be passed to the IPv6 stack, and will automatically reach the Paging module.

5.1.6.2 Packet Transmission block

The connection must have been opened by the Radio Connection Manager sub-block, before any IP packet can be transmitted (if it’s not the case, they will be dropped, but this should never happen as the WCDMA driver is “linked” to the IP stack only when the radio connection is established). An open connection means that the Access Stratum has established all the associated radio control channels, but that no radio bearer has been pre-established. In case of connection loss, we do not buffer the received IP packets, as it will take time to re-establish the connection (we will have to perform the whole registration process), and we do not even know if we will still be using the WCDMA, or if the MTNM will decide to use another technology (WLAN / Ethernet). The only case when we will probably want to buffer IP packets is during a fast handover between two Radio Gateways, during the phase between the closing of the old connection and the opening of the new

Enhanced IPv6 stack

RCM Packet Reception

Control

Packet

Data

Packet

Data Channel Mngt Send /

Receive

Data

Open / Close

Data Chanels


Radio Infos

Open /

Close

Conn

RCF

AS

Data

Packet Control

Packet

Packet Transmission

Send /Receive

Data


Wcdma Infos

Open / Close

Conn


Paging

Figure 27 : Packet Transmission block

D0302_M3-4.doc Final / M3.4 19.12.2002


connection; as the WCDMA driver is constantly “linked” to the IP stack and can receive packets at any time during this process. The Packet Transmission block receives IP packets from the enhanced IPv6 stack. It will determine if it is an IP signalling packet or an IP data packet, by analysing its DSCP code (the IP signalling packets will have a specific DSCP code). The IP signalling packets are transmitted directly to the Control Channel Management block of the RCF (with the local connection reference). The data packets are analysed to perform the mapping between IP QoS classes and radio bearers / radio QoS classes: based on the DSCP of the IP packet, a radio bearer is selected, with a radio QoS class associated to it. The RCM manages a fixed number of radio bearer, each one associated to one of the radio QoS class available (see document from Eurecom “Interface primitives provided to upper layers (NAS)”). This mapping is performed on the Radio Gateway, not on the Mobile Terminal. If the radio bearer is not yet established, a request is made to the Data Channel Management block of the RCF to establish it, with the local connection reference, the DSCP code, the source and destination address of the IP packet, as parameters. An answer is expected from the RCF, to give the status of this operation, upon which the radio bearer is declared established or not. The answer will contain the original DSCP code, the radio bearer Id and a SAP Id as parameters. If the bearer is established, the IP data packets can be transmitted to the Data Channel Management block of the RCF (with the radio bearer Id and SAP id), to be sent on the radio bearer by the AS. Two requests to open a radio bearer can be handled in parallel. While the request to open a radio bearer is handled, the corresponding IP packets will be stored to be sent when the bearer is effectively established. Important point: before the user has been authenticated and authorized, no IP data packet should be transferred (they should be buffered in the WCDMA driver); only signalling packets should be transferred. This means we should not attempt to open radio bearers until we are authenticated and authorized. In the current implementation, we will not buffer IP data packets, we will open radio bearers, and it will be up to the AAA Attendant in the Access Router to control the IP packets received, and let them go further or not. In a more advanced implementation design, the MTNM could warn the RCM that we are authenticated and authorized via a specific control message. Before its reception, we buffer IP data packets and after its reception, we open radio bearers and send IP data packets. This will not be part of the Moby Dick implementation.

D0302_M3-4.doc Final / M3.4 19.12.2002


5.1.6.3 Packet Reception block

The IP signalling packets and the IP data packets received from the RCF are directly transmitted to the IPv6 stack. Some of the IP signalling packets are “pure” IP signalling and will be used by the IPv6 stack. The other IP signalling packets will be automatically directed to the appropriate module (fast handover, registration or paging) by the IPv6 stack.

5.1.7 Radio Convergence Function The Radio Convergence Function is the specific part of the Radio driver. It has a generic interface with the upper layer of the Radio driver: the Radio Channel Manager. It has a specific interface with the Access Stratum, to take into account the specificities of the WCDMA AS layer. It is split into the following sub-blocks.

Enhanced IPv6 stack

RCM

Packet Reception

Control Packet

Data Packet

Data Channel Mngt

Send / Receive

Data

Open /

Close

Data Chanels


Radio

Infos Open /

Close

Conn

RCF

AS

Data Packet

Control Packet

Packet Transmission

Send / Receive

Data


Wcdma

Infos Open / Close

Conn

Paging


Figure 28 : Packet Reception block

D0302_M3-4.doc Final / M3.4 19.12.2002


RCF


Send /Receive

Data


Send /Receive

Data

Data Channel Mngt

Send /Receive

Data

Open /

Close

DataChannels

Send /Receive

Data

Open /

Close

DataChannels


Wcdma Infos

Open /

Close

Conn


Wcdma Infos

Open /

Close

Conn

Data Channel Mngt

Paging

Figure 29 : Radio Convergence Function

The schemas of the previous chapter on the RCM can be used to describe the interactions between the RCM / RCF / AS modules.

5.1.7.1 WCDMA Connection Manager block

5.1.7.1.1 WCDMA Infos sub-block The WCMDA Infos sub-block will receive the following messages from the AS:

• INFORMATION_BROADCAST_IND, with the list of IP addresses of neighbouring Access Routers (connected to Radio Gateways) and an associated RG Identifier (the cell Id) for each of them.

• MEASUREMENT_INDICATION, with a table containing a list of signal quality level for the neighbouring Radio Gateways and their associated cell Id.

A table will be maintained and updated, with the 3 following information, if available: RG Identifier (cell Id), IP address of AR, signal level quality. Every time a new MEASUREMENT_INDICATION or INFORMATION_BROADCAST_IND will be received from the AS, the table will be updated. Every n milliseconds, the message WCDMA_INFO will be transmitted to the Radio Infos sub-block of the RCM, to be transferred to the Network Environment Infos block of the MTNM. It will contain a list with the following information: cell Id, signal level quality, IP address of AR (extracted from the previously described table). The MTNM could also proactively request the sending of the message WCDMA_INFO at any moment, as already explained in a previous chapter. It would trigger the sending of the message MEASUREMENT_REQ to the AS, to obtain updated information via the AS message MEASUREMENT_IND. This will not be implemented in Moby Dick, as we don’t need it. The WCMDA Infos sub-block will also receive the following messages from the AS:

• INFORMATION_BROADCAST_IND, with a router advertisement from the Access Router associated to a neighbouring RG.

These router advertisements from the Access Router, received via AS message INFORMATION_BROADCAST_IND, will be transferred to the Control Packet sub-block, of the Packet Reception block of the RCM. They will then be passed directly to the IPv6 stack. 5.1.7.1.2 Open / Close Connection sub-block The Open / Close Connection sub-block manages the radio connections. - Upon reception of a request to open a connection from the RCM, it will request the AS to execute it, via the message CONNECTION_ESTABLISHMENT_REQ, with a local connection reference (to be attributed locally) and the cell Id (if not provided, the best available RG is chosen by the AS) as parameters. It will wait for the answer of the AS, via message CONNECTION_ESTABLISHMENT_RESP, with the local connection reference and a status. The status and the local connection reference will be transmitted to the RCM, to be handled at the RCM level.

D0302_M3-4.doc Final / M3.4 19.12.2002


Then some information about the connection will be transmitted to the Radio Gateway, via message DATA_TRANSFER_REQUEST. The parameter data will be a specific message type (NAS_CONNECTION_INFO), and the transmitted information will be the Home Address and the CoA of the Mobile Terminal. - Upon reception of a request to close the connection from the RCM, it will request the AS to execute it, via message CONNECTION_RELEASE_REQ. After this, it will notify the RCM, that the connection has been closed, passing the parameters local connection reference and status. The connection cannot be closed on the Radio Gateway initiative. - Upon reception of a notification from the AS, that the connection has been lost, via message CONNECTION_LOSS_IND, it will notify the RCM, with the local connection reference as parameter.

5.1.7.2 Paging sub-block The paging sub-block directly transmits the IP paging packets received from the AS, via message NOTIFICATION_IND, to the Control Packet sub-block, of the Packet Reception block, of the RCM. These IP paging packets will be passed to the IPv6 stack, and will automatically reach the Paging module.

5.1.7.3 WCDMA EUI-64 identifier The hardware identifier of the WCDMA driver will be based on the IMEI of the Mobile Terminal. By construction, we will not be able to use it directly as a MAC address (like for Ethernet or WLAN), as its format is different. Therefore, we will have to build the EUI-64 identifier by ourselves and register it to the WCDMA device driver. This will be used to build the IPv6 address.

5.1.7.4 Control Channel Management block When the connection is established with the Radio Gateway, a radio control channel is automatically allocated. Therefore there is no need to open / close control channels. Any IP control packet received from the RCM (with the associated local connection reference) is transmitted to the AS, via message DATA_TRANSFER_REQ, to be transferred to the Radio Gateway on the radio control channel. Any radio control packet received from the AS, via message DATA_TRANSFER_IND, containing IP signalling, is transmitted to the RCM Packet Reception block. The parameter data of the DATA_TRANSFER_REQ and DATA_TRANSFER_IND will be a specific message type (NAS_IP_SIGNALLING), to identify the content of the AS message as IP signalling. This IP control packet can be pure IP protocol signalling, but also specific signalling for AAA and mobility. Some signalling specific to the NAS can also be exchanged between the Mobile Terminal and the Radio Gateway, using a specific message type for the parameter data of the DATA_TRANSFER_REQ and DATA_TRANSFER_IND messages. This will not be addressed here, but directly in the chapters where this signalling is used.

5.1.7.5 Data Channel Management block

5.1.7.5.1 Open / Close Data Channels sub-block When the connection is established with the Radio Gateway, no radio bearer is established. Upon reception of a request from the RCM to open a radio bearer, a DATA_TRANSFER_REQ is made to the AS, to transmit to the Radio Gateway the request for opening the radio bearer. The parameter data of the DATA_TRANSFER_REQ message will be of a specific type (NAS_RADIO_BEARER_ESTABLISHMENT_REQ), to recognize the radio bearer establishment request, with the DSCP code, the source and destination IPv6 address of the packet, as parameters. An answer is expected from the Radio Gateway, that will be received by the AS and transmitted to the RCF: RADIO_BEARER_ESTAB_IND, with the parameters: local connection reference, radio bearer id, SAP id, radio QoS class, DSCP code. A status is sent to the Packet Transmission block of the RCM, to confirm the opening of the radio bearer associated to the radio QoS class, with the parameters radio bearer id, SAP id, radio QoS class, DSCP code. A timer with a timeout will be started after the DATA_TRANSFER_REQ message has been sent, and if the RADIO_BEARER_ESTAB_IND is not received before the timeout, a negative confirmation will be sent to the RCM, indicating that the radio bearer is not opened.

D0302_M3-4.doc Final / M3.4 19.12.2002


The requests to open radio bearers can be treated in parallel, as the message RADIO_BEARER_ESTAB_IND contains all the necessary information to identify two different requests. A RADIO_BEARER_ESTAB_IND message can be received spontaneously, if the opening of the radio bearer is on the Radio Gateway initiative. In this case again, the parameters of the message will enable its treatment. If a RADIO_BEARER_RELEASE_IND is received from the AS, parameters: local connection reference and radio bearer id, a message must be sent to the Packet Transmission block of the RCM, with the associated radio bearer Id, to warn it that the radio bearer is now closed and no data packet for the associated radio QoS class can be sent. 5.1.7.5.2 Send / Receive Data sub-block The Send / Receive Data sub-block manages the sending and reception of data packets to and from the AS. When an IP data packet is received from the RCM, with the associated radio bearer id and SAP Id, the radio bearer is already opened (this has been taken care of in the RCM, before transmitting this packet). Therefore, the RCF directly makes a PDCP_DATA_REQ to the AS on the appropriate SAP, to transfer the data packet to the Radio Gateway, with parameters radio bearer id, data packet length and data packet. When an IP data packet sent by the Radio Gateway is received from the AS via the message PDCP_DATA_IND, with parameters: radio bearer id, data packet length and data packet; this IP data packet is directly transmitted to the Packet Reception block of the RCM.

5.1.8 Monitoring Extensions to Ethernet / WLAN driver

5.1.8.1 Monitoring Extensions to Ethernet driver One of the access technologies covered by the inter-technology handover within Moby Dick is Ethernet, which entails specific availability constraints, as described in this section. This evaluation requires the distinction between a handover (i) towards an Ethernet interface and (ii) away from an Ethernet interface to a different technology. In the (i) case, the handover decision algorithm, which is located in the MTNM on the Mobile Terminal within the framework of Moby Dick, has to be aware about the presence and availability of the Ethernet link. This is not as trivial as for example in WLAN, where the signal quality, which is provided by the wireless tools from the periodical beacons, implies the presence of the medium. In order to signal the availability of the Ethernet medium to the MTNM module, a monitoring extension is required. Therefore, the medium-independent interface (MII) is deployed in Moby Dick. This extension is part of the Fast Ethernet standard and provides support for 10 and 100 Mbps media segments. In order to announce medium availability to the MTNM module, the status register of this attachment is deployed. The second case does not require extension, but the user has to be aware that a handover away from Ethernet has to be announced ‘manually’, since there is no signal quality decrease, which gives handover preparation time. The medium availability is one or zero; i.e., the cable is connected or unplugged. In order to provide fast handover from Ethernet to any other technology, the user must announce the desire to handover via a manual trigger before unplugging the cable.

5.1.8.2 Monitoring Extensions to WLAN driver In Moby Dick the hostap driver (http://hostap.epitest.fi/), version 19-05, created by Jouni Malinen will be used. The WLAN driver at the MT will include also a filtering function to be able to provide the right information/messages to the upper layers (essentially the MTNM and the IPv6 stack). The WLAN driver will be configured to work in ad-hoc mode, using a common SSID and a common frequency with the WLAN ARs in the Moby Dick network. This configuration, and the reasons behind it, is explained in detail in appendix A. The filtering function has three missions:

1. It detects Router Advertisements (and so, the respective ARs). The IPv6 addresses of these ARs, the corresponding subnet prefixes, and the signal levels associated with the frames that contain the respective Router Advertisements, are sent to the MTNM in a WLAN_INFO message. If no Router Advertisements are received from the AR the MT is using, the IPv6 address of this AR

D0302_M3-4.doc Final / M3.4 19.12.2002


must nevertheless be included in the WLAN_INFO message with signal level “0” (this indicates to the MTNM that the WLAN connection is lost).

2. The Router Advertisements received from the AR the MT is using, are sent to the IPv6 stack. Any other Router Advertisements are not sent to the IPv6 stack. The filtering function knows the AR the MT is using because, each time a handover is executed, the MTNM sends a message USE_WLAN_AR to the WLAN driver. This message includes the IPv6 address of the AR to use, and the respective network prefix.

3. All broadcast traffic that does not belong to the IPv6 subnet of the AR the MT is using, is discarded. The subnet is identified by the source address of the packet, using the subnet prefix of the subnet of the current AR.

5.1.9 W-CDMA Access Stratum The elements of the radio interface protocol are shown in Figure 30, where it is seen that the radio interface is layered into three protocol layers:

• The physical layer (L1); • The data link layer (L2); • The network layer (L3).

D0302_M3-4.doc Final / M3.4 19.12.2002


L3

cont

rol

cont

rol

cont

rol

Logical Channels

Transport Channels

C-plane signalling U-plane information

L2/MAC

L1

RLC

DC SAP

L2/RLC

MAC

RLC RLC

RLC

RLC RLC

Radio Bearers

RRC PDCP

PDCP

control

RB MUX/DEMUX

Qos SAPs

control

NT SAP GC SAP

Layer 1 High

Layer 1 Low

A/D D/A

Hardware Data AcQuisition (DAQ)

RF (TDD)

Figure 30: Access Stratum Layers

L1 is responsible for • Control/configuration of the hardware elements (Data Acquisition), • Basic signal processing, • Channel coding/decoding and multiplexing/demultiplexing. It operates under real-time constraints. We have split L1 into two sub layers, L1L and L1H. L1L is responsible for slot based signal processing (e.g. matched filtering, channel estimation, etc.) while L1H is responsible for frame-based signal processing (e.g. interleaving, error coding/decoding). L1H receives data from the MAC (see 5.1.9.2.4 ) in blocks known as transport channels. These are further sub-divided into transport channel blocks. L1H multiplexes and codes these blocks to forms what

D0302_M3-4.doc Final / M3.4 19.12.2002


are known as physical channels. Physical channels are raw data mapped onto specific radio channels which, as we will see shortly, are indexed by timeslots and channelization codes. At the lowest level, the physical layer software interfaces to the hardware data acquisition system and is responsible for configuring DMA transfers of the incoming/outgoing sample streams. Interfaces for controlling the RF functionality (antenna switch, amplifier gains, oscillator frequencies, etc.) are also implemented. L2 is responsible for

• Medium-access protocols (MAC) (dynamic channel allocation, bandwidth optimization) • Radio Link layer (RLC) algorithms (retransmission protocols, segmentation) • Packet data Convergence Protocol (PDCP)

It also operates under real-time constraints, although somewhat less stringent. L3 implements the signalling protocols that control the radio resources. These are known as control-plane or C-plane signalling protocols. Furthermore, L3 provides the data interface to the IP backbone network, for user data or U-plane information, in the form of a standard Linux networking device. Layer 3 and RLC are divided into Control (C-) and User (U-) planes. PDCP exists in the U-plane only. In the C-plane, Layer 3 is partitioned into sub layers where the lowest sub layer, denoted as Radio Resource Control (RRC), interfaces with layer 2 and terminates in the backbone IP network; it provides the AS Services to higher layers. RRC is part of the Access Stratum and operates under the same real-time constraints as L2. Each RLC/MAC/PDCP block in Figure 30 represents an instance of the respective protocol. Service Access Points (SAP) for peer-to-peer communication are marked with circles at the interface between sub layers. The SAP between MAC and the physical layer provides the transport channels. The SAPs between RLC and the MAC sub layer provide the logical channels. The RLC layer provides three types of SAPs, one for each RLC operation mode (unacknowledged-

UM, acknowledged-AM, and transparent-TM). PDCP is accessed by PDCP SAP. The service provided by L2 is referred to as the radio bearer. The C-plane radio bearers, which are provided by RLC to RRC, are denoted as signalling radio

bearers. In the C-plane, the interface between RRC and higher L3 sub-layers (NAS) is defined by the General

Control (GC), Notification (Nt) and Dedicated Control (DC) SAPs. Also shown in the figure are connections between RRC and MAC as well as RRC and L1 providing local inter-layer control services. An equivalent control interface exists between RRC and the RLC sublayer, between RRC and the PDCP sublayer. These interfaces allow the RRC to control the configuration of the lower layers. For this purpose separate Control SAPs are defined between RRC and each lower layer (PDCP, RLC, MAC, and L1). The RLC sublayer provides ARQ functionality closely coupled with the radio transmission technique used. There is no difference between RLC instances in C and U planes. There are primarily two kinds of signalling messages transported over the radio interface - RRC generated signalling messages and NAS messages generated in the higher layers. On establishment of the signalling connection between the peer RRC entities, three UM/AM signalling radio bearers may be set up in addition to the one set-up by default on common channels. Two of these bearers are set up for transport of RRC generated signalling messages - one for transferring messages through an unacknowledged mode RLC entity and one for transferring messages through an acknowledged mode RLC entity. One signalling radio bearer is set up for transferring NAS messages.

5.1.9.1 General architecture of the software platform This section presents an overview of the basic hardware/software architecture of the Software Radio Platform developed by Eurecom. The platform is used to implement the Time Division Duplex (TDD) transmission mode of the UMTS standard. The hardware architecture is centred on a real-time PC system that gives access to, and allows experimenting with, wide band radio resources. The platform is scalable and allows configurations from a powerful base station with smart antennas to simpler mobile terminals with a single antenna. It provides functionality at three levels: hardware, Digital Signal Processing (DSP) software, and link level software.

D0302_M3-4.doc Final / M3.4 19.12.2002


5.1.9.1.1 Hardware Components The hardware portion of the current testbed consists of 3 elements which are under software-control, namely • a PCI-bus based data acquisition card (PMC form-factor) • an analog/digital interface • an up/down conversion RF card using TDD multiplexing The radio portion is capable of generating arbitrary signals of bandwidth 5 MHz in the 2110-2170 MHz band using TDD multiplexing. A new radio interface is being produced for the 1900-1920 MHz band (UMTS TDD). 5.1.9.1.2 Software Components The software portion of the platform is an extension to the Linux Operating System and makes use of a hard real-time micro-kernel known as RT-Linux for performing layer 1 and layer 2 UMTS/TDD processing. Networking functionality is provided by the Linux kernel and open-source extensions. RT-Linux, an extension to the Linux Operating System, supports real-time interrupt handlers and real-time periodic tasks with interrupt latencies and scheduling jitter close to hardware limits. Real-time tasks in RT-Linux can communicate with Linux processes either via shared memory regions or a FIFO interface. Thus, real-time applications can make use of all the powerful, non-real-time services of Linux, including: Networking, Graphics, Windowing systems, Linux device drivers, Standard POSIX functionality. The configurations for Radio Gateways (RG), a combination of a base station and an IP router, and Mobile Terminals (MT) are shown in Figure 31 and Figure 32.

Multi-CPU Linux Machine/dev/eth0/dev/srnet

DAQ+

RF

PCI

Linux Kernel

Real-timeµKernel

IP Network (v4 v6)

ServerFunctions

UserSpaceReal-time Space

KernelSpace

IP Networking subsystem

Layer1LRT thread

Layer 1H/2/3RT thread

RadioBearers

Figure 31: Radio Gateway Architecture

D0302_M3-4.doc Final / M3.4 19.12.2002


Normal Linux Laptop

/dev/srnet

DAQ+

RF

Cardbus

Linux Kernel

Real-timeµKernel

UserApplication

UserSpaceReal-time Space

KernelSpace

IP Networking subsystem

Layer1LRT thread

Layer1H/2/3RT thread

RadioBearers

Figure 32: Mobile Terminal Architecture

The RG’s network connection is IP based and is assumed to be connected to an IP network via Ethernet using the standard Linux /dev/eth0 Ethernet device. The W-CDMA to IP Network Interconnect is made via a homemade RTLinux driver /dev/srnet. Its basic functions include

• Strict real-time implementation of 3GPP Layers 1 (PHY) and 2 (MAC/RLC) • Adapted RRC signalling functionality to accommodate a set of mobile-IP management functions

(information broadcast, attachment, resource requests, paging, etc.) The entities comprising the Radio Protocol Layers are collectively known as the Access Stratum (AS) in 3GPP terminology, whereas entities in the IP backbone are collectively known as the Non-Access Stratum (NAS). The computational complexity of the RG will depend on the number of channels and/or antennae that are required. It can range from a dual-processor server machine to a powerful 8-way SMP server (e.g. COMPAQ Proliant 6500, 8500). The MT is a normal Linux machine (e.g. laptop) and may be connected to a second machine via Ethernet for running special applications.

5.1.9.2 Physical Layer Software Architecture

5.1.9.2.1 3GPP TDD 3.84 Mchips/s Physical Layer Here we give a very brief summary of the 3GPP TDD 3.84 Mchip/s physical layer. 3GPP TDD 3.84 Mchip/s is a time-slotted CDMA system. Data frames last 10ms and are divided into 15 times slots of equal time duration (667 µs) as shown in Figure 4.

D0302_M3-4.doc Final / M3.4 19.12.2002


Tc = chip time = (1 / 3.84) µs

Slot #0

Slot #1

Slot#14

10 ms

2560 Tc

FRAME i

Figure 33: Frame Structure

Slots can be dynamically allocated for either uplink or downlink transmission which allows for the possibility of asymmetric resource allocation for the two traffic directions.

The basic transmission entity in a slot is a burst. Bursts are further subdivided into 2560 QPSK symbols (chips). 5.1.9.2.2 Implemented Physical Channels Physical channels are indexed by their slot number and orthogonal channelization (spreading) code. Spreading is used to allow several users to share a particular timeslot and as a means of achieving multi-level coding. On the uplink (UL) the maximum number of users sharing a particular timeslot is 8, and users can use at most 2 channelization codes in parallel. On the downlink (DL) up to 16 parallel channelization codes can be used. Spreading is achieved through the use of Orthogonal Variable Spreading Factor (OVSF) codes which are based on Hadamard sequences. Channelization Codes

Channelization codes are simply an organization of Hadamard codes of varying lengths which allow users (or data streams of one user) of potentially different data rates to be mutually orthogonal. These are known as OVSF codes. Scrambling codes

Scrambling is used to reduce interference from signals originating in neighbouring cells. Each cell is assigned a scrambling sequence of length 16 chips. This is a major difference from other CDMA systems such as UMTS/FDD and IS-95 which use very long scrambling codes. Because of this short scrambling sequence, advanced receiver architectures (i.e. equalizers, multi-user receivers) can be implemented at reasonable computational cost. Modulation Pulse-Shaping

QPSK signalling is used in UMTS TDD. Pulse-shaping is achieved through the use of a root-raised cosine filter with a spectral roll-off factor of .22. The resulting channel bandwidth is 5 MHz. Dedicated Physical Channels (DPCH)

Dedicated physical channels are used to transmit user traffic. Any combination of burst types, channelization codes and TFCI formats are allowed. On the downlink the allowed spreading factors are 16 and 1, whereas on the uplink, factors of 1, 2, and 4, 8,16 are possible. Primary common control physical channel (P-CCPCH)

The BCH or broadcast channel is mapped onto the Primary Common Control Physical Channel (P-CCPCH). The position (time slot / code) of the P-CCPCH is known from the Physical Synchronization Channel (PSCH). Secondary common control physical channel (S-CCPCH)

PCH (Paging Channel) and FACH (Forward Access Channel) are mapped onto one or more secondary common control physical channels (S-CCPCH). In this way the capacity of PCH and FACH can be adapted to the different requirements. The S-CCPCH is implemented for control channels.

D0302_M3-4.doc Final / M3.4 19.12.2002


Physical random access channel (PRACH) The RACH (Random-access Channel) is mapped onto one uplink physical random access channel (PRACH). This channel is used by the mobile station during the connection phase with the base station and for passing control information once connected. Because of its importance, the PRACH is implemented for control information and short user data packets. Synchronization channel (SCH)

The SCH is used for two purposes in UMTS/TDD: First, to acquire initial frame synchronization (using the primary synchronization code) and second, to derive the code group of a cell (using the secondary synchronization code). In order not to limit the uplink/downlink asymmetry, the SCH is mapped on one or two downlink slots per frame only. 5.1.9.2.3 Layer 1L overview Layer 1 DSP routines operate on buffers written to and read from the external PCI acquisition system. The two DMA memory buffers contain 1 UMTS frame’s (10ms) worth of samples.

As shown in Figure 30, Layer 1 is subdivided into 2 parts, L1L and L1H. L1L is responsible for modulation and L1H for channel coding and multiplexing. The higher layers (including L1H) provide data to be modulated to L1L in a form that can be interpreted to generate the sample streams. The raw data sequences are first spread (including scrambling) and then modulated. The receiver for a MT operates in 2 modes. The first is the initial acquisition of the RGs synchronization signal. This operation comprises correlation and energy detection. Once synchronized, frame/slot timing is acquired and demodulation of the different parallel channels can be accomplished. The receiver for an RG is somewhat simpler since initial synchronization is not needed. At a later stage, a synchronization (and timing adjustment) algorithm will be required to synchronize several RGs. This will be accomplished using the 3GPP Node-B synchronization burst. The main difference is that the RG must demodulate more parallel streams and perform joint channel estimation of up to 8 users.

5.1.9.2.4 Layer 1H overview On the transmitter side (from the MAC layer), data arrive to the coding/multiplexing unit of L1H in form of transport block sets, once every transmission time interval (TTI). The transmission time interval is transport-channel specific from the set {10 ms, 20 ms, 40 ms, 80 ms}. The following coding/multiplexing steps can be identified: • Addition of CRC information to each transport block • Transport Block concatenation / Code block segmentation • channel coding (convolutional, turbo, uncoded) • radio frame size equalization • interleaving • radio frame segmentation • rate matching • multiplexing of transport channels • bit scrambling • physical channel segmentation • mapping to physical channels The main computational burden related to L1H lies in the channel decoder for the receiver. Three of the channel coding methods require either a soft-decision Viterbi decoder on a 256-state trellis (convolutional code), or a soft-in soft-out 8-state iterative decoder (turbo decoder). We have currently only implemented the convolutional coding options of 3GPP in RT-mode.

5.1.9.3 MAC Services and Functions This section provides an overview on services and functions provided by the MAC sublayer. Further details can be found in the 3GPP specification [25.321]. 5.1.9.3.1 MAC Services to upper layers • Data transfer. This service provides unacknowledged transfer of MAC SDUs between peer MAC

entities. This service does not provide any data segmentation. Therefore, segmentation/reassembly function should be achieved by upper layer.

D0302_M3-4.doc Final / M3.4 19.12.2002


• Reallocation of radio resources and MAC parameters. This service performs, on request of RRC, the execution of radio resource reallocation and the reconfiguration of MAC functions such as change of identity of UE, change of transport format (combination) sets, change of transport channel type.

• Reporting of measurements. Local measurements such as traffic volume and quality indication are reported to RRC.

5.1.9.3.2 Transport and Logical channels

5.1.9.3.2.1 Transport Channels The MAC layer provides an interface to L1 consisting of transport channels. The following transport channels are implemented in the testbed. BCH (Broadcast Channel) - A downlink channel used for broadcasting basic system information, notably radio channel configuration data. FACH (Forward Access Channel) - A common downlink channel for AS/NAS signalling (connection establishment, data channel establishment) as well as short user packets and paging. RACH (Random-Access Channel) - A contention-based uplink channel for AS/NAS signalling (connection establishment, data channel establishment) as well as short user packets. DCH (Dedicated Channel) - An uplink or downlink channel for either dedicated traffic or control information. 5.1.9.3.2.2 Logical Channels The MAC layer provides data transfer services on logical channels. A set of logical channel types is defined for different kinds of data transfer services as offered by MAC. Each logical channel type is defined by what type of information is transferred. Logical channels are generally classified into two groups: • Control Channels (for the transfer of C-plane information); • Traffic Channels (for the transfer of U-plane information). 5.1.9.3.2.2.1 Control Channels Control channels are used for transfer of C-plane information only. The following control channels are implemented. Broadcast Control Channel (BCCH) - A downlink channel for broadcasting system control information. Common Control Channel (CCCH) - Bi-directional channel for transmitting control information between network and UEs. This channel is commonly used by the UEs having no RRC connection with the network Dedicated Control Channel (DCCH) - A point-to-point bi-directional channel that transmits dedicated control information between a UE and the network. This channel is established through the RRC connection setup procedure. 5.1.9.3.2.2.2 Traffic Channels Traffic channels are used for the transfer of U-plane information only. The following U-plane channels are implemented. Dedicated Traffic Channel (DTCH) - A Dedicated Traffic Channel (DTCH) is a point-to-point channel, dedicated to one UE, for the transfer of user information. A DTCH can exist in both uplink and downlink. 5.1.9.3.2.3 Mapping between logical channels and transport channels The logical/transport channel mappings as seen from the UE and Network sides are shown in Figure 34 and Figure 35 respectively.

D0302_M3-4.doc Final / M3.4 19.12.2002


BCH FACH RACH DCH

BCCH- SAP

DCCH- SAP

CCCH- SAP

PCCH- SAP

DTCH-SAP

Transport Channels

MAC SAPs

Figure 34: Logical channels mapped onto transport channels, seen from the UE side

BCH FACH RACH DCH

BCCH- SAP

DCCH- SAP

CCCH-SAP

PCCH- SAP

DTCH-SAP

Transport Channels

MAC SAPs

Figure 35: Logical channels mapped onto transport channels, seen from the Network side

5.1.9.3.3 MAC functions The functions of MAC include: • Mapping between logical channels and transport channels. • Selection of appropriate Transport Format for each Transport Channel depending on instantaneous

source rate. • Priority handling between data flows of one UE. • Priority handling between UEs by means of dynamic scheduling NOTE: In the TDD mode the data to be transported are represented in terms of sets of resource units. • Identification of UEs on common transport channels. • Multiplexing/demultiplexing of upper layer PDUs into/from transport blocks delivered to/from the

physical layer on common transport channels.. • Multiplexing/demultiplexing of upper layer PDUs into/from transport block sets delivered to/from

the physical layer on dedicated transport channels. • Traffic volume measurement. • Transport Channel type switching. • Access Service Class selection for RACH transmission.

5.1.9.4 RLC Services and Functions This section provides an overview on services and functions provided by the RLC sublayer. Further details can be found in the 3GPP specification [25.322].

D0302_M3-4.doc Final / M3.4 19.12.2002


5.1.9.4.1 Services provided to the upper layer • Transparent data transfer. This service transmits upper layer PDUs without adding any protocol

information, possibly including segmentation/reassembly functionality. • Unacknowledged data transfer. This service transmits upper layer PDUs without guaranteeing

delivery to the peer entity. The unacknowledged data transfer mode has the following characteristics: o Detection of erroneous data: By using the sequence-number check function. o Immediate delivery: Delivery of a SDU to the upper layer as soon as it arrives at the

receiver. • Acknowledged data transfer. This service transmits upper layer PDUs and guarantees delivery to

the peer entity. In case RLC is unable to deliver the data correctly, the user of RLC at the transmitting side is notified. For this service, only in-sequence delivery is supported. The acknowledged data transfer mode has the following characteristics:

o Error-free delivery: Error-free delivery is ensured by means of retransmission. The receiving RLC entity delivers only error-free SDUs to the upper layer.

o Unique delivery: The RLC sublayer delivers each SDU only once to the receiving upper layer using duplication detection function.

o In-sequence delivery: RLC sublayer delivers SDUs to the receiving upper layer entity in the same order as the transmitting upper layer entity submits them to the RLC sublayer.

o Out-of-sequence delivery: Alternatively to in-sequence delivery, the receiving RLC entity delivers SDUs to upper layer in different order than submitted to RLC sublayer at the transmitting side.

• Maintenance of QoS as defined by upper layers. The retransmission protocol shall be configurable by layer 3 to provide different levels of QoS. This can be controlled.

• Notification of unrecoverable errors. RLC notifies the upper layer of errors that cannot be resolved by RLC itself by normal exception handling procedures, e.g. by adjusting the maximum number of retransmissions according to delay requirements.

There is a single RLC connection per Radio Bearer. 5.1.9.4.2 RLC Functions The RLC sub layer implements the following functions: Segmentation and reassembly. Concatenation Padding. Transfer of user data. Error correction. In-sequence delivery of upper layer PDUs. Duplicate Detection. Flow control. Sequence number check. Protocol error detection and recovery. SDU discard.

5.1.9.5 PDCP Services and Functions This section provides an overview on services and functions provided by the Packet Data Convergence Protocol (PDCP). A detailed description of the PDCP is given in [25.324]. 5.1.9.5.1 PDCP Services provided to upper layers - PDCP SDU delivery. 5.1.9.5.2 PDCP Functions - Transfer of user data. Transmission of user data means that PDCP receives PDCP SDU from the NAS and forwards it to the RLC layer and vice versa.

5.1.9.6 RRC Specification The RRC sub-component is based on the 3GPP specification [25.331], but modified to fit the needs of the Moby Dick framework whenever needed.

D0302_M3-4.doc Final / M3.4 19.12.2002


5.1.9.6.1 Services provided to the Non Access Stratum

5.1.9.6.1.1 General Control The GC SAP provides an information broadcast service. It is used to enable the NAS entities (IP Network) to provide information and to give commands that do not relate to specific users. There is one General Control SAP per Radio Gateway connection point. On the UE side, there is a single General Control SAP in an MS. This service broadcasts information to all UEs in the cell area. 5.1.9.6.1.2 Notification The Nt SAP provides paging and notification broadcast services. There is one Notification SAP per RG connection point. On the UE side, there is a single Notification SAP (a Paging SAP) in an MS. The paging service sends information to a specific UE(s). The information is broadcast in the cell area but addressed to a specific UE(s). 5.1.9.6.1.3 Dedicated Control The DC SAP provides services for establishment/release of a connection and transfer of messages using this connection. It should also be possible to transfer a message during the establishment phase. A connection is a relationship with a temporary context in the RG. The context in the RG is initiated at the establishment of the connection, and erased when the connection is released. There are typically a great number of Dedicated Control SAPs per RG connection point. SAPs are identified by a SAPI at the AS boundary. During the lifetime of a connection, the connection can be identified unambiguously by the SAPI of the associated SAP, and the SAPI is used as a reference in the exchanges at the AS boundary on the infrastructure side. On the UE side, there is a single dedicated control SAP. The information transfer service sends a signalling message using the earlier established connection. 5.1.9.6.2 RRC functions The Radio Resource Control (RRC) layer handles the control plane signalling of Layer 3 between the UEs and the RG. The RRC performs the following functions: Broadcast of information provided by the non-access stratum. The RRC layer performs system

information broadcasting from the network to all UEs. The system information is normally repeated on a regular basis. How it is repeated is controlled by the non-access stratum. The RRC layer performs the scheduling, segmentation and repetition. This function supports broadcast of higher layer (above RRC) information. This information may be cell specific or not. As an example RRC may broadcast Router Advertisement IP packets and/or the list of suitable neighbouring cells.

Broadcast of information related to the access stratum. The RRC layer performs system information broadcasting from the network to all UEs. The system information is normally repeated on a regular basis. The RRC layer performs the scheduling, segmentation and repetition. This function supports broadcast of typically cell-specific information, such as common channels parameters.

Establishment, re-establishment, maintenance and release of an RRC connection between the UE and RG. The establishment of an RRC connection is initiated by a request from RCF at the UE side to establish the first Signalling Connection for the UE. The establishment of an RRC connection includes a layer 2 signalling link establishment. The release of an RRC connection can be initiated by a request from RCF to release the Connection for the UE or by the RRC layer itself in case of RRC connection failure. In case of connection loss, the UE requests re-establishment of the RRC connection. In case of RRC connection failure, RRC releases resources associated with the RRC connection.

Establishment and release of Radio Bearers. The RRC layer can, on request from RCF, perform the establishment and release of Radio Bearers in the user plane. A number of Radio Bearers can be established to an UE at the same time. At establishment, the RRC layer performs admission control and selects parameters describing the Radio Bearer processing in layer 2 and layer 1, based on information from RCF. This function includes coordination of the radio resource allocation between multiple radio bearers related to the same RRC connection. RRC controls the radio resources in the uplink and downlink such that UE and Network can communicate using unbalanced radio resources (asymmetric uplink and downlink).

Paging/notification. The RRC layer can broadcast paging information from the network to selected UEs. Higher layers on the network side can request paging and notification. The RRC layer can also propagate paging during an established RRC connection.

D0302_M3-4.doc Final / M3.4 19.12.2002


Control of requested QoS. This function shall ensure that the QoS requested for the Radio Bearers can be met. This includes the allocation of a sufficient number of radio resources.

UE measurement reporting and control of the reporting. The measurements performed by the UE are controlled by the RRC layer, in terms of what to measure, when to measure and how to report, including UMTS air interface. The RRC layer may also perform the reporting of the measurements from the UE to the network (currently not planned in Moby Dick).

Initial cell selection and re-selection in idle mode. Selection of the most suitable cell based on idle mode measurements and cell selection criteria.

5.1.9.6.3 RRC procedures and messages The RRC protocol procedures are detailed in specification [25.331]. The following procedures are implemented in the Moby Dick framework. 5.1.9.6.3.1 RRC internal states The RRC layer implements a state machine. From a macroscopic point of view, the UE can be either in idle or in connected mode. This mode is known at NAS level. idle mode : The Mobile Terminal (UE) is first switched on. Then it enters the “Idle” mode where it

listens to the synchronization channel and then to the BCH. After this first synchronization phase, the UE is “physically” attached to the RG. It is said to “camp on the cell”. It monitors the System Information messages broadcasted by the Radio Gateway (RG). When applicable, the UE RRC forwards the information received to the NAS entities. The UE enters connected mode on NAS request when data must be transferred between the UE and the RG. It then continues to monitor the System Information messages.

connected mode. The UE has established a connection with the Network. This mode is divided into several states:

o Connected : CELL-DCH One or more dedicated physical channel(s) is allocated to the UE The UE may monitor FACH for System Info messages

o Connected : CELL-FACH No dedicated physical channel, FACH and RACH are used instead The UE listens to BCH (Broadcast Channel) for System Information

o Connected : CELL-PCH No physical channel is allocated The UE is accessible only via the PCH (Paging Channel) It listens to System Information on BCH

5.1.9.6.3.2 RRC Connection Management Procedures

5.1.9.6.3.2.1 Broadcast of system information The purpose of this procedure is to broadcast system information from the RG to the UEs in a cell. Associated RRC Messages: RG → UE - SYSTEM INFORMATION 5.1.9.6.3.2.2 System Information blocks System Information is broadcasted in System Information Blocks. The following ones are planned to be used as of today (with data according to the need of the project): SIB type 1 : NAS system information as well as UE timers and counters to be used in idle mode and

in connected mode SIB type 2 : the cell identity. SIB type 5 : parameters for the configuration of the common physical channels in the cell. SIB type 11 : measurement control information to be used in the cell. SIB type 18 : Identities of neighbouring cells to be considered in idle mode as well as in connected

mode. 5.1.9.6.3.2.3 RRC connection establishment The purpose of this procedure is to establish an RRC connection. Associated RRC Messages: UE → RG - RRC CONNECTION REQUEST RG → UE - RRC CONNECTION SETUP

D0302_M3-4.doc Final / M3.4 19.12.2002


UE → RG - RRC CONNECTION SETUP COMPLETE RG → UE - RRC CONNECTION REJECT 5.1.9.6.3.2.4 RRC connection release The purpose of this procedure is to release the RRC connection including and all radio bearers between the UE and the Network. By doing so, all established signalling connections will be released. Associated RRC Messages: RG → UE - RRC CONNECTION RELEASE UE → RG - RRC CONNECTION RELEASE COMPLETE 5.1.9.6.3.2.5 Initial Direct transfer The initial direct transfer procedure is used in the uplink to establish a signalling connection. It is also used to carry an initial upper layer (NAS) message over the radio interface. Associated RRC Message: UE → RG - INITIAL DIRECT TRANSFER 5.1.9.6.3.2.6 Downlink Direct transfer The downlink direct transfer procedure is used in the downlink direction to carry upper layer (NAS) messages over the radio interface. Associated RRC Message: RG → UE - DOWNLINK DIRECT TRANSFER 5.1.9.6.3.2.7 Uplink Direct transfer The uplink direct transfer procedure is used in the uplink direction to carry all subsequent upper layer (NAS) messages over the radio interface belonging to a signalling connection. Associated RRC Message: UE → RG - UPLINK DIRECT TRANSFER 5.1.9.6.3.2.8 UE dedicated paging This procedure is used to transmit dedicated paging information to one UE in connected mode in CELL_DCH or CELL_FACH state. Upper layers in the network may request initiation of paging. Associated RRC Message: RG → UE - PAGING TYPE 2 5.1.9.6.3.3 Radio Bearer control procedures

5.1.9.6.3.3.1 Radio bearer establishment The radio bearer establishment procedure is used to establish new radio bearer(s). Associated RRC Messages: RG → UE - RADIO BEARER SETUP UE → RG - RADIO BEARER SETUP COMPLETE UE → RG - RADIO BEARER SETUP FAILURE 5.1.9.6.3.3.2 Radio bearer release The radio bearer release procedure is used to release radio bearer(s). Associated RRC Messages: RG → UE - RADIO BEARER RELEASE UE → RG - RADIO BEARER RELEASE COMPLETE UE → RG - RADIO BEARER RELEASE FAILURE 5.1.9.6.3.4 RRC connection mobility procedures

5.1.9.6.3.4.1 Cell update procedures The cell update procedures serve several main purposes: to notify the Network of an RLC unrecoverable error [25.322] on an AM RLC entity;

D0302_M3-4.doc Final / M3.4 19.12.2002


to be used as a supervision mechanism in the CELL_FACH state by means of periodical update. to act on a radio link failure in the CELL_DCH state;

The cell update procedures may: cause a state transition from the CELL_FACH state to the CELL_DCH state or idle mode.

The cell update procedure may also include: a re-establish of AM RLC entities; a radio bearer release.

Associated RRC Messages: UE → RG - CELL UPDATE RG → UE - CELL UPDATE CONFIRM

D0302_M3-4.doc Final / M3.4 19.12.2002


5.2 Access Router Figure 36 depicts a functional overview of the Access Router (protocol communications with MT are not shown in this figure).


WLAN Ethernet

Fast Handovermodule

Enhanced IPv6 stack

DiffservPacket filter

Standard IPv6 stack

IPSec

MeteringAAAAttendant

PEP

AAAC server QoS brokerRG

Protocol communicationInternal interface

IP paging attendant

RGPA

AR

DSCP tableQoS Attendant

AAA and QoS modules

MT

MT

Figure 36: Access Router Software Architecture.

5.2.1 Overview of the different components This section splits the components identified before in sub-blocks, giving an overview of their role. The detailed behaviour of these sub-blocks and their interactions will be detailed in the next chapter.

5.2.1.1 Fast Handover Module / MIPL It provides the implementation of fast handover procedures. Also, this module will take care of the context transfer of some QoS, AAA, and security parameters that will be done between the old AR and the new AR to speed up handover.

5.2.1.2 Paging Attendant The IP paging attendant implements procedures for IP paging support:

1. Procedures for PA discovery. 2. Procedures for paging request. PA will send paging requests from which the ARs’ paging

attendants will create an on-link paging request to re-activate the dormant MT.

5.2.1.3 Network Device Driver /WLAN This is a standard WLAN driver. In Moby Dick the hostap driver (http://hostap.epitest.fi/), version 19-05, by Jouni Malinen will be used.

D0302_M3-4.doc Final / M3.4 19.12.2002


5.2.1.4 Enhanced IPV6/IPSec/DiffServ packet Filter The enhanced IPv6 stack will be based on the IPv6 stack of the linux kernel 2.4.16. Functionality that must be present:

• Standard IPv6 functionality. • IPSec: for authentication of packets. • Diffserv and packet filter, that includes:

o Filtering: all packets received must belong to a flow in the DSCP table or they must be signalling packets for network access procedures (a particular DSCP code) that must be given to upper layers. If not, they must be dropped.

o Shaping: when sending packets, to control that flows adjust to agreed bandwidth.

5.2.1.5 AAA Attendant The AAA attendant acts as AAA client and is responsible for communication with AAAC server on behalf of the MT. This includes all security specific functionalities like key handling and network access procedures, i.e., it deals with registration and setup. This module must also deal with accounting issues. For that purpose it must have an interface with the Metering module.

5.2.1.6 Metering It deals with metering issues. It will be controlled by the AAA attendant which will decide when start or finish metering a particular user session.

5.2.1.7 QoS Manager / QoS Attendant The QoS manager is responsible for QoS activities in the AR. It includes a Data Base with the DSCP table. The Policy Enforcement Point PEP is responsible for policing issues. The policy information is sent to the PEP by the QoS broker and the PEP stores it in the DSCP table. The QoS attendant receives QoS context transfer from the fast handover module and introduces it in the DSCP table.

5.2.2 Fast Handover Module / MIPL The fast handover module on the access router is mainly responsible for the inter-access router communication and the bi-casting of data, which is destined for the mobile node, during the handover process. Conceptually, MIPL is not required on the access router, but currently, the fast handover modules accesses functionalities of the mobility module and therefore the MIPL module is mentioned here in combination with the fast handover module. Again the sending and receiving functions of the (enhanced) IPv6 stack are to be made accessible without explicit interface specification. Interactions to other modules than the IPv6 stack are not required on the access router. After the reception of a ROUTER_SOLICITATION_PROXY at the ‘old’ access router a HANDOVER_INITIATE message is generated and send to the new access router. The new access router responds with a HANDOVER_ACK message to the old access router. Receiving this packet the old router invokes the bicasting, i.e., duplicates all packets destined for the mobile terminal and send these packets to the old and the new care-of address simultaneously. The FAST_HANDOVER_ACK is generated and send to the mobile node in order to inform the mobile terminal that the preparation is done.

5.2.3 Paging Attendant

D0302_M3-4.doc Final / M3.4 19.12.2002


IP Paging attendant

Enhanced IPv6 proto

Signaling relay

Mapping function

IPv6

IPSec

DiffServ


Ethernet

WLAN

PA MT

Figure 37 : Paging Attendant

The IP paging attendant function includes the paging related signalling relay block as well as a mapping function block. The latter one allows mapping between generic IP paging messages to on-link paging messages. This can be either mapping to an on-link IP paging message, to a proprietary paging related signal to be sent to the W-CDMA RG via appropriate sockets or to an access technology specific paging function (hence the link to the network device driver level). However, since paging is deployed here at L3, the Mapping function is restricted and the paging request control message is just to be addressed to the mobile terminal’s Solicited Node Multicast address, as to be derived from the common paging identifier encapsulated in the paging request message. Also no explicit addressing of RG related functions are necessary, since the RG listens on these multicast addresses and interprets Paging Request ICMPv6 types as to be mapped to the addressed mobile terminal’s paging channel. The remote signalling peers (MT and PA) are shown in the figure above and connected to the IP paging attendant through a dotted line for illustration purposes. Since paging a mobile terminal through the RG has been kept transparent to the paging attendant and no explicit control and addressing of the RG is required from the paging attendant here, the RG has not been included in the figure above.

5.2.3.1 Signalling relay The signalling relay block represents the actual attendant function, receiving IP signalling messages from mobile terminals for Paging Agent (PA) discovery, implicit registration and paging area update. Furthermore, during a paging process this functional block receives the generic IP paging procedure related signalling messages from the respective PA. If L2 support from access technologies is available, the mapping function described in 5.2.3.2 performs appropriate conversion. Receiving an IP dormant registration message from a mobile terminal, the signalling relay checks its database for a responsible PA. Alternatively, PA address discovery can be initiated from the AR or a remote database can be contacted. In Moby Dick, only the local database approach will be implemented and deployed. The dormant registration is to be relayed to the responsible PA. The reply messages, originated from the PA, have to be relayed back to the mobile terminal. In case of receiving a paging request message from a PA, the signalling relay does not process the IP signalling message. The paging request message content is to be passed to the mapping function.

5.2.3.2 Mapping function During a paging process, the mapping function is responsible for generating the appropriate on-link paging request message. This can be either an IP paging message, addressing the Solicited Node

D0302_M3-4.doc Final / M3.4 19.12.2002


Multicast address, or a technology proprietary signalling sequence. On L2 support of respective access technologies, the mapping function represents an additional block for conversion between access technology specific location management signalling and respective IP signalling. For paging area update signalling, the mapping function block of the attendant can support a mobile terminal’s dormant mode if the respective access technology allows tracking and signalling of/from dormant mobile terminals on L2 mechanisms. The attendant on the first AR of the new paging area could then map the access technology specific indication to update the paging area to a generic IP paging area update message, which is to be forwarded to the appropriate PA then. This mechanism is allowed to be implemented from paging attendants in ARs, but will not be specified and implemented within the framework of the Moby Dick project. The mapping function is also responsible for extracting the PBKs from the generic IP paging message, as sent from the PA to the respective ARs, according to the IP paging concept. This key is to be processed and mapped to the concept’s IP-based message authentication scheme or a proprietary authentication scheme as deployed by the access link paging procedure. Also the paging process related proprietary encryption of access link paging messages is to be handled within this function block. However, the concept’s security support will not be implemented here. On reception of an IP paging request message from the signalling relay block, in particular the common IP paging ID is processed and the Solicited Node Multicast address for the respective access technology interface is derived from it.

5.2.4 Network Device Driver /WLAN This is a standard WLAN driver. In Moby Dick the hostap driver (http://hostap.epitest.fi/), version 19-05, by Jouni Malinen will be used. The WLAN driver will be configured to work in ad-hoc mode, using a common SSID and a common frequency with other WLAN ARs in the Moby Dick network and with the MTs. This configuration, and the reasons behind it, is explained in detail in appendix A.

D0302_M3-4.doc Final / M3.4 19.12.2002


5.3 Radio Gateway This chapter gives the software specification of the different components of the Radio Gateway. These include the Inter Working Function (IWF), the WCDMA driver (Radio Channel Manager and Radio Convergence Function), the Access Stratum. It also provides the interface between these components, and also the components involved in other equipments. Below is a high level integrated view of the different components of the Radio Gateway.

Figure 38: Radio Gateway Software Architecture.

QoS attendant on AR

Ethernet NetworkDevice Driver

IPv6 Protocol Stack

IWF

Standard Socket Interface

Standard Network Device Interface

Raw Socket Interface

Raw Socket Interface

WCDMA to IP relay

IP to WCDMA

relay

QoS attendant

Info Management

Kernel space

User space

Protocol communication

Internal interface

WCDMA Network Device Driver

RCM / RCF

Access Stratum

NAS / AS interface

WCDMA NDD on MT

AS on MT

D0302_M3-4.doc Final / M3.4 19.12.2002


5.3.1 Overview of the different components This section splits the components identified before in sub-blocks, giving an overview of their role. The detailed behaviour of these sub-blocks and their interactions will be detailed in the next chapter.

5.3.1.1 Inter Working Function This module will act as a relay between the Ipv6 world and the radio world; transferring the IPv6 packets from one to the other and generating any kind of specific signalling (paging, radio broadcast, QoS signalling, specific IP signalling). The behaviour of the different sub-blocks of the IWF will be detailed in the next chapter.

5.3.1.2 Radio Channel Manager This module will act as a generic radio driver, giving high level interfaces to manage the connections and the associated data channels; to send and receive IP packets and other specific radio data; and get some feedback on the radio conditions. It will be implemented as a kernel module (RCM and RCF will be grouped in a same kernel module, namely a driver). The behaviour of the different sub-blocks of the RCM will be detailed in the next chapter.

5.3.1.3 Radio Convergence Function This module will act as a specific WCDMA driver, giving low level interfaces to manage the connections and the associated data channels; to send and receive IP packets and other specific radio data; and get some feedback on the WCDMA conditions. It will be implemented as a kernel module (RCM and RCF will be grouped in a same kernel module, namely a driver). The behaviour of the different sub-blocks of the RCF will be detailed in the next chapter.

5.3.1.4 Access Stratum The Access Stratum provides services related to the transmission of data over the radio interface and the management of the radio interface. It includes the following Radio Interface protocols: the Physical layer, the data link layer, divided into 2 sub-layers: Medium Access Control (MAC) and Radio Link Control (RLC). In the user-plane, an additional service dependant protocol exists: the Packet Data Convergence Protocol (PDCP). The lowest sub-layer of the network layer consists of one protocol, called Radio Resource Control (RRC), which belongs to the control plane.

5.3.2 Inter Working Function IWF

WCDMA to IP relay

QoS Attendant

IP to WCDMA relay

Router Advertisement

proxy

Neighbor Discovery

proxy

Paging proxy

Other IP signaling + IP data

proxy Info Management

Figure 39 : Inter Working Function

The IWF has interactions with the RCM (generic part of the WCDMA driver), the IP stack, the Ethernet driver. It is split into the following sub-blocks.

D0302_M3-4.doc Final / M3.4 19.12.2002


5.3.2.1 Info Management block In the initialisation phase, it will retrieve the list of IP addresses of the Access Routers (linked to the neighbouring Radio Gateways) from a static configuration file, and a request will be sent to the Broadcasting sub-block of the RCM, to broadcast this information on the radio. The message will be IWF_BROADCAST_REQUEST, with the list as parameter. It will store the Router Advertisement currently broadcasted on the radio, for the Mobile Terminals. It will store a list with the local connection reference of every Mobile Terminal currently connected to the Radio Gateway, the associated Home Address and Care Of Address of the MT, and the IMEI of the MT. Upon reception of the message OPEN_WCDMA_CONN_IND, with parameter local connection reference and IMEI of MT, the corresponding entry will be added to the list. Upon reception of the message WCDMA_CONN_INFO, with parameters local connection reference, associated Home Address and Care Of Address, the corresponding entry in the list will be updated. Upon reception of the messages CLOSE_WCDMA_CONN_IND or LOST_WCDMA_CONN_IND, with parameter local connection reference, the corresponding entry will be deleted from the list.

D0302_M3-4.doc Final / M3.4 19.12.2002


5.3.2.2 IP to WCDMA relay block The following schema details the Info Management Block and the sub-blocks presented in the next 3 chapters.

IWF

RCM RCM

RCF RCF

AS

RCM Ethernet driver

IP stack

Info Management

IP to WCDMA relay

Router Advertisement

proxy

Neighbor Discovery

proxy

Paging proxy

Radio Connection


Broad casting

Open /Close

Conn

Paging

Radio Connection


Broad casting

Open /Close

Conn

Paging

Figure 40 : IP to WCDMA Relay block

5.3.2.2.1 Router Advertisement Proxy sub-block This sub-block will be directly connected to the Ethernet driver via a raw socket, to intercept Router Advertisements from the Access Router. The first received Router Advertisement will be stored in the Info Management block, and a request will be sent to the Broadcasting sub block of the RCM, to broadcast this Router Advertisement on the radio. The message will be IWF_BROADCAST_REQUEST, with the Router Advertisement as parameter. The Radio Gateway is supposed to be connected to the same Access Router all the time, so that the Router Advertisement should never change.

D0302_M3-4.doc Final / M3.4 19.12.2002


5.3.2.2.2 Neighbour Discovery Proxy sub-block This sub-block will be directly connected to the Ethernet driver via a raw socket, to intercept Neighbour Solicitation requests from the Access Router. If it corresponds to the Care Of Address of one of the currently connected Mobile Terminal (information stored in the Info Management block), a Neighbour Advertisement will be sent to the Access Router, with the “MAC address” of the Radio Gateway, instead of the one from the Mobile Terminal. 5.3.2.2.3 Paging Proxy sub-block This sub-block will be directly connected to the Ethernet driver via a raw socket, to intercept requests from the paging proxy of the Access Router. These will be ICMPv6 packets of a specific type, to recognize the paging functionality. The request from the paging proxy of the Access Router will need to be checked, using information stored in the Info Management block, to see if the paging Solicited Node Multicast destination address of the paging packet maps one of the IMEI of the MT connected to the Radio Gateway. The comparison will be made on the 24 last bits. If true, a request will be sent to the Paging sub-block of the RCM, to send a message on the paging radio channel. The message will be IWF_PAGING_REQUEST, with the local connection reference of the Mobile Terminal and the IP paging packet as parameters. 5.3.2.2.4 Other IP signalling and IP data proxy sub-block These IP packets, received from the Ethernet driver (via a raw socket interface), will be transmitted to the RCM packet transmission block (via a raw socket interface), which will take care of sending them on the appropriate radio bearer. We will use the message IWF_IP_PACKET for the interface between the IWF and the RCM. We will use the destination address of the IP packet to find the associated local connection reference, using the information stored in the Info Management block (match the destination address with one of the CoA of the connected Mobile Terminals).

D0302_M3-4.doc Final / M3.4 19.12.2002


IWF

RCM RCM

RCF RCF


Send /Receive

Data


Send /Receive

Data

Data Channel Mngt

Send / Receive

Data

Open / Close

Data Channels

Data Channel Mngt

Send / Receive

Data

Open / Close

Data Channels

AS

RCM Ethernet driver

IP stack

Packet Transmission

Data Packet

Control Packet

Packet Transmission

Data Packet

Control Packet

IP to WCDMA relay

Other IP signaling+ IP data

proxy

Figure 41 : Other IP signalling and IP data proxy sub-block

D0302_M3-4.doc Final / M3.4 19.12.2002


5.3.2.3 QoS Attendant sub-block This entity communicates with the QoS Manager on the Access Router and the QoS Broker. The radio resources will be negotiated dynamically each time a radio bearer is requested by a Mobile Terminal (in the case of a first incoming IP packet originating from the Access Router, the QoS broker will send the necessary information without solicitation from the RG). When the RCF on the Radio Gateway receives a request from the RCF on the Mobile Terminal to open a radio bearer, it will send the message IWF_RADIO_BEARER_REQ to the QoS Attendant of the IWF, with the characteristics associated to the requested bearer (local connection reference, DSCP code, IP source address of original packet on MT, IP destination address of original packet on MT). The QoS Attendant will send a “dummy packet” (an echo request will do the trick) with the characteristics of the original packet on the MT: IP source address, IP destination address, DSCP code. This packet will be intercepted by the QoS Manager on the Access Router and will trigger the “QoS authorisation process” involving the QoS Broker. The QoS Attendant on the RG then expects an answer from the QoS Broker, message RADIO_ACCESS_ALLOCATION, with the following parameters: DSCP code, Home Address of MT (for identification purpose), Radio QoS Class, status. In the case of an incoming packet from the Access Router (and not from the MT), the QoS Broker will also have to send the message RADIO_ACCESS_ALLOCATION, with the parameters corresponding to the incoming packet. In the case of a fast handover with the RG as destination, the QoS Broker will have to send the message RADIO_ACCESS_ALLOCATION, with a list of entries with once again the same parameters. This will enable the Radio Gateway to open the radio bearers corresponding to the DSCP codes used by the Mobile Terminal, immediately after the radio connection between MT and RG has been established. A specific value will be given to the status parameters in the message RADIO_ACCESS_ALLOCATION, to recognize this case of fast handover. Hence, the message RADIO_ACCESS_ALLOCATION should be in fact a list of the following parameters: DSCP code, Home Address of MT (for identification purpose), Radio QoS Class, status (ok, not ok, specific value in fast handover case). It can be a UDP packet exchanged between two known ports on the Radio Gateway and the QoS Broker. After reception of the message RADIO_ACCESS_ALLOCATION, the QoS Attendant on the RG will send the message IWF_RADIO_BEARER_CONF to the RCF, with the following parameters: local connection reference corresponding to the MT Home Address, list of [DSCP code, Radio QoS class, status].

D0302_M3-4.doc Final / M3.4 19.12.2002


IWF

RCM RCM

RCF RCF

Data Channel Mngt

Send / Receive

Data

Open / Close

Data Channels

Data Channel Mngt

Send / Receive

Data

Open / Close

Data Channels

AS

RCM Ethernet driver

IP stack

QoS Attendant

Info Management

Packet Transmission

Data Packet

Control Packet

Packet Transmission

Data Packet

Control Packet

Figure 42 : QoS Attendant sub-block

D0302_M3-4.doc Final / M3.4 19.12.2002


5.3.2.4 WCDMA to IP relay block The WCDMA to IP relay block will receive the IP packets from the WCDMA driver via a raw socket interface, and transmit them to the Ethernet Driver via a raw socket interface. We will use the message IWF_IP_PACKET for the interface between the RCM and the IWF.

IWF

WCDMA to IP relay

RCM RCM Packet Reception

Control Packet

Data

Packet

Packet Reception

Control Packet

Data

Packet

RCF RCF


Send / Receive

Data


Send / Receive

Data

Data Channel Mngt

Send / Receive

Data

Open /

Close

DataChannels

Data Channel Mngt

Send / Receive

Data

Open /

Close

DataChannels

AS

RCM Ethernet driver

IP stack

Figure 43 : WCDMA to IP relay block

D0302_M3-4.doc Final / M3.4 19.12.2002


5.3.3 IP stack The IP stack will be the basic IPv6 stack from the Linux kernel, with no specific functionalities related to Mobility and AAA. As regards QoS, the DSCP marking software is not needed, as the IP signalling packets generated by the IWF will be addressed only to the corresponding Access Router. The IP traffic received from the Mobile Terminal by the WCDMA driver will be sent by the IWF to the Ethernet driver, to be forwarded to the Access Router (raw socket interfaces will be used between the IWF and the W-CDMA / Ethernet drivers). The IP traffic received from the Access Router by the Ethernet driver will not be handled by the IP stack, but by the IP to W-CDMA relay block. Depending on its kind, it will be treated by this block, or transmitted to the W-CDMA driver (via a raw socket interface), to be sent to the Mobile Terminal. The only exception is the IP packets for the Radio Gateway QoS Attendant (exchanged with the QoS Broker and the QoS Manager on the Access Router), which will go through the IP stack.

5.3.4 Radio Channel Manager RCMRCM

Packet Transmission

Data Packet

Control Packet

Packet Transmission

Data Packet

Control Packet

Packet Reception

Control Packet

Data Packet

Packet Reception

Control Packet

Data Packet

Radio Connection


Broad casting

Open /Close

Conn

Paging

Figure 44 : Radio Channel Manager

The Radio Channel Manager is the generic part of the Radio driver. It provides a generic interface to the IWF and to the IP stack. It provides also a generic interface to the lower layer of the Radio driver: the Radio Convergence Function.

5.3.4.1 Radio Connection Manager block

5.3.4.1.1 Broadcasting sub-block It will transmit the broadcast requests from the IWF, message IWF_BROADCAST_REQ, directly to the Broadcasting sub-block of the RCF. 5.3.4.1.2 Paging sub-block It will transmit the paging requests from the IWF, message IWF_PAGING_REQ, directly to the Paging sub-block of the RCF. 5.3.4.1.3 Open / Close connection sub-block The Open / Close Connection sub-block manages the Radio Connections with Mobile Terminal. The connections are always opened on the initiative of the Mobile Terminal. When the Open / Close Connection sub-block of the RCF opens a connection, it will transmit the message OPEN_WCDMA_CONN_IND, to the Open / Close Connection sub-block of the RCM, which will transmit it to the Info Management block of the IWF. There will be two parameters: local connection reference and IMEI of MT. When a connection has been opened, the RCF of the MT sends a NAS signalling message to the RCF of the RG (NAS_CONNECTION_INFO), with the parameters: Home Address and CoA of MT. These information are passed to the Open / Close Connection sub-block of the RCM, with the associated local connection reference, via message OPEN_WCDMA_CONN_INFO. Then this message OPEN_WCDMA_CONN_INFO is forwarded to the Info Management block of the IWF, with the parameters: local connection reference, Home Address and CoA of MT.

D0302_M3-4.doc Final / M3.4 19.12.2002


The association “local connection reference / Mobile Terminal Care Of Address” is important for IP packets received from the Access Router, to be transmitted to a Mobile Terminal: a match is searched between the destination address of the IP packet and the list of Care Of Address, and the associated connection reference is used to send the packet on the proper radio bearer to the Mobile Terminal. The connections are always closed on the initiative of the Mobile Terminal. When the Open / Close Connection sub-block of the RCF closes a connection, it will transmit the message CLOSE_WCDMA_CONN_IND, to the Open / Close Connection sub-block of the RCM, which will forward it to the Info Management block of the IWF. There will be one parameter: local connection reference. When the Open / Close Connection sub-block of the RCF detects a connection loss, it will transmit the message LOST_WCDMA_CONN_IND, to the Open / Close Connection sub-block of the RCM, which will forward it to the Info Management block of the IWF. There will be one parameter: local connection reference.

5.3.4.2 Packet Transmission block The connection must have been opened by the Radio Connection Manager sub-block, before any IP packet can be transmitted (if it’s not the case, they will be dropped: this can only happen with packet arriving from the Access Router, and there is nothing we can do if the MT has not opened the connection yet). An open connection means that the RCF has also established all the associated radio control channels, but that no radio bearer has been pre-established. In case of connection loss, we do nothing on the Radio Gateway side (the IP packets from the Access Router to the Mobile Terminal will be lost). The connection loss will be detected on the Mobile Terminal side too, and a new connection will be established on its initiative, if appropriate. In case of Fast Handover, it might be necessary to buffer IP packets from the new Access Router, during the bi-casting phase, before the new connection between the Mobile Terminal and the Radio Gateway is established. In fact, the problem happens only for a Fast Handover between two Radio Gateways, where there is a time interval during which the MT has closed its connection to the old RG and not opened yet the connection to the new RG (the MT can handle a connection to only one RG at the same time). From an implementation point of view, there is nothing simple we can do, as the RGs are not aware of a Fast Handover taking place. Therefore, we accept to loose a “certain” number of packets in this specific case. The Packet Transmission block receives IP packets from the IWF via a raw socket interface, using the message IWF_IP_PACKET. The associated local connection reference will be used to determine to which MT (radio connection in fact) it is associated. Then it will determine if it is an IP signalling packet or an IP data packet, by analysing its DSCP code (the IP signalling packets have a DSCP corresponding to a specific class). The IP signalling packets are transmitted directly to the Control Channel Management block of the RCF (with the local connection reference). The data packets are analysed to perform the mapping between IP QoS classes and radio bearers / radio QoS classes: based on the DSCP code of the IP packet, a radio bearer is selected, with a radio QoS class associated to it. The RCM manages a fixed number of radio bearers per MT, each one associated to one of the radio QoS class available (see section 6.7). These radio bearers will be: 0—4 for signalling channels, 5—31 for data channels. At the RCM level, a table will be stored for each MT identified by its local connection reference, with for each valid DSCP code, the associated [bearer id, Radio QoS class, SAP id]. If the radio bearer is not yet established, the QoS Broker “is about to” send the characteristics of this radio bearer to the IWF, which will forward the information to the RCF with message RADIO_ACCESS_ALLOCATION. In the meantime, we will store the IP packets. When the message RADIO_ACCESS_ALLOCATION is received from the IWF, we update the RCM table and a request is made to the Data Channel Management block of the RCF to establish the radio bearer, with the local connection reference, the radio bearer Id, the radio QoS class, the DSCP code, as parameters.

D0302_M3-4.doc Final / M3.4 19.12.2002


An answer is expected from the RCF, to give the status of this operation, upon which the radio bearer is declared established or not. The answer will contain the local connection reference, the DSCP code, the radio bearer Id and a SAP Id as parameters. If it is established, the IP data packets can be transmitted to the Data Channel Management block of the RCF (with the local connection reference, the radio bearer Id and SAP id), to be sent on the radio bearer by the AS. The RCM can also receive the message RADIO_ACCESS_ALLOCATION from the QoS Attendant of the IWF, when a request from a MT to open a radio bearer associated to this DSCP code has been sent to the QoS Broker. We will use the same process as for an incoming IP packet, which has been described before (mapping between DSCP / radio bearer + radio QoS class, update of RCF table, and request to the RCF to open the radio bearer). The RCM can also receive the message RADIO_ACCESS_ALLOCATION from the QoS Attendant of the IWF, in the Fast Handover case (a specific value of parameter status will identify this situation). In this case, we receive a list of the currently used DSCP codes, and their associated radio QoS classes. We will store this information in the RCM, and when the radio connection between the MT and RG is opened (as a part of the Fast Handover process), we will use these data to establish the radio bearers, at the same time we establish the radio connection.

5.3.4.3 Packet Reception block The IP signalling packets and the IP data packets received from the RCF are transmitted to the IWF via a raw socket interface, using the message IWF_IP_PACKET.

5.3.5 Radio Convergence Function RCF RCF


Send / Receive

Data


Send / Receive

Data

Data Channel Mngt

Send / Receive

Data

Open / Close

Data Channels

Data Channel Mngt

Send / Receive

Data

Open / Close

Data Channels

RadioConnection


Broad casting

Open / Close

Conn

Paging

Figure 45 : Radio Convergence Function

The Radio Convergence Function is the specific part of the Radio driver. It has a generic interface with the upper layer of the Radio driver: the Radio Channel Manager. It has a specific interface with the Access Stratum, to take into account the specificities of the W-CDMA AS layer.

5.3.5.1 WCDMA Connection Manager block

5.3.5.1.1 Broadcasting sub-block It will transmit the broadcast requests from the RCM, message IWF_BROADCAST_REQ, to the AS, via message INFORMATION_BROADCAST_REQ, with the information to be broadcasted and the period as parameters. Two types of information can be broadcasted: Router Advertisement and list of IP addresses of each neighbouring Access Routers (as explained in the IWF description). Each type of message to be broadcasted will have a specific period, stored as local information in this sub-block. For the Router Advertisement, we will broadcast them once, every time it is received by the RG. For the list of IP addresses, a reasonable value is in the order of a few seconds (to be refined during integration tests). Note that we could broadcast any other information of interest for the Mobile Terminal Non Access Stratum or upper layers (MIPv6 stack, MTNM, Fast Handover module…).

D0302_M3-4.doc Final / M3.4 19.12.2002


5.3.5.1.2 Paging sub-block It will transmit the paging requests from the RCM, message IWF_PAGING_REQ, to the AS, via message PAGING_REQ, with the local connection reference and the IP paging packet (and its length) as parameters. 5.3.5.1.3 Open / Close connection sub-block The Open / Close Connection sub-block manages the Radio Connections with Mobile Terminals. The current number of Mobile Terminals connected to the Radio Gateway will be stored locally, and a maximum number will be defined. The connections can only be opened on the MT initiative. Upon reception of the message CONNECTION_ESTABLISHMENT_IND from the AS (parameter: local connection reference, IMEI of MT), the current number of MT connected will be compared to the maximum number allowed. The connection request will be accepted if it is lower, and refused otherwise. The message CONNECTION_ESTABLISHMENT_CONF will be sent to the AS, to be transmitted to the MT. The parameters are: the local connection reference and the status (connection accepted or refused). A local list containing all the MT connected will be updated with the local connection reference of the newly connected MT. The message OPEN_WCDMA_CONN_IND, with parameter local connection reference and IMEI of MT, will be transmitted to the RCM, to be sent to the IWF Info Management block. When the connection has been opened, the RCF of the MT sends a NAS signalling message (DATA_TRANSFER_IND with specific type NAS_CONNECTION_INFO) to the RCF of the RG, with the parameters: Home Address and CoA of MT. These information are passed to the Open / Close Connection sub-block of the RCM, with the associated local connection reference, via message OPEN_WCDMA_CONN_INFO. The connections can only be closed on the MT initiative. Upon reception of the message CONNECTION_RELEASE_IND from the AS (parameter: local connection reference), a request to release every radio bearer associated to the connection will be sent to the AS, via message (one per bearer) RADIO_BEARER_RELEASE_REQ (parameters: local connection reference and radio bearer id). This may not be necessary: the bearers may be released automatically by the AS. The local list containing all the MT connected will be updated by suppressing the local connection reference. The message CLOSE_WCDMA_CONN_IND, with parameter local connection reference, will be transmitted to the RCM, to be sent to the IWF Info Management block. Upon reception of the message CONNECTION_LOSS_IND from the AS (parameter: local connection reference), the connection with the associated MT will be considered as lost. The local list containing all the MT connected will be updated by suppressing the local connection reference. The message LOST_WCDMA_CONN_IND, with parameter local connection reference, will be transmitted to the RCM, to be sent to the IWF Info Management block. In this case, I consider there is no need to release the radio bearers: they are lost too. In the case of a Fast Handover, with the Radio Gateway as target, the message CONNECTION_ESTABLISHMENT_CONF will contain the list of radio bearers to establish and their Radio QoS class, based on the DSCP codes currently used by the MT. The AS will automatically re-establish these radio bearers. For this, we will use the information stored by the RCM, upon reception of message RADIO_ACCESS_ALLOCATION, as described in chapter Packet Transmission block.

5.3.5.2 Control Channel Management block When a connection is established with a Mobile Terminal, a radio control channel is automatically allocated. Therefore there is no need to open / close control channels. Any IP control packet received from the RCM (with the associated local connection reference) is transmitted to the AS, via message DATA_TRANSFER_REQ, to be transferred to the Mobile Terminal on the radio control channel. Any radio control packet received from the AS, via message DATA_TRANSFER_IND, containing IP signalling, is transmitted to the RCM Packet Reception block.

D0302_M3-4.doc Final / M3.4 19.12.2002


The parameter data of the DATA_TRANSFER_REQ and DATA_TRANSFER_IND will be a specific message type (NAS_IP_SIGNALLING), to identify the content of the AS message as IP signalling. This IP control packet can be pure IP protocol signalling, and also specific signalling for AAA and mobility. Some signalling specific to the NAS can also be exchanged between the Mobile Terminal and the Radio Gateway, using a specific message type for the parameter data of the DATA_TRANSFER_REQ and DATA_TRANSFER_IND messages. This will not be addressed here, but directly in the chapters where this signalling is used.

5.3.5.3 Data Channel Management block

5.3.5.3.1 Open / Close Data Channels sub-block When the connection is established with a Mobile Terminal, no radio bearer is established. Upon reception of a request from the AS to open a radio bearer, issued by a Mobile Terminal, via message DATA_TRANSFER_IND, the QoS Attendant in the IWF will be contacted via message IWF_RADIO_BEARER_REQ. The parameter data of the DATA_TRANSFER_IND message will be of a specific type (NAS_RADIO_BEARER_ESTABLISHMENT_REQ), to recognize the radio bearer establishment request, with the DSCP code, the IP source and destination address of the original packet on the MT, as parameters. These DSCP code, source and destination address, and the local connection reference will be transferred in the message IWF_RADIO_BEARER_REQ, to the IWF QoS Attendant. The IWF QoS Attendant will contact the QoS Broker, and wait for its answer, as already explained in a previous chapter. Upon reception of a request from the RCM to open a radio bearer, the AS will be notified via message RADIO_BEARER_ESTABLISHMENT_REQ, with parameters: local connection reference, radio bearer id, radio QoS class. This request will be sent to the MT by the AS. The acknowledgement from the AS that the radio bearer has been opened will be transmitted by the AS, via message RADIO_BEARER_ESTABLISHMENT_CONF, with parameters local connection reference, radio bearer Id, SAP Id. An acknowledgement that the radio data bearer has been established will be given to the Packet Transmission block of the RCM, so that the transmission of IP packets can start (with parameters local connection reference, radio bearer Id and SAP Id). Note that the request from the RCM to establish the radio bearer will follow the reception of the message RADIO_ACCESS_ALLOCATION, as already explained in a previous chapter. And this request can be originally triggered, either by a request from a MT to open a radio bearer, or a request originating from the Access Router. The radio bearers will be released by the WCDMA Connection Manager block of the RCF, when a connection is closed, if needed (this may be done automatically by the AS when the connection is closed). In the case that a radio bearer has not been used for a certain time, the AS will take care of reallocating the associated radio resources. 5.3.5.3.2 Send / Receive Data sub-block The Send / Receive Data sub-block manages the sending and reception of data packets to and from the AS. When an IP data packet is received from the RCM, with the associated radio bearer id and SAP Id, the radio bearer is already opened (this has been taken care of in the RCM, before transmitting this packet). Therefore, the RCF directly makes a PDCP_DATA_REQ to the AS on the appropriate SAP, to transfer the data packet to the Mobile Terminal, with parameters radio bearer id, data packet length and data packet. When an IP data packet sent by the Mobile Terminal is received from the AS via message PDCP_DATA_IND, with parameters: local connection reference, data packet length and data packet; this IP data packet is directly transmitted to the Packet Reception block of the RCM.

5.3.6 W-CDMA Access Stratum To enhance readability, this section has been included in section 5.1.9 "W-CDMA Access Stratum".

D0302_M3-4.doc Final / M3.4 19.12.2002


5.4 Home Agent According to the current Moby Dick specifications, the one and only component of the Home Agent is the provision of macro mobility, as provided by the MIPL Mobile IPv6 stack. The components of the Home Agent are illustrated in Figure 46: Home Agent Software Architecture. NCP IPv6 stack

IPSec Diffserv

Capability

NCP Mobile IPv6 stack

MIPv6 Home Agent functionality

NCP Network Device Driver

Ethernet (or W-LAN or W-CDMA)

Figure 46: Home Agent Software Architecture.

The Mobile IPv6 Home Agent acts as proxy for in its home network registered roaming Mobile Nodes. The required interface to the IPv6 is already provided by MIPL home agent functionality.

5.4.1 MIPL MIPL (Mobile IPv6 for Linux) is a Mobile IPv6 implementation that was elaborated within the frame work of the GO/Core research project at the Helsinki University of Technology (HUT). The first version (0.5.1) was released in 1999 and has been, since that time, permanently upgraded according to the changes of the Mobile IPv6 specification (IETF Internet Draft). The MIPL implementation is open source and could be downloaded from the following URL: www.mipl.mediapoli.com. Moby Dick makes use of the MIPL version 0.9.1, which was developed for Red Hat distribution and requests Kernel Version 2.4.16. It is based upon the Mobile IPv6 Draft number 15, published in July 2001, which has, at the time of writing, been superseded by version 18, published in June 2002. Since the MIPL version referred to above does not entirely support the registration of an "alternate care-of address" by means on the mechanisms described in the Mobile IPv6 IETF draft, this functionality has been added. The additional code, that enables the mobile node to register a care-of address, which is different to it's source address used in the foreign network (CoA), with its HA, is available as a patch to the MIPL supporting kernel. Also the user-space tool "mipdiag", that enables the user retrieving information on Mobile IPv6 related statistics from the kernel, has been extended to display the alternate CoA specific information. The latter support can be added also by means of a patch to the userland directory of the MIPL source code. To add this functionality properly was required, since the IP paging concept proposes to make use of the alternate CoA registration support to allow for registration of the Paging Agent as recipient of initial user-data packets when the respective mobile terminal is about to enter the dormant mode.

D0302_M3-4.doc Final / M3.4 19.12.2002


Network Device Drivers

Ethernet

Enhanced IPv6 stack

IPSec

Standard IPv6 stack

IP paging module

Paging Agent Functional Component

Tracking Agent

Component Dormant

Monitoring Agent Comp.

MT

AR

AAAC.f

5.5 Paging Agent

Figure 47: Paging Agent Software Architecture.

The protocol interface to the AAAC.f , as illustrated in the figure above, can be used optionally according to the paging concept (see section 4.8) when the proposed security mechanisms are supported. This interface will not be implemented and used in the Moby Dick test-bed

5.5.1 Dormant Monitoring Agent Functional Entity (DMA) The Dormant Monitoring Agent function is responsible to capture/receive user-data traffic, destined for dormant mobile terminals. In Moby Dick, this function is co-located with the Paging Agent node, since with a Mobile IPv6 system, the concept deploys the registration of the PA node address as alternate CoA with the HA for dormant mobile terminals. Therefore, initial packets, destined for dormant mobile terminals, are forwarded from the HA to the PA by means of IP-IP encapsulation. The DMA function receives the tunnelled packets and represents a temporary tunnel endpoint for the HA originated tunnel. User-data packets address information will be processed and it is checked, whether or not the actual addressed node has registered as dormant with the PA before. If the address cannot be matched with one of the registered mobile terminals, the packet has to be dropped and an ICMPv6 Error message has to be sent, indicating that the destination is not reachable. If the user-data packet addresses a mobile terminal registered as dormant with the PA, the DMA function has to buffer the packet and check a previously set individual filter function, indicating whether or not this type of packet is allowed to trigger a paging procedure. As a default function setting, this filter allows all packet types and addressing types to re-activate the addressed dormant mobile terminal. During a paging process, the packet is to be buffered and after the current location has been found out through the paging mechanisms, the DMA has to re-address the packet and forward it to the current location of the addressed mobile terminal by means of IP tunnelling. The configuration of the packet filter function, as described briefly above, will not be implemented in the Moby Dick test-bed, but is for future optimization. Hence, all kind of user-data packets, addressing a dormant mobile terminal and being forwarded from the HA to the PA, will initiate paging the mobile terminal. The size of buffers, which should be available for storing user-data packets temporarily for individual registered mobile terminals during a paging process, should be configurable for an administrator.

D0302_M3-4.doc Final / M3.4 19.12.2002


5.5.2 Tracking Agent Functional Entity (TA) The Tracking Agent is responsible for tracking a dormant mobile terminal’s location. Paging area registrations and updates are to be processed by this functional block. The paging area update message can be either originated from the MT or from the paging attendant implemented in a paging area’s Access Router. In case the DMA receives a validated user-data packet (paging trigger packet) destined for a registered dormant mobile terminal, the DMA requests the TA to initiate the paging process. The TA checks for the paging area the dormant mobile terminal has registered with. The TA initiates paging the mobile terminal by telling the registered paging area to the PA-function. After a successful page, the TA gets information from the PA-function about the current location of the paged mobile terminal. The location information is given to the DMA function to allow forwarding of buffered paging trigger packet for the addressed mobile terminal.

5.5.3 Paging Agent Functional Entity (PA) The Paging Agent function is responsible for generation and distribution of generic IP paging messages. The paging request signalling messages address all paging attendants implemented in a registered paging area’s set of Access Routers. The Paging Agent function receives a notification from the TA function to page an individual mobile terminal. Addressing a paging area: If the registered paging area comprises N Access Routers, N IP paging request messages have to be generated and are to be distributed to the paging area’s ARs. If static paging areas are deployed, a multicast tree could be set up for each set of ARs building a paging area. In the latter case, the PA addresses one IP paging request message to the paging area’s multicast address. The deployment of multicast addressing of paging areas won’t be deployed within the Moby Dick project. Rather lists of ARs access interface addresses are maintained in the Paging Agent node.

6. Interface Specifications For each interface identified, part of the WP3 implementation, this section describes the message contents and format. Again, unless explicitly mentioned: - everything that appears in this specifications will be implemented in the test bed, - anything that is not in the specifications will NOT be implemented.

6.1 MT NCP & MT MTNM

6.1.1 Description The messages exchanged between the NCP and the MTNM consists in:

• User preferences for network technologies and Handover type. • Explicit network connection / de-connection request. • Manual Handover request. • Network Environment info (including paging).

6.1.2 Interface mechanisms The NCP is a user space Linux module and the MTNM as well. The messages exchanged between NCP and MTNM will use FIFOs: one specific on the NCP side (read by NCP and written by MTNM) and one specific on the MTNM side (read by MTNM and written by NCP and other modules).

6.1.3 Interface contents Source Dest Primitive Parameters

NCP MTNM START_NETWORK_CONNECTION User login, user password

D0302_M3-4.doc Final / M3.4 19.12.2002


MTNM NCP START_NETWORK_CONNECTION_ACK Status

NCP MTNM TERMINATE_NETWORK_CONNECTION None

MTNM NCP TERMINATE_NETWORK_CONNECTION_ACK

Status

Source Dest Primitive Parameters

NCP MTNM MANUAL_HANDOVER_REQ Target Network technology

MTNM NCP MANUAL_HANDOVER_ACK Status


MTNM NCP AUTOMATIC_HANDOVER_ACK Status


NCP MTNM SET_NETWORK_PREFERENCES First choice, second choice, third choice

(Choice is among Ethernet, WLAN and WCDMA) Source Dest Primitive Parameters

NCP MTNM SET_HANDOVER_PREFERENCE Preference

(Preference is among manual, automatic, both) Source Dest Primitive Parameters

MTNM NCP NETWORK_ENVIRONMENT_INFOS Update for Ethernet (yes or no), Ethernet present (yes or no), Update for WLAN (yes or no), WLAN signal to noise ratio (0 if absent), Update for WCDMA (yes or no), WCDMA signal level (0 if absent).

MTNM NCP NETWORK_TECHNOLOGY_IN_USE Network technology currently used + current Access Router subnet prefix


NCP MTNM SET_PAGING_STATE State (active or dormant)

MTNM NCP PAGING_STATE_INFO State (active or dormant)

D0302_M3-4.doc Final / M3.4 19.12.2002


6.2 MT MTNM & MT NDD

6.2.1 Description The 3 possible network drivers are considered: Ethernet, WLAN and WCDMA. Two kinds of messages are exchanged:

• Network Environment information. • Network Environment management.

6.2.2 Interface mechanisms The interface between the MTNM and WCDMA driver will be based on a raw socket interface. The interface between the MTNM and the monitoring extensions to the WLAN driver will be based on a character device. The interface between the MTNM and the monitoring extensions to the Ethernet driver will be based on FIFOs: one specific on the MTNM side (read by MTNM and written by Monitoring) and one specific on the Monitoring side (read by Monitoring and written by MTNM).


WCDMA MTNM WCDMA_INFO List of: cell id, signal level, IP address of Access Router linked to Radio Gateway

MTNM WCDMA OPEN_WCDMA_CONN Cell id, Home Address of MT, CoA of MT, Fast Handover optimisation flag

WCDMA MTNM OPEN_WCDMA_CONN_ACK Local connection reference, status

MTNM WCDMA CLOSE_WCDMA_CONN Local connection reference

WCDMA MTNM CLOSE_WCDMA_CONN_ACK Local connection reference, status

WCDMA MTNM LOST_WCDMA_CONN Local connection reference


WLAN MTNM WLAN_INFO List of: signal to noise ratio, IP address of associated Access Router, and respective subnet prefix

MTNM WLAN USE_WLAN_AR IP address of AR and respective subnet prefix

WLAN MTNM USE_WLAN_AR_ACK Status


Ethernet MTNM ETHERNET_INFO Present or absent, IP address of associated Access Router

D0302_M3-4.doc Final / M3.4 19.12.2002


6.3 MT MTNM & MT Fast Handover module

6.3.1 Description The messages exchanged will be the triggering of the fast handover by the MTNM, the acknowledgement from the fast handover module, and the possibility to cancel the procedure.

6.3.2 Interface mechanisms The interface will use netlink sockets.


MTNM FH START_FHO IP address of new Access Router, IP address of current Access Router, new Layer 2 interface name, current Layer 2 interface name

FH MTNM FHO_ACK Status

FH MTNM L2_REQ None

MTNM FH L2_ACK Status

6.4 MT MTNM & MT Registration module

6.4.1 Description The messages exchanged will be the triggering of the initial registration procedure, and the intra-domain handover procedure.

6.4.2 Interface mechanisms The Registration module is a user space Linux module and the MTNM as well. The messages exchanged between Registration module and MTNM will use FIFOs.


MTNM Reg START_REGISTRATION Home Address of MT, CoA of MT, Access Router IP address, user login, user password (secret key)

Reg MTNM REGISTRATION_ACK Status

6.5 MT MTNM & MT Paging module

6.5.1 Description Some information is to be exchanged between the MTNM and the IP Paging module on the mobile terminal. Currently, primitives are specified to set high-level state information within the MTNM from the paging module (active/dormant). Furthermore, the paging module can learn about the current Access Router from the MTNM by means of appropriate request and reply primitives. This is in order to set AR attendant addressing information correctly. Optionally, the paging module can retrieve information on the mobile terminal's access interface types, their presence and the respective MAC address of each

D0302_M3-4.doc Final / M3.4 19.12.2002


individual interface. Furthermore, for NCP-based control on requesting mobile terminal initiated dormant or active state transition, the MTNM can send a respective notification message to the paging module.

6.5.2 Interface mechanisms Bi-directional communication between the MTNM and the IP paging module requires implementation of an appropriate interface allowing exchange of message primitives between user-space processes and kernel modules. The commonly used character device driver interface is used for this purpose, allowing the MTNM in user-space to communicate to the paging module in the kernel in a bi-directional way. This allows for polling the paging module from the MTNM for messages as well as writing messages to the paging module.


Page Mod MTNM SET_STATE_INFO Active, dormant flags

Page Mod MTNM INFO_REQ Flags

MTNM Page Mod INFO_REPL Current Access Router's IP address, list of access interfaces, type and presence indicator plus MAC address info.

MTNM Page Mod NOTIFY_MSG Flags (indication for dormant transition request or active transition request)

6.5.4 Format of the messages Each message comprises a 8 bit type indicator, a 8 bit length indicator as well as a message specific variable length context field.

In the following description, Reserved fields and 0-bits are currently not used. They are for padding purposes or for future use.

SET_STATE_INFO context:

[Reserved] 8 bit

[Flags] 8 bit

Details on specific fields:

Reserved: Should be initialized with 0

Flags: [0 0 0 0 0 0 0 X] X=1: active, X=0: dormant

INFO_REQ context:

[Reserved] 8 bit

[Flags] 8 bit


Type Length Context

D0302_M3-4.doc Final / M3.4 19.12.2002


Flags: [0 0 0 0 0 0 0 X] X=1: provide updated MAC address list,

X=0: MAC address list will not be processed in the paging module

INFO_REPLY context:

[IPv6 address] 128 bit current AR's IPv6 address

[Reserved] 8 bit

[Ethernet_present] 8 bit

[Ethernet_MAC] 48 bit

[Reserved] 8 bit

[WLAN_present] 8 bit

[WLAN_MAC] 48 bit

[Reserved] 8 bit

[WCDMA_present] 8 bit

[WCDMA_IMEI] 48 bit



Ethernet present: [0 0 0 0 0 0 0 X] X=1: present, X=0: Not present

Ethernet MAC: 48 bit MAC address

Same rules are valid for the WLAN interface and the W-CDMA interface. For the W-CDMA interface, the IMEI is provided as L2 identifier.

NOTIFY_MSG context:

[Reserved] 8 bit

[Flags] 8 bit



Flags: [0 0 0 0 0 0 0 X] X=0: dormant transition request

X=1: active transition request,

6.6 MT NAS (RCF layer) / RG NAS (RCF layer)

6.6.1 Description This interface is used to transfer messages relevant to the NAS layer located in the RCM-RCF (WCDMA driver on the MT and RG). They can be of 3 types: IP control packets (pure IP protocol signalling and Mobility / AAA specific signalling), radio bearer establishment request and NAS connection info request.

6.6.2 Interface mechanisms The messages will be transferred by the AS of the WCDMA, using the DATA_TRANSFER_REQ and DATA_TRANSFER_IND messages. The Data parameters will be the NAS messages described in the next paragraph.

6.6.3 Interface contents

3 x Access Interface Descriptors

D0302_M3-4.doc Final / M3.4 19.12.2002



RCF MT

RCF RG

NAS_IP_SIGNALLING Type, size of packet, IP packet

RCF RG

RCF MT

NAS_IP_SIGNALLING Type, size of packet, IP packet

RCF MT

RCF RG

NAS_RADIO_BEARER_ESTABLISHMENT_REQ

Type, DSCP code, IP packet source address, IP packet destination address

RCF MT

RCF RG

NAS_CONNECTION_INFO Type, Home address of MT, CoA address of MT

The parameter type will be used to recognize which of these different types of messages is enclosed in the data parameter of the AS message.

6.7 MT/RG NAS (RCF layer) & MT/RG AS/W-CDMA

6.7.1 Description This section describes the primitives offered in the UMTS platform by the Access Stratum (AS) entities to the Non-Access Stratum (NAS) entities thru the Service Access Points shown in the figure below.

L3

C-plane signalling U-plane information

DC SAP

Radio Bearers

RRC

PDCP PDCP

RB MUX/DEMUX

Qos SAPs NT SAP GC SAP

Signalling Radio Bearers

Non Access Stratum

Access Stratum

Figure 48 : SAP interface between the Access Stratum and the Non Access Stratum

The modelling of the services provided by the Access Stratum follow the basic principles as set by ITU-T Recommendation X.210. In this recommendation the following figure is given as an example for peer-to-peer connection-mode services.

D0302_M3-4.doc Final / M3.4 19.12.2002


S e r v i c e U s e r A

S e r v i c e U s e r B

O S I - S e r v i c e - P r o v i d e r

R e q u e s t ( r e q u e s t o r . s u b m i t )

C o n f i r m ( r e q u e s t o r . d e l i v e r )

I n d i c a t i o n ( a c c e p t o r . d e l i v e r )

R e s p o n s e ( a c c e p t o r . s u b m i t )

Figure 49 Example of a peer-to-peer connection mode service

For connectionless-mode services the basic primitives are "request" and "indication".

6.7.2 W-CDMA driver interface mechanisms

6.7.2.1 Overview – environment The Access Stratum is implemented in software, from the physical to the networking layers. It is developed as a module of the Linux Operating System, under the control of RT-Linux, an open-source hard real-time operating system. The network layer functionality (NAS) is provided by standard Linux kernel’s IP stack and its extensions.

6.7.2.2 RT-FIFOs The communications between RT-threads (AS) and Linux processes (NAS, IP stack, …) could have used: • Signals (pthread_kill), • Interrupts, • shared memory • RT-FIFOs. RT-FIFOs have been selected. They are allocated in the kernel address space during the initialization of the module. The Read and Write operations are atomic and do not block. They are seen as ordinary character devices from Linux user and kernel processes. However, there is a static limit on their number (64…151). Each SAP is realized with an RT-FIFO. Because we are limited by their number, the RB SAPs that are described in the specifications are multiplexed into QoS SAPs. How does it work? We have defined 4 SAPs for carrying the data traffic, that we call QoS-SAPs (actually, there are 8 because FIFOs are unidirectional). When the request for a new Radio Bearer is issued, it contains the identification of the QoS traffic class, together with the identification of the future Radio Bearer. The QoS traffic class corresponds to the class mapped from one of the IP QoS classes (currently 8 data + 1 signalling defined in the Moby Dick framework) All the next messages related with the Radio Bearer Establishment recall this RB Id and associate it with a SAP Id. The SAP Id identifies the QoS SAP or FIFO to use. When the confirmation/ indication message is received, the NAS records which QoS-SAP Id to use when forwarding data for this Radio Bearer. All the Radio Bearers associated with the same traffic class are multiplexed/demultiplexed in the same QoS-SAP. The reverse multiplexing/demultiplexing action is performed on top of PDCP in the Access Stratum. Several sub- traffic classes (such as the BE11, BE12, BE13 classes defined in WP2) could be multiplexed in the same QoS-SAP. Due to hardware and W-CDMA frame processing, the mux/demux component may be interrupted while dequeueing the data in the FIFOs. Because of this, this component empties the FIFOs according to their priority order, the FIFO with highest priority being dequeued first at each occurrence of the routine. The priority order is determined according to the type of traffic of the QoS traffic class. Real time traffic has a higher priority than Background/ Best Effort type of traffic. The QoS SAPs and the RB mux/demux are shown in the figure below

D0302_M3-4.doc Final / M3.4 19.12.2002


QoS-SAPs

RB-SAPs

PDCP

PDCP

PDCP

PDCP

PDCP

PDCP

PDCP

PDCP

PDCP

PDCP

PDCP

PDCP

PDCP

PDCP

……

P1 P2 P3 P4

Figure 50 : QoS SAPs and the RB mux/demux component

The relationship between the QoS traffic classes and the Qos SAPs could be as described in the table below:

Name Class QoS-SAP P1 QoS-SAP P2 QoS-SAP P3 QoS-SAP P4 S1 EF X S3 AF21 X S4 AF11 X S4 AF12 X S4 AF13 X S5 BE11 X S6 BE12 X S7 BE13 X

The number of SAPs that will be opened in each station is equal to: • Mobile device :

• NT SAP : 1 instance (RX) • GC SAP : 1 instance (RX) • DC SAP : 2 instances (RX + TX) • QoS-SAP : 4 instances (one per UMTS traffic class ) * 2 (RX+TX) = Total of 8

• Radio Gateway : • NT SAP : 1 instance (TX) • GC SAP : 1 instance (TX) • DC SAP : 2x Nb Users (RX + TX) • QoS- SAP: 4 instances (one per UMTS traffic class ) * 2 (RX+TX) = Total of 8

The implementation interface uses standard functions such as mkfifo(), open(), read(), write(), close(), ….

6.7.2.3 Interface triggers This section describes our testing code in its current format. This is subject to change according to constraint from hardware. The test code is implemented as 2 modules:

1. the AS module which creates the RT threads and the RT-FIFOs 2. the NAS module (IPV6 driver) which opens the RT-FIFOs

The NAS module

when data is ready to send to the AS, the IP call a function in the device driver called hard_start_xmit()

D0302_M3-4.doc Final / M3.4 19.12.2002


when the AS has put data in the RT-FIFO, it raises an interruption (rtl_global_pend_irq(irq_num)) to the NAS, which then uses the netif_rx(skbuff) function to pass the data to IP.

The AS module

this module is scheduled on a regular basis, according to the frame timing when data is ready to send to the NAS, it calls rtf_put to put the data in the RT-FIFO and raises

an interrupt as described above. As part of its scheduled activities, it polls the Rx RT-FIFO to check if data is ready for reception.

6.7.3 Primitives and functions

6.7.3.1 RG broadcast service This service is provided to the Radio Gateway NAS, which can use it to broadcast on a regular basis the necessary information (e.g. Router Advertisement) to all the UEs in the cell. The period of broadcast can be defined independently for each SIB (System Information Block) in the System information Message. This primitive is transmitted via the GC-SAP. RG SAP-GC INFORMATION_BROADCAST_REQ NAS data packet , data length,

category, Period (one shot/time value)

UE SAP-GC INFORMATION_BROADCAST_IND NAS data packet , data length

Any type of data could be broadcasted. The category parameter indicates which type of data is transferred, helping the AS choose the correct SIB. The following have been identified: 6.7.3.1.1 Router Advertisement

The information “Router Advertisement IP packet” is included in the RRC message : SYSTEM INFORMATION with SIB1 This is the default SIB for NAS data to broadcast.

6.7.3.1.2 List of suitable neighbouring cells

The information “List of IP addresses of ARs associated to neighboring RGs” is included in the RRC message : SYSTEM INFORMATION with SIB18. We will modify the format of this block to include the list of neighboring RGs identified by their Cell_Id with their IP addresses instead of the PLMN identities. This list is entered statically in the Radio Gateway by the “operator”.

6.7.3.2 UE in Idle mode From a macroscopic point of view, the UE can be either in idle or in connected mode. This mode is known at NAS level. The Mobile Terminal (UE) is first switched on. Then it enters the “Idle” mode where it listens to the synchronization channel and then to the BCH. If several RGs are available for the first attachment, the one with the best signal level is chosen. After this first synchronization phase, the UE is “physically” attached to the RG. It is said to “camp on the cell”. It monitors the System Information messages broadcasted by the Radio Gateway (RG). When applicable, the UE RRC forwards the information received to the NAS entities. This applies mainly to System Information Blocks 1 (SIB1 contains NAS system information) and 18 (SIB18 contains the identities of neighbouring cells). This monitoring does not require the UE to be connected. The UE enters connected mode on NAS request (see section 6.7.3.3) when data must be transferred between the UE and the RG. It then continues to monitor the System Information messages.

6.7.3.3 UE transition to connected mode

6.7.3.3.1 RRC Connection Establishment NAS requests the UE to enter the connected mode via the Connection Establishment procedure. This procedure sets up the signalling radio bearers. This decision is taken by the NAS, which must keep track of the UE state: idle or connected. The NAS asks the AS to make the transition to connected mode with the following primitives.

D0302_M3-4.doc Final / M3.4 19.12.2002


UE SAP-DC CONNECTION_ESTABLISHMENT_REQ Local connection reference, Cell_ID

RG SAP-DC CONNECTION_ESTABLISHMENT_IND Local connection reference, UE_IMEI

RG SAP-DC CONNECTION_ESTABLISHMENT_CONF Local connection reference, status, list of RBs

UE SAP-DC CONNECTION_ESTABLISHMENT_RESP Local connection reference, status, UE_IMEI

The establishment of the RRC connection is performed at the RRC level using the RRC Connection messages described in [3] . This set of messages triggers the establishment of the signalling radio bearers RB0 to RB3. RB3 is reserved for the RRC messages carrying NAS Signalling Data Transfer. These data transfers are then mapped on a DCCH logical channel. Parameters: The local connection reference is defined by the NAS according to [4]: “The local connection references have only a local scope, and their values do not necessarily have any predictable relationship with the corresponding reference local to the other side, or with a reference used over some interface to multiplex the messages pertaining to the connection with messages pertaining to other connections.” This parameter is defined locally for each box and is not transferred on the radio link. The cell_id may be needed for the handover procedure, to identify to which RG the Access Stratum should connect. If missing (default), the Access Stratum connects to the best RG available. As defined in other documents, the IMEI of the UE may be used to build the IPV6 auto-configured address. The List of RBs is an optional parameter, used to reduce the handover delay. Note: We propose to transfer the IMEI in the CONNECTION_ESTABLISHMENT_RESP primitive in the MT and use a pre-defined value of 0000:0000:0000:0001 in the RG. This should be OK since there is one IP subnet per Radio Gateway 6.7.3.3.2 RRC Connection Release UE SAP-DC CONNECTION_RELEASE_REQ Local connection reference, release

cause

RG SAP-DC CONNECTION_RELEASE_IND Local connection reference, release cause

RG/UE SAP-DC CONNECTION_LOSS_IND Local connection reference

The parameter release cause is not mentioned in [4], but is specified in [3] with values such as normal event, pre-emptive release, congestion, user inactivity, directed signalling connection reestablishment …

6.7.3.4 UE in connected mode

6.7.3.4.1 Signalling Data Transfer This channel is used for NAS signalling data transfer only. RB3 is used for this purpose. RG / UE SAP-DC DATA_TRANSFER_REQ Local connection reference, priority (*),

Data length, Data

UE / RG SAP-DC DATA_TRANSFER _IND Local connection reference, priority (*), Data Length, Data

* In a first step, only RB3 is established. The priority mechanism performed using RB3 and RB4 as described in the specification is not implemented

D0302_M3-4.doc Final / M3.4 19.12.2002


6.7.3.5 User Data Transmission

6.7.3.5.1 Radio Bearer Establishment Prior to data transmission, a Radio Bearer must be established by the NAS. A NAS signalling message (NAS_RADIO_BEARER_ESTABLISHMENT_REQ) is sent from the UE to the RG inside a DATA_TRANSFER_REQ, 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. In standard UMTS, this implies two steps: PDP context Activation and then Radio Access Bearer establishment. In our platform, this has been streamlined to a single step: Radio Bearer establishment. We directly map Radio Access Bearers to Radio Bearers. This affects the way QoS parameters are converted. RG SAP-DC RADIO_BEARER_ESTABLISHMENT_REQ Local connection reference,

Radio Bearer Id, QoS traffic class, IPv6 DSCP code

UE SAP-DC RADIO_BEARER_ESTABLISHMENT_IND Local connection reference, Radio Bearer Id, SAP Id, QoS traffic class, IPv6 DSCP code

RG SAP-DC RADIO_BEARER_ESTABLISHMENT_CONF Local connection reference, Radio Bearer Id, SAP Id, status

Parameters: There are 27 Radio Bearer Ids available in the MT (range [5..31]) – In the RG, it depends on the number of users supported . It is determined by the NAS in the RG [4]. The QoS traffic class corresponds to the class mapped from one of the IP QoS classes (currently 8 data + 1 signalling defined in the Moby Dick framework) The SAP Id identifies the QoS SAP or FIFO to use. There are 4 QoS SAP defined, but since a FIFO is unidirectional, there are 2*4 = 8 QoS SAPIds available in each station. 6.7.3.5.2 Radio Bearer release RG SAP-DC RADIO_BEARER_RELEASE_REQ Local connection reference, Radio Bearer

Id

UE SAP-DC RADIO_BEARER_RELEASE_IND Local connection reference, Radio Bearer Id

In case of failure of the release of the Radio Bearer, the NAS is informed with a RADIO_BEARER_ESTABLISHMENT_CONF primitive. The Radio Gateway then moves back to the former radio configuration, as if nothing had happened. 6.7.3.5.3 User data transfer This primitive is used when a radio Bearer is ready for the transmission of IP data packets through the corresponding PDCP entity. UE / RG QOS-SAPx PDCP_DATA_REQ Radio Bearer Id , Data Length ,User Data

UE / RG QOS-SAPx PDCP_DATA_IND Radio Bearer Id , Data Length, User Data

6.7.3.6 Handover primitives The handover between two WCDMA cells is possible only if their Base stations (or RGs) can “hear” each other. They can then be synchronized. If it knows on which time slot to listen for the BCH, the physical layer of the Mobile Terminal is able to monitor and report the reception level of these neighbouring cells. Some measurements can be provided by the UE to the NAS when a predefined threshold is reached. This threshold may apply to one or several cells.

D0302_M3-4.doc Final / M3.4 19.12.2002


The MEASUREMENT_REQ message in the UE is used when the NAS wants to force the sending of signal RX quality in the absence of the threshold reached (the need for such a message is still under discussion). UE SAP-DC MEASUREMENT_IND Local connection reference, RGs RX quality –

Table (cell_ID, Quality level)

UE SAP-DC MEASUREMENT_REQ Local connection reference

6.7.3.7 Notification & paging primitives RG SAP-Nt PAGING_REQ UE Id (IP address, IMSI?), Data Length, Paging

information (IP packet)

UE SAP-Nt NOTIFICATION_IND Data Length, Paging information

In a first step, the Paging UE_Id is identical to the Local Connection Reference and the C-RNTI of the UE in the cell.

6.7.3.8 Format of the primitives As primitives flow independently on each SAP, we can define a specific format for each. A specific format is described in a C header file. When the primitive transfers some data, the FIFO operation is performed in two steps: first step for the primitive header as described in the header file, including the data length, second step for the data according to their presence and length.

6.7.4 Message Flows

RG Broadcast Service

NAS NASAS AS

User Equipment Radio Gateway

INFO_BROADCAST_REQ

(RRC) SYSTEM INFORMATION+ SIB1/SIB18

INFO_BROADCAST_IND

D0302_M3-4.doc Final / M3.4 19.12.2002


RRC Connection Establishment

NAS NASAS AS


CONN_ESTABLISH_IND

(RRC) CONNECTION REQUEST

CONN_ESTABLISH_REQ

CONN_ESTABLISH_CONF

(RRC) CONNECTION SETUP

CONN_ESTABLISH_RESP

(RRC) CONNECTION SETUPCOMPLETE

Signalling Data Transfer

NAS NASAS AS


DATA_TRANSFER_REQ

(RRC) DOWNLINK DIRECTTRANSFER

DATA_TRANSFER_IND

DATA_TRANSFER_REQ

(RRC) UPLINK DIRECTTRANSFER

DATA_TRANSFER_IND

Radio Bearer Establishment

(RRC) RB SETUP COMPLETE

NAS NAS AS AS


RADIO_BEARER_ESTAB_REQ

(RRC) RB SETUP

RADIO_BEARER_ESTAB _IND RADIO_BEARER_ESTAB _CONF

D0302_M3-4.doc Final / M3.4 19.12.2002


User Data Transfer

NAS NASAS AS


PDCP_DATA_REQ

(PDCP) DATA TRANSFER

PDCP_DATA_IND

PDCP_DATA_REQ

PDCP_DATA_IND

(PDCP) DATA TRANSFER

Radio Bearer Release

NAS NASAS AS


RADIO_BEARER_RELEASE_REQ

(RRC) RB RELEASE

RADIO_BEARER_RELEASE _IND

(RRC) RB RELEASECOMPLETE

6.8 MT Fast Handover & AR Fast Handover

6.8.1 Description After the decision for a fast intra-domain handover has been made within the MTNM module, the MT Fast Handover Module receives the respective trigger via a Netlink socket, which invokes the fast handover procedure, as described in this chapter. The fast handover mechanism includes communication between the Mobile Terminal and the old Access Router and between the old and the new Access Router, whereas all messages will be implemented as new type of ICMPv6. The inter-Access Router communication provides the structure for context transfer, although the respective parameters are still missing, because they are still under discussion at this point in time.

6.8.2 Interface mechanisms All signalling message primitives will be implemented as new ICMPv6 message types, which is one of the main differences between the IETF Internet Draft ‘Fast Handovers in Mobile IP’ and the Moby Dick Fast Handover approach. Although the deployment of IPv6 destination options (as proposed by the respective Internet Draft) would allow including the Fast Handover signalling messages in any existing packets by means of piggybacking, this would require modifications to the IPv6 stack. The deployment of ICMPv6 provides independence from the existing Mobile IPv6 code and IPv6 stack, since the Linux kernel allows the deployment of an own ICMPv6 message handler, which is independent from all other message handlers. This independence is important in order to facilitate further development.

D0302_M3-4.doc Final / M3.4 19.12.2002



MT OAR RT_SOL_PR • Source link layer address • New point of attachment link layer address • Handover Capability Extension

OAR MT PR_RT_ADV • Source link layer address • Link layer address of the proxy originator (i.e., NAR) • Handover Capability Extension • Prefix Information • New Care of Address option

• CT extension (to be specified)

OAR NAR HI • Link layer address of the MT • Old CoA • New CoA • Lifetime option


NAR OAR HACK • New CoA • Lifetime option


MT OAR FHE • CoA • Tunnel lifetime

OAR MT FHEACK

MT NAR NA • Standard Ipv6 Neighbour Advertisement with the target address set to the new CoA

Abbreviations of the ICMPv6 primitives • RT_SOL_PR Router Solicitation Proxy • PR_RT_ADV Proxy Router Advertisement • HI Handover Initiation • HACK Handover Acknowledgement • FHE Fast Handover Execute • FHEACK Fast Handover Acknowledgement • NA Neighbour Advertisement (standard IPv6)

6.8.4 Format of the messages The Router Solicitation Proxy, Router Advertisement, Handover Initiate and Handover Acknowledgement messages are defined in the Internet Draft ‘Fast Handovers for Mobile IP’. The primitives Handover Execute and the Handover Execute Acknowledgment are newly formed messages and ICMPv6 messages types. Router Solicitation Proxy (RT_SOL_PR) The message is sent with an IP header that uses as source address the current assigned Care of Address and the destination address of the IP packet is the address of the old Access Router or the all router multicast address.

D0302_M3-4.doc Final / M3.4 19.12.2002


Type Code Checksum

Identifier Reserved

Options ...

Figure 51 : Router Solicitation Proxy message format

Type: 145 Code: The code must be set to zero Identifier: An integer number set from the sender. It is used to match replies to this solicitation. Reserved: The reserved field must currently set to zero The Router Solicitation Proxy message has three valid options.

1. Source link layer address 2. New attachment point link layer address 3. Handover Capabilities Extension

Proxy Router Advertisement (PR_RT_ADV) The Proxy Router Advertisement is sent in reply to a Proxy Router Advertisement or it is sent unsolicited. The source address of the packet must be the link-local address assigned to the interface from which the message is sent. The destination address is the link local address of the Mobile Node that requests the handover.

Type Code Checksum

Identifier Reserved

Options ...

Figure 52: Proxy Router Advertisement message format

Type: 146 Code: Zero, one or two

Identifier: The identifier is copied from the Proxy Router Solicitation or it is set to

zero if the message is unsolicited.

Reserved: Must be set to zero There are five valid options.

1. Source link layer address 2. Link layer address of the proxy originator (e.g. new AR) 3. Handover Capabilities Extension 4. Prefix Information 5. New Care of Address option

Handover Initiate (HI) The source address of the message is the old Access Router global IPv6 address and the destination address is the IPv6 address of the new Access Router.

D0302_M3-4.doc Final / M3.4 19.12.2002


Type Code Checksum

Identifier Reserved

Options ...

S U H T R

Figure 53: Handover Initiation message format

Type: 147 Code: zero Identifier: the identifier must set from the old Access Router Flags:

• S: stateful address configuration flag • U: buffer flag • H: message was triggered by a layer 2 two party handover (see draft [17]) • T: message was triggered by a layer 2 handover • R: request to extend or cancel a tunnel

Reserved: Must be set to zero. There are 4 valid options.

1. link layer address of the Mobile Node 2. old Care of Address 3. new Care of Address 4. lifetime Option

Handover Acknowledgement (HACK) The source and destination addresses of the message are copied from the destination and source fields of the Handover Initiation message.

Type Code Checksum

Identifier Reserved

Options ...

H T R

Figure 54: Handover Acknowledgement message format

Type: 148 Code: 0- Handover Accepted, new CoA valid

1- Handover Accepted, -new CoA not valid 2- -new CoA in use 3- -new CoA assigned (stateful) 4- -new CoA not assigned 128- Hanover Not Accepted -Unspecified reason 129- -Administratively prohibited 130- -Insufficient resources

Flags: • H: Set if in response to a layer 2 handover • T: Set in response to a layer 2 two party handover • R: Set in response to a Handover request (layer 2 handover)

The two valid options are

1. New Care of Address 2. Lifetime Option

D0302_M3-4.doc Final / M3.4 19.12.2002


Fast Handover Execute (FHE) The Fast Handover Execute message is sent from the Mobile Node to the old Access Router. It informs the old Access Router that in any case a handover will be executed and it ensures also establishing a temporally tunnel between the old Access Router and the new Care of Address. For this, the valid options are the lifetime option for the tunnel lifetime and the new Care of Address for which the tunnel should be created.

Figure 55 : Handover Execute message format

Type: 149 Code: zero Identifier: the identifier must set from the old Access Router Reserved: must be set to zero. The valid options are:

1. Care of Address 2. Tunnel lifetime

Fast Handover Advertisement (FHEACK) The Fast Handover Acknowledgement message is sent from the old Access Router to the Mobile Node in order to inform it that a handover is allowed, the new Care of Address is valid and the tunnel is established.

Figure 56 : Handover Acknowledgement message format

Type: 149 Code: zero Identifier: the identifier must set from the old Access Router Reserved: Must be set to zero. Currently are no valid options for the Fast Handover Acknowledgement message defined. Neighbour Advertisement (NA) This message is standard IPv6. It will be sent to the NAR as soon as the MT gains layer-2 connectivity. The source address of the Neighbour Advertisement is the link local address of the Mobile Node and the destination address is the all nodes multicast address.

Type Code Checksum

Identifier Reserved Options ...

Type Code Checksum

Identifier Reserved

D0302_M3-4.doc Final / M3.4 19.12.2002


Figure 57 : Neighbour Advertisement message format

Type: 136 Code zero Checksum the ICMP checksum Flags: R: Router Flag

S: Solicited Flag O: Override flag

Reserved: Must be set to zero Target Address: For solicited advertisements the target address is one of the assigned addresses

of the interface In our case the target address is the new Care of Address of the Mobile Node.

In the following, the new ICMPv6 options are presented. IPv6 address option The IPv6 address option could be used from several ICMP messages to transport an IPv6 address. This could be for example the new or old Care of Addresses.

Type Length Sup-Type Prefix Length

Reserved

IPv6 Address

Figure 58 : IPv6 Address Option

Type: not specified but we use type 1 Length: length of the option in octets Sub-Type: 1 old Care of Address 2 new Care of Address Prefix Length: The length of the IPV6 address prefix Reserved: Must be set to zero IPv6 Address: The IP address for the unit defined by the type field

Type Code Checksum

Reserved

Target Address

Options ...

R S O

D0302_M3-4.doc Final / M3.4 19.12.2002


Prefix Information Option This option contains the address prefix and it is used in the Proxy Router Advertisement.

Type Length Prefix Length

Reserved

IPv6 Address

valid lifetime

preferred lifetime

L A R RES

Figure 59 : The Prefix Information Option

Type: not specified but we use type 1 Length: length of the option in octets Prefix Length: length of the Address Prefix Flags: L-flag: 1-bit on link flag A-flag: 1-bit autonomous address-configuration flag R-flag: Router address flag Valid Lifetime: The lifetime of the prefix in seconds Preferred Lifetime: The preferred lifetime in seconds Reserved: Must be set to zero IPv6 Address: The subnet prefix of the link or the Access Router address Link layer address option The link layer address option is used from the Router Solicitation Proxy, Handover Initiate and from the Proxy Router Advertisement message. It contains the link layer address of a specific interface.

Type Length Sup-Type Link Layer Addr.

Figure 60 : Link Layer Address Option

Type: not specified but we use type 1 Length: length of the packet Sup-Type: 1 link layer address of new attachment point

2 link layer address of the Mobile Node 3 link layer address of the proxy originator

Link Layer Address: the link layer address from the interface Lifetime Option The Lifetime Option contains the information of the lifetime for e.g. the IPv6 IP prefix of the Access Router or the lifetime of the tunnel for the bicasting.

D0302_M3-4.doc Final / M3.4 19.12.2002


Type Length Sup-Type Reserved

Lifetime

Figure 61: Lifetime Option

Type: 1 Length: length of the packet in octets Sub Type: 1 Prefix lifetime

2 Tunnel lifetime Reserved: Must be set to zero Lifetime: the lifetime in seconds Handover Capability Extension The Handover Capabilities Extension is an extension to the IPv6 Router Solicitation and Proxy Router Advertisement message. It indicates which handover the Mobile Node and Access Router supports.

Figure 62 : handover capabilities extension

Type: 1 Length: length of the packet in octets Code: 1 Sending node is capable of predictive Fast Handover

2 Sending node is capable of L2 trigger Based Fast Handoff

Reserved: Must be set to zero

6.9 MT Paging Module & PA PA/TA/DMA

6.9.1 Description In case of having a pre-established security association with the PA, the MT can communicate directly to the PA if the current AR lets the ICMPv6 message types passing through, either based on a previously established SA or administrative setting of AR filter functions. This can happen after the discovery phase (explicit dormant mode registration) as well as for paging area updating and dormant mode de-registration.

6.9.2 Interface mechanisms The remote entities deploy the ICMPv6 protocol as specified for the IP paging concept in Moby Dick.


MT PA DORMANT_MODE_REQ Message flags, HoA, CoA, paging area ID, common paging ID, registration lifetime

PA MT DORMANT_MODE_REPL Message flags, status code, HoA, CoA, paging area ID, common paging ID, registration lifetime, paging agent address

Type Length Sup-Type Reserved

D0302_M3-4.doc Final / M3.4 19.12.2002


6.9.4 Format of the messages The following figures illustrate the formats of the small ICMPv6 basic header for IP paging control messages. Most identifiers and variable length fields are encoded as options. The immediate following format illustrates message encoding valid for all REQUEST messages. Type: According to the IP paging message type.

To be specified. Type codes used in this project:

DORMANT MODE REQUEST 152 DORMANT MODE REPLY 153 PAGING REQUEST 154

Code: Set to 0 for all messages as described here for IP paging. Checksum: Calculated according to the ICMPv6 standard [7]. Sequence Number: Allows for correlating replies with requests. Flags: R: Reserved. To be initialised with 0. I: Implicit dormant registration U: Updating messages. Reserved: Reserved for future use. Options: One or more TLV-encoded option. Formant as described below, usage

according to the paging concept. In addition to the ICMPv6 header format of the REQUEST messages, REPLY messages have a status code field encoded, as illustrated ion the following message format:

Options

Reserved

Type Code CRC

R R R R R R I U

Sequence Number

0 31

Options

Reserved

Type Code CRC

R R R R R R I U

Sequence Number

0 31

Status Code

D0302_M3-4.doc Final / M3.4 19.12.2002


Value Type Length 1 byte 1 byte

Type: According to the IP paging message type. To be specified. Type codes used in this project:

DORMANT MODE REQUEST 152 DORMANT MODE REPLY 153 PAGING REQUEST 154

Code: Set to 0 for all messages as described here for IP paging. Checksum: Calculated according to the ICMPv6 standard [7]. Sequence Number: Allows for correlating replies with requests. Flags: R: Reserved. To be initialised with 0. I: Implicit dormant registration (1=Implicit registration). U: Updating messages (1=Updating message). Reserved: Reserved for future use. Status Code: Result of a request message. Currently specified 0x00 SUCCESS 0x02 USE EXPLICIT REGISTRATION

0xff ERROR Options: One or more TLV-encoded option. Formant as described below, usage

according to the paging concept. Most of the signalling message details are encoded as option, which allows carrying one or more options with the message, when needed. Options are encoded as generic TLV messages, as illustrated in the following figure.

Type: Option type identifier according to the table below. Length: Option length in octets, including the Type and the Length field. The following options will be implemented within the framework of the Moby Dick project. These do not include the security related options and some technology specific address options when not needed in the project’s testbed (e.g. IMSI, as described in [2]). The options referred to in the following table are required to be implemented to support basic deployment according to the IP paging scheme.

Option Value-Length Type IPv6 Home Address 16 0x01 IPv6 Care-of Address 16 0x02 IPv6 PA address 16 0x03 Common Paging ID Variable 0x04 Paging Area ID 4 0x05 Registration Lifetime 16 0x06 Home Agent Address 16 0x07

D0302_M3-4.doc Final / M3.4 19.12.2002


Sub-ID-header MAC-address fraction Sub-ID-header MAC-address fraction

ITI 4-bit

ILI 4-bit

Details on the format of the Common Paging Identifier can be found below. For IP paging, a common identifier is used. Its structure allows ARs to derive information, which is necessary to build the appropriate Solicited Node Multicast address for an individual mobile terminal on the respective technology. The identifier has the 24bit-identifier part of the MAC address for IEEE 802.3 and IEEE 802.11b included, for W-CDMA the 24bit terminal identifier part of the IMEI will be taken. To allow flexible deployment of the common identifier, each 24-bit identifier has a preceding 8bit-identifier to allow ARs to ascertain the appropriate identifier part for its respective access technology and to learn about the length of each identifier fraction.

Figure 63 : Common IP Paging Identifier building rule

ITI: Identifier Type Indication IEEE 802.3 0x1 IEEE 802.11b 0x2 W-CDMA 0x3 ILI: Identifier Length Indication In octets (example: 24-bit = 0x3) MAC address fraction: IEEE 802.3 24-bit LSB MAC address part IEEE 802.11b 24-bit LSB MAC address part W-CDMA 24-bit LSB IMEI terminal identifier part Taking the three interfaces as taken for the Moby Dick platform, the raw common identifier has a size of 96 bit (12 byte). This identifier will be conveyed in a TLV-encoded option, as briefly described below. The common IP paging identifier has a preceding unique header, which allows identification of the entire ID length (part of the TLV-encoded generic format), the provider as well as provision of an additional field to distinguish common IP paging identifier (ID Extension). The following illustration shows the common IP paging identifier header as well as the actual identifier for the three access technologies deployed within the Moby Dick project. The option type at the beginning identifier format indicates that the identifier is a common IP paging ID.

Figure 64 : Entire common IP Paging Identifier (header + ID)

Provider ID ID ExtensionLength Type

Sub-ID header

Sub-ID header

Sub-ID header

Ether MAC part

WLAN MAC part

W-CDMA IMEI terminal ID part

0 31

D0302_M3-4.doc Final / M3.4 19.12.2002


6.10 AR Paging Attendant & MT Paging Module

6.10.1 Description On initial registration with or discovery of the Paging Agent, the mobile terminal contacts the paging attendant in its current Access Router. The protocol messages for discovery and possibly implicit dormant registration as well as for implicit dynamic establishment of the paging related security association are specified as ICMPv6 headers and appropriate options.

6.10.2 Interface mechanisms The current access technology provides physical interfacing the mobile terminal to its current Access Router. The ICMPv6-based protocol, specified for building the paging control plane, is carried over this interface. Source Dest Primitive Parameters

AR MT PAGING_REQUEST Message flags, HoA, CoA, paging agent address, paging area ID, common paging ID

MT AR DORMANT_MODE_REQ Message flags, HoA, CoA, paging area ID, common paging ID, registration lifetime

AR MT DORMANT_MODE_REPL Message flags, status code, HoA, CoA, paging area ID, common paging ID, registration lifetime, paging agent address

6.10.3 Format of the messages Format is according to section 6.9.4.

6.11 AR Paging Attendant & RG IWF

6.11.1 Description To convey on-link paging control messages from the Access Router, implementing the paging attendant, to the IWF, implemented in the Radio Gateway, many mechanisms have been evaluated, like tunnelling mechanisms, UDP/IP encapsulation and RG addressing and IWF controlled re-addressing to the paged mobile terminal’s Solicited Node Multicast Address. The most transparent and realistic solution has been selected, keeping the complex paging related functionality within the paging attendant (processing of options, derivation and addressing of the technology specific solicited node multicast address, etc…). The paging attendant generates the PAGING_REQUEST message and provides also appropriate addressing of the dormant mobile terminal. Since the RG performs Proxy Neighbour Discovery for interception and mapping of Neighbour Solicitations and Neighbour Advertisements, the same mechanisms is deployed for interception of paging control messages. Only a further check on the respective ICMPv6 message types is to be performed to allow for mapping the control messages to the appropriate radio channel

6.11.2 Interface mechanisms Physically, the RG is connected to the AR through a wired Ethernet connection. The RG listens to dedicated ICMPv6 message types, either sent to a broadcast or multicast address. The protocol carried by the described mechanism is ICMPv6 encoded paging control messages.

D0302_M3-4.doc Final / M3.4 19.12.2002



AR RG PAGING_REQUEST Message flags, HoA, CoA, paging agent address, paging area ID, common paging ID

AR RG DORMANT_MODE_REPLY Message flags, status code, HoA, CoA, paging area ID, common paging ID, registration lifetime, paging agent address

RG AR DORMANT_MODE_REQ Message flags, HoA, CoA, paging area ID, common paging ID, registration lifetime


6.11.5 Flows Signalling flow is according to the diagrams as specified in section 4.8.

6.12 AR Paging Attendant & PA PA/TA/DMA

6.12.1 Description The generic, access technology independent IP paging protocol specifies appropriate control messages between the Paging Agent and the paging attendant, implemented in Access Routers.

6.12.2 Interface mechanisms Wired Ethernet interfaces the related components, providing transport for ICMPv6 encoded paging control messages.


PA AR PAGING_REQ Message flags, HoA, CoA, paging agent address, paging area ID, common paging ID

PA AR DORMANT_MODE_REPL Message flags, status code, HoA, CoA, paging area ID, common paging ID, registration lifetime, paging agent address

AR PA DORMANT_MODE_REQ Message flags, HoA, CoA, paging area ID, common paging ID, registration lifetime


6.12.5 Flows Signalling flow is according to the diagrams as specified in section 4.8.

D0302_M3-4.doc Final / M3.4 19.12.2002


6.13 AR Fast Handover & AR AAA attendant

6.13.1 Description In case of an intra-domain fast handover, re-establishment of related AAA context on the nAR is performed by transferring the related context between the oAR and the nAR. This requires control primitives to be exchanged locally between the AR’s Fast-HO module and the AAA attendant. Context has to be requested from the AAA attendant on the oAR on reception of the Router Solicitation for Proxy. To identify the respective mobile terminal, the oCoA is used as an identifier on the oAR. The context is to be attached to the Fast-HO CT extension and conveyed to the nAR through the HI message. On the nAR, the context is to be passed to the AAA attendant module, providing also the nCoA as identifier for the new binding. The following figure repeats the fast handover message flow, whereas the important messages for the AAA context transfer are numbered 3 and 5 and the colored messages, marked with A,B,C and X, are not considered in the following description. After the Mobile Terminal initialized the handover via the Proxy Router Advertisement (msg. 2), the FHO module should: Get the WP4 context from the AAAC on the oAR before Msg 3 (See Figure 65) Include the WP4 context in the Handover initiate (msg. 3) and sent it to the nAR Give the WP4 context to the AAAC attendant on the nAR (Figure 65) The context will consist of a TLV structure that is opaque to the FHO module. The parameters passed from the AAAC attendant to the MT registration module are also passed in a TLV structure.

10

1

MN oAR nAR nQoS.f AAAC.f HA

2

3

5

6

7 8

9

11 12 13

14

15

X

oQoS.f

A B

C

Figure 65: Fast Handover Signalling Flow

D0302_M3-4.doc Final / M3.4 19.12.2002


6.13.2 Interface mechanisms After the handover is initiated via the Proxy Router Advertisement (msg. 2) by the Mobile Node, the oAR needs the AAAC context before contacting the nAR and triggers the ATT to relay the AAAC context to the FHO module (see Figure 65: step 1), which is performed in step 2 (Figure 65). The context is included in the Handover initiate message to the nAR (step 3, Figure 65) where it is given to the respective AAA attendant in step4. The figure below shows the interaction between the different entities involved in detail. The kernel - user space communication, which is required for this interface, is implemented via a char-device. This device will be initialized and configured in the kernel; i.e., in the initialization phase of the FHO module.

1.

Trigger

ctxTran

Kernel

User Space

FHO Mod.

AAA Att.

2. CtxtoFHO

Old AR

Kernel

User Space

FHO Mod.

AAA Att.

4. CtxtoAtt

New AR

3. Handover Initiate

Figure 66: Interface between the Fast Handover Module and the AAA Attendant in the AR

On receiving a “Router Solicitation for Proxy” message form the MN, the FHO module at the old access router requests the AAA Attendant for the context associated with the MN. The FHO module executes the function “StartCtxTransfer” which contains identification of the message (MesgType) e.g. StartCtxTransfer, SendctxToAtt or SendctxToFHO and the length of this message. The parameters of the respective messages will be presented in detail below.


Fast-HO (oAR)

AAAatt (oAR)

StartCtxTransfer MesgType MesgLen

AAAatt (oAR)

Fast-HO (oAR)

SendCtxToFHO MesgType MesgLen Context (i.e., stream of bytes)

Fast-HO (nAR)

AAAatt (nAR)

SendCtxToATT MesgType MesgLen

D0302_M3-4.doc Final / M3.4 19.12.2002


Context (i.e., stream of bytes)

The contents of the context are as follows

Context { Auth-Lifetime }; { Session-Timeout }; /* what's left of it */ { ATT-MN-SPI }; { MIPv6-Mobile-Node-Address }; { MIPv6-CO-Address }; { AR-Address }; { MN-User-Name}; { Session-Id}; { ATT-MN-3DES-KEY}; { ATT-MN-SPI};

6.14 AR Fast Handover & AR QoS attendant

6.14.1 Description The Fast Handover modules, implemented in the Access Routers, handle fast handover related control messages. As specified in chapter 4 for the Fast Handover signalling flow, the oAR releases two further control messages on reception of the Router Solicitation for Proxy message. One message is related to the fast handover procedure and refers to the HI/HACK Fast-HO control message handshake between the oAR and the nAR. The second message that should be released is the QoS related control message initiating re-establishment of QoS context on the nAR and to convey QoS related information to the domains QoS brokers. This requires an appropriate local interface between the Fast-HO module and the QoS attendant, both implemented on Access Routers.

6.14.2 Interface mechanisms Control primitive exchange between Fast-HO module and QoS attendant function on Access Routers requires deployment of an appropriate interface for bi-directional user-space / kernel communications.


Fast-HO QoSattend QOS_HO_REQ oCoA, nAR address or respective ID, nCoA, Release execute indication flag.

QoSattend Fast-HO QOS_HO_REPL (to be checked if necessary)

QoSattend Fast-HO QOS_HO_IND Result info (resource reservation info, DAD check)

Fast-HO QoSattend QOS_HO_ACK (to be checked if necessary)

6.15 RG IWF / RG RCM-RCF

6.15.1 Description The messages exchanged between the IWF and the RCM / RCF consists in:

• The standard data and signalling IP packets. • The specific IP packets for the broadcast and paging radio channels. • The specific control messages for the radio.

D0302_M3-4.doc Final / M3.4 19.12.2002


6.15.2 Interface mechanisms The IWF is a user space Linux module and the RCF / RCM are integrated in a device driver (kernel space module). The messages exchanged between IWF and RCM / RCF will use a raw socket interface to the device driver.

6.15.3 Interface contents When I indicate RCF / RCM as a source, it means the message is generated by RCF, goes through RCM, and is passed to IWF. When I indicate RCM / RCF as a destination, it means the message is generated by IWF, goes through RCM, and is passed to RCF. Source Dest Primitive Parameters

IWF RCM IWF_IP_PACKET Local connection reference, packet size, IP packet

RCM IWF IWF_IP_PACKET Local connection reference, packet size, IP packet


IWF RCM/ RCF

IWF_BROADCAST_REQ Type of message, period (if needed), message size, message

IWF RCM/ RCF

IWF_PAGING_REQ Local connection reference, packet size, paging packet

For the IWF_BROADCAST_REQ, the message can be either a router advertisement, or the list of IP address of the neighbouring Access Routers. Source Dest Primitive Parameters

RCF / RCM

IWF OPEN_WCDMA_CONN_IND Local connection reference, IMEI of MT

RCF/ RCM

IWF OPEN_WCDMA_CONN_INFO Local connection reference, Home Address of MT, CoA of MT

RCF/ RCM

IWF CLOSE_WCDMA_CONN_IND Local connection reference

RCF/ RCM

IWF LOST_WCDMA_CONN_IND Local connection reference


RCF IWF IWF_RADIO_BEARER_REQ Local connection reference, DSCP code, IP source address of packet, IP destination address of packet

IWF RCM IWF_RADIO_BEARER_CONF Local connection reference, number of entries in the list, list of: [DSCP code, Radio QoS class, status]

D0302_M3-4.doc Final / M3.4 19.12.2002


Note: the status in IWF_RADIO_BEARER_CONF message can be: ok, not ok, M (special case of fast handover).

6.16 RG IWF / QoS Broker

6.16.1 Description This interface is used to request the opening of a radio bearer on the Radio Gateway (at the Mobile Terminal or Access Router initiative). It will also be used during the Fast Handover to transfer all the DSCP codes currently used by a Mobile Terminal to the destination Radio Gateway (to open the associated radio bearers when the new connection is established).

6.16.2 Interface mechanisms From the IWF to the QoS Manager on the Access Router, it will simply be the sending of a “dummy IP packet”, namely an echo request dummy packet. From the QoS Broker to the IWF, the only message exchanged can be supported by an UDP packet, exchanged between two specific port on the Radio Gateway and the QoS Broker.


IWF QoS Manager on AR

“echo request dummy packet” “IP source address, IP destination address, DSCP code, of original packet on MT

QoS Broker

IWF RADIO_ACCESS_ALLOCATION Number of entries in list, Home Address of MT, list of [DSCP code, Radio QoS class, status]

Note: the status in RADIO_ACCESS_ALLOCATION message can be: ok, not ok, M (special case of fast handover).

6.17 MT/AR Fast Handover with Enhanced IPv6 The Fast Handover Module is implemented as a separate Linux kernel module, which can be loaded and unloaded dynamically. However, the functionality of handling the fast handover message flow and state requires interaction with the IPv6 stack and respective Linux kernel functions, as well as communication to the Mobile IPv6 stack MIPL. Since all these modules and stacks are part of the Linux kernel, there is no need for detailed interface specification, the interaction is realised via function calls. For this reason, the IPv6 stack already provides the required functions mostly as extern declaration; therefore the fast handover module ‘just’ needs to include the respective header files, in order to be able to access these functions. The most deployed example within the Fast Handover Module is the IPv6 ‘xmit’ function, which is called to put the Fast Handover specific ICMPv6 messages in the output queue for sending them to the network. The same mechanism is deployed for the required interaction with the Mobile IPv6 stack MIPL, but in this case the stack is not prepared for this kind of deployment. The function prototype declaration is not uniquely extern and not always in the header files, which brings along some additional efforts in order to call these functions from outside the MIPL stack. Fortunately, the authors of the MIPL stack already recognised this problem before and provided a chain of function, which is accessible from outside MIPL and solves the problem so that all from the FHO module required functions are available. Beyond the integration in the IPv6 and Mobile IPv6 stack as described above, the Fast Handover Module is responsible to create and initialise the char-devices, which are required for the communications to the user-space programs:

FHO - AAAC attendant on the Access Router FHO - QoS attendant on the Access Router FHO - MTNM on the Mobile Node

D0302_M3-4.doc Final / M3.4 19.12.2002


These char-devices must be set up in the kernel and, within the framework of Moby Dick, the FHO module is required in all scenarios and is therefore the most appropriate place for this.

6.18 MT Paging Module / MT Enhanced IPv6 stack

6.18.1 Description Since L3 paging area information is encapsulated in Router Advertisement messages, the interpretation of a new “L3 Paging Area ID” option is to be implemented with the Neighbour Discovery part of the IPv6 protocol stack on the mobile terminal. The modified Router Advertisement Daemon will include this option to encode the paging area identifier information. On reception of the paging area identifier information, the paging module in the mobile terminal should compare the received identifier with the registered paging area. In case of the identifier indicates that the mobile terminal has entered a different paging area as the registered one, a paging area update procedure must be initiated. Furthermore, the Mobile IPv6 code of the enhanced IPv6 implementation will provide an addition a function to allow the paging module to register an alternate CoA with the mobile terminal's PA.

6.18.2 Interface mechanisms The Neighbour Discovery function on the mobile terminal, processing received ICMPv6 Router Advertisements, implements a further check on the IP paging area ID option and calls a notification function in the IP paging kernel module to keep L3 paging area information updated in the paging module of the mobile terminal. For the alternate care-of address registration from the paging module, the dormant registration part of the code calls the new function in MIPL that releases a Mobile IPv6 BU with the alternate CoA sub-option. This function has been implemented in the MIPL code to be publicly available for the paging module.

6.18.3 Interface contents Source Dest Function call Parameters

MT Paging Module

MT IPv6 mipv6_register_altcoa(…) Alternate care-of address, registration lifetime, registration type

MT IPv6 MT Paging module

rcv_parea_info(…)_ Paging area identifier

D0302_M3-4.doc Final / M3.4 19.12.2002


7. References [1] Moby Dick consortium, Moby Dick Framework Specification, Moby Dick Deliverable D0101,

October 2001

[2] Moby Dick consortium, Initial Design and Specification of a Moby Dick Mobility Architecture, Moby Dick Deliverable D0301, April 2002

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

[4] 3GPP Technical Specification Group RAN, 3G TS 23.110, UMTS Access Stratum Services and Functions

[5] Juergen Jaehnert, Amardeo Sarma, Bernd Lamparter, Marco Liebsch, Sebastian Zander, Cristian Constantin, Serge Tessier, Davinder Singh, Ralf Schmitz, Moby Dick Signalling Flow Specification and Implementation Specification with respect to Mobility, QoS and AAA, Moby Dick Task Internal Report, June 2002

[6] M. Wetterwald, C. Bonnet, L, Gauthier, Y. Moret, Interface primitives provided to upper layers (NAS) version 1.1, Moby Dick Task Internal Report, May 2002

[7] A. Conta, S. Deering, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification, RFC 2463, December 1998

D0302_M3-4.doc Final / M3.4 19.12.2002


8. Appendix A : WLAN infrastructure and ad hoc mode The Moby Dick consortium decided to deploy the ad hoc mode for the field trial due to the handover latency increase in infrastructure mode. This appendix summarizes additional work needed in WP3 to cope with the ad hoc mode

8.1 Introduction The WP3 members have made handover tests in order to measure the delay introduced by a layer-2 handover in IEEE 802.11b infrastructure mode. The result of these tests has shown that in 802.11b infrastructure mode handover delay is well over 100ms. This delay is not acceptable for real time applications and would significantly decrease performance for connection oriented TCP connections. These tests covered different equipment (Lucent and SMC cards) getting similar results, handover delay in Lucent cards was smaller but, anyway, too long for real-time communications. The handover delay is then not a problem of particular equipment. The reason for the long handover latency in infrastructure mode has been detected to be the process of searching for a new AP. This search is carried out by sending Probe Request frames in each of the possible channels that the IEEE 802.11b standard defines, and waiting for the possible Probe Response frame to find out the presence of an AP in that channel. Most of these functions are anchored in the firmware of the card, and so it is very difficult to change that behaviour. Moby Dick project cannot work with this layer-2 handover delay because it makes impossible to implement a seamless handover, no matter what it is done at layer-3. The decision was to deploy ad hoc mode in Moby Dick field trial. This decision had to be made, although the consortium considers infrastructure mode as the appropriate mode for future network architecture, but this mode will have to be enhanced in future equipment with new functionality to avoid long handover delays. In current equipment, the only way of controlling the handover execution from upper layers is to set the different APs with different ESSID names, a handover is then forced by changing the ESSID name the MT is using. But, when this is done, connectivity with the old AP is lost and all the process of trying to discover new APs starts, there is not way to instruct the driver/firmware to search for example only in one particular channel. In this document, the differences between the infrastructure mode and ad hoc mode are outlined, and the reason why handover latency in infrastructure mode is much longer than in ad hoc mode is analysed. Based on this information, we describe the additional work in all Moby Dick WPs, which is needed in ad hoc mode, in order to provide all required functionality for the Moby Dick field trial.

8.2 WLAN Basics To understand the differences between infrastructure mode and ad hoc mode, some knowledge is needed; the following information is obtained from IEEE 802.11 standards.

8.2.1 Definitions Ad hoc network A network composed solely of stations within mutual communication range of each other via the wireless medium (WM). An ad hoc network is typically created in a spontaneous manner. The principal distinguishing characteristic of an ad hoc network is its limited temporal and spatial extent. These limitations allow the act of creating and dissolving the ad hoc network to be sufficiently straightforward and convenient so as to be achievable by no technical users of the network facilities; i.e., no specialized “technical skills” are required and little or no investment of time or additional resources is required beyond the stations that are to participate in the ad hoc network. The term ad hoc is often used as slang to refer to an independent basic service set (IBSS). Association: The service used to establish access point/station (AP/STA) mapping and enable STA invocation of the distribution system services (DSSs). Authentication: The service used to establish the identity of one station as a member of the set of stations authorized to associate with another station. Basic service set (BSS): A set of stations controlled by a single coordination function. Deauthentication:

D0302_M3-4.doc Final / M3.4 19.12.2002


The service that voids an existing authentication relationship. Disassociation: The service that removes an existing association. Distributed coordination function (DCF): A class of coordination function where the same coordination function logic is active in every station in the basic service set (BSS) whenever the network is in operation. Distribution: The service that, by using association information, delivers medium access control (MAC) service data units (MSDUs) within the distribution system (DS). Distribution system (DS): A system used to interconnect a set of basic service sets (BSSs) and integrated local area networks (LANs) to create an extended service set (ESS). Independent basic service set (IBSS): A BSS that forms a self-contained network, and in which no access to a distribution system (DS) is available. Infrastructure: The infrastructure includes the distribution system medium (DSM), access point (AP), and portal entities. It is also the logical location of distribution and integration service functions of an extended service set (ESS). An infrastructure contains one or more APs and zero or more portals in addition to the distribution system (DS). Integration: The service that enables delivery of medium access control (MAC) service data units (MSDUs) between the distribution system (DS) and an existing, non-IEEE 802.11 local area network (via a portal). Point coordination function (PCF): A class of possible coordination functions in which the coordination function logic is active in only one station in a basic service set (BSS) at any given time that the network is in operation. Privacy: The service used to prevent the content of messages from being read by other than the intended recipients. Reassociation: The service that enables an established association [between access point (AP) and station (STA)] to be transferred from one AP to another (or the same) AP. Station (STA): Any device that contains an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM). Station service (SS): The set of services that support transport of medium access control (MAC) service data units (MSDUs) between stations within a basic service set (BSS).

8.2.2 Message Type The IEEE 802.11 MAC sublayer uses three types of messages—data, management, and control. The data messages are handled via the MAC data service path. MAC management messages are used to support the IEEE 802.11 services and are handled via the MAC management service data path. MAC control messages are used to support the delivery of IEEE 802.11 data and management messages.

8.2.3 Services and States IEEE 802.11 specifies services. The services are associated with different components of the architecture. There are two categories of IEEE 802.11 service: the station service (SS) and the distribution system service (DSS). Both categories of service are used by the IEEE 802.11 MAC sublayer. Station service (SS) The service provided by stations is known as the station service. The SS is present in every IEEE 802.11 station (including APs, as APs include station functionality). All conformant stations provide SS. The SS is as follows:

a) Authentication b) Deauthentication c) Privacy d) MSDU (MAC service data unit) delivery

Distribution system service (DSS) The service provided by the DS is known as the distribution system service.

D0302_M3-4.doc Final / M3.4 19.12.2002


These services are used to cross media and address space logical boundaries. The physical embodiment of various services may or may not be within a physical AP. The DSSs are provided by the DS. They are accessed via a STA that also provides DSSs. A STA that is providing access to DSS is an AP. The DSSs are as follows:

a) Association b) Disassociation c) Distribution d) Integration e) Reassociation

8.2.3.1.1 Relationships between services A STA keeps two state variables for each STA with which direct communication via the WM (wireless medium) is needed:

—Authentication state: The values are unauthenticated and authenticated. —Association state: The values are unassociated and associated.

These two variables create three local states for each remote STA:

—State 1: Initial start state, unauthenticated, unassociated. —State 2: Authenticated, not associated. —State 3: Authenticated and associated.

The relationships between these station state variables and the services are given in the figure 1 .

Figure A.1: Relationship between state variables and services

The current state existing between the source and destination station determines the IEEE 802.11 frame types that may be exchanged between that pair of STAs. The allowed frame types are grouped into classes and the classes correspond to the station state. In State 1, only Class 1 frames are allowed. In State 2, either Class 1 or Class 2 frames are allowed. In State 3, all frames are allowed (Classes 1, 2, and 3). The frame classes are defined as follows: a) Class 1 frames (permitted from within States 1, 2, and 3):

1) Control frames i) Request to send (RTS) ii) Clear to send (CTS) iii) Acknowledgment (ACK) iv) Contention-Free (CF)-End+ACK v) CF-End

2) Management frames

D0302_M3-4.doc Final / M3.4 19.12.2002


i) Probe request/response ii) Beacon

iii) Authentication: Successful authentication enables a station to exchange Class 2 frames. Unsuccessful authentication leaves the STA in State 1.

iv) Deauthentication: Deauthentication notification when in State 2 or State 3 changes the STA’s state to State 1. The STA shall become authenticated again prior to sending Class 2 frames. v) Announcement traffic indication message (ATIM)

3) Data frames i) Data: Data frames with frame control (FC) bits “To DS” and “From DS” both false.

b) Class 2 frames (if and only if authenticated; allowed from within States 2 and 3 only): 1) Management frames:

i) Association request/response — Successful association enables Class 3 frames. — Unsuccessful association leaves STA in State 2.

ii) Reassociation request/response — Successful reassociation enables Class 3 frames. — Unsuccessful reassociation leaves the STA in State 2 (with respect to the STA that was sent the reassociation message). Reassociation frames shall only be sent if the sending STA is already associated in the same ESS.

iii) Disassociation — Disassociation notification when in State 3 changes a Station’s state to State 2. This station shall become associated again if it wishes to utilize the DS. If STA A receives a Class 2 frame with a unicast address in the Address 1 field from STA B that is not authenticated with STA A, STA A shall send a deauthentication frame to STA B.

c) Class 3 frames (if and only if associated; allowed only from within State 3): 1) Data frames

— Data subtypes: Data frames allowed. That is, either the “To DS” or “From DS” FC bits may be set to true to utilize DSSs.

2) Management frames — Deauthentication: Deauthentication notification when in State 3 implies disassociation as well, changing the STA’s state from 3 to 1. The station shall become authenticated again prior to another association.

3) Control frames — PS-Poll

If STA A receives a Class 3 frame with a unicast address in the Address 1 field from STA B that is authenticated but not associated with STA A, STA A shall send a disassociation frame to STA B. If STA A receives a Class 3 frame with a unicast address in the Address 1 field from STA B that is not authenticated with STA A, STA A shall send a deauthentication frame to STA B.

8.2.4 MAC frame formats Each frame consists of the following basic components: a) A MAC header, which comprises frame control, duration, address, and sequence control information; b) A variable length frame body, which contains information specific to the frametype; c) A frame check sequence (FCS),which contains an IEEE 32-bit cyclic redundancy code (CRC). The MAC frame format comprises a set of fields that occur in a fixed order in all frames. Figure 2 depicts the general MAC frame format. The fields Address 2, Address 3, Sequence Control, Address 4, and Frame Body are only present in certain frame types.

D0302_M3-4.doc Final / M3.4 19.12.2002


Figure A.2: MAC frame format

There are four address fields in the MAC frame format. These fields are used to indicate the BSSID, source address, destination address, transmitting station address, and receiving station address. The usage of the four address fields in each frame type is indicated by the abbreviations BSSID, DA, SA, RA, and TA, indicating basic service set identifier (BSSID), Destination Address, Source Address, Receiver Address, and Transmitter Address, respectively. Certain frames may not contain some of the address fields. The Frame Control field consists of the following subfields: Protocol Version, Type, Subtype, To DS, From DS, More Fragments, Retry, Power Management, More Data, Wired Equivalent Privacy (WEP), and Order. The format of the Frame Control field is illustrated in Figure 3.

Figure A.3: Frame Control field

8.2.5 Number of operating channels The DSSS PHY shall operate in the frequency range of 2.4 GHz to 2.4835 GHz as allocated by regulatory bodies in the USA and Europe or in the 2.471 GHz to 2.497 GHz frequency band as allocated by regulatory authority in Japan. For each supported regulatory domain, all channels in Table 1 marked with “X” shall be supported.

D0302_M3-4.doc Final / M3.4 19.12.2002


Table A.1: DSSS PHY frequency channel plan

In a multiple cell network topology, overlapping and/or adjacent cells using different channels can operate simultaneously without interference if the distance between the centre frequencies is at least 30 MHz. Channel 14 shall be designated specifically for operation in Japan.

8.3 Differences between Infrastructure and Ad hoc Mode and relevance to Moby Dick Based on the information presented above, the differences between infrastructure mode and ad hoc mode are outlined here. These differences come from the 802.11 standard, there may also be vender specific differences, which are not covered here. Furthermore, each of the following sub-chapters outlines the relevance for the project, which is essential to understand the needed additional implementation work, which goes along with the decision to deploy the ad hoc mode for the Moby Dick field trial.

8.3.1 Communication between STAs Ad hoc mode is often used to support an ad hoc network. In ad hoc mode, STAs form an IBSS network, a STA can communicate directly with one or more other STAs. Only DCF is supported in ad hoc mode In infrastructure mode, STAs cannot communicate directly with each other, all the traffic has to go through the AP. The PCF provides contention-free frame transfer. The PC shall reside in the AP. Both DCF and PCF are supported in infrastructure mode (but only DCF is implemented in current equipment). Relevance to Moby Dick: Since the general Moby Dick architecture includes charging, direct communication in an IBSS network can be a problem, because there is no accounting possibility for this kind of network traffic. But, in fact, this traffic doesn’t use any Moby Dick resource, because 802.11 bandwidth cannot be considered a private resource, in any circumstance users can always configure their own ad hoc networks in the nearby of a Moby Dick network (in infrastructure mode or ad hoc mode) and in such a way reduce the overall bandwidth available.

D0302_M3-4.doc Final / M3.4 19.12.2002


8.3.2 Services and States Only Station Service (SS) is supported in ad hoc mode, that is, a STA in an IBSS can only use Authentication, Deauthentication, Privacy and MSDU delivery. In infrastructure mode, in addition to SS, a STA can also have Distribution system service (DSS), that is, it can use Association, Disassociation, Distribution, Integration, and Reassociation. So in ad hoc mode, a STA can communicate without association or authentication, while in infrastructure mode, a STA has to first be authenticated and then associates itself to a access point (AP). As a consequence, a STA in ad hoc mode can only be in state 1 and state 2, and can only send class 1 and class 2 frames; while in infrastructure mode, a STA can have three states, and can send all the three classes of frames. Relevance to Moby Dick: The above mentioned authentication and association refers to layer 2 mechanisms, which are not required for the Moby Dick project, because authentication and authorisation is provided on the layers above. Beyond that, within Moby Dick even nodes which are not authenticated and authorised require layer 2 connection in exceptional situations and scenarios, like emergency calls. Therefore, the choice for ad hoc mode implies no additional implementation efforts in this regard.

8.3.3 Different Requirement on Authentication In 802.11 standard, authentication shall be used in infrastructure mode, and may be used in ad hoc mode. Relevance to Moby Dick: There is no impact on Moby Dick due to this requirement, because layer 2 authentication is replaced by authentication and authorisation on layers above, as pointed out previously.

8.3.4 Frame Formats Difference Frames sent in infrastructure mode and ad hoc mode have different format. At the moment we have not found much relevance with Moby Dick, but it might be useful for the later implementation work. So it is outlined here only for future reference. To DS field From DS field In Frame control filed in a MAC frame, there are To DS filed and From DS field. The To DS field is 1 bit in length and is set to 1 in data type frames destined for the DS. This includes all data type frames sent by STAs associated with an AP. The To DS field is set to 0 in all other frames. The From DS field is 1 bit in length and is set to 1 in data type frames exiting the DS. It is set to 0 in all other frames. BSSID field There are four address fields in the MAC frame format. These fields are used to indicate the BSSID, source address, destination address, transmitting station address, and receiving station address. The BSSID field is a 48-bit field of the same format as an IEEE 802 MAC address. This field uniquely identifies each BSS. The value of this field, in an infrastructure BSS, is the MAC address currently in use by the STA in the AP of the BSS. The value of this field in an IBSS is a locally administered IEEE MAC address formed from a 46-bit random number. This mechanism is used to provide a high probability of selecting a unique BSSID. Content of the Address fields The content of the Address fields of the data frame is dependent upon the values of the To DS and From DS bits and is defined in Table 1. Where the content of a field is shown as not applicable (N/A), the field is omitted.

D0302_M3-4.doc Final / M3.4 19.12.2002


Table A.2: Address field contents

8.3.5 Beacon Generation In infrastructure networks, the AP shall define the timing for the entire BSS by transmitting beacons according to the aBeaconPeriod attribute within the AP. This defines a series of TBTTs (target beacon transmission times) exactly aBeaconPeriod time units apart. At each TBTT, the AP shall schedule a beacon as the next frame for transmission. Beacon generation in an IBSS is distributed. The beacon period is included in Beacon and Probe Response frames, and STAs shall adopt that beacon period when joining the IBSS. All members of the IBSS participate in beacon generation. The beacon interval within an IBSS is established by the STA that instantiates the IBSS. Relevance to Moby Dick: Although the ad hoc mode is chosen, there is the need to distinguish between Access Routers and Mobile Terminals in Moby Dick. One solution is via beacon generation, which implies additional implementation or configuration work, which will be analysed in chapter 5.

8.3.6 Synchronization All STAs within a single BSS shall be synchronized to a common clock. A timing synchronization function (TSF) keeps the timers for all STAs in the same BSS synchronized. In an infrastructure network, the AP shall be the timing master and shall periodically beacons that contain a copy of its TSF timer to synchronize the other STAs in a BSS. A receiving STA shall always accept the timing information in beacons sent from the AP servicing its BSS. If a STA’s TSF timer is different from the timestamp in the received beacon, the receiving STA shall set its local timer to the received timestamp value. The TSF in an IBSS shall be implemented via a distributed algorithm that shall be performed by all of the members of the BSS. Each STA in the BSS shall transmit beacons according to the algorithm described in this clause. Each STA in an IBSS shall adopt the timing received from any beacon or probe response that has a TSF value later than its own TSF timer. Relevance to Moby Dick: The synchronisation implementation in an IBSS network relies on the beacon generation by all nodes. One solution to distinguish between Access Routers and Mobile Terminals is by sending beacon frames only from Access Routers, but this can require to adapt the infrastructure timing mechanism as additional implementation task. This will be analysed in chapter 5, as well.

8.4 Handover Delay Analysis in Infrastructure Mode 802.11 standard does not specify mobility support in ad hoc mode. In infrastructure mode, before sending data to an AP, a STA shall first be associated with the AP, that is, the STA shall be in state 3 as described in Figure 1. In other words, the STA has to be authenticated, and associated with the AP before it can send data. Authentication involves as least two messages exchanged between two STAs, depending on which authentication scenario is used. Association involves Association request and Association response exchanged between a STA and an AP. To find a new AP during handover, a STA can use either Passive Scanning mode or an Active Scanning mode to perform scanning. In Passive Scanning mode, the STA shall listen to each channel scanned for no longer than a maximum duration defined by the ChannelTime parameter. Active scanning involves the

D0302_M3-4.doc Final / M3.4 19.12.2002


generation of Probe Request frames and the subsequent processing of received Probe Response frames. When all channels in the ChannelList parameter have been scanned, scanning results indicating all of the BSS information are sent to the high layer. WP3 members have done several handover tests in infrastructure mode with a MT and two APs with SMC cards; the handover is forced by changing the ESSID with the command iwconfig wlan essid XXX The 802.11 frames exchanged between the MT and APs are captured during the handovers. The handover is considered to start when the first Probe Request is sent by the MT, and finish when the Association Response is sent by an AP followed by an Acknowledgement. The different tests show similar results: the total handover delay is about 500ms, during which the MT sent up to 6 or 7 times Probe Request and received 3 or 4 times Probe Response; the authentication and authorisation process take only 3ms. The results indicate that the handover delay in infrastructure mode is not due to the authentication and authorisation process, but due to the Probe Request and Probe Response process. Mr. William A. Arbaugh from Maryland University, who has done extensive tests in wireless LAN handover, has been consulted. He found the majority of the handover delay was due to the Probe Request/Response time; this is done to find the next AP when the MT probes on all channels. He also mentioned that the Lucent client only probes on channel 1, 6, 11, which makes the delay much less. The number of channels used by 802.11b is 13 (a channel 14 is designed specifically for Japan). If a MT wants scan all the channels, it has to send 13 Probe Requests, but from the captured 802.11 frames in the test, only 6 or 7 Probe Requests can be seen. By carefully checking the captured data frames, it can be found that the Sequence number in the captured 802.11 frames is not continuous, that is some frames are not captured. In the tests, before sending Authentication Request, the MT only sent Probe Request, the Sequence number difference from the first Probe Request to the Authentication Request is 12, that is, there should be 13 Probe Requests sent by the MT, which is exactly the total channel number of 802.11b. So we can infer that, the handover delay in infrastructure mode is due to the scanning of all the channels in the ChannelList. To reduce the layer two handover delay in infrastructure mode, one possible solution is to fix the operating channel of the AP and MT, during handover, only one or a few channels are scanned, thus the handover delay would be reduced. Mr. William A. Arbaugh thinks that the firmware would have to be changed, which is far beyond what WP3 can do.

8.5 Additional Work to Deploy Ad hoc Mode Since the layer 2 handover delay in infrastructure mode is too big to be accepted, two alternative solutions have been raised: To use ad hoc mode or to reduce the handover delay in infrastructure mode. Since modification of infrastructure mode would imply modifications in the driver and the firmware of the WLAN card, and because such modifications are far beyond the scope of the project, the project decided to deploy the ad hoc mode. Therefore, this chapter focuses on configuration and additional implementation efforts needed for deploying the 802.11 ad hoc mode in Moby Dick.

8.5.1 Configuration for working in ad hoc mode The configuration needed for working in ad hoc mode in Moby Dick is as follows:

1. All WLAN Access Routers (AR) and WLAN Mobile Terminals (MT) are configured to work in ad hoc mode, with the same frequency and the same Service Set Identifier.

2. The point above means that a MT can receive packets from all the ARs at the same time (in fact it can receive packets from any other MT also). In other words, this means that, with this configuration, we don’t have a layer 2 handover.

3. A MT distinguishes an AR by receiving the respective Router Advertisements, i.e., the AR discovery is done at layer 3. We should get not only the Router Advertisement received, but also the signal level with each one, so handover decisions can be taken.

4. Handover consists on layer 3 re-configuration, i.e., it is a layer 3 handover.

D0302_M3-4.doc Final / M3.4 19.12.2002


8.5.2 Filter Function in WLAN driver For the configuration above to work, there is the need of a filtering function in the WLAN driver. Only the Router Advertisements of the AR the MT is using, must be sent to the IP layer (or we would have constant handovers among the ARs from which the MT is able to receive). Also, the MTNM module in Moby Dick MT architecture performs movement detection and handover decision. One of the handover decision parameters is signal quality (e.g., signal to noise ratio). In order to be informed about the surround, possible Access Routers and the respective signal quality, Router Advertisements need to be filtered out and sent, with the respective signal quality, to the MTNM. In infrastructure mode, the signal quality is automatically available, while in ad hoc mode, router advertisements needs to be explicitly filtered out and the signal quality evaluated. This is an additional implementation work that will be done within the project. If the MTNM decides to execute effectively the handover (after the preparation phase involving the Fast Handover module), it will indicate to the filter function which is the new AR, so that the Router Advertisements of the new AR are sent to the IP layer, and the others are filtered. Another function of the filter in the WLAN driver will be discarding the broadcast traffic that doesn’t belong to the subnet of the AR the MT is using; this will be done by checking the source address of the received packets.

8.5.3 Beacon generation In order to distinguish between MNs and ARs directly at layer 2, a first possibility is to change somehow the beacon frame generated by the Access Routers to distinguish it from the beacons generated by Mobile Terminals. Another possibility is to allow beacon generation in Access Routers and deny it on Mobile Terminals but this can have an additional problem that is analysed in next section.

8.5.4 Synchronization There is a need to verify, if synchronization in ad hoc mode still works when beaconing at Mobile Terminals is disabled. If this is not the case, there is a need to evaluate if it is possible to adapt the infrastructure mode synchronization to the ad hoc mode. This section and previous one, if implemented, will allow a more efficient implementation of the ad hoc mode in Moby Dick, basically, we will be able to discover ARs at layer 2 without analysing the IP packet. This would make easier and more efficient the filtering function explained in section 8.5.1, and it would permit improvements as configuring different ARs in different frequencies. But the implementation is restricted by the possibility of being dependent on firmware functions so, we’ll study these possibilities but we will base our solution in the configuration described in section 8.5.1.

mobility architecture implementation reportpacyna/deliverables/mobydick/d0302.pdf · mobility...

Documents