Monday, February 6, 2017

Role of SCEF

3GPP Release 13 introduced a new node in the EPC for exposure of 3GPP network service capabilities to 3rd party applications. This node is the Service Capability Exposure Function (SCEF). This node was introduced as part of the Architectural Enhancements for Service Exposure (AESE) work item in SA2. 

Though the concept of exposing telecom network service capabilities via APIs to 3rd party application is not new and the world has seen where OSA/Parlay went with the circuit switched networks, what makes SCEF compelling and different from OSA/Parlay are the following


  1. Deployment and use of cellular technologies for connecting the IoT devices to the network looks imminent.
  2. For IoT, the business value is in the applications and gaining actionable insights from the data gathered from the IoT devices, using analytics.
  3. This requires the operator to open up their network to tap into the network events and onboard applications.
  4. Another key aspect of IoT is security. After the recent large scale DDOS attacks using IoT devices through the Mirai botnet, security has become the key focus. So access to the IoT devices by the applications should be through a controlled and secure environment that first authenticates and authorizes the application during an onboarding process before they gain access to the data from the IoT devices. SCEF provides this key aspect and since the IoT devices connect to the network through the cellular operators, the cellular service providers can make sure these devices are not configured with default credentials and their access to the network is secure.
The following are the key functionalities of SCEF
  1. Exposure of 3GPP network events through northbound APIs to applications. 3GPP does not define the northbound APIs in release 13. The northbound APIs are defined by OMA and OneM2M. However in release 15, 3GPP has started a new work item to define northbound APIs from SCEF for the non IP data delivery (NIDD) procedure. This work item is still pending approval at the SA plenary. The work item was triggered by an LS Response from the SA plenary  to OMA and OneM2M copied to SA2 and SA1. This was a response to the LS sent by OneM2M to SA Plenary. The work item description by SA2 is here.
  2. Exposure of the following events (defined through the Monitoring Events - MONTE work item in release 13):
    1. UE reachability
    2. UE loss of connectivity
    3. UE location reporting
    4. UE roaming status
    5. Communication failure 
    6. Change of IMEI-IMSI association
  3. Registering for UE reachability notification upon DDN failure for high latency communications (defined through the High Latency Communications - HLCom work item in release 13)
  4. Non IP Data Delivery (NIDD) through a non IP PDN established through the SCEF. This was defined in the Cellular IoT work item in release 13.
3GPP is also continuously evolving the functionalities of SCEF in release 14 and release 15 and Network Exposure Function (NEF) is a key network function in the NexGen (5G) network architecture as well. In subsequent posts, I will dig into the details of Cellular IoT optimizations and how SCEF is getting used in that.


2 comments:

  1. What is the use cases and benefits for using AS with SCEF when we use monitoring APi? I believe 3rd party application server always has this monitoring event so why do we need this???

    ReplyDelete
  2. Hello, very good article. It is however, pretty nebulous how much these features are something a mobile network operator would actually benefit from using. Besides security, NIDD seems to be the most non-redundant and desirable functionality. I wonder, however, what order of magnitude should the number of IoT devices reach in order for it to be justifiable to make such an architectural addition to the network. Given that the SCEF function and all the interfaces and licenses will cost them money, for function that mostly seem redundant.

    What do you think?

    ReplyDelete