NB-IoT NIDD via SCEF

NIDD (Non-IP Data Delivery) is defined by 3GPP in several documents. We have extracted a summary of the relevant content here, from the December 2017 versions of the 3GPP Release 15 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.

APIs for NIDD are specified by 3GPP in Release 15. The APIs may be optionally secured by SCEF and the AS with a secure server.

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.

  1. AS registers itself for a particular UE. This API may include a downlink data message for the UE. Load information (e.g., number of NIDD messages and NIDD time duration) is expected in this API.
  2. SCEF performs authentication and authorization. SCEF may downgrade the load information, if the specified load exceeds the local limits maintained in the SCEF’s configuration.
  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. If there is a downlink data message for the UE in the API of Step 1, it is delivered to the UE per the call flow for downlink NIDD messages.

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

  1. The UE attaches, indicating a desired connection for non-IP data. 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. 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 the 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.

  1. AS uses an API to submit the NIDD request.
  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.
  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:
    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; however, the MME only receives notification that the UE was successfully paged and does not know if the UE successfully received the data.
  5. MME sends an answer to SCEF. If delivery was not successful due to UE not being reachable, SCEF registers with MME via T6a to be notified when the UE becomes reachable and SCEF delays the delivery.
  6. SCEF sends a response to the AS.

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

  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.
  4. AS sends a response.
  5. SCEF sends an answer to MME.
  6. The downlink NIDD procedure is used when the Reliable Data Service has been enabled and the UE had requested an acknowledgement that its uplink NIDD had been received.

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 room for improvement in the current specifications, as well as, 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 Solutions.