IETF Next Steps in Signaling S. Jeong Working Group HUFS Internet-Draft S. Lee Expires: January 19, 2006 Samsung AIT G. Karagiannis University of Twente July 18, 2005 3GPP QoS Model for Networks Using 3GPP QoS Classes draft-jeong-nsis-3gpp-qosm-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract QoS interworking between 3GPP wireless and non-3GPP wireline networks will be essential if future IP-based next generation networks are to provide assured-quality end-to-end IP flows. This draft discusses how to achieve QoS interoperability between 3GPP based wireless networks and IETF/ITU-T based wireline IP networks from the NSIS Jeong, et al. Expires January 19, 2006 [Page 1] Internet-Draft 3GPP QoS Model July 2005 point of view. In particular, this draft tries to describe a QoS- NSLP QoS model based on 3GPP QoS classes and bearer service attributes. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Summary of 3GPP QoS Classes and Attributes . . . . . . . . . . 4 3.1 3GPP QoS Classes . . . . . . . . . . . . . . . . . . . . . 4 3.2 3GPP QoS Attributes. . . . . . . . . . . . . . . . . . . . 5 4. QoS Mappings between TS 23.107 and Other QoS Models. . . . . . 6 4.1 QoS Mapping between TS 23.107 and Y.1541/DiffServ. . . . . 6 4.1.1 Mapping between the TS 23.107 and Y.1541 QoS Classes . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.2 Mapping between the TS 23.107 and DiffServ QoS Classes . . . . . . . . . . . . . . . . . . . . . . . 7 4.2 QoS Mapping between TS 23.107 and RMD-QOSM . . . . . . . . 7 5. Additional Optional QSPEC Parameters for 3GPP QOSM . . . . . . 8 5.1 3GPP QoS Classes . . . . . . . . . . . . . . . . . . . . . 9 5.2 Delivery of Erroneous SDU (DES) . . . . . . . . . . . . . 9 5.3 Source Statistics Descriptor (SSD) . . . . . . . . . . . . 9 5.4 Signaling Indication (SI) . . . . . . . . . . . . . . . . 10 5.5 SDU Format Information (SFI) . . . . . . . . . . . . . . . 10 5.6 Transfer Delay (TD) . . . . . . . . . . . . . . . . . . . 11 5.7 Packet Loss Ratio (PLR) . . . . . . . . . . . . . . . . . 11 5.8 Traffic Handling Priority (THP) . . . . . . . . . . . . . 12 6. Interworking Scenarios for End-to-End QoS Support . . . . . . 12 6.1 UE-initiated NSIS signaling . . . . . . . . . . . . . . . 12 6.2 GGSN-initiated NSIS signaling . . . . . . . . . . . . . . 14 7. Future Issues . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1 NSIS signaling within the IP based transport part of UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.2 NSIS signaling between UMTS and WiMAX via an IP-based backbone . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.3 NSIS signaling between UMTS and WLAN via an IP-based backbone . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1 Normative References . . . . . . . . . . . . . . . . . . . 17 11.2 Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 20 Jeong, et al. Expires January 19, 2006 [Page 2] Internet-Draft 3GPP QoS Model July 2005 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. 2. Introduction The NSIS working group is standardizing a signaling protocol suite with QoS signaling as the first use case. The overall signaling protocol suite is decomposed into a generic lower layer with separate upper layers for signaling applications. The upper layer protocol, called NSIS Signaling Layer Protocol (NSLP), has an end-to-end scope and contains application specific functionality. QoS-NSLP [2] which is an NSLP for QoS signaling defines message types and control information generic to all QoS models (QOSMs). A QOSM is a defined mechanism for achieving QoS as a whole. The specification of a QOSM includes a description of its QSPEC parameter information and how that information should be treated or interpreted in the network. The QSPEC contains a set of parameters and values describing the requested resources [3]. The QSPEC object also contains control information and the QoS parameters defined by the QOSM. A QOSM provides a specific set of parameters to be carried in the QSPEC. At each QoS NSIS Entity (QNE), its contents are interpreted by the resource management function (RMF) for policy control and traffic control (including admission control and configuration of the packet classifier and scheduler). +----------+ /-------\ /--------\ /--------\ | Laptop | | Home | | Cable | | Diffserv | | Computer |-----| Network |-----| Network |-----| Network |----+ | (QNE) | | No QOSM | |DQOS QOSM | | RMD QOSM | | +----------+ \-------/ \--------/ \--------/ | | +-----------------------------------------------+ | | /--------\ +----------+ | | "X"G | | Handheld | +---| Wireless |-----| Device | | XG QOSM | | (QNE) | | (e.g., | +----------+ |3GPP QOSM)| \--------/ Figure 1. An Example Configuration with Multiple Different QOSMs Figure 1 shows a network comprised of multiple different QOSMs [3]. Jeong, et al. Expires January 19, 2006 [Page 3] Internet-Draft 3GPP QoS Model July 2005 One of the representative XG QOSMs shown in the figure could be 3GPP QOSM. QoS interworking between 3GPP wireless and non-3GPP wireline networks will be essential if future IP-based next generation networks are to provide assured-quality end-to-end IP flows. In general, in 3GPP UMTS, the wireless physical resource (e.g., frequency spectrum, transmission power or time slots) can be considered to be a significantly scarcer resource than the bandwidth in IP backbone networks [8, 9]. The transmission is therefore optimized in order to utilize the resources as efficiently as possible. Furthermore, in UMTS, different radio bearer services can be provided, that could result in different QoS characteristics, service behaviors, and service costs. The key element for providing optimal QoS with spectrum efficient usage of radio resources is the radio management function. The optimal QoS support can only be provided if the radio management function understands via the 3GPP QOSM, the IP service requirements, and how the radio bearers can be tailored to meet these needs. Therefore, the 3GPP QOSM should be able to signal the user QoS requirements for a session, and as well a set of parameters to control the characteristics of the radio bearers in order to optimize the offered services while maximizing the efficient use of the scarce radio resources. It is, therefore, important to identify what parameters the radio management function should get from an application that wishes to operate efficiently over wireless networks. These parameters allow appropriate radio bearers to be selected, and to determine the effects of these bearers on the IP service characteristics. This draft discusses how to achieve QoS interoperability between 3GPP-based wireless networks and non-3GPP based wireline IP networks from the NSIS point of view. In particular, this draft tries to describe a QoS-NSLP QOSM based on 3GPP QoS classes and bearer service attributes. 3GPP TS 23.107 [5] specifies four different QoS classes for UMTS, and these QoS classes support various user applications. TS 23.107 also describes specific value ranges for each QoS class. 3GPP TS 23.207 [6] and TR 23.802 [7] specify the architecture and procedures for achieving end-to-end QoS across networks with the 3GPP QoS classes as a basis. QSPEC in [3] already addresses generic QoS parameters, and therefore this draft identifies additional optional QSPEC parameters for the 3GPP QOSM. 3. Summary of 3GPP QoS Classes and Attributes 3.1 3GPP QoS Classes 3GPP UMTS QoS classes were defined in [5] by taking the restrictions and limitations of the air interface into account. The QoS mechanisms provided in the cellular network have to be robust and Jeong, et al. Expires January 19, 2006 [Page 4] Internet-Draft 3GPP QoS Model July 2005 capable of providing reasonable QoS resolution. As mentioned above, there are four different QoS classes, i.e., Conversational class, Streaming class, Interactive class, and Background class. The main distinguishing factor between these QoS classes is how delay sensitive the traffic is. For example, Conversational class is meant for traffic which is very delay sensitive while Background class is the most delay insensitive traffic class. Conversational and Streaming classes are mainly intended to be used to carry real-time traffic flows. The main divider between them is how delay sensitive the traffic is. Conversational real-time services, like video telephony, are the most delay sensitive applications and those data streams should be carried in Conversational class. Interactive and Background classes are mainly meant to be used by traditional Internet applications like WWW, E-mail, Telnet, FTP, and News. Due to looser delay requirements, compared to Conversational and Streaming classes, both provide better error rate by means of channel coding and retransmission. The main difference between Interactive and Background classes is that Interactive class is mainly used by interactive applications, e.g., interactive e-mail or interactive web browsing, while Background class is meant for background traffic, e.g., background download of e-mail or background file downloading. Traffic in the Interactive class has higher priority in scheduling than Background class traffic, so background applications use transmission resources only when interactive applications do not need them. This is very important in wireless environment where the bandwidth is scarce compared to fixed networks. To achieve QoS interoperability for end-to-end QoS, the mappings between 3GPP QoS classes (defined in TS 23.107) and non-3GPP QoS Classes such as Y.1541 and DiffServ classes will be important. 3.2 3GPP QoS Attributes UMTS bearer service attributes describe the service provided by the UMTS network to the user of the UMTS bearer service. A set of QoS attributes (QoS profile) defined in TS 23.107 are listed below [5]. (a) Traffic class (b) Maximum bitrate (kbps) (c) Guaranteed bitrate (kbps) (d) Delivery order (y/n) Jeong, et al. Expires January 19, 2006 [Page 5] Internet-Draft 3GPP QoS Model July 2005 (e) Maximum SDU size (octets) (f) SDU format information (bits) (g) SDU error ratio (h) Residual bit error ratio (i) Delivery of erroneous SDUs (y/n) (j) Transfer delay (ms) (k) Traffic handling priority (l) Allocation/Retention Priority (m) Source statistics descriptor ('speech'/'unknown') (n) Signaling Indication (Yes/No) 4. QoS Mappings between TS 23.107 and Other QoS Models The following two subsections illustrate possible mappings between 3GPP QoS classes in TS 23.107 and other QoS classes. Detailed mappings will be implementation specific. 4.1 QoS Mapping between TS 23.107 and Y.1541/DiffServ 4.1.1 Mapping between the TS 23.107 and Y.1541 QoS Classes ITU-T Recommendation Y.1541 proposes six QoS classes defined according to the desired QoS performance objectives [4]. These QoS classes support a wide range of user applications. The QoS classes group performance objectives for one-way IP packet delay (IPTD), IP packet delay variation (IPDV), IP packet loss ratio (IPLR), and IP packet error ratio (IPER). Classes 0 and 1 support interactive real- time applications, and Classes 2, 3, and 4, support non-interactive applications. Class 5 has all the QoS parameters unspecified. These classes serve as a basis for agreements between end-users and service providers, and between service providers. They support a wide range of traffic applications including point-to-point telephony, data transfer, multimedia conferencing, and others. The limited number of classes supports the requirement for feasible implementation, particularly with respect to scale in global networks. Based on the definitions above, the 3GPP Conversational and Streaming classes may correspond to Y.1541 classes 0 and 1, respectively. The two classes of Y.1541 and TS 23.107 are intended to support real-time Jeong, et al. Expires January 19, 2006 [Page 6] Internet-Draft 3GPP QoS Model July 2005 services. The Conversational class and Y.1541 class 0 have a more stringent latency requirement than the Streaming class and Y.1541 class 1. In both specifications, jitter is intended to be limited. In addition, the 3GPP Interactive class may correspond to Y.1541 classes 2, 3, and 4, and one of the relevant applications is interactive data. More detailed mappings can be found in [10]. 4.1.2 Mapping between the TS 23.107 and DiffServ QoS Classes DiffServ [9] proposes differentiation in the queueing and forwarding treatment received by packets at the routers in the network domain, on the basis of DiffServ Code Points (DSCPs) included in their headers at the ingress of the network domain. IETF has standardized two groups of behavior aggregates, namely expedited forwarding or EF (one class) and assured forwarding or AF (four classes each containing three drop-precedence levels). The actual policies used for marking, queueing and forwarding of packets at routers in DiffServ domain is an implementation-specific issue. EF per-hop behavior (PHB) group has been defined with the intention of providing leased-line like service using DiffServ. This is achieved by regulating the total rate of all the flows registered with the EF PHB class to be less than the service rate allocated to the EF PHB class at that node. Strict policing is enforced on the flows, and any non-conforming packets are dropped at the ingress itself. The AF PHB group has provision for classifying packets into different precedence levels. Three such levels have been specified and each level is associated with a drop precedence. Thus, each AF class has three DSCPs reserved, one for each level. AF PHB group defines a relationship between these three precedence levels. If congestion occurs at a particular forwarding node, a packet with the lowest drop precedence must have the lowest probability of being dropped. Likewise, a packet with the highest drop precedence has the highest probability of dropping. Based on the definitions above, it appears that the 3GPP Conversational class corresponds to EF PHB class which can support low latency and jitter, and the 3GPP Streaming class corresponds to AF 4 which can support low jitter. The 3GPP Interactive class may correspond to AF 3 (which can support low latency (but not as low as in conversational class)), and the Background class may correspond to AF2, AF1, or BE PHB class (which does not impose any special QoS requirement). 4.2 QoS Mapping between TS 23.107 and RMD-QOSM Jeong, et al. Expires January 19, 2006 [Page 7] Internet-Draft 3GPP QoS Model July 2005 In Section 8.4 of RFC 3726 [14] it is emphasized that in an UMTS like scenario, (see Figure 2) the NSIS QoS protocol can be applied between a base station and the gateway (GW). Furthermore, in this scenario the NSIS QoS protocol can also be applied either between two GWs, or between two edge routers (ERs). In these situations, the RMD-QOS model [13] can be used to satisfy the requirements imposed by the characteristics of such topologies. In these cases the mapping between the attributes specified in [5] depends on bandwidth and provisioning of resources among the different DiffServ classes which the operators control to satisfy their cost and performance requirements. An example of mapping the TS 23.107 and RMD-QOSM DiffServ QoS Classes could be similar to the mapping explained in Section 3.1.2. An example of mapping the TS 23.107 and RMD-QOSM bandwidth parameters is: RMD QOSM = TS 23.107 |--| |GW| |--| |--| |MH|--- . |--| / |-------| . /--|base | |--| . |station|-|ER|... |-------| |--| . |--| back- |--| |---| |----| ..|ER|.......|ER|..|BGW|.."Internet"..|host| -- |-------| |--| . |--| bone |--| |---| |----| |--| \ |base |-|ER|... . |MH| \ |station| |--| . |--|--- |-------| . MH = mobile host |--| ER = edge router <----> |GW| GW = gateway Wireless link |--| BGW = border gateway ... = interior nodes <-------------------> Wired part of wireless network <----------------------------------------> Wireless Network Figure 2. QoS architecture of wired part of UMTS 5. Additional Optional QSPEC Parameters for 3GPP QOSM Many of the 3GPP QoS attributes described in Section 2.2 are Jeong, et al. Expires January 19, 2006 [Page 8] Internet-Draft 3GPP QoS Model July 2005 specified in the QSPEC draft [3]. Additional optional QSPEC parameters should be defined for appropriate radio resource management in UMTS. This section briefly provides the description and the format of these additional parameters. More detailed description and other possible parameters will be provided in the later version of this draft. 5.1 3GPP QoS Classes Traffic class represents the type of application (i.e., 'conversational', 'streaming', 'interactive', or 'background') for which the UMTS bearer service is optimized. By including the traffic class as an attribute, UMTS can make assumptions about the traffic source and optimize the transport for that traffic type. 5.2 Delivery of Erroneous SDU (DES) Delivery of erroneous SDUs (DES) indicates whether SDUs detected as erroneous shall be delivered or discarded. 'yes' implies that error detection is employed and that erroneous SDUs are delivered together with an error indication, 'no' implies that error detection is employed and that erroneous SDUs are discarded, and '-' implies that SDUs are delivered without considering error detection. This attribute is used to decide whether error detection is needed and whether frames with detected errors shall be forwarded or not. The DES (2 bits) parameter is represented as follows. 0 1 2 +------------+ | DES(2bits) | +------------+ Three values of DES are listed below to indicate different meanings. 0 - 'No' 1 - 'Yes' 2 - '-' 5.3 Source Statistics Descriptor (SSD) Source statistics descriptor (SSD) specifies characteristics of the source of submitted SDUs. Conversational speech has a well-known statistical behaviour. By being informed that the SDUs for a UMTS bearer are generated by a speech source, RAN, the serving GPRS support node (SGSN) and the gateway GPRS support node (GGSN) and also the user equipment (UE) may, based on experience, calculate a Jeong, et al. Expires January 19, 2006 [Page 9] Internet-Draft 3GPP QoS Model July 2005 statistical multiplex gain for use in admission control on the relevant interfaces. Source statistics descriptor (SSD) parameter is represented as follows. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source statistics descriptor [SSD] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.4 Signaling Indication (SI) Signaling Indication (SI) indicates the signaling nature of the submitted SDUs. This attribute is additional to the other QoS attributes and does not over-ride them. This attribute is only defined for the interactive traffic class. If signaling indication is set to 'Yes', the UE should set the traffic handling priority to '1'. Signaling traffic can have different characteristics to other interactive traffic, e.g., higher priority, lower delay, and so on. This attribute permits enhancing the RAN operation accordingly. The SI parameter is represented as follows. 0 1 +-----------+ | SI (1bit) | +-----------+ Two values of SI are listed below to indicate different meanings. 0 - 'No' 1 - 'Yes' 5.5 SDU Format Information (SFI) The SDU format information represents the list of possible exact sizes of SDUs. UMTS uses the Adaptive Multi-Rate (AMR) [11] or the AMR Wideband (AMR-WB) [12] as speech transcoders. As emphasized in [15], the speech bits encoded in each AMR or AMR-WB frame have different perceptual sensitivity to bit errors. By applying this property a better voice quality can be achieved using Unequal Error Protection (UEP) and Unequal Error Detection (UED) mechanisms. These mechanisms focus on the protection and detection of corrupted bits only to the perceptually most sensitive bits in an AMR or AMR-WB frame. In AMR and AMR-WB, these most sensitive bits are denoted as class A bits. Two other classes are also used, i.e., B and C, wherein the bits belonging into these classes are less sensitive to errors. In this case a frame is declared correct even when no bits Jeong, et al. Expires January 19, 2006 [Page 10] Internet-Draft 3GPP QoS Model July 2005 in class A are corrupted, and some bits in class B and C are indeed corrupted. If the bits in class A are corrupted then the frame is anyway declared corrupted. The UEP and UED mechanisms could therefore be significant in achieving spectrum efficient resource management. In order to be able to use these mechanisms, information about the payload format (class A, B and C sensitivity bits) is necessary at the radio level. The specification of the SDU format as a service parameter allows any application to take advantage of the UEP and UED mechanism. The format of this parameter will be provided in an additional version of this draft. 5.6 Transfer Delay (TD) Transfer delay (ms) indicates maximum delay for 95th percentile of the distribution of delay for all delivered SDUs during the lifetime of a bearer service. This parameter allows the radio management function to efficiently configure the radio bearer service. For example, by knowing the Delay requirement, the appropriate interleaving depth can be estimated. This parameter could also be used to determine the maximum number of retransmissions (if any) in the wireless link. The transfer delay (ms) is represented as a 32-bit integer as shown below. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transfer delay (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.7 Packet Loss Ratio (PLR) The packet loss ratio can significantly affect the subjective quality of real time applications. This parameter can be used by the radio management function for admission control and to set some parameters of the radio part, such as L2 buffer size. The Packet Loss Ratio is represented as a 32-bit integer as shown below. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Loss Ratio (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jeong, et al. Expires January 19, 2006 [Page 11] Internet-Draft 3GPP QoS Model July 2005 5.8 Traffic Handling Priority (THP) Traffic handling priority specifies the relative importance for handling of all SDUs belonging to the UMTS bearer compared to the SDUs of other bearers. In many interactive packet services the packet handling priority can be used to provide certain levels of QoS differentiation, in particular in congestion situations. The format of this parameter will be provided in an additional version of this draft. 6. Interworking Scenarios for End-to-End QoS Support 6.1 UE-initiated NSIS signaling This section describes a scenario for end-to-end NSIS signaling that is initiated from a UE connected to a UTMS network. Figure 3 shows an end-to-end network architecture [6, 7] used to explain how end-to- end QoS signaling is achieved using NSIS in the situation where 3GPP and non-3GPP networks are interconnected. ^ +-----+ +----+ +------+ +------+ IP | | | IP Bearer | | //------\\ | | | | Bearer | | | Service | | | | | | | | Layer | | |<----------| |-+---------+-| |-->| | V |Local| | | | | |Remote| |Remote| ============|UE |===========|GGSN| | Backbone| |Access|===|Host | Access ^ | | | | | IP | |Point | | | Bearer | | | +----+ | | | Network | | | | | Layer | | |<-|SGSN|-->| | | | | |<->| | (e.g. UMTS| | | +----+ | | \\------// | | | | Bearer) V +-----+ +----+ +------+ +------+ ^ ^ +............+ Scope of PDP Context Figure 3. An End-to-End Network Architecture Figure 4 shows signaling flows in the scenario. The UE acts as a QNI and initiates NSIS signaling towards the remote end. The IP backbone network is DiffServ enabled, and the GGSN supports DiffServ. The application layer (e.g., SIP/SDP) between the end hosts identifies the QoS requirements. The QoS requirements from the application layer are mapped down to create an NSIS session. The QoS for the wireless access is provided by the PDP context. The wireless QoS can be controlled through signaling for the PDP context. The UE populates the initiator QSPEC and establishes the PDP context suitable for supporting the NSIS session based on the QSPEC information. Jeong, et al. Expires January 19, 2006 [Page 12] Internet-Draft 3GPP QoS Model July 2005 To activate the PDP context, the UE sends an Activate (Secondary) PDP Context message to the SGSN with the UMTS QoS parameters, and the SGSN sends the corresponding Create PDP Context message to the GGSN. The GGSN authorizes the PDP context activation request according to the local operator's IP bearer resource based policy, the local operator's admission control function and the GPRS roaming agreements and sends a Create PDP Context Response message back to the SGSN. The radio access bearer (RAB) setup is done by the RAB assignment procedure, and the SGSN sends an Activate (Secondary) PDP Context Accept message to the UE. Upon receiving the Activate PDP Context Accept message, the QoS-NSLP at the UE (QNI) sends a QoS-NSLP RESERVE (in case of sender-initiated approach) message which contains the Initiator QSPEC to the next hop in the external IP network through the GGSN. The Initiator QSPEC specifies optional parameters specific to 3GPP QoS model as well as generic QSPEC parameters for the application flow. UE (QNI) GGSN (QNF) Remote AP Remote Host (QNR) | | | | | Application Layer (e.g., SIP/SDP) | |<...............................................>| | | | | | NSIS Signalling | |<-------------------+------+-------------------->| Uplink | | | | Data | | DiffServ (RMD) | |....................+------+-------------------->| | | | | | PDP Flow | | | |------------------->| | | | | | | =============================================================== | | | | | Application Layer (e.g., SIP/SDP) | |<...............................................>| | | | | | NSIS Signalling | |<------------------------------------------------+ Downlink | | | | Data | | DiffServ (RMD) | |<...................|<-----+---------------------+ | | | | | PDP Flow | | | |<-------------------+ | | | | | | Figure 4. UE-initiated NSIS signaling Jeong, et al. Expires January 19, 2006 [Page 13] Internet-Draft 3GPP QoS Model July 2005 In the example above, only RMD-QOSM is assumed to be used in the external network. The signaling procedure for QoS interworking in the situation where the external network is based on Y.1541-QOSM will be similar except for QoS mapping. 6.2 GGSN-initiated NSIS signaling This section describes a scenario for NSIS signaling that is initiated from the GGSN. That is, the GGSN acts as a QNI. UE GGSN (QNI) Remote AP Remote Host (QNR) | | | | | Application Layer (e.g., SIP/SDP) | |<...............................................>| | | | | | NSIS Signalling | | <------+-------------------->| Uplink | | | | Data | | DiffServ (RMD-QOSM) | |....................+------+-------------------->| | | | | | PDP Flow | | | |------------------->| | | | | | | =============================================================== | | | | | Application Layer (e.g., SIP/SDP) | |<...............................................>| | | | | | NSIS Signalling | | <----------------------------+ Downlink | | | | Data | | DiffServ (RMD-QOSM) | |<...................|<-----+---------------------+ | | | | | PDP Flow | | | |<-------------------+ | | | | | | Figure 5. GGSN-initiated NSIS signaling Figure 5 shows signaling flows in the scenario. The GGSN acts as a QNI and initiates NSIS signaling towards the remote end. The IP backbone network is DiffServ enabled, and the GGSN supports DiffServ. The application layer (e.g., SIP/SDP) between the end hosts identifies the QoS requirements. The wireless QoS can be controlled through signaling for the PDP context. Therefore, the QoS requirements from the application layer are mapped down to the PDP Jeong, et al. Expires January 19, 2006 [Page 14] Internet-Draft 3GPP QoS Model July 2005 context at the UE. To activate the PDP context, the UE sends an Activate (Secondary) PDP Context message to the SGSN with the UMTS QoS parameters, and the SGSN sends the corresponding Create PDP Context message to the GGSN. The GGSN authorizes the PDP context activation request according to the local operator's IP bearer resource based policy, the local operator's admission control function and the GPRS roaming agreements and sends a Create PDP Context Response message back to the SGSN. The radio access bearer (RAB) setup is done by the RAB assignment procedure, and the SGSN sends an Activate (Secondary) PDP Context Accept message to the UE. The GGSN populates the initiator QSPEC based on the PDP context to create an NSIS session. The QoS-NSLP at the GGSN (QNI) sends a QoS- NSLP RESERVE (in case of sender-initiated approach) message which contains the Initiator QSPEC to the next hop in the external IP network. The Initiator QSPEC specifies optional parameters specific to 3GPP QoS model as well as generic QSPEC parameters for the application flow. Note that QoS mapping between the 3GPP and DiffServ QoS classes/parameters should be performed at the GGSN. In the example above, only RMD-QOSM is assumed to be used in the external network. The signaling procedure for QoS interworking in the situation where the external network is based on Y.1541-QOSM will be similar except for QoS mapping. 7. Future Issues 7.1 NSIS signaling within the IP based transport part of UMTS As emphasized in [5], the RAN Access bearer services and Core network bearer services for packet traffic shall provide different bearer services for variety of QoS. The operator is responsible for choosing which QoS capabilities in Frame Relay layer, in IP layer or in ATM layer are used. Regarding the IP based RAN Access bearer services and Core network bearer services it is recommended that the Differentiated Services defined by IETF shall be used. The NSIS RMD- QOSM [13] satisfies this recommendation and therefore, it can be considered as a feasible solution on satisfying the QoS requirements imposed by the RAN Access bearer services and Core network bearer services on the IP based transport part of UMTS. 7.2 NSIS signaling between UMTS and WiMAX via an IP-based backbone It is possible that 3GPP networks and WiMAX networks will interwork via an IP-based backbone network in the future. In this situation, QoS interwokring will be essential to provide seamless services to Jeong, et al. Expires January 19, 2006 [Page 15] Internet-Draft 3GPP QoS Model July 2005 users. Since 3GPP and WiMAX networks will use different QoS models, QoS model aware signaling should be provided for optimal QoS interworking. Specifically, for end-to-end QoS support, QoS interworking between the 3GPP and backbone networks as well as QoS interworking between the backbone and WiMAX networks should be supported. NSIS signaling can be used for that purpose in such heterogeneous network environments. How to provide such QoS interworking using NSIS is for further study. 7.3 NSIS signaling between UMTS and WLAN via an IP-based backbone The interworking between 3GPP networks and wireless LANs via an IP- based backbone will occur in diverse places in the near future. In this situation, QoS interwokring will be essential to provide seamless services to users. Since 3GPP networks and wireless LANs will use different QoS models, QoS model aware signaling should be provided for optimal QoS interoperability. Specifically, for end-to- end QoS support, QoS interworking between the 3GPP and backbone networks as well as QoS interworking between the backbone network and wireless LANs should be supported. NSIS signaling can be used for that purpose in such heterogeneous network environments. How to provide QoS interworking using NSIS is for further study. 8. Security Considerations There are no new security considerations based on this draft at the moment. Security considerations will be provided in the later version of this draft, if any. 9. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the QSPEC template, in accordance with BCP 26 RFC 2434 [16]. [2] requires IANA to create a new registry for QoS Model Identifiers. The QoS Model Identifier (QOSM ID) is a 32-bit value carried in a QSPEC object. The allocation policy for new QOSM IDs is TBD. This document also defines new objects for the QSPEC Template, as detailed in Section 5. Values are to be assigned for them from the NTLP Object Type registry. 10. Acknowledgements The authors thank Jongho Bang, Byoung-Joon Lee, Cornelia Kappler, Jerry Ash, Al Morton, Gabor Fodor, Fredrik Persson, and Brian Williams for helpful input/comments and discussion. 11. References Jeong, et al. Expires January 19, 2006 [Page 16] Internet-Draft 3GPP QoS Model July 2005 11.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality- of-Service signaling", draft-ietf-nsis-qos-nslp-06 (work in progress), February 2005. [3] Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-05 (work in progress), July 2005. [4] Ash, J., "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes", draft-ash-nsis-y1541-qosm-00 (work in progress), May 2005. [5] 3GPP, "Quality of Service (QoS) concept and architecture", 3GPP TS 23.107 3.9.0, September 2002. [6] 3GPP, "End-to-end Quality of Service (QoS) concept and architecture", 3GPP TS 23.207 5.9.0, April 2004. [7] 3GPP, "Architectural enhancements for end-to-end Quality of Service (QoS)", 3GPP TR 23.802 1.0.0, June 2005. [8] Fodor, G., Persson, F., and B. Williams, "Application of Integrated Services on Wireless Accesses", draft-fodor-intserv-wireless-issues-01 (work in progress), January 2002. [9] Fodor, G., Persson, F., and B. Williams, "Proposal on new service parameters (wireless hints) in the controlled load integrated service", draft-fodor-intserv-wireless-params-01 (work in progress), January 2002. [10] Bain, G. and N. Seitz, "Mapping between ITU-T (Y.1541/Y.1221) and 3GPP (TS 23-107) QoS Classes and Traffic Descriptions", February 2004. [11] 3GPP, "AMR speech Codec; Transcoding Functions", 3GPP TS 26.090 3.1.0, December 1999. [12] 3GPP, "Speech codec speech processing functions; Adaptive Multi-Rate - Wideband (AMR-WB) speech codec; Transcoding functions", 3GPP TS 26.190 5.1.0, January 2002. [13] Bader, A., "RMD-QOSM - The Resource Management in Diffserv QOS Model", draft-ietf-nsis-rmd-03 (work in progress), July 2005. Jeong, et al. Expires January 19, 2006 [Page 17] Internet-Draft 3GPP QoS Model July 2005 11.2 Informative References [14] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004. [15] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real- Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi- Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002. [16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [17] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [18] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [19] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. Authors' Addresses Seong-Ho Jeong Hankuk University of FS 89 Wangsan Mohyun Yongin-si, Gyeonggi-do 449-791 KOREA Phone: +82 31 330 4642 Email: shjeong@hufs.ac.kr Sung-Hyuck Lee Samsung Advanced Institute of Technology Comm. and Network Lab. San 14-1, Nongseo-ri, Giheung-eup Yongin-si, Gyeonggi-do 449-712 KOREA Phone: +82 31 280 9585 Email: starsu.lee@samsung.com Jeong, et al. Expires January 19, 2006 [Page 18] Internet-Draft 3GPP QoS Model July 2005 Georgios Karagiannis University of Twente P.O. BOX 217 7500 AE, Enschede Netherlands Email: g.karagiannis@ewi.utwente.nl Jeong, et al. Expires January 19, 2006 [Page 19] Internet-Draft 3GPP QoS Model July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jeong, et al. Expires January 19, 2006 [Page 20]