lte document v2 - aroma doc… · then, this document identifies the ... sae/lte, previously...

Copyright © 2006-2007 AROMA Consortium 16/4/2008

AROMA

AROMA

AROMA IST-4-027567

Studies carried out in the context of LTE/SAE architecture

Date of Delivery to the CEC: 18-4-2008

Editor: F. Casadevall (UPC)

Work package: WP3

Nature: Report

Version: 1

Total number of pages: 39

Abstract: This report summarizes the studies carried out in AROMA concerning QoS and mobility management for the mobile transport network in the context of LTE/SAE-based architectures. In particular, it is assumed that the QoS model in the mobile transport network is based on the diffServ architecture extended with the Bandwidth Broker (BB) functionality for resource control and the mobility management combines IP mobility with the label switching path functionality provided by MPLS. Keyword list: LTE/SAE architecture, QoS evaluation; Bnadwidth Broker, MPLS, DiffServ.


DISCLAIMER

The work associated with this report has been carried out in accordance with the highest technical standards and the AROMA partners have endeavoured to achieve the degree of accuracy and reliability appropriate to the work in question. However since the partners have no control over the use to which the information contained within the report is to be put by any other party, any other such party shall be deemed to satisfied itself as to the suitability and reliability of the information in relation to any particular use, purpose or application.

Under no circumstances will any of the partners, their servants, employees or agents accept any liability whatsoever arising out of any error or inaccuracy contained in this report (or any further consolidation, summary, publication or dissemination of the information contained within this report) and/or the connected work and disclaim all liability for any loss, damage, expenses, claims or infringement of third party rights.

Studies carried out in the context of LTE/SAE architecture Page i


Table of Contents

1 INTRODUCTION ............................................................................................................................. 1 2 REFERENCE ARCHITECTURE ..................................................................................................... 2

2.1 3GPP REFERENCE FRAMEWORK ....................................................................................... 2 3 AROMA ALL-IP REFERENCE NETWORK ARCHITECTURE: LONG TERM SCENARIO .......... 5

3.1 SCOPE AND KEY DRIVERS................................................................................................... 6 4 RESOURCE MANAGEMENT IN THE TRANSPORT NETWORK LAYER FOR AN IP–BASED LTE RAN ................................................................................................................................................. 8

4.1 FUNCTIONAL MODEL ............................................................................................................ 8 4.2 BASIC ASSUMPTIONS AND STATE OF THE ART ................................................................. 9 4.3 RESOURCE MANAGEMENT & QOS FRAMEWORK........................................................... 13 4.4 MOBILITY FRAMEWORK ..................................................................................................... 16

4.4.1 HIERARCHICAL MOBILITY MANAGEMENT AND QoS FRAMEWORK...................... 19 4.4.2 QOS PERFORMANCE DURING IP HANDOVER......................................................... 22

5 CONCLUSIONS ............................................................................................................................ 36 6 REFERENCES .............................................................................................................................. 37 LIST OF ACRONYMS........................................................................................................................... 38

Studies carried out in the context of LTE/SAE architecture Page 1


1 INTRODUCTION The AROMA project aims at providing tangible contributions, in terms of resource management, for the future all IP heterogeneous wireless systems, which will take into account 2G /2.5/3G (e.g. GERAN, UTRAN ) and 3.5G networks (e.g. HSDPA), including the newly emerging RAN technologies (e.g. WLAN , WIMAX ) and services for the 2010-2015 time frame. In that context, the reference QoS architecture envisaged in the project is aligned with the 3GPP R6 Network Architecture standards. However, being the migration of the Transport Network Layer (TNL) to an All-IP architecture one of the issues addressed in the project, it could be interesting to study the performances of this new TNL configuration in the context of a more advanced QoS architecture such as the envisaged in the LTE/SAE concept of the 3GPP. Then, this document identifies the topics studied under the assumption of the LTE/SAE architecture and summarizes the main obtained results. It is not worthless to mention here that all the concepts and results presented in this document were previously reported in deliverables D05, D09, D12 and D18. The document is structured in five sections. After this short introduction, in section 2 and 3 the document summarizes the most relevant characteristic of the 3GPP reference network architecture, in the context of the topics addressed by the AROMA project, as well as the long-term vision for the reference architecture proposed in AROMA respectively. The aim of this part is to present and capture the major trends in network evolution coming from 3GPP SAE/LTE, previously described in section 3 of deliverable D05 and section 2.2 of deliverable D18. From these studies, three major key drivers were identified for the envisaged AROMA E2E QoS approach in the context of long-term network architecture. These key drivers are:

• Multicell Radio Resource management for evolved Node B • Radio and IP transport coordination • IETF IP solutions for mobility

The first topic was not addressed in the project because at the time of proposing and developing AROMA, the envisaged evolved radio access technologies were still under development in 3GPP forum. As a result AROMA was mainly concentrated in GERAN, UTRAN; WLAN and WIMAX radio access technologies. In relation to the Radio and IP transport coordination, a new framework called CARM (Coordinated Access Resource Management) was developed in the AROMA project. However, this new concept could be applied at both R6 and LTE/SAE architectures, and AROMA selected to concentrate the CARM studies by assuming R6 network architecture in order to provide results at medium-term, due to the STREP nature of the project. Details on the studies carried out in the CARM framework can be found in section 3 of deliverable D18. The IETF IP solutions for mobility in the context of LTE/SAE were addressed in AROMA by King’s College London (KCL), and the proposed solutions are reported in section 4 of this document, which describes the considered framework concerning QoS and mobility management for the mobile transport network and summarises the studies carried out in the context of the LTE/SAE-based architectures. These results were previously reported in section 7 of the deliverable D18. Finally, section 5 synthesizes the main conclusions extracted from the studies carried.



2 REFERENCE ARCHITECTURE The envisaged network architecture in AROMA encompasses heterogeneity in the radio access domain. In this sense, UTRAN, GERAN and WLAN are mainly considered as potential Radio Access Technologies (RAT) according to specific deployments and scenarios. Coordination and interworking of such different RATs in terms of Common Radio Resource Management (CRRM) is stated as a key driver of the AROMA project. In addition to that, the progressive introduction of IP technology in the mobile network also constitutes a main pillar in the way to the definition of more efficient and less complex network architectures capable to accommodate such radio access heterogeneity. Next, the control and interworking of those IP-based functionalities (e.g. QoS, mobility) with (common) radio resource management is another key driver of the project. In this section, the reference architecture considered in AROMA encompassing all aforementioned key drivers is described.

2.1 3GPP REFERENCE FRAMEWORK Network architecture considered in AROMA is basically aligned to release 6 of the 3GPP specifications. However, such as it has been mentioned previously, the progressive introduction of IP technology in the mobile network constitutes one of the topics addressed in AROMA project. In that context, some work related to resource management and mobility issues, assuming a more advanced QoS architecture like the envisaged in the LTE/SAE concept of the 3GPP, has been also carried out in the project. Just in order to fix the relevant aspects of the framework where these studies were conducted, this section provides a brief explanation about the main details of the 3GPP System Evolution Architecture (SAE). The description includes an overview of the UMTS architecture in terms of functional entities and interfaces for the Evolved-Universal Terrestrial Radio Access (E-UTRA) [1], [2], [3] . It is important to stress here that the functional entities and interfaces mentioned hereafter are those that are potentially relevant for the definition of the AROMA reference architecture so that a complete description of the UMTS network architecture is out of the scope of this document. 3GPP System Architecture Evolution (SAE) & UTRAN Long Term Evolution (LTE) The objective of Evolved UTRA and E-UTRAN is to develop a framework for the Long-Term Evolution (LTE) of the 3GPP radio-access technology towards a high-data-rate, low-latency and packet optimized radio-access technology. In parallel, a feasibility study [4] for 3GPP System Evolution Architecture (SAE) devoted to develop a framework for an evolution or migration of the overall 3GPP system to a higher-data-rate, lower-latency, packet-optimized system that supports, multiple RATs has also been carried out. In summary, the SAE evolution is mainly guided by the following requirements [4]: • Overall architecture impacts stemming from requirements coming out from study item on

Radio Evolution ( [2] [3]). • Overall architecture impacts stemming from the work on an All-IP Network (AIPN) [5] • Overall architecture aspects of supporting mobility between heterogeneous access

networks, including service continuity.



Figure 1 depicts the base line high level architecture for the evolved system and the main reference points for interworking to legacy 3GPP or non-·3GPP access networks . As shown in the figure, the SAE/LTE architecture encompasses an Evolved Radio Access Network (E-RAN) and an evolved packet core. CS Domain is not shown in the legacy 3GPP core network since the focus of the SAE/LTE is on the PS domain with the assumption that voice services are supported in this domain. The PCRF function shown in the figure corresponds to the merging of PDF and CRF functions. This merged approach was specified as part of 3GPP Release 7.

TrustedNon 3GPP IP Access

UTRAN

GERAN

IMS

PS Domain

PCRF

HSS

Iu-PS or Gb

Iu-PS

E-UTRAN

SAE/LTE

Evolved Packet Core

MMEUPE

WLAN 3GPP IP Access

PDN(IP networks)

S1 S5a

S3 S4 S6 S7

Gi

Mb/Gi

Rx+

3GPP Core Network

3GPPAnchor

SAEAnchor

S5b SGi

SGiIASA

ePDG

WLAN AN

S2bS2a

TrustedNon 3GPP IP Access

UTRAN

GERAN

IMS

PS Domain

PCRF

HSS

Iu-PS or Gb

Iu-PS

E-UTRAN

SAE/LTE

Evolved Packet Core

MMEUPE

WLAN 3GPP IP Access

PDN(IP networks)

S1 S5a

S3 S4 S6 S7

Gi

Mb/Gi

Rx+

3GPP Core Network

3GPPAnchor

SAEAnchor

S5b SGi

SGiIASA

ePDG

WLAN AN

S2bS2a

Figure 1: Logical high level architecture for the evolved system [4]

The main logical elements introduced in the SAE/LTE architecture are: a Mobility Management Entity (MME), a User Plane Entity (UPE) and an Inter Access System Anchor (Inter AS Anchor), which main functions are summarised hereafter: • MME. It contains the main control plane functions needed in a mobile access network. In

particular, MME is intended to: o authenticate the user, o check the authorization whether the UE may camp on the tracking area or on

the mobile network, o generate temporary identities and allocate them to UEs, o manage and store UE context (for idle state: UE/user identities, UE mobility

state, user security parameters). • UPE. It contains the main data plane functions for handling mobile terminals sessions. In

particular, UPE is intended to: o terminate the downlink data path for idle state UEs, o trigger/initiate paging when downlink data arrive for the UE, o manage and stores UE contexts, e.g. parameters of the IP bearer service or

network internal routing information, o perform replication of the user traffic in case of interception.

• Inter Access System Anchor (IASA) that is logically split into the 3GPP Anchor and the SAE Anchor. The former is charge of anchoring the user plane for mobility between the



2G/3G access system and the LTE access system and the latter anchors the user plane for mobility between 3GPP access systems and non-3GPP access systems.

Figure 1 also shows and identifies some reference points. In particular: • S1 accounts for the interface between evolved radio access and packet core. It provides

access to E-RAN radio resources for the transport of user plane and control plane traffic. • S2a/b, S3 and S4, devoted to support interworking with 3GPP and non-3GPP access

systems. In particular, both S3 and S4 are intended to enable inter 3GPP access system mobility between the legacy GPRS core (i.e. 3GPP R6 CN) and SAE/LTE. Among them, S3 is more focused in user data forwarding and bearer information exchange while S4 provides the user plane with related control and mobility support.

• S5 provides the user plane with related control and mobility support between MME/UPE

and Inter AS Anchor within the SAE/LTE. The existence of S5 depends on whether MME/UPE and Inter AS Anchor are combined into one entity.

• S6 and S7 are control interfaces. S6 enables transfer of subscription and authentication

data for authenticating/authorizing user access to the evolved system (AAA interface) while S7 provides transfer of (QoS) policy and charging rules from PCRF to the corresponding enforcement entities within the evolved packet core.



3 AROMA ALL-IP REFERENCE NETWORK ARCHITECTURE: LONG TERM SCENARIO

The long-term vision for the reference architecture proposed in AROMA is aimed at capturing the major trends in network evolution coming from 3GPP SAE/LTE. In this sense, the main aspects of the reference architecture envisaged as long-term vision are: • IETF-based solutions for session, mobility and QoS are used in the access network. That

is, 3GPP R6 core network protocols and functional elements (i.e SGSN, GGSN) may not be retained in the evolved packet core.

• Flat network hierarchies for the overall network are considered: user traffic processing nodes are kept at minimum (e.g. user plane traffic only processed at the evolved Node-B and at a single network node within all evolved access network).

• Data and control planes are definitively separated in the evolved access network. • Several models for the allocation of Radio Resource Management functions can be used

(e.g. RNS server or distributed RRM in evolved Node-Bs). • Interworking with legacy 3GPP systems is possible through either “loose” (i.e. by means

of core network interfaces) or “tight” (i.e. radio level coordination) coupling approaches. Pros and cons of these interworking possibilities are for further study.

Moreover, at the time of proposing and developing the AROMA project, the envisaged radio access technologies were still under development in 3GPP. Thus, AROMA did not target to analyze 4G radio access technologies. Figure 2 illustrates the main aspects of the reference architecture considered in AROMA for this long-term scenario.

MSC Server

RNC

BSC

GANC

NodeB

AP

BTS

WLAN

GERAN

SGSN

GGSN

MGW

IP Transport network

UTRAN R6

3GPP CN R6(PS and CS domains)

E-NodeBRNS functions

UPE/MME/Inter AS anchor

All-IP access network

“loose” interworking

“tight” interworking

MGW

IMS

PDNnetworks

PDNnetworks

PSTNnetworks

PSTNnetworks

MSC Server

RNC

BSC

GANC

NodeB

AP

BTS

WLAN

GERAN

SGSNSGSN

GGSNGGSN

MGWMGW

IP Transport network

UTRAN R6

3GPP CN R6(PS and CS domains)

E-NodeBRNS functions

UPE/MME/Inter AS anchor

All-IP access network

“loose” interworking

“tight” interworking

MGWMGW

IMS

PDNnetworks

PDNnetworks

PSTNnetworks

PSTNnetworks

Figure 2: Long-term architecture for all-IP network considered in AROMA



3.1 SCOPE AND KEY DRIVERS In terms of QoS architecture, the main aspects retained from the long-term architectural framework are summarized in Figure 3. As shown in the figure, the network architecture is basically designed around an evolved base station (Evolved Node-B in the figure) that includes all radio-related functionalities and an evolved core network represented in the figure by a single network node denoted as Access Gateway (aGW). Notice that the aGW would comprise the three logical network functionalities mentioned in section 0. The interfaces between the core network entities and the evolved base stations are designed to be supported over an IP-based transport network that is referred to as Transport Network Layer (TNL).

aGW ?

PSTN/ISDN

MGW

IMS ServicesExternal PDN

Evolved Node-B ?

IP backhaul IP transport network

MMEUPE

RRCBorder GW

Inter ASanchor

Aligned to 3GPP SAE/LTE

aGW ?

PSTN/ISDN

MGW


Evolved Node-B ?


MMEUPE

RRCBorder GW

Inter ASanchor

Aligned to 3GPP SAE/LTE

Figure 3: Network architecture for AROMA long-term vision

In summary, in such long-term vision context, E2E QoS solutions should rely on the following key drivers:

• Multi-cell RRM. Current design trends towards flat network architectures make most RRM

functionality to be moved towards the edge of the network (i.e. evolved Node-B). However, coordination of those evolved Node-Bs in terms of overall network QoS performance remains a crucial aspect (e.g. admission control decisions not just relying on the status of a single node-B because of the potential movement of the terminal to another nodeB, support of fast handover mechanisms between nodeBs, etc.).

• Introduction of QoS and mobility solutions based on IETF protocols. • Radio and IP transport coordination, that is, the deployment of QoS control mechanisms

(e.g. admission control, traffic engineering, etc.) considering both radio and IP transport resource availability.

Figure 4 illustrates the AROMA scope for E2E QoS in the long-term scenario, highlighting the above mentioned key drivers for E2E QoS solutions.



PSTN/ISDN

MGW


Evolved Node-B (?)


RRCBorder GW

radio

IP nativeIP transport/native?

Access network e2e QoS

RRM

Key DriversMulti-cell RRMIETF IP solutions for mobility and QoSRadio and IP transport coordination

aGW ?

MMEUPE

Inter ASanchor PSTN/ISDN

MGW


Evolved Node-B (?)


RRCBorder GW

radio

IP nativeIP transport/native?

Access network e2e QoS

RRMRRM

Key DriversMulti-cell RRMIETF IP solutions for mobility and QoSRadio and IP transport coordination

aGW ?

MMEUPE

Inter ASanchor

Figure 4: E2E QoS approach in the long-term network architecture

In particular, in the context of LTE/SAE system architecture, AROMA has basically been focused in the introduction of QoS and mobility solutions based on IETF protocols for an IP-based TLE-RAN, because AROMA did not perform any study related to the envisaged radio access technology for LTE, such as been mentioned previously. Moreover in relation to the Radio and IP transport coordination key driver, even though a new framework called CARM (Coordinated Access Resource Management) has been developed in the AROMA project, this new concept could be applied at both R6 and LTE/SAE. Then AROMA has selected to concentrate the CARM studies in assuming R6 network architecture in order to provide results at medium-term due to the STREP nature of the project. Details on the studies carried out in the CARM framework could be found in deliverable D18.



4 RESOURCE MANAGEMENT IN THE TRANSPORT NETWORK LAYER FOR AN IP–BASED LTE RAN

This section describes the considered framework concerning QoS and mobility management for the Transport Network Layer (TNL) and summarises the AROMA studies carried out in the context of the long-term network architecture described in previous section.

4.1 FUNCTIONAL MODEL In order to provide a clear reference wherein the QoS management and mobility studies for the transport network layer (TNL) have been carried out in AROMA, Figure 5 portrays the functional modules of the envisaged TNL architecture. The holistic view of the envisaged TNL is achieved by integrating the functionalities namely routing, QoS provision framework, MPLS based mobility management, resource reservation and admission control. Figure 6 describes the procedures involved in the definition and design of the functional model.

TNL – Functional Modules

Routing

QoS

Mobility

Management

Resource Reservation &

Admission Control

MPLS

Figure 5: TNL-Functional model.

TNL

Functional model

BE & QoS routing Resource Reservation &

Admission Control

Diffserv & MPLS

Protocol / algorithm and IPC Specifications

Implementation aspects

Mobility Management

Figure 6: Functional model development procedures.

The RM - TNL functional model has been developed by means of:

⇒ Definition of protocol / algorithm specifications ⇒ Definition and implementation of IPC between the protocol entities ⇒ Performance analysis by simulation

The BE and QOS routing is provided by the OSPF and QOSPF protocols respectively. Bandwidth Broker performs the resource reservation and admission control. IP mobility management is provided by MPLS based mobility management. The below sections describes each of these functionalities in detail.



4.2 BASIC ASSUMPTIONS AND STATE OF THE ART In a LTE UTRAN1, there is not anymore an Iub interface and the radio resource control and management functionalities are pushed towards the edge of the network at the e-NodeB. Thus, in LTE RAN IP micromobility protocols can be directly used in conjunction with QoS routing and MPLS in the LTE RAN confined between the e-NodeB and MME/UPE entities. As it can be seen in the user-plane stacks of UMTS R5/R6 and LTE respectively in Figure 7 and Figure 8 the difference is at the user-plane radio related layers are located at the e-NodeB for LTE. Thus, the network domain between the UPE/MME and e-NodeB constitutes an IP mobile access network, where the core nodes have IP router functionalities specific functionalities and edge nodes (e-NodeB and UPE/MME) have additional functionalities related to IP mobility management or the radio resource management. Furthermore, at the UPE/MME entity in the evolved packet core, IP packets delivered by the 3GPP anchor, are first processed by the PDCP layer where header compression is occurring and then packets are then passed to the IP mobility management layer, which has the duty to deliver the data packets to the appropriate e-NodeB. It can be pointed out that the S1 interface has not specified yet.

Figure 7: User-plane stack of UMTS R5/R6.

1 The notation LTE RAN (Long Term Evolution Radio Access Network) is used throughout this section to refer to the long-term network architecture pointed out in section 0.



Figure 8: User plane stack of LTE.

In comparison with the LTE architecture, the ANP/GW (Anchor Point/Gateway) entity corresponds to the UPE/MME entity in the LTE architecture. And the AR (Access Router) corresponds to the e-NodeB entity. All nodes in the access network are DiffServ capable and in addition ANPs and ARs have DiffServ edge functionalities (traffic shaping, marking, dropping). The IP QoS management is done by a centralized entity: the Bandwidth Broker (BB), which has information regarding the reserved bandwidth at each link of the access network. As said in [1], ”there are few topics in IP networking research and operational communities that elicit as much inconsistent opinion as QoS”. The papers [1] and [7], which summarise workshop sessions on QoS in IP networks, attest that QoS is a controversial subject and there is no simple answer to the question: ”is QoS needed?”. As shown in those papers, the need of QoS depends on the type of network studied; and if today there is no wide deployment of standardised QoS schemes, it is also due to a lack of simple configuration tools for setting up and tuning the QoS parameters of the system, and it is also due to a lack of billing schemes. Nonetheless, here, the focus is on providing QoS for a specific type of access network: an IP mobile access network. The term IP mobile access network encompasses the cellular access network and also the wireless access network based on WLAN like air interface. However, this does not include other types of wireless networks like ad-hoc networks. Moreover, the issues investigated here confine to maintaining QoS in the intra-domain, therefore issues of maintaining QoS across several provider domains are left aside. The use of QoS routing in a mesh-based access network, presents advantages, which are related to the increase of the network capacity. First, it gives more flexibility in the dimensioning of the mobile access network. For instance, with a tree-based topology, if a new wireless AP is added to the access network, then the capacity of the links at each hierarchy of the tree topology, as shown in Figure 9, has to be increased. With a partially-mesh topology, the change in the capacity of the links is less important, as the traffic from and to this new AP can be routed using multiple paths. Secondly, the use of QoS routing has also an impact on the session completion probability of mobile users. In an IP mobile access network, a user may change its attachment point during an on-going session (for instance a VoIP session), hence specific techniques have to be set up in order to guaranty with a given probability the continuity of the session while the user is moving. Network resources have to be reserved in the following IP attachment point in order to guaranty this continuity. Different methods for the RSVP reservation signalling protocol have been proposed in [8] and [9]. Here, it is examined how QoS routing can increase the session completion probability of a mobile user, compared to the reference case of best effort routing with a tree topology. As it has been seen above, the use of QoS routing in a partially mesh-based mobile access network presents potential benefit in terms of network capacity, session completion probability of mobile users and network dimensioning. Here, the interactions between QoS and IP mobility management entities are identified. A scalable QoS architecture for an IP mobile access network is proposed, which



encompasses the following elements: the DiffServ data-plane, the bandwidth broker, the QoS routing and the IP micromobility management. Moreover, this proposed architecture is further extended in order to include the MPLS forwarding mechanism with constraint-based routing. This architecture aims to provide a scalable QoS framework based on the DiffServ paradigm, for which the network complexity is concentrated at the edge of the network.

Figure 9. Tree and mesh topology.

The general aim is to examine the interactions of an existing QoS architecture (the DiffServ user-plane with the bandwidth broker control-plane entity) with the micromobility overlay of an IP mobile access network. Thus, there is a proposal for the use of QoS routing below the micromobility overlay. The gain in terms of network, due to the use of QoS routing, is presented; and moreover a specific IP handover scheme, named chain tunnelling handover, is chosen in order to further enhance the performance in terms of session completion probability, when QoS routing is being used. It is also shown that the proposal for the micromobility and QoS routing interaction can be extended in order to include the MPLS forwarding mechanism with constraint-based routing. Hence, the proposal of QoS support for IP micromobility protocols can be implemented using the standardised MPLS/CR-LDP protocol. There have been several proposals combining the MPLS technique with IP mobility management protocols. As it is pointed out in the different proposals, one of the motivations for a MPLS-based mobility protocol is the inherent QoS support of such a mobility protocol. However, paradoxically none of the papers examines or evaluates the QoS aspect of the MPLS-based mobility protocol. They all focus at different degrees on the issue of IP mobility and the MPLS forwarding mechanism. The different proposals are reviewed here below. The proposals can be distinguished by the type of mobility management considered. [10] does the assumption that all MPLS nodes have mobility management functionalities. It analyses micromobility and macromobility. It is said:”the lack of interaction between Mobile IP (MIP) and MPLS control planes, forces a change in the protocol layer every time a mobility-enabled router gets a labelled packet for which it is the ingress or egress router”. Thus, each time a data packet is received by a mobility-aware MPLS router, first the MPLS label is taken out, as the node is also an egress router, then the packet is given to the IP layer where the mobility management decides the route to be followed and again the packet is given to the MPLS layer, where it is encapsulated. In order to avoid this unoptimised packet treatment, it is proposed in this paper to add a new field in the Label Forwarding Information Base (LFIB) table. This new field, called LFIB pointer, is a pointer to another entry in the LFIB table. Moreover this pointer is set based on the binding cache information. Therefore, when a packet is received at an egress mobility-aware MPLS router, the packet can be directly re-oriented towards the new LSP. Furthermore, in this paper the LSP is setup when the first data packet is received at the ingress router; it is not established during or after the mobility management signalling. In [11], the proposal combines MPLS with a micromobility similar to Hierarchical Mobile IP (HMIP). The mobility management and the LDP signalling protocols are integrated. A new RSVP object, called ”MIP_Object” is introduced. It contains the MIP registration request, which is transported in the RESV



message. Thus, the MPLS signalling is also used for the mobility management. This supposes that in the access network, some specific routers have both MPLS and mobility management functionalities. Moreover, the LSP establishment is done by the ingress router, which is the gateway of the access network. In [12], a new MPLS-based micromobility is proposed, similar to the previous proposal except that pre-established LSPs are used. LSPs are pre-established between entities called ”LEMA” (Label Edge Mobility Agent), which form a micromobility overlay. These entities are MPLS routers, which also have mobility management functionalities. Furthermore, contrary to the previous paper, only mobility management signalling is used for the establishment of a session. There is no need for an LDP signalling since pre-established LSPs between the micromobility overlay entities (LEMA) are used. Thus, when an AR receives a mobility registration request, it selects a higher level LEMA entity and the associated LSP. As the LSPs are already established, only new entities are added in the LFIB at the LERs. [13], [14] and [15] adopt a similar approach, however in [15] and [16] LEMA-like entities are only located at the ARs and the gateways. In [16], the only routers which have both mobility and MPLS functionalities are edge routers. Moreover, as in [11] the LSPs are dynamically setup at the login and handover phases. Only mobility management signalling is used between the MN and access network nodes. The MN sends a registration request to the gateway, which triggers the LSP setup, since the gateway is the ingress router. Hence, the MPLS and mobility signalling are not combined, but are used sequentially. And after the LSP setup, a registration message is sent back to the MN. Finally [17] differentiates itself from other proposals, as first the MPLS mobility management targets wireless ad-hoc networks and secondly it makes use of LDP inherent mechanisms for the location update, instead of integrating MPLS and mobility mechanisms. LDP protocols provide mechanisms for the modification or recovery of an established LSP. The CR-LDP LSP modification is triggered by the ingress router. Here a new scheme is proposed, which performs local LSP rerouting. As said in [17], it ”recovers from a link or node failure by linking the upstream and downstream nodes around the point of failure without the intervention of the ingress or egress routers”. However, the assumption done in order to perform a local LSP recovery is that each LSR on the LSP path should store the explicit route associated to the LSP. This assumption is necessary so that the downstream node, where the link is not available anymore, can reroute locally the LSP. It can also be noticed that the LSP is established between source and destination ad-hoc hosts. Thus, the end hosts are also ingress and egress nodes. This proposal for a MPLS enabled micromobility distinguishes itself from other proposals by the use of CR-LDP. The CR-LDP gives the possibility to reroute or modify the parameters of an established LSP without disruption. The RFC 3214, which specifies the CR-LDP protocol, defines a method in order to trigger a modification of an established LSP from the ingress router. First, let suppose that an LSP has been set up after the MN has performed a login. The main principle of this MPLS-based micromobility protocol is that when an IP handover is executed, a similar mechanism to the CR-LDP is used in order to reroute the established LSP towards the new AR. It can be pointed out that the part of the LSP, which is rerouted, is between the old AR up to the crossover LSR. In order to be able to trigger an LSP modification, the target AR needs an identification of the LSP that has to be rerouted. The LSPid, defined in the CR-LDP specification, is used as the identification of the LSP. Thus, this LSP identification is stored at the old AR, which is also an egress router, and it is transmitted to the target AR during the handover using the context transfer process between the old and target AR. However remains the issue of the LSP establishment at the login performed by the MN. Currently, the only standardised method for label distribution is the downstream label distribution. If this method is used, this would mean that the ANP, which is the ingress router, has to trigger the LSP setup. A downstream label distribution introduces extra signalling at the login and handover phases, since not only micromobility signalling has to be performed but also the MPLS signalling. This unoptimised inter-working induces an additional latency during the handover. In order to solve this problem, the proposed micromobility protocol uses upstream label distribution. Here, the upstream label assignment method, drafted in [18], is presented. In the case of the standardised downstream label assignment, the upstream LSR sends a label request LDP message to the downstream LSR. Then, the downstream LSR replies by sending a label mapping message. In this message is included the FEC to label binding. The upstream LSR uses this label as the out-going label for packets belonging to this FEC. In the case of an upstream label distribution, the downstream



LSR sends a request message to the upstream LSR. The upstream LSR selects a label, and as this label is an out-going label for this LSR, an entry in the NHLFE table corresponding to the label is created. Moreover, if the upstream LSR is a transit router on the LSP for the FEC, then it binds the ILM for the FEC to this NHLFE. If the upstream LSR is an ingress router, then it binds the FEC to this NHLFE entry. The upstream label distribution introduces the problem of label uniqueness. In order to overcome this issue, when the upstream LSR distributes a label binding for the FEC, the downstream LSR associates the received label to the upstream LSR from which it received it. The labels received from the same LSR constitute a set of labels, named”context specific label space”. Thus, at the downstream LSR, there is a set of context label spaces. Each space is indexed by a neighbour LSR, which may be a potential upstream LSR. Furthermore, the downstream LSR should be able to determine the context of an MPLS packet. One possibility is to use the MAC address in order to determine the context. The LSP establishment is done in the ordered LSP control mode. In this mode an LSR, which is not an egress router and which does no have a mapping for the FEC, must wait until a label is receive from the downstream LSR if the downstream distribution is used, or from the upstream LSR if upstream distribution is used. Finally, the uplink and downlink LSPs (MPLS tunnels in both directions) can be established simultaneously, as in an LDP PDU (Protocol Data Unit), several LDP messages are included. The upstream session from the AR to the access network gateway is set using the downstream on demand advertisement mode. And the downlink session from the gateway to the AR is set up using the upstream label distribution. And during a handover, the upstream LSP is rerouted using the CR-LDP LSP modification method, since the AR is the ingress router for the upstream LSP.

The following sections explain the functionalities of each of the modules and the simulations performed in the AROMA project.

4.3 RESOURCE MANAGEMENT & QOS FRAMEWORK In this study the resource management and IP QoS framework for LTE RAN is defined and the performance of the QoS mechanisms in the IP micro-mobility overlay is evaluated. To this end, it is assumed that all the nodes in the RAN are Diffserv capable and the ANP and ARs have Diffserv edge functionalities like traffic shaping, marking and dropping. The resource management, admission control and IP QoS are provided by centralized entity namely the Bandwidth Broker (BB). The BB has information regarding the reserved bandwidth at each link of the network. Figure 10 describes the IP QoS architecture considered for the LTE RAN. The ANP/GW (Anchor Point/Gateway) entity corresponds to the UPE/MME entity in the LTE architecture whereas the AR (Access Router) corresponds to the e-NodeB entity. All nodes in the access network are DiffServ capable and, in addition, ANPs and ARs have DiffServ edge functionalities (traffic shaping, marking, dropping). The IP QoS management is done by a centralized entity: the Bandwidth Broker (BB), which has information regarding the reserved bandwidth at each link of the access network. Finally, the MPLS-based micromobility management performs the establishment of a new path between the ANP and the new AR after an IP handover, as shown in the Figure 10. A scalable QoS architecture for an IP mobile access network has been proposed and performance analysis of the proposed framework has been evaluated by simulation. The network encompasses the following elements: the DiffServ data-plane, the bandwidth broker, the QoS routing and the IP micro-mobility management. This architecture aims to provide a scalable QoS framework based on the DiffServ paradigm, for which the network complexity is concentrated at the edge of the network. Interactions of the proposed QoS architecture (the Diffserv user plane and BB control plane entities) with the micro mobility overlay are studied by simulations. A detailed description of the simulations carried out and the network gains by the use of proposed QoS framework is given in the below sections.



Figure 10: IP QoS architecture for the LTE RAN

BB Architecture: The BB has an updated knowledge of the available resources in the network and also acts as a policy manager that enforces policies in the network. The BB performs admission control by evaluating whether the requested resources are available in the network. In other words, the BB computes if the routers in the traffic path have enough resources to support the requested session. The BB performs admission control based on the bandwidth constraints, QoS parameters like delay, jitter or loss. When the session is accepted, the BB configures the ingress routers to mark the session packets in order for them to follow the correct LSP and get the guaranteed QoS. In order for the BB to have updated network information, the network characteristics are queried periodically and the BB knowledge base is refreshed. The decision to accept a call is based on the effective bandwidth usage of the current flows and the requested bandwidth of the new call.

Figure 11 Admission Control Unit.

Figure 11 describes the BB architecture used for the simulations. This framework is based on the measured traffic, traffic description and admission criteria. The Admission Control unit performs the flow acceptance based on the measurement based admission control algorithms which includes monitoring of bandwidth and delay. The network traffic can be classified into best effort traffic, traffic requiring predictive service, or guaranteed service. Predictive service traffic makes admission control algorithm flexible and high network utilization by tolerating a level of QoS violations. The admissions control algorithms can either be adaptive to network parameters or conservative depending on the configuration set by the network operator. For the admission control unit to be adaptive, regular network measurements should be made in small time unit which are difficult in the congested network. Hence more parameters should be added to the admission control algorithms for the BB to have a better knowledge of the network and adapt to the conditions.



A pre-emption policy for DiffServ-aware traffic engineering in an IP mobile access network is proposed, as depicted in Figure 12. This policy allows Best Effort (BE) flows to overflow into the region reserved for Expedited (EF) flows with the risk of being pre-empted by newly arriving EF flows. The resources available in the network, in each link, are partitioned between the diffserv (DS) classes: EF, AF (Assured) and BE. The AF handover flows have a pre-emptive priority over the existing BE flows in the dedicated region. It has been seen that BE flows can overflow into the EF and AF specific regions in order to better utilize the additional resources allocated to EF and AF classes for the handover flows. Once the BB has decided to pre-empt a BE flow or possibly an AF flow, remains the issue of choosing the pre-empted flows in the aggregated flow. Two different approaches can be followed: a centralized or a distributed one. In a distributed approach, a mechanism allows to check the availability of resources in all the links, and to detect the links in which the available bandwidth is not enough. Once the bottleneck links have been detected, the associated flows with a certain level of reserved bandwidth can be pre-empted. In a centralized approach, all this information does not need to be discovered proactively but is gathered reactively in a central location. In the case to study, the pre-empted flows belong to the BE class and potentially to the AF class. In order to choose the flows which should be pre-empted, first the AR to which the flows are directed has to be chosen. Once the access router (AR) chosen, as the anchor point (ANP) stores the path to the ARs for each flow, the BE flows are pre-empted successively (or in a more intelligent manner by sorting the flows) until the required amount is achieved. When the flows have been pre-empted, either they can be blocked, remarked to BE if AF, or rerouted if another route is available.

Figure 12: CAC Pre-emption Policy.

Based on the functionalities mentioned above, the BB is split into different modules each with specific functionalities, as depicted in Figure 13.

Figure 13: BB Functional Architecture.



- Routing protocol analyser: This module communicates with the link state routing protocol (OSPF) to obtain the global vision of the network state. The complexity of this module to detect the changes in the network topology is time proportional to the size and complexity of the network.

- Resource request attendant: All session requests are received and processed by this module. This

module decides whether to accept or reject the session. - Measurement analyst: This module receives the information from the routers and updates the

required databases for future utilization and to derive complementary statistics from the received information (e.g. trends, averages over periods of time, etc).

- Admission Control: Admission control is performed every time the BB receives a request. The

admission control process is divided into several parts. First, BB must compute the traffic path inside the network – in other words, based in the requested QoS constraints it should get the LSP that the requested session should use. This is done using the information stored in the topology database. After the path is known, it verifies if the involved links can support the new traffic; if that is the case the session is accepted, otherwise it is not accepted.

- Mobility Attendant: This BB’s internal module is the one responsible to create LSP, on demand,

between the mobility management entities (ANP/AR for a handover, or also old AR/new AR for a fast handover).

In addition to the above, the DiffServ queueing mechanism has a direct impact influence in the network performance indicators: throughput, delay, jitter and loss. The queueing used in order to implement the DiffServ data plane is the one presented in Figure 14.

Figure 14: Diffserv edge router queuing mechanism. Figure 14 shows the queuing mechanism at a DiffServ edge router. In the case of a core router, the classifier is not present. A priority queuing (PQ) discipline is used for the EF class, so that the EF aggregated traffic experiences the lowest delay compared to the other classes. Link sharing queuing discipline is used for the rest of the classes (AF) in order to share in a fair manner the bandwidth used by the EF class. Moreover, the queue length associated to each DiffServ class has an impact on the network performance. The BB policy for the assignment of Diffserv classes is classified based on the node is mobile or static. For a mobile node, if resources are available along the communication path, then EF is assigned, otherwise the DiffServ class is downgraded to BE. For the static nodes, there is one associated to each AR, the AF class is assigned and in addition there is no class downgrade to lower DiffServ classes. The static nodes are used in order to generate background traffic in the access network.

4.4 MOBILITY FRAMEWORK In LTE RAN, IP micromobility protocols can be directly used in conjunction with QoS routing and MPLS in the LTE RAN confined between the e-NodeB and MME/UPE entities. MPLS- based micro mobility management is used for the path establishment between the ANP and the AR. Different mobility schemes (handover mechanisms) are considered in the mobility framework. They include tunnel-based IP handover, chain tunnelling handover mechanism, hierarchical mobility and QoS routing mechanism and adaptive ANP placement mechanisms. With chain tunnelling mechanism, when handover happens, the mobility update is sent only to the old AR instead of to ANP. Hence, the



mobility is transparent to the ANP. The packets are tunnelled from the ANP to the old AR, which decapsulates and tunnels the packets towards the new AR. This results in a chain of tunnels between the initial AR and the AR to which the MN is currently attached. In addition, the IP mobility process is categorized into inter-ANP handover and intra-ANP handover. The inter-ANP handover results in the change in communication path between the gateway and the ANP, whereas the intra-ANP handover results only the change in the communication path between the ANP and the AR. The handover mechanisms are independent of the tunnelling between the ANP and the AR. The mobility management and QoS framework considered in this project involves initial login, handover execution without ANP change, handover execution with ANP change and handover preparation stage. The initial login phase (shown in Figure 15) involves a signalling packet sent to the ANP mobility agent, which is then forwarded to one of the gateways of the domain. This signalling packet is necessary in order to setup a filter at the gateway for the interception of data packets, which have as destination address the MN’s address. The ANP processes this message and provides a Care-of-Address to the MN. When a new session is activated, the MN sends a QoS request to the ANP through the AR to which it is connected. The AR computes a QoS route from the MN’s ANP to itself and is further forwarded to the ANP. The ANP calculates the QoS route from one of the gateway to itself. The QoS request with this calculated QoS route is forwarded to the gateway, which performs a reservation request to the BB of the domain. This request includes the QoS route calculated and the DiffServ class associated to the flow. If the result of the reservation done by the BB is not successful, the DiffServ class of the session can be downgraded to a lower class. The source routing is then configured at the edge in order to encapsulate the packets which are filtered by the gateway. Once the reservation for the segment between the gateway and the ANP has been done, the QoS reply is sent back to the ANP with the current DiffServ class as the result of the first reservation. If the gateway reservation result is lower than the QoS requested by the MN, this lower DiffServ class is kept as the current DiffServ class for the session. The ANP performs also on its turn a reservation request to the BB, which contains the calculated QoS route (from ANP to the current AR) and the current DiffServ class for the session. Finally, the source routing mechanism is set up at the ANP, which is needed for downlink packets. Furthermore, as the final current DiffServ class for the session has been determined, the BB enforces the DiffServ configuration at the edges of the access network: at the gateway for downlink packets and the current AR for uplink packets.

Figure 15: Login Phase Negotiations.



During handover, if the target AR belongs to the ANP to which the MN is attached, then there is no ANP change. As shown in Figure 16, the new AR computes a QoS route, which is added to the handover request message received by the MN. The handover request message is forwarded to its assigned ANP. The ANP checks if the MN’s address belongs to its pool of addresses. If this is the case, then there is no ANP change. Then, the ANP performs a QoS reservation request to the BB. If the DiffServ class is not modified during the handover due to a lack of resources on the new path, then there is no configuration of the edge routers by the BB but it is taken care by QoS context transfer between the old and new AR. It can be noticed that if the MN has several sessions, then the process described above is carried out several times.

Figure 16: IP mobility handover procedure.

If there is an ANP change, i.e. the target AR belongs to a ANP different from the old AR’s one, then the handover process is more complex as it involves also the gateway. As shown in Figure 17, when the ANP receives the handover request and detects that the MN is currently attached to another ANP, the new ANP in a first phase forwards the message to the old ANP which carries out the handover process: it configures the source routing and requests the reservation to the BB. After this first phase, a change of ANP is triggered by the MN. An ANP change message is received by the new ANP, which retrieves the MN QoS context from the old ANP and sets up a path to the current AR. Once this path has been set up, the new ANP sends a ANP ”change” message to the gateway, which sets up a path to the new ANP. Once the gateway has set up the new path, it requests the BB for resource reservation and DiffServ edge configuration. The DiffServ edge configuration occurs in the case the current DiffServ code-point has been changed, depending on policy management at the BB and the available resources on the segments: gateway - ANP and ANP - AR.



Figure 17: IP mobility inter-ANP handover procedure.

4.4.1 HIERARCHICAL MOBILITY MANAGEMENT AND QoS FRAMEWORK The mobility management and QoS performance can be improved by dividing the network into smaller autonomous regions. Ideally these areas are not arbitrary defined, but are defined in order to optimize the performance metrics of the network. Four types of routers are defined based on their position in the network: internal, border, boundary and backbone routers. Internal routers are responsible for routing within a specific area. Boundary routers are responsible for routing between different areas. The functionality of the backbone and border routers is to provide routing in the core network. Hierarchical mobility and QoS routing can be easily adapted to UTRAN topology. The backbone area can be defined within the area of the gateway and the mobility anchor point. Each gateway can act as a boundary router and each ANP can act as an area border router. Hierarchical mobility and QoS routing can improve scalability as route advertisements are propagated only throughout an area and not beyond it. Internal and backbone routers maintain routing information only about the area they belong. Border and boundary routers maintain the information about the routes they belong to and summarized information about the other areas. This results in smaller routing table leading to small memory footprint and less CPU load and time to scan them. Additionally, hierarchical mobility and routing produces less overhead as the update process is concentrated only in the area where a flow request takes place and converges more rapidly, especially when the network topology grows in size. The integrated hierarchical mobility management and QoS routing protocol is designed to support both unplanned and planned handover schemes. The planned handover is performed if the mobile node is able to make handover preparation when still connected to the old access router. Handover preparation stage ensures faster and smoother handover with lesser handover packet loss and end-to-end delay. The necessity for the handover preparation stage is that the mobile node is able to listen to the candidate access router’s broadcast advertisements whilst it is connected to the old access router. In this case, the mobile node has the knowledge about the network it’s moving to. The mobile node sends the handover preparation message (HPREP) to the old BAR indicating the details of the proposed new access router. The old access router forwards the HPREP message to the proposed



new access router. The new access router processes the HPREP message and also passes the details to the BB module. The proposed new AR sends back the HPREP-ACK message back to the mobile node through the access router to which it is connected to the network. The HPREP-ACK message contains the decision made by the new access router. If the new access router decides to accept the mobile node and sends a positive reply, the old access router calculates a temporary path towards the new AR to forward the incoming traffic that corresponds to the MN and then triggers a path update advertisement to inform the other area routers about the occupied resources. This temporary path is released after a timeout or after handover execution. The MN sends a handoff (HOFF) message to its new BAR to initiate the handover execution. The new AR forwards the HOFF message to the old AR and to the MN’s ANP. The old BAR responds with a HOFF-ACK message, release the radio resources and triggers a path update advertisement as the temporary path is not going to be used any longer. The ANP replies with a HOFF-ACK and triggers a path update advertisement to inform the area routers about the released resources. It then calculates a path towards the new BAR and triggers a new path update advertisement In case of planned handover failure, the MN falls back to the unplanned handover scheme. The MN initiates the handover execution, after a successful Layer 2 handover, by sending a HOFF message to its new AR. The new BAR forwards the HOFF message to the old AR and to the ANP. The old AR responds with a HOFF-ACK message that contains all the necessary information about the MN. The ANP calculates a path towards the new BAR and replies to the new AR with a HOFF-ACK message. The path calculation process introduces extra delay in the handover execution phase. Both handover schemes gain all the benefits of QoSR at the cost of more protocol overhead.

4.4.1.1 Hierarchical area definition

Although HQOSPF reduces the forwarding information stored and exchanged between routers, it divides the network into static areas, which cannot reflect accurately all possible traffic patterns at all times. This might lead to non optimal use of the network available resources under certain traffic conditions. Deploying an adaptive routing algorithm, which redefines areas according to the traffic load, could provide a solution to this problem. The adaptive area redefinition should take place only between adjacent areas, while the backbone area remains static at all times. The algorithm should be triggered when there is a major difference between the available resources of two neighboring areas. The event capable to trigger such an area redefinition is the exchange of the intra-area Link State Advertisements (LSAs) because they can reflect summarized area load. Area border routers, which receive an inter-area LSA indicating that its neighbor area has no more available resources, initiates the area redefinition only when their area available resources are below a predefined threshold. The area redefinition should also be triggered by the ANPs in case of frequent handover executions between different areas, in order to reduce the routing overhead and use the available resources more efficient. The major task of this algorithm is to include in the same area any pair of ARs, which is involved in a frequent inter-area handover execution. Such an adaptive algorithm should be triggered when the number of interarea handovers exceeds a predefined threshold. Figure 18 presents the flow diagrams of both hierarchical area redefinition algorithms.



(a) (b)

Figure 18: (a) Area Redefinition Based on Traffic Patterns, (b) Area Redefinition Based on Inter-Area Handovers.

4.4.1.2 Adaptive ANP selection Current QoS schemes rely on the global network QoS state to make routing decisions. In order to construct and maintain the global QoS state, routers need to exchange and maintain global network state information. The more frequent the exchange of this information the more accurate the routing decisions resulting in more overhead. Even in the case of the hierarchical approach inaccuracy is introduced due to aggregation as area border routers advertise summarized information. An alternative approach to global QoSR, which attempts to overcome the problems related to the maintenance of the global QoS state information, is the localized QoSR. Under the localized QoSR, routing decisions are based on the information that is maintained locally at each source router. Therefore, instead of exchanging QoS state information with the other routers of the network, source routers gain knowledge of the global QoS state from locally collected flow statistics and flow blocking or link safety probabilities. on these knowledge source routers can associate a probability on path for a particular flow request. Localized QoSR can be used to adaptively define a new ANP. Upon a new path calculation for an incoming request the source router which is the gateway QoS path. If the ANP is not included, it signals the other QoS path. If the ANP is not included, it signals the other ANP to create a new one. The location of the new ANP can be determined by the gateway based on the probability that it has assigned on each candidate path. Paths with higher probability would be preferred as they carry less traffic. The source router can sent the address of the new ANP to the rest ANPs of the network, which need to inform it about the addresses that they have already allocated to the MN that support. The new ANP upon reception of these messages would have a clear view of the available addresses that it can allocate to approaching MNs. In that way ANP can adaptively created based on network needs. Figure 19 illustrates the flow diagram of the new ANP definition algorithm.



Figure 19: Adaptive ANP selection

4.4.2 QOS PERFORMANCE DURING IP HANDOVER Simulations are carried out to analyse the QoS performance and service degradation during IP handover in the specified architecture. The simulations carried out follow the QoS architecture with the MPLS-based micromobility presented. The simulation platform includes the following functionalities: Diffserv and MPLS for the user plane forwarding, QOSPF for routing, Bandwidth Broker for resource reservation and admission control and finally IP micromobility protocol for mobility management. The results obtained from simulation are valid for a LTE RAN. These results obtained here have a more limited scope for the UTRAN R6. In UTRAN R6, the IP packets are encapsulated into radio frames between the RNC and the Node B. In UTRAN R6, at the IP transport network, DiffServ and MPLS mechanisms can be used, however in addition there is the multiplexing of several IP packets into a radio frame. In the simulation platform used here, there is no multiplexing functionality implemented, therefore the results cannot be directly applied to the case of UTRAN R6. The following quantities have been evaluated by simulation

the network capacity with the use of QoS routing and BE routing the number of service degradation as a function of the user mobility the overhead generated by the QoS routing. Diffserv class degradation during an IP handover Impact of the service degradation on the throughput, end-to-end delay, jitter and loss of user

sessions Impact of the position on the service degradation due to IP handover

In order to evaluate the gain due to QoS routing in an access network compared to the reference case of best-effort routing, different traffic loads have been generated only by static nodes. The quantity of traffic generated by the static nodes is constant in terms of session number and transmitted packet number. However, for each simulation performed, the inter-arrival time between sessions has been modified. By decreasing the session inter-arrival time, the session requests are concentrated in a short duration. And by increasing the session inter-arrival time, the session requests are spread over the simulation duration and not concentrated at a specific time. Thus, by modifying the session inter-arrival time at each static nodes located in the range of an AP, different traffic load distributions are created in the access network. The bigger the value of the inter-arrival time, the more equally



distributed is the traffic among the APs. In Figure 20, it can be seen that if the value of the inter-arrival time is between 1.8 and 7 seconds, the use of QoS routing gives a gain in terms of session blocking probability and therefore in terms of network capacity. It can also be noticed that different QoS routing schemes have been evaluated: on-demand QOSPF, pre-computed QOSPF with different link-state advertisement periods (1,3,5 and 10 seconds) and also QOSPF with hierarchical routing areas. Moreover, it can be highlighted that the network capacity gain shown here is the consequence of only a single peak of session requests during the simulation duration. If there are multiple peaks of requests, then the gain would have been higher. Hence, the gain presented here, is the minimum gain expected to be obtained.

Figure 20: Blocking probability as a function of the session inter-arrival time.

Figure 21, Figure 22, Figure 23 and Figure 24 show results obtained regarding the overhead due to the link-state advertisement of the QoS routing. The Figure 21 shows the number of link-state advertisement packets in the access network as a function of time for the different QoS routing schemes: on-demand, pre-computed routing with advertisement periods of 1, 3 seconds and QoS routing with hierarchical routing areas. It can be observed that QoS routing with hierarchical routing areas presents a lower routing advertisement overhead. And also, a periodical routing advertisement presents a lower overhead than on-demand advertisement. Figure 23 shows the routing advertisement overhead due to a single mobile user, when several IP handovers are performed. The first peak at time unit 1 corresponds to the routing protocol initialization. At time unit 3, the advertisement packets are due to the MN login phase. Then, at time units 5, 7, 9, 13, 15, 17 the advertisement packets are due to an IP handover without ANP change, and at time unit 11, the advertisement packets are due to an IP handover with ANP change. The Figure 23 shows the ratio of the quantity of routing advertisement in bytes and the quantity of transmitted data in bytes. This ratio is plotted as a function of the session inter-arrival time for different QoS routing schemes. It can be seen that for a given QoS routing scheme, a minimum is reached for values of the session inter-arrival time between 2 and 4 seconds. For these values, the different QoS routing schemes present higher performance in terms of number of transmitted packets. Finally, Figure 24 shows the ratio of the quantity of routing advertisement in bytes and the quantity of additional data transmitted compared to the best-effort case. In Figure 24, it can be seen that for the values of the session inter-arrival time between 2 and 8 seconds, for the cases of QoS routing with hierarchical areas, the ratio is below 0.07. However the cases of QoS routing without hierarchical areas or on-demand QoS routing, either the ratio is equal to zero or reaches the value 0.16 for a session inter-arrival time equal to 8 seconds. From these results on the routing advertisement overhead, it can be concluded that QoS routing with hierarchical routing areas and with an advertisement period of 1s presents the minimum overhead among the different QoS routing schemes studied.



Figure 21: Routing overhead as a function of time.

Figure 22: Routing overhead during IP handovers.



Figure 23: Routing overhead ratio.

Figure 24: Routing overhead ratio.

The following describes the impact of the service degradation during IP handover on the throughput, end-to-end delay, jitter and loss of the user sessions. Moreover, the DiffServ queuing mechanism has a direct impact influence in the network performance indicators: throughput, delay, jitter and loss. Respectively in Figure 25, Figure 26, Figure 27 and Figure 28 are shown the average end-to-end delay, jitter, throughput and loss seen by one MN. And respectively in Figure 29, Figure 30, Figure 31 and Figure 32 are shown the average end-to-end delay, jitter, throughput and loss for one static user. Each graph shows an average value over the simulation time. Each curve in a graph corresponds to a specific MN speed. First it can be observed that there is no packet loss for the static nodes. This is a desired effect, in order to create background traffic in the access network. Secondly, the loss and delay seen by the MNs is due to the service degradation to the BE class. The MN experiences longer delays, as the BE priority queues get longer and packet loss happens only when one of the BE priority queues in the network overflows. Thus, the effect of the service degradation can be seen on the delay, jitter, throughput and loss of the MNs’ sessions. Nevertheless, here the absolute values of the network performance indicators are not as interesting as the comparison between QoS routing and BE routing.



Figure 25: End-to-end delay for mobile users’ sessions.

Figure 26: Jitter for mobile users’ sessions.



Figure 27: Packet loss ratio for mobile users’ sessions.

Figure 28: Throughput for mobile users’ sessions.



Figure 29: End-to-end delay for static users’ sessions.

Figure 30: Jitter for static users’ sessions.



Figure 31: Throughput for static users’ sessions.

Figure 32: Packet loss ratio for static users’ sessions.

Figure 33, Figure 34 and Figure 35 show the probability density of the end-to-end delay for QoS routing and BE routing, respectively with a low, medium and higher load, whereas, Figure 36, Figure



37 and Figure 38 show the probability density of the packet loss ratio for QoS routing and BE routing, respectively with a low, medium and higher load.

Figure 33: Delay probability density with low load.

Figure 34: Delay probability density with medium load.



Figure 35: Delay probability density with high load.

Figure 36: Loss probability density with low load.



Figure 37: Loss probability density with medium load.

Figure 38: Loss probability density with high load.

From the simulations, we find that the service degradation varies depending on inter-ANP handover, intra-ANP handover and the chain-tunneling mechanism. The results obtained summarize that when QoS routing is used, the performance in terms of service degradation is better compared with BE routing. With QOSPF, the path chosen after handover varies depending on the traffic distribution and also the mobility pattern of the MNs. In the case of BE routing, the chosen path after handover is



limited to the shortest path between the gateway and the AR. With QOSPF routing, the standard deviation of the service degradation is more and more important as the MN mobility rate increases. When chain tunneling mechanism is used, this deviation is less important although QOSPF is used as the communication path is extended by a new segment, corresponding to the segment the old AR and the new AR. The service degradation during IP handover and the Diffserv queuing mechanisms has impact on the throughput, end-to-end delay, jitter and the loss of user sessions. From simulations performed, it is evident that the position of the ANP has an impact on the quantity of the Diffserv class degradation. If the ANP is closer to AR, the smaller is the routing area and therefore fewer paths available between the ANP and the AR. If the ANP is located closer to gateway, the IP handover delay and packet loss during handover increases due to signalling delay. Hence the position of the ANP on the network is a trade-off between the IP handover delay and access network capacity. Considering the above constraint, we propose a hierarchical and QoS routing architecture and adaptive ANP selection. Following is the performance obtained by using the mentioned hierarchical and QoS routing architecture with adaptive ANP selection. The VoIP QoS received by end users were measured under the same traffic scenario for the three different routing protocols. Figure 39, Figure 40 and Figure 41 illustrate the end-to-end delay, the drop percentage and the jitter. Under light traffic conditions, all three different protocols produce similar QoS. When the shortest path get congested, QOSPF protocols result in better QoS compared to minimum hop, primarily because QOSPF uses alternative paths, which meets the user requirements, while the minimum hop forwards all incoming VoIP traffic through the congested short path. This is illustrated in Figure 42, which presents the mean utilization of the shortest path versus the offered load. The mean utilization of the remaining area paths is 4.17%, 5.09% and 3.54% more under the use of QOSPF. The difference between the QoS of QOSPF protocols and minimum hop increases as the mean utilization increases. The hierarchical and the adaptive QOSPF result in the same QoS before the available resources of the entire area are occupied. When the available resources are occupied, the adaptive version produces better QoS compared to the static. This is due to the fact that the static version forwards all incoming VoIP sessions through the shortest path, while the adaptive QoSPF redefines the area and maximizes its available resources, so it can still find a path that meets the required QoS. Although QOSPF improves the service received by end users, it introduces overhead, which degrade the network performance. The efficiency gains of QOSPF can be measured by comparing the extra amount of VoIP traffic carried using QOSPF, to the protocol overhead. If this extra VoIP traffic is higher compared to the protocol overhead then QOSPF is characterized as efficient. Under light traffic conditions, the use of QOSPF is not efficient because both minimum hop and QOSPF carry the same amount of VoIP traffic and QOSPF produce more overhead. As the mean utilization gets higher and the shortest path gets congested, QOSPF can carry more VoIP traffic compared to the minimum hop, which is much greater than its overhead. Clearly, the use of QOSPF is efficient, especially under the hierarchical arrangement, which produces even less overhead. In addition to topology of the network, the routing update trigger mechanism also affects the overhead. In all the simulations, a class based policy was used to trigger an update. Therefore the QOSPF overhead depends on the value of its class boundary. Three different cases were considered including the flat QOSPF with a class boundary of 10% and the HQOSPF with a class boundary of 10% and 20%. Both hierarchical QOSPF versions produce much less overhead compared to the flat version and especially the one with 20% class boundary. The difference between the protocol overhead increases with the mean utilization. The HQOSPF with 20% class boundary produces the least overhead and therefore, it is the most efficient. Figure 43 illustrates the convergence time of QOSPF under a flat and hierarchical arrangement in relation with the mean utilization. Clearly, HQOSPF converges more rapidly compared to the flat QOSPF and therefore, it results in a more stable routing function. The convergence time difference of the two protocols increases as the mean utilization increases.



Figure 39: End-to-end delay vs utilization.

Figure 40: Drop percentage vs utilization.



Figure 41: Jitter vs utilization.

Figure 42: Shortest Path Utilization vs offered Load.



Figure 43: Convergence time vs Utilization.

5 CONCLUSIONS This document summarized the necessity of IP based micro mobility protocols and the associated resource management framework in the LTE architecture. It described the architecture of the mobility management and QoS framework for the LTE RAN. Based on the state of the art LTE architecture, a framework for the resource management, QoS routing and IP micro mobility stack is designed. In addition, the document also discusses how QOSPF can be adapted in order to co-exist in a mobile environment where mobility management is handled by MPLS-based micro-mobility protocol. We propose hierarchical QoS and adaptive mobility anchor point selection algorithms. It has been shown that for a given access network topology with different network dimensioning, the use of QoS routing in conjunction with adaptive hierarchical ANP selection gives better utilization of resources. Finally, it has been shown how the end-to-end delay, drop percentage, jitter affect the utilization under different characteristics of mobility and QoS abilities.



6 REFERENCES [1] 3GPP TR 23.002 “Network architecture”

[2] TR 25.813 “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Radio interface protocol aspects”

[3] TR 25.814 “Physical layer aspect for evolved UTRA”

[4] TR 23.882 “3GPP system architecture evolution (SAE): Report on technical options and conclusions”

[5] TR 22.978 “All-IP network (AIPN) feasibility study”

[6] Grenville J. Armitage, “Revisiting IP QoS: why do we care, what have we learned? ACM SIGCOMM 2003 RIPQOS workshop report,” ACM SIGCOMM Computer Communication Review, vol. 33, no. 5, pp. 81–88, 2003.

[7] O. Angin et al., “Report on the 5th IFIP International Workshop on Quality of Service (IWQOS’97),” ACM SIGCOMM Computer Communication Review, vol. 27, no. 3, pp. 100–117, July 1997.

[8] B. Moon and H. Aghvami, “Efficient RSVP path management in IP micromobility environment,” IEICE TRANS. COMMUN., vol. E86-B, no. 5, pp. 1710–1714, May 2003.

[9] C. Tseng et al., “HMRSVP: A Hierarchical Mobile RSVP Protocol,” ACM Wireless Networks, vol. 9, pp. 95–102, 2003.

[10] V. Vassiliou et al., “M-MPLS Micro-Mobility enabled Multiprotocol Label Switching,” IEEE ICC, May 2003.

[11] R. Boeringer et al., “I-MPLS: a transparent micro-mobility-enabled MPLS framework,” European Wireless, Apr. 2005.

[12] F. Chiussi et al., “Mobility management in third-generation all-IP networks,” IEEE Communications Magazine, vol. 40, pp. 124–135, Sept. 2002.

[13] K. Sethorn et al., “Wireless MPLS: a new layer 2.5 micro-mobility scheme,” ACM MobiWac’04, pp. 64–71, Oct. 2004.

[14] N. Hoang et al., “QoS support in IP/MPLS-based Radio Access Networks,” IEEE VTC-Spring, Apr. 2003.

[15] K. Xie et al., “Support of micro-mobility in mpls-based wireless access,” IEICE TRANS. COMMUN., vol. E88-B, no. 7, July 2005.

[16] R. Langar et al., “Micro Mobile MPLS: a new scheme for micro-mobility management in 3G all-IP networks,” IEEE ISCC, June 2005.

[17] R. Nagarajan and E. Ekici, “Flexible MPLS Signaling (FMS) for Mobile Networks,” IEEE ICC, vol. 7, pp. 4321–4325, June 2004.

[18] R. Aggarwal et al., “MPLS Upstream Label Assignment and Context Label Space. <draft-ietf-mpls-upstream-label-00.txt>,” IETF Draft, Feb. 2006.



LIST OF ACRONYMS 2G Second Generation 3G Third Generation 3GPP Third Generation Partnership Project 3GPP-Anchor Anchor Point for current 3GPP Radio Access Technology AAA Authentication, Authorisation and Accounting AF Assured Flows aGW Access Gateway AINP All-IP Network ANP Anchor Point AP Access Point BAR Border Access Router BB Bandwidth Broker BTS Base Transceiver Station BE Best Effort CRRM Common Radio Resource Management CRF Charging Rules Function CS Circuit Switched DCF Distributed Coordination Function DiffServ Differentiated Services E2E End to End EF Expedited Flows e-PDG Evolved Packet Data Gateway E-RAN Evolved Radio Access Network E-UTRAN Evolved UMTS Terrestrial Radio Access Network GERAN GSM EDGE Radio Access Network eNB Evolved Node B GGSN Gateway GPRS Support Node GAN Generic Access Network GANC Generic Access Network Controller HPREP Handover Preparation Message HSDPA High Speed Downlink Packet Access HSS Home Subscriber Server IASA Inter Access System Anchor IETF Internet Engineering Task Force IMS IP Multimedia Subsystem Inter AS Anchor Inter Access System Anchor IP Internet Protocol IPC IP Communication LDP Label Distribution Protocol LSA Link State Advertisement LSP Label Switched Path LSR Label Switching Router LTE Long Term Evolution MGW Media GateWay MN Mobile Node MME Mobility Management Entity MPLS Multi Protocol Label Switching MSC Mobile Switching Center OSPF Open Shortest Path First protocol PCEF Policy and Charging Enforcement Function PCF Point Coordination Function PCRF Policy and Charging Rules Function P-CSCF Proxy-Call Session Control Function PDF Policy Decision Function PDN Packet data Network PDU Packet Data Unit, Protocol Data Unit PQ Priority Queuing



PS Packet Switched QoS Quality of Service QOSPF QoS enabled OSPF QoSR QoS Routing RAN Radio Access Network RAT Radio Access Technology RNC Radio Network Controller RRC Radio Resource Controller RRM Radio Resource Management SAE System Architecture Evolution SAE Anchor Anchor Point for SAE technology SLS Service Level Specification SIP Session Initiation Protocol SGSN Serving GPRS Support Node TNL Transport Network Layer TRM Transport Resource Manager UE User Equipment UPE User Plane Entity UMTS Universal Mobile Telecommunications System UTRAN UMTS Terrestrial Radio Access Network VoIP Voice over IP WIMAX Worldwide Interoperability for Microwave Access WLAN Wireless Local Area Network WWW World Wide Web

lte document v2 - aroma doc… · then, this document identifies the ... sae/lte, previously...

Documents