In the article “,” discussing the architecture of the NB-IoT core network, we mentioned the emergence of a new node, SCEF. In this third part, we explain what it is and why it is needed.
When creating an M2M service, application developers face the following questions:
- how to identify devices;
- which authentication verification algorithm to use;
- which transport protocol to choose for interaction with devices;
- how to ensure data delivery to devices;
- how to organize and establish rules for data exchange with them;
- how to monitor and obtain real-time information about their status;
- how to simultaneously deliver data to a group of your devices;
- how to simultaneously send data from one device to multiple clients;
- how to get unified access to additional operator services for managing your device.
To solve these issues, proprietary, technically "heavy" solutions often have to be created, which increases labor costs and time-to-market for services. This is where the new SCEF node comes into play.
According to the 3GPP definition, SCEF (service capability exposure function) is a completely new component of the 3GPP architecture, with the function of securely exposing services and capabilities provided by 3GPP network interfaces via API.
In simple terms, SCEF is a mediator between the network and the application server (application server — AS), serving as a unified access point to operator services for managing your M2M device in the NB-IoT network via an intuitive, standardized API interface.
SCEF hides the complexity of the operator's network, allowing application developers to abstract from complicated, specific mechanisms for interacting with devices.
By transforming network protocols into a familiar API interface for application developers, SCEF facilitates the creation of new services and reduces time-to-market. This new node also includes functions for identifying/authenticating mobile devices and establishing data exchange rules between the device and AS, relieving application developers from the need to implement these functions on their side, thus shifting these responsibilities to the operator.
SCEF encapsulates the interfaces necessary for authenticating and authorizing application servers, maintaining UE mobility, transferring data and triggering devices, as well as accessing additional services and capabilities of the operator’s network.
Towards AS, there is a single T8 interface, an API interface (HTTP/JSON), standardized by 3GPP. All interfaces, except T8, are based on the DIAMETER protocol (see Fig. 1).
T6a – the interface between SCEF and MME. It is used for Mobility/Session management procedures, transferring non-IP data, provisioning monitoring events, and receiving reports on them.
S6t – the interface between SCEF and HSS. It is necessary for subscriber authentication, authorizing application servers, obtaining the external ID and IMSI/MSISDN pair, provisioning monitoring events, and receiving reports on them.
S6m/T4 – interfaces from SCEF to HSS and SMS-C (in 3GPP, the MTC-IWF node is defined, which is used for triggering devices and sending SMS in NB-IoT networks. However, in all implementations, the functionality of this node is integrated into SCEF, so for simplicity, we will not consider it separately). They are used to obtain routing information for sending SMS and interacting with the SMS center.
T8 – the API interface for SCEF interaction with application servers. Through this interface, both control commands and traffic are transmitted.
*in reality, there are more interfaces; here only the most essential ones are listed. A complete list can be found in 3GPP 23.682 (4.3.2 List of Reference Points).
Below are the key functions and services of SCEF:
- binding the SIM card identifier (IMSI) to the external ID;
- transferring non-IP traffic (Non-IP Data Delivery, NIDD);
- group operations using external group ID;
- support for acknowledgment data transfer mode;
- buffering MO (Mobile Originated) and MT (Mobile Terminated) data;
- authentication and authorization of devices and application servers;
- Simultaneous use of data from one UE by multiple AS;
- Support for special functions for monitoring UE status (MONTE – Monitoring Events);
- Triggering devices;
- Ensuring non-IP data roaming.
The main principle of interaction between AS and SCEF is based on the so-called subscription model. When access to a certain service is required for a specific UE, the application server must create a subscription by sending a command to the specific API of the requested service and receive a unique identifier in response. All further actions and communications with UE within this service will then use this identifier.
External ID: universal device identifier
One of the most significant changes in the interaction scheme between AS and devices when working through SCEF is the introduction of a universal identifier. Now, instead of a phone number (MSISDN) or IP address, as it was in the classic 2G/3G/LTE networks, the identifier for the application server becomes the 'external ID'. It is defined by the standard in a familiar format for application developers: '@'.
Developers no longer need to implement device authentication algorithms, as the network takes over this function completely. The External ID is linked to the IMSI, allowing the developer to be confident that when addressing a specific external ID, they are interacting with a specific SIM card. In the case of using a SIM chip, a unique situation arises where the external ID unequivocally identifies a specific device!
Moreover, multiple external IDs can be linked to one IMSI — creating an even more interesting situation where an external ID unequivocally identifies a specific application responsible for a certain service on a specific device.
Additionally, a group identifier appears — the external group ID, which includes a set of individual external IDs. Now, with one request to the SCEF, the AS can initiate group operations — sending data or control commands to multiple devices united in a single logical group.
Given that the transition to the new device identifier cannot be instantaneous for AS developers, SCEF has left the possibility for AS to communicate with UE through the standard number – MSISDN.
Non-IP Data Delivery (NIDD)
In NB-IoT, as part of optimizing the mechanisms for transmitting small amounts of data, in addition to the existing types of PDN such as IPv4, IPv6, and IPv4v6, a new type has emerged — non-IP. In this case, the device (UE) is not assigned an IP address, and data is transmitted without using the IP protocol. Traffic for such connections can be routed in two ways: the classical way — MME -> SGW -> PGW and further through a PtP tunnel to AS (Figure 2) or using SCEF (Figure 3).
The classical method does not offer any significant advantages over IP traffic, except for reducing the size of transmitted packets due to the absence of IP headers. However, using SCEF opens up a range of new opportunities and significantly simplifies interaction procedures with devices.
When transmitting data via SCEF, there are two very important advantages over classical IP traffic:
Delivery of MT traffic to the device via external ID
To send a message to a classical IP device, the AS must know its IP address. Here lies the problem: since the device usually receives a 'gray' IP address during registration, it communicates with the application server, which is located on the internet, through a NAT node, where the gray address is translated into a white one. The association between the gray and white IP addresses lasts for a limited time, depending on the NAT settings. On average, for TCP or UDP, it's no more than five minutes. That is, if there has been no data exchange with this device for 5 minutes, the association will collapse, and the device will no longer be available at the white address with which the session was initiated with the AS. There are several solutions:
1. Use a heartbeat. Once the connection is established, the device must exchange packets with the AS every few minutes, preventing the translations on NAT from closing. However, energy efficiency cannot be considered in this scenario.
2. Each time there is a need, check for packets for the device at the AS — send a message in the uplink.
3. Create a private APN (VRF) where the application server and devices will be in the same subnet and assign static IP addresses to the devices. It will work but is almost impractical when it comes to a fleet of thousands or tens of thousands of devices.
4. Finally, the most suitable option is to use IPv6, as it does not require NAT since IPv6 addresses are directly accessible from the internet. However, even in this case, upon re-registering the device, it will receive a new IPv6 address and will no longer be accessible via the previous one.
Accordingly, it is necessary to send an initialization packet with the device identifier to the server to inform it of the new device IP address. Then, wait for a confirmation packet from AS, which also impacts energy efficiency.
These methods work well for 2G/3G/LTE devices, where there are no strict autonomy requirements placed on the device and, as a result, no limitations on airtime and traffic. For NB-IoT, these methods are not suitable due to their high energy consumption.
SCEF addresses this issue: since the only identifier for the device at AS is the external ID, AS only needs to send a data packet to SCEF for a specific external ID, and SCEF will take care of the rest. If the device is in power-saving mode (PSM) or eDRX, the data will be buffered and delivered when the device becomes available. If the device is traffic-ready, the data will be delivered immediately. This also applies to control commands.
At any moment, AS can revoke the buffered message to the UE or replace it with a new one.
The buffering mechanism can also be applied when transmitting MO data from the UE to AS. If SCEF could not deliver the data to AS immediately, for example, if there is maintenance being performed on the AS servers, these packets will be buffered and guaranteed to be delivered as soon as AS becomes available.
As mentioned above, access to a specific service and UE for AS (and NIDD is a service) is regulated by rules and policies on the SCEF side, which allows for the unique capability of simultaneous use of data from one UE by multiple AS. That is, if several AS subscribe to one UE, after receiving data from the UE, SCEF will distribute it to all subscribing AS. This is well suited for cases where a creator of a specialized device park shares data among multiple clients. For example, by creating a network of weather stations operating on NB-IoT, data from them can be sold to many services simultaneously.
Guaranteed Message Delivery Mechanism
Reliable Data Service — a mechanism for the guaranteed delivery of MO and MT messages without using specialized algorithms at the protocol level, such as the handshake in TCP, for example. It operates by including a special flag in the header of the message during exchange between UE and SCEF. Whether to activate this mechanism when transmitting traffic is decided by AS.
If the mechanism is activated, the UE includes a special flag in the header of the packet for guaranteed delivery of MO traffic when necessary. Upon receiving such a packet, SCEF responds to the UE with a confirmation. If the UE does not receive a packet with confirmation, the packet towards SCEF will be resent. The same applies to MT traffic.
Device Monitoring (monitoring events - MONTE)
As mentioned earlier, the functionality of SCEF includes, among other things, functions for monitoring the state of the UE, known as device monitoring. While new identifiers and data transmission mechanisms are optimizations (albeit significant) of existing procedures, MONTE is an entirely new functionality unavailable in 2G/3G/LTE networks. MONTE enables AS to track device parameters such as connection status, communication availability, location, roaming status, etc. We will discuss each in detail shortly.
To activate any monitoring event for a device or group of devices, AS subscribes to the relevant service by sending a command via the corresponding MONTE API to SCEF, which includes parameters such as external Id or external group ID, the AS identifier, the type of monitoring, and the number of reports the AS wishes to receive. If AS is authorized to perform the request, SCEF provisions the event on HSS or MME depending on the type (see Fig. 4). When an event occurs, MME or HSS generates a report to SCEF, which sends it to AS.
Provisioning of all events, except for 'Number of UEs present in a geographic area', is done through HSS. Two events, 'Change of IMSI-IMEI Association' and 'Roaming Status', are monitored directly on HSS, while others are provisioned by HSS on MME.
Events can be either one-time or periodic and are determined by their type.
The event report (reporting) is sent by the node monitoring the event directly to the SCEF (see Fig. 5).
Important point: monitoring events can apply to both non-IP devices connected via SCEF and IP devices transmitting data in the traditional manner through MME-SGW-PGW.
Let's take a closer look at each of the monitoring events:
Loss of connectivity — informs the AS that the UE is no longer available for both data traffic and signaling exchange. This event occurs when the ‘mobile reachability timer’ for the UE expires at the MME. In the request for this type of monitoring, the AS can specify its own value for the ‘Maximum Detection Time’ — if the UE does not exhibit any activity within this time, the AS will be informed that the UE is unavailable, with a reason provided. This event also occurs if the UE was forcibly removed from the network for any reason.
* For the network to know that the device is still available, it periodically initiates a procedure for re-registration — Tracking Area Update (TAU). The frequency of this procedure is set by the network using timer T3412 or (T3412_extended in the case of PSM), the value of which is transmitted to the device during the Attach procedure or the subsequent TAU. The mobile reachability timer is usually several minutes longer than T3412. If the UE does not perform a TAU before the ‘Mobile reachability timer’ expires, the network considers it to be unavailable.
UE reachability – indicates when the UE becomes available for DL traffic or SMS. This occurs when the UE becomes available for paging (for the UE in eDRX mode) or when the UE switches to ECM-CONNECTED mode (for the UE in PSM or eDRX mode), i.e., it performs a TAU or sends an uplink packet.
Location reporting – This type of monitoring event allows the AS to request the UE's location data. It can either request the current location (Current Location) or the last known location (Last Known Location, determined by the cell ID from which the device last performed TAU or transmitted traffic), which is relevant for devices in power-saving modes PSM or eDRX. For 'Current Location,' the AS can request recurring reports, with the MME informing the AS each time the device changes its location.
Change of IMSI-IMEI Association When this event is activated, SCEF starts monitoring changes in the IMSI (SIM card identifier) and IMEI (device identifier) bindings. When the event occurs, it notifies AS. It can be used for automatic reassignment of external ID to the device during scheduled maintenance or to serve as a device theft identifier.
Roaming Status This type of monitoring is used by AS to determine whether the UE is in the home network or a roaming partner's network. Optionally, the PLMN (Public Land Mobile Network) of the operator to which the device is registered can be transmitted.
Communication failure This type of monitoring informs AS about communication failures with the device based on the release cause code received from the radio access network (S1-AP protocol). This event can help identify the reason for the communication failure—either due to network issues, such as eNodeb overload (Radio resources not available), or due to a malfunction of the device itself (Radio Connection With UE Lost).
Availability after DDN Failure This event informs AS that the device has become available after a communication failure. It can be used when it is necessary to send data to the device, but the previous attempt was unsuccessful, as the UE did not respond to the network's notification (paging), and the data was not delivered. If this type of monitoring was requested for the UE, then as soon as the device makes an incoming communication, performs TAU, or sends data uplink, AS will be informed that the device is available. Since the DDN (downlink data notification) procedure works between MME and S/P-GW, this type of monitoring is only available for IP devices.
PDN Connectivity Status Informs AS of changes in the device's status (PDN connectivity status)—connection (PDN activation) or disconnection (PDN removal). This can be used by AS to initiate communication with the UE or, conversely, to understand that communication is no longer possible. This type of monitoring is available for both IP and non-IP devices.
Number of UEs present in a geographic area This type of monitoring is used by AS to determine the number of UEs in a specific geographic area.
Device triggering)
In 2G/3G networks, the registration procedure was two-step: first, the device registered with SGSN (attach procedure), and then, if data needed to be transmitted, it activated the PDP context – a connection to the packet gateway (GGSN). In 3G networks, these two procedures occurred sequentially, meaning the device did not wait until it needed to transmit data but activated PDP immediately after the attach procedure was completed. In LTE, these two procedures were combined into one, meaning that upon attach, the device immediately requested activation of the PDN connection (analogous to PDP in 2G/3G) through eNodeB to MME-SGW-PGW.
In NB-IoT, there is a connection method defined as "attach without PDN," meaning the UE performs an attach without establishing a PDN connection. In this case, it is not available for traffic transmission and can only receive or send SMS. To transmit a command to such a device for activating PDN and connecting to AS, a functionality called "Device triggering" has been developed.
Upon receiving a connection command for such UE from AS, SCEF initiates the sending of a control SMS to the device through the SMS center. When receiving the SMS, the device activates the PDN and connects to AS for subsequent instructions or data transmission.
There may be cases when the subscription for the device expires on SCEF. Yes, the subscription has its lifespan, established by the operator or agreed with AS. Once it expires, the PDN will be deactivated on MME, and the device will become unavailable for AS. In this case, the "Device triggering" functionality will also help. Upon receiving new data from AS, SCEF will check the connection status of the device and deliver the data via the SMS channel.
Conclusion
The functionality of SCEF, of course, is not limited to the services described above and is constantly evolving and expanding. Currently, there are already more than a dozen standardized services for SCEF. We have touched on only the primary and in-demand functions from developers; we will discuss the others in future articles.
A question immediately arises: how can one gain test access to this "wonder" node for preliminary testing and debugging potential cases? It's very simple. Any developer can send a request to iot.info@mts.ru, where they just need to specify the purpose of the connection, a description of the potential case, and contact information for further correspondence.
Until next time!
Authors:
- Senior Expert in Convergent Solutions and Multimedia Services Sergey Novikov ,
- Expert in Convergent Solutions and Multimedia Services Alexey Lapshin
Source: habr.com
