Tech-invite
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.682  Word version:  16.8.0

Top   Top   Up   Prev   Next
1…   4.2   4.3…   4.4…   4.5…   4.5.7…   4.5.14…   4.6…   5…   5.3…   5.5…   5.6…   5.6.2…   5.6.6…   5.7…   5.8…   5.9…   5.13…   5.14…   5.15   5.16   5.17…   5.18   5.19…   A…   C…

 

4.5.14  Non-IP Data Delivery (NIDD) |R13|

4.5.14.1  General |R14|

Functions for NIDD may be used to handle mobile originated (MO) and mobile terminated (MT) communication with UEs, where the data used for the communication is considered unstructured from the EPS standpoint (which we refer to also as Non-IP). The support of Non-IP data is part of the CIoT EPS optimizations. The Non-IP data delivery to SCS/AS is accomplished by one of two mechanisms:
  • Delivery using SCEF;
  • Delivery using a Point-to-Point (PtP) SGi tunnel.
The delivery using a Point-to-Point (PtP) SGi tunnel is further described in TS 23.401.
NIDD via the SCEF is handled using a PDN connection to the SCEF. The UE may obtain a Non-IP PDN connection to the SCEF either during the Attach procedure (see TS 23.401, clause 5.3.2.1) or via UE requested PDN connectivity (see TS 23.401, clause 5.10.2) or via PDP Context Activation Procedure (see TS 23.060, clause 9.2.2.1).
An association between the SCS/AS and a PDN Connection to the SCEF needs to be established to enable transfer of non-IP data between the UE and the SCS/AS. When the Reliable Data Service is not enabled, the SCEF determines the association based on provisioned policies that may be used to map an SCS/AS identity and User identity to an APN. When the Reliable Data Service is enabled, the SCEF determines the association based on port numbers and provisioned policies that may be used to map SCS/AS identities and User identity to an APN (see clause 4.5.14.3).
NIDD via SCEF uses the User Identity, APN, and the SCS/AS identity to identify which UE a particular T6a/T6b connection belongs to. The User Identity is the user's IMSI. The user's IMSI shall not be used on the interface between SCEF and SCS/AS. In order to perform NIDD configuration or to send or receive NIDD data, the SCS/AS shall use MSISDN or External Identifier to identify the user. In order to facilitate correlation of SCS/AS requests to T6a/T6b connection for a given UE, the HSS provides to the SCEF (see NIDD Configuration procedure in clause 5.13.2) the user's IMSI, and if available, the MSISDN (when NIDD Configuration Request contains an External Identifier) or if available, External Identifier (when NIDD Configuration Request contains an MSISDN).
Depending on operator configuration, the SCEF may perform buffering of MO and/or MT Non-IP data. In this release of specification, neither the MME/SGSN nor the IWK-SCEF are expecting to buffer data pertinent to PDN connection to the SCEF.
The Protocol Configuration Options (PCO) may be used to transfer parameters between the UE and SCEF (e.g. maximum packet size). The PCO's information shall be passed transparently through the MME/SGSN. As specified in TS 23.401 and TS 23.060, the PCO is sent in the EPS Session Management signalling between UE and MME and in GPRS Session Management signalling between UE and SGSN.
The SCEF applies rate control as described in TS 23.401, clause 4.7.7.
Up

4.5.14.2  Enhancements for reliable delivery of NIDD |R14|Word‑p. 36

To ensure reliable delivery of Non-IP data (NIDD) between UE and SCEF using the Control Plane CIoT EPS Optimization, the following functions may be supported by the 3GPP system:
  • Reliable delivery by acknowledgements on a hop-by-hop basis, i.e. the link layer protocol on each interface used for NIDD uses acknowledgments and nodes apply retransmissions if needed to ensure reliable delivery.
  • The UE may retransmit UL data that was not acknowledged by the RLC on the AS layer in the UE;
  • The MME may retransmit DL data for which it got a non-delivery indication from the eNodeB (see e.g. TS 23.401, clause 5.3.4B.3, step 15);
  • The MME indicates to the SCEF the status of the DL data delivery. The SCEF may forward this status to the AS;
  • Disabling/enabling of MME retransmission is handled by a subscription parameter 'Acknowledgements of downlink NAS data PDUs'.
Up

4.5.14.3  Reliable Data Service |R14|

The Reliable Data Service may be used by the UE and SCEF or P-GW when using PDN Connection of PDN Type 'Non-IP'. The service provides a mechanism for the SCEF or P-GW to determine if the data was successfully delivered to the UE and for UE to determine if the data was successfully delivered to the SCEF. When a requested acknowledgement is not received, the Reliable Data Service retransmits the packet. The service is enabled or disabled based on APN Configuration per SLA.
When the service is enabled, a protocol is used between the end-points of the Non-IP PDN Connection. The protocol uses a packet header to identify if the packet requires no acknowledgement, requires an acknowledgement, or is an acknowledgment and to allow detection and elimination of duplicate PDUs at the receiving endpoint. Reliable Data Service supports both single and multiple applications within the UE. Port Numbers in the header are used to identify the application on the originator and to identify the application on the receiver. The UE, the SCEF and the P-GW may support reservation of the source and the destination port numbers for their use and subsequent release of the reserved port numbers. Reliable Data Service protocol (as defined in TS 24.250) also enables applications to query their peer entities to determine which port numbers are reserved and which are available for use at any given time.
During NIDD Configuration, the SCS/AS may indicate which serialization formats it supports for mobile originated and mobile terminated traffic in the Reliable Data Server Configuration. When port numbers are reserved by the UE, the serialization format that will be used by the application may be indicated to the SCEF. When port numbers are reserved by the SCEF, the serialization format that will be used by the application may be indicated to the UE. If the receiver does not support the indicated serialization format, it rejects the port number reservation request and the sender may re-attempt to reserve the port number with a different serialization format. If, during NIDD Configuration, the SCS/AS indicated that it supports multiple serialization formats, the SCEF determines the serialization format that it will indicate to the UE based on local policies and previous negotiations with the UE (e.g. the SCEF may indicate the same serialization format that was indicated by the UE or avoid indicating a serialization format that was previously rejected by the UE). When serialization formats are configured for reserved port numbers, the SCEF stores the serialization formats as part of the Reliable Data Service Configuration and provides the updated Reliable Data Service Configuration to the SCS/AS.
The UE indicates its capability of supporting Reliable Data Service in the Protocol Configuration Options (PCO) to the SCEF or P-GW. If SCEF or P-GW supports and accepts Reliable Data Service then it indicates to the UE, in the PCO, that the Reliable Data Service shall be used if enabled in the APN configuration.
In order to prevent situations where a Reliable Data Service instance needs to interface to both the user and control plane, the Reliable Data Service may only be used with PDN connections for which the "Control Plane Only" indicator is set or with PDN connections using the Control Plane EPS CIoT Optimization when the MME does not move PDN connections to the user plane. The Control Plane CIoT EPS Optimization is defined in TS 23.401.
Up

4.5.15  Support of PFD management via SCEF |R14|Word‑p. 37

The PFDs may be managed by the 3rd party SCS/AS via the SCEF, which ensures the secure access to the operator's network even from the 3rd party SCS/AS in untrusted domain. The 3rd party SCS/AS may request to create, update or remove PFDs in the PFDF via the SCEF.
The specific procedure for PFD management via SCEF is described in clause 5.14.1.

4.5.16  MSISDN-less MO-SMS via T4 |R14|

MSISDN-less MO-SMS via T4 is subscription based. The subscription provides the information whether a UE is allowed to originate MSISDN-less MO-SMS. Support for subscription without MSISDN is defined in TS 23.012.
The UE is pre-configured with the Service Centre address that points to SMS-SC that performs this MO-SMS delivery via MTC-IWF delivery procedure. The recipient of this short message is set to the pre-configured address of the SCS/AS (i.e. Address of the destination SME). If UE has multiple external IDs associated to the same IMSI, the external ID that is associated with an SMS may be determined from the UE's IMSI and the Application Port ID value in the TP-User-Data field (see TS 23.040). The MTC-IWF may obtain the external-ID by querying the HSS with the IMSI and application port ID via S6m.
UE is aware whether the MO-SMS delivery status (success or fail) based on the SMS delivery report from SMS-SC. The network does not perform any storing and forwarding functionality for MO-SMS.
Up

4.5.17  Enhanced Coverage Restriction Control via SCEF |R14|

Restriction of use of the Enhanced Coverage is specified in TS 23.060 and TS 23.401
The support for Enhanced Coverage Restriction Control via SCEF enables 3rd party service providers to query status of, enhanced coverage restriction or enable/disable enhanced coverage restriction per individual UEs. The specific procedure for Enhanced Coverage Restriction Control via SCEF is described in clause 5.16.
Up

4.5.18  MBMS user service for UEs using power saving functions |R14|

MBMS Bearer Services as defined in TS 23.246 together with MBMS User Services defined in TS 26.346, or MBMS Bearer Services accessed via the MB2 interface defined in TS 23.468, provide means to deliver data or triggering payload over broadcast to multiple UEs at the same time. However, for devices using power saving functions, e.g. Power Saving Mode (defined in clause 4.5.4) or extended idle mode DRX (defined in clause 4.5.13), the UEs are usually unreachable for long periods of time. Moreover, different UEs are likely to be reachable at different times. Therefore, it is important that the time intervals the UE stays awake to receive MBMS user service or to discover if there is any MBMS user service scheduled for delivery, should not necessarily be the same as the reachable intervals negotiated for extended idle mode DRX or PSM.
If a UE becomes unreachable for unicast service due to either PSM or extended idle mode DRX, the UE may still perform MBMS specific procedures, e.g. activation/deactivation of the MBMS bearer service, MBMS data transfer reception, reception of service announcement (if needed), as defined in TS 23.246 and TS 26.346.
For those intervals the UE needs to be awake for MBMS bearer service, the following cases can be identified:
  1. When the UE's need to be awake due to MBMS coincides with the UE already being in connected mode due to other reasons, the UE follows normal connected mode procedures.
  2. When the UE's need to be awake due to MBMS coincides with the UE already being in idle mode and reachable (e.g. in active time for PSM or PTW for eDRX) the UE follows normal idle mode procedure.
  3. When the UE's need to be awake due to MBMS coincides with the UE being in idle mode and in deep sleep, i.e. unreachable for paging to the network, the UE leaves the deep sleep state only to perform procedures related to MBMS service.
    • If the MBMS user service does not require the UE to transition to connected mode, i.e. the UE receives MBMS user service in idle mode, then the UE does not update the MME to become reachable for paging. The UE would therefore still be considered unreachable for paging in the MME. This minimizes the signalling between the UE and the network.
    • If the MBMS user service requires the UE to transition to connected mode (e.g. for HTTP reception reporting, file repair, etc.) then the UE performs regular procedures for ECM connected mode. This would therefore make the UE become reachable in the network for other unicast services.
  4. When the UE is in the middle of an MBMS data transfer, and the UE is scheduled to move to deep sleep due to power saving, e.g. end of PTW for extended idle mode DRX or expiration of active time for PSM, then the UE does not go to deep sleep during the remainder of the current MBMS data transfer.
There are two possible ways the UE can be notified of an upcoming MBMS broadcast session start:
  1. If MBMS User Services defined in TS 26.346 is used, the UE needs to receive MBMS service announcement while awake (i.e. while in connected mode, or while idle mode during PTW for extended idle mode DRX, or active time for PSM). The UE wakes up if not already awake for MBMS service reception based on the schedule received in the service announcement. For this option, the MBMS service announcement may be provided via MBMS broadcast service announcement or via any of the possible unicast service announcement delivery mechanisms defined in TS 23.246. If MBMS access via the MB2 interface as defined in TS 23.468 is used, similar mechanisms need to be provided by the application layer using unicast mechanisms.
  2. The UE may be configured by the application server with specific times to perform MBMS procedures, and wakes up from deep-sleep if needed at those times. The UE may also receive MBMS service announcements and/or MBMS broadcast delivery at those times (if needed).
Up

4.5.19  Enhancements to Location Services for CIoT |R14|Word‑p. 39

Location Services (LCS) are defined in TS 23.271. In order to support Location Services for CIoT UEs, following enhancements to Location Services are defined (refer to TS 23.271 for detailed procedures):
  • Deferred location for the UE availability event:
    • When extended idle mode DRX or PSM is used, a deferred location request for UE available event allows an LCS Client to obtain the UE location as soon as the UE becomes available.
    • The procedures for deferred location from V-GMLC to the external client and the EPC Mobile Terminating Location Request (EPC-MT-LR) procedure are combined properly in the V-GMLC as specified TS 23.271.
  • Indication of UE RAT type and/or coverage level to Evolved Serving Mobile Location Centre (E-SMLC):
    • Providing an E-SMLC with an indication of the RAT type and/or the coverage level may enable the E-SMLC to appropriately determine a maximum size, maximum frequency and maximum transfer delay for positioning messages sent to and from the UE.
    • RAT type and coverage level indications from the MME to the E-SMLC are introduced in TS 23.271.
    • For the case of coverage level, and indication of coverage level from eNB to MME is introduced.
  • Support of UE positioning measurements in idle mode:
    • NB-IoT UEs or Cat-M1 UEs may perform measurements for some positioning methods only when in ECM-IDLE state due to minimal resources.
    • An E-SMLC that is aware of this (e.g. from an indication sent by the UE) may allow additional response time to the UE (e.g. in the QoS) to obtain the measurements. An MME that is aware of this (e.g. from the UE access type) may also allow additional time for a location session to complete.
  • Addition of Periodic and Triggered Location for EPC:
    • A flexible periodic and/or triggered Mobile Terminated Location Request (MT-LR) capability is useful to enable UE location at times other than when a UE normally becomes available and/or with better granularity than a cell ID.
    • New procedures are introduced in TS 23.271 to initiate and maintain deferred periodic and triggered event reporting and to cancel reporting by an LCS client, UE or network entity. The area event, periodic event and motion event are clarified in the context of EPC access. Impacts to LCS messages between an LCS Client and GMLC, between GMLCs and between an H-GMLC and PPR are included.
  • Support of Last Known Location for a UE that are unreachable for long periods of times:
    • For UEs that are unreachable for long periods of time, e.g. using extended idle mode DRX or PSM, last known location support enables an external LCS client to receive some information on UE location without waiting (e.g. a few hours) for the UE to become reachable.
    • The EPC-MT-LR procedure defined in TS 23.271 is enhanced to support last known location based on a last known serving cell.
Up

4.5.20  MBMS user service for NB or M UE categories |R14|

TS 36.306 defines UE categories M1, M2 for WB-E-UTRAN and NB1, NB2 for NB-IoT that can only support limited bandwidth and transport block size. In order for UEs of these categories to be able to receive MBMS service, E-UTRAN needs to be able to determine the UE category that applies to the specific service indicated by the TMGI.
In order for E-UTRAN to know the UE categories for MBMS bearer service, the UE Capability for MBMS (which includes UE Category for MBMS and optionally associated coverage level for MBMS) is provided by SCS/AS to the BMSC via the SCEF. Using PLMN specific QCI information, the characteristics are signalled by the BM-SC to E-UTRAN following the procedures described in clause 5.5.1 of the present specification and TS 23.246. This includes:
  • QCI(s) that are determined taking into account the UE Category for MBMS that indicates the "M" or "NB" category (M1, M2, NB1, NB2) as defined in TS 36.306 that can receive the service indicated by the TMGI. E-UTRAN uses the QCI to determine the radio parameters that would determine the categories of UEs that are required to receive the service. EUTRAN is configured with the QCI to UE Category for MBMS mapping.
  • Optionally, the SCS/AS may provide additional information regarding the coverage level for the related MBMS service. The coverage level indicates if the MBMS service is intended to be received by UEs located in extended coverage and is used by E-UTRAN to determine the radio configuration required, e.g. determine the number of repetitions, to reach the UEs that receive the MBMS service. Three levels of Coverage Level for MBMS are defined as "normal", "medium" and "high". The coverage level information, when provided, shall be reflected via the QCI.
Up

4.5.21  Network Parameter Configuration via SCEF |R15|Word‑p. 40

The SCS/AS may issue network parameter configuration requests to the network, via the SCEF, to suggest parameter values that may be used for Maximum Latency, Maximum Response Time and Suggested Number of Downlink Packets. By suggesting values for these parameters, the SCS/AS may influence certain aspects of UE/network behaviour such as the UE's PSM, extended idle mode DRX, and extended buffering configurations. Based on operator's configuration, the SCEF and HSS may choose to accept, reject or modify the suggested configuration parameter value. The SCEF indicates accepted/modified values to the SCS/AS. This feature can also be used to suggest parameter values for a group of UEs.
The specific procedure for Network Parameter Configuration via SCEF is described in clause 5.18.
Up

4.5.22  RACS information provisioning |R16|

The UCMF (UE radio Capability Management Function) stores all UE Radio Capability ID mappings in a PLMN and is responsible for assigning every PLMN-assigned UE Radio Capability ID in this PLMN, see TS 23.401. Provisioning of Manufacturer-assigned UE Radio Capability ID entries in the UCMF is performed from an AS that interacts with the UCMF either directly (according to TS 23.502 and TS 29.675) or via the SCEF (according to TS 29.122 or via Network Management).
Up

Up   Top   ToC