Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x
Top   in Index   Prev   Next

TS 22.262
Message Service within the 5G System

3GPP‑Page   ETSI‑search   CONTENT↓
V18.0.1 (PDF)  2024/03  13 p.
V17.1.0  2022/03  14 p.
V16.0.0  2018/12  14 p.
Rapporteur:
Dr. Zheng, Jianping
China Mobile Com. Corporation

Content for  TS 22.262  Word version:  18.0.1

Here   Top
0 Introduction  1 Scope  2 References  3 Definitions, symbols and abbreviations  4 Overview  5 Service requirements  5.1 General  5.2 Point-to-point message  5.3 Application-to-point message  5.4 Group message  5.5 Broadcast message  6 Charging  7 Security  8 Roaming  9 Interconnection  10 Interworking  $ Change history 

 

0  Introduction  p. 4

1  Scope  p. 5

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.

2  References  p. 5

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
  • For a specific reference, subsequent revisions do not apply.
  • For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
Up

3  Definitions, symbols and abbreviations  p. 5

3.1  Definitions  p. 5

For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
application-to-point message:
message that is originated at a UE and terminated at an application sever in the network or originated at an application sever in the network and terminated at a UE.
MSGin5G Service:
a MNO message service within the 5G System that enables point- to-point, application-to-point, group and broadcast message delivery for thing-to-thing communication and person-to-thing communication.
MSGin5G Server:
an entity in the 5G system for routing messages between UEs and messages between application servers and UEs.
MSGin5G Gateway:
an entity in the 5G system for interworking between the MSGin5G Service and non-3GPP message service.
point-to-point message:
message that is originated at a UE and terminated at a UE.
Up

3.3  Abbreviations  p. 5

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
AOMT
Application Originated Mobile Terminated
IoT
Internet of Things
MIoT
Massive Internet of Things
MOAT
Mobile Originated Application Terminated
MOMT
Mobile Originated Mobile Terminated
NIDD
Non IP Data Delivery
Up

4  Overview  p. 6

4.1  General  p. 6

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-to-thing communication and person-to-thing communication.
Up

4.2  Message communication models  p. 6

Reproduction of 3GPP TS 22.262, Fig. 4.2: The MSGin5G Service overview
Figure 4.2: The MSGin5G Service overview
Up
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).
The message communication models include:
  • point-to-point message: message that is originated at a UE and terminated at a UEs.
  • application-to-point message: message that is originated at a UE and terminated at an application sever in the network or originated at an application sever in the network and terminated at a UE.
  • group message: messages are originated at a UE and terminated at a group of UEs (the members of a group can be located in different geographical areas).
  • broadcast message: messages are originated at an application sever in the network or an UE and terminated at all the UEs in a specific service area within a cell or multiple cells.
Up

5  Service requirements  p. 7

5.1  General  p. 7

5.1.1  Description  p. 7

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.
Up

5.1.2  Requirements  p. 7

[R-5.1.2-001]
The MSGin5G Service shall support UE sending and receiving a text or data message with end-to-end latency less than [500] ms.
[R-5.1.2-002]
The MSGin5G Service shall support variable size of payload of a text or data message with maximum [2048] bytes, and support segmented transmission if the content is large than the maximum payload length of a message.
[R-5.1.2-003]
The MSGin5G Service shall support delivery of a message to a specific application in the terminated UE. This message contains the contents that can be handled by the specific application.
[R-5.1.2-004]
The MSGin5G Service shall support acknowledgement of delivery status (success, failure) of a message and indication of reason if the delivery is failed.
[R-5.1.2-005]
The MSGin5G Service shall support storage of a message if a UE is unavailable (disconnected or power off) for future delivery once the UE becomes available.
[R-5.1.2-006]
The MSGin5G Service shall support a server in the network triggering the UE to perform an action (e.g. wake up and establish a PDN connection).
[R-5.1.2-007]
The MSGin5G Service shall support a UE sending and receiving messages via a MSGin5G Gateway
[R-5.1.2-008]
The MSGin5G Service shall support the mobility of a UE (i.e. the UE can still send/receive messages when it changes the location of network access).
[R-5.1.2-009]
The MSGin5G Service shall support per-message information for store and forward, e.g. whether the message can be buffered or how long the message is valid.
Up

5.2  Point-to-point message  p. 8

5.2.1  Description  p. 8

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.
Up

5.2.2  Requirements  p. 8

[R-5.2.2-001]
The MSGin5G Service shall support Mobile Originated Mobile Terminated (MOMT) messaging, i.e. messages are originated and terminated at UEs.
[R-5.2.2-002]
The MSGin5G Service shall support addressing the UE by IMSI/MSISDN or IMEI.
[R-5.2.2-003]
The MSGin5G Service shall support a mechanism to identify the applicable application and route a MOMT message to the corresponding application server in the network and application client in the UE.

5.3  Application-to-point message  p. 8

5.3.1  Description  p. 8

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.
Up

5.3.2  Requirements  p. 8

[R-5.3.2-001]
The MSGin5G Service shall support Mobile Originated Application Terminated (MOAT) messaging, i.e. messages are originated at a UE and terminated at an application sever in the network.
[R-5.3.2-002]
The MSGin5G Service shall support Application Originated Mobile Terminated (AOMT) messaging, i.e. messages are originated at an application sever in the network and terminated at a UE.
[R-5.3.2-003]
The MSGin5G Service shall support Application Originated Mobile Terminated messaging service with max latency of 10 seconds while maintaining battery life of at least 3 months for small data traffic once every hour and typical sized IOT battery [200-500mAh].
Up

5.4  Group message  p. 9

5.4.1  Description  p. 9

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  p. 9

[R-5.4.2-001]
The MSGin5G Service shall support group message communication, i.e. a UE sends a message to a group of UEs. All the members in a group can send messages. The UEs in a group can be located in different geographical areas.
[R-5.4.2-002]
The MSGin5G Service shall support group management for message communication:
  • establishing/deleting a group
  • adding UEs to the group or removing UEs from the group
  • configuration of a maximum number of members in a group

5.5  Broadcast message  p. 9

5.5.1  Description  p. 9

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  p. 9

[R-5.5.2-001]
The MSGin5G Service shall support broadcasting a text or data message with end-to-end latency less than [500] ms.
[R-5.5.2-002]
The MSGin5G Service shall support an authorized application server or UE to send a broadcast message to all the UEs within a specific area which is configured according to application policy.

6  Charging  p. 9

6.1  Description  p. 9

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  p. 9

[R-6.2-001]
The MSGin5G Service shall be able to collect charging information of a UE according to the operator's charging policy including charge per message, charge by amount of data, and flat rate (e.g., per month or per year).
[R-6.2-002]
The MSGin5G Service shall be able to collect charging information of an application provider in application-to-point message communication.

7  Security  p. 10

7.1  Description  p. 10

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  p. 10

[R-7.2-001]
The MSGin5G Service shall support a mechanism for the operator to configure the allow-list of UEs that are authorized to send messages to a specific UE. The MSGin5G Service shall be able to block messages from non-authorized UEs.
[R-7.2-002]
The MSGin5G Service shall support integrity and confidentiality protection for the payload of a message.

8  Roaming  p. 10

8.1  Description  p. 10

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  p. 10

[R-8.2-001]
The MSGin5G Service shall support a roaming UE sending and receiving messages.

9  Interconnection  p. 10

9.1  Description  p. 10

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  p. 10

[R-9.2-001]
The MSGin5G Service shall support an UE within an operator sending a message to another UE within another operator.
[R-9.2-002]
The MSGin5G Service shall support an application server sending/receiving a message to/from a UE within another operator.

10  Interworking  p. 11

10.1  Description  p. 11

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  p. 11

[R-10.2-001]
The MSGin5G Service shall be able to interwork with SMS for point-to-point message and application-to-point message.
[R-10.2-002]
The MSGin5G Service shall be able to translate one message into multiple SMS messages when the length of a message of MSGin5G Service is large than the maximum length of a SMS message.

$  Change history  p. 11

Up   Top