An Architecture Supporting End-to-End QoS with User Mobility for Systems Beyond 3 rd Generation Victor Marques1 , Rui L. Aguiar2 , Piotr Pacyna 3 , Janusz Gozdecki3 , Christophe Beaujean4 , Nesrine Chaher4 , Carlos García 5 , José Ignacio Moreno 5 , Hans Einsiedler6 1
Portugal Telecom Inovação, 3810-106 Aveiro Portugal (
[email protected]) Instituto de Telecomunicações/Universidade de Aveiro, 3810 Aveiro, Portugal (
[email protected]) 3 AGH University of Technology (UKR), Krakow, Poland ({pacyna, gozdecki}@kt.agh.edu.pl) 4 Motorola Labs, Paris, France ({Christophe.Beaujean, Nesrine.Chaher}@crm.mot.com) 5 Universidad Carlos III de Madrid, Spain ({cgarcia, jmoreno}@it.uc3m.es) 6 T-Systems, Berlin, Germany (
[email protected])
2
ABSTRACT Future telecommunication networks, and in particular networks beyond 3rd Generation, will be based on an “all-IP” architecture. Issues such as Quality of Service (QoS), Mobility and Authentication, Authorisation, Accounting and Charging (AAAC), and their respective interoperation, must be handled in such scenarios. This paper describes a generic end-to-end QoS architecture and its relationship with the other networking components. This architecture is being developed inside the IST project Moby Dick. I.
INTRODUCTION
Today Cellular Networks are beginning to target IP applications in their service offerings. Future UMTS and beyond third generation networks intend to extend this strategy to a higher degree, even transforming the voice service in an IP service as well. This trend is already present in terrestrial telecommunication networks, now using IP to transport all type of data between nodes in the Core network. In this case, the network relies on the different transport technologies capabilities to guarantee QoS requirements (such as SDH or ATM). After all, the IP protocol was not originally designed to supply different grades of QoS. Nevertheless an IP approach to end-to-end QoS (between any two points in the world) is required to be able to build an “all-IP” world of networking without relying on any layer 2 specific QoS mechanism. The IST Moby Dick project addresses these issues, targeting Beyond-3rd Generation networks, where mobility across different technologies will be common, with QoS guarantees before, during and after handovers [1, 5]. This paper discusses the motivation and background of this work on the next section. On section III, Moby Dick QoS scenarios and requirements are presented. On section IV the QoS architecture is discussed, and explained how the several components interact with each other, in order to achieve the expected end-to-end QoS. Finally some conclusions will be presented.
II. MOTIVATIONS AND BACKGROUND A. QoS Architectures in IP Networks During the past few years, several IP QoS architectures were and are still being defined in several international organisations and committees, such as IETF. Among these architectures are the Integrated Services (IntServ) [6] and Differentiated Services (DiffServ) [7] architectures, the former handling explicit end-to-end per-flow resource reservation, and the later providing aggregate handling in a per-hop approach, associated with explicit network access control. Both architectures use CAC (Connection Admission Control) techniques and scheduling algorithms for providing service differentiation to different packets. Unfortunately, its huge processing requirements make IntServ approaches inadequate for core networks. Thus, if pure IP paradigms are aimed for, some sort of DiffServ-based approach has to be implemented. However, QoS assurances in such networks depend on multiple factors, which sometimes leads to the notion of Class of Service (CoS), as a somewhat vague grade of service provision – in opposition to the classical QoS view of explicit, clearly identified parameters, across different types of services. The question of handling the CAC in DiffServ approaches becomes a crucial one, and different strategies may lead to different facilities of “grades of service”. Some proposals for aggregation of RSVP signalling in the core have been presented [8], theoretically providing a simple support of IntServ over DiffServ networks; however, this approach is quite limited. The more typical view of SPs relies on a centralized network control, implemented through a QoS Broker (also known as Bandwidth Broker), an entity that manages the access network resources. This allows for quite intelligent CAC approaches. B. QoS in Mobile Environments The problem of assuring QoS in mobile environments presents a whole new set of design challenges with respect to QoS provision. One fundamental design choice is centred on the specific strategy for providing service differentiation: either resorting to Layer 2-specific characteristics, or not. In fact, the notion of “heterogeneous mobility”
leads inevitably to the possibility of moving across L2 layers with very different properties. This is the case of the Moby Dick network, where mobility between WCDMA (UMTS), 802.11 (Wireless LAN), and Ethernet networks is being implemented. Here, a QoS model could become too complex and overly dependent on the specific properties of the transport technologies. This is not a concept model related with the IP protocol. In IP, service differentiation is achieved by the different treatment given to the packets (according to some characteristic) by the Layer 3 (IP) entities (and by the CAC made at the IP-level). These IP-only models have some drawbacks, as mentioned. The most challenging problem in these networks is to maintain QoS during the handovers (intra- or inter-technology) [2]. Intra-technology handover is a complex task, because it is much dependent on the L2 mechanisms. Any IP-QoS model will be (in a first approach) unable to control this aspect of handover. It has to assume that the handover is fast enough (this is actually the case with wireless networks now). Inter-technology handover, on the other hand, cannot rely on any technology specifics (by definition). Thus specific mechanisms will have to be deployed over IP (such as Mobile IP [9] and/or other mobile improvements) in such a way that these handovers are completed in a reasonable time. If this handover latency is too large, other QoS-related aspects will be usually impaired. On a similar token, handovers should not drop packets (smooth handover). Thus, it would be essential to QoS-frameworks that handovers are simultaneously fast and smooth (known as seamless handovers). For generic QoS-deployment, handovers have to be necessarily seamless, otherwise the handover restrictions will constrain the services able to be provided in such a heterogeneous network. Note that, if an IP-QoS framework may aid in the support of smooth handovers, there will always be intrinsic technology limitations that no network layer strategy will be able to overcome. Another challenge concerning QoS in heterogeneous environments is related with the maintenance of the “QoS level” after a handover, in a seamless way. When a Mobile Terminal (MT) moves, either inside its home domain, or from its home domain to a foreign domain, the user will not necessarily keep the same level of QoS. The new path used by the data does not necessarily offer enough resources to maintain the “QoS level” the MT had before moving. Besides, a user may be rejected in a foreign domain that does not have a Service Level Agreement (SLA) with the MT home domain. Thus, a lot of different and complex mechanisms may be involved to maintain a communication (resource reservation, specific signalling…). This may potentially have a negative impact on the connectivity, and on the QoS offered to the user too. The challenge here is to carefully design a relatively simple QoS architecture in order to ensure handovers will be managed efficiently. C. QoS and Security There are two issues that radically affect the infrastructure of a network: QoS and security
capabilities, and although different people are usually concerned about a single one, when it comes to implementations they are interlaced and have an impact on each other. This relation led us to a model where QoS and security must be taken into account for the development of network design. The choice of certain QoS requirements may affect the required security levels and vice-versa. For example, the QoS system itself needs the use of security capabilities to perform the service assignment; or, if security keys have to be exchanged to maintain a connection, this information should be prioritised over the other connection traffic. Therefore, it is very important a good understanding of the interactions between both concepts. Wrong choices in network design may lead to non effective QoS capabilities, or to non effective security systems, and their respective relationships. The QoS Broker is fortunately an interesting approach for security issues, as described ni [11]. This model implies the development of QoS and security functions into the same entity. However, it is possible the use of a more complex model where two entities exist: an AAAC System and a QoS Broker. Each one of these entities is responsible for its specific (security, QoS) function. The use of this model implies the implementation of some kind of (secure) communication between the QoS Broker and AAAC System. The COPS protocol defines a simple client-server model that does provide policy control for signalling of QoS [12]. III. MOBY DICK QOS FRAMEWORK A. QoS concepts Some basic QoS concepts have to be defined inside the Moby Dick architecture, in order to have a clear view of the QoS classes and services to be used and offered to the user. The basic concept is that end-to-end QoS will be supplied and negotiated at the application level. The negotiation may be done using SIP [10] or any other mean. There is no notion of session at the IP layer, and, changes of the network service being provided will not be supported after the resource allocation. If the user is not authorised for some specific network service (either because the terms of his SLA do not allow it, or the user has run out of his credit in pre-paid scenarios), or if the network has no resources available in that moment, feedback will be provided to the user (which may act accordingly) through a control plane. The contract established between the User and the Service Provider will be based on the following assumptions: 1. There is an IP QoS profile, which is a subset of the SLA stored in the AAAC System [4]. 2. No timing constrains will be supported at the QoS model. 3. There is no explicit deterministic guarantee of QoS parameters on the network. The service provider will have to perform proper network dimensioning for such provision, as the QoS model will not inherently provide resource reservation through a specific path.
4. The MT will request Service by means of DSCP (DiffServ Code Points) – an implicit signalling request. In alternative, the SP may do marking on behalf of the user, based on the type of application (port, for instance) in use. 5. To use a service, the MT will mark the packets, and the first element in the Operator Network will implement Policies based on the User SLS (Service Level Specification). B. QoS scenario The Moby Dick network will be based on DiffServ mechanisms, associated with CAC algorithms and QoS Brokers. Before a user is allowed to use network resources, he must be Authenticated and Authorised, and then admission control will be performed for the specific service he intends to use. If these requirements are within his profile and the resources are available, the QoS broker will allocate them and the user will finally be able to use the service. After this process is concluded, the infrastructure maintains these resources allocated while the user moves between different access networks within and between administrative domains. There will be no notion of end-to-end QoS at the IP layer, in the sense of explicit end-to-end flow identification. The notion of a session similar to the one of the IntServ framework will not be supported in our QoS-framework, due to the scaling problems that could arise from this. However, proper network dimensioning and adequate network management can make this approach a generic end-to-end QoS framework. In terms of service parameters, this will be only limited by the transport technology constrains; thus, timing constrains (delay, jitter) are not currently supported in the QoS framework. IV. THE MOBY DICK QOS ARCHITECTURE In our QoS framework, several different QoS Domains (QoSD) may exist in each Administrative Domain (AD), and each QoSD will have one QoS Broker. The QoS Broker is conceptually a single unit, but can be implemented as several distributed units acting as one, that manages the network resources on the QoSD. These resources will be managed according to the DiffServ paradigm, with different PHBs (Per Hop Behaviour), supported by proper network provisioning and access control. The different DiffServ concepts were used to define several different Moby Dick CoSs; all services offered to the users will be based on the combination of these CoSs. Between different QoSDs, the SLS is statically defined for each CoSs, whether the QoSDs are parts of the same AD or not (this restriction can be later waived). A User Profile is associated with each user. The User Profile stores all information related with that user, such as information about the SLA, Authentication, Authorisation, Accounting, Charging, etc. From the network point of view, only a small set of that data is needed. This is the NVUP (Network View of the User Profile), and contains, e.g. QoS relevant information concerning the services available to the user. The
NVUP will be sent from the AAAC System to the QoS Broker on which domain the user is currently connected. If the user is currently in a Foreign Domain, then this AAAC System (AAAC.f) has to request this information from the AAAC System of the User Home Domain (AAAC.h). In the Moby Dick architecture, the resource allocation is unidirectional. This is the general case, even with multimedia traffic (for instance, if the user is using an application to see a video stream, the QoS parameters required in each direction are necessarily different). However, the contents of the NVUP may lead the QoS Framework to perform symmetric resource allocations for certain types of services (VoIP, for instance). A. QoS parameters According to our generic framework, two QoS parameters will be initially supported: bandwidth usage and packet priority. Currently, in pure IP networks, there are no known solutions on how to guarantee maximum delay, and therefore, Moby Dick network will work without explicit delay guarantees. B. Classes of Service Several custom CoSs were defined within Moby Dick QoS architecture, to illustrate the usage of the framework. These CoSs are defined based on the type of services and access technologies that this network aims to cover. It was intended that these CoSs could be easily mapped to the Conversational, Streaming, Interactive and Background services, defined by the ITU-T and adopted by the UMTS Forum as the future CoSs in telecommunications networks. For each CoS, one or more Network Services are defined to be offered to a User. The Services defined in Moby Dick aim only to demonstrate the concepts of the QoS architecture. The values here defined are the ones that are supposed to meet the requirements of applications in the field trial demonstrator of Moby Dick. Table 1 shows the planned network services, and exemplifies its relationship with typical DiffServ network parameters. In the table, “Name” refers to the service reference signalled by the user; “Class” refers to the target DiffServ PHBs supporting this service. “Relative priority” indicates the relative priority of each packet; the EF (Expedite Forwarding) will have larger priority than the AF (Assured Forwarding) classes (the AF1x, AF2 and AF4 are independent between themselves; AF11 has larger priority than AF12, that has larger priority than AF13). “Service parameters” indicate the typical service parameters used for the configuration of the access routers, while “service description” indicates typical services to be used with these network services. The SIG service will be part of every user’s profile, independently of its particular SLA. A user can subscribe any of these network services and use each of them for different applications simultaneously. That is, each user’s NVUP will be a combination of the Services here presented, and the user will signal for each packet in which CoS the packet should be considered. The user SLA may be a pre-paid
or a subscription based service, each of these having specific related issues to be dealt at an administrative level. Service Relative Name Class Priority S1 EF 1
Service parameters Peak BW: 32 kbit/s
SIG S2
AF41 AF21
2a 2b
unspecified CIR: 256 kbit/s
S3
AF1*
2c
Three drop precedences (kbps): AF11 – 64 AF12 – 128 AF13 – 256
S4
BE
3
Peak bit rate: 32 kbit/s
S5 S6
BE BE
3 3
Peak bit rate: 64 kbit/s Peak bit rate: 256 kbit/s
Service Description Real time services Signalling Priority (urgent) data transfer Olympic service (better then BE: streaming, ftp, etc) Best Effort (BE) Best effort Best effort
Table 1: Services offered to the Users C. QoS management (QoS Brokers) The QoS Broker is the key entity for network resource management within Moby Dick Network. This entity is responsible to perform resource allocation to the costumer, and release unused resources (on timed-out links). The user must be validated to access the network, before the QoS Broker releases permission for the use of network resources. In this sense, the first entity with which the user will interact (either directly or not by means of the attendant) is the AAAC System, and only after being Authenticated and Authorised. The QoS Broker will be then informed by the AAAC System of the NVUP to provide to this user. Figure 1 shows the high level message flows necessary to Set Up a network service between two end points. In reality, the user will contact the Access Router (AR) every time, but initially the AR will redirect the messages towards the AAAC System, and afterwards will process the packets in accordance with the configuration made by the QoS Broker in the routers. AAAC
QoS Broker
QoS Broker
Configuration, data collection QoS negotiation Authentication, SLA control Data
Figure 1: Network Set Up The AAAC System will instruct the QoS Broker, which will configure the routers; the Broker may further negotiate the QoS to be provided to that user with nearby domains. The QoS Broker has the information about all nodes and links in its domain, based on network administration policy. It also controls the distribution of resources between the different CoSs. Upon each allocation or release of resources, the QoS Broker will update its
resource database. A new user will be accepted or not based on the amount of resources he is allowed to use, and on the resources still available in the requested CoS. The type of SLA that each user has may also determine if that user is allowed to enter in a cell that, in principle, has not enough resources for him. That is, a user with a high priority service may force the QoS Broker to degrade the lower-priority services delivered to other users. This kind of detailed control is only possible due to the central nature of management imposed by the QoS Broker. D. Interactions with mobility QoS in mobile environments is a critical issue addressed in the Moby Dick project. Innovative upcoming techniques such as Fast Handovers with Context Transfer may be adopted to minimise the handover effects in the overall QoS. The QoS Broker is the responsible for keeping track of user mobility and for assuring that resources will be available. This can be done either by performing preemptive configuration of the routers, or by fast context switching, upon a user request for changing access cells. The specific message details will depend on the timing performance of the access routers (they will be triggered by the handover process messages). For design simplicity, a handover inside an AD will be considered exactly as a handover between different ADs. This architecture will not allow renegotiation of QoS parameters during the duration of one user session, and this includes handovers. The practical result of this approach is that, if the new access network does not have enough resources to support the active services of the user that is doing handover, two different things may happen: (i) the user is informed that there are insufficient resources available and may decide to stop the handover or, (ii) the session will be terminated. Whenever there are multiple access networks to which the terminal may handover to, the cost of access may be a decision factor. Note also that the degradation of QoS may be a reason to initiate the handover. E. Interactions with AAAC System The QoS management system (QoS Broker) and the AAAC System are closely coupled. The AAAC System will store all information about the User’s SLA, and will be responsible to pass the relevant information (NVUP) to the QoS management system, so it can act accordingly in order to grant each user the resources and QoS that he is paying for. The AAAC System does not have the notion of QoS, or the notion of IP services. These are specific tasks of the QoS management system. In terms of network topology, the first entity with which the MT will interact will always be the AR. The AR will accomplish specific functions related to the AAAC System (such as Authentication and Authorisation, through its AAAC attendant) and to the QoS Broker (resource allocation, through its Policy Enforcement Point). From the AAAC System point of view, the QoS Data that it holds is treated the same way as all other user related information.
F. QoS-Architecture Evaluation As can be seen from the earlier sections, resource management in a QoSD is central to the operation of the network developed according to the presented QoS framework. The QoS Broker performs the resource management. This entity is fully responsible for admission decision of a request for a network service, as well as provisioning of the resources in the domain. There certainly exists a trade-off between utilisation and performance of the network, and it is important to find the suitable operational points that maximise the utilisation but yet keep the performance at a satisfactory level. For the Moby Dick network a voice service has been selected as a benchmark due to its stringent requirements on the infrastructure. The traffic structure, traffic load matrix, CAC algorithms and scheduling disciplines need to be evaluated jointly by means of simulation in order to know how to dimension such networks. Figure 2 presents the proposed architecture of the AR serving as a DiffServ edge node that supports network services defined in Table 1. The specific parameters in this router architecture will be estimated by means of simulation, and evaluated by field trial. EF (S1)
AF4 (SIG)
Metering and packet marking
Queuing – DropTail
Metering and packet marking
Queuing – MRED
Metering and packet marking
Queuing – MRED
Metering and packet marking
Queuing – MRED
Metering and packet marking
Queuing – DropTail or RED
IN MF classifier
AF2 (S2)
AF1 (S3)
BE (S4, S5, S6)
Scheduler (Priority, WIRR, WFQ)
OUT
Figure 2: Configuration of Access Router The main parameters to configure are: 1. Queuing algorithms for each service class (Multi RED, RED or DropTail); 2. Scheduling algorithm for queue serving (Weighted Interleaved Round Robin, Priority and Weighted Fair Queuing); 3. Dimensioning of a node, in terms of queue length and bandwidth requirements for each class. V. CONCLUSIONS This paper describes a QoS architecture to provide mobile services, with AAAC support, across several heterogeneous networks. This architecture is based on IPv6 mechanisms at the network level, and supports three different types of access networks: 802.11 (Wireless LAN), WCDMA (UMTS) and wired (Ethernet). The basic principles upon which this architecture was constructed are directly related to the service and network evolution constrains envisaged for Beyond 3rd Generation networks. The key problems surrounding this architecture are concerned with efficient handover solutions across different cells. Network provisioning
and management is a key issue, especially with mobile users. The overall solutions developed within the project are based on user profiling and, distributed management, with AAAC and QoS aspects being covered separately. The paper presented the most relevant issues between QoS and Mobility and AAAC System, and how these aspects may interrelate. The specific functions to be implemented in the QoS Broker were also presented. A streamlined version of this architecture is under implementation on the Moby Dick project field trial, where the signalling interactions between the QoS Broker and the other entities of the network will be detailed. VI. ACKNOWLEDGEMENTS We would like to thank all partners in the Moby Dick consortium for their contributions and discussions. We also would like to thank the IST program from the European Commission for sponsoring the Moby Dick project. REFERENCES [1]
Hans Einsiedler et al., “The Moby Dick Project: A Mobile Heterogeneous All-IP Architecture”, ATAMS 2001, Krakow, Poland [2] Victor Marques et al., “Enabling IP QoS in Mobile Environments”, IST Mobile Summit 2001, Barcelona, Spain [3] Hans Einsiedler et al., “Mobility Support for a Future Communication Architecture”, IST Mobile Summit 2001, Barcelona, Spain [4] Hasan et al., “Authentication, Authorization, Accounting and Charging for t he Mobile Internet”, IST Mobile Summit 2001, Barcelona, Spain [5] Victor Marques et al., “A Heterogeneous Mobile IP QoS-aware Network”, CRC 2001, Covilhã, Portugal [6] R. Braden, D. Clark, S. Shenker, "Integrated Services in the Internet Architecture: an Overview", IETF RFC 1633, June 1994. [7] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An Architecture for Differentiated Services", IETF RFC 2475, December 1998. [8] F. Baker, C. Iturralde, F. Le Faucheur, B. Davie, “Aggregation of RSVP for IPv4 and IPv6 Reservations”, IETF RFC 3175, September 2001 [9] B. Johnson, C. Perkins, “Mobility Support in IPv6”, IETF Internet Draft , July 2001. [10] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, “SIP: Session Initiation Protocol”, IETF RFC 2543, March 1999 [11] Vollbrecht, et al. “AAA Authorization Application Examples”, IETF RFC 2905, August 2000 [12] Durham, et al., “The COPS (Common Open PolicyService) Protocol”, RFC 2748, January 2000.
