idnits 2.17.00 (12 Aug 2021) /tmp/idnits23679/draft-jeong-nsis-3gpp-qosm-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 980. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 957. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 964. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 970. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 744 has weird spacing: '...ansport netwo...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 24, 2005) is 6053 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '17' is defined on line 887, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 890, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 895, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 899, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 903, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 906, but no explicit reference was found in the text == Outdated reference: draft-ietf-nsis-qos-nslp has been published as RFC 5974 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qos-nslp (ref. '2') == Outdated reference: draft-ietf-nsis-qspec has been published as RFC 5975 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qspec (ref. '3') -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Normative reference to a draft: ref. '8' -- Possible downref: Normative reference to a draft: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' == Outdated reference: draft-ietf-nsis-rmd has been published as RFC 5977 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-rmd (ref. '13') -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Obsolete informational reference (is this intentional?): RFC 3267 (ref. '18') (Obsoleted by RFC 4867) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '19') (Obsoleted by RFC 5226) Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Next Steps in Signaling S. Jeong 3 Working Group HUFS 4 Internet-Draft S. Lee 5 Expires: April 27, 2006 Samsung AIT 6 G. Karagiannis 7 University of Twente 8 G. Lieshout 9 Samsung Electronics Research 10 Institute 11 October 24, 2005 13 3GPP QoS Model for Networks Using 3GPP QoS Classes 14 draft-jeong-nsis-3gpp-qosm-02.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on April 27, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 This draft describes an NSIS QoS Model (QOSM) based on 3GPP QoS 48 classes and bearer service attributes. Specifically, this draft 49 describes additional optional parameters for QSPEC which carries 3GPP 50 QOSM specific information and how the QSPEC information should be 51 processed in QNEs. 53 Table of Contents 55 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Summary of 3GPP QoS Classes and Attributes . . . . . . . . . . 4 58 3.1 3GPP QoS Classes . . . . . . . . . . . . . . . . . . . . . 4 59 3.2 3GPP QoS Attributes . . . . . . . . . . . . . . . . . . . 5 60 4. QoS Mappings between TS 23.107 and Other QoS Models . . . . . 6 61 4.1 QoS Mapping between TS 23.107 and Y.1541/DiffServ . . . . 6 62 4.1.1 Mapping between TS 23.107 and Y.1541 QoS Classes . . . 6 63 4.1.2 Mapping between TS 23.107 and DiffServ QoS Classes . . 7 64 4.2 QoS Mapping between TS 23.107 and RMD-QOSM . . . . . . . . 7 65 5. Additional Optional QSPEC Parameters for 3GPP QOSM . . . . . . 8 66 5.1 3GPP QoS Classes . . . . . . . . . . . . . . . . . . . . . 9 67 5.2 Delivery of Erroneous SDU (DES) . . . . . . . . . . . . . 9 68 5.3 Source Statistics Descriptor (SSD) . . . . . . . . . . . . 9 69 5.4 Signaling Indication (SI) . . . . . . . . . . . . . . . . 10 70 5.5 SDU Format Information (SFI) . . . . . . . . . . . . . . . 10 71 5.6 Transfer Delay (TD) . . . . . . . . . . . . . . . . . . . 12 72 5.7 Packet Loss Ratio (PLR) . . . . . . . . . . . . . . . . . 12 73 5.8 Traffic Handling Priority (THP) . . . . . . . . . . . . . 13 74 6. Interoperation with 3GPP UMTS . . . . . . . . . . . . . . . . 13 75 6.1 UE-initiated NSIS signaling . . . . . . . . . . . . . . . 13 76 6.2 GGSN-initiated NSIS signaling . . . . . . . . . . . . . . 15 77 7. NSIS Signaling within the IP-based Transport Part of 78 UMTS/GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 82 11. Change History . . . . . . . . . . . . . . . . . . . . . . . 17 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 12.1 Normative References . . . . . . . . . . . . . . . . . . . 18 85 12.2 Informative References . . . . . . . . . . . . . . . . . . 19 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 87 Intellectual Property and Copyright Statements . . . . . . . . 21 89 1. Requirements notation 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [1]. 95 2. Introduction 97 The NSIS working group is standardizing a signaling protocol suite 98 with QoS signaling as the first use case. The overall signaling 99 protocol suite is decomposed into a generic lower layer with separate 100 upper layers for signaling applications. The upper layer protocol, 101 called NSIS Signaling Layer Protocol (NSLP), has an end-to-end scope 102 and contains application specific functionality. QoS-NSLP [2] which 103 is an NSLP for QoS signaling defines message types and control 104 information generic to all QoS models (QOSMs). A QOSM is a defined 105 mechanism for achieving QoS as a whole. The specification of a QOSM 106 includes a description of its QSPEC parameter information and how 107 that information should be treated or interpreted in the network. 109 The QSPEC contains a set of parameters and values describing the 110 requested resources [3]. The QSPEC object also contains control 111 information and the QoS parameters defined by the QOSM. A QOSM 112 provides a specific set of parameters to be carried in the QSPEC. At 113 each QoS NSIS Entity (QNE), its contents are interpreted by the 114 resource management function (RMF) for policy control and traffic 115 control (including admission control and configuration of the packet 116 classifier and scheduler). 118 +----------+ /-------\ /--------\ /--------\ 119 | Laptop | | Home | | Cable | | Diffserv | 120 | Computer |-----| Network |-----| Network |-----| Network |----+ 121 | (QNE) | | No QOSM | |DQOS QOSM | | RMD QOSM | | 122 +----------+ \-------/ \--------/ \--------/ | 123 | 124 +-----------------------------------------------+ 125 | 126 | /--------\ +----------+ 127 | | "X"G | | Handheld | 128 +---| Wireless |-----| Device | 129 | XG QOSM | | (QNE) | 130 | (e.g., | +----------+ 131 |3GPP QOSM)| 132 \--------/ 134 Figure 1. An Example Configuration with Multiple Different QOSMs 136 Figure 1 shows a hybrid network comprised of multiple different QOSMs 138 [3]. One of the representative XG QOSMs shown in the figure could be 139 3GPP QOSM. QoS interworking between 3GPP wireless and non-3GPP 140 wireline networks will be essential if future IP-based next 141 generation networks are to provide assured-quality end-to-end IP 142 flows. 144 In general, in 3GPP UMTS, the wireless physical resource (e.g., 145 frequency spectrum, transmission power or time slots) can be 146 considered to be a significantly scarcer resource than the bandwidth 147 in IP backbone networks [8, 9]. The transmission is therefore 148 optimized in order to utilize the resources as efficiently as 149 possible. Furthermore, in UMTS, different radio bearer services can 150 be provided, that could result in different QoS characteristics, 151 service behaviors, and service costs. The key element for providing 152 optimal QoS with spectrum efficient usage of radio resources is the 153 radio management function. The optimal QoS support can only be 154 provided if the radio management function understands via the 3GPP 155 QOSM, the IP service requirements, and how the radio bearers can be 156 tailored to meet these needs. Therefore, the 3GPP QOSM should be 157 able to signal the user QoS requirements for a session, and as well a 158 set of parameters to control the characteristics of the radio bearers 159 in order to optimize the offered services while maximizing the 160 efficient use of the scarce radio resources. It is, therefore, 161 important to identify what parameters the radio management function 162 should get from an application that wishes to operate efficiently 163 over wireless networks. These parameters allow appropriate radio 164 bearers to be selected, and to determine the effects of these bearers 165 on the IP service characteristics. 167 This draft describes an NSIS QoS Model (QOSM) based on 3GPP QoS 168 classes and bearer service attributes. Specifically, this draft 169 describes additional optional parameters for QSPEC which carries 3GPP 170 QOSM specific information, how the QSPEC information should be 171 processed in QNEs, which and how other NSIS QoS models, e.g., RMD- 172 QOSM [13] and Y.1541-QOSM [4], can be applied and interoperate with 173 the 3GPP PDP context signaling. 175 3. Summary of 3GPP QoS Classes and Attributes 177 This section summarizes 3GPP QoS classes and bearer service 178 attributes which are used to describe the 3GPP QOSM. 180 3.1 3GPP QoS Classes 182 3GPP UMTS QoS classes were defined in TS 23.107[5] by taking the 183 restrictions and limitations of the air interface into account. The 184 QoS mechanisms provided in the cellular network have to be robust and 185 capable of providing reasonable QoS resolution. 187 There are four different UMTS QoS classes, i.e., Conversational 188 class, Streaming class, Interactive class, and Background class. The 189 main distinguishing factor between these QoS classes is how delay 190 sensitive the traffic is. For example, Conversational class is meant 191 for traffic which is very delay sensitive while Background class is 192 the most delay insensitive traffic class. 194 Conversational and Streaming classes are mainly intended to be used 195 to carry real-time traffic flows. The main divider between them is 196 how delay sensitive the traffic is. Conversational real-time 197 services, like video telephony, are the most delay sensitive 198 applications and those data streams should be carried in 199 Conversational class. 201 Interactive and Background classes are mainly meant to be used by 202 traditional Internet applications like WWW, E-mail, Telnet, FTP, and 203 News. Due to looser delay requirements, compared to Conversational 204 and Streaming classes, both provide better error rate by means of 205 channel coding and retransmission. The main difference between 206 Interactive and Background classes is that Interactive class is 207 mainly used by interactive applications, e.g., interactive e-mail or 208 interactive web browsing, while Background class is meant for 209 background traffic, e.g., background download of e-mail or background 210 file downloading. Traffic in the Interactive class has higher 211 priority in scheduling than Background class traffic, so background 212 applications use transmission resources only when interactive 213 applications do not need them. This is very important in wireless 214 environment where the bandwidth is scarce compared to fixed networks. 215 To achieve QoS interoperability for end-to-end QoS, the mappings 216 between 3GPP QoS classes (defined in TS 23.107) and non-3GPP QoS 217 Classes such as Y.1541 and DiffServ classes will be important. 219 3.2 3GPP QoS Attributes 221 UMTS bearer service attributes describe the service provided by the 222 UMTS network to the user of the UMTS bearer service. A set of QoS 223 attributes (QoS profile) defined in TS 23.107 are listed below [5]. 225 (a) Traffic class 227 (b) Maximum bitrate (kbps) 229 (c) Guaranteed bitrate (kbps) 231 (d) Delivery order (y/n) 233 (e) Maximum SDU size (octets) 234 (f) SDU format information (bits) 236 (g) SDU error ratio 238 (h) Residual bit error ratio 240 (i) Delivery of erroneous SDUs (y/n) 242 (j) Transfer delay (ms) 244 (k) Traffic handling priority 246 (l) Allocation/Retention Priority 248 (m) Source statistics descriptor ('speech'/'unknown') 250 (n) Signaling Indication (Yes/No) 252 4. QoS Mappings between TS 23.107 and Other QoS Models 254 The following two subsections illustrate possible mappings between 255 3GPP UMTS QoS classes in TS 23.107 and other QoS classes. These 256 mappings will be useful for interoperation between 3GPP networks and 257 non-3GPP networks. More detailed mappings will be implementation 258 specific. 260 4.1 QoS Mapping between TS 23.107 and Y.1541/DiffServ 262 4.1.1 Mapping between TS 23.107 and Y.1541 QoS Classes 264 ITU-T Recommendation Y.1541 proposes six QoS classes defined 265 according to the desired QoS performance objectives [4]. These QoS 266 classes support a wide range of user applications. The QoS classes 267 group performance objectives for one-way IP packet delay (IPTD), IP 268 packet delay variation (IPDV), IP packet loss ratio (IPLR), and IP 269 packet error ratio (IPER). Classes 0 and 1 support interactive real- 270 time applications, and Classes 2, 3, and 4, support non-interactive 271 applications. Class 5 has all the QoS parameters unspecified. These 272 classes serve as a basis for agreements between end-users and service 273 providers, and between service providers. They support a wide range 274 of traffic applications including point-to-point telephony, data 275 transfer, multimedia conferencing, and others. The limited number of 276 classes supports the requirement for feasible implementation, 277 particularly with respect to scale in global networks. 279 Based on the definitions above, the 3GPP Conversational and Streaming 280 classes may correspond to Y.1541 classes 0 and 1, respectively. The 281 two classes of Y.1541 and TS 23.107 are intended to support real-time 282 services. The Conversational class and Y.1541 class 0 have a more 283 stringent latency requirement than the Streaming class and Y.1541 284 class 1. In both specifications, jitter is intended to be limited. 285 In addition, the 3GPP Interactive class may correspond to Y.1541 286 classes 2, 3, and 4, and one of the relevant applications is 287 interactive data. More detailed mappings can be found in [10]. 289 4.1.2 Mapping between TS 23.107 and DiffServ QoS Classes 291 DiffServ [9] proposes differentiation in the queueing and forwarding 292 treatment received by packets at the routers in the network domain, 293 on the basis of DiffServ Code Points (DSCPs) included in their 294 headers at the ingress of the network domain. IETF has standardized 295 two groups of behavior aggregates, namely expedited forwarding or EF 296 (one class) and assured forwarding or AF (four classes each 297 containing three drop-precedence levels). The actual policies used 298 for marking, queueing and forwarding of packets at routers in 299 DiffServ domain is an implementation-specific issue. 301 EF per-hop behavior (PHB) group has been defined with the intention 302 of providing leased-line like service using DiffServ. This is 303 achieved by regulating the total rate of all the flows registered 304 with the EF PHB class to be less than the service rate allocated to 305 the EF PHB class at that node. Strict policing is enforced on the 306 flows, and any non-conforming packets are dropped at the ingress 307 itself. The AF PHB group has provision for classifying packets into 308 different precedence levels. Three such levels have been specified 309 and each level is associated with a drop precedence. Thus, each AF 310 class has three DSCPs reserved, one for each level. AF PHB group 311 defines a relationship between these three precedence levels. If 312 congestion occurs at a particular forwarding node, a packet with the 313 lowest drop precedence must have the lowest probability of being 314 dropped. Likewise, a packet with the highest drop precedence has the 315 highest probability of dropping. 317 Based on the definitions above, it appears that the 3GPP 318 Conversational class corresponds to EF PHB class which can support 319 low latency and jitter, and the 3GPP Streaming class may also 320 correspond to EF. The 3GPP Interactive class may correspond to AF4 321 or AF 3 (which can support low latency (but not as low as in 322 conversational class)), and the Background class may correspond to 323 AF2, AF1, or BE PHB class (which does not impose any special QoS 324 requirement). Please note that there may be different reasonable 325 mappings. 327 4.2 QoS Mapping between TS 23.107 and RMD-QOSM 329 In Section 8.4 of RFC 3726 [14] it is emphasized that in an UMTS like 330 scenario, (see Figure 2) the NSIS QoS protocol can be applied between 331 a base station and the gateway (GW). Furthermore, in this scenario 332 the NSIS QoS protocol can also be applied either between two GWs, or 333 between two edge routers (ERs). In these situations, the RMD-QOS 334 model [13] can be used to satisfy the requirements imposed by the 335 characteristics of such topologies. In these cases the mapping 336 between the attributes specified in [5] depends on bandwidth and 337 provisioning of resources among the different DiffServ classes which 338 the operators control to satisfy their cost and performance 339 requirements. 341 An example of mapping the TS 23.107 and RMD-QOSM DiffServ QoS Classes 342 could be similar to the mapping explained in Section 3.1.2. 344 An example of mapping the TS 23.107 and RMD-QOSM bandwidth parameters 345 is: 347 RMD QOSM = TS 23.107 349 |--| 350 |GW| 351 |--| |--| 352 |MH|--- . 353 |--| / |-------| . 354 /--|base | |--| . 355 |station|-|ER|... 356 |-------| |--| . |--| back- |--| |---| |----| 357 ..|ER|.......|ER|..|BGW|.."Internet"..|host| 358 -- |-------| |--| . |--| bone |--| |---| |----| 359 |--| \ |base |-|ER|... . 360 |MH| \ |station| |--| . 361 |--|--- |-------| . MH = mobile host 362 |--| ER = edge router 363 <----> |GW| GW = gateway 364 Wireless link |--| BGW = border gateway 365 ... = interior nodes 366 <-------------------> 367 Wired part of wireless network 369 <----------------------------------------> 370 Wireless Network 372 Figure 2. QoS Architecture of Wired Part of UMTS 374 5. Additional Optional QSPEC Parameters for 3GPP QOSM 376 Some of the 3GPP QoS attributes described in Section 2.2 are 377 specified in the QSPEC draft [3]. Additional optional QSPEC 378 parameters should be defined for appropriate radio resource 379 management in UMTS. This section provides the description and the 380 format of these additional optional parameters. More detailed 381 description will be provided in the later version of this draft. 383 [Editorial note: The number of the additional QSPEC parameters given 384 in this version is not fixed. Future versions of the draft may 385 include more QSPEC parameters.] 387 5.1 3GPP QoS Classes 389 Traffic class represents the type of application (i.e., 390 'conversational', 'streaming', 'interactive', or 'background') for 391 which the UMTS bearer service is optimized. By including the traffic 392 class as an attribute, UMTS can make assumptions about the traffic 393 source and optimize the transport for that traffic type. This 394 parameter can be defined in a way similar to the 395 parameter in [3] except for the number of classes, i.e., 4 in this 396 draft. 398 5.2 Delivery of Erroneous SDU (DES) 400 Delivery of erroneous SDUs (DES) indicates whether SDUs detected as 401 erroneous shall be delivered or discarded. 'yes' implies that error 402 detection is employed and that erroneous SDUs are delivered together 403 with an error indication, 'no' implies that error detection is 404 employed and that erroneous SDUs are discarded, and '-' implies that 405 SDUs are delivered without considering error detection. This 406 attribute is used to decide whether error detection is needed and 407 whether frames with detected errors shall be forwarded or not. 409 The DES (2 bits) parameter is represented as follows. 411 0 1 412 +-+-+ 413 |DES| 414 +-+-+ 416 Three values of DES are listed below to indicate different meanings. 418 0 - 'No' 419 1 - 'Yes' 420 2 - '-' 422 5.3 Source Statistics Descriptor (SSD) 424 Source statistics descriptor (SSD) specifies characteristics of the 425 source of submitted SDUs. Conversational speech has a well-known 426 statistical behaviour. By being informed that the SDUs for a UMTS 427 bearer are generated by a speech source, RAN, the serving GPRS 428 support node (SGSN) and the gateway GPRS support node (GGSN) and also 429 the user equipment (UE) may, based on experience, calculate a 430 statistical multiplex gain for use in admission control on the 431 relevant interfaces. The format of SSD parameter will be provided in 432 the later version of this draft. 434 5.4 Signaling Indication (SI) 436 Signaling Indication (SI) indicates the signaling nature of the 437 submitted SDUs. This attribute is additional to the other QoS 438 attributes and does not over-ride them. This attribute is only 439 defined for the interactive traffic class. If signaling indication 440 is set to 'Yes', the UE should set the traffic handling priority to 441 '1'. Signaling traffic can have different characteristics to other 442 interactive traffic, e.g., higher priority, lower delay, and so on. 443 This attribute permits enhancing the RAN operation accordingly. The 444 SI parameter (1 bit) is represented as follows. 446 0 447 +--+ 448 |SI| 449 +--+ 451 Two values of SI are listed below to indicate different meanings. 453 0 - 'No' 454 1 - 'Yes' 456 5.5 SDU Format Information (SFI) 458 The SDU format information represents the list of possible exact 459 sizes of SDUs. UMTS uses the Adaptive Multi-Rate (AMR) [11] or the 460 AMR Wideband (AMR-WB) [12] as speech transcoders. As emphasized in 461 [15], the speech bits encoded in each AMR or AMR-WB frame have 462 different perceptual sensitivity to bit errors. By applying this 463 property a better voice quality can be achieved using Unequal Error 464 Protection (UEP) and Unequal Error Detection (UED) mechanisms. These 465 mechanisms focus on the protection and detection of corrupted bits 466 only to the perceptually most sensitive bits in an AMR or AMR-WB 467 frame. In AMR and AMR-WB, these most sensitive bits are denoted as 468 class A bits. Two other classes are also used, i.e., B and C, 469 wherein the bits belonging into these classes are less sensitive to 470 errors. In this case, a frame is declared correct even when no bits 471 in class A are corrupted, and some bits in class B and C are indeed 472 corrupted. If the bits in class A are corrupted then the frame is 473 anyway declared corrupted. 475 The UEP and UED mechanisms could therefore be significant in 476 achieving spectrum efficient resource management. In order to be 477 able to use these mechanisms, information about the payload format 478 (class A, B and C sensitivity bits) is necessary at the radio level. 479 The specification of the SDU format as a service parameter allows any 480 application to take advantage of the UEP and UED mechanism. The 481 format of this parameter can be specified as follows. Two types of 482 AMR codecs should be supported. The first one is the typical AMR 483 codec, where the SDU format is described in Section 4 of [14]. 485 The second type of codec is the the AMR-WB (AMR- Wideband) codec. 486 The SDU format is described in Section 4 of [15]. The format of this 487 parameter should be a QSPEC Control Information container. Its 488 format should be: 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 |AT | FT |Q| MI | MR | CRC | Reserved | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 AT (AMR type): 2 bits integer used to soecify the used AMR type and 496 its values are: 498 0: (default) typical AMR codec as specified in [14] 499 1: AMR-WB (AMR- Wideband) codec as specified in [15]. 500 2: reserved for future use 501 3: reserved for future use 503 Frame Type (FT): 4 bits 505 Q (Frame Quality Indicator): 1 bit 507 MIndication (Mode Indication: MI): 4 bits 508 If AT = 0 then only the 3 Most Signifficant Bits are used 509 If AT = 1 then the 4 bits are used 511 MRequest (Mode Request: MR): 4 bits 512 If AT = 0 then only the 3 Most Signifficant Bits are used. 513 If AT = 1 then the 4 bits are used 515 CRC (Codec CRC): 8 bits 517 Note that the Frame Type and the Frame Quality Indicator represent 518 the AMR header. The Mode Indication, Mode Request and Codec CRC 519 parameters represent the AMR Auxiliary information. The Class A 520 bits, Class B bits and Class C bits represent the AMR Core frame. 521 Using the AMR header and AMR Auxiliary information the destination 522 can deduce how many bits should be used for Class A, how many for 523 Class B and how many for class C in the AMR Core frame. 525 5.6 Transfer Delay (TD) 527 [Editorial note: This parameter may have the same semantic behavior 528 as its associated QSPEC parameter (i.e., QSPEC Path Latency 529 Parameter) described in the QSPEC template draft. A future version 530 of this daft may use the associated QSPEC template parameter instead 531 of the currently specified one.] 533 Transfer delay (ms) indicates maximum delay for 95th percentile of 534 the distribution of delay for all delivered SDUs during the lifetime 535 of a bearer service. This parameter allows the radio management 536 function to efficiently configure the radio bearer service. For 537 example, by knowing the Delay requirement, the appropriate 538 interleaving depth can be estimated. This parameter could also be 539 used to determine the maximum number of retransmissions (if any) in 540 the wireless link. 542 The transfer delay (ms) is represented as a 32-bit integer as shown 543 below. 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Transfer delay (32-bit integer) | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 5.7 Packet Loss Ratio (PLR) 552 [Editorial note: This parameter may have the same semantic behavior 553 as its associated QSPEC parameter (i.e., QSPEC Path BER Parameter) 554 described in the QSPEC template draft. A future version of this daft 555 may use the associated QSPEC template parameter instead of the 556 currently specifeid one.] 558 The packet loss ratio can significantly affect the subjective quality 559 of real time applications. This parameter can be used by the radio 560 management function for admission control and to set some parameters 561 of the radio part, such as L2 buffer size. 563 The Packet Loss Ratio is represented as a 32-bit integer as shown 564 below. 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Packet Loss Ratio (32-bit integer) | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 5.8 Traffic Handling Priority (THP) 573 Traffic handling priority specifies the relative importance for 574 handling of all SDUs belonging to the UMTS bearer compared to the 575 SDUs of other bearers. In many interactive packet services the 576 packet handling priority can be used to provide certain levels of QoS 577 differentiation, in particular in congestion situations. According 578 to Section 6.5.1 of [5] the Traffic handling priority class can get 579 the values 1, 2 and 3. Therefore the format of this parameter is: 581 0 1 582 +-+-+ 583 |THP| 584 +-+-+ 586 Note that the length of this parameter is 2 bits integer. 588 6. Interoperation with 3GPP UMTS 590 This section describes two possible interoperation scenrios for NSIS 591 QoS signaling which is initiated by QNEs in UMTS. 593 6.1 UE-initiated NSIS signaling 595 This section describes an interoperation scenario for end-to-end NSIS 596 signaling that is initiated from a UE connected to a UTMS network. 597 Figure 3 shows an end-to-end network architecture [6, 7] used to 598 explain how end-to-end QoS signaling is achieved using NSIS in the 599 situation where 3GPP and non-3GPP networks are interconnected. 601 ^ +-----+ +----+ +------+ +------+ 602 IP | | | IP Bearer | | //------\\ | | | | 603 Bearer | | | Service | | | | | | | | 604 Layer | | |<----------| |-+---------+-| |-->| | 605 V |Local| | | | | |Remote| |Remote| 606 ============|UE |===========|GGSN| | Backbone| |Access|===|Host | 607 Access ^ | | | | | IP | |Point | | | 608 Bearer | | | +----+ | | | Network | | | | | 609 Layer | | |<-|SGSN|-->| | | | | |<->| | 610 (e.g. UMTS| | | +----+ | | \\------// | | | | 611 Bearer) V +-----+ +----+ +------+ +------+ 612 ^ ^ 613 +............+ 615 Scope of PDP Context 617 Figure 3. An End-to-End Network Architecture 619 Figure 4 shows signaling flows in the scenario. The UE acts as a QNI 620 and initiates NSIS signaling towards the remote end. The IP backbone 621 network is DiffServ-enabled, and the GGSN supports DiffServ. The 622 application layer (e.g., SIP/SDP) between the end hosts identifies 623 the QoS requirements. The QoS requirements from the application 624 layer are mapped down to create an NSIS session. The QoS for the 625 wireless access is provided by the PDP context. The wireless QoS can 626 be controlled through signaling for the PDP context. The UE 627 populates the initiator QSPEC and establishes the PDP context 628 suitable for supporting the NSIS session based on the QSPEC 629 information. 631 To activate the PDP context, the UE sends an Activate (Secondary) PDP 632 Context message to the SGSN with the UMTS QoS parameters, and the 633 SGSN sends the corresponding Create PDP Context message to the GGSN. 634 The GGSN authorizes the PDP context activation request according to 635 the local operator's IP bearer resource based policy, the local 636 operator's admission control function and the GPRS roaming agreements 637 and sends a Create PDP Context Response message back to the SGSN. 638 The radio access bearer (RAB) setup is done by the RAB assignment 639 procedure, and the SGSN sends an Activate (Secondary) PDP Context 640 Accept message to the UE. 642 Upon receiving the Activate PDP Context Accept message, the QoS-NSLP 643 at the UE (QNI) sends a QoS-NSLP RESERVE (in case of sender-initiated 644 approach) message which contains the Initiator QSPEC to the next hop 645 in the external IP network through the GGSN. The Initiator QSPEC 646 specifies optional parameters specific to 3GPP QoS model as well as 647 generic QSPEC parameters for the application flow. 649 UE (QNI) GGSN (QNF) Remote AP Remote Host (QNR) 650 | | | | 651 | Application Layer (e.g., SIP/SDP) | 652 |<...............................................>| 653 | | | | 654 | NSIS Signalling | 655 |<-------------------+------+-------------------->| 656 | | | | 657 | PDP Flow | | | 658 |------------------->| | | 659 | | | | 661 Figure 4. UE-initiated NSIS signaling 662 Please note that the NSIS signaling and the PDP signaling could also 663 be used in an interleaved way. 665 In the example above, only RMD-QOSM is assumed to be used in the 666 external network. The signaling procedure for QoS interworking in 667 the situation where the external network is based on Y.1541-QOSM will 668 be similar except for QoS mapping. 670 6.2 GGSN-initiated NSIS signaling 672 This section describes a scenario for NSIS signaling that is 673 initiated from the GGSN. That is, the GGSN acts as a QNI in this 674 scenario. 676 UE GGSN (QNI) Remote AP Remote Host (QNR) 677 | | | | 678 | Application Layer (e.g., SIP/SDP) | 679 |<...............................................>| 680 | | | | 681 | NSIS Signalling | 682 | <------+-------------------->| 683 | | | | 684 | PDP Flow | | | 685 |------------------->| | | 686 | | | | 688 Figure 5. GGSN-initiated NSIS signaling 690 Figure 5 shows signaling flows in the scenario. The GGSN acts as a 691 QNI and initiates NSIS signaling towards the remote end. The IP 692 backbone network is DiffServ enabled, and the GGSN supports DiffServ. 693 The application layer (e.g., SIP/SDP) between the end hosts 694 identifies the QoS requirements. The wireless QoS can be controlled 695 through signaling for the PDP context. Therefore, the QoS 696 requirements from the application layer are mapped down to the PDP 697 context at the UE. 699 To activate the PDP context, the UE sends an Activate (Secondary) PDP 700 Context message to the SGSN with the UMTS QoS parameters, and the 701 SGSN sends the corresponding Create PDP Context message to the GGSN. 702 The GGSN authorizes the PDP context activation request according to 703 the local operator's IP bearer resource based policy, the local 704 operator's admission control function and the GPRS roaming agreements 705 and sends a Create PDP Context Response message back to the SGSN. 706 The radio access bearer (RAB) setup is done by the RAB assignment 707 procedure, and the SGSN sends an Activate (Secondary) PDP Context 708 Accept message to the UE. 710 The GGSN populates the initiator QSPEC based on the PDP context to 711 create an NSIS session. The QoS-NSLP at the GGSN (QNI) sends a QoS- 712 NSLP RESERVE (in case of sender-initiated approach) message which 713 contains the Initiator QSPEC to the next hop in the external IP 714 network. The Initiator QSPEC specifies optional parameters specific 715 to 3GPP QoS model as well as generic QSPEC parameters for the 716 application flow. Note that QoS mapping between the 3GPP and 717 DiffServ QoS classes/parameters should be performed at the GGSN. 719 In the example above, only RMD-QOSM is assumed to be used in the 720 external network. The signaling procedure for QoS interworking in 721 the situation where the external network is based on Y.1541-QOSM will 722 be similar except for QoS mapping. 724 7. NSIS Signaling within the IP-based Transport Part of UMTS/GPRS 726 As emphasized in [5], the RAN/BSS Access bearer services and Core 727 network bearer services for packet traffic shall provide different 728 bearer services for variety of QoS. The operator is responsible for 729 choosing which QoS capabilities in Frame Relay layer, in IP layer or 730 in ATM layer are used. Regarding the IP based RAN/BSS Access bearer 731 services and Core network bearer services it is recommended that the 732 Differentiated Services defined by IETF shall be used. The NSIS RMD- 733 QOSM [13] satisfies this recommendation and therefore, it can be 734 considered as a feasible solution on satisfying the QoS requirements 735 imposed by the RAN Access bearer services and Core network bearer 736 services on the IP based transport part of UMTS/GPRS. The QoS 737 support in the IP based transport of UMTS/GPRS can be achieved by 738 combining either the UE (MS) initiated or the network initiated 739 Activate/Modify/Deactivate PDP context procedures, specified in [16] 740 with the NSIS RMD-QOSM procedures specified in [13]. This is 741 depicted in Figure 6, where either a UE (MS), or a SGSN or a GGSN can 742 start the PDP context procedures on requesting, modifying or deleting 743 a PDP context, in terms of QoS. The NSIS RMD-QOSM procedures can be 744 applied on the IP based transport network(s), see also Figure 2, 745 used between: 747 * Node B (Base Station) and RNC (or BSC) 748 * between RNC's (or BSC's) 749 * between SGSN and GGSN 751 A possible way of achieving the QoS mapping between the PDP context 752 procedures and the NSIS RMD-QOSM is described in Section 4.2. 754 UE Node B RNC SGSN GGSN 756 (MS) (Base Station) (BSC) 757 | | | | | 758 | | | | | 759 |Activate/Modify/Deactivate PDP context procedure| | 760 |<------------------------------------------------------------->| 761 | | | |NSIS RMD-QOSM | 762 | | | |<------------>| 763 |Activate/Modify/Deactivate PDP context procedure| | 764 |<------------------------------------------------------------->| 765 | | | | | 766 | | | | | 767 | | | | | 768 | | NSIS RMD-QOSM | | | 769 | |<------------->| | | 770 |Activate/Modify/Deactivate PDP context procedure| | 771 |<------------------------------------------------------------->| 772 | | | | | 774 Figure 6. NSIS Signaling within the IP-based Transport Part of 775 UMTS (and GPRS) 777 8. Security Considerations 779 There are no new security considerations based on this draft. 781 9. IANA Considerations 783 This section provides guidance to the Internet Assigned Numbers 784 Authority (IANA) regarding registration of values related to the 785 QSPEC template, in accordance with BCP 26 RFC 2434 [16]. [2] requires 786 IANA to create a new registry for QoS Model Identifiers. The QoS 787 Model Identifier (QOSM ID) is a 32-bit value carried in a QSPEC 788 object. The allocation policy for new QOSM IDs is TBD. This 789 document also defines new objects for the QSPEC Template, as etailed 790 in Section 5. Values are to be assigned for them from the NTLP 791 Object Type registry. 793 10. Acknowledgements 795 The authors thank Jongho Bang, Byoung-Joon Lee, Cornelia Kappler, 796 Jerry Ash, Al Morton, Gabor Fodor, Fredrik Persson, Brian Williams, 797 and Attila Bader for helpful comments and discussion. 799 11. Change History 801 11.1. Changes since -01 803 1. Updated abstract, introduction, and additional optional QSPEC 804 parameters 806 2. Created a new section "NSIS Signaling within the IP-based 807 Transport Part of UMTS/GPRS" 809 3. Updated figures regarding interoperation with UMTS 811 11.2. Changes since -00 813 1. Reduced the text for overview 815 2. Added QoS mapping between 3GPP TS 23.107 and RMD-QOSM 817 3. Updated additional optional QSPEC parameters 819 4. Updated interworking Scenarios for End-to-End QoS Support 821 5. Added Future Issues 823 12. References 825 12.1 Normative References 827 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 828 Levels", BCP 14, RFC 2119, March 1997. 830 [2] Bosch, S., "NSLP for Quality-of-Service signalling", 831 draft-ietf-nsis-qos-nslp-08 (work in progress), October 2005. 833 [3] Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-06 834 (work in progress), October 2005. 836 [4] Ash, J., "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using 837 Y.1541 QoS Classes", draft-ash-nsis-y1541-qosm-00 (work in 838 progress), May 2005. 840 [5] 3GPP, "Quality of Service (QoS) concept and architecture", 3GPP 841 TS 23.107 3.9.0, September 2002. 843 [6] 3GPP, "End-to-end Quality of Service (QoS) concept and 844 architecture", 3GPP TS 23.207 5.10.0, October 2005. 846 [7] 3GPP, "Architectural enhancements for end-to-end Quality of 847 Service (QoS)", 3GPP TR 23.802 7.0.0, October 2005. 849 [8] Fodor, G., Persson, F., and B. Williams, "Application of 850 Integrated Services on Wireless Accesses", 851 draft-fodor-intserv-wireless-issues-01 (work in progress), 852 January 2002. 854 [9] Fodor, G., Persson, F., and B. Williams, "Proposal on new 855 service parameters (wireless hints) in the controlled load 856 integrated service", draft-fodor-intserv-wireless-params-01 857 (work in progress), January 2002. 859 [10] Bain, G. and N. Seitz, "Mapping between ITU-T (Y.1541/Y.1221) 860 and 3GPP (TS 23-107) QoS Classes and Traffic Descriptions", 861 February 2004. 863 [11] 3GPP, "AMR speech Codec; Transcoding Functions", 3GPP TS 26.090 864 3.1.0, December 1999. 866 [12] 3GPP, "Speech codec speech processing functions; Adaptive 867 Multi-Rate - Wideband (AMR-WB) speech codec; Transcoding 868 functions", 3GPP TS 26.190 5.1.0, January 2002. 870 [13] Bader, A., "RMD-QOSM - The Resource Management in Diffserv QOS 871 Model", draft-ietf-nsis-rmd-04 (work in progress), 872 October 2005. 874 [14] 3GPP, "Mandatory speech codec speech processing functions; 875 Adaptive Multi-Rate (AMR) speech codec frame structure", 3GPP 876 TS 26.101 3.3.0, March 2002. 878 [15] 3GPP, "Speech codec speech processing functions; Adaptive 879 Multi-Rate - Wideband (AMR-WB) speech codec; Frame structure", 880 3GPP TS 26.201 5.0.0, April 2001. 882 [16] 3GPP, "General Packet Radio Service (GPRS); Service 883 description; Stage 2", 3GPP TS 23.060 3.16.0, January 2004. 885 12.2 Informative References 887 [17] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, 888 April 2004. 890 [18] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real- 891 Time Transport Protocol (RTP) Payload Format and File Storage 892 Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi- 893 Rate Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002. 895 [19] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 896 Considerations Section in RFCs", BCP 26, RFC 2434, 897 October 1998. 899 [20] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, 900 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 901 Specification", RFC 2205, September 1997. 903 [21] Wroclawski, J., "The Use of RSVP with IETF Integrated 904 Services", RFC 2210, September 1997. 906 [22] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. 907 Weiss, "An Architecture for Differentiated Services", RFC 2475, 908 December 1998. 910 Authors' Addresses 912 Seong-Ho Jeong 913 Hankuk University of FS 914 89 Wangsan Mohyun 915 Yongin-si, Gyeonggi-do 449-791 916 KOREA 918 Phone: +82 31 330 4642 919 Email: shjeong@hufs.ac.kr 921 Sung-Hyuck Lee 922 Samsung Advanced Institute of Technology 923 Comm. and Network Lab. 924 San 14-1, Nongseo-ri, Giheung-eup 925 Yongin-si, Gyeonggi-do 449-712 926 KOREA 928 Phone: +82 31 280 9585 929 Email: starsu.lee@samsung.com 931 Georgios Karagiannis 932 University of Twente 933 P.O. BOX 217 934 7500 AE, Enschede 935 Netherlands 937 Email: g.karagiannis@ewi.utwente.nl 939 Gert-Jan van Lieshout 940 Samsung Electronics Research Institute 941 Geert Grote straat 8a 942 7411GS, Deventer 943 Netherlands 945 Phone: +31(0)570615651 946 Email: gert.vanlieshout@samsung.com 948 Intellectual Property Statement 950 The IETF takes no position regarding the validity or scope of any 951 Intellectual Property Rights or other rights that might be claimed to 952 pertain to the implementation or use of the technology described in 953 this document or the extent to which any license under such rights 954 might or might not be available; nor does it represent that it has 955 made any independent effort to identify any such rights. Information 956 on the procedures with respect to rights in RFC documents can be 957 found in BCP 78 and BCP 79. 959 Copies of IPR disclosures made to the IETF Secretariat and any 960 assurances of licenses to be made available, or the result of an 961 attempt made to obtain a general license or permission for the use of 962 such proprietary rights by implementers or users of this 963 specification can be obtained from the IETF on-line IPR repository at 964 http://www.ietf.org/ipr. 966 The IETF invites any interested party to bring to its attention any 967 copyrights, patents or patent applications, or other proprietary 968 rights that may cover technology that may be required to implement 969 this standard. Please address the information to the IETF at 970 ietf-ipr@ietf.org. 972 Disclaimer of Validity 974 This document and the information contained herein are provided on an 975 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 976 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 977 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 978 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 979 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 980 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 982 Copyright Statement 984 Copyright (C) The Internet Society (2005). This document is subject 985 to the rights, licenses and restrictions contained in BCP 78, and 986 except as set forth therein, the authors retain all their rights. 988 Acknowledgment 990 Funding for the RFC Editor function is currently provided by the 991 Internet Society.