CHAPTER 1.
INTRODUCTION
¢ This section provides a brief introduction to needs of implementing IP based 4G network.
Virtually all papers with the title ˜Beyond 3G Mobile Networks™ consider IP as the final means of integrating access networks from any technology”wireless or fixed” and the, equally IP-based, core network. This migration from traditional circuit-switched networks toward a packet based IP network infrastructure adds considerably to the pressure to provide commercialized services in this network. Although some of these aspects have been already addressed, there is still a long path to follow before all citizens are able to run ™multimedia communications anytime, anywhere, any style™.
Although transmission capabilities have increased drastically, requests of new upcoming applications have evolved in a similar way. In this sense, the fact that more resources are available does not mean that applications will be able to utilize them when needed”which is especially true when we consider the usage of the relatively scarce radio spectrum. Efficiency within this context does not only denote technology-specific efficiency, but also economic efficiency which will lead to profit maximization”one of the reasons behind the integration pressure towards IP networks. Users paying for privileged service should be treated accordingly. This drives the need to integrate QoS support for differentiated traffic of different users, charging components and AAA architectures in an overall mobility environment. An additional fundamental aspect of these new generation networks covers security, since new communication scenarios will comprise security critical processes like e-administration. On a flexible environment, capable of supporting multiple services dynamically offered to various users, it is essential that multiple security-related aspects are assured, such as privacy of the user information and integrity of the control messages.
This paper describes a vision of these future network architectures and present a architecture supporting mobility, assuring Quality of Service (QoS), and with features required to deploy such a network in a providerâ„¢s framework (i.e. supporting AAA functions enriched with charging).
This paper deals with Pure-IPv6 architecture toward 4G networks, integrating Mobility, QoS and AAA. It supports seamless handover mechanisms across heterogeneous access networks. Mobility-enabled end-to end QoS and AAA mechanisms are enriched with Auditing and Charging (AAAC).
CHAPTER 2.
BASIC NETWORK
ARCHITECTURE ELEMENTS
¢ This section describes the elements required to realize basic network architecture.
The overall network was developed in order to support three different types of access technologies (Ethernet, Wireless LAN and TD-CDMA). The network architecture was developed using three key design principles:
1) 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.
2) The network should be able to provide real-time services with quality comparable to traditional cellular networks.
3) The services should be generally accessible regardless of the access network and uninterrupted during handover (change of point-of-attachment).
The overall network architecture, depicted in Fig. 2.1, includes the following elements:
1) Mobile end-systems which can be equipped with interfaces from different technologies simultaneously. In particular, interfaces to TD-CDMA (UMTS-TDD), wireless LANs (802.11b), and fixed networks (Ethernet) are supported;
2) Access Routers, providing an interface between a wireless and a wired-network domain. These nodes are associated with the traditional concept of a Base Station, the actual access point of 2G and 3G wireless technologies, but enriched with IP capabilities. One Access Router controls one IP subnet, which is directly mapped to one radio cell.
3) Network management servers in the fixed network for mobility management, AAA, Charging, QoS, security and paging issues.
All signaling between these entities is exchanged at IP-layer level, in order to achieve a convergence layer independent of the technology. The mechanisms provided by the entities and their proper interworking provide an architecture which supports a cheap and efficient seamless network access on an heterogeneous environment, in an open manner. The architecture flexibility, resorting only to IP for mobility management, QoS provisioning and AAAC, presents a big step towards an IP dominated 4G network architecture, and will allow easy and simple integration of other access technologies. The architecture is completely independent of the access technology, so it can be adapted to incorporate any future spectrum-efficient wireless technologies, like UWB.
In the Moby Dick architecture, network access is provided by a radio AR, which controls a single radio cell. At IP level, an IP subnet is directly mapped on such a radio cell. So, dynamic mobility management is a process managed at IP-level. To provide seamless mobility competitive to the one already achieved in existing cell networks, FHO is used, with some specific enhancements and associated to context transfer techniques. This approach has the advantage to increase the scope of mobility across cells based on different access technologies. Furthermore, to increase the efficiency of both the mobile end systems and the usage of the (scarce) access medium, and simultaneously to improve, low power consumption, a novel IP paging concept was integrated into the overall architecture. For the provision of QoS, a DiffServ-based model was adopted because of its higher scalability and reduced signalling overhead in this highly dynamical network infrastructure. The association of a DiffServ framework with the use of QoS Brokers (QoSBs) supports quality of service on larger scale. The AAAC support is based on the IRTF AAA Architecture, enriched with charging mechanisms to provide an overall architecture targeted to commercial use.
CHAPTER 3.
MOBILITY SUPPORT
¢ This section describes the methods used to provide mobility to the user..
o Fast-handover.
o Paging.
The purpose of mobility support inside Moby Dick is twofold: implementing FHO procedures, able to operate across multiple networks, and developing paging at the network level.
3.1. Fast-handover
Mobile IPv6 is considered as the basic mobility management scheme for the overall Moby Dick network architecture. While Ëœstandardâ„¢ Mobile IPv6 is deployed for global mobility management (i.e. inter-administrative domain handover) extensions for local mobility management (i.e. intra-administrative domain handover) are required in real-time environments (such as voice communications) for achieving seamless handover, i.e. for the user not to be aware that a handover is being processed. There are several different proposals to enhance handover performance, such as hierarchical and nonhierarchical approaches. The analysis and simulation results of the evaluation in showed that a non-hierarchical FHO approach seems to be the most suitable mechanism for this network.
Generally, a handover is composed of two different types: technology specific lower layer handover (which poses rigid technology specific constrains) and IP handover. The chosen IP FHO approach is independent of the access technology (i.e. TD-CDMA, 802.11b or Ethernet) and follows a Ëœmake-before-breakâ„¢ philosophy: layer 3 handover will be prepared via the existing communication channel, before layer 2 handover is performed. In this way, the handover delay is reduced to the minimum amount of time, which is necessary for the reconfiguration of the interface or changing the interface in case of inter-technology handover. During this preparation phase, the current Access Router is informed about the intended handover and, for the duration of the handover, bi-casts all packets destined for the Mobile Terminal (MT) to the current care-off address and copies them to the new point of attachment. This mechanism reduces packet loss during the handover.
3.2. Paging
The paging architecture aims for reachability support of roaming dormant MTs and routing of data packets (destined to that MT). As a requirement of the standard Mobile IPv6 concept used in the network, an active MT acquires in each cell a different Care-off Address (CoA), which identifies the IPv6 subnet in which the MT is currently located. This CoA is then to be used for registration with the Mobile IPv6 Home Agent (HA). Tracking of the MTâ„¢s location, with the preciseness of an IPv6 subnet (i.e. the cell), is required if packets are to be
routed to a MT. If no packets are to be routed to a MT, keeping this location information updated with the HA (Binding Update messages) is superfluous signalling and power overhead. Location update related signalling costs further increase if the mobile is moving very fast and the geographical size of an IPv6 subnet is small” which may be a realistic scenario for 4G networks. Hence, if no packets are to be routed from the network to a MT, the preciseness of the MT location in the network could be decreased. This can save frequent location updating (binding updates), decrease signalling costs, and save scarce radio bandwidth”as well as a saving the MT battery power. The system has then many advantages in supporting ˜dormant™ nodes, where no traffic is flowing for them.
To allow MT to enter this dormant mode, reducing the sending of location update messages to the network, a mechanism has to be deployed to notify the respective dormant MT of incoming traffic. After the notification that data packets are waiting to be received, the dormant MT must re-activate itself and re-establish detailed routing information with the network. Within the Moby Dick architecture, a Mobile IPv6 managed network would know a dormant MT location with the preciseness of the registered paging area”which can be a cluster of two or more IPv6 subnets”each subnet supported by an individual AR.
According to the basic Mobile IPv6 protocol, it is required to keep paging and the specific MT state maintenance transparent to Correspondent Nodes (CNs) and to the MTs HA. The only nodes, which should be aware of the MT current state (active or dormant) are a dedicated Paging Agent (PA) entity and the MT itself. The motivation for handling paging (both paging areas and related signalling) at the IP layer is to keep the paging protocol within the network, independent of and common to all access technologies. This provides a universal framework to be effectively supported in future heterogeneous access networks.
Furthermore, to allow the deployment of access technology specific dormant mode and paging approaches, mapping of the common and generic IP paging protocol to access technology specific functions has to be allowed in the Access Network. This is readily achieved in Moby Dick by means of a paging control supporting function implemented in the ARs. The PA is responsible of localising a registered dormant MT in case of incoming data destined to it. A paging attendant function is implemented with each AR, supporting paging related signalling as well as mapping between the generic IP paging protocol and access technology specifics. A MT, which decides to switch its state to dormant mode, discovers the responsible PA through the paging attendant function in its current AR, and notifies this PA of its current paging area.
The paging area information is retrieved from Router Advertisement messages, since each AR advertises a specific identifier, indicating the paging area it is assigned to. After this, the MT registers the PA address with its HA by means of a standard Mobile IPv6 Binding Update message carrying the ËœAlternate Care-of Address Sub-Optionâ„¢ (see Fig. 3.2.1). This additional option allows a MT to register an IP address, which is different to the MTs care-of address. From this point of time the MT can enter in dormant mode and can roam within the registered paging area without the need to send location update information to the network. When roaming across paging areas, the dormant MT issues a paging area update message to the PA.
When a CN addresses data packets to a dormant MTs home address, the HA intercepts these packets and forwards them to the PA by means of IP tunnelling. The PA terminates this tunnel, and buffers the initial data packets until the paging process has resolved the MTs current location, and the MT is again able to receive traffic packets. The PA initiates the paging process sending an IP Paging Request message to (the paging attendant in) all ARs of the registered paging area (Fig. 3.2.1). Individual paging attendant functions build link-level paging request messages, which are sent through the respective access technology. The current concept and implementation cover wired Ethernet, wireless LAN and TD-CDMA. On
reception of one of the link-level paging messages, the MT re-activates and reestablishes detailed routing information with the network, notifying the PA and the HA of its current care-of address (Fig. 3.2.1). As a result, the data packets buffered at the PA are forwarded to the MT, and further data packets intercepted at the HA are now directly forwarded to the re-activated MT. Route optimisation, through Binding Update information to the CN, is then also possible.
CHAPTER 4.
QOS ARCHITECTURES
¢ This section provides an insight into the QoS architecture used to provide the guaranteed QoS.
o Overall architecture.
o QoS building blocks.
The QoS architecture has to support end-to-end QoS, easily manageable from the operatorâ„¢s point of view. To achieve this objective, entities and methods had to be defined for the allocation and control of resources in the access networks, able to offer and guarantee end-to-end QoS and maintaining user connectivity and QoS while the MT is moving.
4.1. Overall architecture
A hard constraint of the architecture is the simultaneous support of mobility and QoS. Several IETF QoS frameworks were considered before designing the final QoS architecture, taking this integrated vision in consideration. The IETF IntServ approaches uses per-flow resource reservation and RSVP signalling, but is mobility unaware and has well-known problems of scalability and complexity. The IETF DiffServ approach uses flow aggregation per Class of Service based on priorities, and although it is scalable, it does not offer end-to-end guarantees and has no specific provision for mobility. Although more complex approaches are possible, such as the mix of IntServ (at network boundaries) with DiffServ (in the core), none seems to simultaneously support mobility and execute QoS reservations. Thus, the architecture developed resorts to the use of a DiffServ approach, combined with innovative use of QoSBs, to be able to control and manage the available resources in an efficient way.
This architecture is also able to assure that the Service Level Agreement (SLA) contracts are not violated (neither by the users nor by the service provider). The architecture relies on the concept that the user will be provided with a service contracted with the provider. The QoSBs are in charge of allocating resources in the access network, per user and per service (signalled by the CoS-Class of Service), according to the contractual information to the user, and further manage flow aggregation of resources in the core network.
4.2. QoS building blocks
Fig. 4.2.1 presents the building blocks of the several elements of the QoS architecture: the MT, the QoSB, and the AR. The Differentiated Services Code Point (DSCP) Marking Software located in the MT marks outgoing traffic according to globally defined rules. A Layer 2 (L2) QoS entity covers specific physical-layer QoS aspects, dependent on the access technology (mostly important for the radio access). At the Access Router, a L2 QoS entity acts accordingly and is associated to a QoS Mapping function. This block includes the mapping between DiffServ QoS parameters and the appropriate parameters of the access network (TD-CDMA is currently the only technology, which supports layer-2 QoS reservations). The
bandwidth resources for the cell are controlled in AR by using the respective DiffServ building blocks (classifier, meter, shaper, and policer) and it is the place where guarantees are imposed.
The QoSB has the overall resource control and will guarantee the overall QoS resources. Traditional DiffServ support for shaping and policing of the traffic to be sent from and to the MT is another block of the QoS architecture. The QoS Manager performs critical control functionalities in relation with shaping, policing, and mobility. Policing functionality is performed when a new traffic flow from the MT is trying to gain access to the Core Network.
The QoS Manager also is periodically sending reports of the use of resources to the QoSB. When a user initiates a FHO to move to a new AR, it is also the QoS Manager that starts a procedure involving the old and new ARs, and the old and new QoSBs. The QoSB is the core entity in the QoS architecture, performing most control decisions, able to operate on a heterogeneous environment. Its core, the QoSB engine, includes all decision algorithms for the QoS management of the network. The QoSB engine operates on an abstraction of the ARs: a Virtual Router Module provides this uniform interface to the QoSB engine and maps the control decision into the specific network commands to each AR.
The QoSB incorporates two interfaces: an AAAC interface, to receive authorization information from the AAAC server during the registration process and a QoSB Interface for exchanging information with other QoSBs. For handling QoS during handover, a Mobility Interface is defined. Three different functions are dedicated to aspects of control and network monitoring: a NetProbe (monitoring network status, collected in the NetStatus database), a RouterInfo (the module that obtains router information, either manually or automatically), and an NMSInterface (that allows the Network Management System entity to define the network resources that can be controlled by the Broker).
CHAPTER 5.
AAAC ARCHITECTURE
¢ This section provides details of the AAAC architecture used to implement authorisation, authentication, accounting, auditing and charging in Moby Dick 4G networks.
o Basic support components.
Session concept.
User profile.
o Metering, accounting, charging and auditing.
The migration from traditionally circuit-switched networks toward a packet-based wireless IP network infrastructure provokes a demanding pressure to provide packet-switched voice and data services which can be regarded as current key drivers for the development of new communication systems and technologies. In both, the wired Internet and in the future wireless packed-based mobile Internet, an efficient economic concept is still an open issue. Still under research are associated mechanisms required to describe, define and detect IP services and, as a consequence, determine service usage on a finer granularity and, finally charge for this usage in an efficient manner. Along with the Internet Engineering and Research Task Forces™ (IETF, IRTF) AAA work, a promising base for these missing functions and mechanisms has been defined. Although basic mechanisms required are available and widely understood, their efficient and scalable integration” especially in the beyond 3G mobile environment”is still a point under research.
In order to close this missing gap, the Moby Dick architecture has implemented successfully basic elements and concepts of the IETF and IRTF AAA mechanisms, extended where required. An important issue covers the enhancement of the IRTF AAA architecture with charging and auditing functionality. The Moby Dick AAAC System defines the formerly known AAA Server with specific extensions, thus providing metering, charging and auditing
functions. Auditing enables further functions with respect to evaluations of audit trails generated by the AAAC System and others (cf. Fig. 5.1.1). In Moby Dick, different AAAC Systems communicate with each other via the Diameter AAA Protocol i.e. the AAAC Server in the home domain (AAAC.h) uses the Diameter base protocol to communicate with the AAAC Server in the foreign domain (AAAC.f).
With the help of well-defined Application Specific Modules (ASM), an AAA server can communicate to various entities. In such a case, the external entity acts as a quasi AAA Client and communicates with the AAAC System using Diameter. These ASMs can either be integrated into an AAA server or in the external entity. As shown in Fig. 5.1.1, the enhanced generic AAAC Architecture is applied to the QoS-enabled Mobile IPv6 environment resulting in the instantiation of the ASM and respective service equipments.
The Moby Dick architecture includes an ASM for a Mobile IPv6-centered Attendant, as well as one for a QoSB. In this particular application, the service user is the MT on behalf of the human user. It is assumed that any request with respect to authentication and authorization may originate from alternate AAAC Systems, from the MT (therefore, the user), or from the service being supported by the AAAC System, such as the QoSB for a QoS-enabled service or from AAAC Client. The software architecture is modular, thus, separating different processes, e.g. the User Registration module handles the registration process, and other modules execute MIPv6, and Fast handover, accounting. Finding a solution to the problem of authenticating a mobile user posed a major challenge. This was solved using a novel approach to fast handover. In this approach the context of the user is transferred between associated access routers (AR) before such a fast handover is executed.
5.1. Basic support components for AAAC
The key support concepts for the enhanced AAAC Architecture include the session model, service definitions, the user profile, and a QoS Interaction model, each of which is discussed below.
5.1.1. Session concept
The concept of sessions plays an important role in the Moby Dick AAAC environment. The notion of a session ID is introduced to bind together a set of related activities. Each session is associated with a unique session ID and is linked to one user with a unique user ID. The session ID together with the user ID allows a provider to combine accounting data for the different activities and generate a bill.
The AAAC Client creates a new session with a new session ID after several events, e.g. a user switches on his MT and requests authentication and authorisation. After these actions, the AAAC Client produces a Diameter ˜start™ message, which is propagated to the AAAC.h Server. It will generate the first entry for this new session in the accounting database. Within a running session, a customer can”according to his Service Level Agreement (SLA)”use services offered by the operator. It is also possible that a user has more than one open session. During a session, the AAAC Client produces Diameter ˜interim™ messages, containing accounting data that will be written to the accounting database by the AAAC.h Server. Every authorization is bound to a certain lifetime, and before the lifetime expires, the mobile terminal must perform a re-authentication. When a session is closed, the AAAC Client produces a Diameter ˜stop™ message and the last entry in the accounting database is created.
5.1.2. User profiles
User Profile (UP) is defined as a data record of all user-specific data. This includes authentication data, data of the SLA and auditing information. The UP is unique and is initially created, when the user signs his SLA, which allows or prevents the customer to use services. The UP is stored in the AAAC server of that Moby Dick operator with whom the customer has an SLA established. This Moby Dick operator will offer its services in a certain geographical region, which is referred to as the home domain. The user-specific information of the UP is needed to identify properly the customer. The next part of the UP contains tariff IDs f or each service being offered. These tariff IDs are used by the charging component to select the appropriate tariff function. In addition”for auditing purposes” the UP contains the level of availability guarantee and guarantee of success registration and session setup. Those guarantees are valid for home users only.
Finally, the UP contains QoS-related information, called the Network View of the User Profile (NVUP). The NVUP contains DSCPs of those services a user is allowed to use. In the case of a roaming user, the NVUP is transferred to the AAAC.f. The foreign operator will map DSCPs to actual services, according to its service table.
5.2. Metering, accounting, charging, and auditing
After having seen which basic components offer support to the AAAC Systemâ„¢s implementation, it is important to detail the metering of user data, the task of performing accounting, the charging process, and the auditing scheme.
5.2.1. Metering
Measuring network traffic has a long history within the IETF. A working group within the IETF, the Real Time Traffic Flow Measurement (RTFM) Working Group, was founded in 1995 and developed architecture for traffic measurement. Central to this architecture is the notion of traffic flows. An IETF RTFM flow is a bi-directional stream of packets between two endpoints, each defined by a set of attribute values, which can be determined flexibly. Via these flows, the notion of a virtual Ëœconnectionâ„¢ is introduced to the IP layer. Historically, this architecture was designed for accounting issues and as a base for further charging and billing processes in order to detect and economically handle the resource/service usage more accurately. Heart of the traffic flow measurement architecture is the Meter. Meters are placed at measurement points determined by the network operator. Each meter selectively records network activity as directed by its configuration settings. It can also aggregate, transform, and process the recorded activity before the data are stored. Processed and stored results are called the usage data. In Moby Dick the IETF RTFM metering framework is used. In order to fulfill Moby Dick specific requirements, the existing IETF RTFM reference architecture has been modified and integrated into the overall AAA Framework. An AAA/Meter interface was implemented in order to let the AAAC Attendant access the accounting database and to configure the meter.
5.2.2. Accounting
Accounting defines the process of collecting data on resource consumption. Used resources are metered by the metering infrastructure after receiving a trigger from the AAAC Attendant (also called AAAC Client) at the start of a session. The AAAC Client receives metering data and sends it to the AAAC.h via AAAC.f. The accounting data are aggregated at the AAAC.h and made available to the charging and auditing entities. The AAAC Attendant receives answers from AAAC.f for AA requests issued. In case of a negative answer the answer is forwarded to the meter client and no accounting takes place. In case of a positive answer the AAAC Attendant configures its accounting functionality according to accounting policies contained in the AA answer. If no such policies are present it configures accounting according to a default configuration specified before the start of the client. If errors may occur after forwarding the AA answer, the client immediately generates a accounting start request and sends it to the AAAC.f.
During a session runtime the attendant generates interim accounting messages and sends them to the AAAC.f. The AAAC Attendant offers an interface to the metering
functionality on the AR. It sends a message to start a meter”containing a filter spec and all other configuration parameters”when accounting is started. It indicates the meter to stop and sends messages containing a filter spec or handle previously received to stop metering for that particular session.
5.2.3. Charging
Charging calculates the price for a given service consumption based on accounting information and the SLA. It maps technical values into monetary units by applying a tariff. The accounting data together with the user profiles covers all information needed by the CM (Charging Module). Charging is session-based, i.e. only closed sessions are being used. After selecting new accounting data, the CM extracts the user (in more detail, the User ID) associated with the current session (Session ID). The User ID is the key index used by the CM to select the appropriate SLA from the user profile database. At this stage, the CM has obtained all necessary information to apply the tariff function for a given customer and a given session. The result of this charge calculation is written to and stored in the charging database located in the AAAC.h.
5.2.4. Auditing
Moby Dickâ„¢s auditing objective covers the detection of a SLA violation. Moby Dick defines the following commitments: availability, success of user registration, and success of session setup. The availability guarantee defines the availability of Moby Dick entities responsible for user registration, session setup, and service delivery, in unit of time or in percentage within each period of a predefined length. Those entities encompass the AAAC Client, the AAAC Server, the QoS Manager, and the QoSB. The success of a user registration within <n>minutes is guaranteed, if at least <r> valid retries have been made with a valid Network Access Identifier (NAI) and respective credentials. The guarantee is applied only to users in the home domain. To determine whether registration attempts are successful each AAAC Client must log all valid registration requests and responses. The success of a session setup within <n> minutes is guaranteed, if at least <r> valid retries have been made with valid DSCP. The guarantee is applied only to authenticated users in the home domain. To determine whether session setups are successful each QoS Manager must log all valid service requests sent to the QoSB and its corresponding responses.
CHAPTER 6.
MOBILITY, QUALITY OF SERVICE
AND AAAC INTEGRATION
¢ This section provides an insight into how the features such as mobility, QOS and AAAC are integrated into a single architecture.
o Registration.
o Authorisation/session setup.
o QoS enabled handover.
Given the overall concepts described so far, three distinct situations arise in the overall architecture which are described in greater detail in Section 6.1: (i) registration” in this architecture, a MT/User may only start using network resources after authentication and authorisation, as in today™s cellular networks; (ii) authorization”the user has to be authorized to use specific services; and (iii) handover” the user needs to have its existing resources reservations during a dynamic change of the AR.
6.1. Registration
The Registration (see Fig. 6.1.1) process (AAA and Mobility) is initiated after a CoA is acquired by the MT via stateless auto-configuration, using unique layer-2 identifiers to avoid the need for Duplicate Address Detection. However, getting the CoA does not entitle the user to consume resources besides registration messages” but allows emergency calls. For accessing the network otherwise, the MT has to start the authentication process by sending the authentication information (message 1, Fig. 6.1.1) to the AR. That request will be then forwarded to the AAAC System (message 2) responsible for that AR.
In a roaming case, which is more complex, the AAAC system of the visiting domain will issue an AA registration request to the MTs home AAAC (message w). This AAAC checks if there is a formal contractual relationship between the administrative domain this request comes from and the own administrative domain. Then, in case of a positive result, the home AAAC performs authentication by verifying the provided credentials. In the positive case, the home AAAC sends to the HA a request for that user (x) to which the HA answers (y).
Then, the home AAAC finally answers the Domain A AAAC (z). One attribute of this positive acknowledgement is the user profile containing all required information to provide the services requested in the foreign domain.
The NVUP will be forwarded from the AAAC server to the QoSB (3b), and the rest of the profile will be sent to the AAA Attendant located at the AR (3a) (the NVUP contains all required information relevant to the service provisioning, while the metering and security related information will be forwarded to the AAA Attendant). The AAAC will also inform the MT of the successful registration, via the AR (3a and 4). Afterwards, the AR will initiate accounting for that user, and informs the AAAC (message 4a). The authentication process is thus completed.
6.2. Authorization/session setup
Fig. 6.2.1 shows how each network service is authorized. First, the MT sends a packet (message 5, Fig. 6.2.1) (either with real information or just a dummy packet) with the DSCP code marked to request a particular service. If the requested packet does not match any policy already set in the AR, the AR issues a request (6) to the QoSB, through the QoS manager (5a).Upon analysing the request, and based on the User NVUP and on the availability of resources, the QoSB eventually decides on an answer to the AR (7).
The AR QoS manager will then configure the AR with the appropriated policy for that User/MT service (7a), or informs the User/MT of a service denial (7b). After (7a), any other packet sent from the MT that matches the configured policy rule will be able to cross the network (8). Non-conformant packets will restart the authorization process once more. Upon reaching the end domain where the other User or CN is, the marked packet starts another QoS authorization process (8a). The QoS manager on this AR will send a policy query to the QoSB (9), to which the QoSB answers (10).If there are resources, this answer is a positive answer and the QoS Manager will configure the AR (10a) with the right policy, otherwise, the AR will send back a service denial message (10b). After (10a), the next packets matching the installed policy will be able to reach the other terminal (11). With this approach both access networks provide contracted levels of QoS; core network is then monitored to check if the expected performance is being provided, in a DiffServ approach.
6.3. QoS enabled handover
One of the most difficult problems when dealing with IP mobility is assuring a constant level of QoS. User mobility is assured in our network by means of FHO techniques in combination with message exchange to and between the QoSBs during the handover. When a MT starts losing signal strength to the current AR (Ëœold ARâ„¢) (message 1, depicted in Fig. 6.3.1), it starts a handover procedure to a neighboring AR (Ëœnew ARâ„¢) from which it receives a beacon signal with the network prefix advertisement (2). The MT builds its CoA and initiates the handover procedure, sending an IP-handover request to its new AR, but still through the old AR (3). The FHO module in old AR will forward this request to its QoS Manager (3a) and to the FHO module on the new AR (known by the network prefix) (4a).
The QoS Manager immediately forwards this request to the QoSB (4b) (Ëœold QoSBâ„¢). The old QoSB sends a handover request to the new QoSB (5), indicating the Userâ„¢s NVUP and the list of services currently being used. Basically, this acts as a context transfer from the old QoSB to the new QoSB. With this information, the new QoSB will verify the availability of resources, and sends a message to the QoS Manager on the new AR (6) indicating whether the MT may or may not perform the handover. This mechanism allows the QoSB to abort the handover due to QoS constraints (e.g. missing bandwidth resources). If the handover is possible, the QoS Manager then sends this information to the FHO module (6a) and performs the configuration of the new AR to accommodate the MT when it moves.
Meanwhile, the FHO module sends the handover reply back to the FHO module on the old AR (7). Upon receiving this message, the old AR sends it to the MT (8).When the answer is positive, the MT sends a handover execute to the old AR (9), to which the old AR reacts
initiating bi-casting, setting up a timer (9a) and replying to the MT (10). The MT may now perform a successful layer 2 handover (10a), because all the layer 3 resources were previously reserved, which results in sending a neighbour advertisement to the new AR (12). The new AR starts an accounting process in the AAAC system for that user (13). To complete the handover process, the MT must send the binding update to itâ„¢s HA (14) that replies with a binding acknowledge. Meanwhile, the bi-casting timer on the old AR expires (10b), which also makes it send all accounting information relative to that user to the AAAC system (11). The MT has now completed the handover to the new AR. The CN will notice the handover by receiving IP packet with the new CoA. IP packets will be sent to the new address. If the handover is done inside the domain of only one QoSB, that is, if the QoSB controlling the new AR and old AR is the same, then message 5 will not exist. Everything else is exactly the same. Notice that AAAC attendants are also informed of the handover and the current user AAAC parameters (for metering, e.g.) are exchanged directly via the Handover initiate messages (message 4a)
CHAPTER 7.
CONCLUSION
This advanced architecture being able to provide diversified services in heterogeneous access infrastructures: wired LANs, wireless LANs, and TD-CDMA cells. This architecture is a first approach to 4G systems relying on the IPv6 protocol, and replaces most technology dependent tasks by IP-oriented approaches. This paper provides a snapshot of the architecture, showing how proposals under development in the IETF were re-used and mastered in order to achieve this goal. The key problems solved by this architecture are concerned with efficient handover solutions across different cells, which require an efficient involvement of the three traditionally separated disciplines QoS, AAAC and management structure. An innovative IP paging concept was also presented and discussed. The architecture identifies similar elements across all access technologies, but maintains enough flexibility to support optimisations for physical layers. This architecture is conceptually flexible and open and provides a clear separation between technology and administrative domains. The Moby Dick project provides a simple, flexible architecture being able to support multimedia service provision in future 4G networks mobility management. The architecture puts emphasis on the use of Mobile-IP and its FHO optimisations, a DiffServ-based QoS transport infrastructure managed by QoSBs, and a coherent AAA.
The approach does not cover the possibility for backwards compatibility to 3G networks. However, by modifications of the Gateway GPRS Support Node (GGSN in 3G Mobile Communication) to act as an AR, the UMTS Terrestrial Radio Access Network (UTRAN) can be seen as an additional access technology.

REFERENCES
[1] Jurgen Jahnerta, ËœMoby Dick 4G architectureâ„¢, Elsevier/computer communication, vol. 28, January 2005, page nos : 1014-1027
[2] Moby Dick: Mobility and Differentiated Services in Future IP Network; EU Project IST- 2000-25394, January 2004.
[3] istmobydick.org
[4] sciencedirect.com
[5] nalanda.nit.ac.in
[6] ietf.org
[7] irtf.org
[8] nec.com
[9] motorola.com