Configure QOS Support and Enforcement for ASR 5x00 Packet Gateway

Introduction

This article gives a brief Overview on Quality of Service (QoS) support in Cisco Aggregated Service Router (ASR) 5x00 Packet Gateway (PGW). QOS enforcement support is one of the important capability that PGW needs to support in Evolved Packet Core (EPC) network. There are multiple aspects of QoS that needs to be supported in a PGW in order to spec compliant. An Evolved Packet System (EPS) bearer is the level of granularity for bearer level QoS control in the EPC and other Access types.

EPS Bearer QoS Profile

The EPS bearer QoS profile includes the parameters QCI, ARP, GBR and MBR. Each EPS bearer (GBR and Non-GBR) is associated with the following bearer level QoS parameters:

QoS Class Identifier (QCI): A QCI is a scalar that is used as a reference to access node-specific parameters that control bearer level packet forwarding treatment (e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.), and that have been pre-configured by the operator owning the access node (e.g. eNodeB). A one-to-one mapping of standardized QCI values to standardized characteristics is captured Technical Specification (TS) 23.203.

Allocation and Retention Priority (ARP): The ARP shall contain information about the priority level (scalar), the pre-emption capability (flag) and the pre-emption vulnerability (flag). The primary purpose of ARP is to decide whether a bearer establishment / modification request can be accepted or needs to be rejected due to resource limitations (typically available radio capacity for GBR bearers). ARP is also used at Policy and Charging Enforcement Function (PCEF)/ Policy and Charging Rule Function (PCRF) for Bearer-Binding along with QCI. Bearer-Binding is a process of binding the Policy and Charging control (PCC)-rules to a particular EPS bearer.

Guaranteed Bit Rate (GBR): Applicable to only GBR bearers. GBR denotes the bit rate that can be expected to be provided by a GBR bearer. It is expected that the Radio Access Network (RAN) and core would reserve the GBR for the bearer.

Maximum Bit Rate (MBR): Applicable to both GBR and Non-GBR bearers. The MBR limits the bit rate that can be expected to be provided by a bearer (e.g. excess traffic may get discarded by a rate shaping function). The MBR of a particular GBR bearer may be set larger than the GBR.

Each Access Point Name access, by a User Equipment, is associated with the following QoS parameter:

Per APN Aggregate Maximum Bit Rate (APN-AMBR): It limits the aggregate bit rate that can be expected to be provided across all Non GBR bearers of all Packet Data Network (PDN) connections of the same APN. The PGW enforces the APN AMBR in downlink. Enforcement of APN AMBR in uplink is done in the UE and additionally in the PGW.

Each UE is associated with the following bearer aggregate level QoS parameter:

Per UE Aggregate Maximum Bit Rate (UE-AMBR): The MME shall set the UE-AMBR to the sum of the APN-AMBR of all active APN’s up to the value of the subscribed UE-AMBR. The UE-AMBR limits the aggregate bit rate that can be expected to be provided across all Non-GBR bearers of a UE (e.g. excess traffic may get discarded by a rate shaping function). The 4G enforces the UE AMBR in uplink and downlink.

The GBR and MBR denote bit rates of traffic per bearer, while UE-AMBR/APN-AMBR denotes bit rates of traffic per group of bearers.  The GBR and MBR denote bit rates of traffic per bearer, while UE-AMBR/APN-AMBR denotes bit rates of traffic per group of bearers. Each of those QoS parameters has an uplink and a downlink component.

For GBR bearers, Bearer QOS Information Element(IE) (in Create/Update Bearer Request message) carries both bearer level GBR and MBR data rate (as per Technical Specification(TS) 23.401, sec 4.7.3), but Flow QOS IE in Bearer Resource Command (BRC) procedure can carry only GBR data rate (as per TS 23.401, sec 5.4.5). Each PCC-rule associated with GBR bearers will have a PCC-rule level GBR and MBR data rate of its own. Bearer level MBR and GBR data rates for an EPS bearer are derived by adding up corresponding MBR and GBR data rates of the PCC-rules associated with that EPS bearer.

For Non-GBR bearers, GBR data rate is not applicable, Bearer QOS IE always carries MBR data rate as zero (as per TS 23.401, sec 4.7.3), and even Flow QOS IE in BRC procedure have MBR data rate as zero (as per TS 23.401, sec 5.4.5). For Non-GBR bearers APN-AMBR data rate can be shared by multiple bearers, there is no separate per bearer MBR data rate as such. Each PCC-rule associated with Non-GBR bearers will have a PCC-rule level MBR data rate of its own.

Basic QoS Feature Support

• APN-AMBR data rate enforcement support.
• Default-Bearer QOS enforcement support.
• Service Data Flow(SDF) (PCC-rule) Level data rate enforcement support.
• Differentiated services code point(DSCP) marking support.
• Bearer Binding support.

APN-AMBR enforcement support

The APN AMBR is a subscription parameter stored per APN in the Home Subscriber Server(HSS). Mobility Management Entity(MME)/ Serving Gateway(SGW) provides APN-AMBR during default bearer establishment/GnGp handoff/HSS-Initiated QOS modification procedure. This APN-AMBR is then authorized with PCRF. PGW then finally enforces the PCRF authorized APN-AMBR data rate. APN-AMBR limits the aggregate bit rate that can be expected to be provided across all Non GBR bearers of all PDN connections of the same APN. Each of those Non GBR bearers could potentially utilize the entire APN AMBR, e.g. when the other Non GBR bearers do not carry any traffic. The PGW enforces the APN AMBR in downlink and uplink direction.

With Gx enabled, PGW honors PCRF authorized APN-AMBR values always. If an APN-AMBR value is not received in the Gx reauthorization with PCRF, then the last received APN-AMBR values from PCRF is enforced by PGW

In Cisco ASR5x00 PGW, APN-AMBR enforcement can be enabled on per-APN basis using “apn-ambr rate-limit” CLI in APN config mode on PGW.

Syntax

#configure 
# context context_name 
# apn apn_name 
Entering the above command sequence results in the following prompt:

[context_name]host_name(config-apn)# apn-ambr rate-limit direction { downlink | uplink } [ burst-size { auto-readjust duration seconds | bytes } | violate-action { drop | lower-ip-precedence | shape [ transmit-when-buffer-full ] | transmit } ][ default | no ] apn-ambr rate-limit direction { downlink | uplink }

Usage:

Use this command to enforce the AMBR for the APN on bearers that do not have a Guaranteed Bit Rate (GBR).

Example:

The following command sets the downlink burst rate to use an auto-readjust duration of 2 seconds and lowers the IP precedence of violating packets:

apn-ambr rate-limit direction downlink burst-size auto-readjust duration 2 violate-action lower-ip-precedence

Note: For more details on this CLI please refer to PGW config guide

Default-Bearer QOS enforcement support

Default-Bearer QOS represents the QOS that is applied to the traffic flowing over Default-Bearer in a PDN. Default-Bearer QOS info contains the QCI and the ARP. Default-Bearer being a non-GBR bearer there is no bearer-level Data rates associated with its bearer-level QOS. APN-AMBR is applicable to default bearer and is shared with other non-GBR bearers of that subscriber for that APN.

PGW enforces the Default-Bearer QOS that is authorized by PCRF or Local-Policy. If no Gx or Local-Policy is enabled, then the requested Default-Bearer QOS is enforced at PGW. The PGW support for enforcing Default-bearer is similar to the APN-AMBR enforcement support, with corresponding event-triggers for Default-Bearer QOS (DEFAULT-EPS-BEARER-QOS-CHANGE event-trigger or some other) over Gx or Local-Policy.

SDF (PCC-rule) Level enforcement support

Cisco ASR5x00 PGW supports PCEF functionality which is compliant with the 3^rd Generation Partnership Project (3GPP) based PCC framework based on 3GPP spec TS 23.203 & TS 29.212. As part of PCEF functionality support, PGW supports Policy and Charging Control at SDF or PCC-rule level and has support for Gx interface for interaction with PCRF server. PGW supports PCEF based Bearer-Binding of PCC rules for IPCAN session type 3GPP-EPS. Below is the PCC framework architect that Cisco ASR5x00 PGW is compliant with:

For Dynamic PCC rules installed by PCRF, per SDF level policing at the PGW is applied based on the PCC rule level QOS data rates. Traffic hitting this Dynamic PCC rule would be policed with respect to PCC-rules MBR data-rate. Any packet exceeding the configured MBR would be discarded. Policing is achieved by maintaining token counts at flow level.

For Static rules or PCRF activated Pre-Defined rules, PGW (PCEF) could have ITC (Intelligent Traffic Control) policing applied at SDF level based on the flow limits configured in the charging actions. Traffic hitting these rules with their charging actions having flow limits configured, would be policed on these flow limit values .For Static and Predefined rules Policing will be done for both MBR and GBR (if applicable) data-rate. Depending on the threshold exceed option configured in the charging action (violate-action <value> OR exceed-action <value>), the packets would be either discarded or TOS remarked to zero. Policing is achieved by maintaining token counts at content-id level.

CLI for configuring the ITC policing functionality in charging action is as follows:

configure

active-charging service <acs_service_name>

charging-action <charging_action_name1>

flow limit-for-bandwidth direction downlink peak-data-rate 4000 peak-burst-size 1024 violate-action discard committed-data-rate 3200 committed-burst-size 512 exceed-action discard

exit

charging-action <charging_action_name2>

content-id 1

exit

charging-action <charging_action_name3>

flow action terminate-flow

end

Note: For SDF level policing burst size can be only configured as a fixed size. No auto-readjust option is provided.

DSCP marking support

PGW supports DSCP marking of the data packets that are transmitted over the EPS bearers. DSCP levels can be assigned to specific traffic patterns in order to ensure that data packets are delivered according to the precedence with which they’re tagged. The DifServ markings are applied to the IP header of every subscriber data packet transmitted over the S5/S8/SGi interface(s). PGW support DSCP marking for both IPv4 and IPv6 data packets. DSCP marking in IP header is done as per IETF RFC 2474.

In Cisco ASR5x00 Based PGW, DSCP marking is enabled in PGW by associating

associate qci-qos-mapping <table-name>

A QCI-QOS table in a PGW service config or it can be configured on per-APN basis , QCI-table associated in APN take precedence for a call. By default if there is no any QCI-QOS mapping Table associated, so by default DSCP marking is disabled on PGW. QCI-QoS mapping tables are used to map QCI values to appropriate QoS parameters.

QCI-QOS mapping table is used to configure DSCP marking config. Below is the CLI for DSCP marking config for a QCI (num) in uplink/downlink direction:

Syntax

qci num [ {downlink | uplink} { encaps-header { copy-inner | dscp-marking hex } |
userdatagram dscp-marking hex [ encaps-header { copy-inner | dscp-marking hex } ] }]

For example:

configure
   qci-qos-mapping <name>
      qci 1 user-datagram dscp-marking <hex>
      qci 3 user-datagram dscp-marking <hex>
      qci 9 user-datagram dscp-marking <hex>
      exit

Above CLI is configured for each QCI (standard range of 1-9) and for each direction (uplink or downlink). By default no any config exists for a QCI for a direction then no any DSCP marking is done, so explicit config is needed to enable DSCP marking. Using this CLI you can configure the DSCP value to be marked for both outer (Tunnel IP header using “encaps-header” option) IP header and/or even the DSCP value to be marked in the inner (Payloads IP header using “userdatagram” option) IP header of the Tunnel packet. For outer header marking you can configure to copy the inner (using “copy-inner” option) IP headers DSCP marking or a specific value (using “dscp-marking” option). In the Uplink direction the Tunnel could be a SGi tunnel like IP-in-IP, GRE or others. In the Downlink direction the Tunnel will be a GTPU tunnel on the S5/S8/Gn interface.

CLI for configuring the charging action to perform DSCP marking is as follows:

ip tos { af11 | af12 | af13 | af21 | af22 | af23 | af31 | af32 | af33 | af41 | 
af42 | af43 | be | ef | lower-bits tos_value } [ uplink | downlink ]

Bearer Binding Support

Cisco ASR5x00 PGW supports PCEF functionality which is compliant with the 3GPP based PCC framework based on 3GPP spec TS 23.203 & TS 29.212

Being a PCEF it needs to support SDF or PCC-rule level Policy and Charging enforcement, thus supporting flow-based QOS and Charging enforcement. In addition to this, PGW also needs to support Bearer-Binding function. Bearer-Binding is a process of binding PCC-rules to a particular bearer. For EPS, PGW needs to support PCEF based Bearer-Binding for IPCAN Session type 3GPP EPS. In PCEF based bearer binding, PCRF is unaware of the bearers and it just provides the PCC-rules to PCEF to bind it to the bearers. PGW (PCEF) receives the directives from PCRF to activate/update/deactivate the PCC-rules, based on this PGW then generates requests to either create/update/delete the EPS bearers using PGW initiated create/update/delete bearer procedures.

At PGW, each PCC-rule to be activated is received from PCRF, with its own PCC-rule level QOS, which includes QCI, ARP, and Data rates (only MBR if QCI is non-GBR QCI else both MBR and GBR if QCI is GBR QCI). Each EPS bearer is uniquely identified by a combination of QCI+ARP. During Bearer-Binding a candidate bearer to bind a rule to be identified based on whether the bearer QCI+ARP matches with that of the PCC-rule.

A new PCC rule is bound to a bearer by Bearer-Binding function in following manner:

•  If there already exists a bearer whose QCI+ARP matches with PCC-rules QCI+ARP, that bearer is selected to bound the PCC-rule. In this case an PGW initiated Update Bearer procedure is triggered to add the packet-filters pertaining to this PCC-rule to the bearer and if it is a GBR bearer then the GBR and MBR data rates are updated as per the addition GBR and MBR data rate needed for this new PCC rule. For non-GBR, no any MBR data rate change is conveyed, as there is no per bearer level MBR data rate for non-GBR bearers.

• If there is no any existing bearer whose QCI+ARP matches to that of the PCC-rules, then the PGW triggers a PGW initiated Create Bearer procedure to create a new bearer with the new QCI+ARP combination.