3GPP SCEF Primer
SCEF (Service Capability Exposure Function) is defined by 3GPP in Release 13, with enhancements in Release 14 and Release 15. Here, we provide a tutorial of SCEF.
History of SCEF
The first version of 3GPP TS 23.682 (Architecture for enhancements to facilitate communications with packet data networks and applications) for Release 13 was published in December 2014. In that version of the document, the definition of SCEF was provided:
The Service Capability Exposure Function (SCEF) is the key entity within the 3GPP architecture for service capability exposure that provides a means to securely expose the services and capabilities provided by 3GPP network interfaces.
That definition has remained the same since that initial version of the document, but the services and capabilities has drastically changed. Initially, only device triggers were defined – we’ll describe that and all the capabilities further down on this web page. Later, more capabilities were added, mostly for the SCEF to do monitoring and provide notifications of desired events to the AS (Application Server) regarding a UE.
To increase their market share of IoT devices, MNOs want IoT devices to directly connect to broadband cellular networks. For that to happen, new modem technology is necessary. Modems need to be low cost, and also use less power to extend battery life. 3GPP has embraced several LPWA (Low Power Wide Access) technologies, such as, NB-IoT. To help meet the requirement of low power, the power-hungry protocol to establish IP data bearers has been replaced by extending the NAS protocol to allow small amounts of data to be transferred over the control plane. The IP stack is not necessary, so this type of transfer has been named NIDD (Non-IP Data Delivery).
The path for NIDD between UE and AS is defined by 3GPP to traverse the MME and SCEF.
This has caused a turn-around in the demand for SCEF. Initially, the exposing of capabilities was to facilitate Operators being able to charge for use of those capabilities. From the perspective of Operators, SCEF was regarded as a nice to have opportunity. Now, Operators need the SCEF so that LPWA technologies like NB-IoT can be deployed. And so,
SCEF in the Network
Below we illustrate a typical IoT core network, which could be provided either by an MVNO or by the MNO itself.
SCEF may reside at the edge of the IoT domain as shown above, or SCEF may lie completely within the IoT domain interfacing with an external API Management platform at the edge.
The figure below presents a logical view of the 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.
Features of 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
We present the highlights of these features in the sections below.
SCEF offers RESTful 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.
3GPP originally intended for the APIs themselves to be defined by industry groups like OMA and OneM2M. However, that never came to be, so in Release 15, 3GPP is defining the APIs, and these APIs are called the T8 interface.
Authentication and Authorization are not standardized by 3GPP, but 3GPP recognizes that these functions must be performed if SCEF is connected to Enterprises that are in an untrusted domain. Similarly, there may be a need for encryption. For these needs, SCEF and Enterprises might use OAuth2 with a secure server to get these parameters for formatting/processing of the APIs.
For Accounting, the model is straightforward, albeit, the details are not all completed. The 3GPP network elements continue to generate charging events or CDRs for activity regarding a UE, e.g., for sending an SMS message to a UE. Charging events for NIDD and Monitoring by SCEF have been defined. SCEF may also charge for API usage, but such definition is outside of the scope of 3GPP.
The APIs do not require MSISDN to identify the UE. The Enterprise may use an external ID, e.g., firstname.lastname@example.org. 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.
In Release 14, 3GPP added an option for providing a Reliable Data Service (RDS) using NIDD. In Release 15, 3GPP added a group delivery option for NIDD, where SCEF replicates NIDD messages for delivery to each UE that is a member of a targeted group.
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 (DTR)
- 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 Parameter Configuration
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.
Many aspects are for optimizing High Latency Communications (HLCOM). To extend battery life, devices may use Power Saving Mode (PSM) or eDRX (extended Discontinuous Reception) cycles. SCEF’s monitoring capabilities are ideal for helping the Enterprise communicate with these devices that might be in deep sleep.
With this feature, SCEF can inform the Enterprise whether UE reachability issues are due to the network or the UE itself.
Knowing which UEs are in a particular geographic region has great potential benefit to emergency services.
This allows the Enterprise to request a different QoS for a particular session.
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 Release 14, 3GPP introduced the concept of Packet Flow Descriptors (PFDs). SCEF is the interface to the Enterprise for managing the PFDs.
In Release 14, 3GPP defined the capability of UEs without MSISDNs to initiate SMS messages, which get forwarded by SCEF to the Enterprise.
In Release 14, the Enterprise can enable or disable the enhanced coverage restriction of the UE, via the SCEF.
In Release 15, 3GPP separated this capability from the aforementioned Monitoring capabilities of the SCEF. To modify the timers associated with HLCOM, Enterprises should use Network Parameter Configuration APIs instead of Monitoring APIs with the SCEF.
There are many 3GPP documents related to SCEF functionality, and many details are available. In this primer, 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.
For a glimpse into some of the challenges with an SCEF solution, please visit Our Solution for MNOs and MVNOs.