The SCEF Network Node is defined by 3GPP. The DN SCEF contains the 3GPP SCEF functions (including MTC-IWF and IWK-SCEF), plus we address the 3GPP shortcomings and offer the embedded applications that are part of our DN Platform.
One limitation of the 3GPP standard SCEF is that 3GPP has not defined security mechanisms. Any Enterprise can access any device. DN SCEF can utilize per-Enterprise whitelists to provide security, as illustrated below.
Above, we have illustrated two Enterprises, each with its own UEs. We show one Enterprise and its UEs in the color blue, and the other in the color orange. DN SCEF utilizes per-Enterprise whitelists, allowing only blue-to-blue or orange-to-orange communication.
The figure below presents a logical view of the 3GPP-defined features in DN SCEF. In Release 15, 3GPP defined the name “T8” as the interface for the APIs with SCEF.
As illustrated, there are lots of interfaces and lots of complexity. Fear not, in this primer we are keeping the descriptions simple and not going into the details.
3GPP Features of DN SCEF
In Release 13, 3GPP defined SCEF to be the interface for small data transfers and control messaging between Enterprises and the Operators Core Network. SCEF provides APIs to the Enterprises for the small data transfers and control messages, and uses 3GPP-defined interfaces with the network elements in the Operators Core Network in its performance of its functions. The major features of SCEF are the following.
- APIs and AAA
- External ID
- Exposing Capabilities for New Revenue
Briefly, the highlights of these features are as follows.
SCEF offers APIs to the Enterprise, making it easy for the Enterprise to develop applications that may benefit from network information. For example, an application may want to know if a UE is currently reachable. If it is not, then have SCEF send a notification to the application when the UE becomes reachable.
The APIs themselves were not to be defined by 3GPP. Instead, 3GPP had deferred to industry groups like OMA and OneM2M. However, after a couple of years with little action by the industry groups, 3GPP decided to define the APIs in Release 15. API definitions began in 2017, and 3GPP quickly realized that a Common API Framework (CAPIF) would be necessary for several issues, including AAA (Authentication, Authorization and Accounting). These issues are being addressed in 3GPP TS 23.222.
While Accounting for API usage by Enterprises is new to 3GPP, all 3GPP network nodes may perform some 3GPP accounting for UEs. As for other 3GPP network nodes, 3GPP has defined some Charging Events for SCEF. These events are limited to NIDD and Monitoring events.
The APIs do not require MSISDN to identify the UE. The Enterprise may use an external ID, e.g., email@example.com. SCEF interrogates the HSS to get the 3GPP identifier that is associated with the external ID. This provides convenience, flexibility and MSISDN security for the Enterprise.
NIDD is a simple idea, i.e., just have APIs to transfer data between SCEF and the AS. However, complexities abound. It starts with registration procedures. Both the UEs (and IoT forecasts are to have billions of devices) and the AS need to register with the SCEF. Then there is the data transfer itself. It is not simple data forwarding, since every transfer requires state maintenance while waiting for the transfer to be acknowledged. Moreover, the destination might not be reachable, in which case, buffering and delayed delivery is one of the 3GPP options.
The exposed capabilities can be easily monetized by the Operator. For example, for sensors to have a 10-year battery life, their batteries must be monitored and adjustments may need to be done to the timers that affect battery life. SCEF exposes an API for adjusting the timers, and the Operator can charge its customers for using the API.
Exposing Capabilities for New Revenue
As mentioned above in the APIs and AAA section, APIs expose network capabilities and Operators may charge for using the APIs. The APIs enable many use cases for applications by the Enterprise.
- Device Trigger Delivery
- Sponsored Data
- UE Reachability and Monitoring
- Inform 3rd Party of Network Issues
- UE Footprint
- Set QoS for UE Session
- 3rd Party Interaction for UE Patterns
- Group Message Delivery
- Background Data Transfer
- Packet Flow Descriptor (PFD) Management
- MSISDN-less MO-SMS
- Enhanced Coverage Restriction Control
- Network Configuration Parameters
A brief description of these use cases follows:
A device trigger request is intended for the AS to wake-up and notify a UE to connect to the AS for instructions. The trigger would include a small amount of information, e.g., the URL that the UE should use as a destination.
Trigger delivery is a two-step process. First, SCEF replies to the delivery request as to whether the request has been accepted by the SCEF. Later, the AS receives a delivery receipt, either via a notification from SCEF or by polling SCEF.
This feature allows the Enterprise to change the billing party of a session. For example, consider a UE playing an online game and deciding to purchase a subscription from the gaming Enterprise. The Enterprise can use an API to change the billing of the online game session so that the UE is not billed for the remainder of the gameplay.
There are many options for this feature. Here are some examples of what the enterprise might want to know.
Is the UE reachable for IP Data or just SMS, or neither? Is the UE roaming? I just sent data to the UE, but the sending failed so please send me a notification when the UE becomes reachable.
With this feature, SCEF can inform the Enterprise whether UE reachability issues are due to the network or the UE itself.
This allows the Enterprise to request a different QoS for a particular session.
Knowing which UEs are in a particular geographic region has great potential benefit to emergency services.
The Enterprise can inform the Operator of patterns of a UE, so the Operator can better tune the network. For example, particular UEs might always be fixed instead of mobile.
This feature uses MBMS, allowing the Enterprise to establish multicast channels to UEs in particular geographic regions.
When the Enterprise has bulk data to transfer, SCEF can offer specific time windows with different billing options to the Enterprise.
In 3GPP Release 14, 3GPP defined the Packet Flow Description Function (PFDF), and the Nu-interface between the PFD Management capability of SCEF and PFDF.
In 3GPP Release 14, 3GPP added the capability for devices to originate SMS messages without having an MSISDN. The call flow for these messages from device goes through SCEF.
In 3GPP Release 14, 3GPP defined enhanced coverage restriction, with SCEF as the entry point for the SCS/AS to get status or make changes.
In 3GPP Release 15, 3GPP moved the capability of setting timers related to Power Saving Mode (PSM) and Extended Discontinuous Reception (eDRX) from the Monitoring feature of SCEF to this new feature.
There are many 3GPP documents related to SCEF functionality, and many details of 3GPP-defined functionality are available. Here, we have just touched on many of the aspects. Hopefully, the enormity of the opportunities created by SCEF, as well as, the complexity involved in SCEF are now apparent. NIDD has resulted in a requirement for SCEF deployment to support LPWA technologies like NB-IoT. In addition, a multitude of new APIs offer the opportunity to generate new revenue.
Despite the above, a 3GPP standard SCEF is hampered by limitations in the 3GPP specifications. With the improvements over 3GPP provided by the DN SCEF, along with the applications of our DN Platform, the DN SCEF has become the front runner for SCEF and related technology.