When creating an M2M service, application developers are faced with the following questions:
- How to identify devices
- Which authentication and authentication algorithm to use;
- what transport protocol to use for interacting with devices;
- How to guaranteedly deliver data to devices
- how to organize and establish rules for exchanging data with them;
- how to monitor and receive information on their status online;
- how to simultaneously deliver data to a group of their devices;
- How to simultaneously send data from one device to several clients;
- how to get unified access to additional operator services for managing your device.
To solve them, one has to create proprietary technically “heavy” solutions, which leads to an increase in labor costs and time-to-market services. This is where the new SCEF node comes to the rescue.
According to the definition of 3GPP, SCEF (service capability exposure function) is a completely new component of the 3GPP architecture, the function of which is to safely expose the services and capabilities provided by 3GPP network interfaces through the API.
In simple words, SCEF is an intermediary between the network and the application server (AS), a single access window to the operator’s services for managing their M2M device in the NB-IoT network through an intuitive standardized API.
SCEF hides the complexity of the operator’s network, allowing application developers to abstract from complex, specific mechanisms for interacting with devices.
By transforming network protocols into familiar to application developers, the SCEF API facilitates the creation of new services and reduces the time-to-market. Also, the new node includes the functions of identification / authentication of mobile devices, determining the rules for exchanging data between the device and AS, removing the need for the implementation of these functions from application developers on their side, shifting these functions to the shoulders of the operator.
SCEF closes the interfaces necessary for authentication and authorization of application servers, supporting UE mobility, data transfer and device triggering, access to additional services and operator network capabilities.
Towards AS there is one single T8 interface, an API (HTTP / JSON), a standardized 3GPP. All interfaces, with the exception of T8, operate on the basis of the DIAMETER protocol (Fig. 1).
T6a is the interface between SCEF and MME. Used for Mobility / Session management procedures, non-IP data transmission, provisioning of monitoring events and receiving reports on them.
S6t is the interface between SCEF and HSS. It is necessary for authentication of the subscriber, authorization of application servers, obtaining a bunch of external ID and IMSI / MSISDN, providing monitoring events and receiving reports on them.
S6m / T4 are the interfaces from SCEF to HSS and SMS-C (the MTC-IWF node is defined in 3GPP, which is used to trigger devices and send SMS in NB-IoT networks. However, in all implementations, the functionality of this node is integrated into SCEF, so for simplification of the scheme, we will not consider it separately). Used to obtain routing information for sending SMS and interacting with the SMS center.
T8 - API for SCEF interaction with application servers. Both control commands and traffic are transmitted through this interface.
* In reality, there are more interfaces, only the most basic ones are listed here. A complete list is given in 3GPP 23.682 (4.3.2 List of Reference Points).
Below are the key features and services of SCEF:
- binding a SIM card identifier (IMSI) to an external ID;
- non-IP traffic delivery (Non-IP Data Delivery, NIDD);
- group operations using an external group ID;
- support for data transfer mode with confirmation;
- buffering MO (Mobile Originated) and MT (Mobile Terminated) data;
- authentication and authorization of devices and application servers;
- simultaneous use of the data of one UE by several AS;
- support of special functions of monitoring the status of the UE (MONTE - Monitoring Events);
- device triggering;
- Providing roaming non-IP data.
The basic principle of interaction between AS and SCEF is based on the so-called subscriptions. If you need to access any SCEF service for a specific UE, the application server needs to create a subscription by sending a command to the specific API of the requested service and in response to receive a unique identifier. After that, all further actions and communications with the UE within the framework of this service will be carried out using this identifier.
External ID: universal device identifier
One of the most important changes in the scheme of interaction between AS and devices when working through SCEF is the emergence of a universal identifier. Now instead of the telephone number (MSISDN) or IP address, as it was in the classic 2G / 3G / LTE network, the device identifier for the application server becomes “external ID”. It is defined by the standard in the format familiar to application developers "<Local Identifier> @ <Domain Identifier>".
Developers no longer need to implement device authentication algorithms, the network completely takes this function upon itself. External ID is attached to IMSI, and the developer can be sure that referring to a specific external ID, he interacts with a specific SIM card. When using a SIM chip, a generally unique situation is obtained when the external ID uniquely identifies a specific device!
Moreover, several external IDs can be attached to one IMSI - an even more interesting situation is obtained when the external ID uniquely identifies a specific application that is responsible for a particular service on a particular device.
A group identifier also appears - an external group ID, which includes a set of separate external IDs. Now, with a single request to SCEF, AS can initiate group operations - sending data or control commands to multiple devices combined into a single logical group.
Due to the fact that for AS developers, the transition to a new device identifier cannot be instantaneous, SCEF left the possibility of AS communication with the UE through the standard number - MSISDN.
Non-IP Data Delivery (NIDD)
In NB-IoT, as part of optimizing the mechanisms for transferring small amounts of data, in addition to the existing types of PDNs, such as IPv4, IPv6 and IPv4v6, another type appeared - 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: classic - MME -> SGW -> PGW and then through the PtP tunnel to AS (Fig. 2) or using SCEF (Fig. 3).
The classical method does not have any special advantages over IP traffic, with the exception of reducing the size of transmitted packets due to the absence of IP headers. Using SCEF opens up a number of new opportunities and greatly simplifies the procedures for interacting with devices.
When transmitting data through SCEF, there are two very important advantages over classical IP traffic:
Delivery of MT traffic to the device by external ID
To send a message to a classic IP device, the AS must know its IP address. Here a problem arises: since the device usually registers with a “gray” IP address, it communicates with the application server, which is located on the Internet, through the NAT node, where the gray address is translated into white. A bunch of gray and white IP addresses lasts a limited time, depending on the NAT settings. On average, for TCP or UDP - no more than five minutes. That is, if within 5 minutes there was no data exchange with this device, the connection will break up and the device will no longer be accessible at the white address with which the session with AS was initiated. There are several solutions:
1. Use a heartbeat. Having established a connection once, the device must exchange with AS packets every few minutes, thus preventing NAT translations from closing. But there can be no question of any energy efficiency.
2. Each time, if necessary, check for packages for the device on the AS - send a message to uplink.
3. Make a private APN (VRF), where the application server and devices will be on the same subnet, and assign static IP addresses to the devices. It will work, but it is almost impossible when it comes to a fleet of thousands, tens of thousands of devices.
4. Finally, the most suitable option: use IPv6, it does not need NAT, since IPv6 addresses are directly accessible from the Internet. However, even in this case, when re-registering the device, it will receive a new IPv6 address and will no longer be available at the previous one.
Accordingly, it is necessary to send a certain initialization packet with the device identifier to the server in order to report the new IP address of the device. Then wait for the confirmation package from AS, which also affects energy efficiency.
These methods work well for 2G / 3G / LTE devices, where the device does not have strict requirements for autonomy and, as a result, there are no time limits on the air and traffic. For NB-IoT, these methods are not suitable due to their high energy consumption.
SCEF solves this problem: since the only device identifier for AS is an external ID, it is enough for the AS to send a data packet to SCEF for a specific external ID, 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 available for traffic, the data will be delivered immediately. The same is true for management teams.
At any time, the AS can withdraw the buffered message to the UE or replace it with a new one.
The buffering mechanism can also be applied when transferring MO data from the UE to the AS side. If SCEF was unable to deliver data to AS immediately, for example, if service work is underway on AS servers, these packets will be buffered and guaranteed to be delivered as soon as the AS becomes available.
As noted 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 you to realize the unique ability to simultaneously use the data of one UE by several ASs. Those. if several ASs have subscribed to one UE, then after receiving data from the UE, SCEF will send them to all ASs that have signed. This is well suited for cases where the creator of a fleet of specialized devices fumbles data between several clients. For example, by creating a network of weather stations operating on NB-IoT, you can sell data from them to many services at the same time.
Guaranteed message delivery mechanism
Reliable Data Service - a mechanism for guaranteed delivery of MO and MT messages without the use of specialized algorithms at the protocol level, such as, for example, handshake in TCP. It works by including a special flag in the service part of the message during the exchange between the UE and SCEF. Whether or not to activate this mechanism when transmitting traffic is decided by the AS.
If the mechanism is activated, the UE, if necessary, guaranteed delivery of MO traffic includes a special flag in the service part of the packet. Upon receipt of such a packet, the SCEF replies to the UE with a confirmation. If the UE has not received a confirmation packet, the packet will be forwarded to SCEF. The same thing happens for MT traffic.
Device Monitoring (monitoring events- MONTE)
As mentioned above, the SCEF functional, among other things, includes functions for monitoring the state of the UE, the so-called device monitoring. And if new identifiers and data transfer mechanisms are optimizations (albeit very serious) of existing procedures, then MONTE is a completely new functionality that is not available in 2G / 3G / LTE networks. MONTE allows AS to monitor device parameters such as connection status, communication availability, location, roaming status, etc. We will tell you more about each later.
If it is necessary to activate a monitoring event for a device or device group, AS subscribes to the corresponding service by sending to SCEF the corresponding MONTE API command, which includes parameters such as external Id or external group ID, AS identifier, monitoring type, number of reports, which AS wants to receive. If the AS is authorized to execute the request, SCEF, depending on the type, will trigger the event on the HSS or MME (Fig. 4). When an event occurs, the MME or HSS generates a report to the SCEF side, which sends it to the AS.
All events, with the exception of “Number of UEs present in a geographic area”, are provided through HSS. Two events, “Change of IMSI-IMEI Association” and “Roaming Status”, are tracked directly on the HSS, the rest of the HSS will be provisioned on the MME.
Events can be either one-time or periodic, and are determined by their type.
Event reporting (reporting) is sent by the event tracking node directly to SCEF (Fig. 5).
An important point: monitoring events can be applied both to non-IP devices connected via SCEF and to IP devices that transmit data in a classical way via MME-SGW-PGW.
Let's take a closer look at each of the monitoring events:
Loss of connectivity - informs AS that the UE is no longer available for either data traffic or signaling. The event occurs when the “mobile reachability timer” for the UE expires on the MME. In the request for this type of monitoring, the AS can indicate its “Maximum Detection Time” value - if during this time the UE does not show any activity, the AS will be informed that the UE is unavailable, indicating the reason. The event also occurs if the UE was forcibly removed by the network for any reason.
* To let the network know that the device is still available, it periodically initiates the update procedure - Tracking Area Update (TAU). The frequency of this procedure is set by the network using the 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 next TAU. The mobile reachability timer is usually several minutes longer than the T3412. If the UE does not make a TAU before the Mobile reachability timer expires, the network considers it no longer available.
UE reachability - Shows when the UE becomes available for DL traffic or SMS. This happens 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. makes a TAU or sends an uplink packet.
Location reporting - This type of monitoring event allows the AS to request UE location data. Either the current location (Last Location) or the last known (Last Known Location, determined by the cell ID from which the device made the TAU or transmitted traffic for the last time) can be requested, which is important for devices in the PSM or eDRX power saving modes. For “Current Location,” the AS may request repeated repetitions, with the MME informing the AS each time the device location is changed.
Change of IMSI-IMEI Association - When this event is activated, SCEF begins to track the change in the connection between IMSI (SIM card identifier) and IMEI (device identifier). When an event occurs - informs AS. It can be used to automatically reassign the external ID to the device during planned replacement work or serve as an identifier for the theft of the device.
Roaming Status - this type of monitoring is used by the AS to determine whether the UE is in the home network or in the network of the roaming partner. Optionally, the PLMN (Public Land Mobile Network) of the operator in which the device is registered can be transferred.
Communication failure - This type of monitoring informs the AS about failures in communication with the device, based on the reasons for the connection failure (release cause code) received from the radio access network (S1-AP protocol). This event can help determine the reason for the communication failure - due to network problems, for example, when eNodeb (Radio resources not available) is overloaded or because the device itself (Radio Connection With UE Lost) failed.
Availability after DDN Failure - this event informs the AS that the device became available after a communication failure. It can be used when it is necessary to transfer data to the device, but the previous attempt was not successful, since the UE did not respond to the notification from the network (paging), and the data was not delivered. If this type of monitoring was requested for the UE, then as soon as the device makes incoming communication, makes a TAU or sends data to uplink, AS will be informed that the device has become available. Since the DDN (downlink data notification) procedure works between the MME and S / P-GW, this type of monitoring is available only for IP devices.
PDN Connectivity Status - informs the AS when the device status changes (PDN connectivity status) - connect (activate PDN) or disconnect (delete PDN). This can be used by the AS to initiate communication with the UE, or vice versa, to understand that communication is no longer possible. This type of monitoring is available for IP and non-IP devices.
Number of UEs present in a geographic area - this type of monitoring is used by the AS to determine the number of UEs in a specific geographic area.
Device triggering
In 2G / 3G networks, the registration procedure in the network was two-step: first the device was registered in SGSN (attach procedure), then, if necessary, the data was activated by the PDP context - connection to the packet gateway (GGSN). In 3G networks, these two procedures went sequentially, i.e. the device did not wait for the moment when it was necessary to transfer data, but activated PDP immediately after the attach procedure was completed. In LTE, these two procedures were combined into one, that is, when attach, the device immediately requested activation of the PDN connection (analogue of PDP in 2G / 3G) via eNodeB to MME-SGW-PGW.
NB-IoT defines a connection method such as “attach without PDN,” that is, the UE makes attach without establishing a PDN connection. In this case, it is not available for traffic transmission, and can only receive or send SMS. In order to send a command to activate a PDN and connect to AS to such a device, the “Device triggering” functionality was developed.
When receiving a command to connect such a UE from AS, SCEF through the SMS center initiates the sending of a control SMS to the device. Upon receipt of SMS, the device activates the PDN and connects to the AS to receive subsequent instructions or transfer data.
There may be times when a subscription to a device expires on SCEF. Yes, the subscription has its own life span, set by the operator or agreed with AS. Upon its expiration, the PDN will be deactivated on the MME, and the device will become unavailable to the AS. In this case, the “Device triggering” functionality will also help. Upon receipt of new data from AS SCEF, it will find out the connection status of the device and deliver the data via SMS.
Conclusion
SCEF functionality, of course, is not limited to the services described above and is constantly evolving and expanding. To date, more than a dozen services have already been standardized for SCEF. Now we have touched upon only the main functions that are demanded by developers, we will talk about the rest in future articles.
The question immediately arises, how to get test access to this “miracle” node for preliminary testing and debugging of possible cases? Everything is very simple. Any developer can send a request to iot.info@mts.ru, in which it is enough to indicate the purpose of the connection, a description of a possible case and contact information for communication.
See you soon!
Authors: