idnits 2.17.1 draft-kaippallimalil-netext-pmip-qos-wifi-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 18 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 116 has weird spacing: '... and sessio...' == Line 167 has weird spacing: '... to map the v...' == Line 846 has weird spacing: '...mission reque...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 10, 2014) is 3721 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 186, but not defined -- Looks like a reference, but probably isn't: '0' on line 719 -- Looks like a reference, but probably isn't: '1' on line 725 -- Looks like a reference, but probably isn't: '2' on line 728 -- Looks like a reference, but probably isn't: '3' on line 731 -- Looks like a reference, but probably isn't: '4' on line 734 -- Looks like a reference, but probably isn't: '5' on line 677 == Missing Reference: 'GSMA-IR34' is mentioned on line 1055, but not defined == Unused Reference: 'KEYWORDS' is defined on line 905, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 908, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 911, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 916, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 919, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 922, but no explicit reference was found in the text == Unused Reference: 'RFC 2211' is defined on line 944, but no explicit reference was found in the text == Unused Reference: 'RFC 2212' is defined on line 947, but no explicit reference was found in the text == Unused Reference: 'RFC 2216' is defined on line 951, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-netext-pmip6-qos-11 Summary: 1 error (**), 0 flaws (~~), 17 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT John Kaippallimalil 3 Intended Status: Informational Huawei 4 Expires: August 14, 2014 Rajesh S. Pazhyannur 5 Cisco 6 Parviz Yegani 7 Juniper 8 February 10, 2014 10 Mapping 802.11 QoS in a PMIPv6 Mobility Domain 11 draft-kaippallimalil-netext-pmip-qos-wifi-04 13 Abstract 15 This document provides recommendations on procedures and mapping of 16 QoS parameters between 802.11 and PMIPv6. QoS parameters in 802.11 17 that reserve resources for 802.11 streams should be mapped to PMIP 18 QoS resources for IP sessions and flows. QoS reservation sequences in 19 802.11 should allow cases where MN initiate resource reservation, as 20 well as cases where the network initiates resource reservation. 21 Additionally, it should be possible for QoS parameters for PMIPv6 22 flows and mobility sessions to be mapped to 802.11 traffic stream 23 reservations. The sequences and parameters to be mapped to provide a 24 consistent behavior across 802.11 and PMIPv6 QoS are described here. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as 34 Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 Copyright and License Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 6 68 2. End-to-End QoS with no Admission Control . . . . . . . . . . . 6 69 3. End-to-End QoS with Admission Control . . . . . . . . . . . . . 8 70 3.1. Case A: MN Initiates QoS Request . . . . . . . . . . . . . 9 71 3.2. Case B: Network Initiates QoS Signaling (802.11aa based) . 11 72 3.3. Case C: Hybrid (Network Initiated for PMIP, MN initiated 73 in 802.11) . . . . . . . . . . . . . . . . . . . . . . . . 12 74 3.4. Case D: Network Initiated Release . . . . . . . . . . . . . 14 75 3.5. Case E: MN Initiated Release . . . . . . . . . . . . . . . 16 76 3.6. Service Guarantees in 802.11 . . . . . . . . . . . . . . . 17 77 4. Mapping of QoS Parameters . . . . . . . . . . . . . . . . . . . 17 78 4.1 Connection Mapping . . . . . . . . . . . . . . . . . . . . . 18 79 4.2. QoS Class . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 4.3. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 4.4. Preemption Priority . . . . . . . . . . . . . . . . . . . . 20 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 20 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 7.1. Normative References . . . . . . . . . . . . . . . . . . . 21 86 7.2. Informative References . . . . . . . . . . . . . . . . . . 21 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 88 Appendix A: QoS in 802.11, PMIPv6 and 3GPP Networks . . . . . . . 23 89 A.1. QoS in IEEE 802.11 Networks . . . . . . . . . . . . . . . . 23 90 A.2. QoS in PMIPv6 Mobility domain . . . . . . . . . . . . . . . 23 91 A.3. QoS in 3GPP Networks . . . . . . . . . . . . . . . . . . . 24 93 1. Introduction 95 802.11 networks can currently apply QoS policy by using ALG 96 (Application Level Gateway) to detect an application (e.g. SIP 97 signaling) and then install QoS for the corresponding IP flow on the 98 Wireless LAN Controller (WLC)/ Access Point (AP). However, this is 99 not a general mechanism and would require ALG or detection of 100 application level semantics in the access to install the right QoS. 102 [PMIP-QoS] describes a application neutral procedure to obtain QoS 103 for PMIPv6 flows and sessions. However, there are differences in 104 parameters and procedures that need to be mapped between PMIPv6 QoS 105 and 802.11. PMIPv6 has the notion of QoS for mobility sessions and 106 flows while in 802.11 these should correspond to QoS for 802.11 data 107 frames. Parameters in 802.11 QoS do not always have a one-to-one 108 correspondence in PMIPv6 QoS. Further, 802.11 and PMIP QoS procedures 109 need to be aligned based on whether QoS setup is triggered by the MN 110 or pushed by the the network, as well as working with WMM or 802.11aa 111 mechanisms. 113 This document provides information on using PMIPv6 QoS parameters for 114 an MN connection over a 802.11 access network. The recommendations 115 here allow for dynamic QoS policy information per Mobile Node (MN) 116 and session to be configured by the 802.11 access network. PMIPv6 117 QoS signaling between MAG and LMA provisions the per MN QoS policies 118 in the MAG. In the 802.11 access network modeled here, the MAG is 119 located at the Access Point (AP)/ Wireless LAN Controller (WLC) . 120 Figure 1 below provides an overview of the entities and protocols. 122 +--------+ +-------+ 123 | AAA | | PCF | 124 +---+----+ +---+---+ 125 | | 126 | | 127 +----+ +---+----+ +---+---+ 128 | | 802.11 (WMM, 802.11aa) | | PMIPv6 | | 129 | MN <------------------------> AP/WLC <==========> LMA | 130 | | (ADDTS, DELTS) | (MAG) | QoS | | 131 +----+ +--------+ +-------+ 133 Figure 1: QoS Policy in 802.11 Access 135 MN and AP/WLC use 802.11 QoS mechanisms to setup admission controlled 136 flows. The AP/WLC is a MAG that requests for QoS policy from the LMA. 137 The MN uses ADDTS (Add Traffic Stream) to setup QoS for a traffic 138 stream between itself and the AP, and DELTS (Delete Traffic Stream) 139 to delete that stream. In WMM [WMM 1.2.0], the AP advertises if 140 admission control is mandatory for an access class. Admission control 141 for best effort or background access classes is not recommended. In 142 addition to WMM capability, 802.11aa allows for AP/WLC to support an 143 ADDTS reservation request to the MN. This makes it simpler to support 144 a PMIPv6 QoS request that is pushed to the AP/WLC. 146 The parameter mapping recommendations described here support the 147 procedures by which the 3GPP network provisions QoS per application 148 dynamically or during authorization of the Mobile Node (MN). However, 149 the 802.11 procedures described here are not limited to work for just 150 the 3GPP policy provisioning. If PMIPv6 QoS parameters can be 151 provisioned on the MAG via mechanisms defined in [PMIP-QoS], the 152 802.11 procedures can be applied in general for provisioning OoS in a 153 802.11 network. 155 PMIPv6 QoS parameters need to be mapped to 802.11 QoS parameters. In 156 some cases, there is no one-to-one mapping. And in other cases such 157 as bandwidth, the values received in PMIP should be mapped to the 158 right 802.11 parameters. This document provides recommendations to 159 perform QoS mapping between PMIPv6 and 802.11 QoS. 161 [PMIP-QoS] does not explicitly describe how the QoS signaling and QoS 162 sub-options map into corresponding signaling and parameters in the 163 802.11 access network. This mapping and the procedures in the 802.11 164 network to setup procedures are the focus of this document. The 165 end-to-end flow spanning 802.11 access and PMIPv6 domain and the QoS 166 parameters in both segments are described here. Thus, it provides a 167 systematic way to map the various QoS parameters available in 168 initial authorization, as well as setup of new sessions (such as a 169 voice/video call). The mapping recommendations allow for proper 170 provisioning and consistent interpretation between the various QoS 171 parameters provided by PMIP QoS, and 802.11. 173 The rest of the document is organized as follows. Chapter 2 provides 174 an overview of establishing mobility sessions with no admission 175 control. These mechanisms are specified in [PMIP QoS] and outlined 176 here since the mobility session established is the basis for 177 subsequent admission controlled requests for flows. Chapter 3 178 describes how end to end QoS with 802.11 admission control is 179 achieved. The mapping of parameters between 802.11 and PMIP QoS is 180 described in Chapter 5. 182 1.1. Terminology 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in RFC 2119 [RFC2119]. 187 1.2. Definitions 189 Guaranteed Bit Rate (GBR) 190 GBR in a mobile network defines the guaranteed (reserved) bit 191 rate resources of service data flow on a connection (bearer) 192 [TS23.203]. 194 Maximum Bit Rate (AMBR) 195 MBR represents the maximum bandwidth of a flow with reservation. 197 Aggregate Maximum Bit Rate (MBR) 198 AMBR represents the total bandwidth that all flows of a user is 199 allowed. AMBR does not include flows with reservation. 201 Allocation Retention Priority (ARP) 202 ARP is used in the mobile network to determine the order in which 203 resources for a flow may be preempted during severe congestion or 204 other resource limitation. ARP of 1 is the highest priority while 205 15 is the lowest [TS23.203]. 207 Peak Data Rate 208 In WMM, Peak Data Rate specifies the maximum data rate in bits 209 per second. The Maximum Data Rate does not include the MAC and 210 PHY overheads [WMM 1.2.0]. 212 Mean Data Rate 213 This is the average data rate in bits per second. The Mean Data 214 Rate does not include the MAC and PHY overheads [WMM1.2.0] 216 Minimum Data Rate 217 In WMM, Minimum Data Rate specifies the minimum data rate in bits 218 per second. The Minimum Data Rate does not include the MAC and 219 PHY overheads [WMM 1.2.0]. 221 TSPEC 222 The TSPEC element in 802.11 contains the set of parameters that 223 define the characteristics and QoS expectations of a traffic 224 flow. 226 TCLAS 227 The TCLAS element specifies an element that contains a set of 228 parameters necessary to identify incoming MSDU (MAC Service Data 229 Unit) that belong to a particular TS (Traffic Stream) [802.11]. 231 1.3. Abbreviations 233 3GPP Third Generation Partnership Project 234 AAA Authentication Authorization Accounting 235 AMBR Aggregate Maximum Bit Rate 236 ARP Allocation and Retention Priority 237 AP Access Point 238 DSCP Differentiated Services Code Point 239 EPC Enhanced Packet Core 240 GBR Guaranteed Bit Rate 241 MAG Mobility Access Gateway 242 MBR Maximum Bit Rate 243 MN Mobile Node 244 PCF Policy Control Function 245 PDN-GW Packet Data Network Gateway 246 QCI QoS Class Indicator 247 QoS Quality of Service 248 TCLAS Type Classification 249 TSPEC Traffic Conditioning Spec 250 WLC Wireless Controller 252 2. End-to-End QoS with no Admission Control 254 PMIPv6 and 802.11 QoS with no admission control is specified in [PMIP 255 QoS]. This section is provided as background here since prior to the 256 establishment of an admission controlled flow, a mobility session as 257 described here is established. IETF (RFC 4594) and GSMA have defined 258 mapping between DSCP and IEEE 802.11 UP (User Priority). The AP/WLC 259 (MAG) should be pre-configured to use the mapping from one of these 260 specifications. 262 An MN that attempts to connect to a 802.11 network typically 263 authenticates first and may have an authorization profile downloaded. 264 The AP/WLC may use the QoS profile for the MN for policing flows. 265 However, the network can obtain more dynamic policy that corresponds 266 to current mobile network conditions and preferences using PMIP QoS. 268 +--------+ 269 +----+ | AP/WLC | +-------+ 270 | MN | | (MAG) | | LMA | 271 +-+--+ +---+----+ +---+---+ 272 | | | 273 +-------------------------------------------------------------+ 274 | [0] connection setup to mobile network | 275 +-------------------------------------------------------------+ 276 | | | 277 | | PBU(QoS-i, ALLOC)[1] | 278 | |---------------------->| QoS Policy 279 | | PBA (QoS-r, NEG) [2] |<---------------> 280 | |<----------------------| 281 | | | 282 | | PBU(QoS-r, ALLOC)[3] | 283 | |---------------------->| 284 | | PBA (QoS-r, RESP)[4] | 285 | |<----------------------| 286 | | | 288 Figure 2: Default connection setup 290 [0] MN signals to setup connection. The AP/WLC obtains an 291 authorization profile that includes QoS information, or may have 292 an administratively configured profile with QoS information. 294 [1] The completion of 802.11 and IP setup serves as a trigger for 295 the MAG (AP/WLC) to request for dynamic QoS parameters. The MAG 296 sends a PBU containing QoS Option with operation code set to 297 ALLOCATE, and DSCP, QoS Attributes set to initially authorized 298 values for the MN's default connection (QoS-i). 300 This request is for QoS of all flows of a connectivity session 301 of the MN and includes DSCP, Per-MN-Agg-Max-DL-Bit-Rate, Per-MN- 302 Agg-Max-UL-Bit-Rate, Per-Session-Agg-Max-DL-Bit-Rate, Per- 303 Session-Agg-Max-UL-Bit-Rate and Allocation-Retention-Priority 304 fields derived from the MN initial authorization profile. The 305 Traffic Selector field should not be present. 307 [2] The LMA queries the policy server and obtains a response. The 308 policy server may grant the QoS requested or may change the QoS 309 levels based on network or other dynamic conditions (QoS-r in 310 figure). This example assumes that the LMA cannot provide the 311 QoS requested by the MAG. 313 The LMA sets the operational code to NEGOTIATE and responds with 314 downgraded parameters for DSCP, Per-MN-Agg-Max-DL-Bit-Rate, Per- 315 MN-Agg-Max-UL-Bit-Rate, Per-Session-Agg-Max-DL-Bit-Rate, Per- 316 Session-Agg-Max-UL-Bit-Rate and Allocation-Retention-Priority. 317 The Traffic Selector field is not present since the provisioning 318 applies to the entire PMIPv6 connectivity session. 320 [3] The MAG receives the downgraded QoS and sends a revised PBU with 321 the QoS options that the LMA is prepared to offer. The 322 operational code is set to ALLOCATE. 324 [4] The LMA can accept the requested QoS. The LMA sends a PBA 325 message with the revised QoS options and operational code set to 326 RESPONSE. 328 The new QoS values will be used by the MAG to police flows of the MN 329 and will supercede earlier (or initially) provisioned QoS values. MAG 330 polices session flows to not exceed Per-Session-Agg-Max-DL-Bit-Rate, 331 Per-Session-Agg-Max-UL-Bit-Rate. If there are multiple sessions, the 332 total bandwidth should not exceed Per-MN-Agg-Max-DL-Bit-Rate, Per-MN- 333 Agg-Max-UL-Bit-Rate. 335 3. End-to-End QoS with Admission Control 337 This section outlines a few use cases to illustrate how parameters 338 and mapping are applied for flows that require admission control. 339 These cases illustrate the various provisioning sequences and 340 mechanisms. It is not intended to be exhaustive. 342 The general procedure here is that a flow that requires admission 343 control is part of a PMIPv6 connectivity session. QoS options for the 344 overall session are provisioned as described in section 2. As a 345 result of some application layer signaling, specific flows of the 346 application may require admission controlled QoS which can be 347 provisioned on a per flow basis. 349 There are two main types of interaction possible to provision QoS for 350 flows that require admission control - one case is where the MN 351 initiates the QoS request and the network provisions the resources. 352 The second is where the network provisions resources as a result of 353 some out of band signaling (like application signaling). In the 354 second scenario, if the MN supports 802.11aa, the network can push 355 the QoS configuration to the MN. If the MN only supports WMM QoS, 356 then MN requests for QoS for the 802.11 segment and the MAG 357 provisions based on QoS already provisioned for the MN. These three 358 cases are described in sections 3.1 - 3.3. 360 In each of the sequences, QoS parameters need to be mapped between 361 802.11 and PMIPv6. The table below provides an overview of the 362 mapping for establishing QoS for an admission controlled flow. 364 Further details of the parameters and mappings are provided in 365 section 4. 367 +------------------------------+------------------------------+ 368 | MN <--> AP/WLC(802.11) | AP/WLC(MAG) <--> LMA PMIPv6 | 369 +------------------------------+------------------------------+ 370 | (TCLAS) TCP/UDP IP | Traffic Selector (IP flow) | 371 | (TCLAS) User Priority | DSCP | 372 +------------------------------+------------------------------+ 373 | (TSPEC)Minimum Data Rate, DL | Guaranteed-DL-Bit-Rate | 374 | (TSPEC)Minimum Data Rate, UL | Guaranteed-UL-Bit-Rate | 375 | (TSPEC)Mean Data Rate UL/DL | - | 376 | (TSPEC)Peak Data Rate, DL | Aggregate-Max-DL-Bit-Rate | 377 | (TSPEC)Peak Data Rate, UL | Aggregate-Max-UL-Bit-Rate | 378 +------------------------------+------------------------------+ 380 Table 1: 802.11 - PMIPv6 QoS Parameter Mapping 382 3.1. Case A: MN Initiates QoS Request 384 During an MN flow setup that requires admission control in the 802.11 385 network, QoS parameters for the flow needs to be provisioned. This 386 procedure outlines the case where the MN is configured (e.g. in SIM) 387 to start the QoS signaling. In this case, the MN sends an ADDTS 388 request indicating the QoS required for the flow. The AP/WLC (MAG) 389 obtains the corresponding level of QoS to be granted to the flow by 390 PMIPv6 PBU/PBA sequence with QoS options with the LMA. Details of the 391 QoS provisioning for the flow are described below. 393 +--------+ 394 +----+ | AP/WLC | +-------+ 395 | MN | | (MAG) | | LMA | 396 +-+--+ +---+----+ +---+---+ 397 | | | 398 +-------------------------------------------------------------+ 399 | [0] establish connection session to mobile network | 400 +-------------------------------------------------------------+ 401 | | | 402 +-------------+ | | 403 |upper layer | | | 404 |notification | | | 405 +-+-+-+-+-+-+-+ | | 406 | | | 407 | ADDTS Request (TCLAS,TSPEC) | | 408 |---------------------------->| PBU(QoS options)[2] | 409 | [1] |-------------------->| QoS Policy 410 | |PBA (QoS option) [3] |<---------> 411 | ADDTS Response(TCLAS,TSPEC) |<--------------------| 412 |<----------------------------| | 413 | [4] | | 415 Figure 3: MN initiated QoS setup 417 [0] The MN has a best effort connectivity session as described in 418 section 2. This allows the MN to perform application level 419 signaling and setup. 421 [1] The trigger for MN to request QoS is an upper layer 422 notification. This may be the result of end-to-end application 423 signaling and setup procedures (e.g. SIP) 425 If the MN is configured to start QoS signaling, the MN sends an 426 ADDTS request with TSPEC and TCLAS identifying the flow for 427 which QoS is requested. The TSPECs for both uplink and downlink 428 in this request should contain the Minimum Data Rate and Peak 429 Data Rate . 431 [2] If there are sufficient resources at the AP/WLC to satisfy the 432 request, the MAG (AP/WLC sends a PBU with QoS options, 433 operational code ALLOCATE and Traffic Selector identifying the 434 flow. The Traffic selector is derived from the TCLAS to identify 435 the flow requesting QoS. 802.11 QoS parameters in TSPEC are 436 mapped to PMIPv6 parameters. The mapping of TCLAS and TSPEC 437 parameters to PMIPv6 is shown in Table 1. 439 [3] The LMA obtains the authorized QoS for the flow and responds to 440 the MAG with operational code set to RESPONSE. Mapping of PMIPv6 441 parameters to 802.11 TSPEC and TCLAS is shown in Table 1. 443 In networks like 3GPP, the reserved bandwidth for flows are 444 accounted separately from the non-reserved session bandwidth. 445 The Traffic Selector identifies the flow for which the QoS 446 reservations are made. 448 [4] The AP/WLC (MAG) provisions the corresponding QoS and replies 449 with ADDTS Response containing authorized QoS in TSPEC and flow 450 identification in TSPEC. 452 The AP/WLC polices these flows according to the QoS 453 provisioning. 455 3.2. Case B: Network Initiates QoS Signaling (802.11aa based) 457 In some cases (e.g. LTE/SAE), the policy server in the network may be 458 configured to initiate the policy reservation request for a flow. 459 This use case illustrates how an MN and 802.11 network that support 460 802.11aa can provision QoS to flows of the MN that when the policy 461 server pushes the reservation request. 462 +--------+ 463 +----+ | AP/WLC | +-------+ 464 | MN | | (MAG) | | LMA | 465 +-+--+ +---+----+ +---+---+ 466 | | | 467 +----------------------------------------------------------------+ 468 | [0] establish connection session to mobile network | 469 +----------------------------------------------------------------+ 470 | | | 471 | | | Policy update 472 | |UPN(QoS option)[2]|<------------- 473 | ADDTS Reserve Request |<-----------------| [1] 474 | (TCLAS, TSPEC)[3] | | 475 |<----------------------------| | 476 | ADDTS Reserve Response | | 477 | (TCLAS, TSPEC)[4] | | 478 |---------------------------->| | 479 | |UPA(QoS option)[5]| 480 | |----------------->| 481 | | | 483 Figure 4: Network initiated QoS setup with 802.11aa 485 [0] The MN sets up best effort connectivity session as described in 486 Case A. This allows the MN to perform application level 487 signaling and setup. 489 [1] The policy server sends a QoS reservation request to the LMA. 490 This is usually sent in response to an application that requests 491 the policy server for higher QoS for some of its flows. 493 The LMA reserves resources for the flow requested. 495 [2] LMA sends PMIP UPN (Update Notification) to the MAG with QoS 496 parameters for the flow for which the LMA reserved resources in 497 step [1]. In UPN, the operational code in QoS option is set to 498 ALLOCATE and the Traffic Selector identifies the flow for QoS. 500 The LMA QoS parameters include Guaranteed-DL-Bit- 501 Rate/Guaranteed-UL-Bit-Rate and Aggregate-Max-DL-Bit- 502 Rate/Aggregate-Max-UL-Bit-Rate for the flow. In networks like 503 3GPP, the reserved bandwidth for flows are accounted separately 504 from the non-reserved session bandwidth. 506 [3] If there are sufficient resources to satisfy the request, the 507 AP/WLC (MAG) sends an ADDTS Reserve Request (802.11aa) 508 specifying the QoS reserved for the traffic stream including 509 TSPEC and TCLAS element mapped from PMIP QoS Traffic Selector to 510 identify the flow. 512 PMIPv6 parameters are mapped to TCLAS and TSPEC as shown in 513 Table 1. 515 If there are insufficient resources at the AP/WLC, the MAG will 516 not send and ADDTS message and will continue processing of step 517 [5]. 519 [4] MN accepts the QoS reserved in the network and replies with 520 ADDTS Reserve Response. 522 [5] The MAG (AP/WLC) replies with UPA confirming the acceptance of 523 QoS options and operational code set to RESPONSE. The AP/WLC 524 police flows based on the new QoS. 526 If there are insufficient resources at the AP/WLC, the MAG sends 527 a response with UPA status code set to 528 CANNOT_MEET_QOS_SERVICE_REQUEST. 530 3.3. Case C: Hybrid (Network Initiated for PMIP, MN initiated in 531 802.11) 533 This use case outlines a scenario where an MN attaches to the 802.11 534 and then obtains services in the mobile network. When the MN 535 attaches, PMIP signaling between the MAG and LMA establishes mobile 536 connection and related QoS. Subsequently, the MN starts an 537 application that requires dedicated bandwidth resources and signals 538 that using TSPEC/ADDTS request. The details of this sequence are 539 described below. 540 +--------+ 541 +----+ | AP/WLC | +-------+ 542 | MN | | (MAG) | | LMA | 543 +-+--+ +---+----+ +---+---+ 544 | | | 545 | | | 546 +---------------------------------------------------------------+ 547 | [0] establish connection session to mobile network | 548 +---------------------------------------------------------------+ 549 | | | Policy update 550 | | UPN(QoS option)[2] |<-------------- 551 | |<-------------------| [1] 552 +-------------+ | UPA(QoS option)[3] | 553 |upper layer | |------------------->| 554 |notification | | | 555 +-+-+-+-+-+-+-+ | | 556 | | | 557 | ADDTS Request(TSPEC)[4] | | 558 |------------------------>| | 559 | ADDTS Response(TSPEC)[5]| | 560 |<------------------------| | 561 | | | 563 Figure 5: Network initiated QoS setup with WMM 565 [0] The MN sets up best effort connectivity session as described in 566 Case A. This allows the MN to perform application level 567 signaling and setup. 569 [1] The policy server sends a QoS reservation request to the LMA. 570 This is usually sent in response to an application that requests 571 the policy server for higher QoS for some of its flows. 573 The LMA reserves resources for the flow requested. 575 [2] LMA sends PMIP UPN (Update Notification) to the MAG with QoS 576 option operational code set to ALLOCATE and QoS parameters for 577 which the LMA reserved resources in step [1]. In UPN, the 578 Traffic selector field in QoS Option identifies the flow for 579 QoS. 581 The LMA QoS parameters include Guaranteed-DL-Bit- 582 Rate/Guaranteed-UL-Bit-Rate and Aggregate-Max-DL-Bit- 583 Rate/Aggregate-Max-UL-Bit-Rate for the flow. In networks like 584 3GPP, the reserved bandwidth for flows are accounted separately 585 from the non-reserved session bandwidth. This is indicated by 586 using the Traffic Selector in PMIPv6 QoS. 588 [3] If there are sufficient resources to satisfy the request, the 589 MAG (AP/WLC) replies with UPA confirming the acceptance of QoS 590 options and operation code set to RESPONSE. If there are 591 insufficient resources at the AP/WLC, the MAG may send a 592 response with UPA status code set to 593 CANNOT_MEET_QOS_SERVICE_REQUEST. 595 The AP/WLC can police flows based on the new QoS. However, the 596 AP/WLC does not initiate QoS reservation signaling on 802.11 597 because either it or the MN does not support 802.11aa. 599 [4] The trigger for the MN to request QoS is an upper layer 600 notification. This may be the result of end-to-end application 601 signaling and setup procedures (e.g. SIP) 603 The MN sends an ADDTS request with TSPEC and TCLAS identifying 604 the flow for which QoS is requested. The TSPECs for both uplink 605 and downlink in this request should contain the Minimum Data 606 Rate and Peak Data Rate. The MAG maps PMIPv6 parameters obtained 607 earlier as shown in Table 1. 609 If the MN supports only WMM QoS, TCLAS is not sent. The AP/WLC 610 may identify the flow based on connection signaling (e.g. 3GPP 611 23.402, WCS), most recent updates from PMIP QoS (i.e. that in 612 message [3] above), or some combination thereof. 614 [5] The AP/WLC (MAG) provisions the corresponding QoS and replies 615 with ADDTS Response containing authorized QoS in TSPEC. 617 The AP/WLC (MAG) may revise the offer to the MN based on PMIPv6 618 QoS reservation. 620 3.4. Case D: Network Initiated Release 622 QoS resources reserved for a session are released on completion of 623 the session. When the application session completes, the policy 624 server, or the MN may signal for the release of resources. In this 625 use case, the network initiates the release of QoS resources. 627 +--------+ 628 +----+ | AP/WLC | +-------+ 629 | MN | | (MAG) | | LMA | 630 +-+--+ +---+----+ +---+---+ 631 | | | 632 +-------------------------------------------------------------+ 633 | [0] Establishment of application session | 634 | and reservation of QoS resources | 635 | | 636 | ( Session in progress) | 637 | | 638 | Release of application session | 639 +-------------------------------------------------------------+ 640 | | | Policy update 641 | |UPN(QoSx,DE-ALLOC)[2]<-------------- 642 | |<-------------------| [1] 643 | |UPA(QoSx,RESPONSE)[3] 644 | |------------------->| 645 | DELTS Request | | 646 | (TS INFO)[4] | | 647 |<-----------------------| | 648 | DELTS Response | | 649 | (TS INFO)[5] | | 650 |----------------------->| | 651 | | | 653 Figure 6: Network initiated QoS resource release 655 [0] The MN establishes and reserves QoS resources as in use cases A, 656 B or C. 657 When the application session terminates, the policy server 658 receives notification that the session has terminated. 660 [1] LMA receives a policy update indicating that QoS for flow (QoSx) 661 should be released. The LMA releases local resources associated 662 with the flow. 664 [2] LMA sends a UPN with QoS options - Traffic Selector field 665 identifying the flow for which QoS resources are to be released, 666 and operation code set to DE-ALLOCATE. No additional LMA QoS 667 parameters are sent. 669 [3] MAG replies with UPA confirming the acceptance and operation 670 code set to RESPONSE. 672 [4] AP/WLC (MAG) releases local QoS resources associated with the 673 flow. AP/WLC derives the corresponding 802.11 Traffic Stream 674 from the PMIPv6 Traffic Selector. The AP sends a DELTS Request 675 with TS INFO identifying the reseravtion. 677 [5] MN sends DELTS Response confirming release. 679 Since the MN has completed the session, it may send a DELTS to 680 explicitly request release QoS resources at AP. If the AP and MN 681 are 802.11aa capable, the release of resources may also be 682 signaled to the MN. 684 3.5. Case E: MN Initiated Release 686 QoS resources reserved for a session are released on completion of 687 the session. When the application session completes, the policy 688 server, or the MN may signal for the release of resources. In this 689 use case, the network initiates the release of QoS resources. 691 +--------+ 692 +----+ | AP/WLC | +-------+ 693 | MN | | (MAG) | | LMA | 694 +-+--+ +---+----+ +---+---+ 695 | | | 696 +-------------------------------------------------------------+ 697 | [0] Establishment of application session | 698 | and reservation of QoS resources | 699 | | 700 | ( Session in progress) | 701 | | 702 | Release of application session | 703 +-------------------------------------------------------------+ 704 | | | 705 | DELTS Request | | 706 | (TS INFO)[1] | | 707 |----------------------->| | 708 | DELTS Response | | 709 | (TS INFO)[2] | | 710 |<-----------------------| | 711 | |PBU(QoSx,DE-ALLOC)[3] 712 | |------------------->| Policy Update 713 | |PBA(QoSx,RESPONSE)[4]<------------> 714 | |<-------------------| 715 | | | 717 Figure 6: Network initiated QoS resource release 719 [0] The MN establishes and reserves QoS resources as in use cases A, 720 B or C. 722 When the application session terminates, the MN prepares to 723 release QoS resources. 725 [1] MN releases its own internal resources and sends a DELTS Request 726 to the AP/WLC with TS (Traffic Stream) INFO. 728 [2] AP/WLC receives the DELTS request, releases local resources and 729 responds to MN with a DELTS response. 731 [3] AP/WLC (MAG) initiates a PBU with Traffic Selector constructed 732 from TCLAS and PMIPv6 QoS parameters from TSPEC (QoSx) as shown 733 in Table 1. 734 [4] LMA receives the PBU, releases local resources and informs 735 policy server. The LMA then responds with a PBA. 737 3.6. Service Guarantees in 802.11 739 The GBR - Guaranteed Bit Rate in mobile networks are used to request 740 and commit resources in the network for providing the bandwidth 741 requested. In 802.11 networks, a random backoff timer based on the 742 access class only provides priority access to a shared medium. These 743 mappings and recommendations allow the AP to schedule resources in a 744 fair manner based on subscribed QoS and application request/policy 745 server interaction. 747 However, there are no guaranteed or committed resources in the 802.11 748 network - only prioritization that gives better opportunity for 749 frames to compete for a shared medium. 751 It should also be noted that unlike mobile networks which inform the 752 MN about QoS for established or modified connections (bearers), there 753 is no means for an MN in 802.11 networks to find out the QoS that a 754 policy server requests to be granted. Thus, the application in MN 755 should make its determination to downgrade a request based on SDP and 756 media parameters to downgrade to a lower quality. 758 4. Mapping of QoS Parameters 760 This section outlines the handling of QoS parameters between 802.11 761 and PMIP QoS. 802.11 QoS reservations are made for an MN's data 762 frames. PMIP QoS provisioning on the other hand is for IP sessions 763 and flows. Parameters in PMIP QoS and 802.11 also need to be mapped 764 according to the recommendations below. 766 4.1 Connection Mapping 768 TSPEC in 802.11 is used to reserve QoS for a traffic stream (MN MAC, 769 TS(Traffic Stream) id). The QoS reservation is for 802.11 frames 770 associated with an MN's MAC address. TCLAS element with Classifier 1 771 (TCP/UDP Parameters) should be used to identify a flow. The flow 772 definition should use the specification in [PMIP-QoS] Traffic 773 Selector. Thus, there is a one-to-one mapping between the TCLAS 774 defined flow and that in Traffic Selector. 776 When an 802.11 QoS reservation is complete, it is identified by a 777 Traffic Stream (TS) identifier. This corresponds to the flow in 778 PMIPv6 Traffic Selector, and identified in TCLAS. For releasing QoS 779 resources identified by a PMIPv6 Traffic selector, the AP/WLC uses 780 the above relationship to determine the corresponding TS identifier 781 to be sent in the DELTS request. 783 If the MN or AP/WLC is not able to convey TCLAS, the AP/WLC should 784 use out of band methods to determine the IP flow for which QoS is 785 requested. This includes correlation with connection signaling 786 protocols (e.g. 3GPP 23.402 WCS) and Traffic Selector in most recent 787 PMIP QoS updates. 789 4.2. QoS Class 791 Table 1 contains a mapping between Access Class (WMM AC) and 802.1D 792 in 802.11 frames, and DSCP in IP data packets. The table also 793 provides the mapping between Access Class (WMM AC) and DSCP for use 794 in 802.11 TSPEC and PMIP QoS reservations. 796 QCI DSCP 802.1D UP WMM AC Example Services 797 ------------------------------------------------------------ 798 1 EF 6(VO) 3 AC_VO conversational voice 799 2 EF 6(VO) 3 AC_VO conversational video 800 3 EF 6(VO) 3 AC_VO real-time gaming 801 4 AF41 5(VI) 2 AC_VI buffered streaming 802 5 AF31 4(CL) 2 AC_VI signaling 803 6 AF32 4(CL) 2 AC_VI buffered streaming 804 7 AF21 3(EE) 0 AC_BE interactive gaming 805 8 AF11 1(BE) 0 AC_BE web access 806 9 BE 0(BK) 1 AC_BK e-mail 808 Table 2: QoS Mapping between QCI/DSCP, 802.1D UP, WMM AC 810 The MN tags data packets with DSCP and 802.1D UP corresponding to the 811 application and the subscribed policy or authorization. The AP/WLC 812 polices sessions and flows based on these values and the QoS policy 813 for the MN. 815 For QoS reservations, TSPEC use WMM AC values and PMIP QoS uses 816 corresponding DSCP values in Traffic Selector. 802.11 QoS Access 817 Class AC_VO, AC_VI are used for QoS reservations. AC_BE, AC_BK should 818 not be used in reservations. 820 4.3. Bandwidth 822 There are bandwidth parameters that need to be mapped for admission 823 controlled flows and others for non-admission controlled flows. 825 Non-Admission Controlled Flows: 827 Flows and sessions that do not need QoS reservation have no need 828 for equivalent mapping for 802.11. These sessions and flows are 829 policed by the AP/WLC to ensure that QoS policy obtained initially 830 (during MN authorization) or dynamically over PMIP QoS is not 831 exceeded by the MN. 833 All connection sessions of the MN should not in total exceed Per- 834 MN-Agg-Max-DL-Bit-Rate and Per-MN-Agg-Max-UL-Bit-Rate in the 835 downlink and uplink directions respectively. The non-admission 836 controlled flows of a single connectivity session of an MN should 837 not exceed Per-Session-Agg-Max-DL-Bit-Rate and Per-Session-Agg- 838 Max-UL-Bit-Rate in the downlink and uplink directions 839 respectively. 841 Admission Controlled Flows: 843 For flows that require reservation, the 802.11 Minimum Data Rate 844 should be equal to Guaranteed Bit Rate (GBR). If the MN requests 845 Minimum Data Rate in ADDTS greater than GBR, then AP/WLC should 846 reject the admission request in ADDTS Response. 848 +-------------------------+------------------------------+ 849 | MN <--> AP/WLC(802.11) | AP/WLC(MAG) <--> LMA PMIPv6 | 850 +-------------------------+------------------------------+ 851 | Minimum Data Rate, DL | Guaranteed-DL-Bit-Rate | 852 | Minimum Data Rate, UL | Guaranteed-UL-Bit-Rate | 853 | Mean Data Rate UL/DL | [a] | 854 | Peak Data Rate, DL | Aggregate-Max-DL-Bit-Rate | 855 | Peak Data Rate, UL | Aggregate-Max-UL-Bit-Rate | 856 +-------------------------+------------------------------+ 858 NOTE[a] AP/WLC may derive Mean Data Rate from Minimum and Maximum 859 Data Rates. There is no equivalent parameter in PMIP QoS. 861 Table 3: Bandwidth Parameters for Admission Controlled Flows 863 During the QoS reservation procedure, if the MN requests Minimum 864 Data Rate, or other parameters in excess of values authorized in 865 PMIP QoS, the AP/WLC should deny the request in ADDTS Response. 866 Bandwidth of admission controlled flows are policed according to 867 the mappings in Table 2. 869 4.4. Preemption Priority 871 Mobile networks with resource reservation configure ARP (Allocation 872 Retention Priority) during authorization and it is obtained in [PMIP 873 QoS]. There is no corresponding configuration in 802.11 QoS. However, 874 the AP/WLC may use ARP to determine priority during call setup and 875 vulnerability to release of reserved QoS resources. 877 Parameter Allocation-Retention-Priority and sub fields of Priority, 878 Preemption-Capability and Preemption-Vulnerability are used as 879 defined in [PMIP-QoS]. 881 When a new ADDTS request for reservation of QoS resources arrives, if 882 there is sufficient free resources, the AP/WLC proceeds to allocate 883 it. If there are insufficient resources, the AP/WLC may preempt 884 existing calls based on the Preemption-Capability of the new call and 885 Preemption-Vulnerability of established calls. 887 If the AP/WLC determines that an established flow with reserved 888 resources should be released, the AP/WLC should inform the MN using 889 ADDTS (802.11aa) and signal the LMA with a revised QoS reservation in 890 PBU/PBA. 892 5. Security Considerations 893 This document describes mapping of 3GPP QoS profile and parameters to 894 IEEE 802.11 QoS parameters. No security concerns are expected as a 895 result of using this mapping. 897 6. IANA Considerations 899 No IANA assignment of parameters are required in this document. 901 7. References 903 7.1. Normative References 905 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 906 Requirement Levels", BCP 14, RFC 2119, March 1997. 908 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, 909 April 1 1995. 911 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, 912 April 1 1996. 914 7.2. Informative References 916 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 917 RFC 3514, April 1 2003. 919 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 920 Acronyms", RFC 5513, April 1 2009. 922 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1 923 2009. 925 [PMIP-QoS] Liebsch, et al., "Quality of Service Option for Proxy 926 Mobile IPv6", draft-ietf-netext-pmip6-qos-11, Feb 2014. 928 [WMM 1.2.0] Wi-Fi Multimedia Technical Specification (with WMM-Power 929 Save and WMM-Admission Control) Version 1.2.0 931 [802.11aa] Wireless LAN Medium Access Control (MAC) and Physical 932 Layer (PHY) Specification, Amendment 2: MAC Enhancements 933 for Robust Audio Video Streaming, IEEE 802.11aa-2012. 935 [802.11-2012] 802.11-2012 - IEEE Standard for Information technology- 936 -Telecommunications and information exchange between 937 systems Local and metropolitan area networks--Specific 938 requirements Part 11: Wireless LAN Medium Access Control 939 (MAC) and Physical Layer (PHY) Specifications 941 [GSMA-IR34]Inter-Service Provider Backbone Guidelines 5.0, 22 942 December 2010 944 [RFC 2211] Wroclawski, J., "Specification of the Controlled Load 945 Quality of Service", RFC 2211, September 1997. 947 [RFC 2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 948 of Guaranteed Quality of Service", RFC 2212, September 949 1997. 951 [RFC 2216] Shenker, S., and J. Wroclawski, "Network Element QoS 952 Control Service Specification Template", RFC 2216, 953 September 1997. 955 [TS23.107] Quality of Service (QoS) Concept and Architecture, Release 956 10, 3GPP TS 23.107, V10.2.0 (2011-12). 958 [TS23.207] End-to-End Quality of Service (QoS) Concept and 959 Architecture, Release 10, 3GPP TS 23.207, V10.0.0 (2011- 960 03). 962 [TS23.402] Architecture Enhancements for non-3GPP accesses(Release 963 12), 3GPP TS 23.402, V12.2.0 (2013-09). 965 [TS23.203] Policy and Charging Control Architecture, Release 11, 3GPP 966 TS 23.203, V11.2.0 (2011-06). 968 [TS29.212] Policy and Charging Control over Gx/Sd Reference Point, 969 Release 11, 3GPP TS 29.212, V11.1.0 (2011-06). 971 [TS29.273] 3GPP EPS AAA interfaces(Release 12), 3GPP TS 29.273 972 v12.1.0 (2013-09) 974 Authors' Addresses 976 John Kaippallimalil 977 5340 Legacy Drive, Suite 175 978 Plano, Texas 75024 980 E-Mail: john.kaippallimalil@huawei.com 981 Rajesh Pazhyannur 982 170 West Tasman Drive 983 San Jose, CA 95134 985 E-Mail: rpazhyan@cisco.com 987 Parviz Yegani 988 1194 North Mathilda Ave. 989 Sunnyvale, CA 94089-1206 991 E-Mail: pyegani@juniper.net 993 Appendix A: QoS in 802.11, PMIPv6 and 3GPP Networks 995 A.1. QoS in IEEE 802.11 Networks 997 IEEE 802.11-2012 [802.11-2012] provides an enhancement of the MAC 998 layer in 802.11 networks to support QoS--EDCA (Enhanced Distributed 999 Channel Access). EDCA uses a contention based channel access method 1000 to provide differentiated, distributed access using eight different 1001 UPs (User Priorities). EDCA also defines four access categories (AC) 1002 that provide support for the delivery of traffic. In EDCA, the random 1003 back-off timer and arbitration inter-frame space is adjusted 1004 according to the QoS priority. Frames with higher priority AC have 1005 shorter random back-off timers and arbitration inter-frame spaces. 1006 Thus, there is a better chance for higher priority frames to be 1007 transmitted. The Wi-Fi Alliance has created a specification referred 1008 to as WMM (Wi-Fi Multimedia) based on above. 1010 The MN uses ADDTS (Add Traffic Specs) to setup QoS for a traffic 1011 stream between itself and the AP, and DELTS to delete that stream. In 1012 WMM [WMM 1.2.0], the AP advertises if admission control is mandatory 1013 for an access class. Admission control for best effort or background 1014 access classes is not recommended. The Wi-Fi Alliance has created a 1015 specification referred to as WMM-AC (Wi-Fi Multimedia Admission 1016 Control) based on the above. 1018 A.2. QoS in PMIPv6 Mobility domain 1020 [PMIP-QoS] defines a mobility option that can be used by the mobility 1021 entities in the Proxy Mobile IPv6 domain to exchange Quality of 1022 Service parameters associated with an MN's IP flows. Using the QoS 1023 option, the local mobility anchor and the mobile access gateway can 1024 exchange available QoS attributes and associated values. QoS 1025 attributes include node and mobile session Aggregate Maximum Bit Rate 1026 (AMBR) for upstream and downstream, Guaranteed Bit Rate (GBR) for 1027 upstream and downstream, Maximum Bit Rate (MBR) for upstream and 1028 downstream and the Allocation Retention Priority (ARP). 1030 [PMIP-QoS] does not explicitly describe how the QoS signaling and QoS 1031 sub-options map into corresponding signaling and parameters in the 1032 802.11 access network. This mapping and the procedures in the 802.11 1033 network to setup procedures are the focus of this document. The end- 1034 to-end flow spanning 802.11 access and PMIPv6 domain and the QoS 1035 parameters in both segments are described in subsequent sections. 1037 A.3. QoS in 3GPP Networks 1039 3GPP has standardized QoS for EPC (Enhanced Packet Core) from Release 1040 8 [TS 23.107]. 3GPP QoS policy configuration defines access agnostic 1041 QoS parameters that can be used to provide service differentiation in 1042 multi vendor and operator deployments. The concept of a bearer is 1043 used as the basic construct for which the same QoS treatment is 1044 applied for uplink and downlink packet flows between the MN (host) 1045 and gateway [TS23.402]. A bearer may have more than one packet filter 1046 associated and this is called a Traffic Flow Template (TFT). The IP 1047 five tuple (IP source address, port, IP destination, port, protocol) 1048 identifies a flow. 1050 The access agnostic QoS parameters associated with each bearer are 1051 QCI (QoS Class Identifier), ARP (Allocation and Retention Priority), 1052 MBR (Maximum Bit Rate) and optionally GBR (Guaranteed Bit Rate). QCI 1053 is a scalar that defines packet forwarding criteria in the network. 1054 Mapping of QCI values to DSCP is well understood and GSMA has defined 1055 standard means of mapping between these scalars [GSMA-IR34]. 1057 The use cases in subsequent sections use 3GPP policy along with PMIP 1058 QoS for provisioning of QoS in the 802.11 network. However, this is 1059 exemplary and alternative policy architectures may be used in 1060 practice.