Moby Dick Consolidated System Integration Plan

IST-2000-25394 Moby Dick
D0103
Moby Dick Consolidated System Integration Plan
Contractual Date of Delivery to the CEC: June 2003
Actual Date of Delivery to the CEC: 30 th of June 2003
Author:
University of Stuttgart (P05) - Juergen Jaehnert (RUS)
Participants: P01: Serge Tessier, Hans Einsiedler
P02: Marco Liebsch, Amardeo Sarma, Ralf Schmitz
P03: Jose Ignacio Moreno, Antonio Cuevas Casado
P04: Hasan
P06: Davinder Pal Singh
P07: Rui Aguiar, Victor Marques
P08: Eric Melin, Chrstophe Beaujean
P09: Michelle Wetterwald
P10: Piotr Pacyna
P12: Parijat Mishra
Workpackage:
Est. person months:
Security:
Nature:
WP1
Version: 1.0
Total number of pages:
public
Report
168 pages
Abs tract:
This is the final Deliverable of workpackage (WP1) of the Moby Dick project. It describes the Moby
Dick overall architecture as defined and implemented during the first 30 months of the project.
Since parts of this documentation are provided by the specific implementation workpackages it
contain redundant information, especially with D020x (QoS part), D030x (Mobility part) and
D040x (AAA part).
Keyword list: UMTS, TD-CDMA, Mobile IP, QoS, Mobility, AAA, Charging

D0103v1.doc Version 1 6.7.2003
Table of Contents
ABBREVIATIONS.........................................................................................................7
1 INTRODUCTION.....................................................................................................9
2 OVERALL MOBY DICK OPERATION..............................................................10
3 MOBY DICK ARCHITECTURE..........................................................................11
3.1 Conceptual view.......................................................................................................................................... 11
4 MOBY DICK PHYSICAL COMPONENTS........................................................14
4.1 Mobile Terminal Software Specification.............................................................................................. 14
4.1.1 Overview of the different components..............................................................................................15
4.1.1.1 Networking Control Panel ..............................................................................................................15
4.1.1.2 Mobile Terminal Networking Manager........................................................................................15
4.1.1.3 Fast Handover module .....................................................................................................................15
4.1.1.4 Registration module .........................................................................................................................16
4.1.1.5 Paging module...................................................................................................................................16
4.1.1.6 Enhanced IPv6 stack........................................................................................................................16
4.1.1.7 Network Device Driver ...................................................................................................................16
4.1.1.8 Access Stratum..................................................................................................................................17
4.1.2 Detailed description of the components............................................................................................17
4.1.2.1 Networking Control Panel ..............................................................................................................17
4.1.2.2 Mobile Terminal Networking Manager........................................................................................19
4.1.2.3 Radio Channel Manager..................................................................................................................27
4.1.2.4 Radio Convergence Function.........................................................................................................31
4.1.2.5 Fast Handover module .....................................................................................................................33
4.1.2.6 Paging module...................................................................................................................................35
4.1.2.7 Registration Module.........................................................................................................................36
4.1.2.8 Enhanced IPv6 stack........................................................................................................................39
4.1.2.9 DSCP Marking Software .................................................................................................................39
4.1.2.10 Monitoring Extensions to Ethernet / WLAN driver...............................................................43
4.2 Access Router Software Specification ................................................................................................... 44
4.2.1 Overview of the different components..............................................................................................44
4.2.1.1 Fast Handover Module / MIPL......................................................................................................44
4.2.1.2 Paging Attendant..............................................................................................................................44
4.2.1.3 Network Device Driver /WLAN....................................................................................................44
4.2.1.4 Enhanced IPV6/IPSec/DiffServ packet Filter .............................................................................44
4.2.1.5 AAAC Attendant..............................................................................................................................45
4.2.1.6 Metering.............................................................................................................................................45
4.2.1.7 QoS Manager.....................................................................................................................................45
4.2.1.8 Logger ................................................................................................................................................45
4.2.1.9 DSCP Marking Software (DMS) ...................................................................................................46
4.2.2 Description of the different Components..........................................................................................46
4.2.2.1 Network device drivers....................................................................................................................46
4.2.2.2 Enhanced IPv6 stack/IPSec/DiffServ packet Filter ....................................................................46
4.2.2.3 Fast Handover Module / MIPL......................................................................................................47
4.2.2.4 Paging Attendant..............................................................................................................................49
4.2.2.5 QoS Manager.....................................................................................................................................51
4.2.2.6 AAAC Attendant..............................................................................................................................55
4.2.2.7 DSCP Marking Software .................................................................................................................60
4.2.3 Software implementation / interfaces ................................................................................................64
D0103v1.doc 2 / 168

D0103v1.doc Version 1 6.7.2003
4.2.3.1 Interface between QoSManager and Fast Handover module ....................................................64
4.2.3.2 Interface between QoSManager and DiffServ Logic .................................................................66
4.2.3.3 Interface between the QoSManager and the Integrated Logger...............................................66
4.2.3.4 Interface between the IPv6 enhanced stack and the Fast Handover module ..........................67
4.2.3.5 Interface between the IPv6 enhanced stack and the IP paging attendant................................67
4.2.3.6 Interface between AAAC Attendant and IPSec ..........................................................................68
4.2.3.7 Interface between AAAC Attendant and metering.....................................................................70
4.2.3.8 Interface between AAAC attendant and Fast Handover module .............................................70
4.2.3.9 Interface between AAAC Client and Integrated Logger...........................................................72
4.3 Radio Gateway Software Specification................................................................................................. 73
4.3.1 Overview of the different components..............................................................................................73
4.3.1.1 Radio Gateway Operating System.................................................................................................73
4.3.1.2 Inter Working Function...................................................................................................................73
4.3.1.3 IP stack...............................................................................................................................................74
4.3.1.4 Radio Channel Manager (RCM)....................................................................................................74
4.3.1.5 Radio Convergence Function (RCF).............................................................................................75
4.3.1.6 Access Stratum..................................................................................................................................75
4.3.1.7 Inter Working Function...................................................................................................................75
4.3.1.8 Info Management block...................................................................................................................75
4.3.1.9 IP to TD-CDMA relay block..........................................................................................................75
4.3.1.10 QoS Attendant sub-block............................................................................................................78
4.3.1.11 TD-CDMA to IP relay block......................................................................................................79
4.3.1.12 IP stack...........................................................................................................................................80
4.3.2 Radio Channel Manager......................................................................................................................81
4.3.2.1 Radio Connection Manager block.................................................................................................81
4.3.2.2 Packet Transmission block .............................................................................................................81
4.3.2.3 Packet Reception block ...................................................................................................................82
4.3.3 Radio Convergence Function..............................................................................................................83
4.3.3.1 TD-CDMA Connection Manager block.......................................................................................83
4.3.3.2 Control Channel Management block.............................................................................................84
4.3.3.3 Data Channel Management block..................................................................................................84
4.3.4 Access Stratum......................................................................................................................................85
4.3.4.1 General architecture of the software platform.............................................................................87
4.3.4.2 Physical Layer Software Architecture ..........................................................................................88
4.3.4.3 MAC Services and Functions.........................................................................................................90
4.3.4.4 RLC Services and Functions..........................................................................................................91
4.3.4.5 PDCP Services and Functions........................................................................................................92
4.3.4.6 RRC Specification............................................................................................................................92
4.4 QoS Broker Software Specification....................................................................................................... 95
4.4.1 General QoS Broker Positioning........................................................................................................95
4.4.2 QoS Broker components......................................................................................................................96
4.4.2.1 WebGUI.............................................................................................................................................97
4.4.2.2 NetProbe.............................................................................................................................................97
4.4.2.3 QBrokerEngine .................................................................................................................................97
4.4.2.4 QoS Broker Interfaces .....................................................................................................................97
4.4.3 Software Implementation ....................................................................................................................98
4.4.3.1 Interfaces............................................................................................................................................98
4.4.3.2 Data format interchanged between Radio Gateway and QoSBroker....................................102
4.4.3.3 Databases .........................................................................................................................................103
4.5 AAAC Server Software Specification .................................................................................................104
4.5.1 User Profile ..........................................................................................................................................105
4.5.1.1 User Profile Attributes...................................................................................................................105
4.5.1.2 General View of User Profile .......................................................................................................106
4.5.1.3 User Profile Distribution...............................................................................................................108
4.5.1.4 User Profile Management .............................................................................................................108
4.5.1.5 Network View of user Profile (NVUP) - Global SLAs ...........................................................108
4.5.1.6 Test users – Profile Examples ......................................................................................................109
4.5.2 Diameter Entities ................................................................................................................................109
D0103v1.doc 3 / 168

D0103v1.doc Version 1 6.7.2003
4.5.2.1 User registration with a MN .........................................................................................................110
4.5.2.2 Attendant..........................................................................................................................................111
4.5.2.3 Registration Protocol Handler......................................................................................................112
4.5.2.4 AAAC Protocol Handler...............................................................................................................112
4.5.2.5 Fast handover..................................................................................................................................112
4.5.2.6 Diameter / foreign server...............................................................................................................113
4.5.2.7 AAAC.h ...........................................................................................................................................113
4.5.2.8 Home Agent-AAA-Enabler..........................................................................................................113
4.5.2.9 AAA message flow ........................................................................................................................114
4.5.2.10 Attendant to MN (UDP message)...........................................................................................118
4.5.3 Accounting DB....................................................................................................................................118
4.5.3.1 AAAC Client...................................................................................................................................118
4.5.3.2 Accounting Messages ....................................................................................................................119
4.5.3.3 The Accounting Information ........................................................................................................120
4.5.4 Charging Module ................................................................................................................................121
4.5.4.1 DIAMETER Messages vs. Entries in the Accounting Database............................................122
4.5.4.2 Sessions............................................................................................................................................122
4.5.4.3 DSCP Values...................................................................................................................................124
4.5.4.4 Overview of Databases ..................................................................................................................125
4.5.4.5 Representation of Accounting Data in the MySQL database.................................................125
4.5.4.6 Locking of Accounting Database................................................................................................129
4.5.4.7 Charging Database.........................................................................................................................130
4.5.4.8 User-profiles Database..................................................................................................................130
4.5.4.9 Accounting Data Warehouse........................................................................................................130
4.5.4.10 Error Handling and Failure .......................................................................................................130
4.5.4.11 Implementation of the Charging Component........................................................................131
4.5.5 QoS Interface.......................................................................................................................................131
4.5.5.1 Purpose and architecture ...............................................................................................................131
4.5.5.2 Description of the C API interface to the AAAC.f Server......................................................132
4.5.5.3 Description of the COPS Client interface to the QoSB.f.........................................................133
4.5.6 Auditing................................................................................................................................................135
4.5.6.1 MobyDick SLG...............................................................................................................................135
4.5.6.2 Requirements...................................................................................................................................136
4.5.6.3 Architecture .....................................................................................................................................136
4.5.6.4 Data Structures................................................................................................................................137
4.5.6.5 Event Log Transfer.........................................................................................................................139
4.5.6.6 Audit Report ....................................................................................................................................139
4.6 Paging Agent Software Specification ..................................................................................................140
4.6.1 Overview of the different functional components.........................................................................140
4.6.2 Description of the different functional components .....................................................................140
4.6.2.1 Dormant Monitoring Agent Functional Entity (DMA)............................................................140
4.6.2.2 Tracking Agent Functional Entity (TA) .....................................................................................141
4.6.2.3 Paging Agent Functional Entity (PA).........................................................................................141
4.6.3 Softwarimplementation / interfaces .................................................................................................141
4.6.3.1 Interface between the Mobile Terminal and the Paging Agent..............................................141
4.6.4 Implementation specific information ..............................................................................................144
4.6.4.1 Dormant Monitoring Agent Functional Entity ..........................................................................144
4.6.4.2 Tracking Agent Functional Entity ...............................................................................................144
4.6.4.3 Paging Agent Functional Entity...................................................................................................144
4.7 Home Agent Software Specification....................................................................................................145
4.7.1 Overview..............................................................................................................................................145
4.7.2 Detailed description of the components..........................................................................................145
4.7.2.1 Mobile IPv6 Module ......................................................................................................................145
4.7.2.2 Alternate Care -of Address support..............................................................................................146
5 MOBY DICK SIGNALLING FLOW SPECIFICATION ..................................147
5.1 Assumptions ...............................................................................................................................................147
5.1.1 Security Associations.........................................................................................................................147
D0103v1.doc 4 / 168

D0103v1.doc Version 1 6.7.2003
5.1.2 Distinction: Registration, fast intra-domain and inter-domain handover..................................147
5.2 Signalling Scenarios .................................................................................................................................148
5.2.1 Registration..........................................................................................................................................148
5.2.2 Session setup and Service authorization.........................................................................................151
5.2.3 Intra-domain handover.......................................................................................................................153
5.2.4 Inter-domain handover.......................................................................................................................155
5.2.5 Paging ...................................................................................................................................................155
5.2.5.1 General information .......................................................................................................................155
5.2.5.2 Service discovery and dormant mode regis tration....................................................................156
5.2.5.3 Paging process.................................................................................................................................159
5.2.5.4 Paging area update..........................................................................................................................160
5.2.6 Charging ...............................................................................................................................................161
5.2.6.1 Signalling Flow...............................................................................................................................161
5.2.7 Logging and Auditing........................................................................................................................162
5.2.8 Bearer Management ...........................................................................................................................164
5.2.9 Interface AR and RG..........................................................................................................................165
5.2.10 Paging ...................................................................................................................................................166
5.2.10.1 Interface between Paging Attendant and Paging Module ...................................................166
5.2.10.2 AR Paging Attendant & RG IWF............................................................................................166
5.2.10.3 Interface between Paging Attendant and Paging Agent ......................................................167
6 SUMMARY AND OUTLOOK ............................................................................168
D0103v1.doc 5 / 168

D0103v1.doc Version 1 6.7.2003
Executive Summary
In recent years, two parallel developments could be observed in telecommunications. First, the
tremendous success of the Internet and second, the success of the mobile telephones. UMTS is the
technology which will integrate both developments. However, it is not clearly visible in the existing
architecture which of the two network philosophies, connection oriented 2 G based architecture or packetoriented
Internet compatible technology, will dominate. Currently researchers and marketing people from
both, network provider and equipment vendor tend towards a long term All-IP based solution. Both
technologies have their advantages and disadvantages and, since we have never seen a revolution in the
network infrastructure, the transition process from a connection-oriented world to a packet-oriented world
will be smooth and backward compatibility is a very important issue.
Within the Moby Dick project, we took the opportunity to go straight forward towards an All-IP based
solution without taking care of such backward compatibility issues to the connection-oriented “Telephone
World”, however, to the currently deployed Internet. Based on this assumption, a wireless IP world
replacing any connection-oriented elements of the network, the IST project Moby Dick develops and
implements an architecture which substitutes all the network elements and mechanisms historically based
on the GSM based network architecture and combines these with available IP based mechanisms and
network elements to come to a scalable network architecture which would be a possible candidate for the
3,5 G and beyond based wireless access network infrastructure. Within this context is should be clearly
stated that the term ALL-IP is user in a various number of different flavours and is somehow not clear.
Especially the approaches deriving from the circuit switched GSM based technology claim to be “ALL-
IP” although having a significant part of circuit switched elements in their architecture. That’s why
sometimes Moby Dick partner used either the term “real-ALL IP” or “pure-IP” indicating that the Moby
Dick approach is more in the “spirit” of the Internet compared to most other existing approaches.
At the end of this project, which is due to 6 months (end 2003), the consortium should be able to give an
answer to the question if the Internet Protocol is able to replace the existing connection-oriented
infrastructure. The Moby Dick goal is to answer this question quantitatively as well as qualitatively. In
order to achieve this, the Moby Dick architecture contains modifications and changes of existing
protocols and IP-based mechanisms, mainly derived from the Internet standardization bodies, but do not
target the development of fundamental new protocols. The requirement of such fundamental new protocol
could be one potential outcome of the project.
D0103v1.doc 6 / 168

D0103v1.doc Version 1 6.7.2003
Abbreviations
Abbreviation
AAAC.h
AAAC.f
AG
AR
ARQ
AS
ASM
BCCCH
BU
CCCH
CN
CTCH
CoA
DC
DCCH
DCF
DSCP
DSSS
DTCH)
FDD
FHSS
GC
GGSN
GPRS
GTP
HA
HMIP
IETF
IRTF
IMSI
IP
LAN
LLA
LDAP
MAC
MAQ
MAP
MIP
MT
MN
MQA
MRF
NAI
NAS
NAR
OAR
ODMA
ODBC
ODTCH
OCCCH
ODCCH
PA
PCCH
Full Name
Home AAA server
Foreign AAA server
Access Gateway
Access Router
Automatic Repeat Request
Access Stratum
Application Specific Module
Broadcast Control Channel
Binding Update
Common Control Channel
Corresponding Node
Common Traffic Channel
Care -of Address
Data Channel
Dedicated Control Channel
Distributed Co-ordination Function
Differentiated Services Code Point
Direct Sequence Spread Spectrum
Dedicated Traffic Channel
Frequency Duplex Division
Frequency Hopping Spread Spectrum
General Control
Gateway GPRS Support Node
General Packet Radio Service
GPRS Tunnelling Protocol
Home Agent
Hierarchical Mobile IP
Internet Engineering Task Force
Internet Research Task Force
International Mobile Subscriber ID
Internet Protocol
Local Area Network
Local Link Acquirement
Light-weight Directory Access Protocol
Medium Access Control
Sequence: Mobile Node, AAA Framework, QoS Framework
Mobility Anchor Point
Mobile IP
Mobile Terminal
Mobile Node
Sequence: Mobile Node, QoS Framework, AAA Framework
Media Resource Function
Network Access Identifier
Non Access Stratum
New Access Router
Old Access Router
On Demand Multiple Access
Open Data Base Connectivity
ODMA Dedicated Traffic Channel
ODMA Common Control Channel
ODMA Dedicated Control Channel
Paging Agent
Paging Control Channel
D0103v1.doc 7 / 168

D0103v1.doc Version 1 6.7.2003
PCF
PDCP
PDU
QoSB(domain)
RBE
RLC
RNS(domain)
RR(subnet)
RRC
SAP
SHCCH
SCM
SGSN
SLA
SLS
TD-CDMA
TDD
UE
UMTS
URP
W-CDMA
Point Coordination Function
Packet Data Convergence Protocol
Protocol Data Unit
Quality of Server Broker including a policy server
Rules Based Engine
Radio Link Control
Radio Network Server
Radio Router for a specific sub network
Radio Resource Control
Service Access Point
Shared Channel Control Channel
Session Control Manager
Serving GPRS Support Node
Service Level Agreement
Service Level Specification
Time Division- Code Division Multiple Access
Time Division Duplex
User Equipment
Universal Mobile Telecommunications System
User Registration Protocol
Wideband-Code Division Multiple Access
D0103v1.doc 8 / 168

D0103v1.doc Version 1 6.7.2003
1 Introduction
This deliverable describes the first version of the architecture of the Moby Dick network infrastructure.
The goal is to provide QoS-enabled and AAA supported mobility on a heterogeneous network
infrastructure. So Moby Dick merges mechanisms of three different research areas namely QoS, AAA,
and Mobility management. This document should be regarded as baseline document throughout the whole
duration of the project. Moby Dick targets a generic architecture supporting all kind of layer 2 access
technology, however, the architectural considerations are restricted to Ethernet, Wireless LAN, and TD-
CDMA technologies. Since the integration process of QoS, Mobility, and AAA issues to provide a M-
commerce capable all-IP based wireless Internet infrastructure is quite complex it is quite supposable that
the first trial of the architecture specification does not require further iteration processes towards an open,
stable, and scalable platform for “3.5 G and beyond” based access networks.
The big challenge within the architecture is to find an ideal mixture of QoS, Mobility, and AAA elements,
mechanisms and functions which approach as far as possible to the optimised Moby Dick architecture.
The definition of the Moby Dick architecture can be regarded as an optimisation problem since each of
the three major research areas has already solutions for various problems, however, it is clear that first,
the combination of these individual mechanisms can not be achieved from a technical point of view
boundlessly and second, mechanisms and elements of one research area may have a negative impact on
the mechanisms and elements of the other research area. For this reason, the Moby Dick architecture will
be a best practice compromise between mechanisms, requirements, and solutions from the abovementioned
three research areas.
The structure of the document is as follows:
Chapter 2 starts with an overall motivation for the project Moby Dick. Here the authors would like to
summarise again the motivation for the overall project.
Since Moby Dick is targeting a “3,5 G and beyond” wireless network infrastructure assumptions and
requirements based on selected usage scenarios are required to have a realistic input to the architecture
definition. Chapter 3 describes the key architecture from a more generic and conceptual user point of
view. Chapter 4 points the detailed software architecture of the key modules and components developed
within the project. Chapter 5 describes how these detailed modules are mapped first into a functional
architecture by a detailed specification of the interaction flow between these components. In chapter 6, a
conclusion is given.
The overall structure of the project has the following nature: WP1 does define the overall Moby Dick
architecture. WP2, WP3, and WP4 are the so-called implementation workpackages. Here QoS issues
(WP2), Mobility related issues (WP3) and AAAC related issues (WP4) are specified based on the overall
architecture on a more detailed level. Since almost each component contains modules from each
implementation workpackage, this horizontal interface contains major input from all workpackages. In
the current project year all implementation workpackages officially provided an additional deliverable,
this document contains some redundant information since it is of course reported in the Deliverables of
the implementation workpackages. However, in order to increase the overall readability of this document,
this overlap intended. So the reader of this document should get a clear view of the modules and
components the project developed, specified and brought into the evaluation by means of the Moby Dick
field trial. Theoretical aspects with our close relevance to the implementation are kept outside.
D0103v1.doc 9 / 168

D0103v1.doc Version 1 6.7.2003
2 Overall Moby Dick Operation
Within this chapter, a basic Moby Dick operational scenario is described. This scenario is based on the
scenario described in the Moby Dick Deliverable D0101 which was submitted in October 2001 after a
duration of 10 months.
The generic Moby Dick overall scenario starts at first with the assumption that each user is from a
contractual point of view somehow assigned to his home domain. Result of this assumption is that the
Mobility notion is not that flexible that a vagabonding user has no fixed point of attachment where he/she
can be located. Changing this assumption would be from a research point of view very interesting since it
may require e.g. significant changes in the world-wide naming service concept, but within Moby Dick a
hard mapping of a user to a valid, world-wide reachable home address is assumed. This static home
domain could be from a technical point of view a homogeneous network infrastructure based on
exclusively on network technology, or a heterogeneous network infrastructure comprising network
segments of different technologies. In the latter, the network technologies are restricted to Ethernet
according to 802.3 standard, a wireless LAN (802.11), and/or a Moby Dick specific TD-CDMA.
Furthermore, each domain consists of at least one IP subnet. Each IP subnet corresponds to one lower
layer network access cell which can be either one of the three above mentioned layer 2 technologies.
Based on this key assumption the whole and overall Moby Dick scenario is build on. On top of this fixed
home domain, it is further assumed that a user has a contract with the provider of the home network or
home domain. This provider maintains an AAA entity (which is in the whole project called AAAC.h)
which is further responsible for validating and verifying any credentials pertinent to the user. This kind of
authority can be either located at the user premises or at any other location within the domain of the home
network provider. Contract details of the contract between user and provider are agreed based on a
Service Level Agreement (SLA) which is transformed into a User Profile which is stored on the AAAC.h.
entity, or, being more precise, in a database where this AAAC.h entity has secured and exclusive access.
Content of this profile is next to others, roaming permissions, QoS parameters and any further
information which is required to provide a user with the capability to roam around – within and between
administrative domains. Such a roaming user – or Mobile User - is allowed to connect itself using any
mobile device in any location to the network. The provider of the foreign network (foreign means here
that the use has no direct contract with the network the user wants to use) provides the user with network
resources/service according to the SLA reflected in the profile of the home domain only, if there exists a
contractual relationship between these two administrative domains. Here it might be the case that no
roaming agreement exists between the provider of the home domain and the provider of the foreign
domain (of course this is part of the profile) and in this case no service is delivered to the mobile user is
provided.
A user is allowed to move around and the required hand-over procedures enable the user to maintain any
existing connection while moving is based on the agreed SLA with the provider of the home network.
Furthermore, within Moby Dick, service consumption is metered to support the post-paid charging
scheme and registration and service requests are logged to perform auditing.
In the following, based on the above described high level scenarios, some more technology-specific
considerations are summarised.
Within a framework that integrates mobility, AAA, and QoS in heterogeneous networks, a wide range of
ways in which the user perceives the “network” is possible. Obviously, some assumptions need to be
made about how the Moby Dick network will be used as an aid to make design decisions. From a wide
range of possible scenarios, we need to concentrate on a few to optimise the effort and therefore the cost
of the network and the associated functions.
The Moby Dick service provisioning process is user specific, this means that there is a decoupling from a
user and an end-system foreseen. This de-coupling is done via the user profile. So the service
provis ioning process is user-centric.
D0103v1.doc 10 / 168

D0103v1.doc Version 1 6.7.2003
3 Moby Dick Architecture
3.1 Conceptual view
In the wired-network infrastructure circuit-switched voice communications have dominated the
telecommunications market since it’s beginning. Packet-switched voice and data communications are
currently the key drivers for the development of new communication systems and technologies. This
trend can be also observed in the wireless network segment. Also here, technologies like GPRS and of
course UMTS are lower layer designs based on circuit switched principles, but a tendency towards packet
based network design principles is evident.
The emphasis on packet-data communications brings an outstanding opportunity for heterogeneous
environments. Recent developments in the TCP/IP protocol are intended to support the development of a
multi-technology network mainly independent of the underlying physical layers, where all relevant
functions are performed at the IP level.
The importance of IP communications has already been recognized in UMTS (as well as in EDGE/IMT-
2000), which provides an IP packet service using a tunnelling mechanism but still employing all the
mechanisms of 2 nd Generation Networks. Even with these facilities, several operators question the
approach of bringing the concept of packet switching into the existing connection-oriented network
environments, since it is considered an intermediate step towards a pure IP-based solution, which will be
most probably be available in the fourth Generation mobile communication (4G) networks.
The Moby Dick approach can be regarded as a more radical alternative. The Moby Dick architecture is
being developed using three key design principles:
• The network should implement as many functions as possible using standard IP-based protocols and
technologies, by reusing as many commonalities in different access technologies as possible.
• The network should be able to provide real-time services with quality comparable to traditional
cellular networks.
• The services should be generally accessible regardless of the access network and uninterrupted
during handoff.
The overall network architecture includes the following elements (Figure 1):
Figure 1: General Network Architecture
• Mobile end-systems running user applications. Each end-system can be equipped with interfaces of
different technologies simultaneously. In particular, within the Moby Dick project, the interfaces to
TD-CDMA (UMTS-TDD), wireless LANs (802.11), and fixed networks (Ethernet) are supported;
• Access Routers, providing an interface between a wireless and a wired-network domain. It is
assumed that these domains are different IP-subnets. These gateways are associated with the tra-
D0103v1.doc 11 / 168

D0103v1.doc Version 1 6.7.2003
ditional concept of a Base Station, the actual access point of the wireless technology to a wired infrastructure,
but enriched with IP routing capabilities.
• Network management servers in the fixed network for mobility management, AAA, QoS and paging
issues
The architectures’ flexibility and the use of IP for mobility management, QoS provisioning and AAAC as
a convergence layer allows an easy and simple integration of any other access technology like UWB. In
greater detail, the network management servers consist of an AAAC system, a Home Agent for IPv6
mobility management, a QoS Broker and an IP Paging Agent. The mechanisms provided by these entities
and its proper interworking provides an overall architecture, which supports an open, cheap, efficient and
seamless network access.
The TD-CDMA support is achieved by the direct connection of the base station to the IP network (eliminating
several of the elements defined in the 3GPP UMTS architecture such as RNC, SGSN, GGSN, and thus,
simplifying the overall protocol stack). The base station was developed using platform supporting TD-CDMA-
TDD mode. Thus, the network access is provided by a radio access router which controls one radio cell. On IP
layer one, the IP subnet is directly mapped to such a radio cell.
To provide seamless mobility competitive to the one provided by existing cell networks, but with the advantage to
increase the scope of mobility across cells based on different access technologies, Fast Handover with some
enhancements and context transfer techniques are used. To increase the efficiency of both the mobile end systems
and the resource usage of the still scarce access medium, and to overcome the tremendous power required, an IP
paging concept was integrated into the overall architecture. For the provision of QoS the Diffserv model was
adopted because of its higher scalability and reduced signalling overhead. For the overall end-to-end QoS
provisioning, the association of Diffserv principles with the use of QoS Brokers controlling a QoS domain
provided large-scale support for quality of service. The AAAC support is based on the IRTF AAA Architecture
and enriched with Auditing and Charging mechanisms. This architecture covers the full integration between
AAAC, QoS, and Mobility, which provides a large step towards an real All-IP 4G network architecture
supporting TD-CDMA based access technologies as well as IEEE 802.11. The whole architecture is based on
IPv6 exploiting all IPv6 specific support for IP based mobility management.
Within Moby Dick it is foreseen, that one end-system is equipped with more that network interfaces –
which might be based different technologies -, but only one interface will be user at the same time, except
of a small period of time during a seamless handover procedure.
Figure 2 shows a more specific figure of the overall Moby Dick architecture. Here there are different
Administrative domains shown. These domains operate based on same or different access network
technologies. E.g. in the figure Domain C is based all 3 network technologies considered within the
project.
The Correspondent Node (CN) is connected via an unknown QoS supporting access technology to the
backbone and is located in the administrative Domain D.
D0103v1.doc 12 / 168

D0103v1.doc Version 1 6.7.2003
DomainD
DomainE
PA
DomainB2
AAAC.h
QoSB.h
CN
PALa
QoSBa
AAAC.fa
DomainA
Rax
QoS aware
IP Backbone
AAAC.fc
QoSBc
HA
DomainB1
DomainC
Rcx
RARa1 RARa2 RARc1
IPsubnetA1
W-CDMA
IPsubnetA2
W-CDMA
IPsubnetC1
802.11
RARc2
IPsubnetC2
W-CDMA
ARc3
IPsubnetC3
Ethernet
MT
Figure 2: Conceptual view of the Moby Dick architecture
The Home Agent (HA), “home” QoS Broker (QoSB.h), and the Home AAAC server (AAAC.h) are
placed currently in the same home domain – Domain B. However, this is not a must. Both, the HA and
the QoS.h have to be placed in the same domain but the AAAC.h can be located somewhere else in a
different domain. In this case, some additional AAA communication has to take place. Of course, each
domain operated a Home Agent (HA), but for not giving the impression that a mobile user could establish
dynamically relations to different Has, in the figure above only one HA is shown.
The Paging Agent (PA) will be somewhere, connected as well through a QoS aware network technology
to the backbone.
For Moby Dick access networks the following components are necessary:
• QoSB: QoS Broker for management of the QoS “requests” via profiles.
• AAAC.f: Foreign AAAC server for handling Authentication, Authorisation, Accounting, and
Charging issues.
• (Radio) Access Routers: They are policy points in the access network. Each air interface TD-
CDMA or wireless LAN (802.11) – will cover one IP sub-network. The Radio Access Router
(RAR) will have at least one radio interface and one fixed line interface to the domain network.
Access Router (AR) will have only interfaces to fixed lines and to each access interface a subnetwork
will be assigned.
• Routers (R): They are normal ingress (for incoming flows), egress (for leaving flows), and
interior (inside a DS domain) DS routers.
Optional for the access domains will be a local Paging Agent (PA). A local PA offers direct
communication, if needed. This leads to less signalling through the backbone.
The following components have to be Differentiated Services capable:
• CN or the router next to this node: The CN is the source of the flow.
D0103v1.doc 13 / 168

D0103v1.doc Version 1 6.7.2003
• All routers: Since they have to forward the packets of QoS flows.
• HA: In case, the CN does not know the location of the MT, the packets will be sent to the HA
which has then to forward the traffic to the “new” location of the MT.
• PA: If the MT is in idle state, the HA will forward the first few packets to the PA by using
tunnelling. This tunnels have to be DS aware and will be probably implemented by mapping the
respective DS code point from the tunnelled IP packet into the code point of the tunnelling IP
packet.
Connectivity to the QoS aware IP backbone: The different domains are connected via at least one DS
egress/ingress router to the backbone. The same is valid for the inter-connection of the access networks to
the domain’s “backbone”. These “sub-network” access routers can be fully mashed. However, they
should have full IPsec, DS, and mobility support. These are the first and important policy points for
incoming traffic (from the MT towards the backbone).
4 Moby Dick Physical Components
As a preparation for the implementation, the following types of physical elements were identified based
on the logical and conceptual Moby Dick architecture:
i) Mobile Terminal (MT)
ii) Access Router (AR)
iii) Radio Gateway (RG)
iv) QoS broker (QoSB)
v) AAAC Server
vi) Paging Agent (PA)
vii)Home Agent (HA)
At least one set of functions has been identified for each of the physical element types, and these will be
one or more software modules of the implemented system. The following sub-sections contain the
complete list of functions that are associated with each physical element type. They represent the
maximum list of functions, and some physical element instances may not need all of them. Each function
includes handling the associated message flows.
Mobile Terminal and Access Router are the two components which host logical modules of all three
implementation workpackages. Paging Agent and Home Agent are modules which mostly fulfil functions
for mobility management and thus are mainly derived from WP3 work. The QoS Bare mainly based ,
Access Router is of course a component which is exclusively provided by Moby Dick WP2 and the
AAAC Server is a WP4-exclusive component. Further, the Radio Gateway is a component for SC-TDMA
specific radio access with high interaction and involvement of WP2.
4.1 Mobile Terminal Software Specification
This section gives the software specification of the different components of the Mobile Terminal. These
include
• Networking Control Panel (NCP, section 1.1.1): graphical user interface to specify user
preferences and initiate manual handover execution.
• Mobile Terminal Network Manager (MTNM, section 1.1.2): module to decide about handover
execution.
• Fast Handover module:…
• Registration Module
• Paging Module
• Enhanced IPv6 Stack
• Network Device Drivers
Below is a high level integrated view of the different components.
D0103v1.doc 14 / 168

D0103v1.doc Version 1 6.7.2003
NCP
AR
Application 1
Application 2
MTNM
Fast Handover
module
AR
Registration
module
Paging
module
AR
Enhanced IPv6 stack
Standard IPv6 stack
MIPL
IPSec
DSCP marking software
Network device drivers
TD-CDMA NDD on RG
TD-CDMA:
RCM / RCF
WLAN
Ethernet
Internal interface
Protocol
communication
AS on RG
Access Stratum
Kernel space
User space
Figure 3: Mobile Terminal Software Architecture
4.1.1 Overview of the different components
4.1.1.1 Networking Control Panel
This module provides a graphical user interface, letting the user specify his preferences regarding
Network Technologies (TD-CDMA, WLAN, Ethernet) and Handover execution (manual, automatic,
both). The user uses it to request the beginning and the end of a network connection (AAAC registration /
deregistration). The user also uses it to start a manual handover.
This module also provides information about availability and quality of Network Technologies.
It is implemented as a user space program, using gtk for the GUIs.
4.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 (TD-CDMA, 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 section.
4.1.1.3 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 AAAC 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 section.
D0103v1.doc 15 / 168

D0103v1.doc Version 1 6.7.2003
4.1.1.4 Registration module
This module will take care of all the actions related to AAAC, 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).
The behaviour of these components will be detailed in the next section.
4.1.1.5 Paging module
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
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 TD-CDMA, the same mechanism will be deployed here, which is addressing the mobile
terminal’s TD-CDMA Solicited Node Multicast Address from the AR/RG. This address is to be derived
out of the mobile terminal’s TD-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.
The behaviour of this Paging Module, its components and the relations to previously presented Moby
Dick architectural components will be detailed in the next section.
4.1.1.6 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.
• 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.
DSCP Marking Software
The DSCP marking software is composed of an application level module, which communicates with a
kernel level module, 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, AAAC, 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
The behaviour of these components will be detailed in the next section.
4.1.1.7 Network Device Driver
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.
D0103v1.doc 16 / 168

D0103v1.doc Version 1 6.7.2003
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 section.
Radio Convergence Function
This module will act as a specific TD-CDMA driver, giving low level interfaces to open / close
connections, manage data channels, send and receive IP packets, get some feedback on the TD-CDMA
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 section.
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 noise
ratios, and to receive Router Advertisements.
These functions should be implemented at a L2 level. The behaviour of these components will be detailed
in the next section.
4.1.1.8 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.
The functions and services provided by the Access Stratum will be detailed in next section.
4.1.2 Detailed description of the components
This section gives a detailed description of the sub-blocks of each component, and their interactions with
other components .
4.1.2.1 Networking Control Panel
The NCP has interactions (only) with the user and the MTNM, as described in the figure below. It is split
into the following sub-blocks.
• Set Network Preference Sub-block
• Set Handover Preference Sub-block
• Manual Handover Sub-block
• Network Environment Info Sub-block
• Explicit Connectivity Request Sub-block
4.1.2.1.1 Set Network Preferences block
The user will set his/her preferences as follows: first choice x, second choice y, third choice z; with each
x,y,z as one of the possible choices: Ethernet, TD-CDMA, 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 disconnection via the Explicit Connectivity Request sub-block, the data will
be saved in the configuration file.
4.1.2.1.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).
Each time a user requests a disconnection 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.
D0103v1.doc 17 / 168

D0103v1.doc Version 1 6.7.2003
NCP
Set
Network
Preferences
Set
Handover
Preference
Manual
Handover
Network
Environment
Infos
Explicit
Connectivity
Request
MTNM
Set
Network
Preferences
Set
Handover
Preference
Network
Environment
Infos
Manual Handover
Attach / Detach
Procedure
Figure 4: Networking Control Panel
4.1.2.1.3 Network Environment Info 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 a certain signal to noise ratio and the TD-CDMA will have a
certain signal level.
These information will be transmitted by the Network Environment Info block of the MTNM, via the
message NETWORK_ENVIRONMENT_INFOS.
If more than one WLAN or TD-CDMA 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. We consider a
choice between the same network technology for WLAN and TD-CDMA, 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 being used. This information is also
transmitted by the Network Environment Info 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.
4.1.2.1.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, TD-CDMA), one that is available (but not the
D0103v1.doc 18 / 168

D0103v1.doc Version 1 6.7.2003
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 TD-CDMA will be considered as available if its signal level is higher than a predefined threshold
(TD-CDMA_threshold).
The user will have this information: current signal level. In the 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 TD-CDMA.
The order to execute a manual handover will be transmitted to the Manual Handover block of the MTNM,
via the message MANUAL_HANDOVER_REQ.
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 TD-CDMA 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.
4.1.2.1.5 Explicit Connectivity Request block
The effective connection to the network (AAAC 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 AAAC action). No parameters will be
needed.
An acknowledgement is expected from the MTNM, via message
TERMINATE_NETWORK_CONNECTION_ACK, with parameter status.
4.1.2.2 Mobile Terminal Networking Manager
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
Set
Network
Preferences
Set
Handover
Preference
Network
Environment
Infos
Attach Procedure
Manual
Handover
Automatic
Handover
Paging
Figure 5: Mobile Terminal Networking Manager
4.1.2.2.1 Set Network Preferences block
The following schema can be used to illustrate the description of the 3 first sub-blocks.
D0103v1.doc 19 / 168

D0103v1.doc Version 1 6.7.2003
NCP
Set
Network
Preferences
Set
Handover
Preference
Manual
Handover
Network
Environment
Infos
Explicit
Connectivity
Request
MTNM
Set
Network
Preferences
Set
Handover
Preference
Network
Environment
Infos
Network device drivers
TDCDMA WLAN Ethernet
Figure 6: Interactions between MTNM / NCP
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, TD-CDMA, WLAN.
4.1.2.2.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.
4.1.2.2.3 Network Environment Info 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, TD-CDMA_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 Info 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 TD-CDMA.
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.
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.
D0103v1.doc 20 / 168

D0103v1.doc Version 1 6.7.2003
• If WLA N 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 TD-CDMA, the message TD-CDMA_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 TD-CDMA “access point” if this technology is in use, and best candidate for handover.
And the same algorithm as for WLAN applies.
By construction, the TD-CDMA 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 is implemented.
The Network Environment Info 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 TD-CMDA, it means receiving the message LOST_TD-CDMA_CONN from the RCM,
indicating that the radio connection has been lost; or receiving a message TD-CDMA_INFO
from the RCM, with a signal level lower than TD-CDMA_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
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.
4.1.2.2.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.
D0103v1.doc 21 / 168

D0103v1.doc Version 1 6.7.2003
• Third case: the layer two connectivity has been lost unexpectedly as explained in the Network
Environment Info sub-block, and the Automatic Handover sub-block requests an attach
procedure.
NCP
Set
Network
Preferences
Set
Handover
Preference
Manual
Handover
Network
Environment
Infos
Explicit
Connectivity
Request
MTNM
Set
Network
Preferences
Set
Handover
Preference
Network
Environment
Infos
Attach
Procedure
Registration module
Network device drivers
TDCDMA WLAN Ethernet
Figure 7: Attach Procedure block
In the first case, an initial step will be to wait until the Network Environment Info block has received
information from the different device drivers. Then to select a network technology, using the information
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 Info block, and
selected or rejected according to the following rules: Ethernet is selected if present, WLAN and TD-
CDMA are selected if present and signal to noise ratio for WLAN, signal level for TD-CDMA, is higher
than a predefined threshold (respectively WLAN_threshold and TD-CDMA_threshold).
For example, if network preferences are first WLAN, second TD-CDMA and third Ethernet; and if
WLAN signal to noise ratio is lower than WLAN_threshold, but TD-CDMA signal level higher than TD-
CDMA_threshold and Ethernet is present: WLAN is examined first and rejected, TD-CDMA 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 section ‘Handover Execution’, for each of the 3 available technologies. One can refer
to this section 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 AAAC
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 certain timeout.
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.
D0103v1.doc 22 / 168

D0103v1.doc Version 1 6.7.2003
No AAAC 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 section ‘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.
4.1.2.2.5 Manual Handover block
NCP
Set
Network
Preferences
Set
Handover
Preference
Manual
Handover
Network
Environment
Infos
Explicit
Connectivity
Request
MTNM
Set
Network
Preferences
Set
Handover
Preference
Network
Environment
Infos
Manual
Handover
Fast Handover module
Network device drivers
TDCDMA WLAN Ethernet
Figure 8: 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 TD-CDMA are higher than the predefined thresholds
WLAN_threshold and TD-CDMA_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 TD-CDMA (as explained in
the description of NCP).
Every n milliseconds, the following actions will be taken, if the current Network Technology is WLAN or
TD-CDMA, and only if the current signal level is lower to a predefined threshold (WLAN_threshold and
TD-CDMA_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 TD-CDMA) 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 TD-CDMA: TD-CDMA signal level + delta_TD-CDMA < best
candidate TD-CDMA signal level).
D0103v1.doc 23 / 168

D0103v1.doc Version 1 6.7.2003
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,.
4.1.2.2.6 Automatic Handover block
MTNM
Set
Network
Preferences
Set
Handover
Preference
Network
Environment
Infos
Automatic
Handover
Fast Handover module
Network device drivers
TDCDMA WLAN Ethernet
Figure 9: 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 TD-CDMA 1 TD-CDMA 2 TD-CDMA 3
WLA N 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)
Table 1: Network Preferences
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, TD-CDMA will
be considered first, and Ethernet second, as a potential handover technology.
In the case of WLAN and TD-CDMA, 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 subnetwork;
but only if the signal level is lower than a predefined threshold (WLAN_threshold and TD-
CDMA_threshold respectively).
The 3 following situations can happen:
• Ethernet is the current Network Technology: higher preference level Network technologies are
considered.
D0103v1.doc 24 / 168

D0103v1.doc Version 1 6.7.2003
o For TD-CDMA, a decision for handover is taken if the signal level of best candidate for
handover is higher than TD-CDMA_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 TD-CDMA, a decision for handover is taken if the signal level of best candidate for
handover is higher than TD-CDMA_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.
• TD-CDMA 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 TD-CDMA_threshold, a best candidate for TD-CDMA “access point” handover is
present in the Network Environment Infos, and the signal levels follow this relation:
current TD-CDMA signal level + delta_TD-CDMA < best candidate TD-CDMA signal
level, a decision for handover is taken. We introduce delta_TD-CDMA, because we
don’t want to handover to a TD-CDMA new “access point”, which signal level is not
significantly better.
In the case of WLAN and TD-CDMA, 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 TD-CDMA_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.
4.1.2.2.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 intra-domain handover is considered, which will result in a fast-handover.
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
D0103v1.doc 25 / 168

D0103v1.doc Version 1 6.7.2003
Router. The acknowledge message USE_WLAN_AR_ACK will be received from the WLAN
driver, with parameter status.
• If TD-CDMA is the new L2 technology, the message OPEN_TD-CDMA_CONN must be sent
to the TD-CDMA driver, with parameters cell Id of selected Radio Gateway, Home Address and
CoA of MT. The acknowledge message OPEN_TD-CDMA_CONN_ACK will be received from
the TD-CDMA 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 TD-CDMA is the old L2 technology, the message CLOSE_TD-CDMA_CONN must be sent
to the TD-CDMA driver, with parameter local_connection_reference. The acknowledge
message CLOSE_TD-CDMA_CONN_ACK will be received from the TD-CDMA driver, with
parameters local_connection_reference and status.
• If WCMA is the old and new L2 technology, we will use only the message OPEN_TD-
CDMA_CONN, with a specific parameter (fho_optimisation). The TD-CDMA driver will first
close the old connection, then open the new one, and send the acknowledge message OPEN_TD-
CDMA_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 section 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 of
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).
4.1.2.2.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, TD-CDMA 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 subblock
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.
D0103v1.doc 26 / 168

D0103v1.doc Version 1 6.7.2003
NCP
Set
Network
Preferences
Set
Handover
Preference
Manual
Handover
Network
Environment
Infos
Explicit
Connectivity
Request
MTNM
Attach
Procedure
Network
Environment
Infos
Paging
Paging module
Figure 10: Paging block
4.1.2.3 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
Radio Connection
Radio
Manager
Connection Manager
Radio
Infos
Open /
Close
Packet Transmission
Control
Data
Packet
Packet
Packet Packet Reception Reception
Control
Data
Packet
Packet
Conn
Figure 11: Radio Channel Manager
D0103v1.doc 27 / 168

D0103v1.doc Version 1 6.7.2003
4.1.2.3.1 Radio Connection Manager block
Paging module
MTNM
Network
Environment
Infos
Administration,
reconfiguration,
of drivers
Enhanced IPv6 stack
RCM
Radio
Connection Manager
Radio
Infos
Open /
Close
Packet Transmission
Control Data
Packet Packet
Packet Reception
Control Data
Packet Packet
Conn
RCF
TD-CDMA
Connection Manager
TDcdma
Infos
Open /
Close
Paging
Control Channel Mngt
Send /
Receive
Data Channel Mngt
Open / Send /
Close Receive
Conn
Data
Data
Chanels
Data
AS
4.1.2.3.2 Radio Infos sub-block
Figure 12: Radio Connection Manager Block in the Mobile Terminal
The Radio Infos sub-block transmits radio information received from the RCF to the Network
Environment Infos block of the MTNM, via the message TD-CDMA_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.
4.1.2.3.3 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_TD-CDMA_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_TD-
CDMA_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_TD-CDMA_CONN, to close a
connection, to the RCF. There will be one parameter: local connection reference.
It transmits the report status from the RCF of the close connection command, via message CLOSE_TD-
CDMA_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_TD-CDMA_CONN. There will be one parameter: local connection reference.
D0103v1.doc 28 / 168

D0103v1.doc Version 1 6.7.2003
4.1.2.3.4 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.
Enhanced IPv6 stack
RCM
Radio
Connection Manager
Radio
Infos
Open /
Close
Packet Transmission
Control Data
Packet Packet
Packet Reception
Control Data
Packet Packet
Conn
RCF
TD-cdma
Infos
TDCDMA
Connection Manager
Open /
Close
Conn
Paging
Control Channel Mngt
Send /
Receive
Data
Data Channel Mngt
Open /
Close
Data
Chanels
Send /
Receive
Data
AS
4.1.2.3.5 Packet Transmission block
Figure 13: 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
TD-CDMA 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 TD-CDMA, 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
connection; as the TD-CDMA 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. This mapping is performed on the Radio Gateway, not on the Mobile Terminal.
If the radio bearer is not yet establis hed, a request is made to the Data Channel Management block of the
D0103v1.doc 29 / 168

D0103v1.doc Version 1 6.7.2003
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 TD-CDMA 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 AAAC 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.
4.1.2.3.6 Packet Reception block
Enhanced IPv6 stack
RCM
Radio Connection
Manager
Radio
Infos
Open /
Close
Packet Transmission
Control Data
Packet Packet
Packet Reception
Control Data
Packet Packet
Conn
RCF
TD-cdma
Infos
TD-CDMA
Connection Manager
Open /
Close
Conn
Paging
Control Channel Mngt
Send /
Receive
Data
Data Channel Mngt
Open / Send /
Close Receive
Data Data
Chanels
AS
Figure 14: 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.
D0103v1.doc 30 / 168

D0103v1.doc Version 1 6.7.2003
4.1.2.4 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 TD-CDMA AS layer. It is split into the
following sub-blocks.
RCF
TD-CDMA Connection WCDMA Manager
Connection Manager
TD-cdma Wcdma
Infos
Infos
Open /
Close
Conn
Paging
Control
Control
Channel
Channel
Mngt
Mngt
Send /
Receive
Data
Data
Data
Channel
Channel
Mngt
Mngt
Open /
Send /
Close
Receive
Data
Data
Channels
Figure 15: Radio Convergence Function
The schemas of the previous section on the RCM can be used to describe the interactions between the
RCM / RCF / AS modules.
4.1.2.4.1 TD-CDMA Connection Manager block
TD-CDMA 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 TD-CDMA_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 TD-CDMA_INFO at any moment,
as already explained in a previous section. 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.
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.
D0103v1.doc 31 / 168

D0103v1.doc Version 1 6.7.2003
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.
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.
TD-CDMA EUI-64 identifier
The hardware identifier of the TD-CDMA 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 TD-CDMA device driver. This will be used to build the IPv6 address.
4.1.2.4.2 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 AAAC 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 sections where this
signalling is used.
4.1.2.4.3 Data Channel Management block
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.
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
D0103v1.doc 32 / 168

D0103v1.doc Version 1 6.7.2003
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.
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.
4.1.2.5 Fast Handover module
MTNM
Set
Network
Preferences
Set
Handover
Preference
Automatic / Manual
Handover
Network
Environment
Infos
Fast RCF Handover Module
Context
Transfer
WCDMA
Connection Manager
Wcdma
Infos
Fast Handover
Execution
Open /
Close
Enhanced IP stack and
Mobile IP stack
Network device drivers
TDCDMA WLAN Ethernet
Figure 16: FHO module and its interfaces
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 interdomain
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. 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.
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.
D0103v1.doc 33 / 168

D0103v1.doc Version 1 6.7.2003
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; figure 17 depicts
the behaviour of FHO module.
USERSPACE
MTNM
KERNELSPACE
FHO
START_FHO
L2_REQ
-Sending Router Soll. Proxy
-Receiving Proxy Router Adv
-Sending Fast Binding Update
-Receiving Fast Binding Ack
Configuring
Layer 2 handover
L2_ACK
-Fast Handover Execution
FHO_ACK
Figure 17: 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 message flow depicted in figure 18 is executed.
According to what is specified in previous sections, the module performs two main tasks:
• on the oldAR when the Router Solicitation Proxy message is received FHO module recovers
AAAC context from AAAC 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
AAAC context to the AAAC 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.
D0103v1.doc 34 / 168

D0103v1.doc Version 1 6.7.2003
Mobile
Node
STARTFAST_HANDOVER
message from MTNM
Old Access
Router
Router solicitation Proxy
Proxy Router Advertisement
create new CoA
Handover Initate
New Access
Router
ICMP message
get the new CoA
Fast Binding Update
Handover Acknowledgement
check new CoA
Fast Binding Acknowledgement
Fast Binding Acknowledgement
Diconnect
Connect
Fast Neighbour advertisement
disconnected time
Figure 18: FHO exchange of messages
4.1.2.6 Paging module
IP Paging module
Common ID
handler
IP Paging
engine
MT dormant
state manager
MTNM
Dormant state
watchdog
Signaling
state machine
Enhanced IPv6 proto
MIPv6
IPv6
Figure 19: Paging module
4.1.2.6.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.
• 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
D0103v1.doc 35 / 168

D0103v1.doc Version 1 6.7.2003
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.
4.1.2.6.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, 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 previous specifications, 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.
4.1.2.6.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 deregistration
procedure, including re -establishment of system information.
Furthermore, this block should store information on the discovered Paging Agent address.
4.1.2.6.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
is to be checked with the common paging ID block and high-level actions are to be requested from the
dormant state manager.
4.1.2.7 Registration Module
D0103v1.doc 36 / 168

D0103v1.doc Version 1 6.7.2003
WP4 UserSpace
WP3 UserSpace
Kernel Component
Figure 20: Registration Module Legend
MTNM
Trigger Reg
Trigger HO
URP Client
calls
StartInterdomainHO
IPSec
Figure 21: Registration Overview
URP Client
MTNM
Interface
Registration
Protocol Handler
IPSec Interface
[PF_KEY]
Crypto
Services
Figure 22: Registration components of URP Client
This module will take care of all the actions related to AAAC, mainly the registration phase. The
registration module is also called URP Client. It will also be used when a handover is required, but the
Fast Handover cannot be used (inter-domain mobility, unexpected network connectivity loss).
Whenever a new registration takes place or an inter-domain handover is initiated, the MTNM triggers the
registration process by sending the message StartInterdomainHO (message 1 in the diagram below). The
MTMN reads in / stores the User-Name (== NAI) and passes it on to the URP for registration. Now the
URP module sends a registration request to the Attendant on the AR, which in turn gets the user
authenticated form the AAAC-h server. Upon receiving the response of the registration from the
attendant, the URP sends it to the MTNM via the SendRegResponse message. The MT is allowed to send
packets into the network only if the response received from the AAAC server is positive.
The messages, which are exchanged between the URP and the MTNM modules are sketched below,
including the respective parameters.
Whenever a new registration takes place or an inter-domain handover is initiated, the MTMN sends the
same message to URP_CLIENT.
Step1
This message is sent by the MTMN to the URP module when an Interdomain HO or a registration takes
place.
D0103v1.doc 37 / 168

D0103v1.doc Version 1 6.7.2003
Message:
Parameters:
StartInterdomainHO
MesgType
MesgLen
MN-info - stream of bytes of variable length
The structure of MN-info is as follows:
MN-info
in6_addr MIPv6-Mobile-Node-Address (home address of the MT)
in6_addr MIPv6-Home-Agent-Address
in6_addr CoA-MN
in6_addr AR-Addr
MN-AAACh-Secret-Key
Current Interface Name
User-Name
Step2
In order to get authenticated from the AAAC server this message is sent out
Message:
MNA_Rq
This message is not relevant for the URP-MTNM interface
Step3
The response the URP gets from the attendant
Message:
MNA_Rsp
This message is not relevant for the URP-MTNM interface
Step4
Upon receiving a MNA_Rp from the AAAC-Attendant, the URP sends this message to MTMN)
Message: SendRegResponse {
Parameters: MesgType
MesgLen
RespCode (states whether the AAAC reg. was successful or not)
Mobile Terminal
Access Router
User Space
URP Module
4. SendRegResp
2. MNA_Rq
3. MNA_Rp
User Space
AAA Att.
1.
Trigger
StartIntDomHO
NTNM Module
Kernel
Kernel
Figure 23: Registration messages
Also the following message is sent from MTNM to URP, after a successful Fast Handover:
Message:
StartFHO_REG
D0103v1.doc 38 / 168

D0103v1.doc Version 1 6.7.2003
Parameters:
MesgType
MesgLen
MN-info - stream of bytes of variable length
The structure of MN-info is as follows:
MN-info
in6_addr CoA-MN
in6_addr AR-Addr
Current Interface Name
4.1.2.8 Enhanced IPv6 stack
No further details are needed for this component.
4.1.2.9 DSCP Marking Software
Application 1 Application 2
Application level module
DSCP
matching
table
Fast Handover
module
Enhanced IPv6 stack
Standard IPv6 stack
MIPL
DSCP marking software
Network device drivers
TDCDMA WLAN Ethernet
Figure 24: Location of the DSCP marking software in the IP stack
The previous figure shows where the DMS (DiffServ Marking Software) will be located in the protocol
stack. It ”intercepts” packets just before transmitting them to the lower layer. Thus, all the packets
generated by both the IP stack and the upper layers can be filtered and marked.
4.1.2.9.1 Operation
When a new packet is ready to be transmitted to the layer two, the DMS inspects its header and consults a
DSCP Matching Table. This table contains a set of filters to apply on the information extracted from the
header, and the values of the associated DSCPs. Then, if one of the filters matches perfectly with this
information, the packet is marked with the value of the DSCP associated with this filter.
4.1.2.9.2 DMS Architecture
The DMS contains five components, as in figure 23:
• a DSCP Matching Table (DMT): this table contains the definition of every filter and the DSCP
associated with it in the Linux kernel space,
• a DSCP Marking Function (DMF): this is the DMS engine, which consults the fields in the different
headers of each packet, compares it with the filters in the DMT, and decides to mark or not the
packet with a new DSCP; it is located in the Linux kernel (in the IPv6 code),
D0103v1.doc 39 / 168

D0103v1.doc Version 1 6.7.2003
• a Filters Database (FD): this file (or set of files) contains the definitions of all the filters, in the user
space,
• a Table Update Module (TUM): this is a Linux module in charge of updating the DSCP Matching
Table with the data stored in the Filters Database,
• a Service Table (ST): this table, only used by the TUM, associates a DSCP with each service.
4.1.2.9.3 DSCP Matching
The packet marking process is based on the search of a table containing all the filters definitions
whenever a packet is ready to be transmitted. In this section, we describe how these filters are introduced
by a user, and how the DMT is built and updated.
Kernel Space
User Space
DSCP Marking
Function (IPv6)
Table update
Module
Service
Table
DSCP
Matching
Table
Filters
Db
Rules1.txt
Rules2.txt
Rules3.txt
Figure 25: DMS Components
4.1.2.9.4 Packet filtering
The description of a filter is as follows:
Filter
Description
TCPDestPort
IP6SrcAddr
CoS
10
FTPFilter
21
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
S1
Table 2: Filter Description
The complete descriptions of the filters are stored in one or several files (the FD). Each file is loaded in
the DMT with help of the TUM. Then, when a packet is ready to be delivered to the lower layer, the DMF
consults the DMT, and marks the packet with the DSCP associated with the first filter that matches with
the information of its header(s).
A filter contains:
• An identifier (the ‘Description’ field), which also represents its priority. Thus, if two filters
match, only the first one, i.e. the one with the lowest identifier, is considered.
• A description, i.e. a filter name.
• A CoS: the value of this field can be either a service identifier (S1, S2, …) or a DSCP. If this
value is a service identifier, then the DSCP associated with the filter will be found by the TUM
in the ST.
• A list of items, with their values. The number of items is not limited, and a list of items can be
empty (then, all the packets are marked with the DSCP associated with the filter). Packets are
marked with the DSCP associated with the filter only if all the items values are equal to the
corresponding fields values in the different headers of the packet. On the previous example, a
packet will be marked with the ‘101110’ DSCP (which is associated with the S1 service in the
ST) only if, in the packet headers, the TCP Destination Port is set to ‘21’ and the IPv6 Source
Address is set to ‘FEDC:…:3210’. If only one value doesn’t match, then the filter also doesn’t
match.
Typically, each description can use all the possible fields of the different headers added by the network
and the transport layers. This software supports a large subset of these fields, in the following headers:
IPv6 main header, TCP, UDP, Destination option (including the Binding Update, Binding
D0103v1.doc 40 / 168

D0103v1.doc Version 1 6.7.2003
Acknowledgment, Binding Request, and Home Address options), Routing option, Hop-by-hop option,
Authentication option, Encapsulating Security Payload (ESP) option, Fragment option, IPv6 (tunnelling),
and ICMPv6.
The goal of this software is simple: the filtering rules will not be directly written in the XXX. In fact, the
software offers the possibility to filter packets using a more or less complete subset of the different header
fields. Only the user, and/or the network administrator, thanks to their good knowledge of the network
protocols, is able to define precisely these rules. Thus, the code of the software is the same in all the
different entities of the network using it, and in all the different QoS domains. Only the contents of the
filters can change from an entity to another, or from a QoS domain to another.
4.1.2.9.5 DSCP Matching Table
When a user, or a network administrator, triggers a modification of the filters descriptions, the TUM
modifies the DMT automatically. In this section, we describe how this table is organized.
Filter number
(= line number)
0
1
2
3
4
…
N
Filter Pointer
Filter0Ptr
NULL
Filter2Ptr
Filter3Ptr
NULL
…
FilterNPtr
Table 3: Format of the DMT
Each line of the table only contains a pointer to a complete description of a filter loaded in the memory
(see Table 3).
Each filter is a simple structure containing a description, the DSCP (CoS) used to mark each packet that
matches this filter, a set of bits identifying the different headers to examine, and a pointer to a list of items
representing the different fields of the packet header that are to be inspected (see figure 26). Thus, the
number of fields in a filter is variable. The bits identifying the different headers to examine accelerate the
filtering process. Indeed, if a filter contains items related to TCP fields, and if the packet does not contain
a TCP header, the filter doesn’t match, and browsing its items list and the header fields’ values becomes
useless. The use of these bits avoids useless treatments in the DMF.
Every item of this list contains an identification of the field to inspect, i.e. a value identifying the name of
the field in the kernel (IP6_SRC_ADDR is equivalent to the IP6SrcAddr field in the FD,
TCP_SRC_PORT is equivalent to the TCPSrcPort field, etc.), the expected value of this field, and a
pointer to the next item.
Desc .: ANiceFilter
Headers: IP6, TCP
CoS: 101101
Items list: item1
Ident.: IP6_SRC_ADDR
Value: FEC0::1
Next: item2
Ident.: IP6_DSCP
Value: 010110
Next: item3
Ident .: TCP_SRC_PORT
Value: 21
Next: NULL
Figure 26: Representation of a filter in the Linux kernel
It is possible that the information extracted from the packet header matches with several filters. Only the
first filter is taken into account. Thus, the number of the filter, which is the range of the filter in the table,
represents its priority. The lower is this number, the greater is the priority of the filter. So, it is important
to sort the filters from the more detailed to the less detailed.
Table updates
The TUM modifies the DMT each time the user, or the network administrator, modifies the FD and
communicates it to the module (figure 27). The modified FD – which is a single text file – is forwarded to
the module over a simple Linux character device (/dev/dscp). This solution is the simplest way to
D0103v1.doc 41 / 168

D0103v1.doc Version 1 6.7.2003
communicate information from the user space (here, the FD) to the kernel space where the DMT is
located.
Thus, the user only has to write on this device with the contents of the FD (by the ‘cat filters_database.txt
> /dev/dscp’ command for ex.). Then, the TUM automatically reads the text written on the device, and
updates the DMT in the Linux kernel. Note that it is not necessary to write the entire FD on the device to
update properly the DMT: only a file containing new filters, or a subset of modified filters can be
communicated to the TUM.
User
AAAC
Table update
Module
3b
Filtering Rules & DSCP
1 2 3a
Service
Table
Character device
/dev/ dscp
1: Filters writing
2: Filters reading
DSCP
Matching
Table
3a: DSCP update
3b: Filters update
Figure 27: DMT and SC update process
For the moment, the table update process is triggered manually, by writing on the /dev/dscp character
device. However, it is possible to make the AAAC system update the FD, in the same way than the DSCP
update (see section 4.1.2.9.8) or triggering automatic updates regularly, in the user space.
4.1.2.9.6 DSCP marking
DSCP marking is done thanks to a modification of the Traffic Class and Flow Label fields in the IPv6
header. When the information of the packet header matches with a filter, the corresponding DSCP is
marked in the header of the packet: the four first bits of the DSCP are stored in the last four bits of the
Traffic Class field, and the last two bits, plus two bits set to ‘0’, are stored in the four first bits of the Flow
Label field.
DSCP
Vers
TC
…..
Flow Label
Figure 28: DSCP bits in the IPv6 main header
4.1.2.9.7 Packet re-marking
This operation is supported by the DMT, if the DMS is installed in a Linux router. To re-mark packets,
the network administrator has just to add a new filter, containing a ‘IP6DSCP’ item, in the FD. This filter
evaluates the DSCP in the new packet header, and associates a new value with it.
4.1.2.9.8 DSCP updates and interaction with AAAC
In the first version of the DMS, provided in October 2002, the ‘CoS’ field value in each filter in the FD
was only a DSCP (e.g. ‘110110’, …). However, if we consider that several users can be located on the
same MT, but with different QoS contracts, the same applications may use different QoS services for two
different users. Thus, when a user enters in a new domain, she has to load the proper DSCP for each
service she’s authorized to ask for, and to associate each service to each application she can launch. The
second version of the DMS, provided in March 2003, offers the possibility to the user to use both DSCP
values and service identifiers in her filters. In fact, a user can write a service identifier in the ‘CoS’ field
D0103v1.doc 42 / 168

D0103v1.doc Version 1 6.7.2003
instead of a DSCP, and the TUM associates itself this service identifier with a DSCP value, loaded from
the network, thanks to the Service Table.
So, when a user registers, the AAAC module in the MT simply sends a list of service identifiers, with
their associated DSCPs, to the TUM, via the /dev/dscp character device (see figure 27). For example, it
can write ‘SIG 50’, ‘S1 5’, ‘S2 10’, ‘S3 15’, …, ‘S7 35’ on the device. Then the ST looks like in Table 5.
Service DSCP
SIG 50
S1 5
S2 10
S3 15
S4 20
S5 25
S6 30
S7 35
Table 4: Service Table example
What we call here a ‘service’ is only a marking type. The service notion in the MT is lightly different
from the service notion in the network. In fact, S1 means ‘the first service marking type’. So, if the user is
authorized to use only a subset of the network services, it is possible that several marking types will have
the same value, which means that different applications associated with different service names may, in
fact, use the same DSCP.
During the user registration, the MT will always receive seven DSCP codes, which is the number of CoS
defined in Moby Dick. The filters will also be the same in all the Mobile Terminals.
By default, all the DSCPs are set to 0, excepted the SIG value, which is set to 34 (100010 in binary). Each
DSCP can be manually initialised, by the user or the MT administrator himself, by writing ‘SX DSCPX’
on the /dev/dscp character device, where X is the service number. However, a manual initialisation of the
DSCPs is probably useless, considering that a user cannot send traffic towards the network without
registering first.
4.1.2.10 Monitoring Extensions to Ethernet / WLAN driver
4.1.2.10.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.
4.1.2.10.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:
D0103v1.doc 43 / 168

D0103v1.doc Version 1 6.7.2003
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
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.
4.2 Access Router Software Specification
Figure 29 depicts a functional overview of the Access Router (protocol communications with MT are not
shown in this figure).
The basic functional blocks are:
• The Fast Handover Module which is responsible for an appropriate context transfer for intra-mobility
scenarios.
• A Paging Attendant which is responsible for paging in the connected access cell.
• The AAAC Framework which is represented by a Metering module and the AAAC Attendant.
• A QoS Attendant which is responsible for executing QoS related actions on the Access Router.
• The Enhanced IPv6 stack and the Network Device Drivers.
• The Logger which is responsible for logging availability, registration, and authorization events.
All these modules will be described in greater detail in the following sections.
4.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.
4.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 AAAC, and security parameters that will be done between the old AR and the
new AR to speed up handover. QoS context is transferred by the QoS infrastructure.
4.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 AR will create an
on-link paging request to awake the dormant MT (if it is in the corresponding cell).
4.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 is used.
4.2.1.4 Enhanced IPV6/IPSec/DiffServ packet Filter
The enhanced IPv6 stack is 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.
• Mobile-Ipv6, needed for Fast-Handoff implementation
• 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.
D0103v1.doc 44 / 168

D0103v1.doc Version 1 6.7.2003
MT
PA
RG
AAAC server
QoS broker
AR
Fast Handover
module
IP paging
attendant
AAA andQoS modules
AAA
Attendant
Metering
Logger
QoSManager
QoS
Attendant
DSCP table
PEP
Enhanced IPv6 stack
Standard IPv6 stack
IPSec
Diffserv
Packet filter
DiffServ
Marking
Soft
Network device
drivers
Internal interface
Protocolcommunication
WLAN
Ethernet
Figure 29: Access Router Software Architecture.
4.2.1.5 AAAC Attendant
The AAAC attendant acts as AAAC 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 deals further with a metering module. For that purpose it has an interface with the Metering
module.
4.2.1.6 Metering
It deals with metering issues. It will be controlled by the AAAC attendant which will decide when start or
finish metering a particular user session. Metering is based on the output of the IETF Real Time Flow
Measurement working group with project specific enhancements.
4.2.1.7 QoS Manager
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 initiation order from the fast handover module and contacts the PEP so that the QoS
infrastructure performs the QoS context transfer. Also the QoS attendant tells the FHO module of the
availability or not of QoS resources in the nAR during the FHO process.
4.2.1.8 Logger
The Logger consists of two parts:
• Integrated Logger which is integrated into AAAC Client and QoS Manager.
• Local Log Management
The AAAC Client’s Integrated Logger is responsible for generating Availability Event Logs and User
Registration Event Logs, while the QoS Manager’s Integrated Logger is responsible for generating
Availability Event Logs and Service Authorization Event Logs.
D0103v1.doc 45 / 168

D0103v1.doc Version 1 6.7.2003
The Local Log Management transfers the logs generated by Integrated Loggers to the Auditing
Framework.
4.2.1.9 DSCP Marking Software (DMS)
The goal of the DMS is to mark packets with a DiffServ Code Point (DSCP) reflecting the level of QoS
requested by the corresponding stream. Packets are marked according filtering rules (i.e. policies) defined
by the network administrator, in the user space.
When a new packet is ready to be transmitted to the layer two, the DMS inspects its header and consults a
DSCP Matching Table. This table contains a set of filters to apply on the information extracted from the
header, and the values of the associated DSCPs. Then, if one of the filters matches perfectly with this
information, the packet is marked with the value of the DSCP associated with this filter.
4.2.2 Description of the different Components
4.2.2.1 Network device drivers
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.
Network device drivers
WLAN
Ethernet
Figure 30: Network Device Driver
The Network Device Drivers provide layer 2 connectivity to the AR. WLAN will be used in WLAN AR
to provide WLAN access to visiting MT. Ethernet will be used to provide network access to visiting MTs.
Also Ethernet will be used to connect the AR to the core network (perhaps crossing other routers). In case
of TD-CDMA infrastructure these functionality will be placed at the RG.
4.2.2.2 Enhanced IPv6 stack/IPSec/DiffServ packet Filter
Enhanced IPv6
Standard IPv6 stack
IPSe
Diffserv
Packet filter
Figure 31: Enhanced Ipv6 Stack
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.
D0103v1.doc 46 / 168

D0103v1.doc Version 1 6.7.2003
The IPSec and Mobile-Ipv6 functionality within the kernel is provided by a software package called
SWAMP. It is accompanied by a userspace library called liburp, which aids in writing a User-
Registration-Protocol handler program.
The major component of SWAMP consists of patches to the Linux kernel version 2.4.16 which provides
IPSec and Mobile-Ipv6 functionality. SWAMP is not an implementation from-scratch. It merely takes
two existing projects for providing support for these technologies in the Linux kernel and integrates them.
It is not possible to apply them independently to the same kernel.
The liburp provides a simplified interface to the IPSec functionalities of the kernel, since the native API
exposed by IPSec (called PFKey) is quite complex and its fully generic behaviour is not needed in
MobyDick.
In addition, the liburp package provides a kernel module, called pep6_kmod, and an API to control this
module from userspace. This module implements simple but powerful packet filtering functions. Using
this, a user-space program (such as the AAA Attendant in MobyDick) can implement access control
based on user authentication.
Since the Mobile -Ipv6 functionality is the same as that provided by the MIPL implementation by HUT, it
is not described here.
4.2.2.3 Fast Handover Module / MIPL
The fast handover module (FHM) is responsible for fast handover procedures in the access router.
QoS manager
AAA
Attendan
t
Fast Handover
module
QoS
attendant
PEP
DSCP
TABLE
Enhanced IPv6 stack
Standard IPv6 stack
Internal interface
IPSec
Diffserv
Packet filter
Kernel space
User space
Figure 32: Fast Handover module and its relationship with other modules
Figure 32 shows the fast handover module and the interfaces between this module and others in the AR
architecture.
Communication between the FHM and the AAAC attendant is for the following purposes:
• The FHM will inform the AAAC attendant when a MT is expected to execute a handover to this
AR, i.e. a Handover Initiate message has been received and the nCoA proposed has been
checked and is correct.
• The FHM will inform the AAAC attendant when a handover procedure has ended with the
result of a MT finishing using the AR services, this will allow the AAAC attendant to finish the
accounting for this MT and sending the pending accounting information to the AAAC server.
Communication between the FHM and the QoS attendant is for the following purpose:
• The FHM will send a message to the QoS attendant in the oAR when a MT is expected to
execute a handover to the nAR. QoS attendant will indicate the PEP to perform a QoS context
transfer using the QoS infrastructure.
• Also the QoS attendant tells the FHO module of the availability or not of QoS resources in the
nAR during the FHO process.
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.
D0103v1.doc 47 / 168

D0103v1.doc Version 1 6.7.2003
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.
Figure 33 shows an detailed overview of the FHO module.
This module will also take care of the context transfer. Some context related parameters from AAAC and
Security must be transferred from the oAR to the nAR to prepare a handover. The following table
presents the parameters included into the context transfer communication.
RCF Fast Handover Module
WCDMA
Connection Manager
Fast Handover
Wcdma
Open /
Execution
Infos
Close
Context
Transfer
Conn
Figure 33: Fast Handover Module
Context Transfer Message Format
Name Type Length
SA tripple doskey 24 Byte
SPI Integer fix 4 Byte
NAI String 50 Bytes maximum
Meter Configuration
Session ID + User_Class 17 Bytes
Table 5: Context Transfer Format
When the IPv6 stack receives fast handover protocol messages (ICMP packets or destination options in IP
packets), it informs the fast handover module of the correspondent situation. The fast handover module
will request the IPv6 stack to send the messages (ICMP packets or destination options to be included in
other packets) needed for fast handover procedures. The procedures that are carried out in the FHM when
the AR is acting as oAR on behalf of a MT that wants to execute a handover to a nAR are described in
figure 34.
D0103v1.doc 48 / 168

D0103v1.doc Version 1 6.7.2003
RtSolPr received
HI_MAX retransmissions
Of HI without reply
Initiate FH
procedures as oAR
-Send HI to nAR
-Initiate timer and
retransmit HI HI_MAX times
Error 1
END
PrRtAdv_MAX retransmissions
of PrRtAdv without reply
Handover
Proceeding
F-HAck received
-Send PrRtAdv to oCoA
-Initiate timer and retransmit
PrRtAdv PrRtAdv_MAX times
F-BU received
Error 2
END
Executing
Handover
Handover
Finished
END
-Send F-BUAck to oCoA
-Start bicasting
-Start timer to stop bicasting
Bicasting timer
expired
-Stop bicasting
-Inform AAA attendant
of finished handover
-Clear information
about handover
Figure 34: FH procedures in oAR
The procedures that are carried out in the FHM when the AR is acting as nAR on behalf of a MT that
wants to execute a handover from an oAR are described in figure 35.
HI
received
Initiate FH
procedures as
nAR
-Check nCoA
-Inform AAA attendant
-Send F-Hack to oAR
END
Figure 35: FH procedures in nAR
4.2.2.4 Paging Attendant
The IP paging attendant function includes the paging related signalling relay block as well as a
mapping function block. Latter one allows mapping between generic IP paging messages to onlink
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 TD-CDMA RG via appropriate sockets or to
an access technology specific paging function (hence the link to the network device driver level).
For authentication of Paging Agent originated messages, the system deploys IPSec mechanisms and
implementations. For handling of paging process related authentication mechanisms on the access link
(AR/RG originated), the IP paging attendant does not deploy IPSec, since no security association has
been established between a paging area’s ARs and the paged mobile terminal. Rather the paging
proprietary authentication fields are to be deployed in the paging message handler of the IP paging
D0103v1.doc 49 / 168

D0103v1.doc Version 1 6.7.2003
attendant. The respective PBKs are to be extracted from the generic IP paging request message originated
from the Paging Agent.
The remote signalling peers (MT, RG and PA) are shown in the figure above and connected to the IP
paging attendant through a dotted line for illustration purposes.
IP Paging attendant
MT
Signaling
relay
PA
RG
Mapping
function
Enhanced IPv6 proto
DiffServ
IPv6
IPSec
Network device drivers
WLAN
Ethernet
Figure 36: Paging Agent
4.2.2.4.1 Paging Attendant 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 4.2.2.4.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. 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.
4.2.2.4.2 Paging Agent 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
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 mechanisms 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
sent from the PA to the respective ARs. This key is to be processed and mapped to the proprietary
D0103v1.doc 50 / 168

D0103v1.doc Version 1 6.7.2003
authentication scheme 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.
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. In case of having TD-CDMA as access technology, the mapping function is
responsible for building of paging signalling messages and interaction with the Radio Gateway through
the signalling socket.
4.2.2.4.3 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 implies 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 will be processed and it’s checked, whether or not the actual addressed node has
registered with the PA. 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. 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 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.
4.2.2.4.4 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 of getting related L2 support from access technologies while being dormant. 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.
4.2.2.4.5 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 to be distributed to the ARs individually. 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. Later, this list could be maintained by an external
paging server.
4.2.2.5 QoS Manager
The QoS manager is responsible for QoS activities in the AR. Figure 37 shows the QoS Manager and its
relationship with other components.
D0103v1.doc 51 / 168

D0103v1.doc Version 1 6.7.2003
QoS broker
QoS manager
FastHandover
module
QoS
Attendant
PEP
DSCP table
Enhanced IPv6 stack
Standard IPv6 stack
Local Log
Management
Local
Log
IPSec
Diffserv
logic
Internalinterface
Protocol communication
Kernel space
User space
Figure 37: QoSManager and its relationship with other modules
4.2.2.5.1 Communication with other AR elements and within the modules of the QoS Manager
Communication between the QoS Attendant and the FHM is for the following purposes:
• See corresponding paragraph in Fast Handover Module / MIPL section
Communication between the PEP and the DiffServ logic is for the following purposes:
• Once the PEP has queried the BB how to configure the DiffServ Logic, PEP will configure
queues in the DiffServ logic.
• Periodically, the PEP queries the DiffServ Logic about its queues’ state.
• When a new entry is added in the DSCP table, the PEP creates a filter in the DiffServ logic so
that the packets whose parameters match this entry are no longer blocked but given the
appropriated
• When a entry is removed in the DSCP table, the PEP removes the above mentioned filter in the
DiffServ logic.
• When a packet is blocked the DiffServ logic, communicates packet’s parameters to the PEP so
that it can initiate an authorization procedure (i.e. queering the BB).
Communication between the internal elements of the QoS Manager
Three elements constitute the QoS Manager, the PEP module, the QoS Attendant Module and the DSCP
table. PEP communicates with both QoS Attendant and DSCP table. No communication exists between
DSCP table and the QoS Attendant.
Communication between the PEP and the DSCP table is for the following purposes.
• Periodically the PEP checks the table for flows (CoA+DSCP) whose authorization live time is
about to expire. In that case, the PEP queries the BB for a reauthorisation.
• DSCP table contains the QoS treatment to apply to flows and, knowing this, the PEP can
configure accordingly the DiffServ Logic.
Communication between the PEP and the QoSAttendant is for the following purposes.
• The QoSAttendant tells the PEP to:
o ask the QoSBroker for a context transfer (in the oAR)
o start listening for the Context transfer message coming form the QoSBroker (in the
nAR)
• When the PEP in the nAR receives this context transfer it tells the QoSAttendant if there are or
not enough available QoS resources.
D0103v1.doc 52 / 168

D0103v1.doc Version 1 6.7.2003
In addition to the abovementioned communications, PEP has an Integrated Logger which generates
Availability and Service Authorization Event Logs, and sends them to the Local Log Management. The
Availability Event Logs are generated periodically. Each time PEP is going to send a ‘Resource allocation
Request’ message asking authorization for an active traffic not installed at this time, the router is forced to
log this event for later auditing. After the response is received and the report state message sent, this event
must also be logged. The Integrated Logger functionalities are provided by the API
‘SessionSetupLogger’.
4.2.2.5.2 Procedures in the QoS Manager
Procedure when a packet not matching any filter arrives
unknown (CoA,DSCP)
Request Authorization
to the BB
-Send Autho. REQ to BB
Process
BB response
DEC from the BB received
DEC is negative
Unauthorized
Flow
END
Configure
DiffServ
logic
DEC is positive
-Install new filter using
The apropiate API functions
Update
DSCP table
-Add entry with the
(CoA,DSCP) and TTL
END
Figure 38: Procedure in QoS manager
Procedure when a FHO is initiated in the oAR
FHI received
Initiate FH
procedures as oAR
-Send the nAR, oCoA, nCoA to BB
END
Figure 39: FHO Initiation Procedure
Procedure when a FHO occurs (QoS context transfer) in nAR
D0103v1.doc 53 / 168

D0103v1.doc Version 1 6.7.2003
DEC received
Update QoS context
-Update DSCP tabe
-configure filters in DiffServ
logic
END
Procedure when the QoS Manager is (re)configured
Figure 40: FHO Context Transfer Procedure
Inicite (re)configuration
Delete old
configuration
Query BB for new
Configuration
-Send conf. REQ to BB
DEC received
Configure
DiffServ
logic
-Install new queues using
The apropiate API functions
Send Report
To BB
END
Procedure at start up of the QoS Manager
Figure 41: FHO Reconfiguration Procedure
D0103v1.doc 54 / 168

D0103v1.doc Version 1 6.7.2003
AR startup
Open COPS
connection
- Send CO message and
Receive CA message
Configuration
procedure
END
Figure 42: QoS Manager start-up
4.2.2.5.3 Internal Interface spec
Three elements constitute the QoS Manager, the PEP module, the QoS Attendant Module and the DSCP
table. PEP communicates with both QoS Attendant and DSCP table. No communication exists between
DSCP table and the QoS Attendant.
DSCP table is accessed only by the PEP and indeed it is just a variable in the PEP code. This variable is
an array, each element of the array being an authorized (DSCP, CoA) pair and its TTL.
QoSAttendant is part of the code of the PEP. It checks if a message comes from the FHO module and if
so, the PEP is awaken and start to process the received message.
4.2.2.5.4 State Machine
No.
Signal
0 Start
1 CA received
2 DEC(conf) received
3 Always
4 Signal from FHO module FAST_HANDOVER_INI
5 Always (or DEC from QoSB)
6 Signal from FHO module: START_QOSB_LISTEN
6b Unsolicited DEC(Context Transfer) message received
7 KA timer expires
8 KA received
9 Accounting timer expires
10 Always
11 Time out to check for new packets and packet with new (CoA,DSCP,DestAddress) found
12 Positive DEC(AF) received
13 Always
14 Negative DEC(AF) received
15 DEC(AF) with reconf. Flag set received
16 End
Table 6: State Machine
4.2.2.6 AAAC Attendant
The AAAC attendant acts as AAAC client and is responsible for communication between 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.
The Attendant comprises a module of software that implements the AAAC signalling and a set of routing
policies; some of these policies are set up as a consequence of the AAAC signalling.
D0103v1.doc 55 / 168

D0103v1.doc Version 1 6.7.2003
Registration
protocoll
handler
ATTENDANT
AAAC protocol
handler
AAAC
Server
Mapper, Mediator, Event gen.
AAAC client
Attendant
log
Session
Status
Trigger,
remove
S.A.
Configure,
Meter data
Security
Manager
Metering
Figure 43: AAAC Attendant
User-space application residing on the AR
The Attendant communicates with the MN and AAAC. F. The Attendant uses:
- UDP for communication with the MN
- TCP for communication with the AAAC.f
Main function:
- allowing / denying a MN the access to the Net
- metering / accounting
Behaviour:
There are two main external events that trigger some actions from this entity i.e. receiving an MNARq on
the AAAC-signalling-interface and Upon receiving an ARA.f
At receiving a MNARq at its AAAC-signalling interface from MN, the Attendant will execute the
following actions
Upon receiving an MNARq on the AAAC-signalling-interface:
• the Attendant generates an DH key /FORWHOM /
• generates an ARR.f message; generates the following AVPS:
• Session-Id, Origin-Host, Origin-Realm, Destination-Realm (by taking the realm part of the
NAI sent by the MN)
• Att-DH-PV (keying material for setting up an SA btw. the MN and the Att.
• constructs an ARR.f to be relayed/proxied thru one of the AAAC servers (relay/proxy agent)
in its realm
• AAAC.f; keeps some info related to this message (the interface on which the MNARq was
received, the MN CoA, MN-DH-PV) into the list of pending requests (LPR)
Upon receiving an ARA.f from the AAAC.f :
• check the AAAC Result-Code
• sets up the SA with the MN using MN-DH-PV
• constructs an MNARp and sends it to the MN using the info related to this MN (i.e.
interface, CoA and so on.)
• sets up the policy related to IP routing for this MN accordingly.
AAAC Client has an Integrated Logger which generates Availability and User Registration Event Logs,
and sends them to the Local Log Management. The Availability Event Logs are generated periodically.
Each time AAAC Client receives a valid MNARq it logs this event for later auditing. After sending the
response MNARp to MN, this event will also be logged.
D0103v1.doc 56 / 168

D0103v1.doc Version 1 6.7.2003
4.2.2.6.1 Metering
The core component of the metering software is the IETF RTFM NeTraMet implementation as
documented in RFC 2063, RFC 2064 and its successor RFCs.
The NeTraMet implementation was enhanced with the following new features:
A Meter was modifies in the sense that dynamically CoAs can be assigned to User_Class_IDs. This user
class Ids will be used to link CoAs with a predefined user group reflecting a certain SLA.
A Meter Manager and Meter reader was modified in the sense that the flow data is stored into a mySQL
database. The communication between the Meter Reader and the database is done via ODBC.
Figure 44 depicts the components of the meter block located at the Access Router. NeTraMet meters the
data according the above mentioned RFCs. NeMaCDB reads the data from the meter, opens at each
reading cycle the database and stores the raw data into this database. All this modules are installed at the
same machine. The interval between two consecutive meter reading cycles is expected to be in the rage 1
s – 5 s.
NeTraMet
SNMP
NeMaCDB
SNMP
ODBC
Metering
Attendant
Accounting
Interface
AAA Attendant
Figure 44: Metering Module Architecture
The metering attendant can read out the data from the Accounting database on request coming from the
AAAC Attendant. It is expected that data of the accounting database is red out in permanent intervals
(about 3 minutes). The data red out will be deleted at the accounting database in order to keep the size of
this database small and the whole system scalable. This reading intervals will be triggered by the AAAC
Attendant via a C API which is described in the following:
AAAC client can get accounting data through a function call (Get_Meter_Data). Additionally, the C Lib
can also give AAAC client two functions as required in [1]: Meter_Start() and Meter_Stop().
struct st_accdata
{
char *date;
char *time;
char *sourcepeeraddress;
char *destpeeraddress;
unsigned int inputOctets; //fromoctets
unsigned int outputOctets; //tooctets
unsigned int inputPackets; //frompdus
unsigned int outputPackets; //fromoctets
unsigned int destPort;
unsigned int dscp;
struct st_acctdata *next
}
Figure 45: Meter Attendant API – data format
D0103v1.doc 57 / 168

D0103v1.doc Version 1 6.7.2003
Parameters of the Meter_Start message are Session_ID and CoA. Parameters of the get_Meter are the
Session_ID. The Meter_Stop parameter is the Session_ID only.
The Session_ID will be created and maintained by the AAAC Attendant. This session_ID will be
combined with a CoA after Meter_Start is called. AAAC client can use it to get Accounting data from
meter and inform meter to stop counting for this CoA.
Get_Meter_Data return a pointer to the structure. The accounting data are stored in this structure list. The
list end with a null point in next.
4.2.2.6.2 Logger
Figure 46 depicts the logging framework. It is required that the impact caused by the Integrated Loggers
to the main tasks performed by the hosting entity should be reduced to minimum. Therefore Integrated
Loggers are required to be non-blocking and must log as fast as possible. The logs will be stored locally
before being transferred to the Auditing Framework by the Local Log Management.
Access Router
AAAC Client
Integrated
Logger
QoS Manager
Integrated
Logger
Local
Log
Local
Log Mgmt
Auditing
Framework
Figure 46: Logger
QoS Manager’s Integrated Logger does not know NAI but CoA. In order to allow for logging NAI in
Service Authorization Events, the mapping from CoA to NAI must be made available to the QoS
Manager’s Integrated Logger. AAAC Client’s Integrated Logger knows this mapping, therefore both
Integrated Loggers need to communicate.
4.2.2.6.3 Local Log
The Local Log is implemented as a MySQL database consisting of three tables: SoL, UsrReg, and
SvcAuth. The table SoL is used to store Availability Event Logs. The table UsrReg is used to store User
Registration Event Logs, and the table SvcAuth is used to store Service Authorization Event Logs.
The data structure of each of the tables are shown below.
Field Type Null allowed? Default
LoggerID varchar(255) NO “”
LogTime Datetime NO 0000-00-00 00:00:00
EventID tinyint(3) unsigned NO 0
EventID is 1.
Table 7: SoL data structure
LoggerID is the unique identity of QoSManager (e.g., “:QoSManager”) or AAAC
Client (e.g., “:AAACClient”).
Field Type Null allowed? Default
LoggerID varchar(255) NO “”
LogTime Datetime NO 0000-00-00 00:00:00
D0103v1.doc 58 / 168

D0103v1.doc Version 1 6.7.2003
EventID tinyint(3) unsigned NO 0
NAI varchar(255) NO “”
CoA varchar(255) NO “”
ResultCode int(10) unsigned YES NULL
Table 8: UsrReg data structure
EventID is 11 for the registration request event from the MN and 12 for the registration response to the
MN.
NAI is the user identifier.
CoA: Care-of Address in hexadecimal text format.
ResultCode: result code from the AAAC Server if EventID is 12, 0 if EventID is 11.
Field Type Null allowed? Default
LoggerID varchar(255) NO “”
LogTime Datetime NO 0000-00-00 00:00:00
EventID tinyint(3) unsigned NO 0
NAI varchar(255) NO “”
CoA varchar(255) NO “”
DestAddr varchar(255) YES NULL
DSCP tinyint(3) unsigned NO 0
ResultCode int(10) unsigned YES NULL
Table 9: SvcAuth data structure
EventID is 21 for the authorization request event to the QoSBroker and 22 for the authorization response
from the QoSBroker.
CoA: captured and requested traffic source address (Care-of Address) in hexadecimal text format.
DestAddr: captured and requested traffic destination address in hexadecimal text format.
DSCP: captured and requested traffic DSCP in decimal format.
ResultCode: QoSBroker Authorization code: ‘1’=admit/install, ‘2’=reject/block, 0 if EventID is 21.
4.2.2.6.4 Interface between Integrated Loggers for CoA-NAI Mapping
The purpose of this communication is to allow the Integrated Logger of QoS Manager to map a CoA to
NAI. The message exchange between the Integrated Logger of QoS Manager (ILQoSM) and the
Integrated Logger of AAAC Client (ILAAACCl) is simple and defined as follows:
ILQoSM à ILAAACCl : GetMap(CoA)
ILAAACCl à ILQoSM : Map(NAI, CoA)
The format of the message GetMap and Map is shown in the following figure. The Type of the TLV for
CoA is 1 and NAI is 2.
D0103v1.doc 59 / 168

D0103v1.doc Version 1 6.7.2003
0 GetMa 31 0 Map 31 0 TLV 31
Message Type p = 1 Message Type = 2
Type
Length of CoA
CoA
TLV
TLV
Length
Value
4.2.2.7 DSCP Marking Software
4.2.2.7.1 Motivations
Figure 47. Message format for CoA to NAI mapping
Initially, the marking process was expected to work only in the Mobile Terminal. However, a few
network entities (Home Agent for ex.) may generate signalling packets that must be marked. In fact, with
Ethernet and WLAN technologies, these packets do not cause any problem, even if they are marked with
a default DSCP set to ‘0’. With TD-CDMA, these packets may be dropped. To cross the interface, all the
packets are associated with a specific radio bearer, according to their DSCP. In Moby Dick, a DSCP set to
‘0’ is not recognized (see Table 10), and signalling and data packets use separate radio bearers associated
with different DSCPs. So, the signalling packets must be marked just before sending them on a TD-
CDMA interface, i.e. in the Access Router.
Service Relative
Typical Usage
Name Class Priority
Service parameters
Description
DSCP
SIG AF41 2 Unspecified Signalling (network usage) 0x22
S1 EF 1 Peak BW: 32 kbit/s Real time services 0x2e
S2 AF21 3 CIR: 256 kbit/s
Priority (urgent)
data transfer
0x12
Three drop precedences (kbps): Olympic service
S3 AF1* 4
AF11 – 64
AF12 – 128
(better then
BE:streaming, ftp,
0x0a
0x0c
AF13 – 256
etc) 0x0e
S4 BE 0 Peak bit rate: 32 kbit/s Best Effort (BE) 0x00
S5 BE 0 Peak bit rate: 64 kbit/s Best effort 0x02
S6 BE 0 Peak bit rate: 256 kbit/s Best effort 0x04
Table 10: Classes of Service and associated DSCP codes
D0103v1.doc 60 / 168

D0103v1.doc Version 1 6.7.2003
4.2.2.7.2 DMS location
Application 1 Application 2
Application level module
DSCP
matching
table
Fast Handover
module
Enhanced IPv6 stack
Standard IPv6 stack
MIPL
DSCP marking software
Network devicedrivers
TDCDMA WLAN Ethernet
Figure 48: Location of the DSCP marking software in the IP stack
The previous figure shows where the DMS will be located in the protocol stack. It « intercepts » packets
just before transmitting them to the lower layer. Thus, all the packets generated by both the IP stack and
the upper layers can be filtered and marked.
4.2.2.7.3 DMS Architecture
The DMS contains five components, as in figure 49:
• a DSCP Matching Table (DMT): this table contains the definition of every filter and the DSCP
associated with it in the Linux kernel space,
• a DSCP Marking Function (DMF): this is the DMS engine, which consults the fields in the different
headers of each packet, compares it with the filters in the DMT, and decides to mark or not the
packet with a new DSCP; it is located in the Linux kernel (in the IPv6 code),
• a Filters Database (FD): this file (or set of files) contains the definitions of all the filters, in the user
space,
• a Table Update Module (TUM): this is a Linux module in charge of updating the DSCP Matching
Table with the data stored in the Filters Database,
• a Service Table (ST): this table, only used by the TUM, associates a DSCP with each service.
4.2.2.7.4 DSCP Matching
The packet marking process is based on the search of a table containing all the filters definitions
whenever a packet is ready to be transmitted. In this section, we describe how these filters are introduced
by a user, and how the DMT is built and updated.
D0103v1.doc 61 / 168

D0103v1.doc Version 1 6.7.2003
Kernel Space
User Space
DSCP Marking
Function (IPv6)
Table update
Module
Service
Table
DSCP
Matching
Table
Filters
Db
Rules1.txt
Rules2.txt
Rules3.txt
Figure 49: DMS Components
Packet filtering
The description of a filter is as follows:
Filter
10
Description FTPFilter
TCPDestPort 21
IP6SrcAddr FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
CoS
S1
Table 11: Packet Filter
The complete descriptions of the filters are stored in one or several files (the FD). Each file is loaded in
the DMT with help of the TUM. Then, when a packet is ready to be delivered to the lower layer, the DMF
consults the DMT, and marks the packet with the DSCP associated with the first filter that matches with
the information of its header(s).
A filter contains:
• An identifier (the ‘Description’ field), which also represents its priority. Thus, if two filters
match, only the first one, i.e. the one with the lowest identifier, is considered.
• A description, i.e. a filter name.
• A CoS: the value of this field can be either a service identifier (S1, S2, …) or a DSCP. If this
value is a service identifier, then the DSCP associated with the filter will be found by the TUM
in the ST.
• A list of items, with their values. The number of items is not limited, and a list of items can be
empty (then, all the packets are marked with the DSCP associated with the filter). Packets are
marked with the DSCP associated with the filter only if all the items values are equal to the
corresponding fields values in the different headers of the packet. On the previous example, a
packet will be marked with the ‘101110’ DSCP (which is associated with the S1 service in the
ST) only if, in the packet headers, the TCP Destination Port is set to ‘21’ and the IPv6 Source
Address is set to ‘FEDC:…:3210’. If only one value doesn’t match, then the filter also doesn’t
match.
Typically, each description can use all the possible fields of the different headers added by the network
and the transport layers. This software supports a large subset of these fields, in the following headers:
IPv6 main header, TCP, UDP, Destination option (including the Binding Update, Binding
Acknowledgment, Binding Request, and Home Address options), Routing option, Hop-by-hop option,
Authentication option, Encapsulating Security Payload (ESP) option, Fragment option, IPv6 (tunnelling),
and ICMPv6.
The goal of this software is simple: the filtering rules will not be directly written in the. In fact, the
software offers the possibility to filter packets using a more or less complete subset of the different header
fields. Only the user, and/or the network administrator, thanks to their good knowledge of the network
protocols, is able to define precisely these rules. Thus, the code of the software is the same in all the
different entities of the network using it, and in all the different QoS domains. Only the contents of the
filters can change from an entity to another, or from a QoS domain to another. The different filtering rules
supported by the DMS are listed in Table 10.
DSCP Matching Table
When a user, or a network administrator, triggers a modification of the filters descriptions, the TUM
modifies the DMT automatically. In this section, we describe how this table is organized.
D0103v1.doc 62 / 168

D0103v1.doc Version 1 6.7.2003
Filter number
(= line number)
0
1
2
3
4
…
N
Filter Pointer
Filter0Ptr
NULL
Filter2Ptr
Filter3Ptr
NULL
…
FilterNPtr
Table 12: Format of the DMT
Each line of the table only contains a pointer to a complete description of a filter loaded in the memory
(see Table 3).
Each filter is a simple structure containing a description, the DSCP (CoS) used to mark each packet that
matches this filter, a set of bits identifying the different headers to examine, and a pointer to a list of items
representing the different fields of the packet header that are to be inspected (see figure 26). Thus, the
number of fields in a filter is variable. The bits identifying the different headers to examine accelerate the
filtering process. Indeed, if a filter contains items related to TCP fields, and if the packet does not contain
a TCP header, the filter doesn’t match, and browsing its items list and the header fields’ values becomes
useless. The use of these bits avoids useless treatments in the DMF.
Every item of this list contains an identification of the field to inspect, i.e. a value identifying the name of
the field in the kernel (IP6_SRC_ADDR is equivalent to the IP6SrcAddr field in the FD,
TCP_SRC_PORT is equivalent to the TCPSrcPort field, etc.), the expected value of this field, and a
pointer to the next item.
It is possible that the information extracted from the packet header matches with several filters. Only the
first filter is taken into account. Thus, the number of the filter, which is the range of the filter in the table,
represents its priority. The lower is this number, the greater is the priority of the filter. So, it is important
to sort the filters from the more detailed to the less detailed.
Desc.: ANiceFilter
Headers:IP6, TCP
CoS: 101101
Items list: item1
Ident.: IP6_SRC_ADDR
Value: FEC0::1
Next: item2
Ident.: IP6_DSCP
Value: 010110
Next: item3
Ident.: TCP_SRC_PORT
Value: 21
Next: NULL
Figure 50: Representation of a filter in the Linux kernel
Table updates
The TUM modifies the DMT each time the user, or the network administrator, modifies the FD and
communicates it to the module (figure 27). The modified FD – which is a single text file – is forwarded to
the module over a simple Linux character device (/dev/dscp). This solution is the simplest way to
communicate information from the user space (here, the FD) to the kernel space where the DMT is
located.
Thus, the user only has to write on this device with the contents of the FD (by the ‘cat filters_database.txt
> /dev/dscp’ command for ex.). Then, the TUM automatically reads the text written on the device, and
updates the DMT in the Linux kernel. Note that it is not necessary to write the entire FD on the device to
update properly the DMT: only a file containing new filters, or a subset of modified filters can be
communicated to the TUM.
D0103v1.doc 63 / 168

D0103v1.doc Version 1 6.7.2003
User
AAAC
Table update
Module
3b
Filtering Rules & DSCP
1 2 3a
Service
Table
Character device
/dev/ dscp
1: Filters writing
2: Filters reading
DSCP
Matching
Table
3a: DSCP update
3b: Filters update
Figure 51: DMT and SC update process
For the moment, the table update process is triggered manually, by writing on the /dev/dscp character
device. However, it is possible to make the AAAC system update the FD, in the same way than the DSCP
update (see section 4.1.2.9.8) or triggering automatic updates regularly, in the user space.
4.2.2.7.5 DSCP marking
DSCP marking is done thanks to a modification of the Traffic Class and Flow Label fields in the IPv6
header. When the information of the packet header matches with a filter, the corresponding DSCP is
marked in the header of the packet: the four first bits of the DSCP are stored in the last four bits of the
Traffic Class field, and the last two bits, plus two bits set to ‘0’, are stored in the four first bits of the Flow
Label field.
DSCP
Vers
TC
…..
Flow Label
Figure 52: DSCP bits in the IPv6 main header
4.2.2.7.6 Packet re-marking
This operation is supported by the DMT, if the DMS is installed in a Linux router. To re-mark packets,
the network administrator has just to add a new filter, containing a ‘IP6DSCP’ item, in the FD. This filter
evaluates the DSCP in the new packet header, and associates a new value with it.
4.2.3 Software implementation / interfaces
4.2.3.1 Interface between QoSManager and Fast Handover module
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 conveying QoS related information to the
domains QoS brokers. This requires an appropriate local interface between the Fast-HO module and the
QoS attendant function, which are both implemented on Access Routers.
D0103v1.doc 64 / 168

D0103v1.doc Version 1 6.7.2003
4.2.3.1.1 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.
We use for that a character device. The following sections describe the interface.
4.2.3.1.2 Interface contents
Source Dest Primitive Parameters
Fast-HO
in oAR
QoSattend
in oAR
START_QOS_FHO
oCoA, nAR address, nCoA.
Fast-HO
in nAR
QoSattend
in nAR
START_QOSB_LISTEN
none
QoSattend
in nAR
Fast-HO in
nAR
QOS_FHO_ACK
Result info: QOS_AVAILABLE
or
QOS_NOT_AVAILABLE
Table 13: Interface Contents
4.2.3.1.3 Format of the messages
/* Message definition(s) */
struct qos_fho_msg_t
{
int type;
union
{
start_qos_fho_msg_t start_qos_fho;
start_qosb_listen_msg_t start_qosb_listen;
qos_fho_ack_msg_t qos_fho_ack;
} msg;
};
typedef struct qos_fho_msg_t qos_fho_msg_t;
/* FHO module -> QOS-attendant on the oAR: handover initiate info message to QoS */
struct start_qos_fho_msg_t
{
struct in6_addr old_coa;
struct in6_addr new_coa;
struct in6_addr new_ar;
};
typedef struct start_qos_fho_msg_t start_qos_fho_msg_t;
/* FHO module --> QoS attendant on the oAR: trigger the QoS attendant to listen for QoS message */
struct start_qosb_listen_msg_t
{
};
typedef struct start_qosb_listen_msg_t start_qosb_listen_msg_t;
/* QoS attendant --> FHO module on the nAR: allow or deny handover via acknowledgement */
struct qos_fho_ack_msg_t
{
int qos_ack;
};
typedef struct qos_fho_ack_msg_t qos_fho_ack_msg_t;
D0103v1.doc 65 / 168

D0103v1.doc Version 1 6.7.2003
4.2.3.2 Interface between QoSManager and DiffServ Logic
PEP communicates with DiffServ Logic using an API: The IBM TC API. This section describes shortly
the main functions of the API.
• First is the call of the API function QSession() which creates a netlink socket to communicate
between the kernel space (where DiffServ Logic runs) and the user space (where PEP code
runs).
• To configure queues in the DiffServ Logic a two step process is followed. We first call the API
function AddQDiscCBQ() is first called to reserve and configure some resources of a router
interface for later creating the queues in those reserved resources. Then, for each queue we want
to create in the mentioned interface, we call AddTClassCBQ(). If we want to create queues other
than CBQ we may also call AddQDiscName() and AddTClassName().
• To create filters to route packets to any of the queues created in the preceding step, we have to
call two API functions. First we create a set of conditions the packet must meet using the
function AddCondition() as many times as needed. Then, we aggregate these conditions and
create the filter using AddFilterU32Filter(), this functions allow us to specify to which queue the
packets meeting the above created conditions will be routed.
DiffServ Logic has also to tell the PEP when a packet that does not match any filter rules arrives, so that
the PEP initiates the Authorization Process. But TC does not allow that. So we use pcap. Pcap captures all
the packets and stores in a shared memory variable packets parameters (CoA and DSCP). PEP checks this
shared memory variable and looks if any (CoA, DSCP) pair is not in his DSCP table. In that case it begins
the authorization process begins.
A wrapper around IBM’s TC API has been designed. Its more relevant functions are:
Create_session(interface)
Create_initial_qdiscs()
create_CBQ_class(BW, borrow_bw)
create_GRED_VQ(queue capacity (min, max) discard probabilty)
create_default_filter(class to send packets matching none of the filters)
add_filter6(CoA, DSCP, class to send packets matching this filter)
tell_stats(interface_status)
4.2.3.2.1 Flow sequence between PEP and DiffServ Logic
No. Function call Remarks
1 Create_session
To initiate DiffServ Logic
2 Create_initial_qdiscs
3 create_CBQ_class As many times as needed
4 create_CBQ_class
As many times as needed
5 create_GRED_VQ
6 create_CBQ_class
CBQ can be created and deleted as
needed
7 delete_CBQ_class
create_default_filter
8 add_filter6 As many times as needed
9 add_filter6
10 remove_filter6
11 Stats As many times as needed
Table 14: Flow Sequence between PEP and DiffServ logic
Filters can be created and deleted as
needed
4.2.3.3 Interface between the QoSManager and the Integrated Logger
Each time the Access Router is going to send a ‘Resource allocation Request’ message asking
authorization for an active traffic not installed at this time, the router is forced to log this event for later
auditing. After the response is received and the report state message sent, this event must also be logged.
The Integrated Logger functionalities are provided by the API ‘SessionSetupLogger’.
The interface provided by the Integrated Logger is simple and consists of three functions and a structure.
The functions are:
D0103v1.doc 66 / 168

D0103v1.doc Version 1 6.7.2003
• void createQoSMgrLogger(char *loggerName);
This function replaces the deprecated function void *createLogger(char *loggerName).
Call this function once at the initialization of the QoSManager. The parameter loggerName contains
the identity of the logger. If this parameter is NULL, then the concatenated hostname and
“:qosmanager” will be used as the LoggerID by the Integrated Logger.
• int logAuth(svcAuthStruct *log); // return 0 if successful
This function replaces the deprecated function int logSvcAuthorization(void *logger, svcAuthStruct
*log).
Call this function for each session setup request and session setup response. The function returns 0 if
no error occurs, otherwise it returns a negative number (Logger not initialized (-1), Parameter is
NULL (-2), Error while logging (-3)).
• void destroyQoSMgrLogger();
This function replaces the deprecated function void destroyLogger(void **logger).
Call this function at the end of execution of the QoSManager.
The structure is the svcAuthStruct structure defined as:
typedef struct _svcAuthStruct {
unsigned char eventId;
char *NAI;
char *CoA;
char *destAddr;
unsigned char dscp;
unsigned int resultCode;
} svcAuthStruct;
It is used in the logAuth() function.
4.2.3.4 Interface between the IPv6 enhanced stack and the Fast Handover module
The Messages exchanged between the fast handover module (FHM) and the IPv6 enhanced stack (Ipv6)
are the following:
• IPv6 -> FHM: ROUTER_SOLICITATION_FOR_PROXY_RECEIVED, parameters:
_nARaddr (IP address of the new AR if available or perhaps other kind of identifier), _HoA,
_oCoA (the CoA the MT is using), _nCoA (the CoA the MT is going to use with the nAR).
• FHM -> IPv6: SEND_HANDOVER_INITIATE, parameters: _nARaddr, _nCoA,
SubSubProfile, key
• IPv6 -> FHM: HANDOVER_INITIATE_RECEIVED, parameters: _oARaddr (IP address
of the AR that sent the HI), _nCoA, SubSubProfile, key
• IPv6 -> FHM: SEND_HANDOVER_ACK, parameters: _oARaddr
• FHM -> IPv6: HANDOVER_ACK_RECEIVED, parameters: _nARaddr
• FHM -> IPv6: SEND_PROXY_ROUTER_ADVERTISEMENT, parameters: _oCoA
• IPv6 -> FHM: FAST_BINDING_UPDATE_RECEIVED, parameters: _oCoA
• FHM -> IPv6: SEND_FAST_HANDOVER_ACK, parameters: _oCoA, _nCoA
• IPv6 -> FHM: FAST_NEIGHBOUR_ADVERTISEMENT_RECEIVED, parameters:
_nCoA
4.2.3.5 Interface between the IPv6 enhanced stack and the IP paging attendant
The messages exchanged between the IP paging attendant (IP_PA) and the IPv6 enhanced stack (Ipv6)
are the following:
• IPv6 -> IP_PA: DORMANT_MODE_REQUEST_RECEIVED, parameters: _HoA, _MAC
address list (n * 3byte) or _L3-ID, _Paging area ID, _Sequence #, _reg. Lifetime, _NAI,
_credentials
D0103v1.doc 67 / 168

D0103v1.doc Version 1 6.7.2003
• IP_PA -> IPv6: SEND_DORMANT_MODE_REQUEST, parameters: _PAaddr (IP address
of the paging agent), _HoA, _MAC address list (n * 3byte) or _L3-ID, _Paging area ID,
_Sequence #, _reg. Lifetime, _NAI, _credentials
• IPv6 -> IP_PA: PAGING_REQUEST, parameters: _RAN (random number), _SessKey
(session key), _MAC address list , L3-ID (MTSolicitedNodeAddr????)
• IP_PA -> IPv6: ON-LINK_PAGING_REQUEST, parameters:
_MTSolicitedNodeAddrInterface between AAAC Attendant and IpSec
4.2.3.6 Interface between AAAC Attendant and IPSec
4.2.3.6.1 IPSec Functions
SWAMP gets its IPSec functionality from two projects: the FreeS/WAN project
(http://www.freeswan.org) implements IPSec for Ipv4 on the Linux platform. IABG has patched
FreeS/WAN to provide Ipv6 support.
Since the IPSec protocol , and its API, PFKEY has been extensively described in the relevant standards,
this document focuses on the interface provided by liburp for the purposes of liburp. This interface is used
by the AAA Attendant on the AR.
The liburp library provides a simplified interface to the kernel IPSec interface. It allows programs to set
up 'connections', described by a 'struct ipsec_conn'. A connection is an IPSec tunnel between a mobile
node and an access router. It is assumed that all the traffic of a mobile node will be routed to a single
access router, through a single connection. Each router, of course, may have multiple connections, one for
each attached mobile node.
Each connection contains a bundle of Security Associations (SA's). A program may set up a connection
with only AH tunnel, only ESP tunnel, or both AH and ESP tunnel protection.
Before one can use the IPSec functionality, one must call IPSecMgr::init(). Likewise, when done, the
program should call IPSecMgr::exit(). This will destroy any IPSec connections that are still around.
To set up a connection, a program creates and fills up a 'struct ipsec_conn' variable:
truct ipsec_conn {
bool is_mn; /* Is the node an MN? AR? */
in6_addr *local_addr6;
uint32_t local_maskbits;
in6_addr *remote_addr6;
uint32_t remote_maskbits;
uint8_t *ah_key;
uint32_t ah_spi_in;
uint32_t ah_spi_out;
uint8_t *esp_key;
uint32_t esp_spi_in;
uint32_t esp_spi_out;
/* tunnel SA SPI's */
uint32_t ipip_in_spi;
uint32_t ipip_out_spi;
};
On the mobile node, 'is_mn' is set to true, and on the access router, it is set to false. The 'local_addr6' and
'remote_addr6' members are self_explanatory. The '*_maskbits' is set to 128 for now. In future they may
be used to protect network segments instead all traffic.
'ah_key' and 'esp_key' are the keys for AH and ESP protection, respectively. The liburp uses HMAC-
MD5-96 algorithm for AH, and 3DES-CBC for ESP. Thus, they ah_key must always be 16 bytes in
length, and the esp_key must always be 24 bytes in length (the canonical key lengths for these
algorithms). The liburp does not attempt to pad or truncate the keys you supply, and improper lengths
may be fatal.
If neither AH nor ESP is used, then the corresponding key is set to 0 (NULL pointer). This is the only
exception to the restriction on key length described above.
The '*_spi_in' and '*_spi_out' members are the SPI's of incoming and outgoing SA's, respectively. They
must be anti-symmetric on the mobile node and access router. That is, if the ah_spi_in on the mobile node
is 101, then (for the same ipsec connection) the ah_spi_out on the access router must also be 101, and
vice-versa.
If you are not using AH, then you can leave the ah_spi_* members unset: they will not be used. However,
you must always set the esp_spi_* members correctly. This restriction is imposed by the design of the
FreeS/WAN IPSec implementation.
The ipip_*_spi members must also be set, but they need not be anti-symmetric or even same on the
mobile node and access router: they should just be unique within and between ipsec connections.
D0103v1.doc 68 / 168

D0103v1.doc Version 1 6.7.2003
The above means that you will use up four SPI's for an ESP only connection (two for incoming and
outgoing ESP SA's, two for incoming and outgoing IPIP SA's) and six SPI's for an AH or Ah+ESP
connection (additionally two SPI's for incoming and outgoing AH SA's).
Once you have set up the ipsec_conn structure properly, you can create a connection by calling
IPSecMgr::add_conn(). Since liburp will make copies of any data it needs, you can reuse the same
structure variable again and again (after changing the required members, of course). This also implies that
you are responsible for managing the memory (keys, etc.) used by your variable.
The IPsecMgr::add_conn() method returns a 'connection-id': a non-negative integer identifying the
connection. This id can be used to call IPSecMgr::del_conn(), to destroy the connection. Note: calling
IPSecMgr::exit() also destroys all connections which have not been released by calling
IPSecMgr::del_conn().
4.2.3.6.2 SPI Management
Since one needs to have unique SPI's for each connection, and should then return them to the unused SPI
'pool' for later re -use after destroying a connection (lest you run out of SPI's), liburp provides a SPI
management interface.
You can ask for unique SPI's by calling PFKey::get_spi() as many times as required: it will ensure that
you only get unique PI's, and will return 0 if no SPI is available.
Once you have done with an SPI, free it by calling PFKey::free_spi(). PFKey will then re-use it if
necessary.
Note: IPSecMgr::del_conn() does not automatically free the SPI's used by a connection: you must still
call PFKey::free_spi().
Note that the SPI management routines can only ensure that SPI's are unique within a single process.
There is no mechanism to ensure SPI uniqueness system-wide. Thus, if there is another program using the
PF_KEY (RFC 2367) interface to use SPI's, then conflict is likely. To be safe, liburp uses the SPI range
0x100 to 0xfff, which is reserved for manual keying. This will ensure that at least liburpallocated SPI's
do not conflict with those used by some key-management daemon like FreeS/WAN's pluto.
4.2.3.6.3 Firewall control
The Access Router has to implement a packet filter that would drop packets sent from unauthenticated
mobile hosts. This is achieved via the pep6_kmod kernel filter. This is a kernel module provided with the
library. You must compile and insert this mo dule into the kernel to use the packet filter functions of
librup. This library provides a simple interface to the kernel filter rules through the class
URPFWMgr. The philosophy of the kernel filter is to not allow Any packets to be forwarded, except
those from or to addresses Specified in a “rule". Each rule is associated with an interface. The wildcard
"any" interface is also allowed, to create global rules.
Call URPFWMgr::init() to initialize the firewall manager. The kernel module must be loaded for this to
success.
Call URPFWMgr::allow6() to allow forwarding for a particular mobile node. 'in_dev' is the name of the
network interface the rule should be associated with ("eth0", "wlan0", etc. for example). Using "any" as
the interface name causes the rule to be associated with all interfaces. 'v6addr' is the source or destination
address of the packets for which forwarding is enabled, and should be the care-of-address of the mobile
node.
URPFWMgr::forbid6() serves to disable the forwarding enabled by calling allow6(). It takes only a single
argument, which is the address the rules should be revoked. All rules containing this address will be
removed.
All these functions return 0 if the operation was successful; otherwise they return an integer less than 0.
4.2.3.6.4 2.2.2.4 API Synopsis
The API is summarized here.
#include
static void Logger::setDefaults(const char *ident,
const bool tid = false, const int facility = DAEMON)
static void Logger::setDebugState(bool state)
static int IPSecMgr::init()
static int IPSecMgr::add_conn(struct ipsec_conn *conn)
static int IPSecMgr::del_conn(int connid)
static int IPSecMgr::exit()
D0103v1.doc 69 / 168

D0103v1.doc Version 1 6.7.2003
static int PFKey::get_spi()
static void PFKey::free_spi(int spi)
static int URPFWMgr::init()
static int URPFWMgr::allow6(const char *in_dev,
struct in6_addr *v6addr)
static int URPFWMgr::forbid6(struct in6_addr *v6addr)
4.2.3.7 Interface between AAAC Attendant and metering
The metering attendant can read out the data from the Accounting database on request coming from the
AAAC Attendant. It is expected that data of the accounting database is red out in permanent intervals
(about 3 minutes). The data red out will be deleted at the accounting database in order to keep the size of
this database small and the whole system scalable. This reading intervals will be triggered by the AAAC
Attendant via a C API which is described in the following:
AAAC client can get accounting data through a function call (Get_Meter_Data). Additionally, the C Lib
can also give AAAC client two functions as required in [1]: Meter_Start() and Meter_Stop().
struct st_accdata
{
char *date;
char *time;
char *sourcepeeraddress;
char *destpeeraddress;
unsigned int inputOctets; //fromoctets
unsigned int outputOctets; //tooctets
unsigned int inputPackets; //frompdus
unsigned int outputPackets; //fromoctets
unsigned int destPort;
unsigned int dscp;
struct st_acctdata *next
}
Figure 53: Meter Attendant API – data format
Parameters of the Meter_Start message are Session_ID and CoA. Para meters of the get_Meter are the
Session_ID. The Meter_Stop parameter is the Session_ID only.
The Session_ID will be created and maintained by the AAAC Attendant. This session_ID will be
combined with a CoA after Meter_Start is called. AAAC client can use it to get Accounting data from
meter and inform meter to stop counting for this CoA.
Get_Meter_Data return a pointer to the structure. The accounting data are stored in this structure list. The
list end with a null point in next.
4.2.3.8 Interface between AAAC attendant and Fast Handover module
4.2.3.8.1 Description
The AAAC attendant module has an interface to the Fast Handover (FHO) module, which is a kernel
space module. These modules interact with each other to transfer the context from the old access router
(oAR) to the new access router (nAR). This is illustrated in the figure below.
On receiving a “Router Solicitation for Proxy” message form the MN, the FHO module at the old access
router requests the AAAC Attendant for the context associated with the MN. The FHOmodule executes
the function “StartCtxTransfer” which contains identification of the message (MesgType) e.g.
StartCtxTransfer, SendctxToAtt or SendctxToFHO and the length of this message
In case of an intra-domain fast handover, which is the only kind of FAST Handover to be considered
within Moby Dick, transferring the related context between the oAR and the nAR performs reestablishment
of related AAAC context on the nAR. This requires control primitives to be exchanged
locally between the old and new Air’s HO module and the AAAC attendant. Context has to be requested
from the AAAC attendant on the oAR on reception of the Router Solicitation for Proxy. To identify the
respective mobile terminal, the old CoA 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
D0103v1.doc 70 / 168

D0103v1.doc Version 1 6.7.2003
is to be passed to the AAAC 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
AAAC 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 (fig. above)
• 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 (fig above)
The context will consist of a Type Length Value 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.
Old AR
New AR
User Space
AAA Att.
User Space
AAA Att.
1.
Trigger
ctxTran
FHO Mod.
Kernel
2.
CtxtoFHO
3. Handover Initiate
FHO Mod.
Kernel
4.
CtxtoAtt
Figure 54: FHO module and Attendant interaction during FHO
4.2.3.8.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 below: step 1), which is performed in step 2 (figure below). The context is
included in the Handover initiate message to the nAR (step 3, figure below) where it is given to the
respective AAAC attendant in step4. The figure below shows the interaction between the different entities
involved in detail.
On receiving a “Router Solicitation for Proxy” message form the MN, the FHO module at the old access
router requests the AAAC Attendant for the context associated with the MN. The FHOmodule 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.
4.2.3.8.3 Interface contents
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 };
D0103v1.doc 71 / 168

D0103v1.doc Version 1 6.7.2003
{ MN-User-Name};
{ Session-Id};
{ ATT-MN-3DES-KEY};
{ ATT-MN-SPI};
Source Dest Primitive Parameters
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
Context (i.e., stream of bytes)
Table 15: Interface Contents
4.2.3.9 Interface between AAAC Client and Integrated Logger
The interface provided by the Integrated Logger is simple and consists of 5 functions and a structure.
The functions are:
• void createAAACClientLogger(char *loggerName);
Call this function once at the initialization of the AAAC Client. The parameter loggerName contains
the identity of the logger. If this parameter is NULL, then the concatenated hostname and
“:aaacclient” will be used as the LoggerID by the Integrated Logger.
• int logReg(usrRegLogStruct *usrRegLog); // return 0 if successful
Call this function for each registration request and regis tration response. The function returns 0 if no
error occurs, otherwise it returns a negative number (Logger not initialized (-1), Parameter is NULL
(-2), Error while logging (-3)).
• void destroyAAACClientLogger();
Call this function at the end of execution of the AAAC Client.
• void logger_add_map(char *nai, struct in6_addr *in6_CoA);
Call this function if a user is registered to this AAAC Client either by an initial registration or a
“joining” handover.
• void logger_remove_map(struct in6_addr *in6_CoA);
Call this function if a user is deregistered to this AAAC Client either due to session timeout or
“leaving” handover.
The structure is the usrRegLogStruct structure defined as:
typedef struct _usrRegLogStruct {
unsigned char eventId;
char NAI[256];
int NAILen;
char CoA[48];
int CoALen;
unsigned int resultCode;
} usrRegLogStruct;
It is used in the logReg() function.
D0103v1.doc 72 / 168

D0103v1.doc Version 1 6.7.2003
4.3 Radio Gateway Software Specification
This chapter gives the software specification of the different components of the Radio Gateway. These
include the Inter Working Function (IWF), the TD-CDMA 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.
IWF
TD-CDMA to
IP relay
QoS
attendant
IP to
TD-CDMA
relay
QoS Broker
Info
Management
Raw Socket
Interface
Standard Socket
Interface
Raw Socket
Interface
Internal in terface
Protocol
communication
IPv6 Protocol Stack
Kernel space
TD-CDMA NDD on MT
Standard Network
Device Interface
User space
TD-CDMA Network Device Driver
RCM / RCF
Ethernet
Network
Device
Driver
AS on MT
NAS / AS interface
Access Stratum
Figure 55: Integrated View on Radio Gateway
4.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.
4.3.1.1 Radio Gateway Operating System
The Radio Gateway will run the Linux Operating system, kernel 2.4.4 (option 1) or kernel 2.4.20 (option
2)
The Radio Gateway will run the Real-Time Linux (RTLinux) on top of the Linux Operating System,
patch RTL 3.1 (option 1) or patch RTL 3.2 (option 2).
4.3.1.2 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).
D0103v1.doc 73 / 168

D0103v1.doc Version 1 6.7.2003
The behaviour of the different sub-blocks of the IWF will be detailed in the next chapter.
4.3.1.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 TD-CDMA 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 TD-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 TD-CDMA relay block. Depending on its kind, it will be treated by this block, or
transmitted to the TD-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, which will go through the IP stack.
IWF
TD-CDMA to
IP relay
QoS
attendant
IP to
TD-CDMA
relay
QoS attendant on AR
Info
Management
Raw Socket
Interface
Standard Socket
Interface
Raw Socket
Interface
Internal interface
Protocol
communication
IPv6 Protocol Stack
Kernel space
Standard Network
Device Interface
User space
TD-CDMA NDD on MT
TD-CDMA Network Device Driver
RCM / RCF
Ethernet
Network
Device
Driver
AS on MT
NAS / AS interface
Access Stratum
4.3.1.4 Radio Channel Manager (RCM)
Figure 56: Radio Gateway Software Architecture.
This module will act as a generic radio driver, giving a high level interface 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.
D0103v1.doc 74 / 168

D0103v1.doc Version 1 6.7.2003
4.3.1.5 Radio Convergence Function (RCF)
This module will act as a specific TD-CDMA driver, giving a low level interface 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 TD-CDMA 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.
4.3.1.6 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.
The behaviour of the different sub-blocks of the Access Stratum will be detailed in the next chapter.
The following chapters give a detailed description of the sub-blocks of each component, and their
interactions with other components.
4.3.1.7 Inter Working Function
IWF
IP to TD-CDMA relay
TD-CDMA
to IP relay
QoS
Attendant
Router
Advertisement
proxy
Neighbor
Discovery
proxy
Info
Management
Other IP signaling
+ IP data
proxy
Paging
proxy
Figure 57: Inter Working Function
The IWF has interactions with the RCM (generic part of the TD-CDMA driver), the IP stack and the
Ethernet driver. It is split into the following sub-blocks.
4.3.1.8 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_TD-CDMA_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 TD-CDMA_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_TD-CDMA_CONN_IND or LOST_TD-CDMA_CONN_IND,
with parameter local connection reference, the corresponding entry will be deleted from the list.
4.3.1.9 IP to TD-CDMA relay block
The following schema details the Info Management Block and the sub-blocks presented in the next 3
chapters.
D0103v1.doc 75 / 168

D0103v1.doc Version 1 6.7.2003
IWF
IP to TD-CDMA
relay
Paging
proxy
Info
Management
Neighbor
Discovery
proxy
Router
Advertisement
proxy
IP stack
RCM
Ethernet RCM driver
Radio
Connection Manager
Broad
casting
Paging
Open /
Close
Conn
RCF
TD-CDMA Radio
Connection Manager
Broad
casting
Paging
Open /
Close
Conn
AS
• Router Advertisement Proxy sub-block
Figure 58: IP to TD-CDMA Relay 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.
• 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.
• Paging Proxy sub-block
D0103v1.doc 76 / 168

D0103v1.doc Version 1 6.7.2003
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.
IWF
IP to TD-CDMA relay
Other IP signaling
+ IP data
proxy
IP stack
RCM
Packet Transmission
Ethernet RCM driver
Control
Packet
Data
Packet
RCF
Control Channel Mngt
Data Channel Mngt
Send /
Receive
Open /
Close
Send /
Receive
Data
Data
Channels
Data
AS
Figure 59: Other IP signalling and IP data proxy sub-block
D0103v1.doc 77 / 168

D0103v1.doc Version 1 6.7.2003
• 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).
4.3.1.10 QoS Attendant sub-block
IWF
Info
Management
QoS
Attendant
IP stack
RCM
Ethernet RCM driver
Packet Transmission
Control
Packet
Data
Packet
RCF
Data Channel Mngt
Open /
Close
Send /
Receive
Data
Channels
Data
AS
Figure 60: QoS Attendant sub-block
D0103v1.doc 78 / 168

D0103v1.doc Version 1 6.7.2003
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 fro m 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].
4.3.1.11 TD-CDMA to IP relay block
The TD-CDMA to IP relay block will receive the IP packets from the TD-CDMA 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.
D0103v1.doc 79 / 168

D0103v1.doc Version 1 6.7.2003
IWF
TD-CDMA
to IP relay
IP stack
RCM
Packet Reception
Ethernet RCM driver
Control
Packet
Data
Packet
RCF
Control Channel Mngt
Data Channel Mngt
Send /
Receive
Open /
Close
Send /
Receive
Data
Data
Channels
Data
AS
Figure 61: TD-CDMA to IP relay block
4.3.1.12 IP stack
This part does not need to be further detailed.
D0103v1.doc 80 / 168

D0103v1.doc Version 1 6.7.2003
4.3.2 Radio Channel Manager
RCM
Radio
Connection Manager
Broad
casting
Paging
Open /
Close
Conn
Packet Transmission
Control
Data
Packet
Packet
Packet Reception
Control
Data
Packet
Packet
Figure 62: 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.
4.3.2.1 Radio Connection Manager block
• 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.
• 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.
• 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_TD-CDMA_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. This
information is passed to the Open / Close Connection sub-block of the RCM, with the associated local
connection reference, via message OPEN_TD-CDMA_CONN_INFO.
Then this message OPEN_TD-CDMA_CONN_INFO is forwarded to the Info Management block of the
IWF, with the parameters: local connection reference, Home Address and CoA of MT.
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_TD-CDMA_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_TD-CDMA_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.
4.3.2.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.
D0103v1.doc 81 / 168

D0103v1.doc Version 1 6.7.2003
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. 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, the IP packets will be stored.
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.
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.
4.3.2.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.
D0103v1.doc 82 / 168

D0103v1.doc Version 1 6.7.2003
4.3.3 Radio Convergence Function
RCF
TD-CDMA Radio
Connection Manager
Broad
casting
Paging
Open /
Close
Control Channel Mngt
Send /
Receive
Data Channel Mngt
Open /
Send /
Close
Receive
Conn
Data
Data
Data
Channels
Figure 63: 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 TD-CDMA AS layer.
4.3.3.1 TD-CDMA Connection Manager block
• Broadcasting sub-block
It will transmit the broadcast requests from the RCM, message IWF_BROADCAST_REQ, to the Access
Stratum (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…).
• 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.
• 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_TD-CDMA_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. This information is passed to the Open / Close Connection
sub-block of the RCM, with the associated local connection reference, via message OPEN_TD-
CDMA_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
D0103v1.doc 83 / 168

D0103v1.doc Version 1 6.7.2003
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_TD-CDMA_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_TD-CDMA_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, we 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 reestablish
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.
4.3.3.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.
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.
4.3.3.3 Data Channel Management block
• 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, is sued 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. This 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.
D0103v1.doc 84 / 168

D0103v1.doc Version 1 6.7.2003
The radio bearers will be released by the TD-CDMA 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.
• 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.
4.3.4 Access Stratum
C-plane signalling
U-plane information
GC SAP
NT SAP
DC SAP
Qos SAPs
control
RB MUX/DEMUX
RRC
control
PDCP
PDCP
Radio
Bearers
L3
control
control
control
RLC
RLC
RLC
RLC
RLC
RLC
L2/RLC
Logical
Channels
MAC
L2/MAC
Transport
Channels
Layer 1 High
L1
Layer 1 Low
D/A
A/D
Data AcQuisition (DAQ)
Hardware
RF (TDD)
Figure 64: Access Stratum Layers
D0103v1.doc 85 / 168

D0103v1.doc Version 1 6.7.2003
The elements of the radio interface protocol are shown in figure 64, 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).
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 4.3.4.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
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 64 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.
D0103v1.doc 86 / 168

D0103v1.doc Version 1 6.7.2003
4.3.4.1 General architecture of the software platform
This section presents an overview of the basic hardware/software architecture. 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.
• 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 analogue/digital interface
• an up/down conversion RF card using TDD multiplexing
The radio portion is capable of generating arbitrary signals of a 5MHZ bandwidth in the 2110-2170 MHz
band using TDD multiplexing. A new radio interface is being produced for the 1900-1920 MHz band
(UMTS TDD).
• 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 realtime
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 65 and figure 66.
IP Network (v4 v6)
Multi-CPU Linux Machine
/dev/srnet
/dev/eth0
Kernel
Space
Layer 1H/2/3
RT thread
Radio
Bearers
IP Networking subsystem
Linux Kernel
Server
Functions
PCI
Real-time
µKernel
DAQ
+
RF
Layer1L
RT thread
Real-time Space
User
Space
Figure 65: Radio Gateway 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 TD-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).
D0103v1.doc 87 / 168

D0103v1.doc Version 1 6.7.2003
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.
Normal Linux Laptop
/dev/srnet
Kernel
Space
Layer1H/2/3
RT thread
Radio
Bearers
IP Networking subsystem
Linux Kernel
User
Application
Cardbus
DAQ
+
RF
Layer1L
RT thread
Real-time
µKernel
Real-time Space
User
Space
Figure 66: Mobile Terminal Architecture
4.3.4.2 Physical Layer Software Architecture
4.3.4.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 67.
FRAME i
10 ms
Slot
#0
Slot
#1
Slot
#14
2560 T c
T c = chip time = (1 / 3.84) µs
Figure 67: 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).
4.3.4.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 multilevel
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
D0103v1.doc 88 / 168

D0103v1.doc Version 1 6.7.2003
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 originated 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.
• 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 onto one
or two downlink slots per frame only.
4.3.4.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 66, 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.
4.3.4.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)
D0103v1.doc 89 / 168

D0103v1.doc Version 1 6.7.2003
• 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.
4.3.4.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].
4.3.4.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.
• 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.
4.3.4.3.2 Transport and Logical channels
o 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.
o 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).
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.
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 exis t in both uplink and downlink.
D0103v1.doc 90 / 168

D0103v1.doc Version 1 6.7.2003
o Mapping between logical channels and transport channels
The logical/transport channel mappings as seen from the UE and Network sides are shown below.
BCCH-
SAP
PCCH-
SAP
DCCH-
SAP
CCCH-
SAP
DTCH-
SAP
MAC SAPs
BCH
RACH
FACH
DCH
Transport
Channels
Figure 68: Logical channels mapped onto transport channels, seen from the UE side
BCCH-
SAP
PCCH-
SAP
DCCH-
SAP
CCCH-
SAP
DTCH-
SAP
MAC SAPs
BCH
RACH
FACH
DCH
Transport
Channels
Figure 69: Logical channels mapped onto transport channels, seen from the Network side
4.3.4.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.
4.3.4.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].
D0103v1.doc 91 / 168

D0103v1.doc Version 1 6.7.2003
4.3.4.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.
4.3.4.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.
4.3.4.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].
4.3.4.5.1 PDCP Services provided to upper layers
- PDCP SDU delivery.
4.3.4.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.
4.3.4.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.
4.3.4.6.1 Services provided to the Non Access Stratum
• 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
D0103v1.doc 92 / 168

D0103v1.doc Version 1 6.7.2003
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.
• 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).
• 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.
4.3.4.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.
• 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.
D0103v1.doc 93 / 168

D0103v1.doc Version 1 6.7.2003
4.3.4.6.3 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
4.3.4.6.4 RRC procedures and messages
The RRC protocol procedures are detailed in specification [25.331]. The following procedures are
implemented in the Moby Dick framework.
Broadcast of system information
RG → UE - - SYSTEM INFORMATION System Information is broadcasted in System
Information Blocks. The following ones are used:
• 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 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.
RRC connection establishment
UE → RG - RRC CONNECTION REQUEST
RG → UE - RRC CONNECTION SETUP
UE → RG - RRC CONNECTION SETUP
COMPLETE
RG → UE - RRC CONNECTION REJECT
RRC connection release
UE → RG – RRC UL CONNECTION RELEASE
Initial Direct transfer
UE → RG - INITIAL DIRECT TRANSFER
Downlink Direct transfer
RG → UE - DOWNLINK DIRECT TRANSFER
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.
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
The downlink direct transfer procedure is used in the
downlink direction to carry upper layer (NAS)
messages over the radio interface.
D0103v1.doc 94 / 168

D0103v1.doc Version 1 6.7.2003
Uplink Direct transfer
UE → RG - UPLINK DIRECT TRANSFER
UE dedicated paging
RG → UE - PAGING TYPE 2
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.
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.
Radio bearer establishment
RG → UE - RADIO BEARER SETUP
UE → RG - RADIO BEARER SETUP COMPLETE
UE → RG - RADIO BEARER SETUP FAILURE
Radio bearer release
RG → UE - RADIO BEARER RELEASE
UE → RG - RADIO BEARER RELEASE
COMPLETE
UE → RG - RADIO BEARER RELEASE FAILURE
Cell update procedures
UE → RG - CELL UPDATE
RG → UE - CELL UPDATE CONFIRM
The cell update procedures serve several main
purposes:
• to notify the Network of an RLC unrecoverable
error [25.322] on an AM RLC entity;
• 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.
4.4 QoS Broker Software Specification
Table 16 : RRC procedures and messages
This section describes the software specification of the Bandwidth Broker (QoS Broker). It will describe
the Moby Dick components that interact with the QoS Broker, the broker’s interfaces and all its internal
functions.
On each QoS Broker interface we will discuss the messages exchanged between the QoS Broker and the
other MobyDick components, its format and when they will occur. At the end of the section we will
resent the QoS Broker databases format, and discuss its purpose.
A bandwidth broker is an entity that takes admission control decisions and configures all access network
components, according to a set of conditions given by administration entities.
4.4.1 General QoS Broker Positioning
Figure 70 shows a view of all the entities of the Moby Dick project that interact with QoSBroker.
D0103v1.doc 95 / 168

D0103v1.doc Version 1 6.7.2003
AAAC
Server
NMS
Entity
Router
QBroker
QBroker2
Computer
Cisco/Linux
Linux Router
Radio tower
Cisco
Router
Cisco
Router
Laptop
Telephone
Workstation
Server
Figure 70 – The QoS Broker within the Moby Dick architecture
These entities can be summarized as:
• AAAC Server. The entity responsible for authenticating user information, identifying the
proper SLA (Service Level Agreement), keeping accounting and charging information.
• NMS Server. The entity that makes core network configuration and defines the available
resources for the broker in each moment.
• “Other brokers”. Each broker has his own domain of action. To keep end-to-end QoS, all
brokers in the path need to interact.
• Network routers. Routers have to be configured according to the user profile, and network
conditions, so that QoS conditions can be achieved. The QoS broker will be the responsible
for the router configuration.
4.4.2 QoS Broker components
Figure 71 represents a block diagram of the QoS Broker components and its relation to other components
.
AAACInterf
QBroker
FHOInterf
NMSInterf
NetworkDB
User
Profile
Data
QBrokerEngine
NetStatus
RGWClient
NetProbe
WebGUI
RouterInterface
Figure 71 - QoS Broker components and its external relations
D0103v1.doc 96 / 168

D0103v1.doc Version 1 6.7.2003
Now we will list all the components with a small description of each one:
4.4.2.1 WebGUI
WebGUI is the module that enables the contact with the human operator. It was developed with two
purposes:
• It enables the QoS Broker configuration with the data edition in the NetworkDB database;
• It shows the network use status, showing the active reservations and the profiles authorized;
4.4.2.2 NetProbe
NetProbe is the entity that monitors the network status. The collected information is inserted in a database
named NetStatus. This information and the information given by the NMSInterface represent the network
status, at every instant. QBrokerEngine will user this information to decide if it should or should not
allow a new access to the network resources.
4.4.2.3 QBrokerEngine
QBrokerEngine is a process that manages several threads, one for each interface. Those threads should
wait for requests from the outside world. We will have:
• AAACAttendant – AAACAttendant will receive and answer the AAAC requests
• InterBrokerAttendant – InterBrokerAttendant receives external FHO-related data needed by the
nQoSBroker to configure the mobile terminal's nAR.
• RouterAttendant – RouterAttendant will receive router requests after processing the QoSBroker
answers. Those requests can to be summarized as follows:
o Data flow authorizing requests: AR requests QoSBroker to accept some data flow, and
QoSBroker after analysing network resource state answers accepting or rejecting that
flow;
o FHO requests: oAR contacts QoSBroker requesting the FHO process sending oCoA,
nCoA and nAR addresses. QoSBroker looks for nAR address
QBrokerEngine is responsible to launch, stop and manage those threads.
4.4.2.4 QoS Broker Interfaces
QoS Broker has several interfaces, one for each Moby Dick architecture component. Figure 72 shows a
picture of this aspect of the architecture.
AAACInterf
RGWClient
QoSBroker
NMSInterf
RouterInterface
WebServer
BrokerInterface
Attendant
BrokerClient
Now we will describe those interfaces:
4.4.2.4.1 BrokerInterface
Figure 72 – QoS Broker interfaces
BrokerInterface is the module that interfaces with neighbouring Brokers. This interface is used to change
external handover information between oQosBroker and nQoSBroker. As soon as oQoSBroker realises
that nAR belongs to other QoSBroker it collects NVUP information and reservation information about
this oCoA and sends it to the nQoSBroker. The communication between QoSBroker is made using COPS
protocol and the COPSApi developed to the communication between the AAAC, the AR and the
QoSBroker is utilised.
4.4.2.4.2 NMSInterface
That’s the interface with NMS (Network Management System) entity that allows the NMS entity to
define the network resources that can be used by this broker. It should also allow access to policy, alarm
processing and service translation functions. This interface should also to be connected to the database
D0103v1.doc 97 / 168

D0103v1.doc Version 1 6.7.2003
that keeps the network information, named NetStatus. It will receive a message SendQoSBConfigData
with parameter QOSB_CONFIGDATA.
4.4.2.4.3 AAACInterface
AAACInterface interfaces with the AAAC server. It defines the service QoS parameters at QoSBroker
start-up time, and dumps NVUP information to QoSBroker when any user registers in AAAC system.
Once the AAAC server starts running, it connects with the QoSBroker and sends a message defining QoS
parameters used in the available services and the corresponding DSCP codes. Those parameters are used
in the network QoS management that QoSBroker does during its operation.
After user registration in the AAAC system has been performed, the AAAC server dumps NVUP
information into the QoSBroker defining the list of services that the user will be able to use. The NVUP
information contains information such as CoA, authorisation timeout, and a list of services described by a
source address, destination address and a DSCP. It is also possible to have different timeouts for different
services, because each service has its own timeout.
4.4.2.4.4 RouterInterface
RouterInterface is the entity that will interface with the routers. It will have two modes of operation:
• receives the router request reservations: when a host starts sending a packet flow, the
Access Router (AR) will send a request to the QoSBroker through COPSDriver making a
resource reservation. QoSBroker analyses network usage state and sends an answer
accepting the new flow, or denying it.
• sends router configuration information: during AR startup, and when AR requests for a
configuration, the QoSBroker sends a set of parameters configuring the AR Queues;
4.4.3 Software Implementation
Now we will describe the implementation that has been done of the software components. We will start
with the interface description, and then we will analyze the databases used by the broker, and this
structure.
4.4.3.1 Interfaces
4.4.3.1.1 AAACInterface
AAACInterface interfaces with the AAAC server.
4.4.3.1.1.1 Data format interchanged between QoSBroker and AAAC
NVUP (Network View of User Profile). It represents the subset of the user profile that the network needs
to know. Such subset includes:
-User ID / NAI;
-Home Domain / Home service provider;
-Source address;
-N services: number of services that a user subscribed;
-Array of N elements with:
-Destination address;
-Authorisation timeout;
-DSCP signalling code;
DSCP signalling code can be very useful in a situation of a foreign domain access with different QoS
signalization. For each user is defined a set of N services that can be used by him. Each service has an
authorisation timeout, a destination address, a QoS Profile describing this service QoS parameters, and a
DSCP signalling code. Matching user profiles in different domains is a task to AAAC.
QoSProfile – QosProfile represents the QoS conditions of some profile. This profile defines some
parameters as:
-DSCP;
-Bandwidth;
-Priority;
-Minimum Delay;
4.4.3.1.1.2 Messages changed between AAAC and QoSBroker
It will allow several messages in several different moments:
1. Before Operation: SendQoSProfile(QoSProfile) – Used by the AAAC to define to the
QoSBroker the QoS Profiles, and its QoS parameters;
2. Registration time: AuthorizeProfile(NVUP) - AAAC signals QoSBroker to allow resource
usage (for a user). Resources are not yet reserved, this is done at session setup time;
D0103v1.doc 98 / 168

D0103v1.doc Version 1 6.7.2003
3. Deregistration time: DeAuthorizeProfile(NVUP) – AAAC signal QoSBroker to cancel resource
usage by that user;
Communication between AAAC and the QoSBroker is made using a COPS API, that implement COPSprotocol
as messages aren't answered by the QoSBroker because of scalability reasons it was decided that
the AAAC server shouldn't wait for the QoSBroker answer each time it sends a message.
4.4.3.1.2 RouterInterface
As was stated before RouterInterface is the interface to the routers. Figure 73 shows its internal
composition.
QBroker
QBrokerEngine
NetProbe
VirtualRouter
CLIDriver
COPSDriver
Linux Router
Figure 73 - RouterInterface internals
Here is the list of those components :
• VirtualRouter: It chooses the driver that should to be used to communicate with some
specific router;
• CLIDriver: CLIDriver is the driver used to communicate with routers that we should
communicate by Command Line Interface;
• COPSDriver: COPSDriver is the driver used to communicate through COPS.
The incoming messages from the routers that request some network resource are mapped from the
COPSDriver directly to the QBrokerEngine. The outgoing messages, from the QBrokerEngine to the
routers, messages to make some configuration, or simply to analyse the network status are passed to the
VirtualRouter. Now we will describe in more detail these components and their implementation.
4.4.3.1.2.1 VirtualRouter
VirtualRouter, in Figure 74, is a kind of virtual driver that will interface the Router Interface and the
router drivers that broker use to configure the routers. It will have a database that keeps information about
the routers, its vendors, its models, and its communication format.
When the Virtual router receives a message that it should send to a router, it should verify the routers
communication format and use the correct driver to send that message. Like that we are able to have
different protocols to be used to “talk” with different routers. Such an architecture was chosen because of
the following reasons:
• The program uses the drivers as an abstraction to communicate with all the routers without
taking care about specific router communication details, making development easier;
• Makes the program evolution easier, when a new router arise the only thing needed is to add a
new entry in the database and add the specific router commands in the database.
D0103v1.doc 99 / 168

D0103v1.doc Version 1 6.7.2003
Router Interface
VirtualRouter
Engine
Router
List
Database
CLIDriver
COPSDriver
Cisco
Router
Linux Router
Figure 74 - VirtualRouter
4.4.3.1.2.2 CLIDriver
CLIDriver is the driver that will communicate with the routers using the Command Line Interface. It will
receive requests from the VirtualRouter and then forward them to the routers through a set of instructions
that are present in the database.
Router Interface
VirtualRouter
Engine
Router
List
Database
CLIDriver
Engine
CLI
Command
Cisco
Router
Router
Figure 75 - CLIDriver
When the Virtual router receives a message from a CLI router, it sends this message to the
appropriatedriver. CLIDriver check in this database how to format the message in routers CLI commands.
Then it will send the list of commands one by one to the router, making the message configuration.
4.4.3.1.2.3 COPSDriver
COPS protocol was specially designed to exchange network policy information between a network policy
decision point (PDP) and policy enforcement points. In this case the policy decision point is the broker
and the policy enforcement point is the router. When the router starts receiving a set of packets from a
user with some QoSProfile code, it will ask the QoSBroker to reserve resources to this particular flow.
After analysing the network conditions, the QoSBroker will send an answer that will be applied by the
router. In order to supply the QoSBroker with all needed information to judge about that reservation,
router and QoSBroker should exchange some messages with some data.
D0103v1.doc 100 / 168

D0103v1.doc Version 1 6.7.2003
User
Profile
Data
QBroker
QBrokerEngine
NetStatus
RouterInterface
COPSDriver
Linux Router
Figure 76 – COPSDriver as a PDP interface
COPS communication between AR and QoSBroker is made by the COPSApi referred before. The Api
implements a COPS-RSVP-like protocol, with the exception in the FHO message that is the only
unsolicited message the Api supports. This interface uses the change of Keep-Alive messages in order to
the network components to announce its running state to the network elements that they are connected.
4.4.3.1.2.4 Data format interchanged between AR and QoSBroker
BehaviourData: It describes the QoSManager queues parameters. This structure can be described:
- dscp_b;
- dest_addr;
- queue_type;
- behaviuor;
- borrow_flag;
- min_gred_queue;
- max_gred_queue;
- prob_gred_queue;
At QoSManager start-up time, the QoSManager requests the configuration from the QoSBroker. The
QoSBroker collects an array of BehaviourData from describing QoSManager queues information and
send them to QoSManager.
RD (Resource Description). It describes the resource that is being requested to the AR by a host. Such a
description has:
-Source address;
-Destination address;
-DSCP signalling code;
DSCP is the reference to the QoS profile wanted. With this information QoSBroker will analyse network
conditions and decide about accepting or rejecting that flow.
FHOData(Fast Handover data). It describes the FHO process being requested to the QoSBroker. This
structure has:
- oCoA ( the old CoA): the address in use by the MN that is making a FHO;
- nCoA ( the new CoA): the address that will be used by the MN after the FHO process;
- nAR ( new AR): the address of the router that will connect the MN after the FHO.
FHOServReserv (Fast Handover Service Reservation): is the fast handover registered service
description sent by the QoSBroker to the nAR after a FHO decision was taken. This data structures has:
- SourceAddress (Source address): is the source address of the registered service for the MN;
- DestAddress (Destination address): is the destiny address of the service registered to that MN;
- DSCP: is the DSCP of the regis tered service;
- PolicyBW (Policy Bandwidth): is bandwidth values send to nAR that is used for the data rate
parameter of the queue that is created to keep this service packets;
- PolicyBurst (Policy Burst): is the burst rate value that defines the burst rate of the queue that
AR will create in it interface to keep this service packets;
D0103v1.doc 101 / 168

D0103v1.doc Version 1 6.7.2003
A FHO answer is sent from QoSBroker to the nAR having a FHOServReserv for each registered service
that the MN owns in the QoSBroker. For a MN having N registered services in the QoSBroker the
message has an array of N FHOServReserv structures describing those services.
4.4.3.1.2.5 Messages exchanged between AR and QoSBroker
During AR and QoSBroker functioning several messages are exchanged between the two programs.
Those messages can to be listed:
- ConfigRequest: is a configuration request made by AR in order to know configuration it should give to
its interface queues. This message is send at AR start-up and after QoSBroker shows its configuration
intention flag. Each time QoSBroker detects the need of reconfiguring AR it will wait for the next AR
requests and then the QoSBroker will set the reconfiguration flag in the answer it send to AR. After
receiving the message with this flag AR makes a configuration request to QoSBroker.
- ConfigDec: is the configuration message sent by the QoSBroker to the AR describing the interface
queues parameters. This message sends data
- ResourceRequest: Is the message sent by QoSManager to QoSBroker requesting for accepting a flow
described by the RG structure. QoSBroker, accepting or denying that flow acceptance answers this
message.
- ReleaseResource: Is the message send by QoSManager requesting QoSBroker to deallocate those
resources described in the RG structure.
- FHORequest: Is the FHO request sent by oAR to QoSBroker that defines the oCoA, the nCoA and
nAR. QoSBroker analyses this request and send an answer to oAR.
- FHODecision: Is the FHO decision sent from QoSBroker to oAR. After analysing the FHO request and
network resource availability, QoSBroker sends an answer to nAR.
4.4.3.1.3 NMSInterface
NMSInterface is the interface through QoSBroker will know the resources of the core network that will
be able for its own usage.
The definition of those resources will be made by a data structure like:
UpstreamResoucesData
UpstreamBW
UpstreamDelay
This data will be sent to the QosBroker by a message like SendQoSConfigData(UpstreamResoucesData);
4.4.3.1.4 RGWClient
This interface is used to open a radio barrier in the radio gateway.
4.4.3.2 Data format interchanged between Radio Gateway and QoSBroker
qosb_radio_bearer_info_t: This structure defines a radio bearer information. It has some fields:
- dscp;
- radio_QoS_class;
- status;
radio_access_allocation_msg_t: This structure defines the message QoSBroker sends to Radio Gateway
- type: Only one type of message, but keep it for compatibility;
- nb_entries: number of valid entries in info array;
- Home_Addr: home address of the MT attached to radio gateway;
- qosb_radio_bearer_info_t: an array of radio barer information structures;
4.4.3.2.1.1 Messages changed between Radio Gateway and QoSBroker
OpenChanel: QoSBroker sends a message to Radio Gateway opening a radio barer.
4.4.3.2.2 Interface Summary
In order to summarize all the interface information, messages, data changed and message timing we
present the following table:
D0103v1.doc 102 / 168

D0103v1.doc Version 1 6.7.2003
Interface Timing Message Send data
AAAC
QoSBroker SendQoSProfile Services Description
start-up
User
AuthoriseProfile NVUP
registration
time
User
registration
removal
DeAutorizeProfile
AR
Before runtime
ConfigRequest RouterConfig
ChangeConfig
Run-time ResourceRequest Resource
ResourceRelease
In a handover HandoverRequest HandoverResource
HandoverDec
NMS Any time SendQoSConfig QoSResourceData
QoSBrokerInterface External RequestHandover HandoverResource
Hanover
process
Radio Gateway In a new Radio
Gateway flow
OpenChannel
radio_access_allocation_msg_t
Table 17: RG to QoS Broker data
4.4.3.3 Databases
QoS Broker will have several databases. Depending on the size of them, the number of necessary queries
they should have, these databases will be present in memory or in a file. We will analyse each situation in
the following lines.
4.4.3.3.1 NetworkDB
NetworkDBs is the database that keeps the information about the network topology. It will keep
information about each router that the broker manages, its load information, the queues defined to each of
its interfaces, the scheduling algorithm applied to each interface, the occupation of each queue and the
resources that the NMS assigned in this broker. The database, as can be seen in the Figure 77, will have 5
tables:
• Router. Router table keep information such as router memory, processing capacity, router
load, and its state;
• Interface. Represents the router interfaces. It will keep information such as the Interface
address, the scheduling discipline used by the interface, and interface state;
• Queue. Represents the interface queues. It will keep the queue memory, queue occupation,
queue priority;
• QueueConf: Describes the AR queues parameters;
• RadioGW: Lists the radio gateways that belong to QoSBroker network. I has the radio
network address, as well as its network address and network mask;
• NetService: It describes the QoSBroker network services, as well as the correspondence
existing between services and radio classes;
D0103v1.doc 103 / 168

D0103v1.doc Version 1 6.7.2003
PK,FK1,FK2
PK
QueueConf
DSCP
InterfaceBW
Bandwidth
AgregNumb
Borrow
MinGRED
MaxGRED
DropNumb
LimitGRED
QueueID
PK,FK1
FK2
Interface
InterfaceID
Address
Active
IsCoreInterface
TotalBandwidth
RefDisciplineID
RefRouterID
QueueID
PK
FK1
Router
RouterID
Active
AvailBW
Login
Pass
EnablePass
Name
RefBrokerID
InterfaceID
Broker
PK
Queue
QueueID
DSCP
DropNumber
SentNumber
YellowMarked
RedMArked
Occupation
OverLimits
BurtSize
Rate
BufferSize
YellowThreshold
RedThreshold
RefInterfaceID
NetService
PK DSCP
Name
RadioClass
FK1 QueueID
PK,FK1,FK2
PK
RadioGW
BrokerID
Address
Active
RadioGWID
CoreInterf
NetInterf
RefInterfaceID
RefBrokerID
Figure 77 - NetworkDB database format
4.4.3.3.2 NetStatus
NetStatus database keeps information about the network state. It keeps information about network usage,
as well as about authorized user profiles in this network. This database has the tables:
- NVUP: Keeps the information about the NVUP of the registered user;
- NetService: Has the authorized service list of the registered users;
- Reservations: Keeps a list of network services in use by a network user;
NVUP
NetService
Reservations
PK
NVUPID
PK
ServiceID
PK
ReservID
NAI
CoA
Timeout
FK1
SourceAddress
DestAddress
DSCP
Timeout
RefNVUPID
Figure 78: NetStatus database
SourceAddress
DestAddress
DSCP
Timeout
RefRouterID
4.5 AAAC Server Software Specification
This document describes the modules within the AAAC Server and their interaction.
D0103v1.doc 104 / 168

D0103v1.doc Version 1 6.7.2003
User
Profile
Policy
Acctg
DB
Charging
Module
AAAC
Server
DIAMETER
Server
Chrg
DB
Home
Agent
QoS
ASM
QoS
Broker
AAAC
Attendant
Audit
Trail
Auditing
Audit
Rpt
Figure 79: AAAC Server Architecture
The following sections describe the functionalities of each module and the interaction with other
modules within AAAC Server as well as with other MobyDick entities, if any. The interaction comprises
of message sequence and the respective parameters.
4.5.1 User Profile
This document first gives a specification of the user profile as used within the project Moby Dick and in
the second part it defines a set of user profiles to by used within the Moby Dick tests. The goal for these
test users is not to have a complete list of all possible test users with the variety of possibilities of how to
assign parameters to a QoS profile, but to define a well known set of profiles which allow to reproduce
integration tests since they are based on these profiles.
A user profile is a data record of user-specific data; it contains all the data associated with the user, e.g.
username, authentications data, service level agreements, charging info, policies etc.
The user profile is unique, every user who is able to access the network and use some application or
network services must have one user profile.
The information contained in the user profile could be divided in the following different groups:
• User specific information for authentication purpose: Username, password, secret key, etc.
• Service specific information for authorization purpose: Service level agreements, max
bandwidth, etc
• Charging / Tariff specific information for accounting purpose: Tariff group, etc.
4.5.1.1 User Profile Attributes
The information in the user profile is usually represented as attributes.
An attribute is consisting of the name of the attribute and a value, called an Attribute-Value Pair (AVP).
The user profile contains a set of mandatory attributes, which must be present, and a set of optional
attributes, which may be present. Mandatory attributes are set during the creation process of the user
profile with the user value or the default value. In the RADIUS and DIAMETER specification various
attributes are defined.
The user profile contains static attributes. The Static attributes are not being changed during a session.
Dynamic data and accounting data are stored in the session and accounting record. Maybe some (limited)
sections of the user profile could be dynamic. One example of this is a remaining budget in the case of a
prepaid user.
D0103v1.doc 105 / 168

D0103v1.doc Version 1 6.7.2003
4.5.1.2 General View of User Profile
Before talking of user profiles and their definitions, we need to spend some thoughts on the accounting,
charging, customer profiles and SLA’s—since this is all related together. Within the MobyDick project
there will be “MobyDick” -operators offering services to the customers. For such an operator accountingand
charging-components (besides many other components) will be developed. One aim is that roaming
between different “MobyDick”-operators shall be possible. This aim has main influence in developing the
accounting and its components, c.f. section 4.5.3. All accounting data is stored at the AAAC.h—in the
case of roaming (i.e. the customer is in a foreign domain), the accounting data is transferred from the
AAAC.f to the AAAC.h and then stored in the accounting database. The format and structure of the
accounting data is fixed, cf. section 4.5.4.4.
The next step is the SLA between the customer and one of our “MobyDick”-operators. Each user must
have an SLA with at least one operator (called home operator), before he can use a service—this SLA
may include the post- or prepaid billing scenario. Basically each “MobyDick”-operator can setup its own
SLA’s and its own tariff structure. In order to support roaming between operators, the basis for the
charging (and tariffs) will be the accounting data, which has always the same structure (cf. section
4.5.4.4). So, each “MobyDick”operator could use its own charging component and its own tariff
structure, regardless what the other operators will use and roaming would still be possible.
Within the MobyDick-project we need to develop one charging component for a “MobyDick”-operator.
The charging component will be developed at ETH and will then be used for all “MobyDick”-operators,
since no other charging components will be developed. Therefore, all operators will use the same
charging components with the same tariff structure (but not the same tariffs) and hence the SLA’s and the
corresponding parts in the customer profile will have the same structure, too. This is simply due to the
fact that the SLA’s and the charging/tariffing structure are closely related.
This general structure of the SLA’s, i.e. their representations in the customer profiles are shown in Table
20. The customer database containing this data will be realized with MySQL and is always located at the
home “MobyDick” operator.
Some entries in Table 20 should not be transferred to any other “MobyDick”-operator, because the data is
only needed by the charging and/or billing component of the home operator, cf. last column. The first
rows of Table 20 contain information about the user’s address. The row for the remaining budget “RB”
will be used in the future to support the prepaid business case. Here it is important to note that the
remaining budget in monetary units (e.g. € 12.50) must never be transferred to another operator. But the
representation of the remaining budget in terms of “accounting units” (e.g. 120 MB download volume)
needs to be accessible for other operators, since they need to know, when the remaining budget is empty.
The row “Payment scheme” is used to distinguish between the post- and prepaid business case.
The structure of tariffs is as follows:
Within an SLA, each service is associated with a tariff ID. In the accounting process, services can be
distinguished on the basis of the DSCP field, cf. section 4.5.4.3, 4.5.4.4 for details. Because we
distinguish between tariffs in the home and foreign domain, there exists also different tariff ID’s for the
home and foreign domain. As an example “HDTariffS1” would contain the tariff ID for service S1 in the
home domain. Certain values of the tariff ID’s have special meanings, please refer to Table 18.
Values of TariffID’s
Meaning
0 Users is not allowed to use the respective service
according to the SLA
1 Signalling (this might lead to no charge or only a
very small charge)
2 … 9 Reserved for future use
10 … 255 Valid Tariff ID’s of services
Table 18: Values of tariff ID’s.
In order to give further structure in the values of the tariff ID’s, the ranges reserved for selecting the tariff
are shown in Table 19. With this predefined structure it’s possible to setup 5 different tariffs for each
service per domain. For the MobyDick environment this represents enough flexibility.
D0103v1.doc 106 / 168

D0103v1.doc Version 1 6.7.2003
Service Values of TariffID’s Home or Foreign Domain
S1 10 – 14 HD
15 – 19 FD
S2 20 – 24 HD
25 – 29 FD
S311 30 – 34 HD
35 – 39 FD
S312 40 – 44 HD
45 – 49 FD
S313 50 – 54 HD
55 – 59 FD
S4 60 – 64 HD
65 – 69 FD
S5 70 – 74 HD
75 – 79 FD
S6 80 – 84 HD
85 – 89 FD
(S7) 90 – 94 HD
95 – 99 FD
SIG 1 FD and HD
Table 19: Ranges reserved for selecting tariffs.
MySQL
Column
Name
MySQL
Data Type
Example Remarks Transfer
allowed?
UserID VARCHAR (255) mhans@abc.com It is the NAI of the user,
which must be globally
unique, and it will be the
primary key.
Password VARCHAR (255) top-secret No
Email VARCHAR (255) hans.muster@abc.com No
LastName VARCHAR (255) Muster No
FirstName VARCHAR (255) Hans No
Street VARCHAR (255) Bahnhofstrasse 12 No
City VARCHAR (255) Zürich No
Zip VARCHAR (255) 8001 No
Country VARCHAR (255) Switzerland No
HDTariffS1
HDTariffS2
TINYINT
UNSIGNED
(Value 0 to 255)
TINYINT
UNSIGNED
10, cf remarks on
reserved value
This value specifies the
TariffID (i.e. tariff) that
will be applied, when a
customer will use this
service in his HOME
domain.
If the value is “0” then the
user is not allowed to use
the service.
... No
… … … … …
HDTariffS6
TINYINT
UNSIGNED
... No
FDTariffS1 TINYINT 10 This value specifies the No
Yes
No
D0103v1.doc 107 / 168

D0103v1.doc Version 1 6.7.2003
FDTariffS2
UNSIGNED
TINYINT
UNSIGNED
TariffID (i.e. tariff) that
will be applied, when a
customer will use this
service in his FOREIGN
domain.
... No
… … … … …
FDTariffS6
TINYINT
UNSIGNED
... No
Table 20: Generic Moby Dick User Profile
In order to allow a user the usage of applications and services in both, home network and foreign
network, information about the user is necessary and services for authentication, authorization and
accounting purpose. An AAAC service provides the needed information to authenticate a user and to
establish authorized network service for a user. A main idea of a distributed AAAC service is that all data
associated with users are stored centralized in the user database. All data in this database associated with
the same user is called user profile of this user.
4.5.1.3 User Profile Distribution
A User Profile generally is stored in a repository “close” to the AAAC.h server. Within this context,
“closed” means that the AAAC.h server has all access capabilities to this repository required for
Authentication and Authorization process. So an interface to the user profiles is the access over the
AAAC.h to which a user has registered.
After the AAAC.h received an authentication and authorization request over AAA protocol for a usage of
an applications or a network service, the AAAC.h retrieves over this interface all needed information
from the user profile, in order to make a decision. If the decision is successful the home AAAC server
sends in the authentication and authorization response all attributes of the user profiles, which are needed
to provide the service to the user. Usually the authentication and authorization decision is made from
Home AAAC Server (decision enforcement point). Only the result of the decision and configuration data
are send to AAA entity (i.e. AAAC.f), which has generated the authentication and authorization request.
The whole user profile is never sent to other AAA entity for privacy and legal issues. Only AAAC.h has
full knowledge of the user profile.
The conveyance of user profile data over the AAA protocol must be secure. This means that at least data
integrity for the end-to-end communication is guaranteed.
4.5.1.4 User Profile Management
The User Profiles are stored in the user database of users Home Domain and also all management and
maintenance tasks for the user profiles are performed in the home domain. The management and
maintenance tasks involved: to create and to delete user profiles and to add, to modify and to delete static
attributes. The registration process for a new user creates the user profile. It is assumed that this process is
done “offline” and so it is out of the scope of Moby Dick. All these tasks are performed over the
management interface to user database. This interface is not standardized in the AAA infrastructure.
Usually the user database is stored either in database or in directory service. A user has no direct access to
this user profile.
To define and implement the management interface for the user database is out of the scope of the Moby
Dick project.
4.5.1.5 Network View of user Profile (NVUP) - Global SLAs
The following section describes an example NVUP.
Name
Service
Class
Relative
Priority
Service parameters
Typical Usage Description
SIG AF41 2 Unspecified Signalling (network usage)
D0103v1.doc 108 / 168

D0103v1.doc Version 1 6.7.2003
S1 EF 1 Peak BW: 32 kbit/s Real time services
S2 AF21 3 CIR: 256 kbit/s Priority (urgent) data transfer
S3 AF1* 4 Three drop precedences
(kbps):
AF11 – 64
AF12 – 128
AF13 – 256
Olympic service (better than
BE:streaming, ftp, etc)
S4 BE 0 Peak bit rate: 32 kbit/s Best Effort (BE)
S5 BE 0 Peak bit rate: 64 kbit/s Best effort
S6 BE 0 Peak bit rate: 256 kbit/s Best effort
S7
Request AAAC
Table 21: SLA
Note: 1 is highest priority, 4 lowest. 0 means no priority.
4.5.1.6 Test users – Profile Examples
In the following a set of test-users are defined which will be represented in the repository of the database.
In the AAAC system. According to this profile specifications the traffic is marked and services are
provided.
4.5.1.6.1 Victor
User Victor is a user subscribing a high bandwidth “Internet” and a “voice”. He would get a S6, a S1 and
the SIG services attributed, no specific destination. Victor has full roaming possibilities, a fixed contract
with not budget/quota limitations. The detailed profile can be found in the Annex.
4.5.1.6.2 Eric
Eric - user subscribing a “Premium Internet” for company access, a voice and a “Traditional Internet”. It
would get the SIG, the S1 and the S5 services, no specific destination, and a S2 with destiny equal to its
company address. The detailed profile can be found in the Annex.
4.5.1.6.3 Hans
Hans – user subscribing “Flexible Internet”. It would get SIG and S3, no specific destination. Hans is not
allowed to roam. So this profile is only valid in the home domain. The detailed profile can be found in the
Annex.
4.5.1.6.4 Michelle
Michelle – user subscribing “Costless Internet”, “VideoService” and “voice”. It would get a S4, a SIG
and a S1, without specific destination, and a S2, directed to a specific videoserver, and for specific
protocols. Amardeo is able to roam. The detailed profile can be found in the Annex.
4.5.2 Diameter Entities
As shown in Figure 79 the diameter server plays a central role in AAAC architecture. The diameter server
maintains interfaces to other AAAC servers, Attendant on the access router, QoS broker via an ASM, and
to other backend databases that are used for charging, accounting, policy etc.
This section describes the interaction between Mobile Node (MN), Attendant, , AAAC Server foreign
(AAAC.f), AAAC Server home (AAAC.h) and the home agent (HA) respectively in the framework of the
Moby Dick project. The section further describes the parameters to be used. It is further a functional
specification of the interaction between the different entities involved in AAAC and MIP.
D0103v1.doc 109 / 168

D0103v1.doc Version 1 6.7.2003
Foreign
AAA
(AAAF)
Home
AAA
(AAAH)
ƒAA-Mobile-Node-
Request
„AA-Mobile-Node-
Answer
‚AA-Mobile-Node-
Request
…AA-Mobile-Node-Answer
Attendant
on
AR
MNAReq
† MNARsp
Mobile
Node
(MN)
MN = Mobile Node
Figure 80: AAAC in Moby Dick – Global Operation
4.5.2.1 User registration with a MN
The User Registration Protocol (URP) module on the MN is responsible for initiating a communication
between the MN and the AAAC attendant, which is located on the access router. This is a user space
application residing on the MN, which communicates with the MTNM module and the attendant.
The main functions of URP module are:
• Setting up an AAA session after being triggered by MTNM module
• Setting up an Security Association with the Attendant
• Passing the result of registration to NTNM module
Mobile Terminal
Access Router
User Space
URP Module
4. SendRegResp
2.
3.
User Space
AAA Att.
1.
Trigger
StartIntDomHO
NTNM Module
Kernel
Kernel
Figure 81: URP and MTNM interaction
D0103v1.doc 110 / 168

D0103v1.doc Version 1 6.7.2003
The URP is triggered by the MTNM to send a Mobile Node Authentication Request (MNARq) when one
or more then one of the following events are detected:
• the current AAA state was lost due to: (re)booting, crashing, etc.
• expiration of authorization lifetime
• the AAA domain is changed because of an hand-over (inter domain HO)
At the time of registration the URP sends the Mobile Node Authentication Request message (MNARq) to
the attendant on the access router. The information contained in an MNARq is local/internal i.e. residing
in an configuration file on the MN e.g. NAI.
Other information that is used by URP is some external information e.g. the challenge taken from a
Router (Attendant) Advertisement. This information is added into the MNARq to avoid reply attacks.
The attendant responds to MNARq with MNARp
The MN carries out the following actions upon receiving an MNARp:
• check that < AAAC.h-MAC > is correct using the SK[MN-AAAC.h]; if not drop the whole
message
• process the AAA Result-Code, HA-Result-Code
• set up timers for being able to tell when the session identified by the Session-Id is over
• set up SA the MN-Attendant SA (using key material in Att-DH-PV)
In case of errors (transport-mechanism-related, AAA-related, mobile-IPv6-related) an exponential backoff
approach for resending packets is used. As this method does not use too much resources (bandwidth)
for sending requests.
The information about the internal states / info related to MNARq / MNARp signalling must be made
available; especially to be able to generate the SAs.
The AVPs exchanged between the AAAC.h and the MN are always authenticated by computing an
HMAC-MD5 over them using SK[MN-AAAC.h]
4.5.2.2 Attendant
Attendant is a diameter specific module in the access router. The Attendant comprises a module of
software that implements the AAA signalling and a set of routing policies; some of these policies are set
up as a consequence of the AAA signalling.
Registration
protocoll
handler
ATTENDANT
AAAC protocol
handler
AAAC
Server
Mapper, Mediator, Event gen.
AAAC client
Attendant
log
Session
Status
Trigger,
remove
S.A.
Configure,
Meter data
Security
Manager
Metering
Figure 82: The attendant
D0103v1.doc 111 / 168

D0103v1.doc Version 1 6.7.2003
4.5.2.3 Registration Protocol Handler
The Registration Protocol Handler (RPH) is triggered on receiving an MNARq or on receiving an
MNARp.
The MNARq message is sent when the MN is switched on or the authorization lifetime expires. After
such an event the MN communicates with the attendant to request an access. As Diameter is not used for
communication between a MN and an Attendant, the AAA request from the MN must be sent using UDP
to the Attendant.
Message:
Parameters:
MNARq (Mobile Node AAA Request)
Challenge
User-Name (AVP name which can generate lots of confusion)
MIPv6-Mobile-Node-Address
MIPv6-Home -Agent-Address
MIP-Binding-Update (Home Registration)
MN-DH-PV (MN's Diffie-Hellman public value)
The RPH is also triggered at receiving a response message from the AAAC infrastructure. This is the
response sent by the AAA-h to the MNARq
Message: MNARp.
Message:
Parameters:
MNARp
Session-Id
Result-Code
AAAC.h-MN-AVPs
4.5.2.4 AAAC Protocol Handler
Once the Attendant has received the UDP packets containing the AAA messages, it will send all the
upstream messages using Diameter
ARR.f ::= < Diameter-Header: 0xfff00fff, 0, REQ, PXY >
{ Session-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
{ MN-AAAC.h-AVPs } /* An AVP of type Grouped */
{ Att-DH-PV }
* [ AVP ]
The answer to the above request looks as follows
ARA.f ::= < Diameter-Header: 0xfff00fff, 0, REP, PXY >
{ Session-Id }
{ Result-Code }
{ AAAC.h-MN-AVPs } /* An AVP of type Grouped */
* [ AVP ]
4.5.2.5 Fast handover
The attendant also has an interface to the Fast Handover (FHO) module, which is a kernel space module.
These modules interact with each other to transfer the context from the old access router to the new
access router.
D0103v1.doc 112 / 168

D0103v1.doc Version 1 6.7.2003
Old AR
New AR
User Space
AAA Att.
User Space
AAA Att.
1.
Trigger
ctxTran
FHO Mod.
Kernel
2.
CtxtoFHO
3. Handover Initiate
FHO Mod.
Kernel
4.
CtxtoAtt
Figure 83: FHO module and Attendant interaction during FHO
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 FHOmodule executes the
function “StartCtxTransfer” which contains identification of the message (MesgType) e.g.
StartCtxTransfer, SendctxToAtt or SendctxToFHO and the length of this message
4.5.2.6 Diameter / foreign server
The main functions of a foreign server are to support the mobile users to be able to access the network
from outside their home network. For this purpose the AAAC.f must also support MIP.
Upon receiving an AA Registration Request (ARR.f) message, the AAAC.f: The foreign server then
routes the ARR.f message to the AAAC.h (using proxies or not). The AAA core executes routing using
Realm Routing Table (RRT). The AAAC.f then keeps the info related to this message into the list of
pending requests
The response to ARR is AA Registration Reply (ARA). Upon receiving an ARA message from the
AAAC.h, the AAAC.f: checks / processes the AAA Result-Code and then route it back to the Attendant.
After receiving an answer from the AAAC.h the AAAC.f calls the QoS ASM, that communicates with a
QoS broker.
4.5.2.7 AAAC.h
The AAAC.h supports MIP (as developed for the Moby Dick project) with help of ASM (application
specific module)
After receiving an ARR.f message the mobility ASM checks the MN's NAI, MN's Home IP Addr., Home
Ag. Addr. It further checks the authentication of the AVPs record from the MN. Based on this info, it
decides whether it should allow the MN to use mobile-ipv6 or not. It also selects the SA to be used for
authentication.
4.5.2.8 Home Agent-AAA-Enabler
This is a User-space application implementing an AAA-client. Main functions of this entity are that it
enables the AAAC.h to dynamically allocate HAs (load balancing) and enforce mipv6 policies at the HA.
After receiving HOR (Home Agent Request),: the AAA_HA module checks whether it is good or not;
respond with an appropriate Result-Code AVP and create a DH key and send the public part to the MN as
an AVP in the HOA message. This then sends the reply to the requesting AAAC.h server by using the
HOA (Home Agent Answer) message:
D0103v1.doc 113 / 168

D0103v1.doc Version 1 6.7.2003
4.5.2.9 AAA message flow
This section describes and specifies the message flows. The flows are divided in to request flow and reply
flows. The request flow originate from MN and trans the AAA entities towards the AAA server. Whereas
the reply flow is the response to the request flow and goes towards the MN.
MN
MNARq
Attendant AAA.f AAA.h
ARR.f
ARR
Request flow
MNARp
ARA.f
ARA
Reply flow
Figure 84: AAA message flows
Note, upon the reception of the ARA, the AAAC.f dumps the NVUP (part of user’s profile) to the
QoSB.f. For more details see section: QoS Interface.
4.5.2.9.1 MN to Attendant
When the MN is switched on or after the expiration of the authorization lifetime, the MN communicates
with the attendant to request an access. As Diameter is not used for communication between an MN and
Attendant, the diameter AAA request from the MN must be sent using UDP to the Attendant.
Message:
MNARq (Mobile Node AAA Request)
UDP packet containing an AAA message having the following structure:
Parameters:
Challenge
User-Name
MIPv6-Mobile-Node-Address
MIPv6-Home -Agent-Address
MIP-Binding-Update
MN-DH-PV
MN-MAC
In the following sections the content of the AAA message is listed.
Challenge
The attendant broadcasts the challenge. The format of the Challenge has the following structure.
AVP code: 0xfff00400
Type: Unsigned32
Length: 12 (16 if the 'V' bit is enabled)
Value: The challenge MN has got from the Attendant
User-Name
D0103v1.doc 114 / 168

D0103v1.doc Version 1 6.7.2003
This user name should not be seen as the username in a Unix system. This user name is inferred from the
definition as defined in RFC2486.
Note: It is to be kept in mind that mobile-IP DOES NOT have anything to do with user names
AVP code: 1
Type: UTF8String
Length: Variable
Contains: NAI /* As defined in RFC2486 / The Network Access Identifier */
MIPv6 -Mobile-Node-Address
This address has been specified as it is defined in RFC2486 Diameter Mobile IPv6 Application
AVP code: 0xfff00001 /* TBD in the draft */
Type: IPAddress
Length: 24 (28 with bit V enabled) /* 16 (IPv6 Addr) + 8 (12) (AVP Header) */
Contains: Mobile's Node Home Address
MIPv6 -Home-Agent-Address
This is optional since a Home Agent can be assigned automatically. This also defined in RFC 2486
Diameter Mobile IPv6 Application
AVP code: 0xfff00002 /* TBD in the draft */
Type: IPAddress
Length: 24 (28 with bit V enabled) /* 16 (IPv6 Addr) + 8 (12) (AVP Header) */
Contains: Mobile's Node Home Agent AddressA
MIP-Binding-Update
The Home Registration as defined in RFC2486. This is optional because it is used only in the scenario in
which mobile IP and AAA signalling are combined
AVP code: 0xfff00003 /* TBD in the draft */
Type: OctetString
Length: Variable
Contains: Mobile's Node Home Registration message
MN-DH-PV
Defined by Moby Dick. AVP containing the public value of the MN's Diffie -Hellman key
AVP code: 0xfff00500
Type: OctetString
Length: 128 ( 132 when V is set )
Contains: public value of the MN's Diffie-Hellman key
MN-MAC
Defined by Moby Dick
AVP code: 0xfff00004
Type: OctetString
Length: 16 ( 20 when V is set )
Contains: HMAC-MD5 over the following AVPs:
{Challenge }, { User-Name }, { MIPv6-Mobile-Node-Address }
{ MIPv6-Home-Agent-Address }, { MIP-Binding-Update }
the HMAC-MD5 is computed using SK[MN-AAAC.h]
4.5.2.9.2 Attendant to AAAC.f
Once the Attendant has received the UDP packets containing the AAA messages, it will send all the
upstream messages using Diameter (i.e. over TCP / SCTP).
D0103v1.doc 115 / 168

D0103v1.doc Version 1 6.7.2003
Message:
:Parameter Structure
AA-Registration-Request (ARR.f)
Session-Id
Origin-Host
Origin-Realm
Destination-Realm
Auth-Application-Id
MN-AAAC.h-AVPs
Att-DH-PV
{ Session-Id }
/* Defined in Diameter Base Protocol */
AVP code: 263
Type: UTF8String
Length: variable
Value:
;;[;]
{ Origin-Host }
/* Defined in Diameter Base Protocol */
/* Diameter Base Protocol */
AVP code: 264
Type: DiameterIdentity
Length: Variable
Value: an UTF8String encoding of its FQDN
{ Origin-Host }
/* Defined in Diameter Base Protocol */
/* Diameter Base Protocol */
AVP code: 296
Type: DiameterIdentity
Length: Variable
Value: an UTF8String encoding of its realm
{ MN-AAAC.h-AVPs }
/* Defined by Moby Dick */
/* An AVP of type grouped containing all AVPs that are exchanged btw. */
/* MN and AAAC.h. Main reason for grouping is that there is a MAC computed */
/* over their values */
MN-AAAC.h-AVPs ::= < AVP Header: 0xfff00401 >
{ Challenge }
{ User-Name }
* { MIPv6-Mobile-Node-Address }
* { MIPv6-Home-Agent-Address }
* { MIP-Binding-Update }
* { MN-DH-PV }
< MN-MAC >
{ Att-DH-PV }
/* Defined by Moby Dick */
/* Attendant's DH public value */
AVP code: 0xfff00501
Type: OctetString
D0103v1.doc 116 / 168

D0103v1.doc Version 1 6.7.2003
Length: 128 ( 132 when V is set )
Contains: public value of the Attendant's Diffie-Hellman key
The same kind of AAA messages are exchanged btw. AAAC.f and AAAC.h
4.5.2.9.3 AAAC.h to AAAC.f
Message:
Parameters:
{ Result-Code }
AA Registration Answer (ARA)
Session-Id
Result-Code
Origin-Host
Origin-Realm
Auth-Grace-Period
AAAC.h-MN-AVPs
/* Defined in */
AVP code: 268
Type: Unsigned32
Contains: IANA-managed 32-bit address space representing errors.
{ Auth-Grace-Period }
/* Defined in */
AVP code: 276
Type: Unsigned32
Contains: a value that implies the maximum length of the session the home realm is willing to be fiscally
responsible for
AAAC.h-MN-AVPs ::= < AVP Header: 0xfff00402 >
{ User-Name }
{ Authorization-Lifetime }
{ Session-Timeout }
* { MIPv6-Mobile-Node-Address }
{ HA-DH-PV }
* { Att-DH-PV }
< AAAC.h-MAC >
{ Authorization-Lifetime }
/* Defined in Diameter Base Protocol */
AVP code: 291
Type: Unsigned32
Contains: session life time in secs (>= with the BU lifetime req. from the HA)
{ Session-Timeout }
/* Defined in */
AVP code: 27
Type: Unsigned32
Contains: the maximum number of seconds of service to be provided to the user before termination of the
session
< AAAC.h-MAC >
/* Defined by Moby Dick */
AVP code: 0xfff00005
Type: OctetString
Length: 16 ( 20 when V is set )
Contains: HMAC-MD5 over the following AVPs:
{Challenge }, { User-Name }, { MIPv6-Mobile-Node-Address }
D0103v1.doc 117 / 168

D0103v1.doc Version 1 6.7.2003
{ MIPv6-Home-Agent-Address }, { MIP-Binding-Update }
the HMAC-MD5 is computed using SK[MN-AAAC.h]
4.5.2.9.4 AAAC.f to Attendant
Message:
Parameters:
AA Registration Answer foreign (ARA.f)
Session-Id
Result-Code
AAAC.h-MN-AVPs
4.5.2.10 Attendant to MN (UDP message)
Message:
Parameters :
4.5.3 Accounting DB
Mobile Node AAA Reply (MNARp)
Session-Id
Result-Code
AAAC.h-MN-AVPs
A session, that has been started after a successfully authentication and authorization, must also be
accounted for. Several AAA entities are involved in accounting e.g. attendant, AAAC.f, AAAC.h.
4.5.3.1 AAAC Client
The AAAC Client receives answers from AAAC.f for issued AA requests. In case of a negative answer
the answer is forwarded to the meter client (as usual) and no accounting takes place.
In case of a positive answer the AAAC client configures its accounting functionality according to the
accounting policies contained in the AA answer. If no such policies are present it configures accounting
according to a default configuration specified before starting the client. Accounting is configured before
the answer is forwarded to the client. If some error occurs it is open what happens. Possible solutions are:
• The AAAC client forwards answer to the meter client, session takes place as usual (may be no
accounting or missing accounting data)
• The client sends a message to AAAC.f, AAAC.f can try to get around the problem in which case the
client forwards the positive reply. In the other case it forwards the negative reply.
In the implementation the first option will be preferred and used.
After forwarding the AA answer the client immediately generates an accounting start request and sends it
to the AAAC.f.
During a session runtime the client generates interim accounting messages and sends them to AAAC.f.
If the client receives a session stop indication it generates an accounting stop request and sends it to the
AAAC.f.
The AAAC client has an interface to the metering functionality on the access router. It sends a
METER_START message containing a filter spec and all other configuration parameters when
accounting is started. It may receive a handle from the metering function. It sends a METER_STOP
message containing a filter spec or handle previously received to stop metering for that particular session.
The following information is needed as filter:
• mobile nodes IP address (CoA)
• mobile nodes ports (in case of specific QoS sessions which are flow based) (known through specific
AA request from MN).
• DSCP (either 0 for registration or specific value for QoS session; note that signalling traffic between
MN and AR is supposed to have DSCP!=0 so this traffic is not accounted which is intended).
The AAAC client must have a function to retrieve meter data for a particular session. A
GET_METER_DATA function must be supported by the metering which accepts CoA or handle and
return all current accounting information for a particular MN.
The meter data could also be stored in a DB as long as there is a logic that can handle the
GET_METER_DATA function and deliver requested data.
D0103v1.doc 118 / 168

D0103v1.doc Version 1 6.7.2003
4.5.3.2 Accounting Messages
4.5.3.2.1 The Accounting-Request (ACR)
The Accounting-Request (ACR) command, indicated by the Command-Code field set to 271 and the
Command Flags' 'R' bit set, is sent by a Diameter node (AR), acting as a client, in order to exchange
accounting information with a peer (AAA server).
::= < Diameter Header: 271, REQ, PXY >
< Session-Id >
{ Acct-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Accounting-Record-Type }
{ Accounting-Record-Number }
[ User-Name ]
[ Accounting-Sub-Session-Id ]
[ Accounting-RADIUS-Session-Id ]
[ Accounting-Multi-Session-Id ]
[ Accounting-Interim-Interval ]
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy -Info ]
* [ Route-Record ]
Session-Id is the session ID generated by the client at the time sending the AA request. Acct-Application-
Id is the IANA assigned identifier.
Origin-Host: Originator of the Diameter message
Origin-Realm: Realm of the originator
Destination-Realm: Destination realm (real of AAAC.h)
Accounting-Record-Type: start, stop or interim
Accounting-Record-Number: Unique number which identifies acc rec within one session starting with 0
for acc start record
The AAAC client may include:
User-name, interim interval,
The Accounting-Interim-Interval will set to a value equal to 3 minutes.
4.5.3.2.2 The Accounting-Answer (ACA)
The Accounting-Answer (ACA) command, indicated by the Command-Code field set to 271 and the
Command Flags' 'R' bit cleared, is used to acknowledge an Accounting-Request command. The
Accounting-Answer command contains the same Session-Id and MAY contains the same Accounting
Description and Usage AVPs that were sent in the Accounting-Request command. If the CMS-Data AVP
was present in the Accounting-Request, the corresponding ACA message MUST include the CMS-Data
AVP signed by the responder to provide strong AVP authentication, which MAY be used for the purposes
of repudiation.
Only the target Diameter Server, known as the home Diameter Server, SHOULD respond with the
Accounting-Answer command.
::= < Diameter Header: 271, PXY >
< Session-Id >
{ Acct-Application-Id }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Accounting-Record-Type }
{ Accounting-Record-Number }
[ User-Name ]
[ Accounting-Sub-Session-Id ]
D0103v1.doc 119 / 168

D0103v1.doc Version 1 6.7.2003
[ Accounting-RADIUS-Session-Id ]
[ Accounting-Multi-Session-Id ]
[ Error-Reporting-Host ]
[ Accounting-Interim-Interval ]
[ Origin-State-Id ]
* [ AVP ]
* [ Proxy -Info ]
4.5.3.3 The Accounting Information
ACR and ACA contain AVPs containing accounting information. The information is described in the
following section. The following specifications have been done:
Accounting-Input-Octets AVP
The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64, and contains the number of
octets in IP packets received from the user.
Accounting-Output-Octets AVP
The Accounting-Output-Octets AVP (AVP Code 364) is of type Unsigned64, and contains the number of
octets in IP packets sent to the user.
Acct-Session-Time AVP
The Acct-Time AVP (AVP Code 46) is of type Unsigned32, and indicates the length of the current
session in seconds.
Accounting-Input-Packets AVP
The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64, and contains the number of IP
packets received from the user.
Accounting-Output-Packets AVP
The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64, and contains the number of IP
packets sent to the user.
Since we support different QoS classes we need an additional AVP
DSCP AVP
The DSCP AVP is of type unsigned8 and contains the Diffserv Code Point of the session.
An accounting message can contain accounting data for more than one QoS class. The following grouped
AVP is used:
QoS-Class-Acct-Data ::= < >
{DSCP AVP}
{Accounting-Input-Octets AVP}
{Accounting-Output-Octets AVP}
{Acct-Session-Time AVP}
{Accounting-Input-Packets AVP}
{Accounting-Output-Packets AVP}
One or more of these grouped AVPs can appear in a Diameter accounting message.
D0103v1.doc 120 / 168

D0103v1.doc Version 1 6.7.2003
MN
Meter
Attendant/
AAAC client
AAAC.
1
2
3
4a
4 5
6
7
8
9
10
Figure 85: Accounting MSC
The following table specifies the messages, describes parameters and content and allows remarks.
No.
Message Content / Parameters Remarks
1
AA request
usr:pwd@domain; BU
2 AA reques t usr:pwd@domain; BU
3 AA response 2x key(MN, AR), Profile SubSet, BACK
4 Start_Meter CoA, accounting type e.g. [bytes] per DSCP
service class
4a Allow_User_Access
5 ACR 4.5.3.2.1 The Accounting-Request (ACR)
6 ACA 4.5.3.2.2 The Accounting-Answer (ACA)
7 Get_Meter_Value volume, DSCP
8 Send_Meter_Value volume, DSCP
9 ACR 4.5.3.2.1 The Accounting-Request (ACR)
10
ACA
4.5.3.2.2 The Accounting-Answer (ACA)
Table 22: Accounting Messages and their content
4.5.4 Charging Module
Charging calculates the price for a given service consumption based on session and accounting
information. It maps technical values into monetary units, and therefore applies a given contractual
agreed upon tariff. The tariff applied might depend on QoS parameters as well as timely dependent
parameters, e.g. time of the days, days of the week a service is invoked. The tariff for a particular session
is assumed to be static during that session.
If the user stays in a foreign domain (i.e. roaming) then the accounting data could basically be stored in an
accounting database located in AAAC.f or AAAC.h. Furthermore the charging could be done either in
AAAC.f or AAAC.h. Within Moby Dick, all accounting data is stored in an accounting database located
at the AAAC.h only (home domain). This implies that the charging component is located in the home
domain, too. In the case of roaming, accounting data is flowing from the foreign to the home domain. Of
D0103v1.doc 121 / 168

D0103v1.doc Version 1 6.7.2003
course, the accounting data needs to contain information about roaming, in order to allow the charging
component selecting different tariffs (i.e. roaming tariffs).
4.5.4.1 DIAMETER Messages vs. Entries in the Accounting Database
In this context, three kind of DIAMETER messages are of interest: “start”, “interim” and “end” messages.
When a session starts, the DIAMETER “start” message will add the first row of the current session to the
accounting database. This first row is mandatory. Section 0 describes in details how the parameters have
to be defined. When a session is running, DIAMETER “interim” messages are being generated. When a
session ends, a DIAMETER “end” message will be generated and the last row for this current session will
be added to the accounting database. This last row is mandatory like the first row.
It is important that the accounting database is consistent! It’s up to the accounting system, to ensure the
consistency. Therefore, accounting for the current session x has to produce the following entries in the
accounting database:
“start” message => first row for session x
“interim” messages
“end” message => last row for session x
Therefore, accounting for a session x, will at least yield to two rows in the accounting database 1 .
4.5.4.2 Sessions
Moby Dick uses the concept of sessions. The next subsections give some more details about the (Moby
Dick) session concept. In general, each session is defined with a unique session ID and is associated with
a user.
Note: It is possible that a user can have more than one open session.
4.5.4.2.1 Start of a Session
A session can start after the following two events:
1. A user switches on his MN and requests authentication and authorization. After successfully
passing AA, the user will be associated with a session ID.
2. A user moves from one AR to another, i.e. handover takes place. The “new” AR will associate a
new session ID to the user.
3. A new user logs in a MN.
All events will yield to a DIAMETER “start” message and will eventually define the first row of a session
in the accounting DB.
Note: When the user starts a new application (e.g. VoIP) within a current session, then there will be new
flows set up (with certain DSCP values), but not a new session.
It is possible that two different applications generate flows with the same DSCP values; therefore it is not
possible to conclude from an observed flow (i.e. the accounting data in the DB) to a certain application.
4.5.4.2.2 Termination of a Session
A session will be terminated after the following three events:
1. A user switches off his MN.
2. A user moves from one AR to another, i.e. handover takes place. The “old” session from the
previous AR has to be closed.
3. The lifetime of a session is reached, cf. section 4.5.4.2.4.
All events will yield to a DIAMETER “end” message and will eventually define the last row of a session
in the accounting DB.
It is important to note that only closed sessions will be used for the charging process, cf. section 4.5.4.2.5.
1 If the duration of a session is shorter than the interval of diameter „interim“ messages then the accounting DB will
contains only two rows.
D0103v1.doc 122 / 168

D0103v1.doc Version 1 6.7.2003
4.5.4.2.3 Re-Authentication, “Authorization-Lifetime”
After 5 minutes the RE-authentication takes place. The session and hence the sessionID will not change.
4.5.4.2.4 Duration of a Session, “Session-Lifetime”
Each session is associated with a lifetime, which is defined during the AA-phases. The correspondent
DIAMETER Parameter (“Session-Lifetime”) has to be set to a reasonable value. In Moby Dick, this
lifetime will be set to 30 minutes, as it is the case in the GSM standard. After expiring, the AAAC client
must generate a DIAMETER “end” message with the according entry in the accounting DB—since the
current session is terminated and the user is disconnected.
4.5.4.2.5 Charging of “open” Sessions
As described in the section 5.2.6.1, the CC will contact the accounting database periodically. All open
sessions—i.e. sessions without the last mandatory row (the one generated after a DIAMETER “end”
message)—are not used for the charge calculation. It is important to note, that all open sessions need to be
closed finally.
If—due to an error or failure —DIAMETER “end” messages are missing in the accounting DB, then the
AAAC home server has to create the “end” row, i.e. it needs to close the open session.
When the AAAC server is started or restarted it checks whether all sessions have an “end” entry and if
not generates one from the latest entry. This latest entry can be an “interim” or “start” message. The first
case is an indication of lost “interim” messages—the AAAC home server can simply duplicate the last
“interim” message belonging to the open session. The latter case indicates that only the DIAMETER
“start” message was written to the accounting DB. And hence, only “null” values were written to the DB
for this session. In this case the AAAC home server will also duplicate this “start” message and will
generate the “end” message, which will of course contain “null” values only. The CC can detect such
“null” sessions in the charging process and ignores them.
4.5.4.2.6 Definition of Session ID
The session ID is generated in the AR (by the AAAC Client) and has the following structure:
;
An example is: “access-router1.ethz.ch;1234” 2
For a detailed description, see section 4.5.4.5.1.2.
The domain part of the session ID (e.g. “ethz.ch”) is used to compare with the user home domain FQDN
(cf. section 4.5.4.5.1.1) to check for roaming.
4.5.4.2.7 Time Synchronization
The AAAC clients are responsible to generate the session ID and the timestamps of the DIAMETER
messages (cf. section 4.5.4.5.2). Within one domain all AAAC clients and the AAAC server (home or
foreign) should use a synchronized clock. This synchronization is achieved by NTP. Each domain has an
NTP server and the AAA machines have NTP clients installed with synch with the server).
4.5.4.2.8 Counters
The accounting and charging component will rely on counters per session, i.e. absolute counters. Table 23
shows an example of an accounting DB, containing rows for one session (not all MySQL columns are
shown). In the example we made the assumption that DIAMETER “interim” messages are generated after
constant interval (3 minutes).
… EventTime SessionTime AccType BytesToUser …
… 2003-01-12 22:40:00 0 “start” 0 …
… 2003-01-12 22:43:00 180 “interim” 250 …
… 2003-01-12 22:46:00 360 “interim” 259 …
… 2003-01-12 22:48:00 480 “stop” 478 …
2 “1234” is a decimal value.
Table 23: The accounting DB: Use of counters in a session
D0103v1.doc 123 / 168

D0103v1.doc Version 1 6.7.2003
4.5.4.2.9 Interval of “interim” messages
In Moby Dick, DIAMETER “interim” message are being generated after every 3 minutes 3 .
4.5.4.3 DSCP Values
In Moby Dick, each service is associated with bandwidth and priority. This two values will be mapped to
a DSCP value. This mapping is fixed and must not be changed later on. The DSCP value will be used to
select the tariffs. There needs to be a mapping from DSCP values to services (with a certain QoS).
Within Moby Dick we can make the assumptions, that this mapping is static and no services are added
later on. Of course, in a general environment this assumption could not be made.
The DSCP field consists of 6 Bits and is present in every header of an IP packet. Due to implementation
reasons, the DSCP values will be stored in different data types, cf. Table 24.
DSCP Format in
# Bits
Values of Bits
0 1 2 3 4 5 6 7 8 – 15 16 – 31
Meter Component 16 1 2 3 4 5 6 x x x – x –
Accounting Database 32 1 2 3 4 5 6 x x x – x x – x
Charging Database 8 1 2 3 4 5 6 x x – –
Table 24: Representation of DSCP Values; DSCP Bits marked in yellow; “x” are don’t cares
Table 25 shows the mapping from services to DSCP values. It is possible that two different applications
generate flows with the same DSCP values; therefore it is not possible to conclude from an observed flow
(i.e. the accounting data in the DB) to a certain application.
Name
Service
Class
Relative
Priority
Service parameters
Service
Description
DSCP
(binary)
DSCP
(decimal)
S1 EF 1 Peak BW: 32 kbit/s Real time services
101110 46
SIG AF41 2 Unspecified IP signalling only 100010 34
S2 AF21 3 CIR: 256 kbit/s Priority (urgent) data
transfer
S3 AF1* 4 Three drop
precedences (kbit/s):
AF11 – 64
AF12 – 128
AF13 – 256
S4 BE 0 Peak bit rate: 32
kbit/s
S5 BE 0 Peak bit rate: 64
kbit/s
S6 BE 0 Peak bit rate: 256
kbit/s
4.5.4.3.1 Alternatives after charge calculation
Olympic service
(better then BE:
streaming, ftp, etc)
Table 25. Mapping of Services to DSCP values.
010010 18
001010
001100
001110
Best effort 000000 0
Best effort 000010 2
Best effort 000100 4
After the accounting data was used by the charging component, it needs to be marked as “used”.
After this marking of accounting data, there exist two alternatives:
10
12
14
3 There is no scientific reason to set this value to 3 minutes. If it is too small (e.g. 10 seconds) then the accounting DB
would get too big.
D0103v1.doc 124 / 168

D0103v1.doc Version 1 6.7.2003
After marking, the data is left in the accounting database. The problem here is , that after a certain amount
of time the database will be very huge, and the processing time of each database query (or modification)
will get very slow.
After marking, the used data is moved to another database. With this approach, the processing time will
remain more or less constant.
The CC supports the latter proposal: After being used for charging purposes, the accounting data will be
moved to an accounting data warehouse, cf. section 4.5.4.9.
4.5.4.4 Overview of Databases
Figure 86 shows the overview of all Databases in use. All Databases are based on MySQL.
accountingrecords
accountingrecords
AccID, primary key
ID , primary key
Accounting
flows
AccDataWarehouse
flows
FTID, primary key
AccID, foreign key
ID , primary key
AccID, foreign key
chargingrecords
CharginID, primary key
Charging
chargingrecordsdetails
ID, primary key
ChargingID, foreign key
Customer
userprofiles
Figure 86: Overview of Databases
4.5.4.5 Representation of Accounting Data in the MySQL database
The accounting component will write its (accounting-) data in a MySQL database. The charging
component will then pull the data periodically. Table 26 gives an overview of the DIAMETER
parameters and their correspondent MySQL column names. Table 27 describes the main accounting table,
containing the basic accounting information. In the Moby Dick project, there could be more then one flow
per direction. Therefore the detailed information on flows is written into a second (MySQL) table, see
Table 28.
DIAMETER-
Parameter
Name
DIAMETER
Data Type
MySQL
Column Name
MySQL
Data Type
- - AccID INT UNSIGNED, auto_increment
User-Name UTF8String UserID VARCHAR (255)
(Max. 2^8 – 1 Characters)
Session-ID UTF8String SessionID VARCHAR (255)
(Max. 2^8 – 1 Characters)
Accounting-
Session-Time
Unsigned32 SessionTime INT UNSIGNED
(32 Bit Unsigned)
Event-
Time EventTime DATETIME
Timestamp
Accounting-
Record-Type
Enumerated AcctType ENUM(“start”, ”interim”, “stop”,
“event”)
– – DataUsed TINYINT UNSIGNED
D0103v1.doc 125 / 168

D0103v1.doc Version 1 6.7.2003
(Value 0 to 255)
Accounting.-
Input-Octets
Unsigned64 BytesToUser BIGINT UNSIGNED
(64 Bit Unsigned)
Accounting-
Input-Packets
Unsigned64 PacketsToUser BIGINT UNSIGNED
(64 Bit Unsigned)
DSCP Unsigned32 DSCP TINYINT UNSIGNED
(Value 0 to 255)
Accounting-
Output-Octets
Unsigned64 BytesFromUser BIGINT UNSIGNED
(64 Bit Unsigned)
Accounting-
Output-Packets
Unsigned64 PacketsFromUser BIGINT UNSIGNED
(64 Bit Unsigned)
Table 26. Comparison of DIAMETER parameters and MySQL data types
All other DIAMETER parameters shall not be saved in this MySQL Database, since they are not used by
the charging component and would only occupy place.
The accounting information about flows is as general as possible. Therefore it is possible that the flows
from and to the user (from the user’s point of view) can contain different DSCP values.
Table 27 describes all data types that will be needed by the charging component.
MySQL
MySQL
Example
Remarks
Column Name Data Type
AccID INT UNSIGNED Primary key,
auto_increment
UserID VARCHAR (255) hans.muster@abc.com Must be globally unique
(Max. 2^8 – 1
Characters)
SessionID VARCHAR (255) Exact structure see Must be globally unique
(Max. 2^8 – 1
Characters)
4.5.4.5.1.2
SessionTime INT UNSIGNED
(32 Bit Unsigned)
1350 Duration of current session,
measured in seconds.
EventTime DATETIME 2002-12-31 22:40:11 Time when the record was
AcctType
DataUsed
ENUM(“start”,
”interim”, “stop”,
“event”)
Start
generated.
Defines whether the entry
is from a start, interim or
end accounting request
TINYINT
UNSIGNED
(Va lue 0 to 255)
0 or 1 If a row was used for
charging, then the value of
this parameter is set to 1
otherwise the value will be
0.
Table 27. First MySQL table “accounting records”
MySQL MySQL
Remarks
Column Name Data Type
AccID INT UNSIGNED Foreign key from table
“accountingrecords”
FTID INT UNSIGNED Primary key,
auto_increment
BytesToUser BIGINT UNSIGNED
(64 Bit Unsigned)
PacketsToUser BIGINT UNSIGNED
(64 Bit Unsigned)
DSCP
TINYINT
UNSIGNED
(Value 0 to 255)
BytesFromUser BIGINT UNSIGNED
(64 Bit Unsigned)
D0103v1.doc 126 / 168

D0103v1.doc Version 1 6.7.2003
PacketsFromUser BIGINT UNSIGNED
(64 Bit Unsigned)
Table 28. Second MySQL table “flows” for detailed information on flows.
4.5.4.5.1 Detailed Descriptions of Parameters
4.5.4.5.1.1 UserID
For the UserID the NAI format is used. The UserID has the following structure:
@
An example UserID is “fred@bco.com”.
The FQDN contained in the UserID can be compared with the FQDN contained in the sessionID to find
out whether the user is roaming or not. The UserID will be used as a key to select data from the database,
therefore each row in the table must contain the UserID.
MySQL data type
VARCHAR (255)
(Max. 2^8 – 1 Characters)
4.5.4.5.1.2 SessionID
As described in section 4.5.4.1, the accounting components will generate n rows of accounting data for
each session. If the session duration is shorter than the “interim” interval, then a completely accounted
session will consist only of two rows. Otherwise there will be several “interim” rows between the “start”
and “end” row.
Therefore a complete accounting for one session, consists of n rows, where n is greater or equal to two.
Details:
The exact structure of the sessionID is the following:
;
An example is: “access-router1.ethz.ch;1234”
Value
Rows (in the same session)
SessionID 1. – n.
Table 29: Session ID
The 64bit numeric ID uniquely identifies the session at the AAA client. The AAA client can generate it
by just monotonically increase a session counter. The 64bit ID should be spitted into lower and higher
32bit for transfer encoding:
:;

D0103v1.doc Version 1 6.7.2003
MySQL data type:
INT UNSIGNED
(32 Bit Unsigned)
4.5.4.5.2 EventTime
0 1.
Session time at the time the 2. – n.
record was generated in
seconds
Table 30: Session Time Details
In order to support “a time of the day” tariff scheme, each record contains the timestamp of its generation.
Thus the first record contains the start time of the session and the last record contains the end time of the
session. Within the Moby Dick project the time base will be CET.
Details:
MySQL data type:
DATETIME
4.5.4.5.2.1 BytesToUser
Value
Rows (in the same session)
Start time of session and date 1.
Time of interim record 2. – n-1
End time of session n.
Table 31: Event Time
This parameter measures the number of bytes sent to the user (i.e. downstream) from the user’s point of
view. The first row of a session in the accounting DB (“start” row), will contain only “null” values. The
counter is an absolute number from the start of the session. Thus the final amount will be in the n. row
which is the row generated by the DIAMETER “end” message.
Details:
MySQL data type:
INT UNSIGNED
(32 Bit Unsigned)
4.5.4.5.2.2 PacketsToUser
Value
Rows (in the same session)
BytesToUser 1. – n.
Table 32: Bytes To User
This parameter measures the number of packets sent to the user (i.e. downstream) from the user’s point of
view. The first row of a session in the accounting DB (“start” row), will contain only “null” values. The
counter is an absolute number from the start of the session. Thus the final amount will be in the n. row
which is the row generated by the DIAMET ER “end” message.
Details:
MySQL data type:
INT UNSIGNED
(32 Bit Unsigned)
Value
Rows (in the same session)
PacketsToUser 1. – n.
Table 33: Packets To User
D0103v1.doc 128 / 168

D0103v1.doc Version 1 6.7.2003
4.5.4.5.2.3 DSCP
Each flow is associated with a DSCP-Field. In general, there will be at least one flow from the user and
one to the user. In Moby Dick flows occur always pair wise—one flow to and one flow from the user.
Such a pair of flows has always the same DSCP value. Therefore only one DSCP field is needed.
Within one session there can be an unlimited number of such pair wise flows.
Details:
MySQL data type:
TINYINT UNSIGNED
(Value 0 to 255)
4.5.4.5.2.4 BytesFromUser
Same case as “ToUser”
4.5.4.5.2.5 PacketsFromUser
Same case as “ToUser”
4.5.4.5.2.6 AcctType
Value
Rows (in the same session)
DSCP 1. – n.
Table 34: DSCP
This column defines the type of record: start, interim and end row. This field is used to verify that the
session has been closed before calculation of the charges. The column is defined as enumeration
ENUM(“start”, ”interim”, “end”) .
Details:
4.5.4.5.2.7 DataUsed
Value
Rows (in the same session)
“start”, “interim”, “stop” 1. – n.
Table 35: AccType
This is column that must not be changed by the accounting component. The charging component will use
it for marking a row that has been used for charge calculation. After marking it might be useful to move
the row to a separate database – this move operation will be issued by the charging component. This way,
the accounting database doesn’t get to big.
Details:
MySQL data type:
TINYINT UNSIGNED
(Value 0 to 255)
4.5.4.6 Locking of Accounting Database
Value
Rows (in the same session)
0 or 1 1. – n.
2 to 255 Reserved for future use
Table 36: Data Used
Single updates to the accounting DB are atomic. As the accounting DB consists of two tables—cf. Table
27 and Table 28—it is possible that the CC could access an incomplete or inconsistent entry. Therefore
the AAAC server has to lock the tables until the complete data of an accounting message has been
updated. The locking will be realized by putting MySQL write locks on both tables for the time of the
update. A MySQL write lock prevents read and write access to the tables by any other process.
D0103v1.doc 129 / 168

D0103v1.doc Version 1 6.7.2003
4.5.4.7 Charging Database
The charging DB consists of two MySQL tables, cf. Table 37 and Table 38. The first one consists of
charging information for one session, i.e. each session of an user will is represented by one row in this
table. The second MySQL table holds additional information of each session, e.g. it contains information
about the DSCP (i.e. the service) the customer was using.
MySQL
MySQL
Example
Remarks
Column Name Data Type
ChargingID INT UNSIGNED Primary key,
auto_increment
UserID VARCHAR (255) hans.muster@bco.com Must be globally unique
(Max. 2^8 – 1
Characters)
SessionID VARCHAR (255) Exact structure see
Must be globally unique
(Max. 2^8 – 1
Characters)
4.5.4.5.1.2
Charge FLOAT Charge in Euros for this
Domain VARCHAR (50)
(Max. 50
Characters)
SessionTime
INT UNSIGNED
(32 Bit Unsigned)
“foreign”
session.
Indicate the domain where
the services were
consumed: “home” or
“foreign”. Note: It does
not contain the domain
name!
1350 Duration of this session,
measured in seconds.
Table 37: First MySQL table “chargingrecords” containing charge-information for a Session.
MySQL MySQL
Remarks
Column Name Data Type
ID INT UNSIGNED Primary key, auto_increment
ChargingID INT UNSIGNED Foreign key from table
“chargingrecords”
BytesToUser BIGINT UNSIGNED (64 Bit Unsigned)
DSCP TINYINT UNSIGNED (Value 0 to 255)
BytesFromUser BIGINT UNSIGNED (64 Bit Unsigned)
Charge FLOAT Charge in Euros for consuming
services with this DSCP value.
Table 38: Second MySQL table “chargingrecordsdetails” containing detailed charge-information of a
Session.
4.5.4.8 User-profiles Database
The User-profile with its databases is described in section 4.5.1.
4.5.4.9 Accounting Data Warehouse
The table definitions and exactly the same as for the accounting DB, cf. section 4.5.4.5.
4.5.4.10 Error Handling and Failure
After the accounting for one session is finished, there must be the following rows in the accounting
database:
The first row that was created with “DIAMETER start message”
(One or more rows that were generated with “DIAMETER interim messages”) 4
The last row that was created with “DIAMETER end message”
The charging component will only use closed sessions, i.e. sessions containing the last message, cf.
section 4.5.4.2.5. Due to failure of one or several components, it might happen that one or more rows are
4 Only present, if the duration of the session is longer than the „interim“ interval.
D0103v1.doc 130 / 168

D0103v1.doc Version 1 6.7.2003
missing in the accounting database. It is important to note that the accounting data has to be consistent
and complete. Completer in the sense that all open session are eventually closed. The accounting
components are responsible for a consistent and complete accounting database.
Basically, information 5 is lost only when n consecutive “interim” accounting messages are lost until and
including the “end” message of the session. If only “interim” messages are lost, but the “end” message is
correct, then accounting is correct as well. This is because the counters produced from one session at one
AR are absolute—i.e. the lost of DIAMETER “interim” messages is not a problem as long as the
DIAMETER “end” message is correctly written to the accounting database.
4.5.4.11 Implementation of the Charging Component
The charging component is realized by using a web server and JSP’s. The main calculation is done in a
small java module located at the web server. The next figure depicts the overall architecture as well as the
message flows.
The users can login and view their charges that have been accumulated so far. The user communicates
through a web-browser with the web server; this connection can be IPv6, if the user is running an IPv6
capable browser.
The “Moby Dick”-operator on the other can also login via a web-browser, but has more and advanced
possibilities, for instance it can trigger manually the “accounting to charging” process.
Accounting DB
Datawarehouse
Customer DB
Charging DB
New
Accounting
Data
copying of processed data
Datawarehouse
Customer
profile
Charging
Data
Addi ng chargi ng data
Readi ng new accounting Data
Webserver
Accounting to charging
Checking consistency of all
databases
Reading customer profile
Looking up customer data
Looking up charging data of customer
Star ting
Triggering; either
manualy or automatically
Accounting2charging.jsp
cal li ng
Charging report
(JSP)
Charge Servlet, calculates
volume based charges.
Figure 87. Implementation Overview
4.5.5 QoS Interface
4.5.5.1 Purpose and architecture
The QoS Interface is used by the AAAC.f to dump, upon the arrival of a positive ARA, part of the user
profile, the NVUP, to the QoSB.f. The NVUP has a TTL equal to Authorization Life time of the
DIAMETER Session.
Upon its initialization, the AAAC.f provides the QoSB.f with a description of the NetServices within this
domain. To do so, the AAAC.f also uses the QoS Interface.
5 Information is seen here from point of view of the charging component.
D0103v1.doc 131 / 168

D0103v1.doc Version 1 6.7.2003
In Moby Dick, the AAAC System uses DIAMETER protocol and the QoS System employs COPS
protocol. To make the interaction possible between those two Systems (in particular between the AAAC.f
and the QoSB.f), the QoS-ASM presents two interfaces as depicted in Figure 88.
AAAC server source code
Uses
API: AuthorizeProfile();
SendNetServicesDescr ();
connectBB();
disconnectBB();
ASM
COPS Client
COPS messages
QoSB.
Figure 88: QoS ASM interfaces
4.5.5.2 Description of the C API interface to the AAAC.f Server
The C API consists of two structures and 4 functions. The two structures are used to fill the NVUP. The
functions are described hereafter:
AuthorizeProfile(), used upon a positive ARA to dump the NVUP (part of the user profile) to the QoSB.f.
We provide the function the NVUP.
SendNetServicesDesc() must be called once before any operation. It sends the QoSB.f the meaning (in
terms of IpDest Address –optional-, B.W., burst size and priority) of the DSCPs employed within the
domain. Reads this data from a given file. The contents of this file are represented bellow:
Destination
address
Traffic’s
BW (kbps)
Burst size
(Bytes)
Priority DSCP
(hex)
::0 1 1514 2 0x22
::0 32 1514 1 0x2e
::0 256 1514 3 0x12
::0 64 1514 4 0x0a
::0 128 1514 4 0x0c
::0 256 1514 4 0x0e
::0 32 1514 0 0x00
::0 64 1514 0 0x02
::0 256 1514 0 0x04
Table 39: DSCP - Service Provisioning in Moby Dick
These contents are in conformance with the NetServices table defined in Moby Dick.
ConnectBB(). This function must be called once and before any call to any other function.
DisconnectBB(). This function ends the COPS connection to the B.B. Called at the end of the program in
the AAAC.f.
The calling order of this functions is represented in Figure 89.
We stress that this 4 functions and the two mentioned structures is the only part of the QoS ASM visible
to the AAAC.f.
D0103v1.doc 132 / 168

D0103v1.doc Version 1 6.7.2003
ConnectBB()
Opens cops connection
SendNetServicesDesc()
Reads from file and exchanges COPS
messages
AuthorizeProfile()
Creates COPS message and sends it
DisconnectBB()
Closes cops
connection
Figure 89: Usage cycle of the QoS ASM
4.5.5.3 Description of the COPS Client interface to the QoSB.f
We list now the COPS messages exchanged between the COPS client interface of the ASM and the
QoSB.f, the COPS server.
To open the COPS connection –using ConnectBB()- COPS Client-Open and Client-Accept messages
with no optional cops objects are exchanged. The AAAC server client type is 65283 (in decimal).
To close the COPS connection –using DisconnectBB()- we send a COPS ClientClose Message with no
optional cops objects.
To send the NetServices Description –using the SendNetServicesDesc() function- to the QoSB.f a
REQuest message is sent with optional cops “Client Specific Information Objects”. The format of these
objects (and of the entire REQuest message) is given below. The QoSB.f answers to this message with a
DECission message with no optional COPS objects.
Format of the REQuest message (fields length is in bytes):
D0103v1.doc 133 / 168

D0103v1.doc Version 1 6.7.2003
common
#1
Ver 1 Flg 0 Op. code 1 Client Type: 0xFF03
Message length: 52+N*28 (bytes)
Object length: 8 C-Num 1 C-Type 1
Handle
Object length: 8 C-Num 2 C-Type 1
R-Type 2
M-Type
Object length: 28 C-Num 9 C-Type 131
Struct in6_addr dest. Addr.
BW
Burst Size
priority DSCP Padding 00 00
Object length: 28 C-Num 9 C-Type 131
#N
struct in6_addr dest. Addr
BW
Burst Size
Priority DSCP Padding 00 00
When dest. Addr is not used it is filled with 0.
AuthorizeNVUP(); Sends a REPort State message.
Figure 90: Request Message
To dump the NVUP, we send a REPORT STATE message –using the AuthorizeProfile() function- with
optional cops “Client Specific Information Objects”. The format of these objects (and of the entire
REPORT STATE message) is given below.
Format of the REPort message (fields length is in bytes):
Ver 1 Flg 0 Op. Code 3 Client Type: 0xFF03
Message length: 24+24+24*(N-1) (bytes)
Object length: 8 C-Num 1 C-Type 1
Handle
Object length: 8 C-Num 12 C-Type 1
Report-Type: 8
0x0000
Object length: 24 C-Num 9 C-Type 129
#1
struct in6_addr CoA
TTL
Object length: 24 C-Num 9 C-Type 138
#2
in6_addr dest. Addr
DSCP Padding 00 00 00
When dest. Addr is not used it is filled with 0.
Figure 91: Report Message
D0103v1.doc 134 / 168

D0103v1.doc Version 1 6.7.2003
4.5.6 Auditing
Auditing objectives need to be determined in advance in order to be able to specify the auditing and
logging requirements. Auditing requirements determine what tasks to be accomplished to meet the
auditing objectives, whereas logging requirements determine which events need to be logged by whom
and when. The auditing objective of MobyDick is to detect violation of Service Level Guarantees (SLGs)
between a customer and a provider. An SLG is the part of Service Level Agreement (SLA) which
specifies a provider’s commitment on quality level of services it will deliver.
Furthermore it is assumed that MobyDick auditing objectives do NOT include following goals:
• Detection of security breaches
• Detection of failure in design and implementation of MobyDick entities
• Detection of AAAC’s policies violation. AAAC policies represent the provider’s policies in
determining the behavior of AAAC entities in performing authentication, authorization,
accounting, and charging.
It is important to note here, that security breaches, failure in design and/or implementation, and policies
violation may lead to SLG violation.
4.5.6.1 MobyDick SLG
A MobyDick Service Level Agreement (SLA) reflects the contract between a customer and MobyDick
service provider. This section does not describe the whole detail of SLA, but only the guarantees
specified within an SLA, termed SLG.
Three commitments are specified within Moby Dick:
? Entity Availability
? Success of User Registration
? Success of Service Authorization
Entity Availability defines the guaranteed availability of Moby Dick key entities (in particular AAAC
Clients and QoS Managers) in unit of time or in percentage within each period of a pre-defined length.
The usual period is a calendar month or a billing period.
Success of User Registration defines the guaranteed successful of a valid registration request with a valid
NAI and credentials within minute, at least after retries of ‘approximately uniform’ interval, if
the user is currently in the home domain.
Success of Service Authorization defines the guaranteed acceptance of a valid service request from a
registered home user within minutes, at least after retries of ‘approximately uniform’ interval. In
Moby Dick, services offered to customers are network transport services. These services enable IPv6
packets to be transported with a certain QoS within the operator network. The QoS parameters in Moby
Dick are restricted to bandwidth and a priority number. The network transport services are characterized
by any combination of the CoA/HomeAddr, DestAddr, and DSCP. A particular service in Moby Dick is
implicitly requested with the arrival of the first packet marked with the corresponding DSCP.
Different situations and conditions can lead to violations of the abovementioned commitments:
? Implementation errors of one or more of the involving entities.
? Configuration errors of one or more of the involving entities.
? Data communication errors.
? The respective entities are compromised.
? The database which holds the required information e.g., user profile, is corrupted.
? Network is overloaded
The entity unavailability does not include unavailability due to:
? scheduled maintenance
? failures of users’ own devices and/or applications
? force majeure
D0103v1.doc 135 / 168

D0103v1.doc Version 1 6.7.2003
4.5.6.2 Requirements
4.5.6.2.1 Auditing Requirements
There are three tasks to be accomplished to detect SLG violation:
? Determine the downtime of MobyDick entities
? Determine whether all consecutive registration attempts of a user currently in the home
domain, fail within the pre-defined time interval . Failures due to invalid NAI and credentials
do not violate SLG. To perform this task it is necessary to query the customer database to check,
whether the NAI is valid (is a home user). The validity check of the credentials supplied by the
user will rely on the response coming from the AAAC server. This response is reflected in the
AAAC client’s response to the mobile terminal. This means correct implementation and
behaviour of the AAAC server and client is assumed and expected.
? Determine whether all consecutive service requests of an authenticated user are rejected or
ignored within the pre-defined time interval .
4.5.6.2.2 Logging Requirements
Downtime determination requires Moby Dick entities to periodically send a sign of life. The sign of life
contains the identity of the entity (EntityID) and a Timestamp. The time interval must be configurable.
To determine whether registration attempts are successful following events need to be logged:
? Each valid registration request must be logged by the AAAC Client,
? Each registration response must be logged by the AAAC Client.
The receipt of a valid registration request must be logged and the log must contain the following
information: EventID, Timestamp, CoA, and NAI. EventID identifies uniquely the event that occurs; in
this case the arrival of a valid registration request.
The arrival of a valid registration request will trigger a sequence of message exchange in the provider’s
network to carry out the registration process. In the end the AAAC Client will receive a response from the
AAAC Server or a request timeout will occur. This will lead to AAAC Client sends a registration
response containing the result of the request to the MN. Note here that communication errors can lead to
missing response. MN should perform registration retries, if no positive answer is received after a certain
timeout. The following information needs to be logged after sending a response to the MN: EventID,
Timestamp, CoA, NAI, and ResultCode. The ResultCode should tell whether the registration is successful
or not, and if not due to what reason.
To determine whether service requests are accepted following events need to be logged:
• Each service request sent to QoS broker must be logged by the QoS Manager,
• Each corresponding response coming from QoS broker must be logged by the QoS Manager.
After detecting that a new service is requested by a MN (MN sends a packet marked with a DSCP not
being used), the QoS Manager in the access router needs to log the following information regarding this
event: EventID, Timestamp, DSCP, DestAddr, CoA, and NAI. EventID identifies the arrival of a service
request.
The arrival of a service request will trigger a sequence of message exchange between QoS Manager and
QoS Broker. In the end the QoS Manager will receive a response from the QoS Broker or a request
timeout will occur. This will lead to QoS Manager configures the Access Router to forward or drop the
packets of this requested service. The following information needs to be logged: EventID, Timestamp,
DSCP, DestAddr, CoA, NAI, and ResultCode. The ResultCode states whether the requested service is
accepted or not, and if not due to what reason.
4.5.6.3 Architecture
The following figure depicts the logging and auditing architecture. As described in the section on
Logging Requirements, in addition to availability events, AAAC Clients have to log user registration
events, while QoS Managers have to log service authorization events. Both entities, the AAAC Client and
the QoS Manager, reside in each Access Router. Events to be logged will first be stored in the Local Log
via an Integrated Logger. This Local Log will be managed by Local Log Management module, which has
the responsibility to transfer the logs to the Central Log Management module. The Central Log
Management module will store the logs in the Audit Trail before being fetched by the Auditing module to
be examined with respect to the given commitments.
D0103v1.doc 136 / 168

D0103v1.doc Version 1 6.7.2003
Access Router
AAAC Client
Integrated
Logger
QoS Manager
Integrated
Logger
Local
Log
Audit
Trail
Auditing
Local
Log Mgmt
Central Log
Mgmt
Figure 92: Auditing and Logging Architecture
The task carried out by the Integrated Logger should not significantly affect the tasks of the hosting
entity, i.e., the AAAC Client and the QoS Manager. This is the reason why the event logs are not s ent
directly to a central Audit Trail, which may last longer due to the network communication overhead.
Since QoS Manager does not aware of NAI, a way to map a CoA to NAI needs to be found to allow for
logging of NAI in the service authorization event logs. This mapping can be done with the help of the
AAAC Client, who knows exactly which NAI a certain CoA belongs to, as long as the MN having this
CoA is currently registered by this AAAC Client. Because this is a logging issue, the required
communication will be carried out between the AAAC Client’s Integrated Logger and the QoS Manager’s
Integrated Logger. The information on CoA-NAI mapping will be provided to the Integrated Logger by
the AAAC Client.
The Local Log is not implemented as a flat file, but as a MySQL database. This requires a running
MySQL server in each Access Router. Logs that have been successfully sent to the Central Log
Management will be deleted from the Local Log. In this regard MySQL provides for a reliable and easy
manipulation of event logs.
Since each Local Log Management in each Access Router is connected to the Central Log Management,
the data transfer need to be controlled, so that no packet loss occurs due to buffer overflow.
The Audit Trail is a MySQL database, which has the same structure as the Local Log. It stores the event
logs collected from every Local Log before being processed by the Auditing module. Logs in the Audit
Trail that have been completely processed will be deleted or moved into data archives by the Auditing
module. The result of the auditing process is a report telling whether or not violation to each commitment
has occurred. This report is written into different flat files for each customer in case of user registration
and service authorization, and for each entity in case of entity availability.
4.5.6.4 Data Structures
Based on the logging requirements, five types of events have been identified, which can be separated into
three groups. The five types of events are Entity Availability Event, User Registration Request Event,
User Registration Response Event, Service Authorization Request Event, and Service Authorization
Response Event. The three groups are obviously Entity Availability Event Group, User Registration
Event Group, and Service Authorization Event Group. All event logs in a group will be stored in the same
MySQL table in the Local Log, and after being collected in the same MySQL table in the Audit Trail.
The three tables corresponding to the three groups are named SoL (Sign of Life), UsrReg (User
Registration), and SvcAuth (Service Authorization). The following subsections describe the data structure
of each table.
4.5.6.4.1 Sign of Life
MySQL Table: SoL
D0103v1.doc 137 / 168

D0103v1.doc Version 1 6.7.2003
Logger: QoS Manager and AAAC Client
Attribute
(MySQL
Column Name)
MySQL
Data Type
Example
Remarks
LoggerID VARCHAR (255) “arc.ethz.ch:qosmanager”
LogTime DATETIME “2002-12-31 22:40:11”
EventID
TINYINT UNSIGNED
(Value 0 to 255)
1
Globally unique identity of
the entity which creates the
log. Possible format:
: (qosmanager |
aaacclient)
Creation timepoint of the
log
Globally unique identity of
the event
Table 40: SoL Table
4.5.6.4.2 User Registration
MySQL Table: UsrReg
Logger: AAAC Client
Attribute
(MySQL
Column Name)
MySQL
Data Type
Example
Remarks
LoggerID VARCHAR (255) “arc.ethz.ch:aaacclient”
LogTime DATETIME “2002-12-31 22:40:11”
EventID
TINYINT UNSIGNED
(Value 0 to 255)
CoA VARCHAR (255) “2000::1:2:3:4”
NAI VARCHAR (255) “hasan@ethz.ch”
ResultCode
INT UNSIGNED
(32 bit unsigned)
11
12
2001
Globally unique identity of
the entity which creates the
log. Possible format:
:aaacclient
Creation timepoint of the
log
Globally unique identity of
the event:
11 for User Registration
Request and
12 for User Registration
Response
0 for User Registration
Request
Other values are for User
Registration Response
according to the
DIAMETER specification
Table 41: User Registration Table
4.5.6.4.3 Service Authorization
MySQL Table: SvcAuth
Logger: QoS Manager
Attribute
(MySQL
Column Name)
MySQL
Data Type
Example
Remarks
D0103v1.doc 138 / 168

D0103v1.doc Version 1 6.7.2003
LoggerID VARCHAR (255) “arc.ethz.ch:qosmanager”
LogTime DATETIME “2002-12-31 22:40:11”
EventID
TINYINT UNSIGNED
(Value 0 to 255)
CoA VARCHAR (255) “2000::1:2:3:4”
DestAddr VARCHAR (255) “2000::7:7:7:4”
NAI VARCHAR (255) “hasan@ethz.ch”
DSCP
ResultCode
TINYINT UNSIGNED
(Value 0 to 255)
INT UNSIGNED
(32 bit unsigned)
21
22
2
Globally unique identity of
the entity which creates the
log. Possible format:
:qosmanager
Creation timepoint of the
log
Globally unique identity of
the event:
21 for Service
Authorization Request and
22 for Service
Authorization Response
0 for Service
Authorization Request
Other values are for
Service Authorization
Response according to the
QoS Broker
implementation
Table 42: Service Authorization Table
4.5.6.5 Event Log Transfer
The transfer of the event logs stored in the Local Log to the central Audit Trail is carried out by the Local
Log Management and Central Log Management. An event can be conveniently represented as a set of
Attribute Value Pairs (AVPs).
OpenDiameter provides a library to generate and parse messages containing AVPs, which lead to the
decision of using this library. The message format will therefore be the same as all DIAMETER
messages. The main advantage of DIAMETER message format is the flexibility and extensibility. To
allow for correct interpretation of these new messages, new command codes and AVP codes are defined
for the transfer of Availability Event Logs, User Registration Event Logs, and Service Authorization
Event Logs. An attribute can be defined optional, so that a message needs not contain the corresponding
AVP, as in the case of User Registration Events, where the ResultCode is only relevant for Response
Events.
Log messages are transferred over TCP in a client/server fashion, where the Local Log Management can
be seen as a client that initiates a TCP connection upon startup, and the Central Log Management as a
server, which is waiting for new connections from the clients.
4.5.6.6 Audit Report
The Auditor is implemented in C++. A process is started for each type of commitment: Entity
Availability, Success of User Registration, and Success of Service Authorization. The result of the
violation detection process is written in a flat file. For each entity respectively customer, and each
commitment, a report file is generated. The report tells whether an entity is available during the predefined
interval in case of availability guarantee. In the case of guarantees on success of user registration
and service authorization, the report shows for a particular customer, whether the respective provider’s
commitment is fulfilled or not. A commitment violation is considered to happen, if no response has been
received or if negative response is received, which is caused by network generated errors.
An examp le report of the availability investigation of the QoS Manager in the Access Router
ksat72.ipv6.rus.uni-stuttgart.de for April 2003 looks like:
D0103v1.doc 139 / 168

D0103v1.doc Version 1 6.7.2003
AUDITING Availability for ksat72.ipv6.rus.uni-stuttgart.de:QoSManager:
2003-04 down=43155 => violation
It shows that during April 2003, the downtime of the QoS Manager entity is 43155 seconds, which leads
to the conclusion, that the commitment is violated.
Another example report of the examination on user registration for the user cco@rus.uni-stuttgart.de
shows the following:
AUDITING User Registration for cco@rus.uni-stuttgart.de:
2003-05-09 14:23:36 3 1 0 0 0 net-err= 0 usr-err= 0 => no violation
2003-05-09 14:33:50 1 0 0 0 0 net-err= 0 usr-err= 0 => no violation
2003-05-09 14:45:16 1 2 1 1 1 net-err=4002 usr-err= 0 => violation
The report shows that there is a violation of the guarantee on registration success. User cco@rus.unistuttgart.de
tried to register at 2003-05-09 14:45:16 and received a negative response with the code 4002
(DIAMETER_OUT_OF_SPACE). The user has performed registration retries as required (more than 5
times as can be seen in the series of number 1 2 1 1 1, that shows number of retries in each interval).
A similar report is also generated for the examination of service authorization event logs.
4.6 Paging Agent Software Specification
This section provides an overview on the Paging Agent software components, associated interfaces to
remote nodes and implementation specific information.
4.6.1 Overview of the different functional components
The following figure illustrates the logical functions of the Paging Agent node.
IP paging module
AR
Tracking
Agent
Component
MT
AAAC.f
Paging Agent
Functional
Component
Dormant
Monitoring
Agent Comp.
Enhanced IPv6 stack
Standard IPv6 stack
Network Device
Ethernet
Figure 93: 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 in case, the proposed security mechanisms are supported. This interface has been
proposed in the concept, but has not been implemented and is not used in the integrated Moby Dick testbed.
4.6.2 Description of the different functional components
4.6.2.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, which have been registered with the Paging Agent node before. 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 (MTs). 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
D0103v1.doc 140 / 168

D0103v1.doc Version 1 6.7.2003
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 that has been registered as dormant with the PA, the
DMA function has to buffer the packet and checks 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 initiate re-activation of 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 mechanism. The
configuration of the packet filter function, as described briefly above, has not been implemented in the
Moby Dick test-bed, but is for future optimisation. 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, has been implemented to be configurable for an
administrator.
4.6.2.2 Tracking Agent Functional Entity (TA)
The Tracking Agent function 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 mobile terminal or from the paging attendant implemented in a
paging area’s Access Router. In case the DMA receives an initial 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 means of providing the registered paging area information 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.
4.6.2.3 Paging Agent Functional Entity (PA)
The Paging Agent function is responsible for generation and distribution of generic IP paging messages as
well as for the co-ordination of the paging process. 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 are to be
generated and to be distributed to the paging area’s ARs implementing the paging attendant function. 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 will not be deployed within the Moby
Dick project. Rather lists of ARs' access interface addresses are maintained in the Paging Agent node to
keep addressing of paging attendant functions in ARs flexible, which allows operation of enhanced
paging strategies in the future.
4.6.3 Softwarimplementation / interfaces
4.6.3.1 Interface between the Mobile Terminal and the Paging Agent
4.6.3.1.1 Description
In case of having a pre-established security association with the PA, the mobile terminal can
communicate directly to the PA, if the current AR allows respective ICMPv6 message types passing
through, either based on a previously established security association ??? or administrative setting of AR
filter functions (also taking QoS and AAA filtering function on ARs into account). This can happen after
the discovery phase (explicit dormant mode registration) as well as for paging area updating and dormant
mode de-registration.
The remote entities deploy the ICMPv6 protocol as specified for the IP paging concept in Moby Dick.
4.6.3.1.2 Message types
Source Dest Primitive Parameters
D0103v1.doc 141 / 168

D0103v1.doc Version 1 6.7.2003
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
Table 43: Message Types
4.6.3.1.3 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.
0 31
Type Code CRC
Sequence Number
R R R R R R I U
Reserved
Options
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:
Checksum:
Sequence Number:
Set to 0 for all messages as described here for IP paging.
Calculated according to the ICMPv6 standard.
Allows for correlating replies with requests.
Flags: R: Reserved. To be initialised with 0.
I: Implicit dormant registration
U: Updating messages.
Reserved:
Options:
below, usage
Reserved for future use.
One or more TLV (type-length-value )-encoded option. Format as described
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 in the following message format:
0 31
Type Code CRC
Sequence Number
R R R R R R I U
Reserved
Options
Status Code
D0103v1.doc 142 / 168

D0103v1.doc Version 1 6.7.2003
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:
Checksum:
Sequence Number:
Set to 0 for all messages as described here for IP paging.
Calculated according to the ICMPv6 standard.
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:
Status Code:
Options:
Reserved for future use.
Result of a request message.
Currently specified 0x00 SUCCESS
0x02 USE EXPLICIT REGISTRATION
0xff ERROR
One or more TLV-encoded option. Format 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.
1 byte 1 byte
Type
Length
Value
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. International Mobile Subscriber Identifier – IMSI). The options referred to in the
following table are required to be implemented to support basic protocol operation 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
Table 44: Paging Options
An overview 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 TD-CDMA the 24bit terminal identifier part of the International Mobile
station Equipment Identity (IMEI) will be taken. To allow flexible deployment of the common identifier,
D0103v1.doc 143 / 168

D0103v1.doc Version 1 6.7.2003
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. For
details about the format, please be referred to [D0301].
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.
The common IP paging identifier has a preceding unique header, which allows identification of the entire
ID length (part of the generic TLV-encoded format), the access provider as well as provision of an
additional field to distinguish common IP paging identifier (ID Extension).
4.6.4 Implementation specific information
This section provides some details on how the software modules have been designed, implemented and
interfaced.
4.6.4.1 Dormant Monitoring Agent Functional Entity
The Dormant Monitoring Agent (DMA) function on the Paging Agent node was implemented as a
separate kernel module, interfacing to the actual paging signalling control kernel module. Since the DMA
module handles only user-data packets (queuing, management, forwarding) and no paging related
protocol signalling, this separation allows keeping software modules' responsibility separated for control
plane (signalling) and user plane (data packets) tasks. From implementation point of view, the DMA
module depends on the Dormant Mode Host Alerting (DMHA) module (see below), hence first the
DMHA module is to be loaded, then the DMA module can be loaded to the kernel, which dynamically
interfaces to the DMHA module (automatic interfacing through the module initialisation function).
The DMA module must be loaded with a startup script, which checks the availability of the IPv6 tunnel
module, as provided by the MIPL Mobile IPv6 software package. The latter module is needed for support
of IPv6-encapsulation. The script first loads the tunnel module in case it is not yet linked to the kernel,
then four (default value, can be changed in the script) DMA specific tunnel modules are created and the
DMA module is loaded subsequently.
The following functions were implemented with regard to DMA kernel module functionality:
DMA kernel module:
o IPv6 tunnel endpoint functionality
o Queuing of data packets, which address a mobile terminal previously registered as dormant
o Dynamic management of data packets for different registered mobile terminals
o Interfacing to the DMHA (paging signalling control) module
o Forwarding functionality (IPv6 tunnelling)
DMA startup script:
o IPv6 tunnel module availability check and module loading function
o Configuration and activation of four (default value, can be changed) DMA tunnel interfaces
o DMA module (re-)loading (start and stop) functions
4.6.4.2 Tracking Agent Functional Entity
The Tracking Agent function has been co-located with the Paging Agent functional entity in the Dormant
Mode Host Alerting (DMHA) kernel module, which will be described in the following section.
4.6.4.3 Paging Agent Functional Entity
The Paging Agent function has been co-located with the Tracking Agent function within the Dormant
Mode Host Altering (DMHA) kernel module. The DMHA module takes over all functions required for
the dormant registration of a mobile terminal, including PA discovery, dormant registration, tracking the
paging area a registered mobile terminal is located in, as well as controlling the actual paging process for
location, re-activation and initiation of routing state re-establishment. Furthermore, dynamic interfacing
to the DMA module is supported to co-ordinate queuing and forwarding of user-data packets.
The DMHA module is loaded by means of a startup script, that co-ordinates linkage of the module to the
kernel, as well as the configuration of the kernel module. A configuration file is provided, allowing the
module to learn about a min imal set of static configuration parameters. The script deploys a user-space
process to read the configuration data and to provide the configuration information to the kernel module
through a previously established character device driver interface.
The following function are implemented with regard to DMHA kernel module functionality:
DMHA module:
o Paging signalling state machines
o Dynamic mobile terminal registration management, including TA functions
o Message and options handler (message generator and pars er)
o Interfacing to the DMA kernel module
DMHA startup script:
D0103v1.doc 144 / 168

D0103v1.doc Version 1 6.7.2003
o DMHA kernel module (re-)loading (start and stop) functions
o Utilization of a user-space process to read the appropriate configuration file and to write
configuration data to the DMHA kernel module
4.7 Home Agent Software Specification
This document gives the software specification of the different components of the Home Agent (HA).
There are no additional Moby Dick requirements to the Home Agent apart from the (standard) Mobile IP
stack. However, for the sake of completeness. This section specifies the software structure of the Home
Agent.
4.7.1 Overview
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 Mobile IPv6 stack from MIPL
(www.mipl.mediapoli.org ).
Mobile NCP IPv6 module
MIPv6
Home Agent functionality
Figure 94: Mobile IPv6 Module
The Mobile IPv6 Home Agent acts as proxy for in its home network registered roaming Mobile Nodes.
The detailed behaviour of this functionality will be detailed in the next chapter.
4.7.2 Detailed description of the components
This chapter gives a detailed description of the sub-blocks of each component, and their interactions with
other components.
4.7.2.1 Mobile IPv6 Module
The Mobile IPv6 module is integrated into the IPv6 stack and has the following interactions.
IPv6 NCP stack
Mobile NCP IPv6 stack
MIPv6
Home Agent functionality
Network NCP Device Driver
Ethernet
(or WVLAN
or W-CDMA)
Fi
gure 95: Mobile Ipv6 Module
The Mobile IPv6 stack in the Home Agent provides standard Home Agent functionality; i.e., the Home
Agent acts as a proxy for roaming Mobile Nodes of its (home) network and delivers packets destined for
this roaming Mobile Nodes to their current point of attachment via IP-in-IP encapsulation (i.e.,
tunnelling). Therefore, the Home Agent always needs to be informed about the current location (i.e. Careof-Address
CoA) of the Mobile Nodes, which are stored in a binding cache.
D0103v1.doc 145 / 168

D0103v1.doc Version 1 6.7.2003
4.7.2.2 Alternate Care-of Address support
In order to support the alternate-CoA registration with a binding update, which is required for Paging, the
Mobile IPv6 implementation is to be patched with an appropriate alt-CoA patch, which was implemented
within the framework of WP3 activities.
D0103v1.doc 146 / 168

D0103v1.doc Version 1 6.7.2003
5 Moby Dick Signalling Flow Specification
This chapter reports about the specification of signalling and message flows for initial registration, fast
intra-domain handover, inter-domain handover and Paging with respect to mobility, QoS and AAA. Thus,
this version contains all required information for a reader to understand the way, how the components as
described in the previous chapter will interact in the deployed Moby Dick architecture.
Since the specification allows several possible implementations, the structure of the following section
comprises for all scenarios the functional specification and the detailed implementation specification.
5.1 Assumptions
This section lists the assumptions and specifies the interface between WP2 (QoS), WP3 (Mobility) and
WP4 (AAA), especially with respect to implementation issues, since there is the need for ‘message
combination’ during the Moby Dick key scenarios, which are registration, handover signalling within and
between administrative domains, session setup, paging, Auditing and charging. Interaction and Interfaces
between all involved components as described in the previous chapter have been defined.
5.1.1 Security Associations
Within the current Moby Dick approach, the following security associations are assumed:
Static
MN - AAAC.h
AAAC.h – HA
MN – HA
oARx – nAR
AAAC.f - AAAC.h
AR - AAAC.f
MN – PA
PA - ARx
Dynamic
MN – ARx
MN - PA
Table 45: Security Associations
In the framework of Moby Dick, we assume a security association of neighbour Access Routers within an
administrative domain. This assumption is also part of the fast-handover draft [draft-ietf-mobileip -fastmipv6-03.txt;
section 5.2.1].
This means that dynamic attachment of a user to a domain is out of the scope of Moby Dick. It is assumed
that each user has a fixed home domain where he is registered and when asking for resources, this so
called home domain is asked for enabling this resources vouching for the user towards any visiting
domain.
5.1.2 Distinction: 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. This section identifies the entity on which the
decision algorithm should be located and presents the parameters on which the decision is based.
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, special focus will be on intra-domain handover, 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 transparent to the Mobile IP stack, it is
suggested to place this decision algorithm ‘below’ Mobile IP (i.e., in the MTNM).
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 interdomain
Several theoretical work is ongoing to extend and to enhance this decision finding process by AAA, QoS
and possibly higher layer input such ay payment preferences and so on.
D0103v1.doc 147 / 168

D0103v1.doc Version 1 6.7.2003
5.2 Signalling Scenarios
This chapter specifies the scenarios between the Moby Dick key components. This are: the Mobile
Terminal (MT), the Radio Gateway (RG), the Access Router (AR), the AAAC Server, the QoS Broker,
the Paging Agent and the Home Agent.
5.2.1 Registration
This chapter specifies the signalling for Registration i.e., the registration of a Mobile Node, 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 send or receives packets), this process is called inter-domain
handover as is described in one of the following sections. 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 decision
handover type decision algorithm and therefore is part of the MTNM. Additionally there is a reregistration
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.
If this regis tration did not happen correctly, the mobile node is transferred into a de-registered status,
which means that no Internet connectivity is available for the Mobile Node at all.
The Registration process (AAA and Mobility) is initiated after the Care-of-Address (CoA) is acquired by
the Mobile Node. This is performed via the deployment of stateless auto-configuration, avoiding
Duplicate Address Detection (DAD). According to an internal study, the probability for an duplicate IP
address within a network is that low that no additional effort to resolve this is justified within Moby Dick.
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
available to the user, depending on the specific network policy.
The registration scenario has been developed in a two step approach. In the first step, AAA signalling and
MIP signalling is 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
build dynamically. Furthermore in the second step the AAA architecture even could be used for dynamic
HA discovery.
In the first step (Figure 96) the MN sends an AA request via the user registration protocol to the AR. The
AR sends an AA request via AAA protocol to his 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 send out an Binding Update (BU) immediately after the CoA
acquisition. At the point of time the QoS.f is informed about the users successful registration, this BU is
not any more blocked by the QoS attendant located at the access router, but forwarded to the home agent.
Afterwards the MN sends a BU to the HA and the HA replies with a BACK. This message goes through
the AR without any requirement for authorization, as the AR will be configured by default with a minimal
bandwidth for signalling. 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. Within the current Moby Dick implementation this interval is also valid for message “10”, which is
basically inline with the proposed solutions as currently discussed in the IETF. Theoretical work is
ongoing to decouple this which would lead to a more intelligent behaviour of the AAAC.f consolidating
the data received from the AAA Attendants as well. T2 describes the interval for the re-registration
process.
Currently Moby Dick Step1 signalling scenario is implemented and brought to the field trial.
D0103v1.doc 148 / 168

D0103v1.doc Version 1 6.7.2003
MN AR AAAC.
f
1
QoS.f QoS.h AAAC.
h
2
3
4
6
5a
5b
T2
7
8
T1
9
9
9
9
10
10
10
1
2
10
3
4
6
5a
5b
Figure 96: Registration Scenario Step 1
In order to make comments and additions as easy as possible, the messages and parameters will be
defined in a separate table below the signalling flow diagram.
The following table specifies the messages, describes parameters and content and allows remarks.
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
(explanation see below), Session
Timeout
5a AA Response 2x key(MN, AR), Profile SubSet
(explanation see below), Session
Timeout
5b NVUP dump MN, AR, Profile SubSet (includes
timeout)
6 AA Response 1x key(MN, AR), Profile SubSet
(codes), Session Timeout
Dumps the proper
DSCP codes to use in
this network
D0103v1.doc 149 / 168

D0103v1.doc Version 1 6.7.2003
7 BU
8 BACK
9 Accounting Data SrcIP, HoAd?, DesIP, DSCP, In/Out
Byte/Packet Counter
10 Accounting Data SrcIP, HoAd?, DesIP, DSCP, In/Out
Byte/Packet Counter
T1 Timer for AAA Attendant
to forward data to AAAC.f
T2 Re-registration interval
Table 46: Registration Step 1 messages and Parameters
The destination address
may also be required in
many network-level
services (free numbers,
e.g.)
The setting of the timer T1 has not been studies profoundly. However, in first discussions about the
involved partners for the time being a 3 minute interval is foreseen. The timer T2 for the re -registration
interval is proposed to be at the range of about 10 minutes, but also here some further discussions are
required and this value might change significantly. Possible the measurements of the trials will provide
here further input in order to come to an optimal solution.
The key between Mobile Node and Access Router is send 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 URP messages. 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 2. In the 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 step1.
MN AR AAAC. QoS.f QoS.h AAAC. HA
Figure 97: Registration Scenario Step 2
The following table specifies the messages, describes parameters and content and allows remarks.
No. Message Content / Parameters Remarks
1 AA request usr:pwd@domain; BU
2 AA request usr:pwd@domain; BU
D0103v1.doc 150 / 168

D0103v1.doc Version 1 6.7.2003
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, HoAd?, DestIP, DSCP, Time, In/Out
Byte/Packet Counter
10 Accounting Data CoA, HoAd?, DestIP, DSCP, Time, In/Out
Byte/Packet Counter
Table 47: Registration Step 2 messages and Parameters
The protocols used are the same as in step 1.
5.2.2 Session setup and Service authorization
This chapter specifies part of 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, “service
authorization”, is described here. Only the QoS Manager of the AR is involved in that process and is the
sole part considered in this chapter. In this section, we assume that registration has already been done and
that the needed subset of the user profile is in the AAAC.f. and this has already sent a subset of this
subset, the NVUP, to the QoSBroker. 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).
Note that the notion of flow in these sentences is quite flexible. It represents a set of packets, which
trigger a non-default match on the AR classification unit. In typical terms, this will represent a (CoA,
Destination, DSCP) tuple, but can represent a (CoA, DSCP) or a (Destination, DSCP) tuple.
A service is just the network resources (BW and priority) that a flow can employ. It is identified by the
DSCP of the packets sent by the MN.
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
(described below). If the process succeeds the AR forwards the packets, else it drops the flow.
The following MSC (Message Sequence Chart) applies to the following cases:
• An application starts sending packets. The AR detects a new service flow, it may perform the
following flow authorization.
The process can be summarized as follows:
Note that QoSBroker knows already user profile, as the user has already registered in the
network, and thus is implicitly authorized to use some services. In “session setup” time, the AR contacts
the QoSBroker in order to know about the network availability to allow some resource usage that is
described in the NVUP.
1. MT starts a flow. MT sends some packets to AR;
D0103v1.doc 151 / 168

D0103v1.doc Version 1 6.7.2003
2. AR request resource to QoS. If the flow is not registered in the AR, AR requests some resource
usage instructions to QoSBroker sending some message with the identification of the flow
(CoA+ DSCP code+ dest. Address);
3. QoS Broker answers. QoS Broker checks its network availability conditions and allows or
rejects that flow;
4. AR applies QoS Broker decision. In a positive answer from QoSBroker AR reconfigure itself,
and stop discarding the MT packets. In a negative answer it continues discarding MT packets
and doesn’t do any reconfiguration.
This process can be illustrated in Figure 98. In (1) the first packet from the MN is represented. This
packet will trigger the request from the QoSB – which should already have the relevant information for
that user (MN). Until the response from the QoSB arrives (3) the packets are discarded. According to the
initial tests´, only the first packet is discarded. After the authorization from the QoSB (which depends on
the administrative settings provided by the AAAC to the QoSB, and the resource management made by
the QoSB) the packets are then transmitted to the network.
Note that this process can be easily extended to support RSVP -aware applications, processing the RSVP
request in function of QoSB commands for that request.
The figure also shows the situation at a CN, in another domain. First, there will exist proper agreements
between both domains. These agreements are reflected at AAAC-level, and typically will convey rules to
be enforced by QoSBrokers at the respective Border Gateways. All this process is not represented in the
Figure. The figure does represent the flow authorization when the packets transverse domains. The first
packet arriving the egress router (AR2) in the foreign domain, will require authorization to be transmitted
to the CN (e.g. because the CN is on a wireless net). AR2 then contacts its local QoSB, which will then
issue the control information for the AR2 (imply for instance the establishment of a bi-directional
connection between AR2 and CN). Note that in most cases QoSB2 will not need to contact any AAAC
for information. The QosB will, in principle, trust the packets that are arriving from its network
interfaces, and proceed based in the DSCP code of the incoming packet – its significance will be assured
by the transformations/policies made at the ingress of the domain.
Notice that this view is optimised for a small number of services defined across operators. For general
widespread service provision, specific requests to the AAAC entities would be required – however, either
service agreements were already in place between those operators (which basically is the situation defined
here), or dynamic service negotiation would be required –situation which is not foreseeable in a near
future.
MN AR QoSB1 AAAC1 CORE AAAC2
QoSB2
AR2
CN
Trunking Agreement
& SLA Mapping
1
2
3
4
8
7
5
6
Figure 98: “Flow” authorization
AAAC.f ßà SP’s AAAC, AR --- DIAMETER
AAAC.f ßà QoS Broker --- COPS
QoSBroker ßà AR --- COPS, (SNMP, CLI)
No. Message Content / Parameters Remarks
1 1 st packet of a CoA, Destination, DSCP This packet will be discarded by the AR, but
D0103v1.doc 152 / 168

D0103v1.doc Version 1 6.7.2003
given application
with a given DSCP
not yet in use
2 QoS Broker query
for
QoS
instructions
3 AR QoS
Configuration
4 1 st packet,
retransmitted by
the MN
5 QoS Broker query
for
QoS
instructions
6 AR2 QoS
Configuration
7, 8 1 st packet,
retransmitted by
the MN and reply
from the CN.
its information (CoA, Destination, DSCP)
will be used to query the QoS Broker.
CoA, Destination, DSCP The QoS Broker will consult the NVUP
information for that user, and if the DSCP is
allowed by the SLA, the QoS Broker
configures the AR to allow forwarding of
the next matching packets (DSCP, Dest,
CoA).
BW, priority, DSCP, CoA If there are not enough resources available in
that AR, nothing will be done.
CoA, DSCP, CN Address This packet will initiate the resource
reservation on the CN access network.
DSCP, CN Address
DSCP, CN Address
DSCP is the DSCP of the packets sent by the MT.
5.2.3 Intra-domain handover
Table 48: Message Specification for Session Setup
Every packet coming from the CORE is
trusted. No authorization or authentication
information needed at this point.
The QoS Broker will configure the AR to
allow the packets coming and going to the
CN Address with that specific DSCP.
“Session Start”
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 involves no AAA entity. Here AAA mechanisms are included as
attributes into the FAST handover specific communication between the oAR and the nAR. So, the focus
of the Moby Dick project with respect to an integration of AAA 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)
At this point of time there seems to be no need to distinguish between specification and implementation.
Therefore, the following diagram represents the fast handover signalling specification. The
implementation may depend on existing code capabilities.
The deployment of context transfer in combination with the fast handover messages prior to the handover
allow to carry the IPsec related data as e.g. a key, meter configuration information and the (sub-) profile
to the new AR and thus, e.g., allow network configuration before handover execution. It is required that
the whole active user configuration on the oAR is transmitted to the nAR. However, the acceptance of
these new flows may imply changes on current configuration of the nAR. The QoSB is aware of all these
aspects, and thus will be signalled by the oAR that a movement is desired. The QoSB does make the
adequate configuration changes and sends these commands to the nAR. After being properly configured,
the nAR confirms the configuration to the oAR, and the MN then proceeds with the handover. The a-
priory transferred information (i.e., meter configuration information and key) allow the AR to match the
authorization, to start the accounting appropriately and if necessary cancel the connection. It is not
necessary for advising the AAAC.f of the new location of the MN, to start a new AAA session between
nAR and AAAC.f, to configure the accounting on nAR etc. The AAAC only needs to receive the overall
accounting information, offline, and does not need to be informed real-time of these movements. The
parameters concerned with metering can be exchanged via a CT-alike information at the Handover
Initiate. Regardless of the result of the handover, the handover request will be then automatically
registered in the metering unit.
With respect to Context Transfer provision in combination with Fast-HO, the HI message conveys AAA
related data as a byte-stream from the oAR to the nAR. There is no need to transfer context or related
D0103v1.doc 153 / 168

D0103v1.doc Version 1 6.7.2003
parameters for re -establishment of QoS functions on the nAR. Re-establishment of the security
association on the nAR is done by conveying the respective key. Additionally, since each AR generates a
new SPI, this index is not to be conveyed from oAR to nAR, but the nAR generates a new SPI. This SPI
is to be transferred from the nAR to the mobile terminal.
The Accounting Start indication is sent to the AAAC.f from the mobility manager of the nAR on
reception of the 1 st PDU at the nAR.
In case of a inter-domain handover it is expected that no communication between the two provider (of the
oAR and the nAR) takes place for sure and so no direct context transfer is possible. In this case a standard
registration process is triggered. The de-registration of a user/MT in the oAR domain is done exclusively
by either a missing re-registration message, or a registration message of a new user using the same CoA.
MN oAR nAR oQoS.f nQoS.f AAAC.f HA
2
1
3
Is delay an issue? If yes,
consider to not wait for C.
A
C
B
5
6
7
9
8
10
11 12
13
14
X
15
Figure 99: Fast Handover Signalling Flow
The following table describes the messages and parameters for the Fast Handover Signalling:
No. Message Content / Parameters Remarks
1 Router Advertisement Network prefix + x Indicates HO type - see below
2 Router Solicitation for Proxy NARaddr, new CoA
3 Handover Initiate SubSubProfile, key, new
CoA
CT info for AAA as bytestream
conveyed
A QoS message (COPS?) NAR, oCoA Indication of nAR ID, oCoA
B QoS message (COPS?) HoA, nCoA, DSCP in use carry NVUP (HoA, nCoA,
DSCP in use)
C QoS message (COPS?) Configuration data, result
info (command and DAD
check result)
5 Handover Acknowledge SPI
6 Proxy Router Advertisement SPI
7 Handover Execute (FBU)
8 Start Bicasting (& Timer)
carries configuration data for
nAR or info on ResReserv
failure, indication on DAD
result
D0103v1.doc 154 / 168

D0103v1.doc Version 1 6.7.2003
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 49: Fast Handover Signalling Messages and actions
The MIP fast handover message format will follow the fast handover draft specification (see draft-ietfmobileip-fast-mipv6-03.txt).
The AAA specific parameters are to be appended as option(s) to the fast
handover message, which has been defined.
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:
48 bit
16 bit 64 bit = 24 bit + FFFE (16bit) + 24 bit
2001:0638:0202
Ethernet………………….address
Network provider address SLA EUI 64 bit
2001:0638:0202: 0 :0250:daff:fecf:c6ad
Figure 100: IPv6 message format
In case the first 48 bit change, 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.
Extension proposal: Within the framework of Moby Dick the first two bit of the SLA could be reserved to
‘simulate’ different domains within a trial area (see first line of table 3: prefix + x).
5.2.4 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 optimising the inter-domain handover case. However, the signalling for interdomain
handover is quite similar to the Registration case.
5.2.5 Paging
5.2.5.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.
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
D0103v1.doc 155 / 168

D0103v1.doc Version 1 6.7.2003
paged. However, the security support of the paging concept is specified and described in a Deliverable,
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:
• AAAC.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
5.2.5.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 suboption.
This signalling flow for PA discovery as well as for implicit dormant registration and explicit
dormant mode registration is illustrated in Figure 101 and Figure 102 respectively.
Explicit registration is optional and will not be deployed in the Moby Dick test-bed. Implic it registration
is more efficient and will be supported by the test-bed
D0103v1.doc 156 / 168

D0103v1.doc Version 1 6.7.2003
MN
1a
AR1 AR2 AAA PA HA
1b
1f
1e
1c
1d
2
3
Figure 101 : 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, …
2 MIPv6 Binding Update Alternate CoA sub-option (PA
address)
3 BACK
Includes AH for AR
authentication at MN.
PA registration, possibly
extended lifetime
Table 50: Messages for PA Discovery and Dormant Registration (implicit registration).
D0103v1.doc 157 / 168

D0103v1.doc Version 1 6.7.2003
MN
1a
AR1 AR2 AAA PA HA
1b
1f
1e
1c
1d
2
3
4
5
Figure 102 : 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, …
2 Dormant Mode Request HoA, CoA, MAC address list (n *
3byte) or L3-ID, Paging area ID,
Sequence #, reg. Lifetime
3 Dormant Mode Reply + status code, random #, paging
process keys, PA address,
reg. lifetime,…
4 MIPv6 Binding Update Alternate CoA sub-option (PA
address)
5 BACK
Includes AH for AR
authentication at MN.
Status code indicates ‘explicit
PA registration’.
AH carried for MN
authentication at PA.
Includes AH for PA
authentication at MN.
PA registration, possibly extended
lifetime
Table 51 : Messages for PA Discovery and Dormant Registration (explicit registration).
D0103v1.doc 158 / 168

D0103v1.doc Version 1 6.7.2003
5.2.5.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.
MN
AR1 AR2 AAA PA HA
1
2
Polling the
paging area
3
CoA acquisition and
standard attach
(+ AA)
4
5
6
7
Figure 103 : Paging an idle mobile terminal and active state registration
To optimize the paging delay, state re-establishment at the Home Agent (message 4) and de-registration
with the Paging Agent (message 6) could be performed in parallel, assuming the initial data packet for
session setup has been buffered at the PA (this is actually the packet, which initiated the paging process),
waiting for being forwarded to the re-activated mobile terminal
No. Message Parameters Remarks
1 Paging trigger packet ----- Initial user data packet, buffered at
PA.
2 Paging Request Random#, keys, [MAC list Include AH for PA authentication at
3 On-link Paging
Request
4 MIPv6 BU
5 MIPv6 BACK
6 Dormant Mode
Request (0)
or L3-ID]
ARs.
Technology dependent format.
Assume IP paging first.
No AH included, proprietary auth.
and encr. mechanism
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 52: Messages for the IP paging process.
D0103v1.doc 159 / 168

D0103v1.doc Version 1 6.7.2003
5.2.5.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.
MN
AR1 AR2 AAA PA HA
2
1
Paging area ID
advertisements
[RtAdv option or
L2 beacon extension]
No L2 interaction on acces link
3
1a
2
With L2 interaction on acces link
1b
3
L2 interaction with
Paging attendant
in ARs
Figure 104 : Paging Area update signalling
D0103v1.doc 160 / 168

D0103v1.doc Version 1 6.7.2003
No. Message Parameters Remarks
1 RtAdv or L2 beacon …, paging area ID Paging area info
advertisement
2 Dormant Mode Request …, sequence #, paging area ID, Includes AH for PA
reg. lifetime
3 Dormant Mode Reply …, status code, sequence #,
lifetime
authentication at ARs.
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 53: Messages for Paging Area Updates signalling
5.2.6 Charging
5.2.6.1 Signalling Flow
Basically post-paid and prepaid business models are possible, however only the post-paid scenario will be
implemented. Prepaid scenario will need further investigations. In the ongoing text we will therefore
focus only on the post-paid scenario.
5.2.6.1.1 Post-paid Scenario
In the post-paid scenario, the AAAC.h server stores the accounting data in the accounting database. This
database in conjunction with the customer database will contain all necessary information needed to
perform charging by applying tariffs. The detailed structure of the accounting database is described in
section 4.5.4.4. Section 4.5.4.5 contains details about the charging database, section 0 contains details
about the customer database and section 4.5.4.9 describes the data warehouse, i.e. the used accounting
data.
Cf. Figure 105 for a graphical representation of the signalling: Accounting data is added to the database
after starting a session, during a session and after the session was closed (message 1). The charging
component (CC) will periodically contact the accounting database and extract new records that have not
been yet used for charge calculation purposes (messages 2, 3). For the post-paid scenario it is sufficient
that the CC will contact the database only once a day, typically during a period of low accounting
activities. The CC uses other database—the charging and customer database—to manage the charges. The
tariff definitions will be stored either in CC itself, since they will not change during the Moby Dick trials.
On the basis of the accounting data and the entries in the customer database, the appropriate tariff will be
applied (messages 4 and 5). After the charge calculation is finished the result (i.e. the charge) is written
back in the charging database (messages 6,7). The used rows from the accounting database for the current
charge calculation, will be marked (messages 7) and then copied to another database (not drawn in the
figure).
D0103v1.doc 161 / 168

D0103v1.doc Version 1 6.7.2003
AAAC.h or
AAAC.f
Client
AAAC.h
Server
Accounting
DB
Charging
Component
Charging DB
Customer DB
AAA_ Phases
Charging component not yet involved.
Accounting is done for current session.
Accounting data is stored in the accounting
DB.
1)
After a certain interval, the charging
component will fetch all new
accounting data from the Accounting
DB.
2)
3 )
Lookup tariff and
calculate charge.
4)
6)
5)
7)
8)
Figure 105. Signalling flow in the Post-paid scenario (simplified)
5.2.7 Logging and Auditing
The following figure shows the logging and auditing architecture. While AAAC Client is responsible for
logging User Registration Events, QoS Manager is responsible for logging Service Authorization Events.
In addition to that, both entities also log periodically their ‘signs of life’ reflecting their availability. The
logs will first be stored in the Local Log via an Integrated Logger and later be transferred by the Local
Log Management to the Central Log Management. The Central Log Management will store these logs
into the Audit Trail before being fetched by the auditing module to be examined with respect to SLA
compliance.
An event can be conveniently represented as a set of Attribute Value Pairs (AVPs). OpenDiameter
provides a library to generate and parse messages containing AVPs, which lead to the decision of using
this library. The message format will therefore be the same as all DIAMETER messages. The main
advantage of DIAMETER message format is the flexibility and extensibility. To allow for correct
interpretation of these new messages, new command codes and AVP codes are defined for the transfer of
Availability Event Logs, User Registration Event Logs, and Service Authorization Event Logs. An
attribute can be defined optional, so that a message needs not contain the corresponding AVP, as in the
case of User Registration Events, where the ResultCode is only relevant for Response Events.
Log messages are transferred over TCP in a client/server fashion, where the Local Log Management can
be seen as a client that initiates a TCP connection upon startup, and the Central Log Management as a
server, which is waiting for new connections from the clients.
D0103v1.doc 162 / 168

D0103v1.doc Version 1 6.7.2003
The signalling messages between Local Log Management and Central Log Management are depicted in
table 54. There are no signalling messages exchanged between the Central Log Management and the
Auditing module. The Auditing module will periodically fetch data from the Audit Trail and processes
the log stored in the Audit Trail.
Access Router
AAAC Client
Integrated
Logger
QoS Manager
Integrated
Logger
Local
Log
Audit
Trail
Auditing
Local
Log Mgmt
Central Log
Mgmt
Figure 101: Logging and Auditing Architecture
Local Log
Mgmt
Central Log
Mgmt
1
2
Figure 102: Log Signalling
The table below shows the messages for log transfer.
No. Message Parameter
Command
Code
1 Availability-Log-Request Logger-Id, Log-Time, Event-Id 1301
2 Availability-Log-Answer 1301
1 User-Registration-Log-Request
Logger-Id, Log-Time, Event-Id, User-
Name, Care-of-Address, Result-Code
1302
2 User-Registration-Log-Answer 1302
1 Service-Authorization-Log-Request
Logger-Id, Log-Time, Event-Id, User-
Name, Care-of-Address, DSCP,
1303
Destination-Address, Result-Code
2 Service-Authorization-Log-Answer 1303
D0103v1.doc 163 / 168

D0103v1.doc Version 1 6.7.2003
The parameters are described in the following table.
Table 54: Log Message Specification
Parameter Format AVP Code Remarks
Logger-Id Octetstring 5101
Unique identity of the entitiy
which logs the events
Log-Time Octetstring 5102
The timestamp when the event
is logged
Event-Id Unsigned32 5103
Identifies uniquely the event
that is being logged
User-Name UTF8String (in NAI format) 1 The identity of the user
Care -of-Address Octetstring 5105 The IPv6 address of the MN
DSCP Unsigned32 5107
Destination-Address Octetstring 5106 The IPv6 address of the CN
Result-Code Unsigned32 268
The response code returned by
the AAAC Server respectively
the QoS Broker
Table 55: Message description
The following table shows the valid Event-Id.
Event
Event-Id
Availability 1
User-Registration Request 11
User-Registration Response 12
Service-Authorization Request 21
Service-Authorization Response 22
Table 56: Valid Events
5.2.8 Bearer Management
This chapter is based on the service authorization section, adapting the message flow to the Radio
Gateway specificities.
Basically, before sending packets from MN to RG, a radio bearer must be opened. The radio bearer will
have a specific Radio QoS traffic class, which will determine its physical properties. The mapping
between the packet DSCP and this Radio QoS traffic class is performed by the QoS Broker.
D0103v1.doc 164 / 168

D0103v1.doc Version 1 6.7.2003
MN RG AR QoSB
1
2
4
3
5
6
7
Figure 103: Radio Bearer Signalling
No. Message Content / Parameters Remarks
1 1 st packet of a CoA, Destination, DSCP
given application
with a given DSCP
not yet in use
2 Dummy ping CoA, Destination, DSCP
packet generated
by RG with
parameters of
message 1
3 QoS Broker query CoA, Destination, DSCP
for
QoS
instructions
This packet will not be sent to the RG, but
its characteristics (CoA / Destination /
DSCP) transmitted to the RG.
This packet will be discarded by the AR, but
its information (CoA, Destination, DSCP)
will be used to query the QoS Broker.
The QoS Broker will consult the NVUP
information for that user, and if the DSCP is
allowed by the SLA, the QoS Broker
configures the AR to allow forwarding of
the next matching packets (DSCP, Dest,
CoA).
4 AR QoS BW, priority, DSCP, CoA If there are not enough resources available in
Configuration
that AR, nothing will be done.
5 RG QoS DSCP, Radio QoS traffic The QoS Broker performs the mapping
Configuration class to use, status
between DSCP codes and Radio QoS
classes.
6 Establishment of the radio bearer between
7 1 st packet,
transmitted by the
MN
MT and RG, using Radio QoS traffic class.
CoA, DSCP, CN Address This packet will initiate the resource
reservation on the CN access network.
Table 57: Message Specification
In the case of an incoming packet from AR to MT, this flow is simplified: messages 1 – 2 – 3 are not
used; but the rest of the process is the same.
5.2.9 Interface AR and RG
The interface between the AR and the RG has been described in details in the Radio Gateway software
Architecture.
D0103v1.doc 165 / 168

D0103v1.doc Version 1 6.7.2003
To summarize:
• The Router Advertisements received by the RG on its interface with the AR are intercepted, sent
to the MT on a dedicated TD-CDMA broadcasting channel. They will be transferred to the IPv6
stack on the MT to configure the CoA of the TD-CDMA interface.
• The Neighbour Solicitation requests received by the RG on its interface with the AR are
intercepted. If they are addressed to one of the MT having an open radio connection with the
RG, the RG will reply to them with a Neighbour Advertisement, on behalf of the correct MT,
using its own MAC address instead of the one from the MT.
• The Paging Requests received by the RG on its interface with the AR are intercepted. If they are
addressed to one of the MT having an open radio connection with the RG, the RG will send them
to the MT on a dedicated TD-CDMA paging channel.
• The IPv6 packets received by the RG on its interface with the AR and addressed to a MT having
an open connection with the RG are intercepted (the global scope IPv6 address or the link local
address of the MT can both be used). These packets are transmitted to the MT on a dedicated
channel, with QoS characteristics determined by the DSCP code of the IPv6 packet.
• The IPv6 packets transmitted by the MT to the RG on a dedicated channel, are forwarded by the
RG on its interface with the AR. These packets will then be properly routed by the AR.
• A specific mechanism has been deployed between the RG and the AR / QoS Broker to manage
the opening of radio bearers between the MT and the RG. It is described in details in the chapter
“Bearer Management” of this document.
5.2.10 Paging
5.2.10.1 Interface between Paging Attendant and Paging Module
5.2.10.1.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.
5.2.10.1.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.
5.2.10.1.3 Interface contents
Source Dest Primitive Parameters
MT PA DORMANT_MODE_REQ According to the protocol described in
D0301.
PA MT DORMANT_MODE_REPL According to the protocol described in
D0301.
Table 58: Interface Contents
5.2.10.2 AR Paging Attendant & RG IWF
5.2.10.2.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, …). 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
D0103v1.doc 166 / 168

D0103v1.doc Version 1 6.7.2003
for interception of paging control messages. Only a further check on the respective ICMPv6 message
types is to be performed, mapping the control messages to the appropriate radio channel. What is not
described here is the advertisement mechanisms of paging area information. This is not
5.2.10.2.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.
5.2.10.2.3 Interface contents
Source Dest Primitive Parameters
AR RG PAGING_REQUEST According to the protocol described in
D0301.
AR RG DORMANT_MODE_REPLY According to the protocol described in
D0301.
RG AR DORMANT_MODE_REQ According to the protocol described in
D0301.
Table 59: Interface Contents
5.2.10.3 Interface between Paging Attendant and Paging Agent
5.2.10.3.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.
5.2.10.3.2 Interface mechanisms
Wired Ethernet interfaces the related components, providing transport for ICMPv6 encoded paging
control messages.
5.2.10.3.3 Interface contents
Source Dest Primitive Parameters
PA AR PAGING_REQ According to the protocol described in
D0301.
PA AR DORMANT_MODE_REPL According to the protocol described in
D0301.
AR PA DORMANT_MODE_REQ According to the protocol described in
D0301.
Table 60: Interface Contents
D0103v1.doc 167 / 168

D0103v1.doc Version 1 6.7.2003
6 Summary and Outlook
This Deliverable should be regarded as a baseline document for the whole Moby Dick project, with the
assumption that the presented architecture is for the time being final, but might be enhanced in successor
activities. The Deliverable summarises the work during the first thirty months of the project and includes
a description of generic operational scenario.
The Moby Dick Architecture has three goals which are orthogonal: First, the Internet Protocol is regarded
as convergence layer for mobility management, AAAC, and QoS issues. This requires a lower layer
technology independent solution with the goal to provide seamless mobility compared to the one of
existing networks. Second, Moby Dick will manage resources of the scarce wireless access technology
efficiently, namely TD-CDMA and WLAN and third, the whole concept will be targeted towards a
commercial environment and all the required mechanisms will be added around the IETF AAA concept.
The now starting trial will provide qualitative and quantitative answers to various questions related to
overall feasibility, scalability and further operational aspects.
The Moby Dick architecture is fully IP compliant and a more radical approach as several in various
standardization bodies discussed “ALL-IP” approaches. This choises had been made because backward
compatibility was not an issue.
D0103v1.doc 168 / 168