3GPP NIDD via SCEF for NB-IoT

NIDD (Non-IP Data Delivery) is defined by 3GPP in several documents. We have extracted a summary of the relevant content here, from the September 2017 versions of the 3GPP documents.

Before a NIDD transfer via SCEF can be performed, two registration steps are required: one by the AS (Application Server) and one by the UE (User Equipment).

  • AS must register with SCEF, assigning itself as the AS for a particular UE.
  • UE must register with SCEF, indicating the availability of a bearer (e.g., a connection between SCEF and MME) for SCEF to reach the UE.

SCEF uses both the S6t-interface and the T6-interface as part of the registration procedures.

The S6t-interface is between SCEF and HSS. The Diameter commands are defined in 3GPP TS 29.336, and the commands related to NIDD are the following.

  • NIR (NIDD Information Request), from SCEF to HSS.
  • NIA (NIDD Information Answer), from HSS to SCEF.

The T6a-interface is between the MME/C-SGN and SCEF. The T6b-interface is between the SGSN and SCEF. Regardless of whether the MME, C-SGN or SGSN is involved, the Diameter messages are identical. So for simplicity of discussion, we just use T6a in our descriptions here, and we only use MME, i.e., not “MME/C-SGN”.

The T6a-interface Diameter commands are defined in 3GPP TS 29.128, and the commands related to NIDD are the following.

  • CMR (Connection Management Request), from MME to SCEF.
  • CMA (Connection Management Answer), from SCEF to MME.
  • ODR (MO Data Request), from MME to SCEF.
  • ODA (MO Data Answer), from SCEF to MME.
  • TDR (MT Data Request), from SCEF to MME.
  • TDA (MT Data Answer), from MME to SCEF.

Call flows are defined in 3GPP TS 23.682.

The AS and UE information are registered with the SCEF using two different call flows: the AS needs to register with the SCEF, and the UE needs to register with the SCEF.

AS registration is called the NIDD Configuration Procedure, and its call flow is as follows.

NIDD Configuration Procedure
  1. AS registers itself for a particular UE. The registration request may include data to be delivered to the UE, in which case, the AS includes instructions to the SCEF as to how to proceed if the UE has not yet registered with the SCEF.
  2. SCEF performs authentication and authorization.
  3. SCEF sends a NIDD Information Request to HSS.
  4. HSS sends a NIDD Information Answer. The answer includes the UE’s 3GPP identifier, since the request may have used an external-id.
  5. SCEF responds to the AS.

UE registration is called the T6a Connection Establishment Procedure, and its call flow is as follows.

T6a Connection Establishment Procedure
  1. The UE attaches, indicating a desired connection for non-IP data, with an APN that is associated with an SCEF. This registers the UE with the MME. The attach request may include PCOs (Protocol Configuration Options) from the UE.
  2. MME sends a Connection Management Request to SCEF, which includes NIDD rate control parameters for SCEF to use when performing NIDD transfers with the UE. The PCOs (if present) are included in an Extended-PCO AVP within the message to SCEF.
  3. If an AS has not already registered with the SCEF for that UE, SCEF may either reject the Connection Management Request, or SCEF may initiate an implementation-specific NIDD Configuration Procedure for an AS.
  4. SCEF sends a Connection Management Answer. This may include PCOs from SCEF for the UE in an Extended-PCO AVP within the message.

The call flow for downlink NIDD (AS to UE) is the following.

Downlink NIDD
  1. AS uses an API to submit the NIDD request. There are significant options with the API, including maximum latency and priority, and use of Reliable Data Service (defined in 3GPP Release 14) is desired.
  2. As part of its authorizing of the request, SCEF may impose rate-control to limit the number of requests and/or aggregate amount of data from the AS for a particular UE. SCEF may also impose per-APN rate-control.
  3. If the UE has registered with the SCEF, SCEF forwards the request to MME. Otherwise, the SCEF may either return an error to the AS or perform either of two delivery procedures that are not yet fully specified by 3GPP:
    1. Use SMS to cause the UE to attach.
    2. Respond immediately to the AS indicating delivery will be delayed, and wait until the UE attaches and then continue with the remaining delivery steps.
  4. MME delivers the data to the UE. If the eNodeB supports delivery acknowledgments, and if the UE’s subscription includes data acknowledgments, the MME will note whether or not the data delivery has been acknowledged.
  5. MME sends an answer to SCEF. If delivery was not successful due to UE not being reachable, MME will later send a notification to SCEF when the UE is reachable, and SCEF should re-attempt at that time.
  6. SCEF sends a response to the AS.

The call flow for uplink NIDD (from UE to AS) is the following.

MO NIDD
  1. UE sends data to MME.
  2. MME forwards to SCEF.
  3. SCEF delivers to AS, using the callback provided by the AS during the registration step earlier. 3GPP is still considering whether SCEF may aggregate multiple indications per AS.
  4. AS sends a response. If AS has downlink data to send (perhaps an application layer acknowledgment), AS initiates the downlink NIDD procedure.
  5. SCEF sends an answer to MME.
  6. If the Reliable Data Service is enabled, SCEF delivers an acknowledgment to the UE via the MME.

Buffering of Mobile-Terminated and Mobile-Originated non-IP data packets improves the quality of 3GPP network services. In cases of non-delivery of NIDD, SCEF may use local configuration to decide whether to buffer the data and deliver later when the conditions become suitable.

As may be apparent to some readers, there is a need to address many critical areas not mentioned in the specifications. We at Definition Networks welcome the opportunity to provide discussion on these topics, including the benefits provided by our solution. Please take a look at Our Solution for MNOs and MVNOs.