Content for  TS 23.401  Word version:  19.0.0

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). At inter-PLMN mobility the source MME shall provide the EPS bearer QoS parameters used in the source MME to the target MME. 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.

See clause 4.10.3 in TS 23.402.

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

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:

• Mobility management and power saving optimization, see clause 4.13.8.2; and
• Coverage availability information provisioning to the UE, see clause 4.13.8.3; and
• Coverage availability information provisioning to the MME, see clause 4.13.8.4; and
• Paging, see clause 4.13.8.5; and
• Overload control, see clause 4.13.8.6.

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.

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 or Attach request message:

• If the UE did not include a Start of Unavailability Period in the TAU Request message, 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 Duration and/or the Start of Unavailability Period (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 should include the Unavailability Period Duration and/or the Start of Unavailability Period known to the MME in the TAU Accept or Attach Accept message and use those values in subsequent steps of this procedure. 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 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 4.3.5.2. Features described for High latency communication in clause 4.3.17.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 Downlink Buffering Duration 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.

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.

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 is not UE specific and can be applied by the MME for any UE in the affected area.

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.

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.