Where is SCEF based Non IP Data Delivery Useful?

Having looked at the key system architecture optimizations introduced by 3GPP in release 13 for cellular IoT (here and here), lets now look at where the new SCEF based non IP data delivery (NIDD) is useful.

Most of the IoT applications that run on the IoT devices today directly talk to the application service via public network and security has been highly disregarded in most of these applications. Due to this, in the last year, there have been numerous instances of IoT malwares launching distributed denial of service (DDoS) attacks on many prominent web services. It is not expected that the IoT device manufacturers and application writers become security experts. This is where, for service provider based LPWAN IoT devices, NIDD via SCEF offers a secure solution and narrows down the threat vector. Lets see how.

The SCEF based non IP PDN setup and application configuring for NIDD delivery are explained in sections 5.13.2 and 5.13.1 of TS 23.682.

As can be seen, for the application service to be authorized,  it has to go through an on boarding process, and then for each UE towards which the application needs to communicate, it has to do an NIDD Configuration Request. During the NIDD Configuration Request procedure, the SCEF authorizes whether the application server is allowed to access the UE. This step makes sure that any rogue malware is not directly communicating with the UE and installing malware on it to launch a DDoS attack. Since the PDN uses non IP payload (e.g OMA is discussing LWM2M binding over 3GPP NAS in Annex J of its draft 1.1 release of the LWM2M Technical Specification) and the fact that the NAS is encrypted, no IP based application can directly access UE. The communication between the UE and the SCEF will be non IP while the application can use RESTful HTTP APIs (over IP) to communicate with the SCEF.  SCEF in this case, essentially acts as an IoT application gateway between the IoT devices and the applications. All security policies can be controlled through the SCEF.

But a question arises, where these application oboarding process, API for NIDD configuration request are defined. As of Release 13 and 14, these were not in scope of 3GPP. However 3GPP SA plenary agreed a WID last week (SP‑170240) for SA2 to work on defining northbound APIs from SCEF for NIDD and also a study item (SID) to define a common API framework for northbound APIs (SP‑170279).

In order for secure IoT devices / applications via cellular IoT / LPWAN technologies to be successful, the following are necessary

1. Operators providing SDKs for IoT device manufacturers to write non IP based applications that can communicate with the operator SCEF
2. Standardized APIs northbound of SCEF for application writers to interface with SCEF
3. Viable business agreements between operators and application developers for revenue share and accelerated innovation
1. Possibly an experimental / developer test API interface exposed at limited period free subscription / low cost option could help application developers to quickly experiment an idea.
2. AT&T already provides APIs for writing applications and communicating with the devices - https://m2x.att.com/ and they provide a free trial as well.

Other use cases of SCEF based NIDD:

1. Circuit switch based SMS infrastructure can now be slowly reach a sunset.
2. SMS can be sent as a non IP data via SCEF by an application. Instead of using MSISDN to reach the UE for mobile terminated SMS, the UE external Identifier can be used.
3. However sending SMS via NIDD path requires a non IP PDN to be established by the UE, unlike the traditional SMS, where a PDN is not necessary.