- SGSN Quality of Service Management
- Quality of Service Attributes
- Quality of Service Attributes in Release 97/98
- Quality of Service Attributes in Release 99
- Quality of Service Management in SGSN
- QoS Features
- Traffic Policing
- QoS Handling When EPS Subscription is Available
- QoS Handling When Only GPRS Subscription is Available
- QoS Handling When EPS Subscription is Available
- QoS Handling When Only GPRS Subscription is Available
- Difference between Gn SGSN and S4 SGSN
- ARP values in Gn SGSN
- ARP values in S4 SGSN
Quality of Service (QoS) Management for SGSN
This chapter describes the implementation of Quality of Service (QoS) related features and functionali ties in SGSN.
Quality of Service Management
The network associates a certain Quality of Service (QoS) with each data transmission in the GPRS packet mode. The QoS attributes are collectively termed as a "QoS Profile". The PDP context stores the QoS Profile information. The QoS management is performed by using the PDP context management procedures, such as PDP context activation, modification and de-activation. QoS enables the differentiation between services provided.
SGSN Quality of Service Management
The SGSN applies an admission control function on each PDP context activation request. The function results in further processing of the request; that is, either negotiation of the QoS with the Mobile Subscriber (MS), or rejection of the PDP context activation request. The SGSN negotiates QoS with the MS when the level requested by the subscriber cannot be supported or when the QoS level negotiated from the previous SGSN cannot be supported at an inter-SGSN routing area update. The response to the mobile subscriber depends on the provisioned subscription data, the requested QoS, the QoS permitted by the Gateway node and the QoS permitted by the Radio Access Network.
Quality of Service Attributes
In an End-to- End Service the network user is provided with a certain Quality of Service, which is specified by a set of QoS attributes or QoS profile. The first list of attributes was defined in Release 97/98 of the 3GPP recommendations but these are now replaced by Release 99 3GPP recommendations. Many QoS profiles can be defined by the combination of these attributes. Each attribute is negotiated by the MS and the GPRS/UMTS/LTE network. If the negotiated QoS profiles are accepted by both parties then the network will have to provide adequate resources to support these QoS profiles.
In Release 97/98 recommendations, the PDP context is stored in the MS, SGSN and GGSN. It represents the relation between one PDP address, PDP type (static or dynamic address), the address of a GGSN that serves as an access point to an external PDN, and one Quality of Service (QoS) profile. PDP contexts with different QoS parameters cannot share the same PDP address. In Release 99 recommendations a subscriber can use more than one PDP contexts with different QoS parameters and share the same PDP address.
Quality of Service Attributes in Release 97/98
In Release 97/98 of the 3GPP recommendations, QoS is defined according to the following attributes:
- Precedence Class: This attribute indicates the packet transfer priority under abnormal conditions, for example during a network congestion load.
- Reliability Class: This attribute indicates the transmission characteristics. It defines the probability of data loss, data delivered out of sequence, duplicate data delivery, and corrupted data. This parameter enables the configuration of layer "2" protocols in acknowledged or unacknowledged modes.
- Peak Throughput Class: This attribute indicates the expected maximum data transfer rate across the network for a specific access to an external packet switching network (from 8 Kbps up to 2,048 Kbps).
- Mean Throughput Class: This attribute indicates the average data transfer rate across the network during the remaining lifetime of a specific access to an external packet switching network (best effort, from 0.22 bps up to 111 Kbps).
- Delay Class: This attribute defines the end-to-end transfer delay for the transmission of Service Data Units (SDUs) through the GPRS network. The SDU represents the data unit accepted by the upper layer of GPRS and conveyed through the GPRS network.
Quality of Service Attributes in Release 99
The attributes of GPRS QoS were modified in Release 99 of the 3GPP recommendations in order to be identical to the ones defined for UMTS.
The quality of service is a type "4" information element with a minimum length of "14" octets and a maximum length of "18" octets.
The Release 99 of 3GPP recommendations defines QoS attributes such as Traffic class, Delivery order, SDU format information, SDU error ratio, Maximum SDU size, Maximum bit rate for uplink, Maximum bit rate for downlink, Residual bit error ratio, Transfer delay, Traffic-handling priority, Allocation/retention priority, and Guaranteed bit rate for uplink and Guaranteed bit rate for downlink. The attributes are listed below:
- Traffic Class: Indicates the application type (conversational, streaming, interactive, background). Four classes of traffic have been defined for QoS:
- Conversational Class: These services are dedicated to bi-directional communication in real time (for example, voice over IP and video conferencing).
- Streaming Class: These services are dedicated to uni-directional data transfer in real time (for example, audio streaming and one-way video).
- Interactive Class: These services are dedicated to the transport of human or machine interaction with remote equipment (for example, Web browsing, access to a server and access to a database).
- Background Class: These services are dedicated to machine-to-machine communication; this class of traffic is not delay sensitive (for example, e-mail and SMS).
Quality of Service Management in SGSN
QoS management comprises of approximately "23" individual parameters. As part of QoS Management, the SGSN negotiates the MS requested QoS with the following during PDP context Activation and Modification procedures:
- Subscribed QoS
- Local QoS capping limit (if configured)
- QoS sent by GGSN in tunnel management messages
- QoS sent by RNC in RAB assignment messages (UMTS only)
Each negotiation is between QoS parameters of the two sets, and the resulting negotiated QoS will be the lower of the two. QoS negotiation for Secondary PDP contexts is same as Primary PDP context.
For more information see, 3GPP TS 24.008 (section 10.5.6.5 "Quality of Service".
QoS Negotiation During an Activation Procedure
During an Activation procedure the MS requested QoS is negotiated with the subscribed QoS. Higher values are not valid in case of GPRS access, the SGSN restricts some of the QoS parameters during PDP activation in GPRS access. Listed below are the QoS parameters which are restricted in GPRS access:
- Maximum Bitrate (MBR) DL is capped to "472" kbps.
- Maximum Bitrate (MBR) UL is capped to "472" kbps.
- Peak Throughput (PR) is capped to "6" ("32000" octets/sec).
- Reliability class (RC) of "0x2", "Unacknowledged GTP; Acknowledged LLC and RLC, Protected data" is not supported. In such cases, RC is over-ridden as "0x3", "Unacknowledged GTP and LLC; Acknowledged RLC, Protected data"
The SDU Error ratio is capped in following cases:
- For Reliability Class "0x3", the SDU error ratio is capped to "4" (1x10 -4 ) if it exceeds a value of "4", a value greater than "4" represents stringent error ratios.
- For Reliability Class greater than "0x3", the SDU error ratio capped to "3" (1x10 -3 ) if the value provided exceeds "4".
For more information see, 3GPP TS 23.107 (Table 6 "Rules for determining R99 attributes from R97/98 attributes").
The QoS parameters are sent to GGSN in the Create PDP Context Request. On receiving a Create PDP Context Response, the QoS sent by GGSN is negotiated with the one sent by SGSN to GGSN. For GPRS access, this negotiated QoS is sent to the MS in Activate PDP Context Accept.
If the UE requests a subscribed traffic class, the SGSN defaults it to "Interactive" traffic class regardless of the configuration in the HLR subscription.
In a UMTS access scenario, the negotiated QoS is sent to RNC in RAB Assignment Request. By default, the SGSN includes Alternative Max Bit Rate with type set to "Unspecified". This indicates to the RNC that it can further negotiate the QoS downwards if either the RNC/UE cannot support the QoS value sent. The RNC may downgrade the QoS based on its current load/capability and include it in RAB Assignment Response. The SGSN does QoS negotiation once more with received QoS from the RNC. This is used as the negotiated QoS of PDP context and is sent to the MS in Activate PDP context Accept. If the RNC has downgraded the QoS, the same will be informed to GGSN by means of an Update PDP context procedure.
When the MS sends an Activate PDP Context Request, it may set all the QoS values to "0", this implies that the MS is requesting the SGSN to take QoS values from the subscription. In this case the SGSN negotiates the subscribed QoS with any locally configured QoS and sends the negotiated QoS value to GGSN.
QoS Negotiation During a Modification Procedure
The PDP Context Modification procedure can be MS initiated or Network initiated, it is used to change the current negotiated QoS. If it is a MS initiated PDP Context Modification procedure the QoS negotiation is similar to the QoS negotiation followed during an Activation procedure. The HLR or GGSN or SGSN (RNC in case of UMTS access) can perform a Network Initiated QoS modification.
For more information on "PDP Context Modification Procedure" see, 3GPP TS 24.008 section 6.1.3.3
HLR Initiated QoS Modification
- User action (The user may subscribe for a more premium service)
- Service provider action (The QoS is restricted on reaching download limits)
This change is relayed by the HLR to the SGSN through the Insert Subscription Data procedure. As per 3GPP TS 23.060 section 6.11.1.1 "Insert Subscriber Data procedure", the SGSN negotiates the current QoS with new subscribed QoS and initiates a Network Initiated PDP modification procedure only in case of QoS downgrade. As part of this procedure, the GGSN (and RNC in case of UMTS access) is updated with the new negotiated QoS followed by the MS. If a failure occurs or no response is received from the MS for the Modify Request, the PDP context is deactivated.
The SGSN is compliant with 3GPP TS 23.060 Release 7 version. The specifications Release 8 and above specify a modified behavior when the UE is in a IDLE/STANDBY state. If the QoS is modified by the HLR when an UE is an IDLE/STANDBY state the PDP is de-activated. The SGSN is made compliant with this change to align its behavior with LTE elements like MME. Therefore the SGSN is compliant with both the Release 7 and Release 8 specifications.
GGSN Initiated QoS Modification
- An External Trigger (PCRF)
- Current load or capability of the GGSN
- If the "No Qos negotiation" flag is set in the previous Tunnel Management Request from SGSN.
The SGSN negotiates this QoS with the subscription. The negotiated Qos is then sent to the UE in a Modify PDP Request. In an UMTS access scenario, the SGSN updates the new negotiated QoS to the RNC. The new negotiated Qos is then forwarded to the GGSN in response message.
SGSN Initiated QoS Modification
The SGSN initiated QoS Modification occurs during an Inter-RAT HO (2G to 3G / 3G or 2G), here the negotiated QoS in new access is different from the negotiated QoS in old access. The SGSN QoS initiated QoS Modification can also occur during a new SGSN ISRAU/SRNS procedure where the new negotiated QoS is different from the negotiated QoS received from the peer SGSN.
Whenever a UE performs an Intra or Inter SGSN HO, the SGSN receives the requested QoS, subscribed QoS and the negotiated QoS from the old access (during Intra SGSN HO) or from peer SGSN (during Inter SGSN HO). This requested QoS is then negotiated with the subscribed QoS. If the negotiated QoS is different from the received negotiated QoS, the SGSN initiates a network initiated QoS modification procedure to update the new negotiated QoS to the UE after completing the HO procedure.
RNC Initiated QoS Modification (UMTS access only)
In a RNC initiated QoS modification procedure the SGSN negotiates the QoS with the current negotiated QoS. In case of a downgrade, the SGSN updates the GGSN and MS with the new negotiated QoS.
For more information see, 3GPP TS 23.060 section 9.2.3.6 on "RAN-initiated RAB Modification Procedure"
No QoS Negotiation Flag
When the 'No QoS Negotiation' flag is set, the SGSN indicates to the GGSN not to negotiate the QoS. The "No QoS Negotiation" flag is set in the following scenarios:
- While sending Update PDP Context request during activation (Direct tunnel).
- During a service request for data with direct tunnel enabled for the subscriber, a UPCQ is initiated to inform the GGSN with the teid and the address of the RNC. This Update PDP context request has no negotiation bit set.
- Update PDP context request sent during preservation procedures.
- UPCQ sent to indicate establishment / removal of direct tunnel.
- Intra SGSN SRNS.
- Downlink data for the subscriber without active RABs and direct tunnel enabled for the subscriber, UPCQ is initiated to inform the GGSN of the teid and the address of the RNC. This Update PDP context request has "No QoS Negotiation" flag set.
- In all modification procedures (HLR, RNC, MS) if any other node other than the modifying entity has downgraded the QoS. For example, consider a HLR Initiated Modification procedure where the SGSN does the following signaling:
- Initiates a UPCQ to inform the GGSN of the QOS change, GGSN sends a UPCR with same QOS as UPCQ.
- Modify PDP context Request to MS, the MS sends a Modify PDP Accept.
- RAB establishment request to the RNC, the RNC downgrades the QoS in the RAB assignment response.
- The SGSN initiates a UPCQ to inform the GGSN of the new QoS sent in the previous step. This UPCQ will have no QoS negotiation bit set.
QoS Features
Traffic Policing
The SGSN can police uplink and downlink traffic according to predefined QoS negotiated limits fixed on the basis of individual contexts - either primary or secondary. The SGSN employs the Two Rate Three Color Marker (RFC2698) algorithm for traffic policing. The algorithm meters an IP packet stream and marks its packets either green, yellow, or red depending upon the following variables:
- PIR: Peak Information Rate (measured in bytes/second)
- CIR: Committed Information Rate (measured in bytes/second)
- PBS: Peak Burst Size (measured in bytes)
- CBS: Committed Burst Size (measured in bytes)
The following figure depicts the working of the TCM algorithm:
The policing function compares the data unit traffic with the related QoS attributes. Data units not matching the relevant attributes will be dropped or marked as not matching, for preferential dropping in case of congestion.
Procedure To Configure Traffic Policing:
This procedure is used to configure the actions governing the subscriber traffic flow. That is, if the flow violates or exceeds the configured, negotiated peak or committed data-rates. The SGSN performs traffic policing only if the command qos rate-limit direction is configured.
config apn-profile profile_name qos rate-limit direction < downlink | uplink >[ burst-size < auto-readjust [ duration seconds ] | bytes > ] [ class < background | conversational | interactive traffic_priority | streaming > ] [ exceed-action < drop | lower-ip-precedence | transmit >] [ gbr-qci [ committed-auto-readjust durarion seconds ] ] [ non-gbr-qci [ committed-auto-readjust durarion seconds ] ] [ violate-action < drop | lower-ip-precedence | transmit >] + exitThis command can be entered multiple times to specify different combinations of traffic direction and class.
The remove keyword can be used with the qos rate-limit direction command to remove the qos rate-limit direction entries from the configuration.
config apn-profile profile_name remove qos rate-limit direction < downlink | uplink >[ burst-size < auto-readjust [ duration seconds ] | bytes > ] [ class < background | conversational | interactive traffic_priority | streaming > ] [ exceed-action < drop | lower-ip-precedence | transmit >] [ gbr-qci [ committed-auto-readjust durarion seconds ] ] [ non-gbr-qci [ committed-auto-readjust durarion seconds ] ] [ violate-action < drop | lower-ip-precedence | transmit >] + exitQoS Traffic Policing Per Subscriber
Traffic policing enables the operator to configure and enforce bandwidth limitations on individual PDP contexts for a particular traffic class. It deals with eliminating bursts of traffic and managing traffic flows in order to comply with a traffic contract.
The SGSN complies with the DiffServ model for QoS. The SGSN handles the 3GPP defined classes of traffic, QoS negotiation, DSCP marking, traffic policing, and support for HSDPA/HSUPA.
The per Subscriber traffic policing can be achieved by creating an operator policy for required subscribers (IMSI range) and associating the APN profile having the relevant qos-rate-limit configuration with the operator policy.
DSCP Marking and DSCP Templates
Differentiated Services Code Point specifies a mechanism for classifying and managing network traffic and providing Quality of Service (QoS) on IP networks. DSCP uses the 6-bit Differentiated Services Code Point (DSCP) field in the IP header for packet classification purposes. DSCP replaces the Type of Service (TOS) field.
The SGSN performs a DiffServ Code Point (DSCP) marking of the GTP-U packets according to the allowed-QoS to PHB mapping. The default mapping matches that of the UMTS to IP QoS mapping defined in 3GPP TS 29.208.
DSCP is standardized by the RFCs 2474 and 2475. DSCP templates contain DSCP code points for specific traffic types. DSCP is used to differentiate traffic types and the priority with which they should be allowed through the network. In MPC, DSCP templates are created and applied for signaling (2G/3G) and data traffic, where signaling takes precedence over the data plane. When signaling and data are sent through a single channel, critical signaling messages are adversely affected due to the queueing created by large chunks of data. With DSCP it is possible to have separate queues for signaling and data based on code point value and handle them based on relative precedence.
The SGSN supports DSCP marking of the GTP control plane messages on the Gn/Gp interface. This allows the QoS to be set on GTP-C messages, and is useful if Gn/Gp is on a less than ideal link. DSCP can also be configured at the NSEI level and this configuration has higher precedence over GPRS level configuration. DSCP marking is configurable through the CLI, with default being "Best Effort Forwarding".
The following configuration procedures are used to configure DSCP marking parameters:
-
The IP command The ip command is used to configure DSCP Marking which is used for sending packets of a particular 3GPP QoS class.
To reset the values to the default configuration, use the following procedure:config apn-profile profile_name ip < qos-dscp < < downlink | uplink >< background forwarding | conversational forwarding | interactive traffic-handling-priority priority forwarding | streaming forwarding > + > | source-violation < deactivate [ all-pdp | exclude-from accounting | linked-pdp | tolerance-limit >| discard [ exclude-from-accounting ] | ignore > exit
The following procedure is used to disable IP QoS-DSCP mapping:config apn-profile profile_name default ip exitconfig apn-profile profile_name no ip qos-dscp < downlink | uplink > < background | conversational | interactive | streaming >+ exit
The following command is used to configure the QoS DSCP value to "BE" (Best Effort):config context context_name sgsn-global dscp-templatetemplate_name control-packet qos-dscp exitconfig context context_name sgsn-global dscp-templatetemplate_name default control-packet exitThe following configuration procedure is used to configure DSCP value for 3GPP QoS class downlink data packets:
The following command is used to configure the QoS DSCP value to "BE" (Best Effort):config context context_name sgsn-global dscp-templatetemplate_name data-packet < background | conversationa | interactive < priority1 | priority2 | priority3 >| streaming > qos-dscp exitconfig context context_name sgsn-global dscp-templatetemplate_name default data-packet < background | conversationa | interactive < priority1 | priority2 | priority3 >| streaming > exit
To disassociate a previously associated DSCP marking template:config context context_name gprs-service service_name associate-dscp-template downlink template_name exit
IuPS Service Configuration Mode:config context context_name gprs-service service_name no associate-dscp-template downlink exit
To disassociate a previously associated DSCP marking template:config context context_name iups-service service_name associate dscp-template downlink dscp_template_name exit
SGSN PSP Configuration Mode:config context context_name iups-service service_name no associate dscp-template downlink exit
To disassociate a previously associated DSCP marking template:config context context_name ss7-routing-domain routing_domain_id variant variant_type associate < asp instance asp_num | dscp-template downlink template_name > exitconfig context context_name ss7-routing-domain routing_domain_id variant variant_type no associate [ asp | dscp-template downlink ] exit
To remove the specified configuration from this peer-nsei configuration:config context context_name gprs-service service_name peer-nsei nse_id associate dscp-template downlink template_name | lac lac_id rac rac_id | name peer_nsei_name | pooled > exitconfig context context_name gprs-service service_name no peer-nsei nse_id [ associate dscp-template downlink | lac lac_id rac rac_id | name | pooled ] exit
To reset the values to the default configuration, use the following procedure:config context context_name sgtp-service service_name gtpc < bind address ipv4_address | dns-sgsn context context_name | echo-interval interval_seconds | echo-retransmission < exponential-backoff [ [ min-timeout timeout_seconds ] [ smooth-factor smooth_factor ] + ] | timeout timeout_seconds > | guard-interval interval_seconds | ignore response-port-validation | ip qos-dscp dscp_marking | max-retransmissions max_retransmissions | retransmission-timeout timeout_seconds | send < common flags | rab-context | target-identification-preamble >> exitconfig context context_name sgtp-service service_name default gtpc < echo-interval | echo-retransmission | guard-interval | ignore response-port-validation | ip qos-dscp | max-retransmissions | retransmission-timeout | send < common-flags | rab-context | target-identification-preamble >> exitTo check values configured for DSCP templates, use the show sgsn-mode command.
Local QoS Capping
The QoS bit rate can be capped by the operator. The SGSN can be configured to limit the QoS bit rate parameter when the subscribed QoS provided by the HLR is lower than the locally configured value. Based on the configuration enabled, the SGSN can choose the QoS parameter configuration from the HLR configuration or from the local settings used in the APN profile. During session establishment the SGSN applies the lower of the two, that is either the HLR subscription or locally configured value.
The following procedure is used to configure the local Traffic Class (TC) parameters:
To enable any of the values/features configured with this command, the qos prefer-as-cap configuration (also in the APN profile configuration mode) must be set to either local or both-hlr-and-local .
config apn-profile profile_name qos class < background | conversational | interactive | streaming >[ qualif_option ] exitTo remove the previously defined TC parameters, use the following procedure:
config apn-profile profile_name remove qos class < background | conversational | interactive | streaming >[ qualif_option ] exitTo specify the operational preferences of QoS Parameters (specifically the QoS bit rates), use the following procedure:
config apn-profile profile_name qos prefer-as-cap < both-hlr-and-local | both-hss-and-local | hlr-subscription | local > exitTo remove all the previous configurations and reset the values to default, use the following procedure:
config apn-profile profile_name remove qos prefer-as-cap exitQoS Management When UE is Using S4-interface for PDP Contexts
EPC QoS Parameters
The SGSN uses the S4 interface with EPC network elements S-GW or P-GW. The QoS parameters used in the EPC network are different from the ones used in GPRS/UMTS network. For more information refer to the 3GPP TS 23.203 section 6.1.7.
- QoS Class Identifier (QCI): The QCI is scalar that is used as a reference to node specific parameters that control packet forwarding treatment (for example, scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration and so on.) and that have been pre-configured by the operator owning the node (for example, eNodeB). The standardized characters associated with a standard QCI are listed below:
- Resource Type (GBR or Non-GBR)
- Priority
- Packet Delay Budget
- Packet Error Loss Rate
- APN AMBR: The APN-AMBR limits the aggregate bit rate that can be provided across all Non- GBR PDP contexts of the same APN (for example, excess traffic may get discarded by a rate shaping function). Each of those Non-GBR PDP contexts can potentially utilize the entire APN AMBR (for example, when the other Non-GBR PDP contexts do not carry any traffic). The GBR PDP contexts are outside the scope of APN AMBR. The PGW enforces the APN AMBR in downlink. Enforcement of APN AMBR in uplink may be done in the UE and additionally in the PGW.
- UE AMBR: The UE AMBR limits the aggregate bit rate that can be provided across all Non-GBR PDP contexts of a UE (for example, excess traffic may get discarded by a rate shaping function). Each of the Non-GBR PDP contexts can potentially use the entire UE AMBR (for example, when the other Non-GBR PDP contexts do not carry any traffic). The GBR (real-time) PDP contexts are outside the scope of UE AMBR. The RAN enforces the UE AMBR in uplink and downlink.
- E-ARP: The EPC uses Evolved ARP, which has priority level ranging from "1" up to "15". Additionally, evolved ARP comprises of pre-emption capability and pre-emption vulnerability. The preemption capability information defines whether a bearer with a lower priority level should be dropped to free up the required resources. The pre-emption vulnerability information indicates whether a bearer is applicable for such dropping by a preemption capable bearer with a higher priority value. For handover between UTRAN/GERAN and E-UTRAN, refer to 3GPP TS 24.101 "Annexure-E" . It defines the mapping rule between ARP and Evolved ARP during R99 QoS to EPS bearer QoS mapping and vice versa.
- MBR: Maximum Bit Rate indicates the maximum number of bits delivered to the network or by the network within a period of time. This parameter is as defined in GMM QoS Parameters. In EPC, these values are encoded as a "5" octet linear value but in GMM QoS it is a single octet or a two octet step wise value.
- GBR: Guaranteed Bit Rate indicates the guaranteed number of bits delivered to the network or by the network within a period of time. This parameter is as defined in GMM QoS Parameters. In EPC, these values are encoded as a "5" octet linear value but in GMM QoS it is a single octet or a two octet step wise value.
Subscription Types Supported by S4-SGSN
- EPC Subscription: If a subscriber has an EPC subscription, the QoS in subscription data is sent in the EPC format.
- GPRS Subscription: If the subscriber does not have an EPC subscription, the QoS in subscription data is sent in R99/R5/R7 format.
QoS Mapping
The S4-SGSN communicates the QoS parameters towards the S-GW and P-GW in EPC QoS.In UTRAN / GERAN access, the QoS carried over NAS messages to UE are in legacy GMM QoS R99/R5/R7 format ( Refer to, 3GPP TS 24.008 section 10.5.6.5 ). However on the S4 / S5 / S16 / S3 interfaces the QoS is carried in EPC format (APN-AMBR, E-ARP and so on). A mapping is required between EPC QoS and GMM QoS, this mapping for EPS QoS to pre-release 8 QoS is defined in 3GPP TS 23.401, Annexure E.
Mapping Details
Information on the parameters mapped is listed below:
- APN-AMBR is mapped to MBR for non-GBR bearers.
- Per bearer MBR and GBR is mapped to MBR and GBR towards UE for GBR bearers.
- For information on other mapping values refer to, 3GPP TS 23.203, table 6.1.7.
Mapping is performed during the following scenarios:
- During Activate Accept (EPC QoS to GMM QoS)
- During Activation initiated Create Session Request (if GPRS subscription is used GMM QoS to EPC QoS mapping)
- During S4-SGSN to Gn SGSN handover (EPC QoS to GMM QoS)
- During HLR / HSS initiated QoS modification (if GPRS subscription is used GMM to EPC QoS towards SGW/PGW; towards UE EPC to GMM QoS for both types of subscription)
Calculation on UE-AMBR
The S4-SGSN sets the value of UE-AMBR as follows:
Value of used UE-AMBR = Sum of APN-AMBRs of all active PDN connections for the given UE, limited or capped by the subscribed UE-AMBR.
For more information refer to, 3GPP TS 23.401, section 4.7.3.
Local capping of UE-AMBR will be applicable in the upcoming software releases.
The calculated UE-AMBR is communicated to the RNC. The RNC enforces the UE level aggregate bit rate in both uplink and downlink directions. The RNC has to be R9 compliant. This functionality of sending IE to RNC will not be supported on release 15.0, it is planned for future releases.
To obtain E-ARP when GPRS subscription is used
To obtain E-ARP, configure ARP high and medium priority values at the Call Control Profile through the CLI command listed below:
For more information refer to, 3GPP TS 23.401, Annexure E
To obtain QCI when GPRS subscription is used
The mapping information on obtaining QCI when GPRS subscription is used is listed in 3GPP TS 23.401 (table E.3) and 3GPP TS 23.203 (table 6.1.7).
QoS Mapping from SGSN to SGW/PGW
The QoS Mapping from SGSN to SGW/PGW can be depicted as follows:
QoS Mapping from SGSN to UE/RNC
The QoS Mapping from SGSN to UE/RNC can be depicted as follows:
QoS in GMM is an encoded octet. QoS in EPC is a linear "4" octet value in kbps. It is not possible to encode an odd value like "8991" kbps in GMM QoS.
QoS Handling Scenarios
Scenario-1:
Listed below are various QoS handling scenarios and QoS Mapping for each of the scenarios:
Description of the scenario:
- Attach is received from an EPC capable UE.
- The HLR subscription does not have EPS subscription data. Only GPRS subscription is present.
- Activate a PDP context with all QoS parameters set to "subscribed".
For this scenario, PDP context activation through Gn/Gp interface by default is not done. Instead a S4 election is done as the UE is EPC capable. However, if the local operator policy overrides this to select Gn/Gp, then Gn/Gp is preferred.
QoS mapping for the scenario:
If S4 is the selected interface, then the subscribed MBR is mapped to APN AMBR. The EPS bearer QoS MBR is set to subscribed MBR (for conversational and streaming class bearers). For non-GBR bearers the EPS bearer QoS MBR is set to "0". If the traffic class is conversational or streaming, then the EPS bearer QoS GBR is set to subscribed GBR.
A detailed list of mapping:
- APN AMBR = Subscribed MBR
- Bearer QoS PVI = Taken from local policy [use call-control-profile qos gn-gp config]
- Bearer QoS PCI = Taken from local policy [use call-control-profile qos gn-gp config]
- Bearer QoS PL = Taken from local policy [use call-control-profile qos gn-gp config]
- Bearer QoS QCI = Mapped from subscribed traffic class
- Bearer QoS MBR UL and DL = Mapped from subscribed MBR + MBR-Extended for UL and DL
- Bearer QoS GBR UL and DL = Zero for interactive or background traffic. For streaming or conversational it is mapped from subscribed GBR + Ext.GBR UL / DL
References:
3GPP TS 23.401 Annexure E and 3GPP TS 29.274 section 8.15.
Scenario-2:
Description of the scenario:
The scenario is same as Scenario-1 described above, the only change being inclusion of sending activate accept to UE.
- Attach is received from an EPC capable UE.
- The HLR subscription does not have EPS subscription data. Only GPRS subscription is present.
- Activate a PDP context with all QoS parameters set to "subscribed".
For this scenario, PDP context activation through Gn/Gp interface by default is not done. Instead a S4 election is done as the UE is EPC capable. However, if the local operator policy overrides this to select Gn/Gp, then Gn/Gp is preferred.
QoS mapping for the scenario:
After the create session response is received from the S-GW, the following mapping shall be used to send the QoS towards UE:
- Traffic Mapped from QCI based on Table E.3 in 3GPP TS 23.401.
- Delivery Order = Taken from local configuration [apn-profile --> qos --> class [traffic class] --> sdu --> delivery order]
- Delivery of erroneous SDU = Taken from local configuration [apn-profile --> qos --> class [traffic class] --> sdu --> erroneous]
- Maximum SDU Size = [apn-profile --> qos --> class [traffic class] --> sdu --> max size]
- MBR Uplink = APN-AMBR-UL (if traffic /background) or Bearer MBR-UL (if TC = streaming / conversational)
- MBR DL = APN-AMBR-DL (if traffic /background) or Bearer MBR-DL (if TC = streaming / conversational)
- Residual BER = Taken from local config [apn-profile-->qos-->class [tc] --> residual-bit-error-rate
- SDU error ratio = Mapped based on Table 6.1.7 in 3GPP TS 23.203
- Transfer delay = Mapped based on Table 6.1.7 in 3GPP TS 23.203
- THP = Mapped from QCI based on Table E.3 in 3GPP TS 23.401
- GBR UL = "0" for interactive or background class traffic. Mapped from Bearer QoS GBR UL for conversational or streaming traffic.
- GBR DL = "0" for interactive or background class traffic. Mapped from Bearer QoS GBR DL for conversational or streaming traffic.
- Signaling Indication = Mapped from QCI as per Table E.3 3GPP TS 23.401
- Extended bit rates will be present if the mapped MBR / GBR exceeds "8640" Kbps
Scenario-3:
Description of the scenario:
- Attach is received from an EPC capable UE
- The HLR subscription does not have EPS subscription data. Only GPRS subscription data is present.
- A primary PDP context is activated with all QoS parameters set to some requested values.
QoS mapping for the scenario:
- Negotiate the requested QoS with subscribed QoS. Map the negotiated QoS as described in Scenario-1.
- After receiving a Create Session Response, map the accepted EPS QoS to R99+ QoS as described in Scenario-2 and send the Activate accept.
Scenario-4:
Description of the scenario:
- Attach is received from an EPC capable UE
- The HLR subscription has EPS subscription data.
- A PDP context is activated with all QoS parameters set to "Subscribed" values or some requested values.
QoS mapping for the scenario:
- For every primary PDP context to an APN, the EPS subscribed QoS is used as is.
- Once the EPS bearer is activated, the Activate PDP Accept is sent by mapping the accepted QoS value as described in Scenario-2.
Scenario-5:
Description of the scenario:
- Attach is received from an EPC capable UE
- The HLR subscription has EPS subscription data.
- A secondary PDP context is activated with all QoS parameters set to "Subscribed" values.
QoS mapping for the scenario:
The SGSN sends a Bearer Resource Command with the following parameters:
- Linked EPS Bearer bearer ID of linked Primary PDP
- PTI = Transaction ID received from the MS (In MME, the received PTI is used in the NAS message as the PTI towards S-GW. But for the SGSN PTI is not there in the NAS message. The 3GPP TS is not clear on what the SGSN should send as PTI, therefore TI is sent.
- QCI = Mapped from requested Traffic Class, if TC= conversational / streaming
- MBR UL = APN-AMBR last received from P-GW for primary PDP activation
- MBR DL = APN-AMBR last received from P-GW for primary PDP activation
- GBR UL = APN-AMBR last received from P-GW for primary PDP activation
- GBR DL = APN-AMBR last received from P-GW for primary PDP activation
- Else, the values will be MBR UL = "0", BR DL ="0", GBR UL = "0", GBR DL = "0"
The value sent in the Flow QoS does not have any impact as it is the P-GW which decides the correct QoS value to be provided. If the requested QoS is set to "subscribed" then as a placeholder value the APN-AMBR value is sent as the MBR and GBR values.
References:
3GPP TS 23.401 Annexure E and 3GPP TS 29.274 (sections 8.15 and 8.16).
Scenario-6:
Description of the scenario:
- Attach is received from an EPC capable UE
- The HLR subscription has EPS subscription data.
- A secondary PDP context is activated with all QoS parameters set to specified values.
QoS mapping for the scenario:
The SGSN sends a Bearer Resource Command with the following parameters:
- Linked EPS Bearer bearer ID of linked Primary PDP
- PTI = Transaction ID received from the MS (In MME, the received PTI is used in the NAS message as the PTI towards S-GW. But for the SGSN PTI is not there in the NAS message. The 3GPP TS is not clear on what the SGSN should send as PTI, therefore TI is sent.
- QCI = Mapped from requested Traffic Class, if TC= conversational or streaming.
- MBR UL = Requested MBR UL, MBR DL = Requested MBR DL
- GBR UL = Requested GBR UL, GBR DL = Requested GBR DL or GBR UL = "0", GBR DL = "0"
If the traffic class is conversational or streaming, the requested MBR or GBR values can be greater than the subscribed APN-AMBR.
References:
3GPP TS 23.401 Annexure E and 3GPP TS 29.274 (sections 8.15 and 8.16)
Scenario-7:
Description of the scenario:
- Attach is received from an EPC capable UE
- The HLR subscription does not have EPS subscription data.
- A secondary PDP context is activated with all QoS parameters set to "Subscribed".
QoS mapping for the scenario:
The SGSN sends a Bearer Resource Command with the following parameters:
- Linked EPS Bearer bearer ID of linked Primary PDP
- PTI = Transaction ID received from the MS (In MME, the received PTI is used in the NAS message as the PTI towards S-GW. But for the SGSN PTI is not there in the NAS message. The 3GPP TS is not clear on what the SGSN should send as PTI, therefore TI is sent.
- QCI = Mapped from requested Traffic Class, if TC= conversational or streaming
- MBR UL = APN-AMBR-UL last obtained from P-GW for primary
- MBR DL = APN-AMBR-DL last obtained from P-GW for primary
- GBR UL = APN-AMBR-UL last obtained from P-GW for primary
- GBR DL = APN-AMBR-UL last obtained from P-GW for primary
- Else, MBR UL = "0", MBR DL = "0", GBR UL = "0", GBR DL = "0"
Scenario-8:
Description of the scenario:
- Attach is received from an EPC capable UE
- The HLR subscription does not have EPS subscription data.
- A secondary PDP context is activated with all QoS parameters set to valid requested values.
QoS mapping for the scenario:
Cap the requested QoS with the subscribed QoS. Then use the negotiated QoS as described below, the SGSN sends a Bearer Resource Command with the following parameters:
- Linked EPS Bearer bearer ID of linked Primary PDP
- PTI = Transaction ID received from the MS (In MME, the received PTI is used in the NAS message as the PTI towards S-GW. But for the SGSN PTI is not there in the NAS message. The 3GPP TS is not clear on what the SGSN should send as PTI, therefore TI is sent.
- QCI = Mapped from requested Traffic Class, if TC= conversational or streaming
- MBR UL = MBR-UL negotiated
- MBR DL = MBR-DL negotiated
- GBR UL = GBR-UL negotiated
- GBR DL = GBR-DL negotiated
- Else, MBR UL = "0", MBR DL = "0", GBR UL = "0", GBR DL = "0"
Scenario-9:
Description of the scenario:
In-bound RAU or Forward Relocation Request for a subscriber, who was earlier attached on a Gn/Gp SGSN.
This scenario is currently not supported.
QoS mapping for the scenario:
- APN-AMBR-UL = Subscribed MBR-UL
- APN-AMBR-DL = Subscribed MBR-DL
- Bearer QoS MBR = Negotiated MBR received from peer SGSN Bearer QoS GBR = "0", for Interactive or Background traffic classes and it is Negotiated GBR value for Conversational or Streaming traffic classes.
- Bearer QoS - PVI = Use from Local Policy (use call-control-profile qos gn-gp configuration)
- Bearer QoS - PCI = Use from Local Policy (use call-control-profile qos gn-gp configuration)
- Bearer QoS - PL = Use from Local Policy (use call-control-profile qos gn-gp configuration), based on the negotiated ARP received.
- Bearer QoS - QCI = Mapped from negotiated traffic class.
References:
3GPP TS 23.401 Annexure E and 3GPP TS 23.060 v8.9.0 (section 6.9.1.2.2.a)
Scenario-10:
Description of the scenario:
Outbound RAU or Forward Re-location Request is sent towards a Gn/Gp SGSN.
QoS mapping for the scenario:
- Subscribed QoS = Mapped from subscribed EPS QoS
- Requested QoS = Return the MS requested value
- Negotiated QoS = Mapped from the current EPS QoS
- The mapping of EPS QoS to pre- release "8" QoS is as described in scenario-2.
- When mapping subscribed EPS QoS to pre-release "8" MBR and GBR the following rules are applied:
- MBR-UL = APN-AMBR-UL
- MBR-DL = APN-AMBR-DL
- GBR-UL / DL = "0" (for TC = interactive / background)
- GBR-UL / DL = APN-AMBR-UL / DL (for TC = interactive / background)
Scenario-11:
Description of the scenario:
Initiating modify a PDP towards UE from SGSN (for instances of P-GW initiated QoS modification, HSS initiated modification and so on.)
QoS mapping for the scenario:
The current EPS QoS at SGSN is mapped to pre-release "8" QoS as described in Scenario-2.
QoS in GMM is an encoded octet. QoS in EPC is a linear "4" octet value in kbps. It is not possible to encode an odd value like "8991" kbps in GMM QoS.
QoS Handling During Primary PDP Activation
QoS Handling When EPS Subscription is Available
- The subscribed APN-AMBR and ARP values are sent in Create Session Request to SGW or PGW.
- The PGW can change the APN-AMBR value in Create Session Response.
- The SGSN accepts the APN-AMBR value sent by the PGW. No further negotiation happens as described in 3GPP TS 23.060 section 9.2.2.1A, list item "d".
- In most cases the S4-SGSN does not perform any further QoS negotiation. (However, there is a special case of SGSN capping the bit rate sent to RAN at 16Mbps. This requirement will be supported in future releases).
- The S4-SGSN maps the received APN-AMBR to MBR values as per the mapping table provided in 3GPP TS 23.203 Table 6.1.7 and 3GPP TS 23.401 Annex E.
- The mapped MBR values are sent to the RNC in RAB assignment request and in Activate Accept to the UE.
- In Release 14.0 local override of APN-AMBR / ARP based on CLI configuration is supported.
QoS Handling When Only GPRS Subscription is Available
- The requested QoS from UE and the subscribed QoS are negotiated, the SGSN chooses the least of the two values as the negotiated output. If the requested QoS is the Subscribed QoS, the SGSN chooses the Subscribed QoS as is. If any local QoS capping is configured, the Negotiated QoS is the least of Requested QoS or Subscribed QoS capped by local values).
- The Negotiated QoS is mapped to EPC QoS as per the mapping table in 3GPP TS 23.203 Table 6.1.7 and 3GPP TS 23.401 Annexure E.
- The mapped values are sent in Create Session Request to the SGW or PGW.
- The PGW is allowed to change the APN-AMBR value in Create Session Response.
- The SGSN accepts the APN-AMBR value sent by the PGW. No further negotiation happens as described in 3GPP TS 23.060 section 9.2.2.1A, list item "d".
- The S4-SGSN maps the received the APN-AMBR to MBR value as per the mapping table described in 3GPP TS 23.203 table 6.1.7 and 3GPP TS 23.401 Annexure "E".
- The mapped MBR values are sent to the RNC in RAB assignment request and in Activate Accept to UE.
QoS Handling During Secondary PDP Activation
QoS Handling When EPS Subscription is Available
- The Requested QoS is mapped to EPC QoS and sent in the Bearer Resource Command to the SGW or PGW.
- If the traffic class requested is a non-GBR traffic class (interactive / background), the per bearer MBR / GBR values sent in Bearer Resource Command will all be zeroes.
- The PGW sends a Create Bearer Request to the SGW or SGSN.
- The SGSN sends a RAB assignment request to the RNC by mapping QoS as follows:
- If the bearer is a non-GBR: The APN-AMBR is mapped to MBR values and GBR is set to "0".
- If the bearer is GBR: The MBR / GBR values received in Create Bearer Request are sent to RNC / UE in the Secondary Activate Accept.
QoS Handling When Only GPRS Subscription is Available
- The Requested QoS from the UE and the Subscribed QoS are negotiated. The SGSN chooses the least of the two values as the negotiated output. If the Requested QoS is mentioned as the Subscribed QoS, then the SGSN chooses the Subscribed QoS as is, if local QoS capping is not configured.
- The Requested QoS is mapped to the EPC QoS and sent in the Bearer Resource Command to the SGW or PGW.
- If the traffic class requested is a non-GBR traffic class (interactive / background), the per bearer MBR / GBR values sent in Bearer Resource Command will be all zeroes.
- The PGW sends a Create Bearer Request to SGW or SGSN.
- The SGSN sends a RAB assignment request to the RNC by mapping QoS as follows:
- If the bearer is non-GBR: The APN-AMBR is mapped to MBR values and the GBR value is set to "0".
- If the bearer is GBR: The MBR / GBR values received in the Create Bearer Request will be sent to RNC / UE in Secondary Activate Accept.
MS Initiated QoS Modification
- The MS sends a Modify PDP Context Request (TI, QoS Requested, TFT, and Protocol Configuration Options) message to the SGSN. Either QoS Requested or TFT or both may be included. The QoS Requested indicates the desired QoS profile, while the TFT indicates the TFT that is to be added or modified or deleted from the PDP context. Protocol Configuration Options may be used to transfer optional PDP parameters and/or requests to the PGW.
- The SGSN identifies the bearer modification scenario that applies and sends the Bearer Resource Command (TEID, LBI, PTI, EPS Bearer QoS (excluding ARP), TFT, EBI, RAT type, Protocol Configuration Options, serving network identity, CGI/SAI, User CSG Information, MS Info Change Reporting support indication, DL TEID and DL Address, DTI) message to the selected Serving GW.
- An S4-based SGSN applies the BCM 'MS/NW' whenever the S4 is selected for a certain MS. The following table list the details of MS-initiated EPS bearer modification, MS/NW mode:
Table 1. MS-initiated EPS bearer modification, MS/NW mode
Sl No. PDP context modification use case Information provided by SGSN at S4 signaling 1. Add TFT filters and increase QoS QoS related to EPS Bearer, TFT filters added, TEID, EPS Bearer ID 2. Increase of QoS related to one or more TFT filter(s) QoS related to EPS Bearer filters, Impacted TFT filters, TEID, EPS Bearer ID 3. Increase of QoS, TFT filters not specified Not allowed in MS/NW mode 4. Add/remove TFT filters, no QoS change TFT filters added/removed, TEID, EPS Bearer ID 5. Decrease QoS related to one or more TFT filter(s) QoS related to EPS Bearer filters, Impacted TFT filters, TEID, EPS Bearer ID 6. Remove TFT filters and decrease QoS QoS related to EPS Bearer, TFT filters removed, TEID, EPS Bearer ID 7. Decrease of QoS, TFT filters not specified Not allowed in MS/NW mode Note: Only the modified QCI and/or GBR parameters are forwarded by the SGSN. - The PDN GW sends an Update Bearer Request (TEID, EPS Bearer Identity, PTI, EPS Bearer QoS, APN-AMBR, TFT, Protocol Configuration Options, Prohibit Payload Compression, MS Info Change Reporting Action, and CSG Information Reporting Action) message to the Serving GW. The Procedure Transaction Id (PTI) parameter is used to link this message to the Request Bearer Resource Modification message received from the Serving GW.
HSS Initiated PDP Context Modification
- The Home Subscriber Server (HSS) initiated PDP context modification procedure is used when the HSS decides to modify the subscribed QoS, where typically QoS related parameters are changed. The parameters that may be modified are UE-AMBR, APN-AMBR QCI and Allocation/Retention Policy.
- The HSS initiates the modification by sending an Insert Subscriber Data (IMSI, Subscription Data) message to the SGSN. The Subscription Data includes EPS subscribed QoS (QCI, ARP) and the subscribed UE-AMBR and APN AMBR.
- The S4-SGSN then updates the stored Subscription Data and acknowledges the Insert Subscriber Data message by returning an Insert Subscriber Data Ack (IMSI) message to the HSS and sends the Modify Bearer Command (EPS Bearer Identity, EPS Bearer QoS, APN AMBR) message to the S-GW. The S-GW forwards the Modify Bearer Command (EPS Bearer Identity, EPS Bearer QoS, APN AMBR) message to the P-GW. Note that the EPS Bearer QoS sent in the Modify Bearer Command does not modify the per bearer bit-rate. It is sent to carry only a change in the ARP / QCI received from subscription. Also, the Modify Bearer Command can be sent only for the default bearer (primary PDP) in a PDN connection.
- The P-GW modifies the default bearer of each PDN connection corresponding to the APN for which subscribed QoS has been modified. If the subscribed ARP parameter has been changed, the P-GW shall also modify all dedicated EPS bearers having the previously subscribed ARP value unless superseded by PCRF decision. The P-GW then sends the Update Bearer Request (EPS Bearer Identity, EPS Bearer QoS [if QoS is changed], TFT, APN AMBR) message to the S-GW.
- The S-GW sends the Update Bearer Request (EPS Bearer Identity, EPS Bearer QoS (if QoS is changed) APN-AMBR, TFT) message to the SGSN. On completion of modification S4-SGSN acknowledges the bearer modification by sending the "Update Bearer Response (EPS Bearer Identity)" message to P-GW via S-GW. If the bearer modification fails, the P-GW deletes the concerned EPS Bearer.
PGW Initiated QoS Modification
- The P-GW sends the Update Bearer Request (TEID, EPS Bearer Identity, EPS Bearer QoS, APN-AMBR, Prohibit Payload Compression, MS Info Change Reporting Action, CSG Information Reporting Action, TFT, and Protocol Configuration Options) message to the S-GW.
- The TFT is optional and included in order to add, modify or delete the TFT related to the PDP Context. Protocol Configuration Options is optional.
ARP Handling
Difference between Gn SGSN and S4 SGSN
In Create PDP Context response the GGSN sends as ARP value whereas the S-GW sends "15" value ARP in Create Session response. In Gn SGSN while sending the RAB assignment request, the Allocation retention priority values are mapped to "15" values so there is need of conversion from "3" values to "15" values.
In S4 SGSN, since the P-GW sends ARP in the "15" value range there is no need for conversion.
ARP values in Gn SGSN
According to GTPv1 3GPP TS 29.060 clause 7.7.34 Allocation/ Retention priority encodes each priority level defined in 3GPP TS 23.107 as the binary value of the priority level.
Quality of Service (QoS) Profile
The Quality of Service (QoS) Profile includes the values of the defined QoS parameters.
Octet "4" carries the Allocation/Retention priority octet that is defined in 3GPP TS 23.107. The Allocation/Retention priority octet encodes each priority level defined in 3GPP TS 23.107 as the binary value of the priority level.
The Allocation/Retention priority field is ignored by the receiver if:
- The QoS profile is pre-Release '99.
- The QoS profile IE is used to encode the Quality of Service Requested (QoS Req) field of the PDP context IE.
Octet "5" the QoS Profile Data Field is coded according to the 3GPP TS 24.008 [5] Quality of Service IE, octets 3-m. The minimum length of the field QoS Profile Data is "3" octets, the maximum length is "254" octets.
The clause 11.1.6 "Error handling" defines the handling of the case when the sent QoS Profile information element has a Length different from the Length expected by the receiving GTP entity.
ARP values in S4 SGSN
The behavior of ARP values in S4 SGSN is according to GTPv2 3GPP TS 29.274 clause 8.15.
Bearer Quality of Service (Bearer QoS)
Bearer Quality of Service (Bearer QoS) is transferred through the GTP tunnels. The sending entity copies the value part of the Bearer l QoS into the Value field of the Bearer QoS IE.
Octet "5" represents the Allocation/Retention Priority (ARP) parameter. The meaning and value range of the parameters within the ARP are defined in 3GPP TS 29.212 [29]. The bits within the ARP octet are:
- Bit 1 - PVI (Pre-emption Vulnerability), see 3GPP TS 29.212[29], clause 5.3.47 Pre-emption-Vulnerability AVP.
- Bit 2 - Spare bit.
- Bits 3 up to 6 - PL (Priority Level), see 3GPP TS 29.212[29], clause 5.3.45 ARP-Value AVP. Priority Level encodes each priority level defined for the ARP-Value AVP as the binary value of the priority level.
- Bit 7 - PCI (Pre-emption Capability), see 3GPP TS 29.212[29], clause 5.3.46 Pre-emption-Capability AVP.
- Bit 8 - Spare bit.
Priority-Level AVP (All access types)
The values "1" up to "15" are defined, with value "1" as the highest level of priority.
Values "1" up to "8" should only be assigned for services that are authorized to receive prioritized treatment within an operator domain. Values "9" up to "15" can be assigned to resources that are authorized by the home network and thus applicable when a UE is roaming.
Pre-emption-Capability AVP
PRE-EMPTION_CAPABILITY_ENABLED (0)
This value indicates that the service data flow or bearer which is allowed to get resources that were already assigned to another service data flow or bearer with a lower priority level.
PRE-EMPTION_CAPABILITY_DISABLED (1)
This value indicates that the service data flow or bearer is not allowed to get resources that were already assigned to another service data flow or bearer with a lower priority level. This is the default value applicable if this AVP is not supplied.
Pre-emption-Vulnerability AVP
PRE-EMPTION_VULNERABILITY_ENABLED (0)
This value indicates that the resources assigned to the service data flow or bearer which can be pre-empted and allocated to a service data flow or bearer with a higher priority level. This is the default value applicable if this AVP is not supplied.
PRE-EMPTION_VULNERABILITY_DISABLED (1)
This value indicates that the resources assigned to the service data flow or bearer which shall not be pre-empted and allocated to a service data flow or bearer with a higher priority.
Handling of ARP Values in Various Scenarios
Gn + GPRS Subscription
The following CLI command is used to send RAB parameters in RAB Assignment request:
config apn-profile profile_name ranap allocation-retention-priority-ie subscription-priority priority class < < background | conversational | interactive | streaming > < not-pre-emptable | priority | queuing-not-allowed | shall-not-trigger-pre-emptable >+ > exitS4 + EPC subscription
For EPC subscription with S4 activation, ARP in RAB is filled from the Evolved ARP applied for the PDP context. The Evolved ARP applied is:
- Subscribed Evolved ARP if P-GW does not send any evolved ARP in Create Session Response.
- Evolved ARP supplied by the P-GW.
S4+GPRS Subscription
For GPRS subscription with S4 activation, the ARP in RAB is filled from the Evolved ARP applied for the PDP context. The Evolved ARP applied is:
- Evolved ARP derived from the GPRS subscription using CLIs displayed below, when the P-GW does not send any Evolved ARP in Create Session Response:
config call-control-profile profile_name qos qos gn-gp < arp high-priority priority medium-priority priority | pre-emption < capability < may-trigger-pre-emption | shall-not-trigger-pre-emption >| vulnerability exit- Evolved ARP supplied by the P-GW.
The Evolved ARP applied is sent in RANAP towards the RNC.
Mapping EPC ARP to RANAP ARP
The ARP values are defined as per 3GPP TS 29.212 clause 5.3.46 and 5.3.47 for the Core Network Side.
The following values are defined:
- PRE-EMPTION_CAPABILITY_ENABLED (0) This value indicates that the service data flow or bearer which is allowed to get resources that were already assigned to another service data flow or bearer with a lower priority level.
- PRE-EMPTION_CAPABILITY_DISABLED (1) This value indicates that the service data flow or bearer which is not allowed to get resources that were already assigned to another service data flow or bearer with a lower priority level. This is the default value applicable if this AVP is not supplied.
- PRE-EMPTION_VULNERABILITY_ENABLED (0) This value indicates that the resources assigned to the service data flow or bearer which can be pre-empted and allocated to a service data flow or bearer with a higher priority level. This is the default value applicable if this AVP is not supplied.
- PRE-EMPTION_VULNERABILITY_DISABLED (1) This value indicates that the resources assigned to the service data flow or bearer which shall not be pre-empted and allocated to a service data flow or bearer with a higher priority level.
For more information on ARP values and their definitions see, 3GPP TS 25.413 clause 9.2.1.3.
The ARP values defined are different on the RNC side and the Core Network side, the RAB assignment request is mapped according to the following table:
RAB parameters (ARP)
ARP values received from SGW (According to 3GPP TS 29.212 clause5.3.46 and 5.3.47)
Mapping EPC ARP to RANAP ARP in RNC side (According to RANAP 3GPP TS 25.413 clause 9.2.1.3)
Pre-emption is triggered.
Pre-emption is not triggered.
Pre-emption is triggered.
Pre-emption is not triggered.
ARP configured in CC Profile
The QoS configured in the Call Control Profile is used if the S4 interface is chosen for PDP activation, but the subscription does not have an EPS subscription. Therefore, GPRS subscription data (which uses QoS in pre-release 8 format), will be mapped to EPS QoS. The Allocation and Retention policy will be mapped to EPS ARP using the configuration in the Call Control Profile.
If the QoS mapping configuration is not used, the following default mappings are used:
- Default ARP high-priority value = 5.
- Default ARP medium-priority value = 10.
- Default pre-emption capability = shall-not-trigger-pre-emption.
- .Default pre-emption vulnerability = not pre-emptable
The mapping is configured through the following CLI command:
config call-control-profile qos qos gn-gp < arp high-priority priority medium-priority priority | pre-emption < capability < may-trigger-pre-emption | shall-not-trigger-pre-emption >| vulnerability exitThe mapping of these configured values to EPC ARP is given in below, this table is present 3GPP TS 23.401:
Release 99 bearer parameter ARP value
EPS bearer ARP priority value
In the above table H = High-priority value configured and M = Medium-priority value.
ARP-RP Mapping for Radio Priority in Messages
The SGSN can choose a preferred radio priority according to the ARP values sent by the GGSN and HLR using the ARP to RP mapping. These mappings will be used by the corresponding 2G and/or 3G services to choose the radio priority value while triggering messages (such as those listed below) towards the MS/UE:
- Activate PDP Accept.
- Modify PDP Request during network-initiated PDP modification procedure.
- Modify PDP Accept during MS-initiated PDP modification procedure provided the ARP has been changed by the network.
In releases prior to 15.0 MR4 ER5, the Radio priority was hardcoded to "4" irrespective of ARP values received by the SGSN from either a GGSN or an HLR.
The following commands are used to create profiles for mapping ARP to RP values and associate the mapping with SGSN (3G) and GPRS (2G) services.
Use the following command in the SGSN Global configuration mode to create an ARP-RP mapping profile:
configure sgsn-global qos-arp-rp-map-profile arp_profile_name no qos-arp-rp-map-profile arp_profile_name end- arp_profile_name - Enter a string of 1 to 64 alphanumeric characters to identify the mapping profile and moves into the ARP-RP mapping profile configuration mode.
- no qos-arp-rp-map-profile - Removes the profile definition from the configuration.
When the ARP-RP mapping profile is created, the default ARP-RP mapping is automatically included (see default values in the Notes section below). This arp command, in the ARP-RP mapping profile configuration mode, modifies the ARP-RP mapping for the profile.
configure sgsn-global qos-arp-rp-map-profile arp_profile_name arparp_value radio-priority rp_value end- arp_value - Defines the allocation retention priority. Enter an integer from 1 to 3.
- rp_value - Defines the radio priority. Enter an integer from 1 to 4.
- Default ARP-RP mapping would be
- ARP1 RP4
- ARP2 RP4
- ARP3 RP4
The radio-priority keyword in the sm commands in both the GPRS-Service and SGSN-Service configuration modes. This keyword is used to associate an ARP-RP mapping profile with a 2G and/or a 3G service.
configure context context_name gprs-service service_name sm radio-priority from-arp arp_profile_name no sm radio-priority from-arp arp_profile_name end- This example illustrates the GPRS Service configuration mode, but either GPRS or SGSN Service configuration modes could be entered. The command sequent would have to be repeated, once for each type of service, to associate the ARP-RP profile with both types of services.
- no sm radio-priority from-arp - This command will remove the association from the configuration.
- Use the show configuration command to display the association.
