10
MTC Service – Network Architecture
10.1. Functional architecture
The term CIoT (Cellular Internet of Things) refers to the evolution of the evolved packet system (EPS) for taking into account connected objects.
LTE-M and NB-IoT (NarrowBand Internet of Things) are two technologies whose specificity lies in the radio interface described in Chapter 11.
These two types of radio interfaces use the same network architecture described in Figure 10.1.
The machine type communication (MTC) is performed between an MTC application hosted in the user equipment (UE) and an MTC application hosted in an application server (AS).
The MTC application server can use the services of a services capability server (SCS) to gain access to certain features of the EPS network.
For the direct model, the application server connects directly to the EPS network to establish communications with the terminal using the user plane without using the SCS entity.
For the indirect model, the application server connects indirectly to the EPS network through an SCS entity to use additional MTC services.
For the hybrid model, the application server simultaneously uses the direct model to connect directly to the EPS network in order to establish direct communications and the indirect model using the SCS entity.
Figure 10.1. Network architecture
10.1.1. MTC-IWF entity
The MTC-IWF (Interworking) entity hides the internal topology of the EPS network and relays or translates the signaling protocol used on the Tsp interface to invoke specific features of the EPS network.
This entity verifies that the SCS entity is authorized to send a request to trigger the terminal and routes it to the service center which stores the short messages.
It signals to the SCS entity the acceptance or the rejection of the request to trigger the terminal.
It reports to the SCS entity the success or the failure of the short message delivery to the terminal.
It queries the home subscriber server (HSS) for the correspondence between, on the one hand, the E.164 telephone number or an external identifier and, on the other hand, the international mobile subscriber identity (IMSI) of the terminal, and to verify that the SCS entity is authorized to send trigger requests.
10.1.2. MTC-AAA entity
The MTC-AAA (Authentication, Authorization and Accounting) entity supports the conversion of the IMSI to external identifiers, in response to a request from the HSS entity.
10.1.3. SCEF entity
The service capability exposure function (SCEF) exposes the functionality provided by the EPS network and provides access to EPS network capabilities through application programming interfaces (API).
The services offered by the SCEF entity to the SCS/AS entities are described in the following sections.
10.1.3.1. Group message delivery
The group message delivery allows SCS/AS entities to deliver data to a group of devices:
- – the delivery of group messages via the evolved Multimedia Broadcast/Multicast Services (eMBMS);
- – the delivery of group messages via unicast transmission of non-IP data delivery (NIDD).
10.1.3.2. Event monitoring
Event monitoring is intended to monitor specific events in the EPS network and make this information available to SCS/AS entities.
Event monitoring supports the following functions:
- – the monitoring of the association of IMSI and IMEI;
- – the accessibility of the terminal;
- – the location of the terminal;
- – the loss of connectivity;
- – the failure of communication;
- – the roaming status of the terminal;
- – the number of terminals present in a geographical area;
- – the availability after failure on the downlink.
10.1.3.3. High latency communication
The high latency communication can be used to manage communication with inaccessible devices when they are in a power-saving mode.
This communication is handled by buffering the downlink data in the serving gateway (SGW) or the mobility management entity (MME) until the terminal wakes up.
10.1.3.4. Session management
Third-party SCS/AS entities may request that a session be configured with a specific quality of service. This feature is exposed via SCEF entities to SCS/AS entities.
When the SCEF entity receives a request from SCS/AS entities, it forwards the request to the policy and charging rules function (PCRF) via the Rx interface to retrieve the traffic profile.
If the SCEF entity is informed of events occurring in the EPS network via the Rx interface, it reports this to the SCS/AS entities.
10.1.3.5. Non-IP data delivery
NIDD support is part of the optimization of the EPS network. The transmission of non-IP data is done by the SCEF entity or via a point-to-point IP tunnel on the SGi interface.
10.1.4. IWF-SCEF entity
The IWF-SCEF entity deployed in the visited EPS network allows the terminal in roaming to connect to the SCEF entity located in the home EPS network.
This entity receives the event monitoring reports and sends them to the SCEF entity.
It relays the NIDD between the MME and SCEF entities.
10.2. Network optimization
The optimization of the EPS network is necessary because, on the one hand, the mobiles for the MTC service are characterized by intermittent data transmission at low bit rate, and, on the other hand, the EPS network is structured for transmissions with high data rates.
Two optimization methods were defined: the first one is based on the control plane (Control Plane CIoT EPS optimization) and the second is based on the user plane (User Plane CIoT EPS optimization) (Figure 10.2).
Figure 10.2. Different variants of data transmission
In the case of the use of the control plane, the data is carried by the NAS (Non-Access Stratum) messages exchanged between the terminal and the MME entity. This arrangement makes it possible to reduce the number of messages of the control plane during the processing of a session establishment procedure.
Moreover, a new feature allows the terminal to remain connected without having a packet data network (PDN) connection via the SGi interface, since data can be directly transmitted between the MME and SCEF entities. This is useful if a large number of terminals keep the connection idle for a long time and rarely transmit data.
In the case of the use of the user plane, the data are transported in a conventional way. However, the control associated with the maintenance of the bearers introduces two new states of the RRC (Radio Resource Control) connection: the RRC state Suspend and the RRC state Resume.
The RRC state Suspend makes it possible to release the data radio bearer (DRB) and the S1-U bearer while maintaining the context elements. The RRC state Resume allows the bearers to be restored more quickly by optimizing the number of exchanged messages.
10.2.1. RRC state Suspend
The procedure for suspending the RRC connection is described in Figure 10.3.
Figure 10.3. RRC Suspend procedure
1) The procedure for suspending the RRC connection is initiated by the evolved node base station (eNB) which sends the message S1-AP UE Context Suspend Request to the MME entity.
2) The MME entity transmits the message GTP-C RELEASE ACCESS BEARER REQUEST to the SGW entity.
The SGW removes from the context the information relating to the S1-U bearer (IP address of the eNB entity and the value of the tunnel endpoint identifier (TEID) for the downlink), but retains the other information.
3) The MME entity receives the confirmation of its request in the message GTP-C RELEASE ACCESS BEARER RESPONSE.
The MME entity keeps in its context the parameters relating to the S1-AP connection and the S1-U bearer.
4) The eNB entity receives the confirmation of its request in the message S1-AP UE Context Suspend Response.
The eNB entity keeps in its context the parameters relating to S1-AP and RRC connections.
5) The eNB entity transmits the message RRC Connection Suspend to the terminal which retains in its context the parameters relating to the RRC connection.
10.2.2. RRC state Resume
The procedure for resuming the RRC connection is described in Figure 10.4.
Figure 10.4. RRC Resume procedure
1) The procedure for resuming the RRC connection is initialized by the terminal which sends the message RRC Connection Resume to the eNB entity performing a security check.
2) The eNB entity transmits the message S1-AP UE Context Resume Request to the MME entity to warn it of the RRC connection recovery.
3) The MME responds to the eNB entity with the message S1-AP UE Context Resume Response containing the S1-U bearer parameters for uplink recovery.
4) The MME entity transmits to the SGW entity the message GTP-C MODIFY BEARER REQUEST containing the S1-U bearer parameters for downlink recovery.
5) The MME entity receives the confirmation of its request in the message GTP-C MODIFY BEARER RESPONSE.
10.3. Congestion control
Congestion control is useful when multiple terminals simultaneously transmit a connection request to the eNB entity, and an attachment request or a session establishment request to the MME entity.
A terminal can be configured with the low access priority indicator (LAPI) indicating a low priority level.
When the terminal connects, it transmits to the eNB entity an RRC message containing LAPI parameter (Figure 10.5).
When the terminal attaches, it transmits to the MME entity a NAS message containing LAPI parameter (Figure 10.5).
The LAPI is then propagated to SGW and PGW (PDN Gateway) entities in a GTP-C message when establishing bearers (Figure 10.5).
Figure 10.5. LAPI notification
The terminal transmits a session establishment request to the MME entity in a NAS message, which triggers the sending of GTP-C messages for bearer creation to the SGW and PGW entities (Figure 10.6).
If the PGW entity has detected congestion, it responds to the SGW entity with a reject GTP-C message, indicating the cause. The SGW entity relays this message to the MME entity (Figure 10.6).
The MME entity indicates to the terminal the reject of the session request in a NAS message containing the cause and value of the retransmission timer (Figure 10.6).
The terminal will have to wait for the timer expiration before retransmitting the session establishment request. The terminal may, however, transmit a session request for another access point name (APN) before the timer expires.
Figure 10.6. Congestion control: session establishment reject
If the MME entity detects congestion during an attachment request or location update, it responds to the terminal with a reject NAS message indicating the cause and value of the retransmission timer (Figure 10.7).
Figure 10.7. Congestion control: attachment reject
If the eNB entity detects congestion during a connection request, it responds to the terminal with a reject RRC message indicating the value of the retransmission timer (Figure 10.8).
Figure 10.8. Congestion control: connection reject
10.4. Procedures
10.4.1. Triggering procedure
The triggering procedure allows the SCS entity to send a short message service (SMS) to the terminal. This procedure is used for the indirect model, when the terminal cannot receive an IP packet on the SGi interface (Figure 10.9).
Figure 10.9. Triggering procedure by short message
1) The SCS entity transmits the message DIAMETER DAR (Device-Action-Request) to the MTC-IWF entity. This message contains the external identifier or the public identity (MSISDN) of the terminal, the identifier of the SCS entity and the identifier of the MTC application.
2) The MTC-IWF entity sends the message DIAMETER SIR (Subscriber-Information-Request) to the HSS entity to determine whether the SCS entity is authorized to trigger the terminal, in order to resolve the correspondence between the external identifier or the MSISDN and the IMSI.
3) The HSS entity responds with the message DIAMETER SIA (Subscriber-Information-Answer) containing the answers to questions from the MTC-IWF entity, the SMS-SC (Service Center) identity to which the SMS must be routed, and the identity of the next node.
There are three ways to define the identity of the next node:
- – the message is routed to the mobile switching center (MSC) server, in the case of the circuit-switched fallback (CSFB) function;
- – the message is routed to the IP short-messaging gateway (IP-SM-GW) for accessing the IP multimedia sub-system (IMS);
- – the message is directly routed to the MME entity.
4) The MTC-IWF entity transfers the received information to the SMS-SC entity in the message DIAMETER DTR (Device-Trigger-Request).
5) The SMS-SC entity confirms to the MTC-IWF entity in the message DIAMETER DTA (Device-Trigger-Answer) that the sending of the SMS has been accepted.
6) The MTC-IWF entity responds to the SCS entity with the message DIAMETER DAA (Device-Action-Answer), confirming that the request has been accepted.
7) The short message is transmitted to the terminal and is acknowledged to the SMS-SC entity.
8) The SMS-SC entity indicates to the MTC-IWF entity that the SMS has been delivered to the terminal in the message DIAMETER DRR (Device-Report-Request).
9) The MTC-IWF entity indicates to the SCS entity that the SMS has been delivered to the terminal in the message DIAMETER DNR (Device-Notification-Request).
10) The SCS entity acknowledges the receipt of the message DIAMETER DRR with the message DIAMETER DNA (Device-Notification-Answer) transmitted to the MTC-IWF entity.
11) The MTC-IWF entity acknowledges the receipt of the message DIAMETER DRR with the message DIAMETER DRA (Device-Report-Answer) transmitted to the SMS-SC entity.
10.4.2. Group message delivery
The group message delivery procedure allows the SCS entity to send a message to multiple terminals using the eMBMS network (Figure 10.10).
Figure 10.10. Group message delivery
1) The SCS entity sends to the SCEF entity a request for allocation of the temporary mobile group identity (TMGI), indicating its identity and the identity of the concerned group. The SCS entity may provide location information (cell identifier list, MBMS service area list, geographic area).
2) and 3) The SCEF entity verifies with the HSS entity whether the SCS entity is allowed to request a TMGI, by the exchange of the messages DIAMETER CIR (Configuration-Information-Request) and CIA (Configuration-Information-Answer).
4) and 5) The SCEF entity retrieves from the broadcast/multicast service center (BM-SC) the TMGI Identifier, by the exchange of the messages DIAMETER GAR (GCS-Action-Request) and DIAMETER GAA (GCS-Action-Answer).
6) The SCEF entity sends the TMGI allocation response to the SCS entity.
7) The terminal retrieves the TMGI from interactions at the application level with the SCS entity.
8) The SCS entity sends to the SCEF entity the group message request containing its identifier, the identifier of the concerned group, the TMGI and optionally, the location information and the start time of the message delivery.
9) and 10) The SCEF entity verifies with the HSS entity whether the SCS entity is allowed to issue group messages, by the exchange of messages DIAMETER CIR and CIA.
11), 12) and 13) The SCEF entity triggers the activation of the multicast bearer with the BM-SC entity, by the exchange of the messages DIAMETER GAR and GAA.
14) The SCEF entity sends a response to the SCS entity to indicate that the group message request has been accepted.
15) The group message transfer can then take place, from the SCS entity to the SCEF entity, then from the SCEF entity to the BM-SC entity and finally from the BM-SC entity to the terminals.
10.4.3. Event monitoring configuration
Events of which the SCEF entity wishes to be notified are provided by either the HSS entity, the MME entity or the PGW entity.
The configuration is subject to a single process when event monitoring is for a single terminal, or to a group process when event monitoring is for multiple terminals.
In the case of a single process, the messages for event monitoring configuration at the MME level can be passed through the HSS entity or directly forwarded by the SCEF entity.
The messages for event monitoring configuration at the PGW level pass through the PCRF entity.
The event configuration procedure is also used to delete a previously configured event monitoring or to replace a previously configured event monitoring with a new event monitoring.
10.4.3.1. HSS and MME configuration
The procedure for configuring event monitoring at the MME and HSS level is described in Figure 10.11, for a single process.
Figure 10.11. HSS and MME configuration: single process
1) The SCS entity sends to the SCEF entity a monitoring request by indicating the external identifier or the MSISDN, the type and the duration of monitoring.
2) The SCEF entity transfers to the HSS entity the message DIAMETER CIA containing the received information in order to configure the event monitoring on the HSS or MME entity.
3) If the event monitoring is supported by the MME entity, the HSS entity transfers the received information in the message DIAMETER IDR (Insert-Subscriber-Data-Request).
4) If the event monitoring configuration is successful, the MME entity responds to the HSS entity with the message DIAMETER IDA (Insert-Subscriber-Data-Answer). If the requested event monitoring is available at the time of sending the response, the MME entity includes the event monitoring report in the response message.
5) The HSS entity responds to the SCEF entity to inform it of the acceptance of the event monitoring request in the message DIAMETER CIR. If the requested event monitoring is available at the time of sending the response message or has been received from the MME entity, the HSS entity includes an event monitoring report in the response message.
6) The SCEF entity responds to the SCS entity to inform it of the acceptance of the event monitoring request. If the SCEF entity has received an event monitoring report, it includes it in the monitoring response message.
The procedure for configuring event monitoring at the MME and HSS level is described in Figure 10.12, for a group process.
Figure 10.12. HSS and MME configuration: group process
1) If the SCS entity wishes to configure an event monitoring for a terminal group, it sends a monitoring request message including the group identifier and the group report hold-time.
The group report hold-time is an optional parameter to indicate that aggregated event monitoring reports detected for terminals in a group should be sent when the timer has expired.
2) and 3) When the HSS entity receives the monitoring request with a group identifier in the message DIAMETER CIR, it immediately responds to the SCEF entity with the message DIAMETER CIA indicating that the group process is in progress.
4) Upon receipt of the message DIAMETER CIA, the SCEF entity transmits the monitoring response message to the SCS entity.
5) and 6) The HSS entity sends one message DIAMETER IDR per terminal to all MME entities serving the members of the group. If the monitoring configuration succeeds, each MME entity responds to the HSS entity with the message DIAMETER IDA.
7) The HSS entity accumulates several responses for the group terminals in the hold-time of the report group. After the timer expires, it sends the responses accumulated in the message DIAMETER RIR (Reporting-Information-Request) to the SCEF entity and indicates whether the response is an intermediate message or the last group message.
8) The SCEF entity accumulates the event monitoring for the group terminals until the timer expires, and sends a monitoring indication message to the SCS entity.
9) For each received monitoring indication message, the SCS entity sends a response message to the SCEF entity.
10) The SCEF responds to the message DIAMETER RIR with the message DIAMETER RIA (Reporting-Information-Answer) indicating that monitoring indications have been received.
10.4.3.2. PGW configuration
The procedure for configuring event monitoring at the PGW level through the PCRF entity is described in Figure 10.13 for a single process and in Figure 10.14 for a group process.
The procedure for configuring the PGW entity is similar to that of the MME entity, for which the following changes are made:
- – the messages DIAMETER CIR and CIA exchanged between the SCEF and HSS entities are replaced by the messages DIAMETER AAR (Authentication-Authorize-Request) and AAA (Authenticate-Authorize-Answer) exchanged between the SCEF and PCRF entities;
- – the messages DIAMETER IDR and IDA exchanged between the HSS and MME entities are replaced by the messages DIAMETER RAR (Re-Auth-Request) and RAA (Re-Auth-Answer) exchanged between the PCRF and PGW entities;
- – the messages DIAMETER RIR and RIA exchanged between the SCEF and HSS entities are replaced by the messages DIAMETER CCR (Credit-Control-Request) and CCA (Credit-Control-Answer) exchanged between the SCEF and PCRF entities.
Figure 10.13. PGW configuration: single process
Figure 10.14. PGW configuration: group process
10.4.4. NIDD transfer
10.4.4.1. Connection establishment
When the terminal performs the attachment procedure to the 4G mobile network with the “non-IP” data type and the APN, the MME entity initiates a T6a connection with the SCEF entity.
The connection is initiated by the MME entity that transmits to the SCEF entity the message DIAMETER CMR (Connection-Management-Request) containing the terminal identity.
If the SCS entity has previously executed the NIDD configuration procedure with the SCEF entity, the SCEF entity responds to the MME with the message DIAMETER CMA (Connection-Management-Answer) confirming the establishment of the connection.
If the NIDD configuration procedure with the SCEF entity has not been performed, the SCEF entity may reject the connection setup request or initiate a NIDD configuration procedure with the SCS entity.
10.4.4.2. NIDD configuration
The NIDD configuration is associated with a single terminal or a group of terminals. The procedure can also be used to replace or delete existing configuration information.
In order to avoid any errors for uplink transmission, the NIDD configuration procedure should be performed by the SCS entity before the terminal establishes a connection on the T6a interface. The downlink non-IP data from the SCS entity may be contained in the NIDD configuration request message.
The NIDD configuration procedure is described in Figure 10.15.
Figure 10.15. NIDD configuration
1) The SCS entity sends to the SCEF entity an NIDD configuration request message, which contains the terminal or the group identifier.
An optional field is used to indicate what the SCEF entity shall do if the T6a connection is not established and if data on the downlink must be sent: wait for the T6a connection to be established, reply with an error message or arm a timer.
2) The SCEF entity transmits the message DIAMETER NIR (NIDD-Information-Request) to the HSS entity to authorize the NIDD configuration request.
3) The HSS entity responds with the message DIAMETER NIA (NIDD-Information-Answer) to accept the request from the SCEF entity.
If the terminal identity uses an external identifier, the HSS entity provides the correspondence with the IMSI and/or MSISDN.
If a group identifier is included in the authorization request, the HSS entity provides the correspondence with a list of external identifiers and maps the identifiers external to the IMSI and/or MSISDN.
4) The SCEF entity sends a response message to the SCS entity to acknowledge the NIDD configuration request.
10.4.4.3. Downlink data
The procedure for transmitting downlink NIDD is described in Figure 10.16.
1) The SCS entity transmits downlink NIDD to the SCEF entity.
Maximum latency is an optional field used to indicate the maximum acceptable value. Zero latency indicates that buffering is not allowed. If maximum latency is not provided, the SCEF entity determines the acceptable delay based on local policies.
Other optional fields may be used: the priority of NIDD, the acknowledgment of data, the action to be taken if the T6a connection is not established and the sequence number if NIDD refers to previous data.
2) The SCEF entity verifies whether the SCS entity is allowed to send NIDD and whether or not it has exceeded the number of bytes or the bit rate. These values were transmitted by the MME entity during the T6a connection.
If the T6a connection is established, the SCEF entity sends to the MME entity the message DIAMETER TDR (MT-Data-Request) containing the NIDD and indicating the maximum duration during which the SCEF entity is ready to wait for a MME entity response and delay for the retransmission of NIDD.
Figure 10.16. Downlink NIDD transfer
3a) If the terminal is in the ECM_CONNECTED state, the MME entity may issue the NIDD carried by the NAS message to the terminal.
If the terminal is idle, the MME entity initiates the paging procedure so that the terminal enters the ECM_CONNECTED state.
4a) The MME entity may receive an acknowledgment of NIDD from the terminal or eNB entity, or may not receive an acknowledgment. In these different cases, the MME entity responds to the SCEF entity with the message DIAMETER TDA (MT-Data-Answer) to acknowledge receipt of NIDD.
5a) The SCEF entity sends a response to the SCS entity indicating whether the NIDD receipt has been received or not.
3b) If the MME knows that the terminal is temporarily unreachable, it responds to the SCEF entity with the message DIAMETER TDA indicating the cause (e.g. the terminal is not reachable for energy-saving reasons). The MME entity shall notify the SCEF entity when the terminal is reachable.
If the maximum retransmission time has been included in the SCEF request, the MME entity may indicate the time at which the SCEF entity shall retransmit the data.
4b) The SCEF entity may respond to the SCS entity to inform it of the results received from the MME entity. If the SCEF entity receives from MME the cause indicating that the terminal is temporarily unreachable due to power saving, it can buffer the NIDD.
5b) and 6b) When the MME entity detects that the terminal is reachable, it informs the SCEF entity with the message DIAMETER RIR, acknowledged by the SCEF response with the message DIAMETER RIA.
The procedure continues with steps 2 (transfer of NIDD to the MME entity), 3a (transfer of NIDD to the terminal), 4a (acknowledgment of the MME entity) and 5a (acknowledgment of the SCEF entity).
10.4.4.4. Uplink data
The procedure for transmitting uplink NIDD is described in Figure 10.17.
Figure 10.17. Uplink NIDD transfer
1) The terminal transmits the NIDD to the MME entity in a NAS message.
2) The MME entity transfers the NIDD to the SCEF entity in the message DIAMETER ODR (MO-Data-Request).
3) The SCEF entity transfers the NIDD to the SCS entity.
4) The SCS entity acknowledges the receipt of the data towards the SCEF entity.
5) The SCEF entity uses the message DIAMETER ODA (MO-Data-Answer) to inform the MME entity that the NIDD has been successfully delivered.