6 MSGin5G Procedures

24.5383GPPEnabling MSGin5G ServiceProtocol specificationRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.1 General

In clause 6, the detailed behaviors of the MSGin5G UE, the MSGin5G Server and Constrained UE with/without MSGin5G Client during the MSGin5G procedures are described.

Depending on communication over different MSGin5G interfaces, different MSGin5G procedures are supported as:

a) For the communication between the MSGin5G Client of MSGin5G UE and the MSGin5G Server over the MSGin5G-1 interface, the following procedures are involved:

1) Configuration;

2) Registration and de-registration;

3) MSGin5G message delivery including sending and receiving MSGin5G message, aggregated MSGin5G message, MSGin5G message delivery status report and aggregated MSGin5G message delivery status report.

4) MSGin5G message segment and reassembly; and

5) Messaging topic subscription.

b) For the communication between the Constrained UE (without MSGin5G Client) and MSGin5G Gateway UE which is an Unconstrained UE over the MSGin5G-5 interfaces, the following procedures are involved:

1) Registration and de-registration;

2) message delivery procedure including sending and receiving message and message delivery status report.

c) For the communication between the Constrained UE (with MSGin5G Client) and the MSGin5G Relay UE which is an Unconstrained UE over the MSGin5G-6 interfaces, all the procedures listed in bullet a) are supported. The communication between MSGin5G Client of the Constrained UE and the MSGin5G Server re-uses the procedures listed in bullet a). The MSGin5G Relay UE relays the requests and responses as traffic between the MSGin5G Client of the Constrained UE and the MSGin5G Server.

For procedures used for bullet a) and bullet c), CoAP specified in IETF RFC 7252 [5] is used as the basic transport protocol. For procedures used for bullet b), guidance on definitions of the message format and information elements are described in Annex A.

The authorization of MSGin5G Client by the MSGin5G Server is performed by verifying the UE service ID as specified in Annex Y of TS 33.501 [16].

6.2 Configuration

6.2.1 MSGin5G UE Configuration

6.2.1.1 General

MSGin5G UE Configuration is based on the configuration management functionality specified in TS 23.434 [3] and TS 24.546 [6].

6.2.1.2 Procedure at MSGin5G Client

The MSGin5G UE should support the configuration management client functionality as specified in 3GPP TS 23.546 [6]. The configuration management client functionality may be collocated with MSGin5G Client or it can be separated with MSGin5G Client as per 3GPP TS 23.554 [2].

If the configuration management client functionality is not collocated with the MSGin5G Client, the MSGin5G Client should use SEAL-C interface to interact with configuration management client functionality for MSGin5G UE configuration.

The MSGin5G UE configuration procedures at the configuration management client functionality are based on the procedures in clause 6.2.3.3 of 3GPP TS 24.546 [6], in the procedures:

a) the configuration management client functionality on the MSGin5G UE acts as SCM-C;

b) the configuration management server functionality at the server-side acts as SCM-S;

c) shall set the Option header to the CoAP URI identifying the user profile document to be retrieved according to the resource API definition in Annex C.3.1 of 3GPP TS 24.546 [6],

1) the "apiRoot" is set to the URI of the configuration management server functionality at the server-side;

2) the "valServiceId" is set to the unique service identifier of MSGin5G service; and

3) the configuration management client functionality shall make a GET request for the UE Configurations as described in Annex C.3.1.2.2.3.1 of 3GPP TS 24.546 [6] and shall set applicable query parameters defined in table C.3.1.2.2.3.1-1 of 3GPP TS 24.546 [6] with the clarification listed below.

i) the ue-uri is set to the MSGin5G UE ID as specified in 3GPP TS 23.554 [2]

ii) the ue-vendor and/or the ue-type parameter are set to the MSGin5G UE information as specified in 3GPP TS 23.554 [2] if included.

Upon receiving the requested MSGin5G UE configuration data, the configuration management client functionality shall submit the configuration data to MSGin5G Client by SEAL-C interface if it is not collocated with the MSGin5G Client. The MSGin5G Client shall store the configuration data, including MSGin5G UE Service ID, the address of MSGin5G Server and other available MSGin5G Service specific information.

The corresponding JSON Schema used in step e) is defined in 7.3.2.1.

6.2.1.3 Procedure at MSGin5G Server

The configuration management server functionality as specified in 3GPP TS 23.546 [6] may be collocated with MSGin5G Server or it can be separated with MSGin5G Server as per 3GPP TS 23.554 [2].

The MSGin5G UE configuration procedures at the configuration management server functionality are based on the procedures in clause 6.2.3.4 of 3GPP TS 24.546 [6]. In the procedures, the configuration management server function acts as SCM-S.

6.2.2 Constrained device Configuration

6.2.2.1 Procedure at MSGin5G Relay UE

When the MSGin5G Client on the MSGin5G Relay UE receives a CoAP GET request from UDP port XXX and the recipient’s address included in the CoAP Option is set to the configuration management server functionality, the MSGin5G Relay UE acts as either 5G ProSe Layer-2 and Layer-3 UE-to-Network Relay entity as specified in 3GPP TS 23.304 [9] and relays the CoAP GET request as a uplink traffic to the configuration management server functionality.

Editor’s note: The exact UDP port number on which the CoAP GET request is sent, is FFS.

When the MSGin5G Client-1 on the MSGin5G Relay UE receives a CoAP 2.05 (Content), 4.03 (Forbidden) or 4.04 (Not found) response from UDP port XXX and the recipient’s address included in the CoAP Option is set to another MSGin5G Client-2 which has established a connection for One-to-one ProSe Direct Communication with it as specified in 3GPP TS 23.304[9], the MSGin5G Relay UE acts as either 5G ProSe Layer-2 and Layer-3 UE-to-Network Relay entity as specified in 3GPP TS 23.304 [9] and relays the CoAP 2.05 (Content), 4.03 (Forbidden) or 4.04 (Not found) response as a downlink traffic to the MSGin5G Client-2, Otherwise the MSGin5G Client-1 shall discard the CoAP 2.05 (Content), 4.03 (Forbidden) or 4.04 (Not found) response.

Editor’s note: The exact UDP port number on which the CoAP GET response is sent, is FFS.

6.2.2.2 Procedure at Constrained UE with MSGin5G Client

In order to send an MSGin5G UE Configuration request, the configuration management client functionality on the Constrained UE with MSGin5G Client shall use the procedures specified in clause 6.2.1.2.

Upon receiving an CoAP 2.05 (Content), 4.03 (Forbidden) or 4.04 (Not found) response and the recipient’s address included in the CoAP Option is set to the MSGin5G Client itself, the MSGin5G Client shall handle the CoAP 2.05 (Content), 4.03 (Forbidden) or 4.04 (Not found) response as specified in clause 6.2.1.2.

6.3 Registration

6.3.1 MSGin5G UE Registration

6.3.1.1 Procedure at MSGin5G Client

6.3.1.1.1 MSGin5G UE registration

After the UE Service ID is configured to the MSGin5G UE, in order to register MSGin5G UE to the MSGin5G Server, the MSGin5G Client shall send a CoAP POST request to the MSGin5G Server according to procedures specified in IETF RFC 7252 [5]. In this CoAP POST request, the MSGin5G Client:

a) shall set the "T" field in the CoAP header to 0 to indicate acknowledge message required;

b) shall include the MSGin5G Server address in the Option header of the CoAP POST request and set the Option header to a corresponding value, e.g. if the MSGin5G Server address is a URI, the Uri-Path Option is set to the value of such URI;

c) shall set the "Content-Format" element to "50" to indicate the format of the CoAP payload is "application/json"; and

d) shall include the following information elements in the CoAP payload encoded in JSON format as specified in clause 7.3.3.1:

1) the "MSGin5G service identifier" element to indicate that this CoAP POST request is used for MSGin5G service;

2) the "Message Type" element with a "REG" value to indicate that this CoAP POST request is used for registration;

3) the "UE Service ID" element to indicate the MSGin5G UE initiating registration procedure; and

4) optionally, the "MSGin5G Client Profile" element to include a set of parameters describing the MSGin5G Client. This element may include the "MSGin5G Client Triggering Information" element and the "MSGin5G Client Communication Availability" element. The "MSGin5G Client Triggering Information" element shall include the "MSGin5G UE ID" element to indicate the MSGin5G UE hosting the MSGin5G Client and the "MSGin5G Client Ports" element to indicate that the MSGin5G Client listens on for device triggers from the MSGin5G Server. The "MSGin5G Client Communication Availability" element informs the MSGin5G Server whether the client has a specific application-level schedule/periodicity to its MSGin5G communications, which may be used in conjunction with UE reachability monitoring to determine whether and when MSGin5G communications are attempted. This element:

i) shall include the "Scheduled communication time" element to indicate the time when the UE becomes available for communication;

ii) shall include the "Communication duration time" element to indicate the duration time of periodic communication;

iii) may include the "Periodic communication indicator" element to identify whether the client communicates periodically or not;

iv) may include the "Periodic communication interval" element to indicate the interval Time of periodic communication if "Periodic communication indicator" element is included;

v) may include the "Data size indication" element to indicate the expected data size to be exchanged during the communication duration; and

vi) may include the "Store and forward option" element to indicate the UE does not request store and forward services for incoming MSGin5G requests.

6.3.1.1.2 MSGin5G UE de-registration

The MSGin5G Client initiates a CoAP POST request to de-register from the MSGin5G Server. In this CoAP POST request, the MSGin5G Client:

a) shall set the "T" field in the CoAP header to 0 to indicate acknowledge message required;

c) shall set the "Content-Format" element to "50" to indicate the format of the CoAP payload is "application/json"; and

d) shall include the following information elements encoded in JSON format as specified in clause 7.3.3.2:

1) the "MSGin5G service identifier" element to indicate that this CoAP POST request is used for MSGin5G service;

2) the "Message Type" element with a "DEREG" value to indicate that the CoAP POST request is used for de-registration; and

3) the "UE Service ID" element to indicate the MSGin5G UE initiating de-registration procedure.

6.3.1.2 Procedure at MSGin5G Server

6.3.1.2.1 MSGin5G UE registration

Upon reception of the CoAP POST request containing MSGin5G service identifier indicating that the received request is for MSGin5G service and Message Type indicating that the received request is for registration, the MSGin5G Server shall verify the UE service ID. After a successful verification, the MSGin5G Server:

a) shall store the UE Service ID and the MSGin5G Client Profile information included in the received CoAP POST request; and

b) shall generate a CoAP 2.01 (Created) response or CoAP 2.04 (Change) response including the following parameters:

1) the CoAP "Message ID" element and the "Token" element with the same values with those in the CoAP POST request for registration; and

2) the "Content-Format" element with "50" to indicate the format of the CoAP payload is "application/json" and the CoAP payload encoded in JSON format as specified in clause 7.3.3.1 including:

i) the "UE Service ID" element to indicate the MSGin5G UE initiating registration procedure; and

ii) the "Registration result" element to indicate whether the registration is success or failure.

6.3.1.2.2 MSGin5G UE de-registration

Upon reception of the CoAP POST request containing MSGin5G service identifier indicating that the received request is for MSGin5G service and Message Type indicating that the received request is for deregistration from an MSGin5G UE, the MSGin5G Server shall verify the UE service ID. After a successful verification, the MSGin5G Server:

a) shall delete the registration information of the MSGin5G UE and any applicable MSGin5G Client Profile information that it has stored; and

b) shall generate a CoAP 2.04 (Change) response including the following parameters:

1) the CoAP "Message ID" element and the "Token" element with the same values with those in the CoAP POST request for deregistration;

2) optionally, the MSGin5G Client address in the Option header of the CoAP response and set the Option header to a corresponding value, if it is provided in the payload of CoAP POST request; and

3) the "Content-Format" element with "50" to indicate the format of the CoAP payload is "application/json" and the CoAP payload encoded in JSON format as specified in clause 7.3.3.2 including:

i) the "UE Service ID" element to indicate the MSGin5G UE initiating de-registration procedure; and

ii) the "De-registration result" element to indicate whether the registration is success or failure.

6.3.2 Constrained UE registration to use MSGin5G Gateway UE

6.3.2.1 Procedure at Gateway MSGin5G UE

6.3.2.1.1 Constrained UE registration to use MSGin5G Gateway UE

Upon reception of registration request from the application client on the Constrained UE, the MSGin5G Gateway UE decides whether to accept the registration request based on local condition.

If the registration is accepted by the MSGin5G Gateway UE, the MSGin5G Client on the MSGin5G Gateway UE:

a) stores Application ID included in the registration request from the Constrained UE and the mapping between the transport identifier and the Application ID;

NOTE 1: Based on the connection mode, e.g. L2 connection or L3 connection, the MSGin5G Gateway UE can allocate a specified MAC address or UDP port for exchanging information between the MSGin5G Gateway UE and the Constrained UE. The transport mechanism is based on the legacy transport protocol.

NOTE 2: The MSGin5G Gateway UE retrieves the transport identifier from the transport layer. The transport identifier can be a Layer-2 ID, e.g. a MAC address, or a Layer-3 ID, e.g. an IP address with a specific UDP port.

b) allocates a Registration ID for the Constrained UE; and

c) constructs the registration response and sends it to the application client on the Constrained UE. The registration response shall include:

1) the Registration Result indicates the registration is accepted by the MSGin5G Gateway UE; and

2) the Registration ID allocated by the MSGin5G Gateway UE.

If the registration is not accepted by the MSGin5G Gateway UE, the MSGin5G Client on the MSGin5G Gateway UE constructs the registration response and sends it to the application client on the Constrained UE. The registration response shall include:

a) the Registration Result indicating the registration is not accepted by the MSGin5G Gateway UE; and

b) the Failure Reason indicating an appropriate reason why the registration request is rejected by the MSGin5G Gateway UE.

6.3.2.1.2 Constrained UE de-registration to use MSGin5G Gateway UE

Upon reception of de-registration request from the application client on the Constrained UE, the MSGin5G Gateway UE:

a) removes the mapping between Application ID and transport identifier of the UE-2 based on the Registration ID included in the de-registration request; and

b) constructs the de-registration response including:

1) the De-registration Result indicating whether the de-registration is accepted or not;

2) the Registration ID included in the de-registration request, if the de-registration is accepted by the MSGin5G Gateway UE; and

3) the Failure Reason indicating an appropriate cause indicating why the de-registration request is rejected by the MSGin5G Gateway UE, if the de-registration is not accepted by the MSGin5G Gateway UE.

NOTE: Based on the connection mode, e.g. L2 connection or L3 connection, the MSGin5G Gateway UE may allocate a specified MAC address or UDP port for exchanging information between the MSGin5G Gateway UE and the Constrained UE. The transport mechanism is based on the legacy transport protocol.

6.3.2.2 Procedure at Constrained UE

6.3.2.2.1 Constrained UE registration to use MSGin5G Gateway UE

In order to register Constrained UE to the MSGin5G Gateway UE, the Application Client on the Constrained UE sends a registration request to the MSGin5G Client on the MSGin5G Gateway UE. The registration request shall include the "Application ID" to indicate the Application Client on the Constrained UE initiating registration.

NOTE: If a specified MAC address or UDP port is configured for exchanging information between the MSGin5G Gateway UE and the Constrained UE, the Constrained UE shall send the registration request to the specified MAC address or UDP port.

6.3.2.2.2 Constrained UE de-registration to use MSGin5G Gateway UE

In order to de-register Constrained UE to the MSGin5G Gateway UE, the Application Client on the Constrained UE sends a de-registration request to the MSGin5G Client on the MSGin5 Gateway UE. The de-registration request shall include the "Registration ID" which has been allocated by the MSGin5G Gateway UE during the registration procedure.

NOTE: If a specified MAC address or UDP port is configured for exchanging information between the MSGin5G Gateway UE and the Constrained UE, the Constrained UE shall send the de-registration request to the specified MAC address or UDP port.

6.3.3 Constrained UE registration to use MSGin5G Relay UE

6.3.3.1 General

The MSGin5G Relay UE acts as either 5G ProSe Layer-2 or Layer-3 UE-to-Network Relay entity as specified in 3GPP TS 23.304 [9] and relays the CoAP POST request/response as traffic between the MSGin5G Server and the Constrained UE.

6.3.3.2 Procedure at MSGin5G Relay UE

6.3.3.2.1 Constrained UE with MSGin5G Client registration via MSGin5G Relay UE

When a CoAP POST request for registration from the MSGin5G Client of the Constrained UE, the MSGin5G Relay UE relays the CoAP POST request as an uplink traffic to the MSGin5G Server.

When the CoAP 2.01 (Created) response or CoAP 2.04 (Change) response returned from the MSGin5G Server, the MSGin5G Relay UE relays the CoAP 2.01 (Created) response or CoAP 2.04 (Change) response as a downlink traffic to Constrained UE.

6.3.3.2.2 Constrained UE with MSGin5G Client de-registration via MSGin5G Relay UE

When a CoAP POST request for de-registration from the MSGin5G Client of the Constrained UE, the MSGin5G Relay UE relays the CoAP POST request as an uplink traffic to the MSGin5G Server.

When a CoAP 2.04 (Change) response returned from the MSGin5G Server, the MSGin5G Relay UE relays the CoAP 2.04 (Change) response as a downlink traffic to Constrained UE.

6.3.3.3 Procedure at Constrained UE

6.3.3.3.1 Constrained UE with MSGin5G Client registration via MSGin5G Relay UE

In order to register Constrained UE to the MSGin5G Server, the MSGin5G Client of Constrained UE sends a CoAP POST request to the MSGin5G Server via the MSGin5G Relay UE. The CoAP POST request is constructed as specified in clause 6.3.1.1.1.

6.3.3.3.2 Constrained UE with MSGin5G Client de-registration via MSGin5G Relay UE

In order to de-register Constrained UE to the MSGin5G Server, the MSGin5G Client of Constrained UE sends a CoAP POST request to the MSGin5G Server via the MSGin5G Relay UE. The CoAP POST request is constructed as specified in clause 6.3.1.1.2.

6.4 MSGin5G Message delivery

6.4.1 Procedures between MSGin5G UE and MSGin5G Server

6.4.1.1 Procedure at MSGin5G Client

6.4.1.1.1 General

This clause specifies the procedures for sending and receiving MSGin5G message, aggregated MSGin5G message, MSGin5G message delivery status report and aggregated MSGin5G message delivery status report at MSGin5G Client.

6.4.1.1.2 Sending of an MSGin5G message

In order to send an MSGin5G message, the MSGin5G Client shall compare the size of the received message from the Application Client to the maximum allowed MSGin5G message segmentation size. If the size exceeds, the MSGin5G Client shall segment the MSGin5G message into a set of segmented MSGin5G messages such that each segmented MSGin5G message can fit within the maximum allowed MSGin5G message segmentation size. For each segmented MSGin5G message, the steps listed below shall be processed individually.

The MSGin5G Client shall send the MSGin5G message in a CoAP POST request message according to procedures specified in IETF RFC 7252 [5]. In the CoAP POST request message, The MSGin5G Client:

a) shall set the "T" field in the CoAP header to 0 if delivery status report from the recipient is requested, i.e. indicates that this message is the type of Confirmable, to ensure the application layer delivery status report;

b) shall include the MSGin5G Server address in a CoAP Option, e.g. if the MSGin5G Server address is a URI, includes a Uri-Path Option with the value of the URI;

c) shall set the CoAP Content-Format to "50", i.e. application/json;

d) shall include the information elements specified in 3GPP TS 23.554 [2] in the CoAP payload encoded in JSON format as specified in clause 7.3.4:

1) shall include an "MSGin5G service identifier" element to indicate that this CoAP POST request message is used for MSGin5G service;

2) shall include a "Message Type" element and set it to "MSG" to indicate that this CoAP POST request message is used for MSGin5G message;

3) shall include an "Originating UE Service ID" element set to the UE which requests the sending of the MSGin5G message;

4) shall include a "Recipient UE Service ID/AS Service ID" element if the recipient is an MSGin5G UE/Non-MSGin5G UE or Application Server;

5) shall include a "Group Service ID" element if the recipient is an MSGin5G Group;

6) shall include a "Broadcast Area ID" element if the message needs to be broadcast;

7) shall include a "Messaging Topic" element if this message will be distributed based on message topic. This element shall not present in other message scenarios;

NOTE: In an MSGin5G Message request, only one of these IEs listed from step 4) to step 6) shall be included.

8) may include one or more "Application ID" elements to indicate the application(s) for which the payload is(are) intended;

9) shall include a "Message ID" which is globally unique within the MSGin5G service to identify this specific MSGin5G message;

10) may include a "Delivery status required" element if delivery acknowledgement from the recipient is requested;

11) may include a "Priority type" element to indicate the application priority level requested for this message;

12) may include a "Message is segmented" element with a "true" value to indicate that this message is part of a segmented message;

13)if "Message is segmented" element with a "true" value is included, shall include a "Segmentation set identifier" element to indicate that this segmented message is associated within a set of segmented messages. All segmented messages associated with the same MSGin5G message shall be assigned the same unique identifier;

14) if "Message is segmented" element with a "true" value is included and this message is the first segment of the set of segmented messages, shall include a "Total number of message segments" element to indicate the total number of segments for the MSGin5G message;

15) if "Message is segmented" element with a "true" value is included, shall include a "Message segment number" element to indicate the number of each segmented message within a set of segmented messages;

16) if "Message is segmented" element with a "true" value is included and this message is the last segment of the set of segmented messages, shall include a "Last segment flag" element to indicate that this segmented message is the last segment in the set of segmented messages;

17)shall include a "Store and forward flag" element to indicate whether store and forward services are requested for this message;

18) if store and forward services are requested, may include a "Store and forward parameters" element to carry the parameters used by MSGin5G Server for providing store and forward services. The "Store and forward parameters":

i) may include a "Message expiration time" element to indicate the message expiration time used for providing store and forward services if the destination is not available for communications; and

ii) may include an "Application specific store and forward information" element to carry the information used by MSGin5G Server for handling store and forward, e.g. a delivery time/date; and

19) may include a "Payload" element which carries the application payload that is transferred by the MSGin5G Service in the CoAP payload and located it after the elements listed from step 1) to 19); The content of "Payload" element is transparent to the MSGin5G Service; and

e) if needed, i.e. a message segment recovery request is received, acts as Message Sender to perform the procedures in clause 6.5.1.1.

6.4.1.1.3 Sending of an aggregated MSGin5G message

Before the sending of an MSGin5G message, the MSGin5G Client shall check if aggregation is allowed for this message, check the message data size, and the priority level to determine if the message can be aggregated. For example, if the MSGin5G Client finds that the messages have small payload size when compared to the maximum segment size that can be transmitted over CoAP and the messages are not high priority messages, which could be sent as per scheduling policy towards a selected target, the MSGin5G Client can decide to aggregate messages until optimal use of segment size before sending message towards MSGin5G Server.

If the message can be aggregated, the MSGin5G Client aggregates multiple MSGin5G message requests intended for a selected target and sends the aggregated message in a single CoAP POST request message. The sending of the CoAP POST request message shall follow the procedures specified in clause 6.4.1.1.2 with the clarifications listed below:

a) The MSGin5G Client should not segment the aggregated message, so in step d) of clause 6.4.1.1.2, the "Message is segmented", "Segmentation set identifier", "Total number of message segments", "Message segment number" and "Last segment flag" elements should not be included.

b) In addition to the step d) of clause 6.4.1.1.2, the MSGin5G Client should include a "Number of individual messages" element in this message to indicate the total number of messages which are aggregated into this single message.

c) In addition to the step d) of clause 6.4.1.1.2, the MSGin5G Client should include a "List of individual messages" element in this message. Each child element of this "List of individual messages" element contains information elements listed below:

1) "Message ID" of the individual message;

2) "Payload" which carries the application payload that is transferred by the individual MSGin5G message;

3) one or more optional "Application ID" elements;

4) an optional "Delivery status required" element; and

5) an optional "Priority type" element.

d) The MSGin5G Client should not include the "Payload" element outside the "List of individual messages" element, i.e. the 19) in step e) of clause 6.4.1.1.2 shall not be processed.

6.4.1.1.4 Sending of an MSGin5G message delivery status report

In order to send a MSGin5G message delivery status report, the MSGin5G Client shall send an CoAP POST request according to procedures specified in IETF RFC 7252 [5]. In the CoAP POST request, the MSGin5G Client:

a) shall sets the "T" field in the CoAP header to 0, i.e. indicates that this message is the type of Confirmable, to ensure that the MSGin5G message delivery status report can be received by the originator of the receiving MSGin5G message;

b) shall include the MSGin5G Server address in an CoAP Option, e.g. if the MSGin5G Server address is a URI, includes a Uri-Path Option with the value of the URI;

c) shall set the CoAP Content-Format to "50", i.e. application/json; and

d) shall include the information elements specified in 3GPP TS 23.554 [2] in the CoAP payload encoded in JSON format as specified in clause 7.3.4.2:

1) shall include an "MSGin5G service identifier" element to indicate that this CoAP POST request message is used for MSGin5G service;

2) shall include an "Message Type" element and set it to "IMDN" to indicate that this CoAP POST request message is used for MSGin5G message delivery status report;

3) shall include an "Originating UE Service ID" element set to the UE which requests the sending of the MSGin5G message delivery status report;

4) shall include a "Recipient UE Service ID/AS Service ID" element if the recipient is an MSGin5G UE/Non-MSGin5G UE or an Application Server. This element indicates is the sender of the message that this message delivery status report is for;

5) shall include the "Message ID" element copied from the MSGin5G message that is being acknowledged;

6) shall include a "Delivery Status" element to carry the delivery status description. The delivery status can be success or failure in delivery; and

7) may include a "Failure Cause" element to indicate the failure reason if the delivery status is failure.

6.4.1.1.5 Sending of a aggregated MSGin5G message delivery status report

The MSGin5G Client can aggregate multiple MSGin5G message delivery status reports into one single message. The MSGin5G Client shall check whether the MSGin5G message delivery status reports can be aggregated as specified in clause 6.4.1.1.3.

If the MSGin5G message delivery status reports can be aggregated, the MSGin5G Client aggregates MSGin5G message delivery status reports intended for a selected target and sends the aggregated MSGin5G message delivery status reports in a single CoAP POST request message. The sending of the CoAP POST request message shall follow the procedures specified in clause 6.4.1.1.4 with the clarifications listed below:

a) In step d) of clause 6.4.1.1.4, the "Delivery Status" element and the "Failure Cause" element should not be included.

b) In addition to the step d) of clause 6.4.1.1.4, the MSGin5G Client should include a "Number of individual messages" element in this message to indicate the total number of MSGin5G message delivery status reports which are aggregated into this single message.

c) In addition to the step d) of clause 6.4.1.1.4, the MSGin5G Client should include a ""List of individual messages" element in this message. Each child element in this "List of individual messages" element contains information elements listed below:

1) "Message ID" of the individual MSGin5G message delivery status reports which is copied from the MSGin5G message that is being acknowledged;

2) "Delivery Status" element; and

3) an optional "Failure Cause" element.

6.4.1.1.6 Reception of an MSGin5G message

Upon receiving an CoAP POST request containing the MSGin5G Service identifier and the "Message Type" with the value "MSG", if the "Number of individual messages" element and "List of individual messages" element are not included, the MSGin5G Client shall handle the CoAP POST request according to procedures specified in IETF RFC 7252 [5] with the clarifications listed below:

a) The MSGin5G Client shall check whether a "Message is segmented" element is included in the CoAP POST request. If this element is included, the MSGin5G Client shall wait until all the segmented messages have been received by checking the "Segmentation set identifier", "Total number of message segments", "Message segment number" and "Last segment flag" elements. The MSGin5G Client shall reassemble all the segmented messages into a single MSGin5G message.

b) The MSGin5G Client shall provide the received information in the "payload" element to the Application Client(s) if one or more "Application ID" elements are included. The Application Client(s) is(are) indicated by the "Application ID" element(s):

1) If the Application Client is on the other MSGin5G UE-2 for which this MSGin5G Client is acting as MSGin5G Relay UE or MSGin5G Gateway UE, the MSGin5G Client shall send the received information to the corresponding MSGin5G UE via MSGin5G-6 (if MSGin5G Client is supported by MSGin5G UE-2) as specified in clause 6.4.2.4 or MSGin5G-5 reference point (if MSGin5G Client is not supported by MSGin5G UE-2) as specified in clause 6.4.2.2.

2) If the Application Client is on the same MSGin5G UE with the MSGin5G Client, the MSGin5G Client shall deliver the received information to the Application Client via MSGin5G-5 reference point.

NOTE: when the Application Client and MSGin5G Client are resided on the same MSGin5G UE, the interaction in MSGin5G-5 reference point may implementation specific and is out of scope of the present document.

c) If a "Delivery status required" element is included in the CoAP POST request, the MSGin5G Client shall send an MSGin5G message delivery status report as specified in clause 6.4.1.1.4 or clause 6.4.1.1.5 with the clarifications listed below:

1) if the message delivery status is supported by the Application Client(s), the MSGin5G message delivery status report shall be sent after the delivery status information is received from the Application Client(s), and shall be generated based on this(these) delivery status information; or

2) if the message delivery status is not supported by the Application Client, the MSGin5G message delivery status report shall be sent immediately by the MSGin5G Client on behalf of the Application Client(s).

6.4.1.1.7 Reception of a aggregated MSGin5G message

Upon receiving an CoAP POST request containing the MSGin5G Service identifier and the "Message Type" with the value "MSG", if a "Number of individual messages" and a "List of individual messages" are included, the MSGin5G Client determines that this message is an aggregated MSGin5G message. The MSGin5G Client shall handle the CoAP POST request according to procedures specified in IETF RFC 7252 [5] with the clarifications listed below:

a) The MSGin5G Client shall split the received aggregated message request into multiple new created individual MSGin5G messages:

1) all elements listed in step d) of clause 6.4.1.1.2 included in the received MSGin5G message, except the "Message ID", "Message is segmented", "Segmentation set identifier", "Total number of message segments", "Message segment number" and "Last segment flag" elements, are copied to each new created individual MSGin5G message; and

2) each child element of the "List of individual messages" element in the received aggregated MSGin5G message is included in a new created individual MSGin5G message. The "Message ID", "Payload", "Application ID" (if present), "Delivery status required" (if present) and "Priority type" (if present) in the child element of the "List of individual messages" are used as the same elements in the new created individual MSGin5G message; and

b) The MSGin5G Client shall handle each individual MSGin5G messages according to step b) and c) specified in clause 6.4.1.1.6.

6.4.1.1.8 Reception of an MSGin5G message delivery status report

Upon receiving an CoAP POST request containing the MSGin5G Service identifier and the "Message Type" with the value "IMDN", if the "Number of individual messages" element and "List of individual messages" element are not be included and a "Delivery Status" element is included, the MSGin5G Client shall handle the CoAP POST request according to procedures specified in IETF RFC 7252 [5] with the clarifications listed below:

a) The MSGin5G Client shall provide the received information in the "Delivery Status" element and the "Failure Cause" element (if applicable) to the Application Client(s) if one or more "Application ID" elements are included. The Application Client(s) is(are) indicated by the "Application ID" element(s):

1) If the Application Client on the other MSGin5G UE for which this MSGin5G Client is acting as MSGin5G Relay UE or MSGin5G Gateway UE, the MSGin5G Client shall send the received information to the corresponding MSGin5G UE via MSGin5G-6 (if MSGin5G Client is supported by MSGin5G UE-2) as specified in clause 6.4.2.4 or MSGin5G-5 reference point (if MSGin5G Client is not supported by MSGin5G UE-2) as specified in clause 6.4.2.2.

2) If the Application Client is on the same MSGin5G UE with the MSGin5G Client, the MSGin5G Client shall deliver the received information to the Application Client via MSGin5G-5 reference point.

6.4.1.1.9 Reception of a aggregated MSGin5G message delivery status report

Upon receiving an CoAP POST request containing the MSGin5G Service identifier and the "Message Type" with the value "IMDN", if a "Number of individual messages" and a "List of individual messages" are included, the MSGin5G Client determines that this message is an aggregated MSGin5G message. The MSGin5G Client shall handle the CoAP POST request according to procedures specified in IETF RFC 7252 [5] with the clarifications listed below:

a) The MSGin5G Client shall split the received aggregated MSGin5G message request into multiple new created individual MSGin5G messages:

1) all elements listed in step d) of clause 6.4.1.1.4 included in the received MSGin5G message, except the "Message ID", "Delivery Status" and the "Failure Cause" elements, are copied to each new created individual MSGin5G message; and

2) each child element of the "List of individual messages" element in the received aggregated MSGin5G message is included in a new created individual MSGin5G message. The"Message ID", "Delivery Status" and the "Failure Cause" (if present) in the child element of the "List of individual messages" are used as the same elements in the new created individual MSGin5G message; and

b) If "Delivery Status" element is included in the new created individual MSGin5G message, the MSGin5G Client determines that the new created individual MSGin5G messages are MSGin5G delivery status reports. The MSGin5G Client shall handle each individual MSGin5G delivery status report according to step a) specified in clause 6.4.1.1.8.

6.4.1.2 Procedure at MSGin5G Server

6.4.1.2.1 General

An MSGin5G Server provides server-side functionality of messages delivery among MSGin5G UE, Application Server and Message Gateway. A messages delivery procedure in the MSGin5G Server can be divided to reception and sending procedures.

The reception procedure consists:

a) the messages arrival at the MSGin5G Server;

b) the related authentication and authorization of the message on the MSGin5G Server; and

c) the possible message response to the sender.

The sending procedure consists the outbound messages from the MSGin5G Server.

When the MSGin5G Server receives message from MSGin5G UE, the reception procedure is specified in clause 6.4.1.2.2, 6.4.1.2.3, 6.4.1.2.4 and 6.4.1.2.5. When the MSGin5G Server receives message from Application Server or Message Gateway, the reception procedure is specified in 3GPP TS 29.538 [7].

Upon reception of a message, the MSGin5G Server shall analysis the communication model of the message by analysis the Service ID of the recipient in the message, then generates a new message based on the received message and send it to the recipient:

a) if a "Recipient UE Service ID" element is included, this message is a Point-to-Point message or a Application-to-Point message. The MSGin5G Server analyzes the URI:

1) if the URI points to an MSGin5G Client, the MSGin5G Server send the MSGin5G message to the MSGin5G Client via MSGin5G-1 reference point as specified in clause 6.4.1.2.6, 6.4.1.2.7, 6.4.1.2.8 or 6.4.1.2.9; or

2) if the URI points to a Message Gateway, the MSGin5G Server sends the message to the Message Gateway via MSGin5G-2 or MSGin5G-4 reference point as specified in 3GPP TS 29.538 [7];

NOTE: The analysis procedure is implementation specific, e.g. by querying the DNS or local database, and is out of scope of the present document.

b) if a "Recipient AS Service ID" element is included, this message is a Point-to-Application message. The MSGin5G Server analysis the URI and send the message to the Application Server via MSGin5G-3 reference point as specified in 3GPP TS 29.538 [7];

c) if a "Group Service ID" element is included, this message is a Group message. The MSGin5G Server obtains the group members by checking the group profile with the "Group Service ID". For each group member, the MSGin5G Server analyzes its UE Service ID and sends the message to it as specified in step a);

d) if a "Broadcast Area ID" element is included, this message is a Broadcast message; and

NOTE: The detailed procedure for broadcast message will be given in future release.

e) if a "Messaging Topic" element is included, this message is needed to be distributed based on message topic. The MSGin5G Server obtains the subscribers of the Messaging Topic by checking the related subscription. The subscriber of the Messaging Topic can be MSGin5G UE, Application Server or Message Gateway (on behalf of non-MSGin5G UE). For each subscriber, the MSGin5G Server analyzes its Service ID and sends the message to it as specified in step a) or b).

6.4.1.2.2 Reception of an MSGin5G message

Upon receiving an CoAP POST request from the MSGin5G Client on a MSGin5G UE, containing the MSGin5G Service identifier and the "Message Type" with the value "MSG", i.e. the request is for sending a MSGin5G message, if the "Number of individual messages" element and "List of individual messages" element are not be included, the MSGin5G Server shall handle the CoAP POST request according to procedures specified in IETF RFC 7252 [5] with the clarifications listed below:

a) The MSGin5G Server shall authenticate the message and shall verify that the sending UE is authorized to send the message by checking the registration status of the MSGin5G Client and the "Originating UE Service ID" element in the CoAP payload. If message is needed to be rejected, the MSGin5G Server shall send a message response in a new CoAP POST request to the originating entity as specified in step e) and skips the rest steps in this clause;

b) The MSGin5G Server executes the message segment related procedures as specified in clause 6.5.3 if needed;

c) The MSGin5G Server shall determine the communication model of the message as specified in clause 6.4.1.2.1;

d) If the message is stored for deferred delivery as specified in clause 6.4.1.2.6 or 6.4.1.2.7, the MSGin5G Server shall send a message response in a new CoAP POST request to the originating entity as specified in step e); and

e) The MSGin5G Server shall send a message response in a new CoAP POST request to the originating entity as specified in IETF RFC 7252 [5] with the clarifications listed below:

1) may set the "T" field in the CoAP header to 0 or 1;

2) shall include the originating MSGin5G Client’s address in an CoAP Option, e.g. if the originating MSGin5G Client address is a URI, includes a Uri-Path Option with the value of the URI;

3) shall set the CoAP Content-Format to "50", i.e. application/json; and

4) shall include the information elements specified in 3GPP TS 23.554 [2] in the CoAP payload encoded in JSON format as specified in clause 7.3.4.3:

i) shall include an "MSGin5G service identifier" element to indicate that this CoAP POST request is used for MSGin5G service;

ii) shall include an "Originating UE Service ID" element set to the UE which sends the previous MSGin5G message;

iii) shall include the "Message ID" copied from the received MSGin5G message which this Message response is responded to;

iv) may include a "Delivery Status" element to indicate that the delivery status of this MSGin5G message is a failure, or is stored for deferred delivery;

v) may include a "Failure Cause" element to indicate the reason for failure; and

vi) in addition to the information elements specified in 3GPP TS 23.554 [2], shall also include a "Message Type" element set to "MSGRESP" to indicate that this message is a message response.

6.4.1.2.3 Reception of an aggregated MSGin5G message

Upon receiving an CoAP POST request containing the MSGin5G Service identifier and the "Message Type" with the value "MSG", if a "Number of individual messages" and a "List of individual messages" are included, the MSGin5G Server determines that this message is an aggregated MSGin5G message. The MSGin5G Server shall handle the whole aggregated MSGin5G message according to procedures specified in clause 6.4.1.2.2.

6.4.1.2.4 Reception of an MSGin5G delivery status report

Upon receiving an CoAP POST request containing the MSGin5G Service identifier and the "Message Type" with the value "IMDN", if the "Number of individual messages" element and "List of individual messages" element are not be included and a "Delivery Status" element is included, the MSGin5G Server shall handle the CoAP POST request according to procedures specified in IETF RFC 7252 [5] with no additional requirement.

6.4.1.2.5 Reception of an aggregated MSGin5G delivery status report

Upon receiving an CoAP POST request containing the MSGin5G Service identifier and the "Message Type" with the value "IMDN", if a "Number of individual messages" and a "List of individual messages" are included, the MSGin5G Server determines that this message is an aggregated MSGin5G message. The MSGin5G Server shall handle the whole aggregated MSGin5G delivery status report according to procedures specified in clause 6.4.1.2.4.

6.4.1.2.6 Sending of an MSGin5G message

In order to deliver the MSGin5G message to an MSGin5G UE, the MSGin5G Server shall send the MSGin5G message in an new CoAP message according to procedures specified in IETF RFC 7252 [5] via MSGin5G-1 reference point. The sending of the CoAP message shall follow the procedures below:

a) the MSGin5G Server shall set the "T" field in the CoAP header to 0 if delivery status report from the recipient is requested, i.e. indicate that this message is the type of Confirmable, to ensure the application layer delivery status report;

b) the MSGin5G Server shall set the CoAP Content-Format to "50", i.e. application/json;

c) The MSGin5G Server shall remove any "Priority type" element, "Store and forward flag" and related "Store and forward parameters" elements from the CoAP payload of the received message. If "Message is segmented" and related elements is included in the received message, the MSGin5G Server shall handle the message as specified in clause 6.5.3;

d) the MSGin5G Server shall determine the communication model of the message by checking the recipient of the message as specified in clause 6.4.1.2.1 and generate the new CoAP message:

1) if the Service ID of the recipient points to an MSGin5G Client, the MSGin5G Server:

i) shall include the recipient MSGin5G Client address in an CoAP Option, e.g. if the MSGin5G Client address is a URI, include a Uri-Path Option with the value of the URI; and

ii) shall copy other elements in the CoAP payload of the received message to the new CoAP POST request;

2) if the Service ID of the recipient points to an Application Server or a Message Gateway, the MSGin5G Server shall follow the procedure specified in 3GPP TS 29.538 [7];

3) if the MSGin5G message is a Group message, the MSGin5G Server:

i) shall obtain the group members by checking the group profile with the "Group Service ID" element included in the received MSGin5G message; and

ii) for each group member which is an MSGin5G UE, include its CoAP address got from the recipient MSGin5G UE registration specified in clause 6.3.1.2 in an CoAP Option, e.g. if the recipient client’s address is a URI, includes a Uri-Path Option with the value of the URI. The MSGin5G Server shall add the "Recipient UE Service ID" element and set the value of it to the UE Service ID. The MSGin5G Server shall also copy other elements in the CoAP payload of the received message to the new CoAP POST request; and

4) if the MSGin5G message is needed to be distributed based on message topic, the MSGin5G Server:

i) shall obtain the UE Service ID/AS Service ID of the subscribers by checking the subscription with this Messaging Topic; and

ii) for each subscriber which is an MSGin5G UE, include its CoAP address got from the recipient MSGin5G UE registration specified in clause 6.3.1.2 in an CoAP Option, e.g. if the recipient client’s address is a URI, includes a Uri-Path Option with the value of the URI. The MSGin5G Server shall add the "Recipient UE Service ID" element and set the value of it to the UE Service ID. The MSGin5G Server shall also copy other elements in the payload of the received message to the new CoAP 2.05 response.

e) before sending the new CoAP message generated in step d), the MSGin5G Server shall compare the size of the new CoAP message to the maximum allowed MSGin5G message segmentation size. If the size exceeds, the MSGin5G Server shall segment the MSGin5G message into a set of segmented MSGin5G messages such that each segmented MSGin5G message can fit within the maximum allowed MSGin5G message segmentation size. For each segmented MSGin5G message, the MSGin5G Server:

1) shall include a "Message is segmented" element with a "true" value to indicate that this message is part of a segmented message;

2) shall include a "Segmentation set identifier" element to indicate that this segmented message is associated within a set of segmented messages. The same unique identifier is assigned to all segmented messages associated with the same MSGin5G message;

3) shall include a "Total number of message segments" element in the first segment of the MSGin5G message to indicate the total number of segments for the MSGin5G message;

4) shall include a "Message segment number" element to indicate segmented message number of each segmented message within the set of segmented messages; and

5) shall include a "Last segment flag" element in the last segment in the set of segmented messages; and

f) the MSGin5G Server checks the availability of recipient by checking the UE registration status. The MSGin5G Server can also use UE reachability status monitoring specified in 3GPP TS 29.538 [7] to determine whether the recipient is available. If the recipient is available, the MSGin5G Server send the new CoAP message generated as above to the recipient. If the recipient is unavailable, the MSGin5G Server checks whether a "Store and forward flag" element is included in the received MSGin5G message:

1) if the "Store and forward flag" element is not included, the MSGin5G Server discards the message and may send a message response as specified in clause 6.4.1.2.2 which includes delivery status information in the "Delivery Status" element, e.g., that the message was discarded; and

2) if the "Store and forward flag" element is included:

i) the MSGin5G Server stores the message and uses the information obtained from the "Store and forward parameters" element to determine the forwarding. The MSGin5G Server may send a message response as specified in clause 6.4.1.2.2 which includes store and forward status information in the "Delivery Status" element, e.g., the delivery had been deferred; and

ii) when the recipient UE becomes available, the MSGin5G Server attempts delivery of the new CoAP message to the recipient. If the UE does not become available prior to the time included in the "Message expiration time" element, the MSGin5G Server attempts delivery of the new CoAP message at the message expiration time and the stored message is discarded afterwards. The MSGin5G Server may send a message response as specified in clause 6.4.1.2.2 which includes store and forward status information the "Delivery Status" element, e.g., that the message was discarded.

6.4.1.2.7 Sending of an aggregated MSGin5G message

If the MSGin5G Server receives an aggregated MSGin5G message as specified in clause 6.4.1.2.3, and the received aggregated MSGin5G message is smaller than the supported message segment size of the recipient, it shall send it as specified in clause 6.4.1.2.6 without splitting the received aggregated message request into multiple individual MSGin5G message.

If the received aggregated MSGin5G message is larger than the supported message segment size of the recipient, the MSGin5G Server should remove the last individual message in the List of individual messages element from the aggregated message until the aggregated message is smaller than the maximum segmentation size that can be transmitted over available transport, and then send the remaining aggregated MSGin5G message as specified in clause 6.4.1.2.6. The MSGin5G messages removed from the aggregated message may be sent individually or aggregated again by the MSGin5G Server according to service configuration.

NOTE: Aggregated MSGin5G message is supported by all MSGin5G Clients and Application Servers. MSGin5G message and MSGin5G delivery status report cannot be aggregated in the same aggregated MSGin5G message.

If the MSGin5G Server receives an MSGin5G message as specified in clause 6.4.1.2.2, it may send multiple MSGin5G messages toward the same recipient in an aggregated MSGin5G message. Before the sending of an MSGin5G message, the MSGin5G Server shall check if aggregation is allowed for this message, MSGin5G Server shall also check the message data size, and the priority level to determine if the message can be aggregated. For example, if the MSGin5G Server finds that the received messages have small payload size when compared to the maximum segment size that can be transmitted over CoAP and the messages are not high priority messages, which could be sent as per scheduling policy towards a selected target. The MSGin5G Server can decide to aggregate messages until optimal use of segment size before sending message towards MSGin5G Client.

If the message can be aggregated, the MSGin5G Server aggregates multiple MSGin5G messages, and sends the aggregated message in a single CoAP POST request message. The sending of the CoAP POST request message shall follow the procedures specified in clause 6.4.1.2.6 with the clarifications listed below:

a) The MSGin5G Server should not segment the aggregated message, so the MSGin5G Server should ensure that the new aggregated MSGin5G message is smaller than the maximum allowed MSGin5G message segmentation size and skips the step e) in clause 6.4.1.2.6. The "Message is segmented", "Segmentation set identifier", "Total number of message segments", "Message segment number" and "Last segment flag" elements should not be included in the aggregated MSGin5G message.

b) In addition to the elements specified in clause 6.4.1.2.6, the MSGin5G Server should include a "Number of individual messages" element in this message to indicate the total number of messages which are aggregated into this single message.

c) In addition to the elements specified in clause 6.4.1.2.6, the MSGin5G Server should include a "List of individual messages" element in this message. Each child element of this "List of individual messages" element contains information elements listed below:

1) "Message ID" of the individual message;

2) "Payload" which carries the application payload that is transferred by the individual MSGin5G message;

3) one or more optional "Application ID" element(s);

4) an optional "Delivery status required" element; and

5) an optional "Priority type" element.

6.4.1.2.8 Sending of an MSGin5G delivery status report

Upon receiving an MSGin5G delivery status report as specified in clause 6.4.1.2.4, the MSGin5G Server may generate a new CoAP POST request contains the MSGin5G delivery status report if the MSGin5G Server decides not to aggregate the delivery status report. The new CoAP POST request is sent to the recipient obtained from the "Recipient UE Service ID" element in the payload of the received CoAP POST request. The MSGin5G Server:

a) shall set the "T" field in the CoAP header to 0;

b) shall include the recipient address in the Option header of the CoAP message and set the Option header to a corresponding value, e.g. if the MSGin5G Client address is a URI, includes a Uri-Path Option with the value of the URI; and

c) shall copy other elements in the payload of the received message to the new CoAP POST request.

6.4.1.2.9 Sending of a aggregated MSGin5G delivery status report

If the MSGin5G Server receives an aggregated MSGin5G delivery status report as specified in clause 6.4.1.2.5, it shall generate a new CoAP POST request contains the aggregated MSGin5G delivery status report and sends it to the recipient obtained from the "Recipient UE Service ID" element in the payload of the received CoAP POST request. The MSGin5G Server:

a) shall set the "T" field in the CoAP header to 0;

c) shall copy other elements in the payload of the received message to the new CoAP POST request.

If the MSGin5G Server receives MSGin5G delivery status report as specified in clause 6.4.1.2.4, it may aggregate multiple MSGin5G message delivery status reports into one single message. The MSGin5G Server shall check whether the MSGin5G message delivery status reports can be aggregated as specified in clause 6.4.1.2.7.

If the MSGin5G message delivery status reports can be aggregated, the MSGin5G Server aggregates MSGin5G message delivery status reports intended for a selected target and sends the aggregated MSGin5G message delivery status reports in a single CoAP POST request message. The sending of the CoAP POST request message shall follow the procedures specified in clause 6.4.1.2.6 with the clarifications listed below:

a) In step d) of clause 6.4.1.2.6, the "Delivery Status" element and the "Failure Cause" element in payload of every individual MSGin5G message should not be copied to the payload of the new CoAP POST request message.

b) In addition to the step d) of clause 6.4.1.2.6, the MSGin5G Server should include a "Number of individual messages" element in this message to indicate the total number of MSGin5G message delivery status reports which are aggregated into this single message.

c) In addition to the step d) of clause 6.4.1.2.6, the MSGin5G Server should include a "List of individual messages" element in this message. Each child element of this "List of individual messages" element contains information elements listed below:

1) "Message ID" of the individual MSGin5G message delivery status reports which is copied from the MSGin5G message that is being acknowledged;

2) "Delivery Status" element copied from the individual MSGin5G message delivery status report; and

3) an optional "Failure Cause" element copied from the individual MSGin5G message delivery status report.

6.4.2 Message delivery and message delivery status report delivery for Constrained UE

6.4.2.1 General

Clause 6.4.2.2 and 6.4.2.3 define the procedures used for message or message delivery report sending/receiving over MSGin5G-5.

In the procedures, for delivering messages or message delivery reports to MSGin5G Client in MSGin5G Gateway UE, the Application Client in Constrained UE may use any message format or protocol supported by the MSGin5G Client.

NOTE 1: How the Application Client knows the message protocol/format supported by the MSGin5G Client is out of scope of this specification.

In the procedures, for delivering messages or message delivery reports to Application Client in Constrained UE, the MSGin5G Client in MSGin5G Gateway UE may use any message format or protocol supported by the Application Client.

NOTE 2: How the MSGin5G Client knows the message protocol/format supported by the Application Client is out of scope of this specification.

Annex A lists some message formats/protocols examples (only for implementation reference) which may be used for the interaction between Application Client in Constrained UE and MSGin5G Client in MSGin5G Gateway UE over MSGin5G-5.

Clauses 6.4.2.4 and 6.4.2.5 define the procedures used for MSGin5G message or MSGin5G message delivery report sending/receiving over MSGin5G-6. The MSGin5G Relay UE relays the CoAP POST request/response as traffic between the MSGin5G Server and the Constrained UE.

6.4.2.2 Procedure at MSGin5G Gateway UE

6.4.2.2.1 Sending of an message to Constrained UE

Upon successfully receiving a MSGin5G message including an Application ID from MSGin5G Server, if the Application ID is registered by an Application Client in Constrained UE, based on Constrained UE registration information, the MSGin5G Client on the MSGin5G Gateway UE shall send a request/message to the Application Client, including the following information elements:

a) the Message Type IE with the value “MESSAGE RECEIVED REQUEST” indicating the request/message is for delivering a message;

b) the Message ID IE with the unique identity of this message;

c) if the received message is a point-to-point or application-to-point message, the Originator Address IE indicating the originating UE or AS;

d) if the received message is a group message, the Group ID IE indicating the originating group;

NOTE: the information included in the Originator Address IE is generated based on the received originating UE/AS Service ID, the information included in the Group ID IE is generated based on received Group Service ID. How to generate the value of Originator Address IE and Group ID IE is implementation specific.

e) the Payload IE indicating the application message content included in the received message;

f) if the delivery status report is required by the originator, the Delivery Status Required IE with “true”; and

g) optionally, the Priority IE indicating the application priority level.

6.4.2.2.2 Reception of an message from Constrained UE

Upon receiving a request from Application Client in Constrained UE, and the request is for initiating a MSGin5G message, i.e. with Message Type IE set to “MESSAGE SENDING REQUEST”, the MSGin5G Client in the MSGin5G Gateway UE shall construct and send a CoAP POST request to MSGin5G Server as specified in clause 6.4.1.1.2. The MSGin5G Client generates the Recipient UE Service ID/AS Service ID based on Target address IE the included in the request from the Constrained UE.

If the Constrained UE indicates “UE” in the Target Type IE, the Target Address shall include information of another MSGin5G Client, i.e. it shall not indicate a Constrained UE without MSGin5G Client.

If an IPv4 or IPv6 address is included in the Target Address, the MSGin5G Client generates the Recipient UE Service ID/AS Service ID based on the mapping between the addresses and UE Service IDs/AS Service IDs stored in the MSGin5G UE.

If the Constrained UE indicates “UE” in the Target Type IE, in order to route the MSGin5G message to the correct target MSGin5G Client, the Target Address may indicate an FQDN.

When the MSGin5G Client cannot generate the Recipient UE Service ID/AS Service ID based on Target address IE, the MSGin5G Client generates the request message to the Application Client in Constrained UE as specified in clause 6.4.2.2.3 if the Delivery status required IE indicates “DELIVERY REPORT REQUIRED “. Otherwise, the MSGin5G Client discards the request from the Constrained UE.

6.4.2.2.3 Sending of a message delivery status report to Constrained UE

Upon receiving a MSGin5G message delivery status report request including an Application ID from MSGin5G Server, and the Application ID is registered by the Application Client on Constrained UE, based on the Constrained UE registration information, the MSGin5G Client on the MSGin5G Gateway UE shall send a request/response message to the Application Client, in the request, including the following information elements:

a) the Message Type IE with the value "DELIVERY REPORT RECEIVED REQUEST" indicating the request/message is for delivering a message delivery status;

b) the Message ID IE with the unique identity of this message delivery report;

c) the Reply-to Message ID IE indicating the delivery status is for which message; and

d) the Delivery Status IE indicating the delivery status.

6.4.2.2.4 Reception of an message delivery status report from Constrained UE

Upon receiving a request/response from Application Client in Constrained UE, and the request is for delivering a message delivery report, i.e. with Message Type IE set to "DELIVERY REPORT SENDING REQUEST", the MSGin5G Client in the MSGin5G Gateway UE shall construct and send a CoAP POST request to MSGin5G Server as specified in clause 6.4.1.1.4.

6.4.2.2.5 Sending of an message sending response to Constrained UE

Upon received the message request from Application Client in Constrain UE, the MSGin5G Client in the MSGin5G Gateway UE sends a response to the Application Client including the following information elements:

a) the Message Type IE with the value "MESSAGE SENDING RESPONSE" indicating this is a response to the message sending request.

b) the Result IE indicating success or failure of the message sending request; and

c) optionally, the Failure Reason IE indicating the reason of failure when the Result IE is set to failure.

6.4.2.3 Procedure at Constrained UE

6.4.2.3.1 Sending of an message via MSGin5G Gateway UE

In order to initiate an MSGin5G message by using the MSGin5G Client in MSGin5G Gateway UE, the Application Client in Constrained UE shall send a request/message to the MSGin5G Client including the following information elements:

a) the Message Type IE with the value "MESSAGE SENDING REQUEST" indicating the request/message is for initiating a MSGin5G message;

b) the Message ID IE with the unique identity of this message;

c) the Target Address IE with the information for MSGin5G Client to generate the Recipient UE/AS/Group Service ID in the MSGin5G message request;

d) optionally, the Target Type IE indicating the type of the message recipient, with "UE" if the message is sent to a UE, with "AS" if the message is sent to an Application Server, or with "GROUP" if message is sent to a MSGin5G Group;

e) optionally, the Application ID IE indicating the application(s) for which the payload is intended;

f) the Payload IE including the application content of the message to send to the recipient; and

g) optionally, the Delivery Status Required IE with the value "true" if delivery status report is required.

6.4.2.3.2 Sending of an MSGin5G message delivery status report via MSGin5G Gateway UE

In order to sending an message delivery report by using the MSGin5G Client in MSGin5G Gateway UE, the Application Client in Constrained UE shall send a request/response to the MSGin5G Client including the following information elements:

a) the Message Type IE with the value "DELIVERY REPORT SENDING REQUEST" indicating the request/response is for sending a delivery status report;

b) the Message ID IE with the unique identity of this message delivery report;

c) the Reply-to Message ID IE copied from the received message, to indicate the delivery status is for which message; and

d) the Delivery Status IE with delivery status.

6.4.2.3.3 Sending of a message received response to MSGin5G Gateway UE

Upon received the message request from MSGin5G Client in MSGin5G Gateway UE, the Application Client in the Constrained UE sends a response to the MSGin5G Client, including the following information elements:

a) the Message Type IE with the value "MESSAGE RECEIVED RESPONSE" indicating the request/message is for initiating a MSGin5G message.

b) the Result IE indicating success or failure of the message received request; and

c) optionally, the Failure Reason IE indicating the reason of failure when the Result IE is set to failure.

6.4.2.4 Procedure at MSGin5G Relay UE

6.4.2.4.1 Sending of an MSGin5G message to Constrained UE with MSGin5G Client

When the MSGin5G Client-1 on the MSGin5G Relay UE receives a CoAP POST request from UDP port XXX and the recipient’s address included in the CoAP Option is set to another MSGin5G Client-2 which has established a connection for One-to-one ProSe Direct Communication with it as specified in 3GPP TS 23.304[9], the MSGin5G Relay UE acts as either 5G ProSe Layer-2 and Layer-3 UE-to-Network Relay entity as specified in 3GPP TS 23.304 [9] and relays the CoAP POST request as a downlink traffic to the MSGin5G Client-2, Otherwise the MSGin5G Client-1 shall discard the CoAP POST request and may send a CoAP 4.04 (Not Found) response to the MSGin5G Server.

Editor’s note: The exact UDP port number on which the message is sent, is FFS.

6.4.2.4.2 Reception of an MSGin5G message from Constrained UE with MSGin5G Client

When the MSGin5G Client on the MSGin5G Relay UE receives a CoAP POST request from UDP port XXX and the recipient’s address included in the CoAP Option is set to the MSGin5G Server, the MSGin5G Relay UE acts as either 5G ProSe Layer-2 and Layer-3 UE-to-Network Relay entity as specified in 3GPP TS 23.304 [9] and relays the CoAP POST request as a uplink traffic to the MSGin5G Server.

Editor’s note: The exact UDP port number on which the message is sent, is FFS.

6.4.2.5 Procedure at MSGin5G Client in Constrained UE

6.4.2.5.1 Sending of an MSGin5G message

In order to send an MSGin5G message or MSGin5G message delivery status report, the MSGin5G Client shall use the procedures specified in clause 6.4.1.1.2, 6.4.1.1.3, 6.4.1.1.4 and 6.4.1.1.5.

6.4.2.5.2 Reception of an MSGin5G message

Upon receiving an CoAP POST request and the recipient’s address included in the CoAP Option is set to the MSGin5G Client itself, the MSGin5G Client shall handle the CoAP Post request as specified in clause 6.4.1.1.6, 6.4.1.1.7, 6.4.1.1.8 and 6.4.1.1.9.

6.5 MSGin5G Message Segmentation and Reassembly

6.5.1 Segment recovery and received confirmation procedures

The Message Sender in this clause can only be the MSGin5G Client (when the message is from MSGin5G Client) or MSGin5G Server (when the message is from Application Server).

The Message Receiver in this clause can only be the MSGin5G Client (when the message is targeted to an MSGin5G Client) or MSGin5G Server (when the message is targeted to an Application Server).

6.5.1.1 Procedure at Message Sender

Upon receiving a CoAP POST request containing the MSGin5G service identifier and containing the Message Type with a value "SEGREC" which indicates the request is for messgage segment recovery, the MSGin5G Client shall send a CoAP ACK response to the request. Then the MSGin5G Client shall send all requested segmented messages as requested in the received "List of Segment range" element to the message receiver (e.g. Application Server, UE) as specified in 6.4.1.1.2.

6.5.1.2 Procedure at Message Receiver

6.5.1.2.1 Segments recovery procedure when failed to receive all segments

If not all segments are received within expected time, the Message Receiver shall send a CoAP POST request to the Message Sender for recovering the segments which are not received. In the CoAP POST request, the Message Receiver:

a) shall set the "T" field in the CoAP header to 0 to indicate this request is the type of Confirmable;

b) shall include the Message Sender address in a CoAP Option, e.g. if the Message Sender address is a URI, includes a Uri-Path Option with the value of the URI;

c) shall set the CoAP Content-Format to "50", i.e. application/json; and

d) shall include the following information elements in the CoAP payload encoded in JSON format:

1) an "MSGin5G service identifier" element to indicate that this CoAP POST request is used for MSGin5G service;

2) a "Message Type" element with a value "SEGREC" to indicate that this request is for segments recovery;

3) a "Segmentation Set Identifier" element copied from one of the previous received segments; and

4) a "List of Segment range" element to indicate the segments range which the client wants to recover, each segment range consist of start and end sequence number of missing segments e.g. (5-7, 10-10, 15-19).

If not all segments are received within the expected time (based on configuration), the Message Receiver may consider that the recovery is failed. The Message Receiver may initiate the procedure again with updated list of segment range.

NOTE: The MSGin5G message segment recovery procedure may repeat based on the configuration.

The corresponding JSON Schema used in step d) is defined in clause 7.3.6.2.

6.5.1.2.2 Segments received confirmation procedure

If the Message Receiver determines that it receives all segments successfully, or the Message Receiver determines that it is failed (including recovery failed) to receive all segments, the Message Receiver sends the message segments received confirmation to the Message Sender by a CoAP POST request. In the CoAP POST request, the Message Receiver:

a) shall set the "T" field in the CoAP header to 0 to indicate this request is the type of Confirmable;

b) shall include the Message Sender address in a CoAP Option, e.g. if the Message Sender address is a URI, includes a Uri-Path Option with the value of the URI;

c) shall set the CoAP Content-Format to "50", i.e. application/json; and

d) shall include the following information elements in the CoAP payload encoded in JSON format:

1) the "MSGin5G service identifier" element to indicate that this CoAP POST request is used for MSGin5G service;

2) the "Message Type" element with a value "SEGCONFIR" to indicate that this request is for sending message segments received confirmation;

3) the "Segmentation Set Identifier" element copied from one of the previous received segments; and

4) the "Result" element to indicate whether the segments are received successful or failed.

The corresponding JSON Schema used in step d) is defined in 7.3.6.1.

6.5.2 Procedure at MSGin5G Client

6.5.2.1 Procedure at MSGin5G Client in Sending UE

To support MSGin5G Message segmentation and reassembly, the Message Client performs the procedures specified in 6.4.1.1.2, and acts as Message Sender to perform the procedures in clause 6.5.1.1 if needed. When the MSGin5G Client performs the procedures in clause 6.5.1.1, the MSGin5G Server acts as Message Receiver.

6.5.2.2 Procedure at MSGin5G Client in Recipient UE

Upon receiving an MSGin5G message, to support MSGin5G Message segmentation and reassembly, the MSGin5G Client performs the procedures in 6.4.1.1.6, and acts as Message Receiver to perform the procedures in clause 6.5.1.2 if needed. When the MSGin5G Client performs the procedures in clause 6.5.1.2, the MSGin5G Server acts as Message Sender.

6.5.3 Procedure at MSGin5G Server

6.5.3.1 General

When the MSGin5G Server receives a message which is not segment message, the MSGin5G Server should follow the procedures in clause 6.4.1.2.6 to perform potential segment if needed (i.e. if the received message size exeeds the maxmium allowed MSGin5G message segmentation size of the target UE).

This following clauses specify the procedures when the MSGin5G Server receives segemented message delivery request, messgage segments recovery request or messgage segments received confirmation request.

6.5.3.2 Procedures on receiving message segments targeting to a MSGin5G UE

Upon receiving a message segment targeting to MSGin5G UE, the MSGin5G Server checks if the segment size exceeds the configured maximum message segment size of the targeted UE,

a) if exceed, upon receiving all segments,

1) reassembles them into a single MSGin5G message;

2) splits the re-assembled message to segments such that each segment is smaller than the maximum allowed message segment size of the targeted UE; and

3) sends each new segment to the target MSGin5G UE as specified in clause 6.4.1.2.6; and

b) if not exceed, upon receiving all segments, sends each segment to the target MSGin5G UE as specified in clause 6.4.1.2.6.

6.5.3.3 Procedures on receiving message segments targeting to an Application Server

Upon receiving all message segments from MSGin5G UE to an Application Server, the MSGin5G Server shall reassemble them into a single MSGin5G message and sends it to the Application Server as specified in TS 29.538 [7].

Upon receiving message segments from MSGin5G UE to an Application Server, the MSGin5G Server acts as a Message Receiver to perform the procedures specified in clause 6.5.1.2.1 and in clause 6.5.1.2.2 if needed. In these procedures, the MSGin5G Client in the MSGin5G UE acts as Message Sender.

6.5.3.4 Procedures on receiving message segments recovery request to a MSGin5G UE

Upon receiving a CoAP POST request containing the MSGin5G service identifier and containing the Message Type with a value "SEGREC" indicating the request is for messgage segment recovery, if the request is targeted to an MSGin5G UE, the MSGin5G Server shall construst a new CoAP POST request to the targeted UE. In the request, the MSGin5G Server:

a) shall construct the new CoAP POST request with the corresponding value in the recevied CoAP POST request message except the Option header; and

b) shall include the MSGin5G Client address in the Option header of the CoAP message and set the Option header to a corresponding value, e.g. if the MSGin5G Server address is a URI, the Uri-Path Option is set to the value of such URI.

6.5.3.5 Procedures on receiving message segments received confirmation to a MSGin5G UE

Upon receiving a CoAP POST request containing the MSGin5G service identifier and containing the Message Type with a value "SEGCOFIR" indicating the request is for message segments received confirmation, if the request is targeted to an MSGin5G UE, the MSGin5G Server shall construst a new CoAP POST request to the targeted UE. In the request, the MSGin5G Server:

a) shall construct the new CoAP POST request with the corresponding value in the received CoAP POST request message except the Option header; and

6.6 Messaging Topic Subscription and Unsubscription

6.6.1 General

As specified in 3GPP TS 23.554 [2], an MSGin5G Client may subscribe one or more Messaging Topics on the MSGin5G Server.

The message topic subscription and unsubscription are based on the CoAP Observe method as specified in IETF RFC 7641 [4], the MSGin5G Client acts as an observer, the MSGin5G Server acts as a CoAP Server, the message topic is a resource to observe.

6.6.2 Procedure at MSGin5G Client

6.6.2.1 Messaging Topic Subscription

Upon receiving a request to subscribe a messsage topic from an Application Client, MSGin5G Client shall send a CoAP GET request, as specified in IETF RFC 7641 [4], to the MSGin5G Server. In the CoAP GET request, the MSGin5G Client:

a) shall set the "T" field in the CoAP header to the value "0" to indicate this request is the type of Confirmable;

b) shall include the MSGin5G Server address in the Option header and set the Option header to a corresponding value, e.g. if the MSGin5G Server address is a URI, the Uri-Path Option is set to the value of such URI;

c) shall include the message topic name in the Uri-Path Option (e.g. "\top");

d) shall include the Observe Option with the value "0" which indicates the request is for observing a resource, i.e. for subscribing a message topic;

e) shall include the Content-Format Option with the value "50" which indicate the format of the CoAP payload is "application/json" as specified in RFC 7252 [5]; and

f) shall include the CoAP Payload in JSON format, including the following information elements as specified in clause 8.8.1 of 3GPP TS 23.554 [2]:

1) an "Originating UE Service ID" element set to the MSGin5G UE which requests the message topic subscription; and

2) optionally, an "Expiration time" element which indicates the expiration time of the message topic subscription.

The corresponding JSON Schema used in step g) is defined in clause 7.3.5.1.

6.6.2.2 Messaging Topic Unsubscription

If the MSGin5G Client needs to unsubscribe a messsage topic, as specified in RFC 7641 [4], the MSGin5G Client shall send a CoAP GET request to MSGin5G Server. In the request, the MSGin5G Client:

a) shall set the "T" field in the CoAP header to the value "0" to indicate this request is the type of Confirmable;

c) shall include the message topic name in the Uri-Path Option (e.g. "\top");

d) shall include the Observe Option with the value "1" which indicates the observer request to cancel the previous resource observation, i.e. the MSGin5G Client requests to unsubscribe the message topic;

e) shall include the Content-Format Option with the value "50" which indicate the format of the CoAP payload is "application/json" as specified in RFC 7252 [5]; and

e) shall include the CoAP Payload in JSON format and an "Originating UE Service ID" element indicating the MSGin5G UE which requests the message topic unsubscription shall be included in the CoAP Payload.

The corresponding JSON Schema used in step g) is defined in 7.3.5.2.

6.6.3 Procedures at MSGin5G Server

The MSGin5G Server should support parsing CoAP request as specified in RFC 7252 [5] and RFC 7641 [4].

Upon receiving a CoAP GET request from MSGin5G Client, the MSGin5G Server shall parse the CoAP headers, Options and Payload in the request to get:

a) the value of Observe Option;

b) the message topic from the Uri-Path Option;

c) the Originating UE Service ID from the Payload; and

d) the Expiration time from the Payload if exists in the Payload.

6.6.3.1 Messaging Topic Subscription

If the Observe Option is included in the CoAP GET request with a value "0" as specified in RFC 7641 [4], the MSGin5G Server shall:

a) if the message topic does not exist, create the message topic;

b) if the Originating UE Service ID is not in the list of the subscribers of the message topic, add the Originating UE Service ID to the list of the subscribers of the topic, and record its expiration time if exists;

c) if an entry with a matching Originating UE Service ID is already present in the list of the subscribers of the message topic, updates the expiration time of the subscription of this UE; and

d) send a CoAP Notifications with a 2.05 (Content) response code to the MSGin5G Client and with CoAP Payload in JSON format, including the following information elements as specified in clause 8.8.1 of 3GPP TS 23.554 [2]:

1) a "subscription status" element set to indicate whether the subscription was successfully added or deleted on the MSGin5G Server; and

2) optionally, an "Expiration time" element set to indicate the expiration time of the message topic subscription.

The MSGin5G Server shall remove the Originating UE Service ID from list of the subscribers of the message topic when the expiration time reached.

6.6.3.2 Messaging Topic Unsubscription

If the Observe Option is included in the received CoAP GET request with a value "1" as specified in RFC 7461 [4], the MSGin5G Server shall handle the CoAP GET request according to procedures specified in IETF RFC 7252 [5] with the clarifications listed below:

a) if the message topic exists, the MSGin5G Server shall remove the Originating UE Service ID from list of the subscribers of the message topic; and

b) the MSGin5G Server sends a CoAP Notifications with a 2.05 (Content) response code to the MSGin5G Client, and with CoAP Payload in JSON format. A "subscription status" element set to indicate whether the subscription was successfully added or deleted on the MSGin5G Server shall be included in this CoAP Payload as specified in clause 8.8.3 of 3GPP TS 23.554 [2].

6.7 Void

6.8 Usage of SEAL

6.8.1 General

The MSGin5G Service functional entities MSGin5G Client and MSGin5G Server utilize the SEAL services. All SEAL services specified in 3GPP TS 24.544 [10], 3GPP TS 24.545 [11], 3GPP TS 24.546 [12], 3GPP TS 24.547 [13] and 3GPP TS 24.548 [14] are available to MSGin5G Service. In this clause, the procedures whose utilization by MSGin5G Service are well-known are described.

NOTE: If SEAL client is co-located with MSGin5G client, then MSGin5G client act as a SEAL client to perform procedures. If SEAL client is not co-located with MSGin5G client, then the interaction between MSGin5G client and SEAL client is implementation specific.

6.8.2 Configuration management service

6.8.2.1 General

The MSGin5G Client and MSGin5G Server utilize configuration management service procedures of SEAL to support MSGin5G Service. The procedure to fetch VAL UE configuration data specified in clause 6.2.3 of 3GPP TS 24.546 [12] is applicable for the configuration management services of the MSGin5G Service. The MSGin5G UE configuration data is specified in clause 7.2.

6.8.3 Group management service

6.8.3.1 General

The MSGin5G Client and MSGin5G Server utilize group management service procedures of SEAL to support MSGin5G Service. The following procedures of group management service of SEAL as specified in 3GPP TS 24.544 [10] are applicable for the MSGin5G Service:

a) Group creation specified in clause 6.2.2; with following clarification:

1) Upon receiving Group Creation notification as specified in clause of 3GPP TS 24.544 [10], for list of VAL user IDs or VAL UE IDs which does not have group management client on the UE (e.g. Legacy 3GPP UEs or Non-3GPP UEs), the MSGin5G server initiate the group creation notification towards those UEs;

b) Group configuration management specified in clause 6.2.5; and

c) Group membership update specified in clause 6.2.4.