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 3GPP has done for other 3GPP network nodes, 3GPP has defined some Charging Events for SCEF. These events are limited to NIDD (for SCEF and IWK-SCEF) and Monitoring events (for IWK-SCEF).

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

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.

In 3GPP Release 16, 3GPP added the capability for the SCS/AS to use the SCEF to provision the RACS (Radio Capability Signaling) in the UE’s database.