5 Service requirements

22.2623GPPMessage service within the 5G System (5GS)Release 17Stage 1TS

5.1 General

5.1.1 Description

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

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

NOTE 1: Initial connection activation latencies may be longer depending on receiving UE power saving states, paging, etc.

[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

NOTE 2: The connection between the UE and the MSGin5G Gateway can be 3GPP or non-3GPP access (e.g. WLAN.)

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

5.2 Point-to-point message

5.2.1 Description

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

[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

5.3.1 Description

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

[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].

5.4 Group message

5.4.1 Description

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

[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

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

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