4.7 Overall QoS concept

23.4013GPPGeneral Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) accessRelease 18TS

4.7.1 PDN connectivity service

The Evolved Packet System provides connectivity between a UE and a PLMN external packet data network. This is referred to as PDN Connectivity Service.

The IP PDN Connectivity Service supports the transport of traffic flow aggregate(s), consisting of one or more Service Data Flows (SDFs).

NOTE: The concept of SDF is defined in the context of PCC, TS 23.203 [6], and is not explicitly visible in the NAS signalling.

A PDN connection to an SCEF has the following characteristics:

– It is only supported for WB-EUTRA, LTE-M and NB-IoT RAT types;

– It applies only when Control Plane CIoT EPS Optimisation are applicable;

– It does not support the transport of traffic flow aggregate(s);

– It does not support Emergency Services.

4.7.2 The EPS bearer

4.7.2.1 The EPS bearer in general

For E-UTRAN access to the EPC the PDN connectivity service is provided by an EPS bearer for GTP-based S5/S8, and if IP is in use, by an EPS bearer concatenated with IP connectivity between Serving GW and PDN GW for PMIP-based S5/S8.

In this release of the specifications, dedicated bearers are only supported for the IP and Ethernet PDN Connectivity Service.

When User Plane (S1-U) is used for data traffic, then an EPS bearer uniquely identifies traffic flows that receive a common QoS treatment between a UE and a PDN GW for GTP-based S5/S8, and between UE and Serving GW for PMIP-based S5/S8. The packet filters signalled in the NAS procedures are associated with a unique packet filter identifier on per-PDN connection basis.

NOTE 1: The EPS Bearer Identity together with the packet filter identifier is used to reference which packet filter the UE intends to modify or delete, i.e. it is used to implement the unique packet filter identifier.

An EPS bearer is the level of granularity for bearer level QoS control in the EPC/E-UTRAN. That is, all traffic mapped to the same EPS bearer receive the same bearer level packet forwarding treatment (e.g. scheduling policy, queue management policy, rate shaping policy, RLC configuration, etc.). Providing different bearer level packet forwarding treatment requires separate EPS bearers.

NOTE 2: In addition but independent to bearer level QoS control, the PCC framework allows an optional enforcement of service level QoS control on the granularity of SDFs independent of the mapping of SDFs to EPS bearers.

One EPS bearer is established when the UE connects to a PDN, and that remains established throughout the lifetime of the PDN connection to provide the UE with always-on connectivity to that PDN. That bearer is referred to as the default bearer. Any additional EPS bearer that is established for the same PDN connection is referred to as a dedicated bearer.

The EPS bearer traffic flow template (TFT) is the set of all packet filters associated with that EPS bearer. An UpLink Traffic Flow Template (UL TFT) is the set of uplink packet filters in a TFT. A DownLink Traffic Flow Template (DL TFT) is the set of downlink packet filters in a TFT. Every dedicated EPS bearer is associated with a TFT. A TFT may be also assigned to the default EPS bearer. The UE uses the UL TFT for mapping traffic to an EPS bearer in the uplink direction. The PCEF (for GTP-based S5/S8) or the BBERF (for PMIP-based S5/S8) uses the DL TFT for mapping traffic to an EPS bearer in the downlink direction. The UE may use the UL TFT and DL TFT to associate EPS Bearer Activation or Modification procedures to an application and to traffic flow aggregates of the application. Therefore the PDN GW shall, in the Create Dedicated Bearer Request and the Update Bearer Request messages, provide all available traffic flow description information (e.g. source and destination IP address and port numbers and the protocol information).

For the UE, the evaluation precedence order of the packet filters making up the UL TFTs is signalled from the P‑GW to the UE as part of any appropriate TFT operations.

NOTE 3: The evaluation precedence index of the packet filters associated with the default bearer, in relation to those associated with the dedicated bearers, is up to operator configuration. It is possible to "force" certain traffic onto the default bearer by setting the evaluation precedence index of the corresponding filters to a value that is lower than the values used for filters associated with the dedicated bearers.

Further details about the TFT and the TFT operations are described in clause 15.3 of TS 23.060 [7]. The details about the TFT packet filter(s) are described in clause 15.3.2 of TS 23.060 [7] for PDN connections of IP type and in clause 5.7.6.3 of TS 23.501 [83] for PDN connections of Ethernet type.

A TFT of an uplink unidirectional EPS bearer is only associated with UL packet filter(s) that matches the uplink unidirectional traffic flow(s) A TFT of a downlink unidirectional EPS bearer is associated with DL packet filter(s) that matches the unidirectional traffic flow(s) and a UL packet filter that effectively disallows any useful packet flows (see clause 15.3.3.4 in TS 23.060 [7] for an example of such packet filter.

The UE routes uplink packets to the different EPS bearers based on uplink packet filters in the TFTs assigned to these EPS bearers. The UE evaluates for a match, first the uplink packet filter amongst all TFTs that has the lowest evaluation precedence index and, if no match is found, proceeds with the evaluation of uplink packet filters in increasing order of their evaluation precedence index. This procedure shall be executed until a match is found or all uplink packet filters have been evaluated. If a match is found, the uplink data packet is transmitted on the EPS bearer that is associated with the TFT of the matching uplink packet filter. If no match is found, the uplink data packet shall be sent via the EPS bearer that has not been assigned any uplink packet filter. If all EPS bearers (including the default EPS bearer for that PDN) have been assigned one or more uplink packet filters, the UE shall discard the uplink data packet.

NOTE 4: The above algorithm implies that there is at most one EPS bearer without any uplink packet filter. Therefore, some UEs may expect that during the lifetime of a PDN connection (where only network has provided TFT packet filters) at most one EPS bearer exists without any uplink packet filter.

To ensure that at most one EPS bearer exists without any uplink packet filter, the PCEF (for GTP-based S5/S8) or the BBERF (for PMIP-based S5/S8) maintains a valid state for the TFT settings of the PDN connection as defined in clause 15.3.0 of TS 23.060 [7] and if necessary, adds a packet filter which effectively disallows any useful packet flows in uplink direction (see clause 15.3.3.4 in TS 23.060 [7] for an example of such a packet filter) to the TFT of a dedicated bearer.

NOTE 5: The default bearer is the only bearer that may be without any uplink packet filter and thus, a packet filter which effectively disallows any useful packet flows in uplink direction will not be added by the PCEF/BBERF.

The initial bearer level QoS parameter values of the default bearer are assigned by the network, based on subscription data (in E-UTRAN the MME sets those initial values based on subscription data retrieved from HSS).

In a non-roaming scenario, the PCEF may change the QoS parameter value received from the MME based on interaction with the PCRF or based on local configuration. When the PCEF changes those values, the MME shall use the bearer level QoS parameter values received on the S11 reference point during establishment or modification of the default bearer.

In a roaming scenario, based on local configuration, the MME may downgrade the ARP or APN-AMBR and/or remap QCI parameter values received from HSS to the value locally configured in MME (e.g. when the values received from HSS do not comply with services provided by the visited PLMN). The PCEF may change the QoS parameter values received from the MME based on interaction with the PCRF or based on local configuration. Alternatively, the PCEF may reject the bearer establishment.

NOTE 6: For certain APNs (e.g. the IMS APN defined by the GSMA) the QCI value is strictly defined and therefore remapping of QCI is not permitted.

NOTE 7: In roaming scenarios, the ARP/APN-AMBR/QCI values provided by the MME for a default bearer may deviate from the subscribed values depending on the roaming agreement. If the PCC/PCEF rejects the establishment of the default bearer, this implies that Attach via E-UTRAN will fail. Similarly, if the PCEF (based on interaction with the PCRF or based on local configuration) upgrades the ARP/APN-AMBR/QCI parameter values received from the MME, the default bearer establishment and attach may be rejected by the MME.

NOTE 8: Subscription data related to bearer level QoS parameter values retrieved from the HSS are not applicable for dedicated bearers.

For WB-E-UTRA, the decision to establish or modify a dedicated bearer can only be taken by the EPC, and the bearer level QoS parameter values are always assigned by the EPC.

Dedicated bearers are not supported over NB-IoT. The PDN GW uses the RAT Type to ensure that no dedicated bearers are active when the UE is accessing over NB-IoT. In the case of inter-RAT mobility from WB-EUTRA to NB-IoT, the UE and MME indicate local deactivation of non-default EPS bearers at TAU as specified in TS 24.301 [46].

The MME shall not modify the bearer level QoS parameter values received on the S11 reference point during establishment or modification of a default or dedicated bearer (except when the conditions described in NOTE 9 or NOTE 10 apply). Consequently, "QoS negotiation" between the E-UTRAN and the EPC during default or dedicated bearer establishment / modification is not supported. Based on local configuration, the MME may reject the establishment or modification of a default or dedicated bearer if the bearer level QoS parameter values sent by the PCEF over a GTP based S8 roaming interface do not comply with a roaming agreement.

NOTE 9: If the EPS QoS parameters are not compliant with the roaming agreement, the MME, based on local policies, can downgrade the ARP priority level, ARP pre-emption capability, ARP pre-emption vulnerability, APN-AMBR or MBR (for GBR bearers) parameters received over S8 and allow the bearer establishment or modification of a default or dedicated bearer. The HPLMN is expected to set EPS QoS parameters compliant with roaming agreements, therefore the HPLMN is not informed about any downgrade of EPS bearer QoS parameters. The consequences of such a downgrading APN-AMBR and MBR are that APN-AMBR and MBR enforcement at the HPLMN and at the UE will not be aligned. The consequence of downgrading the ARP is that the EPS bearer ARP at the HPLMN and at the eNodeB will not be aligned, and multiple EPS bearers created can possibly have the same EPS bearer ARP in the eNodeB.

NOTE 10: In roaming scenarios, for IMS voice service (e.g. the IMS APN defined by the GSMA), the MME, based on local policy, can override the ARP (i.e. ARP priority level, ARP pre-emption capability, ARP pre-emption vulnerability) received over S8 if the ARP indicates lower priority than the local policy. The purpose of ARP override in the serving PLMN is to apply the same allocation and retention priority for IMS voice service for all users (i.e. roamers and non-roamers) and to apply the same allocation and retention priority for all MPS service users (clause 4.3.18) when roaming agreements are in place and where regulatory requirements apply.

At inter-RAT mobility, based on local configuration, the MME may perform a mapping of QCI values for which there is no mapping defined in Table E.3 or which are not supported in the target RAT.

NOTE 11: The PCRF ensures that the EPS bearer QCI values are aligned with the QCI values mapped by the MME for the current RAT as described in clause A.4.1.2 of TS 23.203 [6].

The distinction between default and dedicated bearers should be transparent to the access network (e.g. E-UTRAN).

An EPS bearer is referred to as a GBR bearer if dedicated network resources related to a Guaranteed Bit Rate (GBR) value that is associated with the EPS bearer are permanently allocated (e.g. by an admission control function in the eNodeB) at bearer establishment/modification. Otherwise, an EPS bearer is referred to as a Non-GBR bearer.

NOTE 12: Admission control can be performed at establishment / modification of a Non-GBR bearer even though a Non-GBR bearer is not associated with a GBR value.

A dedicated bearer can either be a GBR or a Non-GBR bearer. A default bearer shall be a Non-GBR bearer.

NOTE 13: A default bearer provides the UE with connectivity throughout the lifetime of the PDN connection. That motivates the restriction of a default bearer to bearer type Non-GBR.

4.7.2.2 The EPS bearer with GTP-based S5/S8

Figure 4.7.2.2-1: Two Unicast EPS bearers (GTP-based S5/S8)

An EPS bearer is realized by the following elements:

– In the UE, the UL TFT maps a traffic flow aggregate to an EPS bearer in the uplink direction;

– In the PDN GW, the DL TFT maps a traffic flow aggregate to an EPS bearer in the downlink direction;

– A radio bearer (defined in TS 36.300 [5]) transports the packets of an EPS bearer between a UE and an eNodeB. If a radio bearer exists, there is a one-to-one mapping between an EPS bearer and this radio bearer;

– An S1 bearer transports the packets of an EPS bearer between an eNodeB and a Serving GW;

– An E-RAB (E-UTRAN Radio Access Bearer) refers to the concatenation of an S1 bearer and the corresponding radio bearer, as defined in TS 36.300 [5].

– An S5/S8 bearer transports the packets of an EPS bearer between a Serving GW and a PDN GW;

– A UE stores a mapping between an uplink packet filter and a radio bearer to create the mapping between a traffic flow aggregate and a radio bearer in the uplink;

– A PDN GW stores a mapping between a downlink packet filter and an S5/S8 bearer to create the mapping between a traffic flow aggregate and an S5/S8 bearer in the downlink;

– An eNodeB stores a one-to-one mapping between a radio bearer and an S1 Bearer to create the mapping between a radio bearer and an S1 bearer in both the uplink and downlink;

– A Serving GW stores a one-to-one mapping between an S1 Bearer and an S5/S8 bearer to create the mapping between an S1 bearer and an S5/S8 bearer in both the uplink and downlink.

The PDN GW routes downlink packets to the different EPS bearers based on the downlink packet filters in the TFTs assigned to the EPS bearers in the PDN connection. Upon reception of a downlink data packet, the PDN GW evaluates for a match, first the downlink packet filter that has the lowest evaluation precedence index and, if no match is found, proceeds with the evaluation of downlink packet filters in increasing order of their evaluation precedence index. This procedure shall be executed until a match is found, in which case the downlink data packet is tunnelled to the Serving GW on the EPS bearer that is associated with the TFT of the matching downlink packet filter. If no match is found, the downlink data packet shall be sent via the EPS bearer that does not have any TFT assigned. If all EPS bearers (including the default EPS bearer for that PDN) have been assigned a TFT, the PDN GW shall discard the downlink data packet.

4.7.2.3 The EPS bearer with PMIP-based S5/S8

See clause 4.10.3 in TS 23.402 [2].

4.7.3 Bearer level QoS parameters

The EPS bearer QoS profile includes the parameters QCI, ARP, GBR and MBR, described in this clause. This clause also describes QoS parameters which are applied to an aggregated set of EPS Bearers: APN‑AMBR and UE‑AMBR.

Each EPS bearer (GBR and Non-GBR) is associated with the following bearer level QoS parameters:

– QoS Class Identifier (QCI);

– Allocation and Retention Priority (ARP).

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 in TS 23.203 [6].

NOTE 1: On the radio interface and on S1, each PDU (e.g. RLC PDU or GTP-U PDU) is indirectly associated with one QCI via the bearer identifier carried in the PDU header. The same applies to the S5 and S8 interfaces if they are based on GTP.

NOTE 2: When required by operator policy, the eNodeB can be configured to also use the ARP priority level in addition to the QCI to control bearer level packet forwarding treatment in the eNodeB for SDFs having high priority ARPs.

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). The priority level information of the ARP is used for this decision to ensure that the request of the bearer with the higher priority level is preferred. In addition, the ARP can be used (e.g. by the eNodeB) to decide which bearer(s) to drop during exceptional resource limitations (e.g. at handover). The pre-emption capability information of the ARP defines whether a bearer with a lower ARP priority level should be dropped to free up the required resources. The pre-emption vulnerability information of the ARP defines whether a bearer is applicable for such dropping by a pre-emption capable bearer with a higher ARP priority level.

Once a bearer has been successfully established, the packet handling (e.g. scheduling and rate control) within the eNodeB, PDN GW, and Serving GW should be solely determined by the following EPS bearer QoS parameters: QCI, GBR and MBR, and by the AMBR parameters. However, when required by operator policy, the eNodeB can be configured to also use a bearer’s ARP priority level in addition to the QCI to determine the relative priority of the SDFs for packet handling (e.g. scheduling and rate control) in the eNodeB as defined in TS 23.203 [6] clause 6.1.7.2. This configuration applies only for bearers with high priority ARPs as defined in TS 23.203 [6] clause 6.1.7.3.

The ARP priority level may be used in addition to the QCI to determine the transport level packet marking, e.g. to set the DiffServ Code Point. The ARP is not included within the EPS QoS Profile sent to the UE.

NOTE 3: The ARP should be understood as "Priority of Allocation and Retention"; not as "Allocation, Retention, and Priority".

NOTE 4: Video telephony is one use case where it may be beneficial to use EPS bearers with different ARP values for the same UE. In this use case an operator could map voice to one bearer with a higher ARP, and video to another bearer with a lower ARP. In a congestion situation (e.g. cell edge) the eNodeB can then drop the "video bearer" without affecting the "voice bearer". This would improve service continuity.

NOTE 5: The ARP may also be used to free up capacity in exceptional situations, e.g. a disaster situation. In such a case the eNodeB may drop bearers with a lower ARP priority level to free up capacity if the pre-emption vulnerability information allows this.

Each GBR bearer is additionally associated with the following bearer level QoS parameters:

– Guaranteed Bit Rate (GBR);

– Maximum Bit Rate (MBR).

The GBR denotes the bit rate that can be expected to be provided by a GBR bearer. The MBR limits the bit rate that can be expected to be provided by a GBR bearer (e.g. excess traffic may get discarded by a rate shaping function). See clause 4.7.4 for further details on GBR and MBR.

GBR bearers are not supported by NB-IoT. The PDN GW uses the RAT Type to ensure that GBR bearers are not active when the UE is using NB-IoT.

Each APN access, by a UE, is associated with the following QoS parameter:

– per APN Aggregate Maximum Bit Rate (APN-AMBR).

The subscribed APN‑AMBR is a subscription parameter stored per APN in the HSS, which applies as APN-AMBR unless the APN-AMBR is modified by the MME (e.g in roaming scenarios and/or for usage of NB-IoT) or the PDN GW, based on local policy (e.g. for RAT Type = NB-IoT) or PCRF interactions. The APN-AMBR limits the aggregate bit rate that can be expected to be provided across all Non‑GBR bearers and across all PDN connections of the same APN (e.g. excess traffic may get discarded by a rate shaping function). 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. GBR bearers are outside the scope of APN‑AMBR. The P‑GW enforces the APN‑AMBR in downlink. Enforcement of APN‑AMBR in uplink is done in the UE and additionally in the P‑GW.

NOTE 6: All simultaneous active PDN connections of a UE that are associated with the same APN shall be provided by the same PDN GW (see clauses 4.3.8.1 and 5.10.1).

APN-AMBR applies to all PDN connections of an APN. For the case of multiple PDN connections of an APN, if a change of APN-AMBR occurs due to local policy or the PDN GW is provided the updated APN-AMBR for each PDN connection from the MME or PCRF, the PDN GW initiates explicit signalling for each PDN connection to update the APN-AMBR value.

Each UE in state EMM-REGISTERED is associated with the following bearer aggregate level QoS parameter:

– per UE Aggregate Maximum Bit Rate (UE-AMBR).

The UE‑AMBR is limited by a subscription parameter stored in the HSS. The MME shall set the UE‑AMBR to the sum of the APN‑AMBR of all active APNs 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). Each of those Non‑GBR bearers could potentially utilize the entire UE‑AMBR, e.g. when the other Non‑GBR bearers do not carry any traffic. GBR bearers are outside the scope of UE AMBR. The E‑UTRAN enforces the UE‑AMBR in uplink and downlink except for PDN connections using the Control Plane CIoT EPS Optimisation.

The GBR and MBR denote bit rates of traffic per bearer while UE-AMBR/APN-AMBR denote bit rates of traffic per group of bearers. Each of those QoS parameters has an uplink and a downlink component. On S1_MME the values of the GBR, MBR, and AMBR refer to the bit stream excluding the GTP-U/IP header overhead of the tunnel on S1_U.

The HSS defines, for each PDN subscription context, the ‘EPS subscribed QoS profile’ which contains the bearer level QoS parameter values for the default bearer (QCI and ARP) and the subscribed APN-AMBR value. The subscribed ARP shall be used to set the priority level of the EPS bearer parameter ARP for the default bearer while the pre-emption capability and the pre-emption vulnerability information for the default bearer are set based on MME operator policy. In addition, the subscribed ARP shall be applied by the P-GW for setting the ARP priority level of all dedicated EPS bearers of the same PDN connection unless a different ARP priority level setting is required (due to P-GW configuration or interaction with the PCRF).

NOTE 7: The ARP parameter of the EPS bearer can be modified by the P‑GW (e.g. based on interaction with the PCRF due to e.g. MPS user initiated session) to assign the appropriate pre-emption capability and the pre-emption vulnerability setting.

The ARP pre-emption vulnerability of the default bearer should be set appropriately to minimize the risk of unnecessary release of the default bearer.

4.7.4 Support for Application / Service Layer Rate Adaptation

The E‑UTRAN/UTRAN and the UE support the RFC 3168 [55] Explicit Congestion Notification (ECN), as described in TS 36.300 [5], TS 25.401 [16] and TS 26.114 [56]. The IP level ECN scheme enables the E‑UTRAN/UTRAN to trigger a rate adaptation scheme at the application / service / transport layer. To make sufficient time available for end-to-end codec rate adaptation the E-UTRAN/UTRAN should attempt to not drop any packets on a bearer for a default grace period of at least 500 ms after it has indicated congestion with ECN on the bearer for packets within the packet delay budget. During this ECN grace period the E-UTRAN/UTRAN should also attempt to meet the QCI characteristics / QoS class associated with the bearer.

NOTE 1: Note that the receiving end-point should interpret all ECN-CE signals received within one end-to-end round-trip time as one "congestion event" (see IETF RFC 3168 [55] and TS 26.114 [56]).

The MBR of a particular GBR bearer may be set larger than the GBR.

NOTE 2: Enforcement of APN-AMBR / UE-AMBR is independent of whether the MBR of a particular GBR bearer has been set larger than the GBR (see clause 4.7.3).

The EPC does not support E-UTRAN/UTRAN-initiated "QoS re-negotiation". That is, the EPC does not support an eNodeB/RNC initiated bearer modification procedure. If an eNodeB/RNC can no longer sustain the GBR of an active GBR bearer then the eNodeB/RNC should simply trigger a deactivation of that bearer.

4.7.5 Application of PCC in the Evolved Packet System

The Evolved Packet System applies the PCC framework as defined in TS 23.203 [6] for QoS policy and charging control. PCC functionality is present in the AF, PCEF and PCRF.

An EPS needs to support both PCEF and PCRF functionality to enable dynamic policy and charging control by means of installation of PCC rules based on user and service dimensions. However, an EPS may only support PCEF functionality in which case it shall support static policy and charging control.

NOTE: The local configuration of PCEF static policy and charging control functionality is not subject to standardization. The PCEF static policy and control functionality is not based on subscription information.

The following applies to the use of dynamic policy and charging control in EPS:

– The service level (per SDF) QoS parameters are conveyed in PCC rules (one PCC rule per SDF) over the Gx reference point. The service level QoS parameters consist of a QoS Class Identifier (QCI) Allocation and Retention Priority (ARP) and authorised Guaranteed and Maximum Bit Rate values for uplink and downlink. The QCI is a scalar that represents the QoS characteristics that the EPS is expected to provide for the SDF. ARP is an indicator of the priority for the SDF that is used to decide about the assignment of resources due to resource limitations. The service level ARP assigned by PCRF in a PCC rule may be different from the bearer level ARP stored in subscription data;

– The set of standardized QCIs and their characteristics that the PCRF in an EPS can select from is provided in TS 23.203 [6]. It is expected that the PCRF selects a QCI in such a way that the IP-CAN receiving it can support it;

– It is not required that an IP-CAN supports all standardized QCIs;

– In the case of IP address configuration subsequent to initial attachment, i.e. through DHCP mechanism to complete the IP address configuration, the PDN GW/PCEF shall notify the PCRF of the UE’s IP address by means of an IP-CAN Session Modification procedure or IP-CAN Session Establishment procedure as defined in TS 23.203 [6] when it is assigned. If the PCRF response leads to an EPS bearer modification the PDN GW should initiate a bearer update procedure;

– For local breakout, the visited network has the capability to reject the QoS authorized by the home network based on operator policies.

The following applies regardless of whether dynamic or static policy and charging control is used in EPS:

– For E-UTRAN the value of the ARP of an EPS bearer is identical to the value of the ARP of the SDF(s) mapped to that EPS bearer;

– For the same UE/PDN connection: SDFs associated with different QCIs or with the same service-level QCI but different ARP shall not be mapped to the same EPS bearer;

– The bearer level QCI of an EPS bearer is identical to the value of the QCI of the SDF(s) mapped to that EPS bearer.

4.7.6 Bearer Control Mode in EPC

The Bearer Control Mode (BCM) for E-UTRAN access is always UE/NW. Hence, explicit signalling between the UE and the network to determine BCM for E-UTRAN access does not occur.

GERAN/UTRAN/E-UTRAN capable UEs negotiate the BCM of a PDN Connection applicable for GERAN/UTRAN access during E-UTRAN Initial Attach and during UE Requested PDN Connectivity procedure. Such UEs provide the Network Request Support UE (NRSU) parameter to the PDN GW in PCO. The PDN GW derives the BCM applicable to GERAN/UTRAN access based on the NRSU and operator policy. The selected BCM, valid for GERAN/UTRAN, is provided back to the UE in PCO IE in the E-UTRAN Attach Accept or PDN Connectivity Accept message. The selected BCM is also stored in the PDN GW and the UE, and applied by UE upon moving to GERAN or UTRAN access unless explicitly informed by PDN GW of a change in BCM (see TS 23.060 [7]) via PCO IE.

NOTE 1: In Rel‑8 it was not mandatory for GERAN/UTRAN/E-UTRAN capable UEs to provide NRSU to the PDN GW during E-UTRAN Initial Attach and UE Requested PDN Connectivity procedure.

When a GERAN/UTRAN/E-UTRAN capable UE moves from UTRAN or GERAN access to E-UTRAN access, it stores the BCM used in UTRAN or GERAN access to be used again when the UE moves back to UTRAN or GERAN access unless explicitly informed by PDN GW of a change in BCM (see TS 23.060 [7]) via the PCO IE.

If PCC is deployed, the PDN GW requests PCRF to perform BCM selection for the RAT the UE is accessing at IP‑CAN session establishment and IP-CAN session modification. The PCRF, determines the applicable BCM, based on a number of factors (see TS 23.203 [6]), and informs the PDN GW. If the BCM has changed, the PDN GW informs the UE of the new BCM via the PCO IE.

4.7.7 Support of rate control of user data using CIoT EPS Optimisation

4.7.7.1 General

The rate of user data sent to and from a UE (e.g. a UE using CIoT EPS Optimisations) can be controlled in two different ways:

– Serving PLMN Rate Control

– APN Rate Control

Serving PLMN Rate Control is intended to allow the Serving PLMN to protect its MME and the Signalling Radio Bearers in the E-UTRAN from the load generated by NAS Data PDUs.

APN Rate Control is intended to allow HPLMN operators to offer customer services such as "maximum of Y messages per day".

NOTE: Existing AMBR mechanisms are not suitable for such a service since, for radio efficiency and UE battery life reasons, an AMBR of e.g. > 100kbit/s is desirable and such an AMBR translates to a potentially large daily data volume.

The PDN GW in the visited PLMN may send the APN rate control parameter for an emergency PDN connection.

4.7.7.2 Serving PLMN Rate Control

The Serving PLMN Rate Control value is configured in the MME.

NOTE 1: Homogeneous support of Serving PLMN Rate Control in a network is assumed.

At PDN connection establishment, the MME may inform the UE and PDN GW/SCEF (as specified in TS 24.301 [46] and TS 29.274 [43]) of any per PDN connection local Serving PLMN Rate Control that the Serving PLMN intends to enforce for NAS Data PDUs. The MME shall only indicate Serving PLMN Rate Control command to the PDN GW if the PDN connection is using S11-U and set to Control Plane only. The MME shall only indicate Serving PLMN Rate Control command to the SCEF if that PDN connection is using SCEF.

This rate control is operator configurable and expressed as "X NAS Data PDUs per deci hour" where X is an integer that shall not be less than 10. There are separate limits for uplink and downlink NAS Data PDUs:

– The UE shall limit the rate at which it generates uplink NAS Data PDUs to comply with the Serving PLMN policy. In the UE the indicated rate control applies only on the PDN connection where it was received, and therefore the UE shall limit the rate of its uplink NAS Data PDUs to comply with the rate that is indicated for the PDN connection. The indicated rate is valid until the PDN connection is released.

– The PDN GW/SCEF shall limit the rate at which it generates downlink Data PDUs. In the PDN GW/SCEF the indicated rate control applies only on the PDN connection where it was received, and therefore the PDN GW/SCEF shall limit the rate of its downlink Data PDUs to comply with the rate that is indicated for the PDN connection.

– The MME may enforce these limits per PDN connection by discarding or delaying packets that exceed this these limits. The Serving PLMN Rate does not include SMS sent via NAS Transport PDUs. The MME starts the Serving PLMN Rate Control when the first NAS Data PDU is received.

NOTE 2: If the UE/PDN GW/SCEF start the Serving PLMN rate control at a different time than the MME, PDUs sent within the limit enforced at the UE/PDN GW/SCEF can still exceed the limit enforced by the MME.

NOTE 3 It is assumed that the Serving PLMN Rate is sufficiently high to not interfere with the APN Rate Control as the APN Rate Control, if used, is assumed to allow fewer messages. NAS PDUs related to exception reports are not subject to the Serving PLMN Rate Control.

4.7.7.3 APN Rate Control

The APN Rate Control is configured in the PDN GW or in the SCEF. The PDN GW or SCEF can send an APN Uplink Rate Control command to the UE using the PCO information element.

The APN Uplink Rate Control applies to data PDUs sent on that APN by either Data Radio Bearers (S1-U) or Signalling Radio Bearers (NAS Data PDUs).

The rate control information is separate for uplink and downlink and in the form of:

– a positive integer ‘number of packets per time unit’, and

– an indication as to whether or not exception reports can still be sent if this rate control limit has been met, and

– if the UE indicated support for it, an integer ‘number of additional allowed exception report packets per time unit’ once the rate control limit has been reached.

UEs supporting APN Rate Control shall support the ‘number of additional allowed exception report packets per time unit’ and shall provide an indication to the CN at PDN connection establishment.

NOTE 1: Pre-Rel‑14 UEs do not support the ‘number of additional allowed exception report packets per time unit’ and do not send an indication to the CN at PDN connection establishment.

The UE shall comply with this uplink rate control instruction. If the UE exceeds the uplink ‘number of packets per time unit’, the UE may still send uplink exception reports if allowed and the ‘number of additional allowed exception reports per time unit’ has not been exceeded. The UE shall consider this rate control instruction as valid until it receives a new one from either PDN GW or from SCEF.

When the last PDN connection using a given APN is released, the APN Rate Control Status (including the number of packets still allowed in the given time unit, the number of additional exception reports still allowed in the given time unit and the termination time of the current APN Rate Control validity period) may be stored in the MME so that it can be retrieved for a subsequent re-establishment of a new first PDN connection for that given APN.

At subsequent establishment of a new first PDN connection for that given APN, the PDN GW/SCEF may receive the previously stored APN Rate Control Status and, if the first APN Rate Control validity period has not expired, it applies the received APN Rate Control Status and provides the related parameters to the UE in the PCO (instead of the configured APN Rate Control parameters). If the initially applied parameters differ from the configured APN Rate Control parameters, the PDN GW/SCEF uses the configured APN Rate Control parameters once the first APN Rate Control validity period expires, and sends an update to the UE with the configured APN Rate Control parameters.

NOTE 2: The storage of the APN Rate Control Status information for very long time intervals can be implementation specific.

The PDN GW or SCEF realises the APN rate control based on a ‘maximum allowed rate’ per direction. If PDN GW or SCEF provided the ‘number of additional allowed exception report packets per time unit’ to the UE, then the ‘maximum allowed rate’ is equal to the ‘number of packets per time unit’ plus the ‘number of additional allowed exception report packets per time unit’. Otherwise, the ‘maximum allowed rate’ is equal to the ‘number of packets per time unit’.

NOTE 3: Pre-Rel‑14 UEs understand only the ‘number of packets per time unit’, and, if an indication that exception reports are allowed has been sent to such UEs, there is a risk that exception report packets are discarded by the PDN GW or SCEF. To overcome this problem, the PDN GW or SCEF can still apply a configured ‘number of additional allowed exception report packets per time unit’ even though not sent to pre-Rel‑14 UEs.

The PDN GW or SCEF may enforce the uplink rate by discarding or delaying packets that exceed the ‘maximum allowed rate’. The PDN GW or SCEF shall enforce the downlink rate by discarding or delaying packets that exceed the downlink part of the ‘maximum allowed rate’.

NOTE 4: It is assumed that the Serving PLMN Rate is sufficiently high to not interfere with the APN Rate Control as the APN Rate Control, if used, is assumed to allow fewer messages. NAS PDUs related to exception reports are not subject to the Serving PLMN Rate Control.

4.7.8 Inter-UE QoS for NB-IoT UEs using Control Plane CIoT EPS Optimisation

To allow the E-UTRAN to prioritise resource allocation between different NB-IoT UEs when some of the UEs are using the Control Plane CIoT EPS Optimisation, the eNodeB may request, based on configuration, the MME to supply the eNodeB with the negotiated QoS profile for any UE that is using the Control Plane CIoT EPS Optimisation.

The QoS profile sent to the eNodeB by the MME consists of the E-RAB Level QoS Parameter in the E-RAB to be Setup List IE (see TS 36.413 [36]).

In order to reduce signalling load on the MME, the eNodeB may be configured to request the QoS profile from the MME by using the UE’s S-TMSI as identifier, e.g., when the eNodeB’s NB-IoT load exceeds certain threshold(s) or when the eNodeB needs to cache the QoS profile.

If the UE has more than one EPS bearer active, the MME sends QoS profile for only one EPS bearer to the eNodeB. In this case the MME uses local configuration (e.g. considering table 6.1.7 in TS 23.203 [6], the MME chooses the non-GBR EPS bearer with the QCI corresponding to the highest Priority Level) to determine which EPS bearer’s QoS to send to the eNodeB. If the MME has no EPS bearers active for the UE, then this fact is indicated to the eNodeB.

The eNodeB can use the QoS profile to assist with resource prioritisation decisions between different NB-IoT UEs (irrespective of whether the UE/eNodeB is using the Control Plane CIoT EPS Optimisation, or, the User Plane CIoT EPS Optimisation).