Mapping Quality of Service (QoS) Procedures
of Proxy Mobile IPv6 (PMIPv6) and WLAN
Huawei5340 Legacy Dr., Suite 175PlanoTX75024United Statesjohn.kaippallimalil@huawei.comCisco170 West Tasman DriveSan JoseCA95134United Statesrpazhyan@cisco.comJuniper1194 North Mathilda Ave.SunnyvaleCA94089-1206United Statespyegani@juniper.net
Internet
PMIPv6Wi-FiQoS
This document provides guidelines for achieving end-to-end
Quality of Service (QoS) in a Proxy Mobile IPv6 (PMIPv6) domain
where the access network is based on IEEE 802.11. RFC 7222
describes QoS negotiation between a Mobile Access Gateway (MAG)
and Local Mobility Anchor (LMA) in a PMIPv6 mobility domain.
The negotiated QoS parameters can be used for QoS policing and
marking of packets to enforce QoS differentiation on the path
between the MAG and LMA.
IEEE 802.11 and Wi-Fi Multimedia - Admission Control (WMM-AC)
describe methods for QoS negotiation between a Wi-Fi Station (MN in
PMIPv6 terminology) and an Access Point. This document
provides a mapping between the above two sets of QoS procedures
and the associated QoS parameters. This document is intended
to be used as a companion document to RFC 7222 to enable
implementation of end-to-end QoS.
PMIPv6 QoS describes an access-network-independent
way to negotiate Quality of Service (QoS) for Proxy Mobile IPv6
(PMIPv6) mobility sessions. IEEE 802.11, Wi-Fi Multimedia (WMM), and
Wi-Fi Multimedia - Admission Control (WMM-AC) describe ways to
provide QoS for Wi-Fi traffic between the Wi-Fi Station (STA) and
Access Point (AP). This document describes how QoS can be implemented
in a network where the access network is based on IEEE 802.11 (Wi-Fi).
It requires a mapping between QoS procedures and information
elements in two segments: 1) the Wi-Fi segment and 2) the PMIPv6 segment.
(See .) The recommendations here allow for dynamic QoS
policy information per Mobile Node (MN) and session to be configured
by the IEEE 802.11 access network. PMIPv6 QoS signaling between the
Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA)
provisions the per-MN QoS policies in the MAG. Further details
on policy configuration and the Policy Control Function (PCF) can be
found in , Section 6.1.
In the IEEE 802.11 access network modeled here, the MAG is located
at the AP / Wireless LAN Controller (WLC).
below provides an overview of the
entities and protocols.
The MN and Access Point (AP) use IEEE 802.11 QoS mechanisms to set up QoS
flows in the Wi-Fi segment. The MAG and LMA set up QoS flows using PMIPv6
QoS procedures. The protocols and mechanisms between the AP and MAG are outside
the scope of this document. Some implementations may have the AP and MAG in
the same network node. However, this document does not exclude various
deployments including those in which the AP and WLC are separate nodes or in which the
MAG control and data planes are separate.
The recommendations in this document use IEEE 802.11 QoS and PMIPv6
QoS mechanisms . State machines for QoS policy
setup in IEEE 802.11 and PMIPv6 operate differently. Guidelines for
installing QoS in the MN using IEEE 802.11 and PMIPv6 segments and for mapping
parameters between them are outlined below.
PMIPv6-defined procedures for QoS setup, as specified in , may be triggered
by the LMA or MAG. IEEE 802.11 QoS setup, on the other hand, is always
triggered by the MN (IEEE 802.11 QoS Station (QSTA)). The end-to-end QoS setup
across these network segments should accommodate QoS that is triggered
by the network or by the end user.
There is no systematic method of mapping of specific parameters
between PMIPv6 QoS parameters and IEEE 802.11 QoS.
For example,
parameters like Allocation and Retention Priority (AARP) in PMIPv6 QoS
have no equivalent in IEEE 802.11.
The primary emphasis of this specification is to handle the
interworking between WMM-AC signaling/procedures and PMIPv6 QoS
signaling/procedures. When the client does not support WMM-AC, then
the AP/MAG uses the connection mapping in and
DSCP-to-AC mapping as shown in .
The rest of the document is organized as follows.
provides an overview of IEEE 802.11 QoS.
describes a mapping of QoS signaling procedures
between IEEE 802.11 and PMIPv6.
The mapping of parameters between IEEE 802.11 and PMIPv6 QoS is
described in .
AAA Authentication, Authorization, and AccountingAARP Allocation and Retention PriorityAC Access CategoryADDTS ADD Traffic StreamAIFS Arbitration Inter-Frame SpaceALG Application Layer GatewayAMBR Aggregate Maximum Bit RateAP Access PointCW Contention WindowDELTS DELete Traffic StreamDL DownLinkDSCP Differentiated Services Code PointDPI Deep Packet InspectionEDCA Enhanced Distributed Channel AccessEPC Evolved Packet CoreGBR Guaranteed Bit RateMAC Media Access ControlMAG Mobile Access GatewayMBR Maximum Bit RateMN Mobile NodeMSDU Media Access Control Service Data UnitPBA Proxy Binding AcknowledgementPBU Proxy Binding UpdatePCF Policy Control FunctionPHY Physical LayerQCI QoS Class IdentifierQoS Quality of ServiceQSTA QoS StationSIP Session Initiation ProtocolSTA StationTC Traffic ClassTCLAS Type ClassificationTCP Transmission Control ProtocolTS Traffic StreamTSPEC Traffic Conditioning SpecificationUDP User Datagram ProtocolUL UpLinkUP User PriorityWLAN Wireless Local Area NetworkWLC Wireless ControllerWMM Wi-Fi MultiMediaWMM-ACWi-Fi MultiMedia Admission Control
In WMM-AC, Peak Data Rate specifies the maximum data rate in bits per
second. The Maximum Data Rate does not include the MAC and PHY
overheads .
Data rate includes the transport of the IP packet and header.
TSPECs for both uplink and downlink may contain Peak Data Rate.
This is the average data rate in bits per second. The Mean Data Rate
does not include the MAC and PHY overheads .
Data rate includes the transport of the IP packet and header.
TSPECs for both uplink and downlink must contain the Mean Data Rate.
In WMM-AC, Minimum Data Rate specifies the minimum data rate in bits
per second. The Minimum Data Rate does not include the MAC and
PHY overheads .
Data rate includes the transport of the IP packet and header.
Minimum Data Rate is not used in QoS provisioning as it is described here.
The QoS Class Identifier (QCI) is a scalar parameter that points to
standardized characteristics of QoS as opposed to signaling separate
parameters for resource type, priority, delay, and loss
.
A station (STA) is a device that has the capability to use the
IEEE 802.11 protocol. For example, a station maybe a laptop, a desktop PC,
an access point, or a Wi-Fi phone .
An STA that implements the QoS facility is a QoS Station (QSTA)
.
The TSPEC element in IEEE 802.11 contains the set of parameters that
define the characteristics and QoS expectations of a traffic flow
.
The TCLAS element specifies an element that contains a set of
parameters necessary to identify incoming MSDUs (MAC Service Data Units)
that belong to a particular TS (Traffic Stream)
.
IEEE 802.11 defines a way of
providing prioritized access for different traffic classes (video, voice,
etc.) by a mechanism called EDCA (Enhanced Distributed Channel Access).
The levels of priority in EDCA are called access categories (ACs) and
there are four levels (in decreasing order of priority): Voice, Video,
Best-Effort, and Background.
Prioritized access is achieved by using AC-specific
values for Contention Window (CW) and Arbitration Inter-Frame Space (AIFS).
(Higher-priority categories have smaller values for minimum and maximum
CW and AIFS.)
A subset of the QoS mechanisms is defined in WMM -- a Wi-Fi Alliance
certification of support for a set of features from an IEEE 802.11e draft
(now part of IEEE 802.11). This certification is for both clients and
APs and certifies the operation of WMM. WMM is primarily the
implementation of the EDCA component of IEEE 802.11e. WMM uses the IEEE 802.1P
classification scheme developed by the IEEE (which is now a part of the
802.1D specification). The IEEE 802.1P classification scheme has eight
priorities, which WMM maps to four access categories: AC_BK, AC_BE, AC_VI,
and AC_VO. The lack of support in WMM for the TCLAS (used in identifying
an IP flow) has an impact on the QoS provisioning. The impact on WMM-based
QoS provisioning is described
in Sections and .
IEEE 802.11 defines the way a (non-AP) STA can request QoS to be
reserved for an access category. Correspondingly, the AP can determine
whether to admit or deny the request depending on the available resources.
Further, the AP may require that Admission Control is mandatory for an
access category. In such a case, the STA is expected to use the access category only
after being successfully admitted. WMM-AC is a Wi-Fi Alliance certification
of support for Admission Control based on a set of features in IEEE 802.11.
The QoS signaling in IEEE 802.11 is initiated by the (non-AP)
STA (by sending an ADDTS request). This specification references procedures
in IEEE 802.11, WMM, and WMM-AC.
There are two main types of interaction possible to provision QoS
for flows that require Admission Control -- one where the MN initiates
the QoS request and the network provisions the resources. The second is
where the network provisions resources as a result of a PMIPv6 QoS request.
In the second scenario, the LMA can push the QoS configuration to the MAG.
However, there is no standard way for the AP to initiate a
QoS service request to the MN. Recommendations to set up QoS in both these
cases are described in this section.
This procedure outlines the case where the MN is configured to start
the QoS signaling. In this case, the MN sends an ADDTS request indicating
the QoS required for the flow.
The AP/MAG obtains the corresponding level
of QoS to be granted to the flow by using the PMIPv6 PBU/PBA sequence
that contains the QoS options exchanged with the LMA.
Details of the QoS provisioning for the
flow are provided below.
In the use case shown in ,
the MN initiates the QoS service request.
The MN establishes a session as
described in steps 1-4 of Use Case 2 (MAG-Initiated QoS Service
Request) in Section 3.1 of
. At this point, a connection with a PMIPv6 tunnel is
established to the LMA. This allows the MN to start application-level signaling.
The trigger for the MN to request QoS is an upper-layer
notification.
This may be the result of end-to-end application signaling and setup
procedures (e.g., SIP ).
Since the MN is configured to start QoS signaling, it sends an ADDTS
request with TSPEC and TCLAS identifying the flow for which QoS is
requested.
It should be noted that WMM-AC specifications do not contain TCLAS.
When TCLAS is not present, there is no direct way to derive flow-specific attributes like Traffic Selector in PMIPv6.
In this case, functionality to derive IP flow details from information
in upper-layer protocols (e.g., SIP ) and
associate them with a subsequent QoS request may be used.
This is not described further here, but it
may be functionality in an Application Layer Gateway (ALG) or
Deep Packet Inspection (DPI).
It should be noted that an ALG or DPI can increase the complexity of
the AP/MAG implementation and affect its scalability.
If no TCLAS is derived, the reservation applies to all flows of the
MN. Parameter mapping in this case is shown in
.
If there are sufficient resources at the AP/WLC to
satisfy the request, the MAG sends a PBU with QoS options, Operational
Code ALLOCATE, and the Traffic Selector identifying the flow.
The Traffic Selector is derived from the TCLAS to identify the
flow requesting QoS. IEEE 802.11 QoS parameters in TSPEC are mapped
to PMIPv6 parameters. The mapping of TCLAS to PMIPv6 is shown in .
TSPEC parameter mapping is shown in .
If TCLAS is not present (when WMM-AC is used), TCLAS may be derived from
information in upper-layer protocols (as described in step 1)
and populated in the Traffic Selector. If TCLAS cannot be derived, the
Traffic Selector field is not included in the QoS options.
The LMA obtains the authorized QoS for the flow
and responds to the MAG with Operational Code set to RESPONSE.
Mapping of PMIPv6 to IEEE 802.11 TCLAS is shown in
, and mapping of TSPEC parameters is shown in .
Reserved bandwidth for flows is calculated separately from the
non-reserved session bandwidth.
The Traffic Selector identifies the flow for which the QoS
reservations are made.
If the LMA offers downgraded QoS values to the MAG, it should send a
PBU to the LMA with Operational Code set to DE-ALLOCATE. (The LMA would
respond with PBA to confirm completion of the request.)
The AP/MAG provisions the corresponding QoS and
replies with ADDTS Response containing authorized QoS in TSPEC, the
flow identification in TSPEC, and ResultCode set to SUCCESS.
The AP polices these flows according to the QoS provisioning.
In step 3, if the LMA sends a downgraded QoS or a PBA message with
status code CANNOT_MEET_QOS_SERVICE_REQUEST (179), then the AP should
respond to the MN with ADDTS Response and ResultCode set as follows:
for downgraded QoS from LMA, ResultCode is set to
REJECTED_WITH_SUGGESTED_CHANGES. Downgraded QoS values from LMA are
mapped to TSPEC as per .
This is still a rejection, but the MN may revise the QoS to a lower
level and repeat this sequence if the application can adapt.
if LMA cannot meet the QoS service request,
ResultCode is set to TCLAS_RESOURCES_EXHAUSTED.
Either REJECTED_WITH_SUGGESTED_CHANGES or TCLAS_RESOURCES_EXHAUSTED results
in the rejection of the QoS reservation, but it does not cause the removal
of the session itself.
QoS resources reserved for a session are released on completion of
the session. When the application session completes, the LMA or the MN
may signal for the release of resources. In the use case shown in
, the MN initiates the release of QoS resources.
The MN establishes and reserves QoS resources.
When the application session terminates, the MN prepares to release
QoS resources.
The MN releases its own internal resources and sends a
DELTS Request to the AP with TS (Traffic Stream) INFO.
The AP receives the DELTS request, releases local
resources, and responds to the MN with a DELTS response.
The MAG initiates a PBU, with the Operational Code set to
DE-ALLOCATE, and with the Traffic Selector constructed from TCLAS and
PMIPv6 QoS parameters from TSPEC.
When TCLAS is not present, the MAG should de-allocate all flows with
the same access category as indicated in the DELTS Request.
In the typical case, if the client does not support TCLAS and only
MN-initiated QoS Service requests are supported, then the MAG will
have at most one QoS Service request per access category.
LMA receives the PBU and releases local resources.
The LMA then responds with a PBA.
It should be noted that steps 3 and 4 can proceed independently of
the DELTS Response (step 2).
This section describes the case when the QoS service request is
initiated by the LMA. For example, an application such as voice may
request the network to initiate configuration of additional QoS policy
as in , Section 7.4.2. In the current WLAN
specifications, there is no standard-defined way for the AP to initiate
a QoS service request to the MN. As a result, when the MAG receives a
QoS request from the LMA, it does not have any standard mechanisms to
initiate any QoS requests to the MN over the access network.
Given this, the PMIPv6 QoS service requests and any potential WLAN
service requests (such as described in )
are handled asynchronously.
The PMIPv6 QoS service requests and WLAN QoS service request could
still be coordinated to provide an end-to-end QoS.
If the MAG receives an Update Notification (UPN) request from the LMA to reserve QoS resources
for which it has no corresponding QoS request from the MN, the MAG may, in
consultation with the AP, provision a policy that can grant a subsequent
QoS request from the MN.
If the MN initiates QoS procedures after the completion of PMIPv6 QoS
procedures, the AP/MAG can ensure consistency between the QoS resources
in the access network and QoS resources between the MAG and LMA.
For example, if the MN is requesting a mean data rate of x Mbps,
the AP and MAG can ensure that the rate can be supported on the network
between MAG and LMA based on previous PMIPv6 QoS procedures.
If the MN subsequently requests data rates of x Mbps or less,
the AP can accept a request based on the earlier PMIPv6 QoS provisioning.
For the case where there is a mismatch, i.e., the network does not
support the x Mbps, then either the MAG should renegotiate the QoS
resource and ask for increased QoS resources or the AP should reject
the QoS request.
The network-initiated QoS service request scenario poses some
challenges outlined here. IEEE 802.11 does not provide any mechanisms
for the AP to initiate a QoS request.
As a result, the AP/MAG cannot explicitly make any reservations in
response to a QoS reservation request made using UPN. IEEE 802.11aa
(which is an amendment to IEEE 802.11)
has a mechanism that enables the AP to ask the client to reserve QoS
for a traffic stream.
It does this via the ADDTS Reserve Request. The ADDTS Reserve Request
contains a TSPEC, an optional TCLAS, and a mandatory stream identifier.
The specification does not describe how the AP would obtain such a stream
identifier. As a result, there needs to be a new higher-layer protocol
defined that is understood by the MN and AP and that provides a common stream
identifier to both ends. Alternately, the IEEE 802.11aa specification could
be modified to make the usage optional.
When (or if) the stream identifier is made optional, the TCLAS can provide
information about the traffic stream.
outlines a protocol sequence with PMIPv6
UPN / Update Notification Acknowledgement (UPA) if the
above IEEE 802.11aa issues can be resolved.
QoS resources reserved for a session are released on completion of
the session. When the application session completes, the LMA or the
MN may signal for the release of resources. In this use case, the
network initiates the release of QoS resources.
In the use case shown in , the network
initiates the release of QoS resources.
When the application session terminates, the LMA receives notification
of that event. The LMA releases local QoS resources
associated with the flow and initiates signaling to release QoS resources
in the network.
The LMA sends a UPN with QoS options identifying
the flow for which QoS resources are to be released and Operational
Code set to DE&nbhy;ALLOCATE. No additional LMA QoS parameters are sent.
The MAG replies with a UPA confirming the acceptance
and Operational Code set to RESPONSE.
The AP/WLC (MAG) releases local QoS resources associated
with the flow. The AP derives the corresponding access category from
the Traffic Class (TC) field provided in the QoS option.
In addition, if the AP supports TCLAS and the QoS option contains a
Traffic Selector field, then the AP shall map the Traffic Selector
into a TCLAS element. In the case where the AP does not support TCLAS
(for example, an AP compliant with WMM-AC), then the AP shall only use the
access category. The AP sends a DELTS Request with TS INFO
identifying the reservation.
The MN sends DELTS Response confirming release.
It should be noted that steps 3 and 4 can proceed independently
of the UPA (step 2).
TSPEC in IEEE 802.11 is used to reserve QoS for a traffic stream
(MN MAC, TS ID). The IEEE 802.11 QoS reservation is for
IEEE 802.11 frames associated with an MN's MAC address.
The TCLAS element with Classifier 1 (TCP/UDP Parameters) is used to
identify a PMIPv6 QoS flow. We should note that WMM-AC procedures do
not support TCLAS.
When TCLAS is present, a one-to-one mapping between the TCLAS-defined
flow and the Traffic Selector is given below.
QoS reservations in IEEE 802.11 are made for a traffic stream
(identified in TCLAS) and correspond to PMIPv6 QoS session parameters
(identified by the Traffic Selector). PMIPv6 QoS
specifies that when QoS-Traffic-Selector is included along with the
per-session bandwidth attributes described in
below, the attributes apply at a per-session level.
MN <--> AP (IEEE 802.11)MAG <--> LMA (PMIPv6)(TCLAS Classifier 1)TCP/UDP IPTraffic Selector (IP flow)(TCLAS Classifier 1) DSCPTraffic Class (TC)If the MN or AP is not able to convey flow parameters in TCLAS,
the QoS reservation request in IEEE 802.11 is derived as shown in
.
MN <--> AP (WMM)MAG <--> LMA (PMIPv6)(no IP flow parameter/TCLAS)(a) applies to all flows(b) derived out-of-band User Priority (802.1D) Traffic Class (TC)(derived using )When WMM is used, and TCLAS is not present
to specify IP flow, one of two options apply for the MAG - LMA (PMIPv6)
segment:
Bandwidth parameters described in
apply to all flows of the MN.
This is not a preferred mode of operation if the LMA performs
reservation for a single flow, e.g., a voice flow identified by an
IP 5-tuple.
The IP flow for which the MN requests reservation
is derived out-of-band. For example, the AP/MAG observes application-level signaling (e.g., SIP ) or session-level
signaling (e.g., 3GPP WLCP (WLAN Control Protocol)
), associates
subsequent ADDTS requests using heuristics, and then derives the
IP flow / Traffic Selector field.
contains a mapping between access category
(AC) and IEEE 802.1D User Priority (UP) tag in IEEE 802.11 frames,
and DSCP in IP data packets.
The table also provides the mapping between AC and
DSCP for use in IEEE 802.11 TSPEC and PMIPv6 QoS (Traffic Class).
Mapping of QCI to DSCP uses the tables in .
QCIDSCP802.1D UPACExample Services1EF 6(VO)3 AC_VOconversational voice2EF 6(VO)3 AC_VOconversational video3EF 6(VO)3 AC_VOreal-time gaming4AF415(VI)2 AC_VIbuffered streaming5AF314(CL)2 AC_VIsignaling6AF324(CL)2 AC_VIbuffered streaming7AF213(EE)0 AC_BEinteractive gaming8AF111(BE)0 AC_BEweb access9BE 0(BK)1 AC_BKemailThe MN tags all data packets with DSCP and IEEE 802.1D UP corresponding
to the application and the subscribed policy or authorization.
The AP polices sessions and flows based on the configured QoS policy
values for the MN.
For QoS reservations, TSPEC uses WMM-AC values and PMIPv6 QoS uses
corresponding DSCP values in Traffic Class (TC).
IEEE 802.11 QoS Access Category AC_VO and AC_VI are used for QoS reservations.
AC_BE and AC_BK should not be used in reservations.
When WMM-AC specifications that do not contain TCLAS are used,
it is only possible to have one reservation per Traffic Class /
access category. PMIPv6 QoS will not contain any flow-specific
attributes like Traffic Selector.
Bandwidth parameters that need to be mapped between IEEE 802.11 and
PMIPv6 QoS are shown in .
MN <--> AP(IEEE 802.11)MAG <--> LMA (PMIPv6)Mean Data Rate, DLGuaranteed-DL-Bit-RateMean Data Rate, ULGuaranteed-UL-Bit-RatePeak Data Rate, DLAggregate-Max-DL-Bit-RatePeak Data Rate, ULAggregate-Max-UL-Bit-RateIn PMIPv6 QoS , services using a sending rate
smaller than or equal to the Guaranteed Bit Rate (GBR) can assume, in general,
that congestion-related packet drops will not occur
.
If the rate offered by the service exceeds this threshold, there are
no guarantees provided.
IEEE 802.11 radio networks do not offer such a guarantee, but
notes that the application (service)
requirements are captured in TSPEC by the MSDU (MAC Service Data Unit)
and Mean Data Rate. The TSPEC should contain Mean Data Rate, and it is
recommended that it be mapped to the GBR parameters,
Guaranteed-DL-Bit-Rate and Guaranteed-UL-Bit-Rate in PMIPv6 QoS
.
IEEE 802.11 TSPEC requests do not require all fields to be completed.
specifies a list of TSPEC parameters that are
required in the specification.
Peak Data Rate is not required in WMM; however, for MNs and APs that are
capable of specifying the Peak Data Rate, it should be mapped to
MBR (Maximum Bit Rate) in PMIPv6 QoS.
The AP should use the MBR parameters Aggregate-Max-DL-Bit-Rate and
Aggregate-Max-UL-Bit-Rate to police these flows on the backhaul segment
between MAG and LMA.
During the QoS reservation procedure, if the MN requests Mean Data Rate,
or Peak Data Rate in excess of values authorized in PMIPv6 QoS,
the AP should deny the request in an ADDTS response.
The AP may set the reject cause code to REJECTED_WITH_SUGGESTED_CHANGES
and send a revised TSPEC with Mean Data Rate and Peak Data Rate set to
acceptable GBR and MBR, respectively, in PMIPv6 QoS.
This document describes mapping of PMIPv6 QoS parameters to
IEEE 802.11 QoS parameters.
Thus, the security in the WLAN and PMIPv6 signaling segments and the
functional entities that map the two protocols need to be considered.
IEEE 802.11 provides the means to secure
management frames that are used for ADDTS and DELTS.
The PMIPv6 specification recommends using IPsec
and IKEv2 to secure protocol messages.
The security of the node(s) that implement the QoS mapping functionality
should be considered in actual deployments.
The QoS mappings themselves do not introduce additional security
concerns.
IEEE Standard for Information Technology -
Telecommunications and information exchange between systems - Local
and metropolitan area networks - Specific requirements Part 11:
Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications
IEEEWi-Fi Multimedia Technical Specification
(with WMM-Power Save and WMM-Admission Control)
Wi-Fi AllianceWireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) Specification, Amendment 2: MAC Enhancements for Robust Audio
Video Streaming
IEEEGuidelines for IPX Provider networks (Previously
Inter-Service Provider IP Backbone Guidelines)
3GPPTechnical Specification
Group Core Network and Services; Wireless LAN control plane
protocols for trusted WLAN access to EPC; Stage 3 (Release 12)
3GPPTechnical Specification
Group Services and System Aspects; Policy and Charging Control
Architecture (Release 13)
3GPPIn the use case shown in , the LMA initiates
the QoS service request and IEEE 802.11aa is used to set up the QoS reservation
in the Wi-Fi segment.
The MN sets up a best-effort session.
This allows the MN to perform application-level signaling and setup.
The policy server sends a QoS reservation request
to the LMA. This is usually sent in response to an application that
requests the policy server for higher QoS for some of its flows.
The LMA reserves resources for the flow requested.
The LMA sends a PMIPv6 UPN (Update Notification)
, as outlined in ,
to the MAG with Notification Reason set to QOS_SERVICE_REQUEST and
Acknowledgement Requested flag set to 1.
The Operational Code in the QoS option SHOULD be set to ALLOCATE, and the
Traffic Selector identifies the flow for QoS.
The LMA QoS parameters include
Guaranteed-DL-Bit-Rate/Guaranteed-UL-Bit-Rate and
Aggregate-Max-DL-Bit-Rate/Aggregate-Max-UL-Bit-Rate for the flow.
The reserved bandwidth for flows is calculated separately from the
non-reserved session bandwidth.
If there are sufficient resources to satisfy the
request, the AP/MAG sends an ADDTS Reserve Request (IEEE 802.11aa)
specifying the QoS reserved for the traffic stream, including the TSPEC and
TCLAS elements mapped from the PMIPv6 QoS Traffic Selector to identify the flow.
PMIPv6 parameters are mapped to TCLAS () and
TSPEC ().
If there are insufficient resources at the AP/WLC, the MAG will not
send an ADDTS message and will continue the processing of step 5.
The higher-level stream identifier in IEEE 802.11aa should be encoded as discussed
in .
MN accepts the QoS reserved in the network and
replies with ADDTS Reserve Response.
The MAG (AP/WLC) replies with a UPA confirming the
acceptance of QoS options and Operational Code set to RESPONSE.
The AP/WLC polices flows based on the new QoS.
If there are insufficient resources at the AP in step 3,
the MAG sends a response with UPA status code set to
CANNOT_MEET_QOS_SERVICE_REQUEST (130).
The authors thank the NETEXT Working Group for the valuable feedback
to different versions of this specification. In particular, the authors
wish to thank Sri Gundavelli, Georgios Karagianis, Rajeev Koodli,
Kent Leung, Marco Liebsch, Basavaraj Patil, Pierrick Seite, and
Hidetoshi Yokota for their suggestions and valuable input.
The authors also thank George Calcev, Mirko Schramm, Mazin Shalash, and
Marco Spini for detailed input on parameters and scheduling in
IEEE 802.11 and 3GPP radio networks.