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.3.16  Local IP Access (LIPA) function |R10|p. 63

The LIPA function enables a UE connected via a HeNB to access other entities in the same residential/enterprise network without the user plane traversing the mobile operator's network except HeNB subsystem.
The Local IP Access is achieved using a Local GW (L-GW) collocated with the HeNB.
LIPA is established by the UE requesting a new PDN connection to an APN for which LIPA is permitted, and the network selecting the Local GW associated with the HeNB and enabling a direct user plane path between the Local GW and the HeNB. The HeNB supporting the LIPA function includes the Local GW address to the MME in every INITIAL UE MESSAGE and every UPLINK NAS TRANSPORT control message as specified in TS 36.413.
For this release of the specification no interface between the L-GW and the PCRF is specified and there is no support for Dedicated bearers on the PDN connection used for Local IP Access. The Local GW (L-GW) shall reject any UE requested bearer resource modification.
The direct user plane path between the HeNB and the collocated L-GW is enabled with a Correlation ID parameter that is associated with the default EPS bearer on a PDN connection used for Local IP Access. Upon establishment of the default EPS bearer the MME sets the Correlation ID equal to the PDN-GW TEID (GTP-based S5) or the PDN-GW GRE key (PMIP-based S5). The Correlation ID is then signalled by the MME to the HeNB as part of E-RAB establishment and is stored in the E-RAB context in the HeNB. The Correlation ID is used in the HeNB for matching the radio bearers with the direct user plane path connections from the collocated L-GW.
If the UE is roaming and if the HSS indicates LIPA roaming allowed for this UE in this VPLMN, then the VPLMN (i.e. MME) may provide LIPA for this UE. Furthermore, in the absence of any LIPA information for the requested APN from the HSS, the VPLMN (i.e MME) shall not provide LIPA. The VPLMN address allowed flag is not considered when establishing a LIPA PDN connection.
LIPA is supported for APNs that are valid only when the UE is connected to a specific CSG. LIPA is also supported for "conditional" APNs that can be authorized to LIPA service when the UE is using specific CSG. APNs marked as "LIPA prohibited" or without a LIPA permission indication cannot be used for LIPA.
MME shall release a LIPA PDN connection to an APN if it detects that the UE's LIPA CSG authorization data for this APN has changed and the LIPA PDN connection is no longer allowed in the current cell.
As mobility of the LIPA PDN connection is not supported in this release of the specification, the LIPA PDN connection shall be released when the UE moves away from H(e)NB. Before starting the handover procedure towards the target RAN, the H(e)NB shall request using an intra-node signalling the collocated L-GW to release the LIPA PDN connection. The H(e)NB determines that the UE has a LIPA PDN connection from the presence of the Correlation ID in the UE (E-)RAB context. The L-GW shall then initiate and complete the release of the LIPA PDN connection using the PDN-GW initiated bearer deactivation procedure as per clause 5.4.4.1 or GGSN initiated PDP context deactivation procedure as specified in TS 23.060. The H(e)NB shall not proceed with the handover preparation procedure towards the target RAN until the UE's (E-)RAB context is clear for the Correlation ID.
At the handover, the source MME checks whether the LIPA PDN connection has been released. If it has not been released:
  • and the handover is the S1-based handover or the Inter-RAT handover, the source MME shall reject the handover.
  • and the handover is X2-based handover, the MME shall send a Path Switch Request Failure message (see more detail in TS 36.413) to the target HeNB. The MME performs explicit detach of the UE as described in the MME initiated detach procedure of clause 5.3.8.3.
During idle state mobility events, the MME/SGSN shall deactivate the LIPA PDN connection when it detects that the UE has moved away from the HeNB.
Up

4.3.17  Support for Machine Type Communications (MTC) |R10|p. 64

4.3.17.1  Generalp. 64

This clause provides an overview about functionality for Machine Type Communications according to service requirements described in TS 22.368. The specific functionality is described in the affected procedures and features of this and other specifications. For discrepancies between this overview clause and the detailed procedure and function descriptions, the latter take precedence.
MTC functionality is provided by the visited and home networks when the networks are configured to support machine type communication. It applies to both the non-roaming case and the roaming case and some functionality may be dependent upon the existence of appropriate roaming agreements between the operators.
Some of the MTC functions are controlled by subscriber data. Other MTC functions are based on indicators sent by the UE to the network. MTC functionality is performed by UEs that are configured to support different options as described in clause 4.3.17.4.
Though motivated by scenarios and use cases defined in TS 22.368, the functions added to support MTC have general applicability and are in no way constrained to any specific scenario or use case except where explicitly stated.
Unless otherwise stated in this specification, MTC functionality also applies over satellite access.
Up

4.3.17.2  Overview of protection from Potential MTC Related Overloadp. 65

The number of MTC devices may be several orders of magnitude greater than "traditional" devices. Many (but not all) MTC devices will be relatively stationary and/or generate low volumes of traffic. However, these UEs have the capability to generate normal quantities of signalling. As normal signalling from large numbers of UEs may cause overload independently whether the UE is used for MTC or not, generic functionality for overload and congestion control is required.
The total signalling from large numbers of UEs is a concern in at least two situations:
  • when an application (running in many UEs) requests many UEs to do "something" at the same time; and/or
  • when many UEs are roamers and their serving network fails, then they can all move onto the local competing networks, and potentially overload the not (yet) failed network(s).
To counter these potential problems, the following standardised indications and mechanisms are provided in a generic manner. These permit node specific features to be developed to protect the networks.
  1. Where applicable, UEs can be configured for enhancements as described in subsequent bullets Post-manufacturing configuration can be performed remotely as described in clause 4.3.17.4.
  2. For mobile originated services, UEs configured for low access priority provide the E-UTRAN with information indicating that the RRC connection establishment request has low access priority (see clause 4.3.17.4). Clause 4.3.17.4 describes when low access priority is not applicable.
  3. RRC signalling has the capability of providing 'extended wait timers' when rejecting messages from UEs. These 'extended wait timers' are only used by UEs that access the network with low access priority.
  4. The MME can initiate rejection of RRC connection establishments in the E-UTRAN for UEs that access the network with low access priority as described in clause 4.3.7.4.1. In addition, MME signalling or O&M can trigger E-UTRAN to initiate Extended Access Barring. These mechanisms are further described in clause 4.3.7.4.1.
  5. Overload messages from the MME to E-UTRAN are extended to aid the RAN in performing the functionality in bullets b, c and d above.
  6. UEs configured with a long minimum periodic PLMN search time limit (see TS 24.368) have an increased minimum time in between their searches for more preferred PLMNs.
  7. At PLMN change, UEs configured to perform Attach with IMSI at PLMN change (see TS 24.368) do this rather than a TA update with GUTI (thus avoiding the need to reject the TA update, and to request the IMSI following the subsequent Attach with GUTI).
  8. For mobile originated services, UEs configured for low access priority (see TS 24.368) provide a low access priority indication to the MME in NAS signalling that permit the MME to undertake protective measures (e.g. to permit the MME to immediately command the UE to move to a state where it does not need to generate further signalling messages and/or does not reselect PLMNs), as described in clause 4.3.7.4.1. Clause 4.3.17.4 describes when low access priority is not applicable.
  9. Using Periodic TAU timer value sent by the HSS and/or UE provided low access priority indication (bullet h above), the MME can allocate a long periodic TAU timer value to the UE. A long periodic TAU timer is likely to slow down the rate at which a UE detects a network failure and thus it slows down the rate of movement of UEs from a failed network to other local competing networks (see clause 4.3.17.3).
  10. Mechanisms for the MME and P-GW to detect congestion associated with a particular APN (see clauses 4.3.7.4.2 and 4.3.7.5).
  11. The addition of 'back off timers' to EMM and ESM signalling messages (e.g. to rejection messages). These include some time randomisation to guard against a repeat of a load peak. The MME should be able to apply this behaviour on a per-APN basis. as described in clause 4.3.7.4.2
  12. Signalling that permits the P-GW to request the MME to generate the above ESM signalling with 'back off timers' (see clause 4.3.7.5).
  13. An MME overload control mechanism to selectively limit the number of Downlink Data Notification requests the S-GW sends to the MME for downlink low priority traffic received for UEs in idle mode (see clause 4.3.7.4.1a).
  14. UE configured for specific handling of the invalid USIM state, the "forbidden PLMN list", the "forbidden PLMNs for attach in S1mode list" and the "forbidden PLMNs for GPRS service list" remembers that the USIM is invalid and keeps the PLMN forbidden lists even if the UE is switched off and then switched on.
  15. When the UE has an activated PDN connection without low access priority or the UE is requested to establish such a PDN connection and the UE is configured with a permission for overriding low access priority the UE doesn't provide a low access priority indication to the MME in NAS MM signalling and also not to the RAN in the RRC requests. In the NAS request for activating a PDN connection this UE always indicates what the upper layers requested, i.e. the UE indicates low access priority in that NAS request unless the upper layers request activation of a PDN connection without low access priority.
  16. When the UE has an activated PDN connection that is without low access priority or the UE is requested to activate such a PDN connection and the UE is configured with a permission for overriding Extended Access Barring, then the UE ignores any Extended Access Barring (if it is activated in the network) as defined in TS 22.011.
  17. The eNodeB may use the low access priority indication provided by the UE to steer UEs configured for low access priority to specific MMEs.
Up

4.3.17.3  Optimising periodic TAU Signallingp. 66

To reduce network load from periodic TAU signalling and to increase the time until the UE detects a potential need for changing the RAT or PLMN (e.g. due to network problems) the longer values of the periodic TAU timer and Mobile Reachable timer shall be supported.
A long periodic RAU/TAU timer value may be locally configured at MME or may be stored as part of the subscription data in HSS. During Attach and TAU procedures the MME allocates the periodic RAU/TAU timer value as periodic TAU timer to the UE based on VPLMN operator policy, low access priority indication from the UE, periodic RAU/TAU timer value requested by UE, subscription information received from the HSS and Start of Unavailability Period and/or Unavailability Period Duration if using a RAN that provides discontinuous coverage (see clause 4.13.8.2).
If MME receives a subscribed periodic RAU/TAU timer value from the HSS it allocates the subscribed value to the UE as periodic TAU timer. A visited PLMN MME may use subscribed periodic RAU/TAU timer value, if available, as an indication to decide for allocating a locally configured periodic RAU/TAU timer value to the UE.
If no subscribed periodic RAU/TAU timer value is received from the HSS, the MME should:
  • if the periodic RAU/TAU timer value requested by UE is within the boundaries of the VPLMN operator policy, allocate the value requested by the UE;
  • if the periodic RAU/TAU timer value requested by UE is higher than allowed per the VPLMN operator policy, allocate the highest allowed value per the VPLMN operator policy;
  • if the periodic RAU/TAU timer value requested by UE is lower than allowed per the VPLMN operator policy, allocate the lowest allowed value per the VPLMN operator policy.
Up

4.3.17.4  UE configuration and usage of indicatorsp. 66

A subscriber can by agreement with its operator be required to use UEs that are configured (see TS 24.368) to support one or more of the following options:
  • UE configured for low access priority; and/or
  • UE configured with a permission for overriding low access priority, which is only applicable for a UE that is also configured for low access priority; and/or
  • UE configured to perform Attach with IMSI at PLMN change; and/or
  • UE configured with a long minimum periodic PLMN search time limit; and/or
  • UE configured for specific handling of the invalid USIM state, the "forbidden PLMN list", the "forbidden PLMNs for attach in S1mode list" and the "forbidden PLMNs for GPRS service list"; and/or
  • UE configured for Extended Access Barring; and/or
  • UE configured with a permission for overriding Extended Access Barring, which is only applicable for a UE that is also configured for Extended Access Barring.
UEs can be configured for one or more of the above options with the following restrictions:
  • in this Release of the specification, a UE that is configured for low access priority shall also be configured for Extended Access Barring; and
  • in this Release of the specification, a UE that is configured for Extended Access Barring shall be configured for low access priority.
  • in this Release of the specification, a UE that is configured for overriding low access priority shall also be configured for overriding Extended Access Barring; and
  • in this Release of the specification, a UE that is configured for overriding Extended Access Barring shall also be configured for overriding low access priority.
UEs can be configured for one or more of the above options. Post-manufacturing configuration of these options in the UE can be performed only by OMA DM or (U)SIM OTA procedures. UEs capable of the above options should support configuration of these options by both OMA DM and (U)SIM OTA procedures.
A UE configured for low access priority shall transmit the low access priority indicator to the MME during the appropriate NAS signalling procedures and transmit the corresponding low access priority to the E-UTRAN during RRC connection establishment procedures.
Low access priority shall not be applicable in the following situations:
  • for all procedures related to an emergency PDN connection; used for IMS Emergency sessions that are to be prioritized as per the requirements for IMS Emergency session procedures (see clause 4.3.12). When an emergency PDN connection gets established, the MME may, based on MME configuration, initiate the deactivation of any non-emergency PDN connection using the MME requested PDN disconnection procedure described in clause 5.10.3;
  • for all procedures when preferential access to the network is provided to the UE by the Access Class 11-15 mechanism according to TS 36.331 and TS 22.011 e.g. for Multimedia Priority Services as described in clause 4.3.18;
  • for RRC connection establishment procedures when responding to paging;
  • for a UE configured with a permission for overriding low access priority under conditions described by bullet o in clause 4.3.17.2; or
  • other specific situations described in TS 24.301.
If the NAS session management request message used to establish a new PDN connection contains a low access priority indication, the MME shall forward the low access priority indication in the Create Session Request message to the S-GW/P-GW. The low priority indication gets associated with a PDN connection when it is established and it shall not change until the PDN connection is deactivated.
The low access priority indication may be included in charging records by the visited and home networks. In order to permit the S-GW to include the low access priority indicator in the charging records, the low access priority indicator should be stored in the MME EPS Bearer contexts and should be passed as part of these contexts to other SGSN/MME or S-GW nodes in mobility management procedures.
A network node may invoke one or more of the following mechanisms based on the indicators received in signalling from UEs or forwarded by other network nodes:
  • based on the low access priority indicator in NAS request messages, bullets e, h, i, k and l as defined in clause 4.3.17.2; and/or
  • based on the low access priority for RRC connection establishment, bullets b, c and q as defined in clause 4.3.17.2.
A UE shall invoke one or more of the following mechanisms based on the configuration and capabilities of the UE:
  • when UE is configured with a long minimum periodic PLMN search time limit, the UE invokes actions as described in bullet f in clause 4.3.17.2; and/or
  • when UE is configured to perform Attach with IMSI at PLMN change, the UE invokes actions as described in bullet g in clause 4.3.17.2; and/or
  • when a UE is configured for low access priority, the UE invokes actions as described in bullets b and h in clause 4.3.17.2; and/or
  • when UE is configured for specific handling of the invalid USIM state, the "forbidden PLMN list", the "forbidden PLMNs for attach in S1mode list" and the "forbidden PLMNs for GPRS service list", the UE invokes actions as defined in bullet n in clause 4.3.17.2; and/or
  • when UE is configured for Extended Access Barring, the UE invokes actions as defined in bullet d in clause 4.3.17.2; and/or
  • when a UE is configured with a permission for overriding low access priority and configured with a permission for overriding Extended Access Barring, the UE invokes actions as described in bullets o) and p) in clause 4.3.17.2.
Up

4.3.17.5Void

4.3.17.6  Support of UEs configured for low access priority, Extended Access Barring and permission for override |R11|p. 68

The feature is specified in clause 5.3.13.6 of TS 23.060.

4.3.17.7  High latency communication |R13|p. 68

Functions for High latency communication may (depending on operator configuration) be used to handle mobile terminated (MT) communication with UEs being unreachable while using power saving functions (e.g. UE Power Saving Mode (see clause 4.3.22) or extended idle mode DRX (see clause 5.13a)) or UEs that are using a satellite access with discontinuous coverage. "High latency" refers to the initial response time before normal exchange of packets is established. That is, the time it takes before a UE has woken up from its power saving state and responded to the initial downlink packet(s). The feature is described in TS 23.682.
The High latency communication includes invoking extended buffering of MT data at the Serving-GW when the UE is in a power saving state and not reachable. The handling is specified in the Network Triggered Service Request procedure, clause 5.3.4.3. Establishing the user plane for delivering the buffered data when the UE contacts the MME or SGSN by signalling shall be done in the Tracking Area Update and Routing Area Update procedures. The MME/SGSN uses its parameter DL Data Buffer Expiration Time in the MM context information to remember if there is buffered DL data to be delivered when the UE becomes reachable. When set, the DL Data Buffer Expiration Time shall be cleared at any user plane setup to the RAN, i.e. buffered DL data can been delivered. At TAU/RAU procedures with MME/SGSN change, the old MME/SGSN shall indicate in the context response to the new MME/SGSN that buffered DL data is waiting and hence the new MME/SGSN shall establish the user plane for delivery of the buffered DL data. When the DL Data Buffer Expiration Time has expired, the MME/SGSN considers no DL data to be buffered and no indications of Buffered DL Data Waiting are sent during context transfers at TAU procedures. At TAU/RAU procedures with Serving-GW change, the buffered DL data is forwarded to the new Serving-GW or Gn/Gp-SGSN.
For Control Plane CIoT EPS Optimisation, the High latency communication includes invoking the buffering of MT data at the Serving-GW or the MME as specified in Mobile Terminated Data Transport in Control Plane CIoT EPS Optimisation with P-GW connectivity, clause 5.3.4B.3. When the UE contacts MME, MME delivers the buffered data using NAS PDUs. If MT data is buffered in MME, at TAU procedures with MME change the buffered data in the old MME is discarded.
The High latency communication also includes sending event notifications to application servers that have requested "UE Reachability" or "Availability after DDN failure" monitoring events. Event notifications are sent when a UE becomes reachable, for example as part of the Attach Procedure, TAU/RAU procedures and the UE triggered Service Request procedure.
When "UE Reachability" monitoring is requested for UE's that are using extended idle mode DRX, an event notification is sent to the application server when the UE is about to become reachable for paging.
If the MME is aware that some signalling or data is pending in the network for an UE that is known as being unreachable for a long duration, e.g. for UE's having extended idle mode DRX or PSM enabled, the MME may include a Pending Data indication in the next S1-AP message towards an eNodeB. If the eNodeB receives this indication, the eNodeB may take this information into account when determining user inactivity. At inter-RAN node handovers, if some signalling or data are still pending, the target MME may send a Pending Data indication to the target RAN node.
Up

4.3.17.8  Support for Non-IP Data Delivery (NIDD) |R13|p. 69

4.3.17.8.1  Generalp. 69
The support of Non-IP data is part of the CIoT EPS Optimisations. A PDN Type "Non-IP" is used for Non-IP data. The Non-IP data delivery to SCS/AS is accomplished by one of two mechanisms:
When the Reliable Data Service is not used, Non-IP data in-sequence delivery cannot be guaranteed and data PDUs may be lost requiring higher protocol layers to ensure guaranteed delivery when needed. The Reliable Data Service is defined in TS 23.682.
The SMS service may also be used to deliver data without use of the IP protocol. The SMS service is always supported for CIoT EPS Optimisations, i.e. can be used simultaneously with Non-IP and IP data. When only the SMS service is needed, an attach without PDN connection establishment can be used, see clause 5.3.2.
Dedicated bearers are not supported for the Non-IP data.
Up
4.3.17.8.2  ESM Proceduresp. 70
The UE indicates in the ESM connection request, e.g. in Attach or PDN Connectivity Request, that a Non-IP PDN type shall be used. The subscription information has a default APN for PDN Type Non-IP, which the MME uses for the first received Non-IP connectivity request unless the UE has included an APN in the request.
4.3.17.8.3  Delivery mechanismp. 70
4.3.17.8.3.1  Generalp. 70
At each PDN connectivity request, the MME decides which delivery mechanism (SCEF based delivery or SGi based delivery) is used for delivering the Non-IP data between RAN and AS. An indication associated with the used APN determines if SCEF based delivery or SGi based delivery shall be used.
4.3.17.8.3.2  SCEF based deliveryp. 70
When the MME decides to use SCEF based delivery mechanism for Non-IP data, a PDN connection is established towards the selected SCEF. Such a PDN Connection is also known as an "SCEF Connection". The APN used for SCEF based delivery is an FQDN, which either resolves to an SCEF hostname or to an SCEF IP address.
The SCEF based delivery is applicable only to the Control Plane CIoT EPS Optimisation (see clause 4.10).
The support of Non-IP data via the SCEF is further defined in TS 23.682.
Up
4.3.17.8.3.3  SGi based deliveryp. 70
4.3.17.8.3.3.1  Generalp. 70
When support of Non-IP data is provided at the SGi interface, different point-to-point tunnelling techniques may be used. Point-to-point tunnelling by UDP/IP encapsulation can be used as described in clause 4.3.17.8.3.3.2 below. Other techniques as described in clause 4.3.17.8.3.3 below may be used.
Support for the SGi based delivery of Non-IP data can be used by any UE. That is, it is independent of support for the User Plane CIoT EPS Optimisation and the Control Plane CIoT EPS Optimisation (see clause 4.10).
The P-GW decides at PDN connection establishment based on pre-configuration which point-to-point tunnelling technique is used for the SGi based delivery between the P-GW and the AS.
Up
4.3.17.8.3.3.2  SGi PtP tunnelling based on UDP/IPp. 71
SGi PtP tunnelling based on UDP/IP may be used to deliver Non-IP data to AS via SGi.
A point-to-point tunnel is used by the P-GW towards the AS. The tunnel parameters (i.e. destination IP address and UDP port) for SGi PtP tunnelling based on UDP/IP are pre-configured on the P-GW. IP address allocation procedures for PDN connections are performed locally (e.g. without involving the UE) by the P-GW based on APN configuration and according to clause 5.3.1. Only single IP address is used (i.e. both IPv4 and IPv6 addresses are not allocated).
The P-GW acts as a transparent forwarding node for the payload between the UE and the AS.
For uplink Non-IP data, the P-GW forwards the received data to the AS over the SGi PtP tunnel using UDP/IP encapsulation. When the Reliable Data Service is enabled, the P-GW processes the Reliable Data Service Header. The Reliable Data Service Configuration is pre-configured on the P-GW. The Reliable Data Service Configuration is defined in TS 23.682.
For downlink Non-IP data, the AS sends the data using UDP/IP encapsulation with the IP address of the UE and the 3GPP defined UDP port for "Non-IP" data. The P-GW decapsulates the received data (i.e. removes the UDP/IP headers) and forwards the data to S-GW on the GTP-U tunnel identified by the IP address of the UE (i.e. PDN connection) for delivery to the UE. When the Reliable Data Service is enabled, the P-GW adds the Reliable Data Service Header.
The P-GW performs the IP related operations (e.g. allocates IP address for the PDN connection), but the IP address or IP prefix is not provided to the UE (i.e. SLAAC / Router Advertisements are not performed. DHCP or DHCPv6 are not used). In the case of IPv6 the P-GW assigns an Interface Identifier for the PDN connection. The allocated IP address or IPv6 prefix identifies the PDN connection of the UE. The P-GW shall inform the MME of the assigned IPv4 address or IPv6 prefix and Interface Identifier for a PDN Connection of a given UE. However, the UE is not informed about the assigned IPv6 prefix and Interface Identifier.
Up
4.3.17.8.3.3.3  Other SGi PtP tunnelling mechanismsp. 71
SGi PtP tunnelling mechanisms such as PMIPv6/GRE, L2TP, GTP-C/U, etc, may be used to deliver Non-IP data to AS via SGi. The general handling of such delivery mechanisms is as described below.
A point-to-point tunnel is established by the P-GW towards the AS. Depending on the type of protocol employed on the SGi PtP tunnel, the SGi PtP tunnel setup may be done at the time of Attach or at the time of first MO datagram being sent by the CIoT UE. The P-GW selects the AS based on the P-GW configuration (e.g. per APN, or per PtP tunnel type etc.). However, IP address allocation procedures for the UE (according to clause 5.3.1) are not performed by the P-GW.
The P-GW acts as a transparent forwarding node between the UE and the AS.
For uplink Non-IP data, the P-GW forwards the received data to the AS over the established SGi PtP tunnel.
For downlink Non-IP data, the AS locates the right SGi PtP tunnel for the UE (using information such as UE identifiers in the Non-IP protocol itself, etc) to forward the data. The AS sends the data to P-GW over the established SGi PtP tunnel. The P-GW in turn sends the data to S-GW on the GTP-U tunnel identified by the associated SGi PtP tunnel for delivery to the UE.
Up

4.3.17.8a  Support of PDN type Ethernet |R16|p. 71

The support of Ethernet PDN type relies upon the selection of a P-GW that supports combined PGW+SMF functionality specified in TS 23.501, TS 23.502 and TS 23.503. This functionality may be supported by a PLMN even if it has no NG-RAN coverage, however, it does require that the subscriber has a subscription record in the 5GS UDM.
This feature is described in clause 5.6.10.2 of TS 23.501.
For PDN connection with Ethernet PDN type, IP address allocation is not needed.
In contrast to the Non-IP PDN type, EPS Dedicated Bearers are supported for the Ethernet PDN type (including the TFT as described in clause 4.7.2.1). The details about the TFT packet filter(s) are described in clause 5.7.6.3 of TS 23.501.
For PDN connection of Ethernet type, dynamic PCC is applied as described in clause 4.7.5 with the following differences:
  • Dynamic PCC specified in TS 23.503 is applied, i.e. the PCEF interacts with the PCF using N7 interface as described in TS 23.501, and the PCEF does not interact with the PCRF using Gx interface as specified in TS 23.203.
  • The SDF template included in the PCC rule(s) uses Ethernet packet filter as specified in TS 23.501.
  • The description related to IP address configuration is not applicable.
Dedicated Core Network functionality (see clause 4.3.25) can be used to avoid the need for all MMEs in the PLMN to be upgraded to support Ethernet PDN Type.
If the UE's attempt to use the Ethernet PDN Type is rejected by the network, the UE may attempt to gain service by requesting the Non-IP PDN type.
Ethernet PDN Type is not supported in GERAN/UTRAN. If the UE only has an Ethernet PDN connection established, mobility to GERAN/UTRAN should be prevented. To do this, the MME shall indicate to the eNodeB in Handover Restriction List that GERAN/UTRAN is restricted.
For PDN connection with Ethernet PDN type, mobility to Non 3GPP access to EPC is not supported.
Up

4.3.17.9  Service Gap Control |R15|p. 72

Service Gap Control is an optional feature intended for MTC/CIoT UEs to control the frequency at which these UEs can access the network. That is, to ensure a minimum time gap between consecutive Mobile Originated data communications initiated by the UE. This helps reducing peak load situations when there are a large number of these UEs in an operator network. Service Gap Control is intended to be used for "small data allowance plans" for MTC/CIoT UEs where the applications are tolerant to service latency.
Service Gap Time is a subscription parameter used to set the Service Gap timer and is enforced in the UE and in the MME on a per UE level (i.e. the same Service Gap Timer applies for all PDN connections that the UE has). The UE indicates its capability of support for Service Gap Control in the Attach Request message and TAU Request message to the MME. The MME passes the Service Gap Time to the UE in the Attach Accept message and/or Tracking Area Update Accept message for UE that has indicated its supports of the Service Gap Control. The Service Gap Control shall be applied in a UE when a Service Gap Time is stored in the UE context and applied in the MME when the Service Gap Time is stored in the MM context.
Service Gap Control requires the UE to stay in ECM-IDLE mode for at least the whole duration of the Service Gap timer before triggering Mobile Originated user data transmission, except for procedures that are exempted (see TS 24.301). The Service Gap timer shall be started each time a UE moves from ECM-CONNECTED to ECM-IDLE, unless the connection request was initiated by the paging of a Mobile Terminated event, or after a TAU procedure without active flag or signalling active flag, which shall not trigger a new or extended Service Gap interval. When a Service Gap timer expires, the UE is allowed to send a connection request again. If the UE does so, the Service Gap timer will be restarted at the next ECM-CONNECTED to ECM-IDLE transition.
The Service Gap control is applied in ECM-IDLE state only and does not impact UE Mobile Originated user data transmission or Mobile Originated signalling in ECM-CONNECTED state. The Service Gap timer is not stopped upon ECM-IDLE state to ECM-CONNECTED state transition. The UE shall not initiate connection requests for MO user plane data, MO control plane data, or MO SMS when a Service Gap timer is running. The UE shall also not initiate Attach Requests when a Service Gap timer is running, unless it is Attach Request without PDN connectivity or Emergency Attach which are allowed.
The MME may enforce the Service Gap timer by rejecting connection request for MO user plane data, MO control plane data, or MO SMS when a Service Gap timer is running. The MME may enforce the Service Gap timer by not allowing Attach Requests when a Service Gap timer is running, unless it is Attach Request without PDN connectivity or Emergency Attach which are allowed. When rejecting the connection requests and the Attach Requests while the Service Gap timer is running, the MME may include a Mobility Management back-off timer corresponding to the time left of the current Service Gap timer. For the UEs that does not support Service Gap Control (e.g. pre-release-15 UEs), Service Gap Control may be enforced using "General NAS level Mobility Management control" as defined in clause 4.3.7.4.2.1.
When the MME starts the Service Gap timer, the MME should invoke the Service Gap timer with a value that is slightly shorter than the Service Gap Time value provided to the UE in the subscription information received from the HSS.
A UE which transitions from a PSM or eDRX power saving state shall apply Service Gap Control when it wakes up if the Service Gap timer is still running.
Additional aspects of Service Gap Control:
  • Service Gap Control applies in all PLMNs.
  • When the Service Gap timer is running and the UE receives paging, the UE shall respond as normal.
  • Service Gap Control applies to low priority (delayTolerant) and normal traffic.
  • Service Gap Control does not apply to exception reporting for NB-IoT.
  • Emergency Attach and Attach without PDN Connectivity are allowed when a Service Gap timer is running.
  • Service Gap Control shall be effective also for UEs performing detach and reattach unless it is Attach Request without PDN connectivity or Emergency Attach.
  • Tracking Area Update with active flag or signalling active flag is not allowed when a Service Gap timer is running except for emergency bearer services or if the UE is accessing with high priority access class in the range AC 11-15.
  • If the Service Gap timer is running, the Service Gap is applied at PLMN selection as follows:
    1. Re-attach to the registered PLMN: The remaining Service Gap timer value survives and controls the re-attach.
    2. Attach or Tracking Area Update to a different PLMN: The remaining Service Gap timer value survives and controls the Attach/Tracking Area Update to the new PLMN.
    3. USIM swap: The Service Gap timer is no longer running and the Service Gap feature does not apply, unless re-instatiated by the serving PLMN.
  • Multiple uplink packets and downlink packets are allowed during one RRC connection for UE operating within its APN Rate Control limits.
The following procedures are impacted by Service Gap Control:
Up

4.3.18  Multimedia Priority Service |R10|p. 73

4.3.18.1  Generalp. 73

Multimedia Priority Service (MPS) allows certain subscribers (i.e. Service Users as per TS 22.153) priority access to system resources in situations such as during congestion, creating the ability to deliver or complete sessions of a high priority nature. Service Users are government-authorized personnel, emergency management officials and/or other authorized users. MPS supports priority sessions on an "end-to-end" priority basis.
MPS is based on the ability to invoke, modify, maintain and release sessions with priority, and deliver the priority media packets under network congestion conditions. MPS is supported in a roaming environment when roaming agreements are in place and where regulatory requirements apply.
MPS is supported for Service Users using UEs connecting via 3GPP access. MPS is also supported for Service Users using UEs that support connecting via Trusted or Untrusted non-3GPP access via WLAN as specified in TS 23.402 for MPS. ePDG selection is according to clause 4.5.4 in TS 23.402.
A Service User obtains priority access to the Radio Access Network by using the Access Class Barring mechanism according to TS 36.331 and TS 22.011. This mechanism provides preferential access to UEs based on its assigned Access Class. If a Service User belongs to one of the special access-classes as defined in TS 22.011, the UE has preferential access to the network compared to ordinary users in periods of congestion.
MPS subscription allows users to receive priority services, if the network supports MPS. The same MPS subscription applies to access via 3GPP access and non-3GPP access via WLAN. MPS subscription entitles a USIM with special Access Class(es). MPS subscription includes indication for support of Priority EPS Bearer Service, IMS priority service and CS Fallback priority service support for the end user. Priority level regarding Priority EPS Bearer Service and IMS are also part of the MPS subscription information. The usage of priority level is defined in TS 23.203 and TS 23.228.
An MPS Service User is treated as an On Demand MPS subscriber or not, based on regional/national regulatory requirements. On Demand service is based on Service User invocation/revocation explicitly and applied to the PDN connections for an APN. When not On Demand, MPS service does not require invocation, and provides priority treatment for all EPS bearers for a given Service User after attachment to the EPS network.
Since the Service User has an access class within the range for priority services, the Establishment Cause in RRC connection request is set to highPriorityAccess. When the eNodeB receives mobile initiated signalling with establishment cause set to highPriorityAccess, the eNodeB handles the RRC connection request with priority. When the MME receives and verifies mobile initiated signalling with establishment cause set to highPriorityAccess, the MME establishes the S1 bearer with priority.
The terminating network identifies the priority of the MPS session and applies priority treatment, including paging with priority, to ensure that the MPS session can be established with priority to the terminating user (either a Service User or normal user).
Priority treatment for MPS includes priority message handling, including priority treatment during authentication, security, and location management procedures.
Priority treatment for MPS session requires appropriate ARP and QCI (where necessary for non-GBR bearers) setting for bearers according to the operator's policy.
When an MPS session is requested by a Service User, the following bearer management principles apply in the network:
  • EPS bearers (including default bearer) employed in an MPS session shall be assigned ARP value settings appropriate for the priority level of the Service User.
  • Setting ARP pre-emption capability and vulnerability for MPS bearers, subject to operator policies and depending on national/regional regulatory requirements.
  • Pre-emption of non-Service Users over Service Users during network congestion situation, subject to operator policy and national/regional regulations.
Priority treatment is applicable to IMS based multimedia services, priority EPS bearer services (PS data without IMS interaction) and CS Fallback.
For Multimedia Priority services any EPC functions, procedures and capabilities are provided according to this clause's specification except when specified differently in the following clauses.
Up

4.3.18.2  IMS-based Multimedia Priority Servicesp. 75

4.3.18.2.1  Originating IMS-based MPS Sessionp. 75
IMS based MPS sessions are permitted to be originated from any UE, in addition to MPS-subscribed UEs.
The MPS-subscribed UE, based on the MPS IMS subscription information, operator's policy and national/regional regulations, may be given priority treatment for the default bearer and the EPS bearer carrying IMS signalling in the EPS prior to and during IMS-based MPS invocation. Further, priority treatment in the EPS for signalling and media bearers may be modified/established via dynamic PCC based on the session authorization information received from the AF.
As the IMS media bearer is established after the IMS session of the MPS service has been established, it can be assigned with correct ARP value when it is established. However IMS signalling related EPS bearer needs to be upgraded if it has not been assigned with an appropriate ARP setting for the MPS service when the IMS session of the MPS service has been initiated.
Also to avoid cases where the default bearer may not be allocated resources in the handover case, due to low ARP priority for the PDN connection, it is necessary to assure that the default bearer has an ARP setting appropriate for the MPS service.
Up
4.3.18.2.2  Terminating IMS-based MPS Sessionp. 75
The terminating network identifies the priority of the IMS-based MPS session and applies priority treatment to ensure that the call is delivered with priority to the terminating user (either a Service User or normal user).
If the existing ARP of the default or dedicated EPS bearer that is used to transport IMS signalling are not appropriate for the MPS service, then PCRF updates to the appropriate settings.
S-GW triggers a new priority paging towards MME if the ongoing paging is lower priority than the incoming data received in the S-GW for IMS terminating session.
Up

4.3.18.3  Priority EPS Bearer Servicesp. 75

The Service User receives on demand priority treatment according to its MPS profile, i.e. On-Demand. If the Service User is not authorized to use on-demand priority request, the Service User receives priority treatment (i.e. appropriate ARP and QCI ) at initial attach for all bearers, based on user profile data stored in the HSS/SPR and authorized by the PCRF (see clause 7.2 of TS 23.203).
An On-Demand Service User requires explicit invocation/revocation via SPR MPS user profile update (see clause 7.5 of TS 23.203). Since MPS user profile are part of inputs for PCC rules, the update will trigger PCC rules modification to achieve appropriate ARP and QCI settings for bearers (see clause 7.4.2 of TS 23.203).
When the eNodeB receives mobile initiated signalling with establishment cause set to highPriorityAccess, the eNodeB handles the RRC connection request with priority. When the MME receives and verifies mobile initiated signalling with establishment cause set to highPriorityAccess, the MME establishes the S1 bearer with priority. Based on MPS EPS priority subscription, MME can verify whether the UE is permitted to handle the request preferentially comparing to other UEs not prioritized.
An AF for MPS Priority Service is used to provide Priority EPS Bearer Services using network-initiated resource allocation procedures (via interaction with PCC) for originating accesses.
Up

4.3.18.3a  MPS for Data Transport Service |R17|p. 75

MPS for Data Transport Service is an on-demand service that may be invoked/revoked by an authorized MPS Service User using a UE with a subscription for MPS (i.e. according to its MPS profile), or using a UE that does not have a subscription for MPS (using methods not in scope of this specification).
MPS for Data Transport Service requires explicit invocation. The Service User invokes the service by communicating with an AF. The authorization of an MPS for Data Transport Service request is done by the AF or by the PCRF according to clause 6.1.11.5 of TS 23.203. Upon successful authorization the PCRF performs the necessary actions to achieve appropriate ARP and QCI settings for the bearers (see clause 6.1.11.5 of TS 23.203).
MPS for Data Transport Service enables the prioritization of all traffic on the default bearer and other bearers upon AF request. The QoS modification to the default bearer and other bearers is done based on operator policy and regulatory rules by means of local PCRF configuration.
For MPS for Data Transport Service, the AF may also create an SDF for signalling priority between the UE and the AF (see clause 6.1.11.5 of TS 23.203).
Up

4.3.18.4  CS fallbackp. 76

CS Fallback allows users to fallback to GERAN/UTRAN/1x RTT while in E-UTRAN access thus allowing the network to transfer the call towards GERAN/UTRAN CS domain. In order to ensure that a priority CSFB call to/from a service user is given proper priority treatment in the EPS, MPS subscription indicates the user's CS priority status, i.e. MPS CS Priority, which is provided to MME with user's subscription information. When the eNodeB receives mobile initiated signalling with establishment cause set to highPriorityAccess, the eNodeB handles the RRC connection request with priority. When the MME receives and verifies mobile initiated signalling with establishment cause set to highPriorityAccess, the MME establishes the S1 bearer with priority.
Details on the priority treatment of CSFB, see TS 23.272.
Up

4.3.18.5  Network Congestion Controls for MPS |R11|p. 76

Based on regional/national requirements and network operator policy, MPS shall be exempted from network congestion controls up to the point where further exemptions cause network instability. The MME should not apply NAS level congestion control for mobile initiated signalling with establishment cause set to highPriorityAccess. The MME should not apply congestion control for termination requests related with an ARP associated with MPS.

4.3.18.6  Load Re-balancing between MMEs for MPS |R11|p. 76

When a UE is in ECM-CONNECTED mode with a bearer having an ARP associated with MPS, the MME should not release the UE for load re-balancing, except under critical conditions such as the need to perform an MME node restart. The MME should wait until the UE initiates a TAU or becomes ECM-IDLE before initiating load re-balancing.

4.3.19  Core Network node resolution |R10|p. 76

4.3.19.1  Generalp. 76

The indication of mapped or native GUTI shall be signalled by the UE to the MME as an explicit indication in Attach Request and TAU Request messages. The indication of mapped or native P-TMSI/RAI shall be signalled by the UE to the SGSN as an explicit indication in Attach Request and RAU Request messages. The MME/SGSN resolves the old MME/SGSN using old GUTI respective old P-TMSI/RAI sent in the Attach request and TAU/RAU request messages, and determines if the old GUTI or the old P-TMSI/RAI is mapped or native by one of the following two methods:
  • Indication using most significant bit (MSB) in LAC and MME Group ID.
  • Explicit indication sent from UE to MME and SGSN.
Up

4.3.19.2  MSB in LAC and MME Group IDp. 77

For PLMNs deployed with such mechanism the MME differentiates between a GUMMEI mapped from P-TMSI/RAI and a native GUMMEI based on the value of most significant bit of the MME Group ID; i.e. the MSB is set to "0" then the GUMMEI is mapped from P-TMSI/RAI and if MSB is set to "1", the GUMMEI is a native one, as specified in TS 23.003.
For PLMNs deployed with such mechanism the S4-SGSN differentiates between a P-TMSI/RAI mapped from GUTI and a native P-TMSI/RAI based on the value of most significant bit of the LAC; i.e. the MSB is set to "1" then the P-TMSI/RAI is mapped from GUTI and if MSB is set to "0", the P-TMSI/RAI is a native one, as specified in TS 23.003.
Up

4.3.19.3  Explicit Indicationp. 77

For PLMNs deployed with such mechanism the MME differentiates between a GUTI mapped from P-TMSI/RAI or a native GUTI based on the explicit indication sent by the UE.
For PLMNs deployed with such mechanism the S4-SGSN differentiates between a P-TMSI/RAI mapped from GUTI or a native P-TMSI/RAI based on the explicit indication sent by the UE.

Up   Top   ToC