A simple QoS service provision framework for beyond 3rd generation scenarios Victor Marques
Rui L. Aguiar
Portugal Telecom Inovação Aveiro, Portugal
[email protected]
Uni. Aveiro / Instituto de Telecomunicações Aveiro, Portugal
[email protected]
Antonio Cuevas Casado, Jose Ignacio Moreno
Nesrine Chaher
Universidad Carlos III de Madrid Leganés (Madrid) Spain
[email protected],
[email protected]
Motorola Labs, Paris, France
[email protected]
Abstract — This paper describes a global Quality of Service architecture for mobile, audited and accountable environments. Target networks are “Beyond 3rd Generation Networks”, where several heterogeneous access networks are available to the user. Providing per user and per service differentiated QoS is a key issue in these networks. The paper proposes an integrated management approach for service and network management in the case of heterogeneous and mobile network access, based on the cooperative association between QoS Brokers and Authentication, Authorization, Accounting and Charging (AAAC) systems. Keywords—QoS Broker; Mobility; AAAC System; Architecture; B3G I. INTRODUCTION A homogeneous network architecture for heterogeneous environments, where all types of services may be jointly provided while simultaneously fulfilling its different inherent requisites, has been a consistent objective of network providers. Currently this homogeneous network architecture is now being developed in the context commonly referenced as B3G (Beyond 3rd Generation) networks, and has the IP protocol as its reference banner. However, many obstacles still have to be overcome before this can be a reality. Although the use of IP enabled terminals will seemingly allow users to access a larger variety of services, it is of paramount importance that the current voice service (channel based) quality can be replicated in these B3G terminals, in order to convince users of a clear advantage on the new technologies. Voice services are actually some of the most demanding services in terms of network design, imposing hard limits on network performance. QoS support and QoS provision is then a major concern for these future (heterogeneous) IP networks. The so called killer application problem is now targeted to be the same that it was decades ago – voice – and the telecommunication operators must be able to offer the
same quality on the next generation networks. These B3G generations will, nevertheless, have to cope with user mobility. The widespread usage of cellular terminals (cell phones) has changed people perception and being unable to communicate from anywhere is no longer something easily accepted. The merge of IP, QoS, and Mobility, in a telecommunication operator environment, where AAAC functions are also required and of major importance, is a complex task. This paper focuses on a easily implementable QoS framework oriented to flexible service provision in B3G networks. Most aspects of this architecture are under implementation in a field trial, under the sponsorship of the IST project Moby Dick [1] [2]. This paper is structured as follows. In the next section the envisaged B3G network architecture is presented. Section III details the QoS architecture, while section IV discusses the details of the QoS Broker (QoSB). Section V discusses end-to-end QoS support, and our key conclusions are presented in Section VI. II. ENVISAGED NETWORK ARCHITECTURE The architecture presented in this paper (Fig. 1) aims at an “all-IP” provider infrastructure covering mobility between different access technologies and domains while providing end-to-end QoS. Currently, three access technologies are being incorporated: WCDMA (UMTS), Wireless LAN (802.11) and Ethernet [2]. The users/terminals may handover between any of these technologies and between domains belonging to different providers, without breaking their network connection. Fig. 1 depicts the conceptual network architecture, illustrating some of the handover possibilities in such a network. The figure shows three administrative domains, with different types of access technologies, and a user moving in this environment. Due to the requirements of full service control by the provider, all the handovers are explicitly handled by the management infrastructure (even when they are intra-technology, such as between two different Access Points in 802.11, or between two different Radio Network Controllers in
AAAC System
QoS Broker
AR/AG
NMS
Domain A
W-CDMA
User / MT
W-CDMA (Intra domain) W-CDMA
PA AR/AG
AAAC System
W-CDMA (Inter domain)
AAAC System QoS Broker W-CDMA
QoS Broker
Domain D
AR/AG
NMS
NMS
Domain B
W-CDMA to 802.11 (Inter domain) 802.11
PA
CORE AAAC System
802.11 (Inter domain)
QoS Broker 802.11 AR/AG
802.11 to Ethernet 802.11
NMS
Domain C
Ethernet
PA
802.11 to Ethernet
AR
Figure 1 - General Network Architecture WCDMA). Clearly, if a resource is not managed by the network provider, then it is not part of its access network, and will belong to the user local network. The whole network, including management functions and applications is running the IPv6 (IP version 6) protocol stack. The project relies on MIPL (Mobile IP for Linux), together with the development of several Fast Mobile IP [3] extensions. The WCDMA access is fully developed in the project, and complete control on the Radio Gateway is available. Furthermore, the project is developing the stack entities required for the mobile terminals to seamlessly operate in this heterogeneous environment. The QoS and the AAAC systems are responsible of serving each user according to the SLA previously negotiated. The software for these entities is being developed, resorting to a mix of existing implementations (e.g. Interlink Diameter’s implementation), and of project internally developed modules. The key entities in this network architecture are: User – person or company with a service level agreement SLA with one operator for a set of services. This concept architecture is concerned with user mobility, meaning that access is granted to users, not to specific terminals. MT (Mobile Terminal) – the user terminal from where the user accesses the subscribed services. Our network supports terminal portability, meaning that a terminal may be shared among several users (although not at the same time). AR (Access Router) – generic MT point of attachment to the network. RG (Radio Gateway) – Access Router for wireless access (WCDMA or 802.11). NMS (Network Management System) – responsible for managing and guaranteeing availability of resources on the Core Network. In this
paper, metering entities are included as part of this NMS, for simplicity PA (Paging Agent) – responsible to locate the MT when it is in “idle mode” and there are packets to be delivered to it [4]. .QoS Broker – entity responsible of managing one or more ARs, controlling user access and access rights according to the information provided by the AAAC System. AAAC System – Authentication, Authorization, Accounting and Charging System, responsible for service level management, accounting and charging. III.
QUALITY OF SERVICE ARCHITECTURE
A. Generic requirements and description The aim is to have an infrastructure potentially scalable, possible to be expanded in the future to span large areas maintaining contracted levels of QoS eventually replacing today’s telecommunications infrastructures. In this context, no specific network services should be imposed by the QoS architecture, although naturally it should be optimized for “typical” network services. On the other hand, no special charging models will be imposed by the user-level AAAC system, and the overall framework must be able to support eventually very restrictive and controlled network resource usage. With such requirements, the network resource usage control cannot be delegated to the user or user terminal (the Mobile Terminal), as it would be impossible to provide all this flexibility to users, and still maintain a reliable network. The network (operator) must be able to control every resource, and to grant or deny user/service access. These requirements impose the existence of flexible and fast explicit CAC mechanisms on the network side (which can be further enhanced – or not - by network operator’s policies regarding dynamic tariffs as a mechanism for access control.)
In terms of services, applications that use VoIP, video streaming, web, e-mail access and file transfer have completely different requisites, and our network should be able to meet these requirements. In this sense, the QoS framework should provide different levels of network-layer services. Furthermore, scalability concerns impose a DiffServ-alike approach [5]. End-to-end QoS support within this network is then achieved by a set of complementary systems and interactions. It relies on the differentiated services approach, with control mostly performed at the borders of the network, and QoS assurances achieved by the concatenation of multiple managing entities. B. QoS on the Core Network Core management is independent, and with much less dynamic requirements than access: basically the core is managed per aggregate of network-services and not by user-service, like the access. Furthermore, the Core is composed by different domains, one or more from each network operator. The packets may cross all these domains before they reach the end point, with minimal management intervention. The core network resources are distributed between several Classes of Service. We assume that the Core Network is managed basically as it is today: the network will be over provisioned, with an NMS system monitoring resource usage, and regularly upgrading transmission capabilities according to the effective resources usage. C. QoS on the Access Network Due to the potential CAC complexity, the Access Network is managed by a specific entity, the QoS Broker. This entity issues the adequate management controls for the provision of user service, controlling both ARs and RGs. Typically, there are several QoS Brokers per domain: these are logically close to the actual routers, in order to minimize performance delays. Further details are given in the next section. D. User Signaling In this architecture, each network service is associated to a different DSCP code. This way, every packet has concisely all information needed to the network entities to correctly forward, account, and differentiate each packet and each service/user. The user signals the intention of using a service by sending packets marked with the DSCP associated to that service. The QoS Broker has the relevant information for mapping that user-service request into network resources requirements. If there are resources available for that service, the packets will be forwarded and accounted. If not, the AR signals this occurrence to the user/terminal. E. End-of-“session” Signaling Every network service has an associated time-out. If there are not packets sent or received, belonging to that service, for this timeout period, the network elements will automatically free the resources and stop accounting usage of that service. In addition, the user (or the service provider) may explicitly send a teardown message to the network, unsubscribing itself. This facility is essential for “pre-paid” services: the AAAC can issue commands for the QoS Broker to stop provision of given services, or can issue a command to the QoS Broker allowing specific
“credits” (either in time or traffic) that the QoS Broker will use to translate in network control commands. F. Services 1) Network services This architecture is able to provide network services based on the DiffServ framework. Each network service will be of one of the three basic DiffServ types (EF, AF* or BE) and it will have associated bandwidth characteristics (Table 1 lists our target network services). Delay, Jitter and BER are others possible parameters to include in the future. The services may also be unidirectional or bidirectional, e.g., 256Kbps BE for browsing applications and 64Kbps EF for voice services. In fact the QoS structure is flexible enough (as later described) to support any type of network service specification, depending on the management complexity that the network provider is willing to support. 2) User view Users will subscribe to service level agreements consisting in “sets of network services”, i.e., the operator may have a portfolio of packages composed by different sets of network services, e.g., “Inexpensive service” composed with (see Table 1) S1, and S4 and “Exclusive Pack”, composed by S1, S2, S3, and S6. The reflection of this “service pack” in terms of network level services is called the “network view of the user profile” (NVUP), containing the subscribed network services and the user identification. The services presented in Table 1 are optimized for voice communications and data transfer services from network provider point of view, but other Table 1: Targeted network services Service
Relative Priority
Service parameters
Typical Usage Description
Name
Class
SIG
AF41
2a
Unspecified Signalling
(network usage)
S1
EF
1
Peak BW: 32 kbit/s
Real time services
S2
AF21
2b
CIR: 256 kbit/s
Priority (urgent) data transfer
S3
AF1*
2c
Three drop precedences (kbps): AF11 – 64 AF12 – 128 AF13 – 256
Olympic service (better then BE:streaming, ftp, etc)
S4
BE
3
Peak bit rate: 32 kbit/s
Best Effort (BE)
S5
BE
3
Peak bit rate: 64 kbit/s
Best effort
S6
BE
3
Peak bit rate: 256 kbit/s
Best effort
S7
Special Service Requesting AAAC Contact for DSCP
possibilities exist. Notice that the user may even have simply a contract with a value-added service provider (as we will see later), which will then necessarily have a contract with the network provider. G. Integrated Management in Mobile Networks The basic management concepts underlying the complexity of service and network management have been defined in the TMN framework. This framework is complex and resource consuming, but its layered concepts, separating business, service, networks and devices, have been generally used as guide in many management developments. Our approach for B3G networks is similarly based in the separation of service and network management entities. In this proposal, we define a service-layer, which will have its own interoperation mechanisms across different administrative domains (and is directly mapped on the service provider notion), and a network layer, which will have its associated interoperation mechanism between network domains. An administrative domain will be composed of one (or more) network domains. If a terminal is crossing administrative domains during its movement, this implies that it is also changing its current network service provider. Service definitions are handled inside administrative domains. These services are negotiated across domains [6]. Each domain has an entity responsible for handling user service aspects (the AAAC system) and one (at least) entity handling the network device management aspects (the QoS Broker.) The AAAC system is the central point for Authentication, Authorization and Accounting. When a mobile user enters the network, the AAAC will have to authenticate it (this is done when the network detects that a new terminal wishes to enter that domain, as we will see in the next section.) Upon successful authentication, it sends to the QoS Broker the relevant QoS policy information based on the SLA of the user, stored in his profile. The user profile consists of terminal/service pairs, ideally suited to implicit Diffserv QoS signaling [7]. From this moment, the AAAC has delegated further networkrelated management concerned with that user to the QoS Broker. However, this framework is flexible enough for allowing the implementation of specific services which will require the QoSB to question the AAAC system for special services: a special code point will command the QoSB to retrieve further instructions from the AAAC system. IV. QOS BROKER Network resources must be efficiently managed and optimized in order to improve their profitability, avoiding overspending. The introduction of QoS considerations in the network brings further the need for some type of efficient and differentiated treatment inside the network (either per-packets or per-flow belonging to different connections) for different applications (services). Although several models for approaching this problem exist, in the Differentiated Services framework the entity responsible for the management of these aspects in the access is the QoS Broker. In a simplified way, the QoS Broker manages and monitors the network resources in one particular
domain of operation. It also monitors the edges for the incoming and outgoing resource reservations and/or utilization. The information thereby acquired is used in conjunction with system policies to take admission control decisions. A QoS Broker is then an entity that takes Service Admission Control (SAC) decisions and does network device configuration, according to a set of conditions imposed by the network administration entities (AAAC System, for instance) with the goal of achieving end-to-end QoS (eventually over different networks). The QoS Broker may be also responsible for managing inter-domain communications with neighbor QoS Brokers, so that services may be implemented in a coordinated way across various domains. On small sized scenarios, the QoS Broker may be in charge of handling the resources in the full path of the user session, that is, between the caller/callee or the client/server parties. On wider scenarios, due to scalability considerations, it is necessary to involve more than just one QoS Broker to achieve end-to-end QoS. Typically, the QoS Broker has to set the relevant configuration aspects of the border router (queue lengths, scheduling disciplines, etc..), but may be responsible also for configuring link-level specific aspects in the radio gateways. The optimization of the network resources will thus rely on the strategies implemented in this entity. The QoS Broker manages user requests according to the user’s profile. Upon a successful authentication in the AAAC system, the NVUP is given to the QoS Broker. This way, the QoS Broker may perform SAC decisions mostly without any further intervention of the AAAC – unless a service requiring direct AAAC decision is invoked. A. AR – QoS Broker Interactions ARs and QoS Broker will have the following main types of interactions: • The AR pools the QoS Broker for policies related to the services that the attached users are requesting. • The QoS Broker configures the AR with a specific policy for each user/service request, using Common Open Policy Service (COPS). B. QoS Broker-AAAC Interactions The QoS Broker and the AAAC System continually exchange some messages: • The AAAC System informs the QoS Broker of every new MT/User that attaches to its management domain. This information includes the NVUP information for that user. • The QoS Broker may also send a request for specific information. This may occur if, by some failure, the QoS Broker has not previously received the information about that user, and the user is trying to initiate a communication, or if the user is requesting a AAAC-dependent service. C. Network Management Protocols The network elements have to interact between them, and for that they need to have a common “language”. This section refers to the management protocols chosen to run on this network.
1)The COPS Protocol The IETF RAP (resource allocation protocol) working group has defined the COPS protocol [8] as a mean to support policy control in an IP QoS based network. COPS is based on simple request and answer messages used to exchange information about traffic policy between a policy server (PDP, Policy Decision Point) and different kind of clients (PEPs, Policy Enforcement Points). The PDP is responsible for interpretation of the rules to be implemented in the network and enforced by the PEPs. At least one policy server must be present in each administrative domain. The interactions between QoS Brokers (acting as PDPs), edge routers (acting as PEPs) and AAAC systems (also acting as PDP, but at a higher level) are based on COPS message exchange. 2)The DIAMETER Protocol Although the policy concepts associated with QoS Brokers are adequate to network resources management, there is also a need for information to be exchanged related with users’ services. In a B3G environment, as in current cellular networks, the user may subscribe to a different service provider than the one that is currently attached to. Nevertheless, its relevant contract information has to be conveyed to the management system of its current network, which should then provide the adequate network services to the user. In an IP-based infrastructure, these network services can be quite diverse: the negotiation of such services between service providers is a current research topic (e.g. [6]), but even for globally known services, user service information has to flow between service control entities. The AAA framework [9], and the DIAMETER protocol [10], are adequate for our B3G reference environment. The DIAMETER protocol is defined for the transport of authentication, authorization, and accounting information between AAA clients, such as Network Access Server (NAS), and AAA servers. Usually, an AAA client requests authentication and authorization from an AAA server. At the AAA server an internal database keeps track of user authentication information, such as user names and passwords, authorization information, and information of the service type to be delivered. The DIAMETER protocol is also able to transport configuration information back to an AAA client after successful authorization. D. Mobility Support User mobility is supported by means of enabling fast handover techniques in conjunction with context transfer between the network elements (ARs – old and new – and QoS Brokers). When a MT starts losing signal from one cell, it starts receiving a beacon signal from the neighboring cells. This beacon identifies the cell and the MT starts a handover process through its current AR (now called old AR). The new AR (access router on the new cell) is contacted in order to negotiate all parameters with the MT (CoA, etc). The QoS Brokers responsible for both accesses are contacted so that the new AR is configured the same way as the old AR (i.e., for the services the user is using). Basically, the new QoS Broker receives a context transfer from the old QoS Broker with the user’s NVUP and the services currently in use by that user. Upon a successful network elements
configuration, the MT may start the layer 2 handoff because it now has the guarantee that the resources needed are already reserved in the next access network. After concluding the handover process, the AAAC System receives the accounting information from the old access network. V. END-TO-END QOS SUPPORT Fig. 2 shows an example scenario to discuss the problem of end-to-end QoS support. The scenario consists of two autonomous domains (A and B), each having a QoS Broker. For every service request in each domain, the respective QoS Broker takes SAC decisions, depending on the network conditions as well as the specific SLA of the user requesting the service. Each QoS Broker configures its domain, and may interact with other QoS Brokers for requests involving both domains. The interaction between QoS Brokers may potentially be direct (if they belong to the same administrative domain) or indirect (via an AAAC System, as discussed in this scenario). A. Service to Device Mapping: User Registration The first aspect of this association is done at the user registration time. When the user enters a domain for the first time, the user is unknown in this network, and user authentication has to be performed. The MT will register itself in the present domain. This domain is either its home domain or a foreigner domain with which its home domain has a service (“peering”) agreement. To accomplish this, the first action the MT will take is to get a CoA (Care-of-Address) from the AR on the cell it intends to enter. Then, the MT will send a registration request that will be forwarded to the AAAC System. If it is a foreign domain the AAAC system contacts the users’ service provider AAAC (easily implemented using DIAMETER), retrieving the relevant network information from its server. Then the AAAC System exchanges registration messages with the MT. After a successful user authentication, the AAAC is able to map the services subscribed by that user with the current MT being used. Upon authentication, and taking in consideration the existing service agreements between both domains (in case of roaming), the local AAAC system sends its QoS Broker the network services allowed to that user, dumping the NVUP to the QoS Broker, and will also inform the MT of the adequate DSCP mappings to use for signaling its services. The user may now start any of the services within its profile. B. Service Authorisation After a successful authentication process, the user may want to start an application, associated to one of the services in his profile. The terminal has a middleware function that will mark traffic coming from specific applications (e.g. VoIP) with the adequate DSCP. The process can be described as follows, for a connection crossing two domains. When traffic is flowing from the mobile terminal, the access router requests instruction, from the QoS Broker, for what action to take on the IP packets received, assuming it has not any previous configuration for that specific terminal/service pair. The QoS Broker uses the information previously received from the AAAC system, and the current status of the network resources to answer the edge router, either allowing or denying this new traffic. If
AAAC System A
AAAC System B SLA
QoS Broker A
QoS Broker B
ER A
AR A
Domain A
AR B
ER B
Domain B User B
User A
Figure 2: End-to-EndQoS Support the traffic is authorized, the QoS Broker will further send adequate configuration commands to the router. In Figure 2, if the User A wants to initiate a specific service (e.g. VoIP) it starts sending packets marked with the DSCP code for that service (e.g. S2). Upon packet arrival to AR A, AR A will query QoS Broker A for a policy for that Address/DSCP pair. Packets are discarded by the AR A until the Broker configures the AR A (although simple buffering could be easily supported). The QoS Broker A will consult the NVUP information for that user (MT/CoA), and if the DSCP is allowed by the SLA and there are resources available, the QoS Broker A configures the AR A to allow forwarding of the next matching packets (DSCP, CoA, and optionally destination address). Since the first packets may have been dropped (AR A was not yet configured to let it pass through) and the user application did not get an acknowledgement, this “same” packet (in case of a TCP connection) will be retransmitted. This packet will now be able to go into the network and it will initiate the resource reservation on the User B access network. The QoS Broker A maintains updated information about the availability and usage of the network resources in its access domain. If there are not enough resources available for the service that the user is requesting, nothing will be done in AR A, but the user will be informed about the service unavailability. Crossing the border between domains, the packet may have its DSCP changed, depending both on the agreements and on the services supported by both domains. This is handled according to the peering agreements between domains. AR B queries QoS Broker B for QoS instructions (based on DSCP, and destination address) upon first packet arrival. The packet may or may not be dropped, depending on the operator policy. In principle there is no reason to drop the packet, but our architecture is flexible enough to consider the worst case (packet dropped). Our policy considers every packet coming from the Core as trusted (if it is traveling on the Core, it was previously admitted), so, no authorization or authentication information is required at this point. The QoS Broker B has all the information required (travels with the DSCP, set at the edge of domain B) to network resource mapping and configures AR B accordingly. Eventually a return channel can be simultaneously
configured for bi-directional services (the default in our implementation). From this point onwards, every packet sent from the User A be classified according with the filters set. If a packet arrives to AR A with a different DSCP, and does not match the existing rules, the AR A will restart the whole process for this new service. Notice that this approach is quite flexible. Both sender oriented and receiver oriented, both symmetric and asymmetric services can be easily supported. For instance, the QoS Broker can be easily informed that it should allow all traffic to given terminals (as the emergency services), regardless of the MT. RSVP reservations can also be incorporated by adding a new DSCP code point that will be used for forwarding the RSVP request to the QoSB. This information is the forwarded between QoSB, and reservations are performed on the access networks. Once it is assumed that an inter-domain QoS setup is facilitated by a QoS Broker architecture, a path may be signaled (implicitly or explicitly) for a user's session according to the QoS requirements given in the request, (e.g., bandwidth, delay, priority, etc.). This “path signaling” is actually a hybrid reservation/confirmation scheme, consisting of the reservation for traffic flows at the access networks, and the checking of aggregated traffic limits on the core network. This allows an easy mapping of the Differentiated Services model into B3G networks. The usage of QoS Broker has the advantage of allowing different QoS models to be implemented in different parts of the network (e.g. MPLS mechanisms could be used in the core), without introducing signaling problems. Naturally each QoS Broker would require the appropriate intelligence to translate the “service signaling” in the proper actions inside its domain of operation. On an end-to-end vision, this signaling will operate as a reservation action: access network resources (both of the originator and of the terminator of the communication) will be reserved, and core network resources will be checked for availability.
VI. CONCLUSIONS We presented a providers’ framework able to support end-to-end QoS in an infrastructure where mobility and AAAC are also supported. The division of the end-to-end path in into several domains (corresponding basically to two access networks and a core network) simplifies the overall QoS framework. The core network can be managed based on the traffic aggregation of the several services, while the access network can be managed by a QoS Broker on a per user/service basis – a traditional differentiated services approach. However, this is further enhanced by associating an AAAC system supporting aspects of service provision, according to the negotiated SLA. The QoS Broker and the AAAC system interact with each other for maximum network management efficiency, with associated maximum service flexibility. Their communications is assured through facilities provided by DIAMETER and COPS protocols. Current developments on requirements for B3G networks make the existence of such a layered network structure unavoidable. The usage of an AAAC System, responsible for per-user service management, and a QoS Broker, responsible for the network optimization view, presents several advantages. First, this distributed environment is able to handle multiple physical layers, and optimize network resources, since QoS Brokers can be designed for optimally manage different types of access networks resources (such as radio resources). Second, it provides a scalable structure, both in terms of network dimensions, and of service offerings, as management load is distributed through different elements – both in logical and geographical aspects. Third, this is uttermost flexible in terms of management options and IP QoS models: since userservice issues will be hidden of the specific network management aspects. Furthermore, as we have based our work on current standardization trends inside the IETF, this approach may be implemented worldwide. With this approach, very little restrictions are imposed on the service offering. However, each domain has to implement a correspondence between each network service and a DSCP, and thus, for inter domain service provision, it is essential a service/DSCP mapping between neighboring domains. Furthermore, an adequate middleware function is required in the MT, to optimally mark the packets generated by the applications. This approach facilitates the deployment of multiple service provision models, as it decouples the notion of service (associated with the user contract) from the network management responsibilities. This architecture is currently being tested in field trials. ACKNOWLEDGMENT We would like to acknowledge the European Commission support and all partners in the Moby Dick consortium. [1]
REFERENCES Moby Dick: “Mobility and Differentiated Services in a Future IP Network”. http://www.istmobydick.org
Hans Einsiedler et al., “The Moby Dick Project: A Mobile Heterogeneous All-IP Architecture”, ATAMS 2001, Krakow, Poland [3] G. Dommety, ed. "Fast Handovers in Mobile IPv6", Internet Draft, work in progress, , July 2001. [4] M. Liebsch, G. Renker, R. Schmitz, "Paging Concept for IP based Networks", , http://www.ietf.org/internetdrafts/draft-renker-paging-ipv6-01.txt. [5] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An Architecture for Differentiated Services", IETF RFC 2475, December 1998. [6] Thi Mai Trang Nguyen et al, COPS-SLS: a Service Level Negotiation Protocol for the Internet, IEEE Communications Magazine , Vol. 40 No. 5 , May 2002 , pp. 158–165 [7] Victor Marques, R. Aguiar et al, An Architecture Supporting End-to-End QoS with User Mobility for Beyond 3rd Generation Systems, IST Mobile Communications Summit 2002, Thessaloniki, Greece, June 2002. [8] D. Durham et al, RFC 2748, The COPS (Common Open Policy Protocol), Jan 2000. [9] J. Vollbrecht, P. Calhoun, et al, AAA Authorization Application Examples, Internet Engineering Task Force, RFC 2905, August 2000. [10] P. Calhoun, J. Arko, et al, Diameter Base Protocol; Internet Draft, work in progress, draftietf-aaa-diameter-11.txt, June 2002. [2]
