Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.401  Word version:  18.4.0

Top   Top   Up   Prev   Next
1…   4…   4.2.2…   4.3…   4.3.6…   4.3.8…   4.3.12…   4.3.16…   4.3.20…   4.3.25…   4.4…   4.6…   4.7…   5…   5.1.2…   5.3…   5.3.2…   5.3.3…   5.3.3.2   5.3.3.3…   5.3.4…   5.3.4B…   5.3.5…   5.3.8…   5.3.9…   5.4…   5.4.4…   5.5…   5.5.1.2…   5.5.2…   5.5.2.2…   5.5.2.3…   5.5.2.4…   5.6…   5.7.3…   5.7A…   5.10   5.11…   5.19…   D…   D.3…   D.3.4   D.3.5   D.3.6   D.3.7…   D.3.8…   E   F…   J…   K…   L…   M…

 

4.7  Overall QoS conceptp. 106

4.7.1  PDN connectivity servicep. 106

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);
  • It does not support Emergency Services.
Up

4.7.2  The EPS bearerp. 106

4.7.2.1  The EPS bearer in generalp. 106

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 5.7.6.3 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 15.3.3.4 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 15.3.3.4 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.
Up

4.7.2.2  The EPS bearer with GTP-based S5/S8p. 109

Reproduction of 3GPP TS 23.401, Fig. 4.7.2.2-1: Two Unicast EPS bearers (GTP-based S5/S8)
Up
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.
Up

4.7.2.3  The EPS bearer with PMIP-based S5/S8p. 110

4.7.3  Bearer level QoS parametersp. 110

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 clause 6.1.7.2 of TS 23.203. This configuration applies only for bearers with high priority ARPs as defined in clause 6.1.7.3 of TS 23.203.
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.
Up

4.7.4  Support for Application / Service Layer Rate Adaptationp. 112

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.
Up

4.7.5  Application of PCC in the Evolved Packet Systemp. 112

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.
Up

4.7.6  Bearer Control Mode in EPC |R11|p. 113

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.
Up

4.7.7  Support of rate control of user data using CIoT EPS Optimisation |R13|p. 113

4.7.7.1  Generalp. 113

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.
Up

4.7.7.2  Serving PLMN Rate Controlp. 114

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.
Up

4.7.7.3  APN Rate Controlp. 114

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'.
Up

4.7.8  Inter-UE QoS for NB-IoT UEs using Control Plane CIoT EPS Optimisation |R14|p. 115

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).
Up

4.8  Compatibility Issuesp. 116

4.8.1  Network Configuration for Interaction with UTRAN/GERANp. 116

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.
Up

4.9  Paging Policy Differentiation |R13|p. 116

Paging policy differentiation is an optional feature that allows the MME, based on operator configuration, to apply different paging strategies as defined in clause 5.3.4.3 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.
Up

4.10  Introduction of CIoT EPS Optimisations |R13|p. 116

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 4.3.5.10 "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.
Up

4.11  User Plane CIoT EPS Optimisation |R13|p. 117

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 4.3.5.10,
  • 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.
Up

4.12  Supporting up to 15 EPS bearers per UE |R15|p. 118

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 4.3.5.3).
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 5.3.3.0, 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).
Up

4.13  Introduction of satellite support for Cellular IoT |R17|p. 119

4.13.1  Generalp. 119

This clause describes the functionality for supporting Cellular IoT over satellite access. Support for WB-E-UTRAN, NB-IoT and LTE-M satellite access is specified in TS 36.300.

4.13.2  Support of RAT types defined in EPC for satellite accessp. 119

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.
The MME may initiate Detach of the UE when an S1 UE Context Release Request is received with Cause indicating the release is requested due to a UE using satellite access moved out of PLMN serving area, as specified in TS 36.413.
Up

4.13.3  Network/Access selection for satellite accessp. 119

Network/Access selection principles specified in clause 4.3.2.2 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.
Up

4.13.4  Verification of UE locationp. 119

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 or if the received ULI is not sufficiently reliable, 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.
Up

4.13.5  Use of extended NAS timersp. 120

Whenever the UE is accessing the network using a satellite RAT, the MME and the UE shall set the NAS timers long enough according to this satellite RAT, as specified in TS 24.301.

4.13.6  Support of Tracking Area Updatep. 120

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.
Up

4.13.7  Tracking Area handlingp. 120

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.
If the MME receives multiple TAIs from E-UTRAN and determines that some, but not all, TAIs in the received list of TAIs are forbidden by subscription or by operator policy, the MME shall send the forbidden TAI(s) to UE as described in clause 5.3.2, 5.3.3 and 5.3.4. The UE stores the TAI(s) in the appropriate Forbidden Area list and removes the TAI(s) from the TAI list.
Up

4.13.8  Enhanced support of discontinuous network coverage for satellite access |R18|p. 120

4.13.8.1  Generalp. 120

Basic support for discontinuous coverage is specified in clause 4.3.5.2 and clause 4.3.17.7. The present clause 4.13.8 provides additional optional enhancements to discontinuous coverage:
In the following, "Enhanced Discontinuous Coverage" functionality includes the following enhancements as listed above: Mobility management and power saving optimization described in clause 4.13.8.2, and Overload control described in clause 4.13.8.6.
During Attach or TAU procedures, a UE supporting Enhanced Discontinuous Coverage provides "Enhanced Discontinuous Coverage Support" indication as part of UE Core Network Capability in the Attach Request or TAU Request message to the MME. The MME receiving an Attach Request or a TAU Request message from the UE including "Enhanced Discontinuous Coverage Support" indicates whether Enhanced Discontinuous Coverage is supported by providing the "Enhanced Discontinuous Coverage Support" indication to the UE in the Attach Accept or TAU Accept message.
Up

4.13.8.2  Mobility Management and UE Power Saving Optimizationp. 121

For satellite access that provides discontinuous network coverage, and in case both the UE and the network support Enhanced Discontinuous Coverage, then the Mobility Management and UE Power Saving Optimization functionality may be used.
If both the UE and the network indicate support for "Enhanced Discontinuous Coverage Support" and if the UE determines it will lose coverage and will become unavailable, and decides to remain in no service during that time, then:
  • The UE may be able to determine, including considering current and expected future locations of the UE, a Start of Unavailability Period and/or Unavailability Period Duration for when it expects to be out of coverage.
  • The UE triggers a TAU procedure and includes an indication of upcoming loss of coverage in the TAU Request message to the MME. If the UE is able to determine a Start of Unavailability Period and/or Unavailability Period Duration it also includes them in the TAU Request message.
  • The UE should trigger the TAU procedure early enough such that the procedure, under normal conditions, is able to complete before the start of the unavailability period.
  • The UE and the MME re-negotiate unavailability at every TAU procedure, if it is required. If Start of Unavailability Period and/or Unavailability Period Duration is not included in a TAU Request message any pending loss of coverage configuration stored in the UE context at MME is discarded.
  • If the UE determines an upcoming loss of coverage to the network no longer applies or determines a new Start of Unavailability Period or Unavailability Period Duration related to the upcoming loss of coverage, the UE sends a new TAU Request to the MME to update the Start of Unavailabililty Period and/or Unavailability Period Duration.
Upon receiving a TAU Request message from the UE including an indication of upcoming loss of coverage:
  • If the UE did not include a Start of Unavailability Period, the MME considers implicitly the Start of Unavailability Period to be the time at which it has received the TAU Request message from the UE. If the UE included a Start of Unavailability Period, the Start of Unavailability Period indicates the time at which the UE determines it expects to lose coverage, i.e. time until which the UE determines it is available.
  • The MME may determine, if not provided by the UE, or update the Unavailability Period Duration and/or the Start of Unavailability Period.
    If the MME knows an Unavailability Period Duratio and/or the Start of Unavailability Periodn (e.g. based on information available to the MME as described in clause 4.13.8.4) for the UE, and the UE not include an Unavailability Period Duration and/or the Start of Unavailability Period or included an Unavailability Period Duration and/or the Start of Unavailability Period different to the Unavailability Period Duration and/or the Start of Unavailability Period known to the MME, the MME may use either the Unavailability Period Duration and/or the Start of Unavailability Period known to the MME or the Unavailability Period Duration and/or the Start of Unavailability Period from the UE as the Unavailability Period Duration and/or the Start of Unavailability Period. The MME should include the Unavailability Period Duration and/or the Start of Unavailability Period known to the MME in the TAU Accept. How the UE treats the MME provided Unavailability Period Duration and/or the Start of Unavailability Period is up to UE implementation e.g. to help to determine when to return to coverage after a discontinuous coverage period, whether to listen to paging in eDRX, not to initiate any NAS signalling (including Service Request for MO data) within the discontinuous coverage period in case of any UL signalling/data request or the UE may deactivate its Access Stratum functions for satellite access in order to optimise power consumption until coverage returns, etc.
    The MME indicates to the UE in the Attach Accept or TAU Accept whether the UE is not required to perform a TAU procedure when the unavailability period has ended.
  • The MME stores the information that the UE is unavailable at the Start of Unavailability Period in the UE context, and considers the UE is unreachable from then until the UE enters ECM_CONNECTED state.
If the UE requests power saving features the MME uses procedures defined in other clauses to provide the UE with timers (e.g. periodic TAU timer, extended idle mode DRX (see clause 5.13a), and PSM mode configuration (see clause 4.3.22)), and may also consider the Unavailability Period Duration (if available) and Start of Unavailability Period (if available).
Unless the MME indicated that the UE is not required to perform a TAU procedure when the unavailability period has ended, then once the event which makes the UE unavailable is completed in the UE, the UE triggers a TAU procedure. If the event which makes the UE unavailable is delayed to a future time or cancelled or unavailability period deviates from negotiated value in the UE, the UE triggers TAU procedure.
The MME should adjust the mobile reachable timer or Implicit Detach timer or both such that the MME does not implicitly detach the UE while the UE is out of coverage, see clause 3,4.2. Features described for High latency communication in clause 4.3.14.7 may be used to handle mobile terminated (MT) communication with UEs being unreachable due to satellite access with discontinuous coverage and the Unavailability Period Duration (if available) and Start of Unavailability Period (if available) may be used when determining the Estimated Maximum Wait Time.
The UE may send Tracking Area Update request message to inform the network of its UE unavailability period even if Mobility Management back-off timer is running.
Up

4.13.8.3  Coverage availability information provisioning to the UEp. 122

A UE may use satellite coverage availability information for satellite access to support discontinuous coverage operations. Satellite coverage availability information can be provided to a UE by an external server via a PDN Connection or SMS. The protocol and format of satellite coverage availability information via PDU Connection or SMS is not defined in this release of the specification, but some examples on the information that constitutes the satellite coverage availability information is defined in Annex N.
Up

4.13.8.4  Coverage availability information provisioning to the MMEp. 122

The MME may use satellite coverage availability information to support satellite access by UEs with discontinuous coverage operation. Satellite coverage availability information may be provisioned to the MME by O&M.
The satellite coverage availability information provisioned to the MME describes when and where satellite coverage is expected to be available in an area. The satellite coverage availability information is not UE specific and can be applied by the MME for any UE in the affected area.
Up

4.13.8.5  Pagingp. 122

In the case of satellite access that provides discontinuous network coverage, the MME may utilize sub-area paging (e.g. first page in the last known ECGI or TA and retransmission in all registered TAs). The MME may utilize the location information as received at or before the S1 release due to the discontinuous coverage for paging optimisation.
The MME may e.g. receive UE location from eNodeB during the Attach or TAU procedure e.g. triggered for Mobility Management and Power Saving Optimization for discontinuous network coverage as described in clause 4.13.8.2, or the MME may request the Location Reporting Procedure when the UE is in ECM_CONNECTED state as described in clause 5.9.1.
Up

4.13.8.6  Overload controlp. 123

The MME and UE may only use the procedure defined in this clause if both the UE and MME indicate "Enhanced Discontinuous Coverage Support", see clause 4.13.8.1.
In order to avoid a large number of UEs causing excessive signalling load on the network when leaving coverage or re-gaining coverage after being out of coverage, the MME may determine a Maximum Time Offset controlling when UEs are allowed to initiate NAS signalling with the network, as described in this clause.
In this case, the MME determines this Maximum Time Offset based on network configuration, high priority access and priority services. The MME sends this Maximum Time Offset to individual UEs during the Attach or TAU procedures.
If the UE receives this Maximum Time Offset from the network in an Attach or TAU Accept, the UE shall replace any previously received Maximum Time Offset on the same RAT type and PLMN with this one.
When the UE knows a later time at which coverage will be lost and when the UE does not send a TAU Request to the MME in advance (see clause 4.13.8.2), the UE determines a random value up to the minimum of the latest Maximum Time Offset for this PLMN and RAT type and the time until coverage will be lost. The UE shall send the TAU Request at the time when coverage will be lost less the random value to the MME indicating the loss of coverage.
Upon returning to coverage after being out of coverage due to discontinuous coverage, the UE sets the discontinuous coverage wait timer value to a random value up to and including the latest Maximum Time Offset for this PLMN and RAT type, and starts this timer. The UE shall not initiate any NAS signalling on that RAT Type and PLMN while the discontinuous coverage wait timer is running.
The UE shall stop the discontinuous coverage wait timer and initiate NAS signalling if the UE receives paging message, has pending emergency services or when UE enters a Tracking Area outside the current Tracking Area List.
Up

Up   Top   ToC