TS 22.262
SA1
★
Message Service within the 5G System
use "3GPP‑Page" to get the Word version
use "ETSI‑search" to get the PDF version
for a better overview, the Table of Contents (ToC) is reproduced
use "ETSI‑search" to get the PDF version
for a better overview, the Table of Contents (ToC) is reproduced
V16.0.0 (Wzip)
2018/12 11 p.
WI Acronym: 5GMSG
Rapporteur: Dr. Zheng, Jianping China Mobile Com. Corporation
Rapporteur: Dr. Zheng, Jianping China Mobile Com. Corporation
The present document provides the service requirements for operation of the MSGin5G Service. The MSGin5G Service provides point-to-point, application-to-point, group and broadcast message delivery for person-to-thing communication and thing-to-thing communication.
full Table of Contents for TS 22.262 Word version: 16.0.0
1 Scope Word-p. 5
2 References
3 Definitions, symbols and abbreviations
4 Overview Word-p. 6
4.1 General
The MSGin5G Service is a message enabler for applications. An application client (APP1 Client) in UE A utilizes MSGin5G Service to send a message to UE B. This message will be routed to UE B via the 5G system, or this message will be first routed to the application server (APP 1 Server) and then forwarded to UE B. If the terminated UE (UE C) supports SMS but does not support the MSGin5G Service, the message will be translated to SMS by MSGin5G Server. A UE (UE D) that does not support 3GPP message service can connect to the MSGin5G Service via MSGin5G Gateway that facilitates the translation between the MSGin5G Service and non-3GPP message service. The connection between the UE D and the gateway can be via 3GPP access or non 3GPP access (e.g. WLAN).
5 Service requirements Word-p. 7
Massive Internet of Things (MIoT) is one of key market segments of 5G. The typical IoT device communication is sending and receiving small data which can be delivered just in a message. Today SMS is used as message enabler for some IoT applications. However, SMS has limitation in term of service capabilities (e.g. 140 bytes payload) and performance (e.g. long latency), in addition, the overhead of control plane resource is high. There have been enhancements and optimizations on the 3GPP network capabilities to facilitate IoT applications including device triggering, small data transfer, and Non IP Data Delivery (NIDD) etc.
Nevertheless, the characteristics of MIoT devices including high density connection, flexible mobility, saving power, limited computing capability, bulk of devices, and traffic pattern of short burst of small data will bring various new demands on message communication, e.g. light weight message communication for provision and monitoring, ultra low latency and high reliability message communication for remote control, and extremely high resource efficiency for large scale connections.
The MSGin5G Service is basically designed and optimized for massive IoT device communication including thing-tothing communication and person-to-thing communication.
4.2 Message communication models
The MSGin5G Service is a message enabler for applications. An application client (APP1 Client) in UE A utilizes MSGin5G Service to send a message to UE B. This message will be routed to UE B via the 5G system, or this message will be first routed to the application server (APP 1 Server) and then forwarded to UE B. If the terminated UE (UE C) supports SMS but does not support the MSGin5G Service, the message will be translated to SMS by MSGin5G Server. A UE (UE D) that does not support 3GPP message service can connect to the MSGin5G Service via MSGin5G Gateway that facilitates the translation between the MSGin5G Service and non-3GPP message service. The connection between the UE D and the gateway can be via 3GPP access or non 3GPP access (e.g. WLAN).
5.1 General
6 Charging
5.1.1 Description
5.2 Point-to-point message Word-p. 8
The MSGin5G Service enables various message communication models with advanced service capabilities and performance. In addition to point-to-point, application-to-point, group and broadcast message communication are supported in the MSGin5G Service. To meet the requirements of remote control, the MSGin5G Service needs to provide very low end-to-end latency and high reliability of message delivery.
Considering the massive connections of IoT devices and high throughput of message communication between devices or between devices and application servers, the MSGin5G Service needs to be in a resource efficient manner to optimize the resource usage of the both control plane and user plane. The IoT devices usually have limitation in computation and storage, and are powered by batteries or small solar photovoltaic equipment, so the message communications need to be light weight and well scheduled in order to save power and data traffic consumption in the device.
5.1.2 Requirements
5.2.1 Description
5.3 Application-to-point message
The typical IoT communication happens between a person and a thing or two things, where the messages are Mobile Originated and Mobile Terminated (MOMT). A person can use his mobile handset to communicate with multiple smart devices, e.g. wearable devices like intelligent watch and smart home devices like air conditioner. These smart devices may have USIM or not. The MSGin5G Service needs to support addressing the UE by IMSI/MSISDN or IMEI.
There are different applications in a UE that will use point-to-point messages. The MSGin5G Service needs to identify which application a message is to be delivered to and hence route the message to the corresponding application server in the network and application client in the UE.
5.2.2 Requirements
5.3.1 Description
5.4 Group message Word-p. 9
The application-to-point message enables sending/receiving message between an application server and an IoT device. The message can be Mobile Originated Application Terminated (MOAT) and Application Originated Mobile Terminated (AOMT). The MOAT messages can be used by devices for reporting the small data. For example, in environmental monitoring, a monitoring device sends a message to the application server to report the collected data by the sensor every hour. The AOMT messages can be used by an application server to manage or control the devices. For example, in shared bike communication, the application server sends a message to a bike to unlock the bike.
One type of devices need to report data to the application server in a scheduled way (e.g. every hour). Another type of devices need to be reachable by the application server in a non-scheduled way, e.g. the server updates the configuration of the device. An IoT device that is powered by batteries or small solar photovoltaic equipment, needs to access the MSGin5G Service in the whole lifecycle (e.g. 10 years), which requires the MSGin5G Service be very light weight in power consumption. The AOMT messages are time sensitive. The MSGin5G Service needs to support low latency delivery of AOMT messages.
5.3.2 Requirements
5.4.1 Description
5.5 Broadcast message
In 5G IoT communication, there is a need that a group of devices can communicate with each other, which means the message sent by a device will be received by all the other devices in the group. The members of a group can be devices for persons and smart things that are located in different geographical areas. Group management mechanism is required to support the members joining or leaving a group.
5.4.2 Requirements
5.5.1 Description
The MSGin5G Service for MIoT needs to support broadcast message delivery in order to handle the massive communications efficiently without long latency. The receivers of broadcast messages can be all UEs within a cell or multiple cells. The broadcast areas can be configured according to the policy of application.
To avoid malicious attack, only authorized UEs or application server can send broadcast messages.
5.5.2 Requirements
6.1 Description
7 Security Word-p. 10
The business model of MIoT market may be different from that of consumer market. The MNO may need flexible policy for charging of the MSGin5G Service, e.g., flat rate (per month or per year), charge per message, and charge by amount of data. For different message communication models, the charging policy may be distinguished. The MSGin5G Service needs to provide charging information to support different charging policy.
6.2 Requirements
7.1 Description
8 Roaming
The messages of thing-to-thing or person-to-thing can be critical, e.g., a message for remote control may trigger actions of a device. To protect an IoT device from malicious attack, only authorized UEs can send messages to this device. In addition, the content of messages need to be integrity and confidentiality protected.
The IoT devices may be battery-powered, so the security mechanism for MSGin5G needs to be light weight.
7.2 Requirements
8.1 Description
9 Interconnection
The IoT device can be a device equipped in a vehicle moving from one nation to anther nation. When roaming, the device needs to be able to access to the MSGin5G Service.
8.2 Requirements
9.1 Description
10 Interworking Word-p. 11
The MSGin5G Service is a service that can involve two different operators on originating and terminating side, and hence interconnection is needed.
9.2 Requirements
10.1 Description
A Change history
The legacy IoT devices have been widely deployed. These devices may support legacy message service like SMS. When the terminated UE does not support the MSGin5G Service, interworking between MSGin5G Service and another message service (e.g., SMS) is required subject to the operator's policy.
10.2 Requirements
