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 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.

nidd

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-needed-for-nidd

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-in-network

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.

scef-logical-view

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
  • NIDD
  • Exposing Capabilities for New Revenue

We present the highlights of these features in the sections below.

APIs and AAA

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.

External ID

The APIs do not require MSISDN to identify the UE. The Enterprise may use an external ID, e.g., name-of-device@domain.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

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

A brief description of these use cases follows:

Device Trigger Delivery

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.

Sponsored Data

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.

UE Reachability and Monitoring

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.

Inform 3rd Party of Network Issues

With this feature, SCEF can inform the Enterprise whether UE reachability issues are due to the network or the UE itself.

Set QoS for UE Session

This allows the Enterprise to request a different QoS for a particular session.

UE Footprint

Knowing which UEs are in a particular geographic region has great potential benefit to emergency services.

3rd Party Interaction for UE Patterns

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.

Group Message Delivery

This feature uses MBMS, allowing the Enterprise to establish multicast channels to UEs in particular geographic regions.

Background Data Transfer

When the Enterprise has bulk data to transfer, SCEF can offer specific time windows with different billing options to the Enterprise.

Summary

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.