IETF Next Steps in Signaling S. Jeong Working Group HUFS Internet-Draft S. Lee Expires: April 27, 2006 Samsung AIT G. Karagiannis University of Twente G. Lieshout Samsung Electronics Research Institute October 24, 2005 3GPP QoS Model for Networks Using 3GPP QoS Classes draft-jeong-nsis-3gpp-qosm-02.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 April 27, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This draft describes an NSIS QoS Model (QOSM) based on 3GPP QoS classes and bearer service attributes. Specifically, this draft Jeong, et al. Expires April 27, 2006 [Page 1] Internet-Draft 3GPP QoS Model October 2005 describes additional optional parameters for QSPEC which carries 3GPP QOSM specific information and how the QSPEC information should be processed in QNEs. 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 TS 23.107 and Y.1541 QoS Classes . . . 6 4.1.2 Mapping between 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) . . . . . . . . . . . . . . . . . . . 12 5.7 Packet Loss Ratio (PLR) . . . . . . . . . . . . . . . . . 12 5.8 Traffic Handling Priority (THP) . . . . . . . . . . . . . 13 6. Interoperation with 3GPP UMTS . . . . . . . . . . . . . . . . 13 6.1 UE-initiated NSIS signaling . . . . . . . . . . . . . . . 13 6.2 GGSN-initiated NSIS signaling . . . . . . . . . . . . . . 15 7. NSIS Signaling within the IP-based Transport Part of UMTS/GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 11. Change History . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 12.1 Normative References . . . . . . . . . . . . . . . . . . . 18 12.2 Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . 21 Jeong, et al. Expires April 27, 2006 [Page 2] Internet-Draft 3GPP QoS Model October 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 hybrid network comprised of multiple different QOSMs Jeong, et al. Expires April 27, 2006 [Page 3] Internet-Draft 3GPP QoS Model October 2005 [3]. 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 describes an NSIS QoS Model (QOSM) based on 3GPP QoS classes and bearer service attributes. Specifically, this draft describes additional optional parameters for QSPEC which carries 3GPP QOSM specific information, how the QSPEC information should be processed in QNEs, which and how other NSIS QoS models, e.g., RMD- QOSM [13] and Y.1541-QOSM [4], can be applied and interoperate with the 3GPP PDP context signaling. 3. Summary of 3GPP QoS Classes and Attributes This section summarizes 3GPP QoS classes and bearer service attributes which are used to describe the 3GPP QOSM. 3.1 3GPP QoS Classes 3GPP UMTS QoS classes were defined in TS 23.107[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 capable of providing reasonable QoS resolution. Jeong, et al. Expires April 27, 2006 [Page 4] Internet-Draft 3GPP QoS Model October 2005 There are four different UMTS 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) (e) Maximum SDU size (octets) Jeong, et al. Expires April 27, 2006 [Page 5] Internet-Draft 3GPP QoS Model October 2005 (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 UMTS QoS classes in TS 23.107 and other QoS classes. These mappings will be useful for interoperation between 3GPP networks and non-3GPP networks. More detailed mappings will be implementation specific. 4.1 QoS Mapping between TS 23.107 and Y.1541/DiffServ 4.1.1 Mapping between 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 April 27, 2006 [Page 6] Internet-Draft 3GPP QoS Model October 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 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 may also correspond to EF. The 3GPP Interactive class may correspond to AF4 or 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). Please note that there may be different reasonable mappings. 4.2 QoS Mapping between TS 23.107 and RMD-QOSM In Section 8.4 of RFC 3726 [14] it is emphasized that in an UMTS like Jeong, et al. Expires April 27, 2006 [Page 7] Internet-Draft 3GPP QoS Model October 2005 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 Some of the 3GPP QoS attributes described in Section 2.2 are specified in the QSPEC draft [3]. Additional optional QSPEC Jeong, et al. Expires April 27, 2006 [Page 8] Internet-Draft 3GPP QoS Model October 2005 parameters should be defined for appropriate radio resource management in UMTS. This section provides the description and the format of these additional optional parameters. More detailed description will be provided in the later version of this draft. [Editorial note: The number of the additional QSPEC parameters given in this version is not fixed. Future versions of the draft may include more QSPEC parameters.] 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. This parameter can be defined in a way similar to the parameter in [3] except for the number of classes, i.e., 4 in this draft. 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 +-+-+ |DES| +-+-+ 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 Jeong, et al. Expires April 27, 2006 [Page 9] Internet-Draft 3GPP QoS Model October 2005 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 statistical multiplex gain for use in admission control on the relevant interfaces. The format of SSD parameter will be provided in the later version of this draft. 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 (1 bit) is represented as follows. 0 +--+ |SI| +--+ 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 in class A are corrupted, and some bits in class B and C are indeed Jeong, et al. Expires April 27, 2006 [Page 10] Internet-Draft 3GPP QoS Model October 2005 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 can be specified as follows. Two types of AMR codecs should be supported. The first one is the typical AMR codec, where the SDU format is described in Section 4 of [14]. The second type of codec is the the AMR-WB (AMR- Wideband) codec. The SDU format is described in Section 4 of [15]. The format of this parameter should be a QSPEC Control Information container. Its format should be: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AT | FT |Q| MI | MR | CRC | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AT (AMR type): 2 bits integer used to soecify the used AMR type and its values are: 0: (default) typical AMR codec as specified in [14] 1: AMR-WB (AMR- Wideband) codec as specified in [15]. 2: reserved for future use 3: reserved for future use Frame Type (FT): 4 bits Q (Frame Quality Indicator): 1 bit MIndication (Mode Indication: MI): 4 bits If AT = 0 then only the 3 Most Signifficant Bits are used If AT = 1 then the 4 bits are used MRequest (Mode Request: MR): 4 bits If AT = 0 then only the 3 Most Signifficant Bits are used. If AT = 1 then the 4 bits are used CRC (Codec CRC): 8 bits Note that the Frame Type and the Frame Quality Indicator represent the AMR header. The Mode Indication, Mode Request and Codec CRC parameters represent the AMR Auxiliary information. The Class A Jeong, et al. Expires April 27, 2006 [Page 11] Internet-Draft 3GPP QoS Model October 2005 bits, Class B bits and Class C bits represent the AMR Core frame. Using the AMR header and AMR Auxiliary information the destination can deduce how many bits should be used for Class A, how many for Class B and how many for class C in the AMR Core frame. 5.6 Transfer Delay (TD) [Editorial note: This parameter may have the same semantic behavior as its associated QSPEC parameter (i.e., QSPEC Path Latency Parameter) described in the QSPEC template draft. A future version of this daft may use the associated QSPEC template parameter instead of the currently specified one.] 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) [Editorial note: This parameter may have the same semantic behavior as its associated QSPEC parameter (i.e., QSPEC Path BER Parameter) described in the QSPEC template draft. A future version of this daft may use the associated QSPEC template parameter instead of the currently specifeid one.] 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 Jeong, et al. Expires April 27, 2006 [Page 12] Internet-Draft 3GPP QoS Model October 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Loss Ratio (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. According to Section 6.5.1 of [5] the Traffic handling priority class can get the values 1, 2 and 3. Therefore the format of this parameter is: 0 1 +-+-+ |THP| +-+-+ Note that the length of this parameter is 2 bits integer. 6. Interoperation with 3GPP UMTS This section describes two possible interoperation scenrios for NSIS QoS signaling which is initiated by QNEs in UMTS. 6.1 UE-initiated NSIS signaling This section describes an interoperation 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 +-----+ +----+ +------+ +------+ ^ ^ +............+ Jeong, et al. Expires April 27, 2006 [Page 13] Internet-Draft 3GPP QoS Model October 2005 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. 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 | |<-------------------+------+-------------------->| | | | | | PDP Flow | | | |------------------->| | | | | | | Figure 4. UE-initiated NSIS signaling Jeong, et al. Expires April 27, 2006 [Page 14] Internet-Draft 3GPP QoS Model October 2005 Please note that the NSIS signaling and the PDP signaling could also be used in an interleaved way. 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 in this scenario. UE GGSN (QNI) Remote AP Remote Host (QNR) | | | | | Application Layer (e.g., SIP/SDP) | |<...............................................>| | | | | | NSIS Signalling | | <------+-------------------->| | | | | | 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 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. Jeong, et al. Expires April 27, 2006 [Page 15] Internet-Draft 3GPP QoS Model October 2005 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. NSIS Signaling within the IP-based Transport Part of UMTS/GPRS As emphasized in [5], the RAN/BSS 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/BSS 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/GPRS. The QoS support in the IP based transport of UMTS/GPRS can be achieved by combining either the UE (MS) initiated or the network initiated Activate/Modify/Deactivate PDP context procedures, specified in [16] with the NSIS RMD-QOSM procedures specified in [13]. This is depicted in Figure 6, where either a UE (MS), or a SGSN or a GGSN can start the PDP context procedures on requesting, modifying or deleting a PDP context, in terms of QoS. The NSIS RMD-QOSM procedures can be applied on the IP based transport network(s), see also Figure 2, used between: * Node B (Base Station) and RNC (or BSC) * between RNC's (or BSC's) * between SGSN and GGSN A possible way of achieving the QoS mapping between the PDP context procedures and the NSIS RMD-QOSM is described in Section 4.2. UE Node B RNC SGSN GGSN (MS) (Base Station) (BSC) Jeong, et al. Expires April 27, 2006 [Page 16] Internet-Draft 3GPP QoS Model October 2005 | | | | | | | | | | |Activate/Modify/Deactivate PDP context procedure| | |<------------------------------------------------------------->| | | | |NSIS RMD-QOSM | | | | |<------------>| |Activate/Modify/Deactivate PDP context procedure| | |<------------------------------------------------------------->| | | | | | | | | | | | | | | | | | NSIS RMD-QOSM | | | | |<------------->| | | |Activate/Modify/Deactivate PDP context procedure| | |<------------------------------------------------------------->| | | | | | Figure 6. NSIS Signaling within the IP-based Transport Part of UMTS (and GPRS) 8. Security Considerations There are no new security considerations based on this draft. 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 etailed 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, Brian Williams, and Attila Bader for helpful comments and discussion. 11. Change History 11.1. Changes since -01 1. Updated abstract, introduction, and additional optional QSPEC parameters Jeong, et al. Expires April 27, 2006 [Page 17] Internet-Draft 3GPP QoS Model October 2005 2. Created a new section "NSIS Signaling within the IP-based Transport Part of UMTS/GPRS" 3. Updated figures regarding interoperation with UMTS 11.2. Changes since -00 1. Reduced the text for overview 2. Added QoS mapping between 3GPP TS 23.107 and RMD-QOSM 3. Updated additional optional QSPEC parameters 4. Updated interworking Scenarios for End-to-End QoS Support 5. Added Future Issues 12. References 12.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., "NSLP for Quality-of-Service signalling", draft-ietf-nsis-qos-nslp-08 (work in progress), October 2005. [3] Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-06 (work in progress), October 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.10.0, October 2005. [7] 3GPP, "Architectural enhancements for end-to-end Quality of Service (QoS)", 3GPP TR 23.802 7.0.0, October 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. Jeong, et al. Expires April 27, 2006 [Page 18] Internet-Draft 3GPP QoS Model October 2005 [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-04 (work in progress), October 2005. [14] 3GPP, "Mandatory speech codec speech processing functions; Adaptive Multi-Rate (AMR) speech codec frame structure", 3GPP TS 26.101 3.3.0, March 2002. [15] 3GPP, "Speech codec speech processing functions; Adaptive Multi-Rate - Wideband (AMR-WB) speech codec; Frame structure", 3GPP TS 26.201 5.0.0, April 2001. [16] 3GPP, "General Packet Radio Service (GPRS); Service description; Stage 2", 3GPP TS 23.060 3.16.0, January 2004. 12.2 Informative References [17] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004. [18] 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. [19] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [20] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. Jeong, et al. Expires April 27, 2006 [Page 19] Internet-Draft 3GPP QoS Model October 2005 [21] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [22] 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 Georgios Karagiannis University of Twente P.O. BOX 217 7500 AE, Enschede Netherlands Email: g.karagiannis@ewi.utwente.nl Gert-Jan van Lieshout Samsung Electronics Research Institute Geert Grote straat 8a 7411GS, Deventer Netherlands Phone: +31(0)570615651 Email: gert.vanlieshout@samsung.com Jeong, et al. Expires April 27, 2006 [Page 20] Internet-Draft 3GPP QoS Model October 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 April 27, 2006 [Page 21]