In the article "”, talking about the architecture of the packet core of the NB-IoT network, we mentioned the emergence of a new SCEF node. We explain in the third part 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 algorithm to use;
- which transport protocol to choose for interacting with devices;
- how to ensure data delivery to devices;
- how to organize and establish rules for exchanging data with them;
- how to control and get information about their condition 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, it is necessary 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 in.
As defined by 3GPP, SCEF (service capability exposure function) is an entirely new component of the 3GPP architecture whose function is to securely expose services and capabilities provided by 3GPP network interfaces via APIs.
In simple words, SCEF is an intermediary between the network and the application server (application server - AS), a single window for accessing operator services for managing their M2M device in the NB-IoT network through an intuitive standardized API.
SCEF hides the complexity of an operator's network, allowing application developers to abstract away complex, device-specific interaction mechanisms.
By transforming network protocols into the familiar application developer API, SCEF facilitates the creation of new services and reduces time-to-market. Also, the new node includes the functions of identifying/authenticating mobile devices, determining the rules for data exchange between the device and the AS, removing the need for application developers to implement these functions on their side, shifting these functions to the shoulders of the operator.
SCEF encapsulates the interfaces required for application server authentication and authorization, UE mobility support, data transfer and device triggering, access to additional services and operator network capabilities.
The AS side has one single T8 interface, an API (HTTP/JSON) standardized by 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, transferring non-IP data, provisioning monitoring events and receiving reports on them.
S6t is the interface between SCEF and HSS. Required for subscriber authentication, authorization of application servers, obtaining a bunch of external ID and IMSI / MSISDN, provisioning monitoring events and receiving reports on them.
S6m/T4 - interfaces from SCEF to HSS and SMS-C (3GPP defines an MTC-IWF node that 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 receive routing information for sending SMS and interacting with the SMS center.
T8 - SCEF interaction API with application servers. Through this interface, both control commands and traffic are transmitted.
*in fact, there are more interfaces, only the most basic ones are listed here. See 3GPP 23.682 (4.3.2 List of Reference Points) for a complete list.
Following are the key functions and services of SCEF:
- linking a SIM card identifier (IMSI) to an external ID;
- transmission of non-IP traffic (Non-IP Data Delivery, NIDD);
- group operations using external group ID;
- support for data transmission mode with confirmation;
- buffering of MO (Mobile Originated) and MT (Mobile Terminated) data;
- authentication and authorization of devices and application servers;
- simultaneous use of data of one UE by several AS;
- support for special UE status monitoring functions (MONTE - Monitoring Events);
- device triggering;
- provision of non-IP data roaming.
The basic principle of interaction between AS and SCEF is based on the so-called. subscriptions. When it is necessary 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 receive a unique identifier in response. After that, all further actions and communications with the UE within the framework of this service will take place using this identifier.
External ID: universal device identifier
One of the most important changes in the AS interaction with devices when working through SCEF is the appearance of a universal identifier. Now, instead of a phone number (MSISDN) or an 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 " @ ".
Developers no longer need to implement device authentication algorithms, the network completely takes over this function. External ID is tied to IMSI, and the developer can be sure that by accessing 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 tied to one IMSI - an even more interesting situation is obtained when the external ID uniquely identifies a specific application that is responsible for a specific service on a specific device.
A group identifier also appears - an external group ID, which includes a set of individual external IDs. Now, with a single request to SCEF AS, it 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 ID cannot be instantaneous, SCEF left the possibility of AS communication with the UE through a standard number - MSISDN.
Transfer of non-IP traffic (Non-IP Data Delivery, NIDD)
In NB-IoT, as part of the optimization of mechanisms for transferring small amounts of data, in addition to the already existing PDN types, such as IPv4, IPv6 and IPv4v6, another type has 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 a PtP tunnel to AS (Fig. 2) or using SCEF (Fig. 3).
The classical method does not have any special advantages over IP traffic, except for reducing the size of transmitted packets due to the absence of IP headers. The use of SCEF opens up a number of new possibilities and greatly simplifies the procedures for interacting with devices.
When transmitting data via SCEF, there are two very important advantages over classic IP traffic:
Delivery of MT traffic to the device via 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 receives a “gray” IP address during registration, it communicates with the application server 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 for 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 link will break up, and the device will no longer be available at the white address with which the session with AS was initiated. There are several solutions:
1. Use heartbeat. Once a connection is established, the device must exchange packets with AS every few minutes, thereby preventing the broadcast from closing on NAT. But there can be no question of any energy efficiency.
2. Each time, if necessary, check for the presence of packets for the device on the AS - send a message to the 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 unrealistic when it comes to a fleet of thousands, tens of thousands of devices.
4. Finally, the most suitable option is to use IPv6, it does not need NAT, since IPv6 addresses are directly accessible from the Internet. However, even in this case, when the device is re-registered, it will receive a new IPv6 address and will no longer be available using the previous one.
Accordingly, it is necessary to send some initializing packet with the device identifier to the server in order to report the new IP address of the device. Then wait for a confirmation packet 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 restrictions on air time and traffic. For NB-IoT, these methods are not suitable due to their high energy consumption.
SCEF solves this problem: since the external ID is the only device identifier for an AS, it is enough for the AS to send a data packet to SCEF for a specific external ID, and SCEF takes care of the rest. In case the device is in PSM or eDRX power saving mode, 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 control commands.
At any time, the AS may withdraw the buffered message towards the UE or replace it with a new one.
The buffering mechanism may also be applied when transmitting MO data from the UE to the AS. If SCEF was unable to deliver the data to the AS immediately, for example, if service work is being done on the 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 an AS (and NIDD is a service) is governed by rules and policies on the SCEF side, which makes it possible to realize the unique possibility of simultaneously using data from one UE by several ASs. Those. if several ASs have subscribed to the same UE, then after receiving data from the UE, SCEF will distribute them to all subscribing ASs. This is well suited for cases where the creator of a fleet of specialized devices shares data between several clients. For example, by creating a network of weather stations powered by NB-IoT, you can sell data from them to many services at the same time.
Guaranteed Message Delivery Mechanism
Reliable Data Service is 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. It is up to the AS to decide whether or not to activate this mechanism during traffic transmission.
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 an acknowledgment. If the UE does not receive an acknowledgment packet, the packet will be forwarded towards the SCEF. The same happens for MT traffic.
Device monitoring (monitoring events - MONTE)
As mentioned above, the functionality of SCEF, among other things, includes the functions of monitoring the state of the UE, the so-called. device monitoring. And if new identifiers and data transfer mechanisms are optimizations (albeit very serious ones) of already 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 talk about each in more detail a little later.
If it is necessary to activate any monitoring event for a device or a group of devices, AS subscribes to the corresponding service by sending the corresponding MONTE API command to SCEF, 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 fulfill the request, SCEF will provision the event to the HSS or MME, depending on the type (Fig. 4). When an event occurs, the MME or HSS generates a report to the SCEF, which sends it to the AS.
All events, with the exception of “Number of UEs present in a geographic area”, are provisioned via HSS. Two events “Change of IMSI-IMEI Association” and “Roaming Status” are monitored directly on the HSS, the rest of the HSS will be provisioned on the MME.
Events can be both one-time and periodic, and are determined by their type.
Sending an event report (reporting) is performed by the node tracking the event directly to SCEF (Fig. 5).
Important point: monitoring events can be applied both to non-IP devices connected via SCEF, and to IP devices transmitting data in the classical way via 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 either data traffic or signaling. The event occurs when the "mobile reachability timer" for the UE expires on the MME. In a request for this type of monitoring, the AS can specify its “Maximum Detection Time” value - if the UE does not show any activity during this time, the AS will be informed that the UE is unavailable, indicating the reason. Also, the event occurs if the UE is forcibly removed by the network for any reason.
* In order for the network to know that the device is still available, it periodically initiates an update procedure - 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 next TAU. The mobile reachability timer is typically several minutes longer than the T3412. If the UE has not made a TAU before the "Mobile reachability timer" expires, the network considers it no longer available.
UE reachability – Indicates when the UE becomes available for DL traffic or SMS. This occurs when the UE becomes available for paging (for a UE in eDRX mode) or when the UE enters ECM-CONNECTED mode (for a UE in PSM or eDRX mode), i. makes a TAU or sends an uplink packet.
location reporting – This kind of monitoring event allows the AS to request the location of the UE. Either the current location (Current Location) or the last known location (Last Known Location, determined by the cell ID from which the device did TAU or transmitted traffic for the last time) can be requested, which is relevant for devices that are in PSM or eDRX power saving modes. For "Current Location" AS can request repeated repo, and MME will inform AS every time the device's location changes.
Change of IMSI-IMEI Association – When this event is activated, SCEF starts to monitor the change in the combination of IMSI (SIM card identifier) and IMEI (device identifier). When an event occurs, informs AS. Can be used to automatically rebind an external ID to a device during scheduled replacement work or serve as a device theft identifier.
Roaming Status – this type of monitoring is used by the AS to determine whether the UE is in the home network or in the roaming partner's network. Optionally, the PLMN (Public Land Mobile Network) of the operator in which the device is registered can be transmitted.
communication failure - This type of monitoring informs the AS about failures in communication with the device, based on the reasons for the disconnection (release cause code) received from the radio access network (S1-AP protocol). This event can help determine whether communication failed due to network problems, such as eNodeb overload (Radio resources not available) or due to device failure (Radio Connection With UE Lost).
Availability after DDN Failure – this event informs the AS that the device has become available after a communication failure. Can be used when it is necessary to send data to the device, but the previous attempt was not successful, because the UE did not respond to the notification from the network (paging), and the data was not delivered. If this type of monitoring has been requested for the UE, then as soon as the device makes an incoming communication, makes a TAU, or sends data to the uplink, the AS will be informed that the device has become 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 the AS when the device status (PDN connectivity status) changes — connecting (PDN activation) or disconnecting (PDN deletion). This may 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 particular geographic area.
Device triggering)
In 2G / 3G networks, the registration procedure in the network was two-stage: first, the device was registered in the SGSN (attach procedure), then, if necessary, data transfer was activated by the PDP context - connection to the packet gateway (GGSN). In 3G networks, these two procedures were carried out sequentially, i.e. the device did not wait for the moment when it was necessary to transmit data, but activated the 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 the activation of a PDN connection (analogous to PDP in 2G / 3G) via eNodeB to MME-SGW-PGW.
The NB-IoT defines the connection method as “attach without PDN”, that is, the UE does 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 such a device to activate the PDN and connect to the AS, the “Device triggering” functionality was developed.
When receiving a command to connect such a UE from AS, SCEF initiates sending a control SMS to the device via the SMS center. Upon receiving an SMS, the device activates the PDN and connects to the AS to receive further instructions or transfer data.
There may be times when a device subscription expires on SCEF. Yes, the subscription has its own lifetime, set by the operator or agreed with AS. After it expires, 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 device connection status and deliver the data via SMS.
Conclusion
The functionality of SCEF, 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 only on the main and demanded by developers functions, we will talk about the rest in future articles.
The question immediately arises, how to get test access to this “wonder” node for preliminary testing and debugging of possible cases? Everything is very simple. Any developer can send a request to [email protected], in which it is enough to indicate the purpose of the connection, a description of a possible case and contact information for communication.
Until next time!
Authors:
- senior expert of the department of convergent solutions and multimedia services Sergey Novikov ,
- Alexey Lapshin, Convergent Solutions and Multimedia Services Department Expert
Source: habr.com