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).
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);
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.
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.
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.
Further details about the TFT and the TFT operations are described in clause 15.3 of TS 23.060. The details about the TFT packet filter(s) are described in clause 15.3.2 of TS 23.060 for PDN connections of IP type and in clause 18.104.22.168 of TS 23.501 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 22.214.171.124 of TS 23.060 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.
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 and if necessary, adds a packet filter which effectively disallows any useful packet flows in uplink direction (see clause 126.96.36.199 of TS 23.060 for an example of such a packet filter) to the TFT of a dedicated bearer.
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.
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.
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.
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.
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.
A dedicated bearer can either be a GBR or a Non-GBR bearer. A default bearer shall be a Non-GBR bearer.
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) 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.
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.
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.
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, clause 188.8.131.52. This configuration applies only for bearers with high priority ARPs as defined in TS 23.203, clause 184.108.40.206.
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.
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.
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).
The ARP pre-emption vulnerability of the default bearer should be set appropriately to minimize the risk of unnecessary release of the default bearer.
The E-UTRAN/UTRAN and the UE support the RFC 3168 Explicit Congestion Notification (ECN), as described in TS 36.300, TS 25.401 and TS 26.114. 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.
The MBR of a particular GBR bearer may be set larger than the GBR.
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.
The Evolved Packet System applies the PCC framework as defined in TS 23.203 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.
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. 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 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.
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) via PCO IE.
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) 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), and informs the PDN GW. If the BCM has changed, the PDN GW informs the UE of the new BCM via the PCO IE.
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".
The PDN GW in the visited PLMN may send the APN rate control parameter for an emergency PDN connection.
The Serving PLMN Rate Control value is configured in the MME.
At PDN connection establishment, the MME may inform the UE and PDN GW/SCEF (as specified in TS 24.301 and TS 29.274) 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 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.
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.
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.
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'.
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'.
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).
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, 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).
GPRS idle mode mobility within GERAN or UTRAN and also between GERAN and UTRAN specifies a set of sequence number handling functions, e.g. the exchange of sequence numbers during Routing Area Update procedures. EPS idle mode mobility procedures don't specify any such sequence number mappings for IRAT mobility scenarios. To avoid interoperation issues a network that deploys E-UTRAN together with GERAN and/or UTRAN shall not configure usage of the GPRS feature "reordering required" for PDP contexts of PDP type IPv4, IPv6 or IPv4v6. Also the network shall not configure usage of lossless PDCP of UTRAN and the GERAN SGSN shall not configure usage of acknowledged mode LLC/NSAPI/SNDCP.
Paging policy differentiation is an optional feature that allows the MME, based on operator configuration, to apply different paging strategies as defined in clause 220.127.116.11 for different traffic or service types provided within the same PDN connection.
When it supports Paging Policy Differentiation feature, the Serving GW provides a Paging Policy Indication in the Downlink Data Notification. The Paging Policy Indication is based on information received with the downlink packet that triggers the Downlink Data Notification. For example, as defined in TS 23.228, the P-CSCF may support Paging Policy Differentiation by marking packet(s) to be sent towards the UE that relate to specific IMS services (e.g. conversational voice as defined in IMS multimedia telephony service).
The PDN GW shall not modify the received downlink IP packet e.g. the DSCP (IPv4) / TC (IPv6). Unconditionally, for each bearer and for each packet of PDN type IPv4, IPv6 or IPv4v6 that triggers a Downlink Data Notification, the SGW shall send the DSCP in TOS (IPv4) / TC (IPv6) information received in the IP payload of the GTP-U packet from the PDN GW in the Paging Policy Indication in the Downlink Data Notification.
It shall be possible for the operator to configure the MME in such a way that the Paging Policy Indicator only applies to certain HPLMNs and/or APNs and/or QCIs.
CIoT EPS Optimisations provide improved support of small data transfer. One optimisation is based on User Plane transport of user data and is referred to as User Plane CIoT EPS Optimisation. Another optimisation, known as Control Plane CIoT EPS Optimisation, transports user data or SMS messages via MME by encapsulating them in NAS, reducing the total number of control plane messages when handling a short data transaction. For EPC Mobile Originated Location Request (EPC-MO-LR) and EPC Mobile Terminated Location Request (EPC-MT-LR) when the UE and network support Control Plane CIoT EPS Optimisation, Control Plane Service Request is used. These optimisations can be used separately e.g. if the UE or the network supports one of them, or in parallel if the UE and the network supports both. If both the Control Plane and User Plane CIoT EPS Optimisations are supported for a UE, the PDN connections that only use the Control Plane CIoT EPS Optimisation, i.e. the MME has included Control Plane Only Indicator in the ESM request, will only be handled via the Control Plane CIoT EPS Optimisation. All other PDN connections are handled using Control Plane or User Plane CIoT EPS Optimisations. In addition, the Control Plane CIoT Optimisation can be used to support PDN connections to an SCEF, while regular S1-U data transfer is used independently to support PDN connections to P-GW. The MME shall consistently include Control Plane Only Indicator either in all SGi PDN connections of a UE or in none of them. All the SGi PDN connections of a UE shall either use S11-U or S1-U at any point in time.
The CIoT data could include e.g. status information, measurement data from Machine-to-Machine applications.
Several types of MME are envisaged, e.g.
an MME that supports either User Plane or Control Plane CIoT EPS Optimisation;
an MME that supports both User Plane and Control Plane CIoT EPS Optimisations;
an MME that does not support any CIoT EPS Optimisations.
The E-UTRAN shall support the routeing of UEs to an MME that can process the request from the UE.
The CIoT EPS Optimisations are negotiated as described in clause 18.104.22.168"Preferred and Supported Network Behaviour".
CIoT EPS Optimisations may be supported also by UEs that are not limited to low complexity and low throughput applications for Machine Type Communications.
If Control Plane CIoT EPS Optimisation applies, separation of S11-U from S1-U may be required, and if required, the MME and the Serving GW shall handle the IP address and TEID for the S1-U and the address and TEID for the S11-U separately.
The User Plane CIoT EPS Optimisation functionality enables support for transfer of user plane data without the need for using the Service Request procedure to establish Access Stratum (AS) context in the serving eNodeB and UE.
If the following preconditions are met:
UE and MME support User Plane CIOT EPS Optimisation as defined in clause 22.214.171.124,
MME indicates "UE User Plane CIoT Support Indicator" IE to "supported" as defined in TS 36.413,
and the UE performs an initial connection establishment that establishes the AS bearers and the AS security context in the network and UE,
then the RRC connection can be suspended by means of a Connection Suspend Procedure (see clause 5.3.4A).
Based on trigger from the NAS layer when UE is in ECM-IDLE including if it attempts to send data using Control Plane CIoT EPS Optimisation as defined in clause 5.3.4B, the UE shall attempt the Connection Resume procedure, see clause 5.3.5A and TS 24.301. If the Connection Resume procedure fails, the UE initiates the pending NAS procedure, see TS 24.301. To maintain support for User Plane CIoT EPS Optimisation at UE mobility between cells configured on different eNodeBs, the AS Context should be transferred between the eNodeBs, see TS 36.300 and TS 36.423.
Early Data Transfer (EDT) for User Plane CIOT EPS Optimisation is defined in TS 36.300, and clause 5.3.5A.
If the UE is in ECM-IDLE state with AS information stored, and the UE attempts to send data using Control Plane CIoT EPS Optimisation as defined in clause 5.3.4B, the UE shall attempt the Connection Resume procedure without Early Data Transfer.
By using the Connection Suspend procedure, see clause 5.3.5A and TS 36.300:
the UE at transition into ECM-IDLE stores the AS information;
the eNodeB stores the AS information, the S1AP association and the bearer context for that UE;
MME stores the S1AP association and the bearer context for that UE and enters ECM-IDLE.
In the context of this functionality, the UE and the eNodeB store the relevant AS information at transition into ECM-IDLE.
By using the Connection Resume procedure, see clause 5.3.5A and TS 36.300:
the UE resumes the connection with the network using the AS information stored during the Connection Suspend procedure;
the, potentially new, eNodeB notifies the MME that the connection with the UE has been securely resumed and the MME enters ECM-CONNECTED.
If a MME has a S1AP association stored for a UE and the MME receives for that UE a EMM procedure over another UE-associated logical S1-connection or at Tracking Area Update procedure with MME change, or SGSN Context Request, when the UE has re-attached, or when the UE has been Detached, the MME and the previously involved eNodeB shall delete that stored S1AP association using the S1 Release procedure, see clause 5.3.5 and TS 36.413.
A UE attached to WB-E-UTRAN access, including for dual connectivity using E-UTRAN access as described in clause 4.3.2a, may support 8 or 15 EPS bearers. To enable support of establishing 15 EPS bearers, it requires the EPC connected to the E-UTRAN access to support 15 EPS bearers for such UEs.
If the UE supports 15 EPS bearers, then the UE shall indicate this to the MME in NAS signalling as defined in TS 24.301.
The network shall support E-UTRAN idle mode mobility and handover procedures in such PLMNs, where only part of the network nodes have been upgraded to support 15 EPS bearers. In the case of mobility procedures involving target nodes not supporting 15 EPS bearers, additional bearers not supported by the non-upgraded nodes should be thus released.
The network shall homogeneously support 15 EPS bearers per UE, at least per MME pool area/SGW serving area, in order to avoid EPS bearer deactivations and attempts from services to re-activate the deactivated EPS bearers caused by UE mobility within that area, by defining the tracking areas accordingly (see clause 126.96.36.199).
The MME shall provide the UE with a TAI List such that it triggers the UE to perform the TAU procedure, as defined in clause 188.8.131.52, when the UE enters and exits the area with support for 15 EPS bearers per UE. The TAU procedure execution enables the nodes in the supporting area to identify a supporting UE when it enters the area. When exiting the area, also enables the nodes to remove bearer resources for the UE towards nodes without support for 15 EPS bearers per UE.
For a UE supporting 15 EPS bearers, mobility to UTRAN or GERAN may also lead to selective release of EPS bearers, due to the lack of support of 15 PDP contexts in the GPRS core network and Radio Access networks.
In order to minimize the impact from release of bearers not supported by the target nodes during mobility, the MME should be able to allocate the EPS bearer IDs in such way that the bearers with higher operator preference will be preserved in the case of mobility involving legacy target nodes. This prioritised bearer allocation should be based on, at least, the Allocation Retention Priority of the EPS bearers and may take other bearer parameters (e.g. QCI, APN) into consideration.
All PDN GWs in a PLMN shall support 15 EPS bearers. MME may be configured to take into account additional PDN GW information such as whether the HPLMN supports 15 EPS bearers when selecting PDN GW (e.g. in the case of roaming users Home Routed PDN GW selection) for UEs supporting 15 EPS bearers.
For inter-PLMN handover, support of 15 EPS bearers is based on MME configuration according to operator policy (e.g. bilateral agreements between operators).
In the case of satellite access with WB-E-UTRAN, NB-IoT or LTE-M, the RAT Types values "WB-E-UTRAN(LEO)", "WB-E-UTRAN(MEO)", " WB-E-UTRAN(GEO)", " WB-E-UTRAN(OTHERSAT)", "NB-IoT(LEO)", "NB-IoT(MEO)", "NB-IoT(GEO)", "NB-IoT(OTHERSAT)", "LTE-M(LEO)", "LTE-M(MEO)", "LTE-M(GEO)" and "LTE-M(OTHERSAT)" are used in EPC to distinguish the different WB-E-UTRAN, NB-IoT and LTE-M satellite access types.
In order to enable efficient enforcement of mobility restrictions:
Cells of each NB-IoT satellite RAT type (NB-IoT(LEO), NB-IoT(MEO), NB-IoT(GEO) or NB-IoT(OTHERSAT)) need to be deployed in TAs that are:
different from TAs for other NB-IoT satellite RAT types; and
different from TAs supporting terrestrial NB-IoT RAT type; and
different from TAs for WB-E-UTRAN satellite RAT types; and
different from TAs for WB-E-UTRAN terrestrial RAT types.
Network/Access selection principles specified in clause 184.108.40.206 also apply for satellite access for Cellular IoT.
In the case of satellite access for Cellular IoT, a UE with location capability (i.e. GNSS capability) should use its awareness of its location to select a PLMN that is allowed to operate the UE location as specified in TS 23.122.
In order to ensure that regulatory requirements are met, the network may be configured to enforce this UE choice by verifying the UE location as specified in clause 4.13.4.
In order to ensure that the regulatory requirements are met, the network may be configured to enforce that the selected PLMN is allowed to operate in the current UE location by verifying the UE location during EMM and ESM procedures. In this case, when the MME receives the User Location Information (ULI) for a UE using satellite access for Cellular IoT, the MME may decide to verify the UE location.
If the MME determines based on the Selected PLMN ID and the identity of the cell serving this UE that it is not allowed to operate at the present UE location the MME should reject any NAS request with a suitable Cause value. If the UE is already registered to the network when the MME determines that the UE is not allowed to operate at the present UE location, the MME may initiate an explicit detach of the UE. The MME should not reject the request or detach the UE unless it has sufficiently accurate UE location information to determine that the UE is located in a geographical area where the PLMN is not allowed to operate.
If the MME is not able to determine the UE location with sufficient accuracy to make a decision, the MME proceeds with the Mobility Management or Session Management procedure and may initiate UE location procedure after the Mobility Management or Session Management procedure is complete, as specified in clause 9.1.17 of TS 23.271, to determine the UE location. The MME shall be prepared to detach the UE if the information received from the E SMLC indicates that the UE is registered to a PLMN that is not allowed to operate in the UE location. In case of a NAS procedure, the MME should either reject any NAS request targeted towards a PLMN that is not allowed to operate in the known UE location and indicate a suitable cause value, or accept the NAS procedure and initiate the Detach procedure once the UE location is known. In the Detach Request message to the UE, the MME shall include a suitable cause value.
Whenever the UE is accessing the network using a satellite RAT, the MME shall set the NAS timers long enough according to the worst transmission delay (see TS 24.301). For a UE accessing the network using satellite WB-E-UTRAN(GEO) RAT regardless whether CE mode B is used or not for this UE, the MME shall use the extended NAS timer settings for the UE as specified in TS 24.301.
A moving cell for NB-IoT, LTE-M or WB-E-UTRAN satellite access may indicate support for one or more Tracking Areas Codes (TACs) for each PLMN (see clause 4.13.7). A UE that is registered with a PLMN may access a cell and does not need to perform a Tracking Area Update procedure for mobility reasons as long as at least one supported TAC for the RPLMN or equivalent to the RPLMN indicated in the cell is part of the UE's Tracking Area List. A UE shall perform a Tracking Area Update procedure when entering a cell where none of the supported TACs for the RPLMN or equivalent to the RPLMN indicated in the cell are part of the UE's Tracking Area List.
When indicating a last visited TAI in an Attach Request or a TAU Request, a UE may indicate any TAI supported in the last visited cell for that RPLMN or PLMN equivalent to the RPLMN.
For Cellular IoT over satellite access with moving cells, in order to ensure that each TA is Earth-stationary, even if the radio cells are moving across the Earth's surface, the E-UTRAN may change the TAC values that are broadcast in a cell's system information as the cell moves, as described in TS 36.331.
E-UTRAN may broadcast in a cell a single TAC per PLMN and change this TAC value as the cell moves. Alternatively, the E-UTRAN may broadcast in a cell more than one TAC for a PLMN and add or remove TAC values as the cell moves. The eNodeB provides either the single broadcast TAI or all broadcast TAIs corresponding to the Selected PLMN as described in TS 36.413 to the MME as part of the ULI, whenever the TAI is included in the S1-AP message as described in TS 36.413. The eNodeB indicates, if known, also the TAI where the UE is geographically located.
The MME considers the UE to be in a forbidden area if the only TAI or all TAIs received from the eNodeB are forbidden based on subscription data. The UE considers it is in a cell within a forbidden area if the only TAI or all TAIs broadcast in this cell for the selected PLMN are forbidden. In a PLMN, the UE considers it is not in a cell within a forbidden area if at least one broadcast TAI for this PLMN in this cell is not forbidden.