3GPP SCEF Primer
SCEF (Service Capability Exposure Function) is defined by 3GPP in Release 13. 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 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. 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.
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 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., 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.
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 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.