7.4.2 Short data service for on-network

23.2823GPPFunctional architecture and information flows to support Mission Critical Data (MCData)Release 18Stage 2TS

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

The procedures described in the following subclauses are limited to single MCData system only.

7.4.2.1 Information flows for short data service

7.4.2.1.1 MCData standalone data request

Table 7.4.2.1.1-1 describes the information flow for the MCData standalone data request sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.4.2.1.1-1: MCData standalone data request (MCData client to MCData server)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data
Functional alias	O	The associated functional alias of the MCData user sending data.
MCData ID (see NOTE 1)	O	The identity of the MCData user towards which the data is sent
Functional alias (see NOTE 1)	O	The associated functional alias of the MCData user identity towards which the data is sent.
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Emergency indicator	O	Indicates that the data request is for MCData emergency communication
Disposition Type	O	Indicates the disposition type expected from the receiver (i.e., delivered or read or both)
Payload Destination Type	M	Indicates whether the payload is for application consumption or MCData user consumption
Location	O	Location of the Originating MCData user sending the SDS message
Application identifier (see NOTE 2)	O	Identifies the application for which the payload is intended (e.g. text string, port address, URI)
Application metadata container	O	Implementation specific information that is communicated to the recipient
Payload	M	SDS content
NOTE 1: Either the MCData ID or the functional alias must be present. NOTE 2: The application identifier shall be included only if the payload destination type indicates that the payload is for application consumption.

Table 7.4.2.1.1-2: MCData standalone data request (MCData server to MCData client)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data
MCData ID	M	The identity of the MCData user towards which the data is sent
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Emergency indicator	O	Indicates that the data request is for MCData emergency communication
Disposition Type	O	Indicates the disposition type expected from the receiver (i.e., delivered or read or both)
Payload Destination Type	M	Indicates whether the payload is for application consumption or MCData client consumption
Location	O	Location of the Originating MCData user sending the SDS message
Application identifier (see NOTE)	O	Identifies the application for which the payload is intended (e.g. text string, port address, URI)
Application metadata container	O	Implementation specific information that is communicated to the recipient
Payload	M	SDS content
NOTE: The application identifier shall be included only if the payload destination type indicates that the payload is for application consumption.

7.4.2.1.2 MCData data disposition notification

Table 7.4.2.1.2-1 describes the information flow for the MCData data disposition notification sent from the MCData client to the MCData server.

Table 7.4.2.1.2-1: MCData data disposition notification

Information element	Status	Description
MCData ID	M	The identity of the MCData user towards which the notification is sent
MCData ID	M	The identity of the MCData user sending notification
Conversation Identifier	M	Identifies the conversation
Disposition association	M	Identity of the original MCData transaction
Disposition	M	Disposition which is delivered or read or both

7.4.2.1.3 MCData standalone session data request

Table 7.4.2.1.3-1 describes the information flow for the MCData standalone session data request sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.4.2.1.3-1: MCData standalone session data request (MCData client to MCData server)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data
Functional alias	O	The associated functional alias of the MCData user sending data.
MCData ID (see NOTE 1)	O	The identity of the MCData user towards which the data is sent
Functional alias (see NOTE 1)	O	The associated functional alias of the MCData user identity towards which the data is sent.
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Transaction type	M	Standalone transaction
Emergency indicator	O	Indicates that the data request is for MCData emergency communication
Disposition Type	O	Indicates the disposition type expected from the receiver (i.e., delivered or read or both)
Payload Destination Type	M	Indicates whether the SDS payload is for application consumption or MCData user consumption
Location	O	Location of the Originating MCData user sending the SDS message
Application identifier (see NOTE 2)	O	Identifies the application for which the payload is intended (e.g. text string, port address, URI)
Requested Priority	O	Application priority level requested for this communication.
Application metadata container	O	Implementation specific information that is communicated to the recipient
SDP offer	M	Media parameters offered
NOTE 1: Either the MCData ID or the functional alias must be present. NOTE 2: The application identifier shall be included only if the payload destination type indicates that the SDS message is for application consumption.

Table 7.4.2.1.3-2: MCData standalone session data request (MCData server to MCData client)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data
MCData ID	M	The identity of the MCData user towards which the data is sent
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Emergency indicator	O	Indicates that the data request is for MCData emergency communication
Transaction type	M	Standalone transaction
Disposition Type	O	Indicates the disposition type expected from the receiver (i.e., delivered or read or both)
Payload Destination Type	M	Indicates whether the SDS payload is for application consumption or MCData user consumption
Location	O	Location of the Originating MCData user sending the SDS message
Application identifier (see NOTE)	O	Identifies the application for which the payload is intended (e.g. text string, port address, URI)
Application metadata container	O	Implementation specific information that is communicated to the recipient
SDP offer	M	Media parameters offered
NOTE: The application identifier shall be included only if the payload destination type indicates that the SDS message is for application consumption.

7.4.2.1.4 MCData standalone session data response

Table 7.4.2.1.4-1 describes the information flow for the MCData standalone session data response sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.4.2.1.4-1: MCData standalone session data response

Information element	Status	Description
MCData ID	M	The identity of the MCData user receiving data
MCData ID	M	The identity of the MCData user sent data
Conversation Identifier	M	Identifies the conversation
SDP answer	M	Media parameters selected
Establishment reason	M	Reason for establishment or rejection

7.4.2.1.5 MCData session data request

Table 7.4.2.1.5-1 describes the information flow for the MCData session data request sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.4.2.1.5-1: MCData session data request (MCData client to MCData server)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data
Functional alias	O	The associated functional alias of the MCData user sending data.
MCData ID (see NOTE 1)	O	The identity of the MCData user towards which the data is sent
Functional alias (see NOTE 1)	O	The associated functional alias of the MCData user identity towards which the data is sent.
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Transaction type	M	Session based transactions
Emergency indicator	O	Indicates that the data request is for MCData emergency communication
Disposition Type	O	Indicates the disposition type expected from the receiver (i.e., delivered or read or both)
Payload Destination Type	M	Indicates whether the SDS payload is for application consumption or MCData user consumption
Location	O	Location of the Originating MCData user sending the SDS message
Application identifier (see NOTE 2)	O	Identifies the application for which the payload is intended (e.g. text string, port address, URI)
Application metadata container	O	Implementation specific information that is communicated to the recipient
SDP offer	M	Media parameters offered
Requested priority	O	Application priority level requested for this communication session
NOTE 1: Either the MCData ID or the functional alias must be present. NOTE 2: The application identifier shall be included only if the payload destination type indicates that the SDS message is for application consumption.

Table 7.4.2.1.5-2: MCData session data request (MCData server to MCData client)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data
MCData ID	O	The identity of the MCData user towards which the data is sent
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Transaction type	M	Session based transactions
Emergency indicator	O	Indicates that the data request is for MCData emergency communication
Disposition Type	O	Indicates the disposition type expected from the receiver (i.e., delivered or read or both)
Location	O	Location of the Originating MCData user sending the SDS message
Payload Destination Type	M	Indicates whether the SDS payload is for application consumption or MCData user consumption
Application identifier (see NOTE)	O	Identifies the application for which the payload is intended (e.g. text string, port address, URI)
Application metadata container	O	Implementation specific information that is communicated to the recipient
SDP offer	M	Media parameters offered
Requested priority	O	Application priority level requested for this communication session
NOTE: The application identifier shall be included only if the payload destination type indicates that the SDS message is for application consumption.

7.4.2.1.6 MCData session data response

Table 7.4.2.1.6-1 describes the information flow for the MCData session data response sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.4.2.1.6-1: MCData session data response

Information element	Status	Description
MCData ID	M	The identity of the MCData user receiving data
MCData ID	M	The identity of the MCData user sent data
Conversation Identifier	M	Identifies the conversation
SDP answer	M	Media parameters selected

7.4.2.1.7 MCData group standalone data request (MCData client – MCData server)

Table 7.4.2.1.7-1 describes the information flow for the MCData group standalone data request (in subclause 7.4.2.5.2) sent from the MCData client to the MCData server.

Table 7.4.2.1.7-1: MCData group standalone data request (MCData client – MCData server)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data
Functional alias	O	The associated functional alias of the MCData user sending data.
MCData group ID	M	The MCData group ID to which the data is to be sent
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Emergency indicator (see NOTE 1)	O	Indicates that the data request is for MCData emergency communication
Alert indicator (see NOTE 2)	O	Indicates whether an emergency alert is to be sent
Imminent peril indicator (see NOTE 1)	O	Indicates that the data request is for MCData imminent peril communication
Disposition Type	O	Indicates the disposition type expected from the receiver (i.e., delivered or read or both)
MCData ID list (see NOTE 4)	O	The specified MCData users who should send a disposition notification message.
Payload Destination Type	M	Indicates whether the payload is for application consumption or MCData user consumption
Location	O	Location of the Originating MCData user sending the SDS
Application identifier (see NOTE 3)	O	Identifies the application for which the payload is intended (e.g. text string, port address, URI)
Application metadata container	O	Implementation specific information that is communicated to the recipient
Payload	M	SDS content
NOTE 1: If used, only one of these information elements shall be present. NOTE 2: This information element may be present only when Emergency indicator is present. NOTE 3: The application identifier shall be included only if the payload destination type indicates that the SDS message is for application consumption. NOTE 4: If Disposition Type IE is not present, this IE shall not be present. If Disposition Type IE is present but this IE is not, which indicates that all receivers shall respond with disposition notification message.

7.4.2.1.8 MCData group standalone data request (MCData server – MCData client)

Table 7.4.2.1.8-1 describes the information flow for the MCData group standalone data request (in subclause 7.4.2.5.2) sent from the MCData server to the MCData client.

Table 7.4.2.1.8-1: MCData group standalone data request (MCData server – MCData client)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data
Functional alias	O	The associated functional alias of the MCData user sending data.
MCData group ID	M	The MCData group ID to which the data is to be sent
MCData ID	M	The identity of the MCData user towards which the data is sent
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Emergency indicator (see NOTE 1)	O	Indicates that the data request is for MCData emergency communication
Alert indicator (see NOTE 2)	O	Indicates whether an emergency alert is to be sent
Imminent peril indicator (see NOTE 1)	O	Indicates that the data request is for MCData imminent peril communication
Disposition Type	O	Indicates the disposition type expected from the receiver (i.e., delivered or read or both)
MCData ID list (see NOTE 4)	O	The specified MCData users who should send disposition notification message.
Payload Destination Type	M	Indicates whether the payload is for application consumption or MCData user consumption
Location	O	Location of the Originating MCData user sending the SDS
Application identifier (see NOTE 3)	O	Identifies the application for which the payload is intended (e.g. text string, port address, URI)
Application metadata container	O	Implementation specific information that is communicated to the recipient
Payload	M	SDS content
NOTE 1: If used, only one of these information elements shall be present. NOTE 2: This information element may be present only when Emergency indicator is present. NOTE 3: The application identifier shall be included only if the payload destination type indicates that the payload is for application consumption. NOTE 4: If Disposition Type IE is not present, this IE shall not be present. If Disposition Type IE is present but this IE is not, which indicates that all receivers shall respond with disposition notification message.

7.4.2.1.9 MCData data disposition notification (MCData server – MCData client)

Table 7.4.2.1.9-1 describes the information flow for the MCData data disposition notification(s) sent from the MCData server to the MCData client.

Table 7.4.2.1.9-1: MCData data disposition notification(s) (MCData server – MCData client)

Information element	Status	Description
MCData ID	M	The identity of the MCData user towards which the notification is sent
MCData ID	M	The identity of the MCData user sending notification
Conversation Identifier	M	Identifies the conversation
Disposition association	M	Identity of the original MCData transaction
Disposition	M	Disposition which is delivered or read or both

7.4.2.1.9A MCData aggregated data disposition notification

Table 7.4.2.1.9A-1 describes the information flow for the MCData aggregated data disposition notification sent from the MCData server to the MCData client, indicating the result of a request for an SDS delivery to an MCData group.

Table 7.4.2.1.9A-1: MCData aggregated data disposition notification

Information element	Status	Description
MCData ID	M	The identity of the MCData user towards which the notification is sent
Number of Aggregated Notifications	M	Total number of received individual notifications
Number of "Read" Notifications	O	Number of MCData users who only reported the "read" disposition
Number of "Delivered" Notifications	O	Number of MCData users who only reported the "delivered" disposition
Conversation Identifier	M	Identifies the conversation
Disposition association	M	Identity of the original MCData transaction
"Read" MCData ID list	O	List, partial or full, of MCData users who only reported the "read" disposition
"Delivered" MCData ID list	O	List, partial or full, of MCData users who only reported the "delivered" disposition

7.4.2.1.10 MCData group session standalone data request (MCData client – MCData server)

Table 7.4.2.1.10-1 describes the information flow for the MCData group session standalone data request (in subclause 7.4.2.6.2) sent from the MCData client to the MCData server.

Table 7.4.2.1.10-1: MCData group session standalone data request (MCData client – MCData server)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data
Functional alias	O	The associated functional alias of the MCData user sending data.
MCData group ID	M	The MCData group ID to which the data is to be sent
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Transaction type	M	Standalone transaction
Emergency indicator (see NOTE 1)	O	Indicates that the data request is for MCData emergency communication
Alert indicator (see NOTE 2)	O	Indicates whether an emergency alert is to be sent
Imminent peril indicator (see NOTE 1)	O	Indicates that the data request is for MCData imminent peril communication
Disposition Type	O	Indicates the disposition type expected from the receiver (i.e., delivered or read or both)
Payload Destination Type	M	Indicates whether the payload is for application consumption or MCData user consumption
Location	O	Location of the Originating MCData user sending the SDS message
Application identifier (see NOTE 3)	O	Identifies the application for which the payload is intended (e.g. text string, port address, URI, attached data hosts)
Application metadata container	O	Implementation specific information that is communicated to the recipient
SDP offer	M	Media parameters offered
Requested priority	O	Application priority level requested for this communication session
NOTE 1: If used, only one of these information elements shall be present. NOTE 2: This information element may be present only when Emergency indicator is present. NOTE 3: The application identifier shall be included only if the payload destination type indicates that the SDS message is for application consumption or IP data in IP connectivity sessions are for data host consumption.

7.4.2.1.11 MCData group session standalone data request (MCData server – MCData client)

Table 7.4.2.1.11-1 describes the information flow for the MCData group session standalone data request (in subclause 7.4.2.6.2) sent from the MCData server to the MCData client.

Table 7.4.2.1.11-1: MCData group session standalone data request (MCData server – MCData client)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data
Functional alias	O	The associated functional alias of the MCData user sending data.
MCData group ID	M	The MCData group ID to which the data is to be sent
MCData ID	M	The identity of the MCData user towards which the data is sent
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Transaction type	M	Standalone transaction
Emergency indicator (see NOTE 1)	O	Indicates that the data request is for MCData emergency communication
Alert indicator (see NOTE 2)	O	Indicates whether an emergency alert is to be sent
Imminent peril indicator (see NOTE 1)	O	Indicates that the data request is for MCData imminent peril communication
Disposition Type	O	Indicates the disposition type expected from the receiver (i.e., delivered or read or both)
Payload Destination Type	M	Indicates whether the payload is for application consumption or MCData user consumption
Location	O	Location of the Originating MCData user sending the SDS message
Application identifier (see NOTE 3)	O	Identifies the application for which the payload is intended (e.g. text string, port address, URI, attached data hosts)
Application metadata container	O	Implementation specific information that is communicated to the recipient
SDP offer	M	Media parameters offered
NOTE 1: If used, only one of these information elements shall be present. NOTE 2: This information element may be present only when Emergency indicator is present. NOTE 3: The application identifier shall be included only if the payload destination type indicates that the SDS message is for application consumption or IP data in IP connectivity sessions are for data host consumption.

7.4.2.1.12 MCData group session standalone data response

Table 7.4.2.1.12-1 describes the information flow for the MCData group standalone data response (in subclause 7.4.2.6.2) sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.4.2.1.12-1: MCData group session standalone data response

Information element	Status	Description
MCData ID	M	The identity of the MCData user receiving data
MCData group ID	M		The MCData group ID to which the data is to be sent
MCData ID	M	The identity of the MCData user sent data
Conversation Identifier	M	Identifies the conversation
SDP answer	M	Media parameters selected

7.4.2.1.13 MCData group data request (MCData client – MCData server)

Table 7.4.2.1.13-1 describes the information flow for the MCData group data request sent from the MCData client to the MCData server.

Table 7.4.2.1.13-1: MCData group data request (MCData client – MCData server)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data
Functional alias	O	The associated functional alias of the MCData user sending data.
MCData group ID	M	The MCData group ID to which the data is to be sent
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Transaction type	M	Session based transactions
Emergency indicator (see NOTE 1)	O	Indicates that the data request is for MCData emergency communication
Alert indicator (see NOTE 2)	O	Indicates whether an emergency alert is to be sent
Imminent peril indicator (see NOTE 1)	O	Indicates that the data request is for MCData imminent peril communication
Disposition Type	O	Indicates the disposition type expected from the receiver (i.e., delivered or read or both)
Payload Destination Type	M	Indicates whether the SDS payload is for application consumption or MCData user consumption
Location	O	Location of the Originating MCData user sending the SDS message
Application identifier (see NOTE 3)	O	Identifies the application for which the payload is intended (e.g. text string, port address, URI)
Application metadata container	O	Implementation specific information that is communicated to the recipient
SDP offer	M	Media parameters offered
Requested priority	O	Application priority level requested for this communication session
NOTE 1: If used, only one of these information elements shall be present. NOTE 2: This information element may be present only when Emergency indicator is present. NOTE 3: The application identifier shall be included only if the payload destination type indicates that the SDS message is for application consumption.

7.4.2.1.14 MCData group data request (MCData server – MCData client)

Table 7.4.2.1.14-1 describes the information flow for the MCData group data request sent from the MCData server to the MCData client.

Table 7.4.2.1.14-1: MCData group data request (MCData server – MCData client)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data
Functional alias	O	The associated functional alias of the MCData user sending data.
MCData group ID	M	The MCData group ID to which the data is to be sent
MCData ID	M	The identity of the recipient MCData user
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Transaction type	M	Session based transactions
Emergency indicator (see NOTE 1)	O	Indicates that the data request is for MCData emergency communication
Alert indicator (see NOTE 2)	O	Indicates whether an emergency alert is to be sent
Imminent peril indicator (see NOTE 1)	O	Indicates that the data request is for MCData imminent peril communication
Disposition Type	O	Indicates the disposition type expected from the receiver (i.e., delivered or read or both)
Payload Destination Type	M	Indicates whether the SDS payload is for application consumption or MCData user consumption
Location	O	Location of the Originating MCData user sending the SDS message
Application identifier (see NOTE 3)	O	Identifies the application for which the payload is intended (e.g. text string, port address, URI)
Application metadata container	O	Implementation specific information that is communicated to the recipient
SDP offer	M	Media parameters offered
NOTE 1: If used, only one of these information elements shall be present. NOTE 2: This information element may be present only when Emergency indicator is present. NOTE 3: The application identifier shall be included only if the payload destination type indicates that the SDS message is for application consumption.

7.4.2.1.15 MCData group data response

Table 7.4.2.1.15-1 describes the information flow for the MCData group data response sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.4.2.1.15-1: MCData group data response

Information element	Status	Description
MCData ID	M	The identity of the MCData user receiving data
MCData group ID	M		The MCData group ID to which the data is to be sent
MCData ID	M	The identity of the MCData user sent data
Conversation Identifier	M	Identifies the conversation
SDP answer	M	Media parameters selected

7.4.2.1.16 MCData one-to-one SDS communication upgrade request

Table 7.4.2.1.16-1 describes the information flow for the MCData one-to-one SDS communication upgrade request sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.4.2.1.16-1: MCData one-to-one SDS communication upgrade request

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data (when initiated by MCData client); The identity of the MCData user receiving data (when initiated by MCData server).
Functional alias	O	The associated functional alias of the MCData user sending data or receiving data.
Conversation Identifier	M	Identifies the conversation
Emergency indicator	M	Indicates that the data request is for MCData emergency communication

7.4.2.1.17 MCData one-to-one SDS communication upgrade response

Table 7.4.2.1.17-1 describes the information flow for the MCData one-to-one SDS communication upgrade response sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.4.2.1.17-1: MCData one-to-one SDS communication upgrade response

Information element

Status

Description

MCData ID

The identity of the MCData user sending data (when initiated by MCData client);

The identity of the MCData user receiving data (when initiated by MCData server).

Conversation Identifier

Identifies the conversation

7.4.2.1.18 MCData group SDS communication upgrade request

Table 7.4.2.1.18-1 describes the information flow for the MCData group SDS communication upgrade request sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.4.2.1.18-1: MCData group SDS communication upgrade request (MCData client to MCData server)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending upgrade request
Functional alias	O	The associated functional alias of the MCData user sending data or receiving data.
MCData group ID	M	The MCData group ID on which the emergency upgrade request is made
Conversation Identifier	M	Identifies the conversation
Emergency indicator (see NOTE 1)	O	Indicates that the data request is for MCData emergency communication
Alert indicator (see NOTE 2)	O	Indicates whether an emergency alert is to be sent
Imminent peril indicator (see NOTE 1)	O	Indicates that the data request is for MCData imminent peril communication
NOTE 1: If used, only one of these information elements shall be present. NOTE 2: This information element may be present only when Emergency indicator is present.

Table 7.4.2.1.18-2: MCData group SDS communication upgrade request (MCData server to MCData client)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending upgrade request
Functional alias	O	The associated functional alias of the MCData user sending data or receiving data.
MCData group ID	M	The MCData group ID on which the emergency upgrade request is made
MCData ID	M	The identity of the MCData user receiving the upgrade request
Conversation Identifier	M	Identifies the conversation
Emergency indicator (see NOTE 1)	O	Indicates that the data request is for MCData emergency communication
Alert indicator (see NOTE 2)	O	Indicates whether an emergency alert is to be sent
Imminent peril indicator (see NOTE 1)	O	Indicates that the data request is for MCData imminent peril communication
NOTE 1: If used, only one of these information elements shall be present. NOTE 2: This information element may be present only when Emergency indicator is present.

7.4.2.1.19 MCData group SDS communication upgrade response

Table 7.4.2.1.19-1 describes the information flow for the MCData group SDS communication upgrade response sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.4.2.1.19-1: MCData group SDS communication upgrade response

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data (when initiated by MCData client); The identity of the MCData user receiving data (when initiated by MCData server).
MCData group ID	M	The MCData group ID on which the emergency upgrade request is made
Conversation Identifier	M	Identifies the conversation

7.4.2.1.20 MCData group SDS communication in-progress priority state cancel request

Table 7.4.2.1.20-1 describes the information for the MCData group SDS communication in-progress priority state cancel request sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.4.2.1.20-1: MCData group SDS communication in-progress priority state cancel request (MCData client to MCData server)

Information Element	Status	Description
MCData ID	M	The identity of the cancelling party
MCData group ID	M	The MCData group ID on which the MCData in-progress emergency state is to be cancelled.
Emergency indicator (see NOTE 1)	O	Indicates that the data request is for MCData emergency communication
Alert indicator (see NOTE 2)	O	Indicates whether an emergency alert is to be sent
Imminent peril indicator (see NOTE 1)	O	Indicates that the data request is for MCData imminent peril communication
Conversation Identifier	M	Identifies the conversation
NOTE 1: If used, only one of these information elements shall be present. NOTE 2: This information element may be present only when Emergency indicator is present.

Table 7.4.2.1.20-2 MCData group SDS communication in-progress priority state cancel request (MCData server to MCData client)

Information Element	Status	Description
MCData ID	M	The identity of the cancelling party
MCData group ID	M	The MCData group ID on which the MCData in-progress emergency state is to be cancelled.
MCData ID	M	The identity of the recipient MCData user
Emergency indicator (see NOTE 1)	O	Indicates that the data request is for MCData emergency communication
Alert indicator (see NOTE 2)	O	Indicates whether an emergency alert is to be sent
Imminent peril indicator (see NOTE 1)	O	Indicates that the data request is for MCData imminent peril communication
Conversation Identifier	M	Identifies the conversation
NOTE 1: If used, only one of these information elements shall be present. NOTE 2: This information element may be present only when Emergency indicator is present.

7.4.2.1.21 MCData group SDS communication in-progress priority state cancel response

Table 7.4.2.1.21-1 describes the information flow for the MCData group SDS communication in-progress priority state cancel response sent from the MCData server to the MCData client.

Table 7.4.2.1.21-1: MCData group SDS communication in-progress priority state cancel response

Information Element	Status	Description
MCData ID	M	The identity of the cancelling party
MCData group ID	M	The MCData group ID on which the MCData in-progress emergency in-progress is to be cancelled.
Conversation Identifier	M	Identifies the conversation

7.4.2.1.22 MCData functional alias resolution response

Table 7.4.2.1.22-1 describes the information flow MCData functional alias resolution response from the MCData server to the MCData client.

Table 7.4.2.1.22-1: MCData functional alias resolution response information elements

Information Element	Status	Description
MCData ID	M	The identity of the MCData user sending the data
MCData ID	M	The corresponding MCData ID of the functional alias resolved by MCData server

7.4.2.2 One-to-one standalone short data service using signalling control plane

7.4.2.2.1 General

A MCData user initiates a standalone SDS data transfer with another MCData user. For the SDS data transfer signalling plane is used. The target MCData user may be addressed using the functional alias that can be shared with other MCData users.

7.4.2.2.2 Procedure

The procedure in figure 7.4.2.2.2-1 describes the case where an MCData user is initiating one-to-one MCData data communication for sending standalone SDS data to other MCData user, with or without disposition request. Standalone refers to sending unidirectional data in one transaction.

Pre-conditions:

1. The SDS payload data size is below the configured maximum payload data size for SDS over signalling control plane.

2. MCData users on MCData client 1 and MCData client 2 are already registered for receiving MCData service.

3. MCData client 1 and MCData client 2 belong to the same MCData system.

4. Optionally, the MCData client may have activated functional alias to be used.

5. The MCData server may have subscribed to the MCData functional alias controlling server within the MC system for functional alias activation/de-activation updates.

Figure 7.4.2.2.2-1: One-to-one standalone short data service using signalling control plane

1. The user at MCData client 1 initiates an SDS data transfer for the chosen MCData user.

2. MCData client 1 sends a MCData standalone data request towards the MCData server. The MCData standalone data request contains conversation identifier for message thread indication. The MCData standalone data request may include additional implementation specific information in the application metadata container. The MCData standalone data request may contain disposition request if indicated by the user at MCData client 1. MCData user at MCData client 1 may include a functional alias within the SDS data transfer and addresses the target MCData client 2 using a functional alias.

a) If the MCData user at the MCData client 1 initiates an MCData emergency short data service communication or MCData emergency state is already set for the MCData client 1 (due to previously triggered MCData emergency alert):

i) The MCData standalone data request shall contain emergency indicator; and

ii) If MCData emergency state is not set already, MCData client 1 sets its MCData emergency state. The MCData emergency state of MCData client 1 is retained until explicitly cancelled by the user of MCData client 1.

NOTE 1: While MCData client 1 is in the emergency state, all types of MCData one-to-one and group communications initiated by MCData client 1 are initiated as MCData emergency communications.

3. MCData server checks whether the MCData user at MCData client 1 is authorized to send MCData standalone data request. MCData server verifies whether the provided functional alias of MCData client 1, if present, can be used and has been activated for the user. The MCData server also checks whether any policy is to be asserted to limit certain types of message or content to certain members due, for example, to location or user privilege or affiliation. If functional alias is used to address that target MCData user, the MCData server resolves the functional alias to the corresponding MCData ID(s) for which the functional alias is active and proceed with step 4 otherwise proceed with step 6. The MCData server allows only two participating MCData clients for a standalone short data service.

NOTE 2: The MCData server prioritizes the MCData emergency communication over the other MCData communication. How the MCData server prioritizes MCData emergency communication is not in the scope of the present document.

NOTE 3: If the MCData server detects that the functional alias used as the target of the SDS data transfer request is simultaneously active for multiple MCData users, then the MCData server can proceed by selecting an appropriate MCData ID based on some selection criteria. The selection of an appropriate MCData ID is left to implementation. These selection criteria can include rejection of the SDS data transfer request, if no suitable MCData ID is selected.

4. The MCData server responds back to MCData client 1 with a functional alias resolution response message that contains the resolved MCData ID.

5. If the MCData server replies with a MCData functional alias resolution response message, the MCData client 1 assumes the MCData standalone data request in step 2 is rejected and sends a new MCData standalone data request towards the resolved MCData ID.

6. MCData server initiates the MCData standalone data request towards the MCData user that is determined based on step 3. The MCData standalone data request towards the MCData user contains the emergency indicator if it is present in the received MCData standalone data request from MCData client 1.

NOTE 4: MCData client 2 does not set its emergency state as a result of receiving the MCData standalone data request containing the emergency indicator.

7. If the payload is for MCData user consumption (e.g. is not application data, is not command instructions, etc.) then the MCData user of MCData client 2 may be notified. Otherwise if the payload is not for MCData user consumption, then the MCData user of MCData client 2 shall not be notified. The action taken when the payload contains application data or command instructions are specific based on the contents of the payload. Payload content received by MCData client 2 which is addressed to a known local non-MCData application that is not yet running shall cause the MCData client 2 to start the local non-MCData application (i.e., remote start application) and shall pass the payload content to the just started application.

8. If the MCData data disposition for delivery was requested by the user at MCData client 1, then the receiving MCData client initiates a MCData data disposition notification for delivery report. The MCData data disposition notification from MCData client may be stored by the MCData server for disposition history interrogation from authorized MCData users.

9. MCData data disposition notification is sent to the disposition requesting user at MCData client 1.

10. If the MCData data disposition for read was requested by the user at MCData client 1, then once the receiving user reads the data, the receiving MCData client 2 initiates a MCData data disposition notification for read report. The MCData data disposition notification from MCData client 2 may be stored by the MCData server for disposition history interrogation from authorized MCData users.

11. MCData data disposition notification is sent to the disposition requesting user at MCData client 1.

7.4.2.3 One-to-one standalone short data service using media plane

7.4.2.3.1 General

A MCData user initiates a standalone SDS data transfer with another MCData user. For the SDS data transfer media plane is used. The target MCData user may be addressed using the functional alias that can be shared with other MCData users.

7.4.2.3.2 Procedure

The procedure in figure 7.4.2.3.2-1 describes the case where an MCData user is initiating one-to-one MCData data communication for sending standalone SDS data to other MCData user, with or without disposition request. Standalone refers to sending unidirectional data in one transaction. The SDS payload data size is assumed to be above the configured maximum payload data size for SDS over signalling control plane.

Pre-conditions:

1. MCData users on MCData client 1 and MCData client 2 are already registered for receiving MCData service.

2. MCData client 1 and MCData client 2 belong to the same MCData system.

3. Optionally, the MCData client may have an activated functional alias to be used.

4. The MCData server may have subscribed to the MCData functional alias controlling server within the MC system for functional alias activation/de-activation updates.

Figure 7.4.2.3.2-1: One-to-one standalone short data service using media plane

1. User at MCData client 1 would like to initiate an SDS data transfer request for the chosen MCData user.

2. MCData client 1 sends a MCData standalone session data request towards the MCData server. The MCData standalone session data request contains one MCData user for one-to-one data communication as selected by the user at MCData client 1. The MCData standalone session data request contains conversation identifier for message thread indication. The MCData standalone session data request may include additional implementation specific information in the application metadata container. The MCData data request may contain disposition request if indicated by the user at MCData client 1. MCData user at MCData client 1 may include a functional alias within the SDS data transfer and addresses the target MCData client 2 using a functional alias.

i) The MCData standalone session data request shall contain emergency indicator; and

NOTE 1: While MCData client 1 is in the emergency state, all types of MCData one-to-one and group communications initiated by MCData client 1 are initiated as MCData emergency communications.

3. MCData server checks whether the MCData user at MCData client 1 is authorized to send MCData standalone session data request. MCData server verifies whether the provided functional alias of MCData client 1, if present, can be used and has been activated for the user. The MCData server also checks whether any policy is to be asserted to limit certain types of message or content to certain members due, for example, to location or user privilege. MCData server determines the eligible MCData user(s) after policy assertion for sending the MCData standalone session data request. If functional alias is used to address that target MCData user, the MCData server resolves the functional alias to the corresponding MCData ID(s) for which the functional alias is active and proceed with step 4 otherwise proceed with step 6. The resulting list contains all associated MCData IDs/MCData users that share this functional alias. The MCData server allows only two participating MCData clients for a standalone short data service.

4. The MCData server responds back to MCData client 1 with a functional alias resolution response message that contains the resolved MCData ID.

NOTE 3: If the MCData server detects that the functional alias used as the target of the MCData standalone session data request is simultaneously active for multiple MCData users, then the MCData server can proceed by selecting an appropriate MCData ID based on some selection criteria. The selection of an appropriate MCData ID is left to implementation. These selection criteria can include rejection of the MCData standalone session data request, if no suitable MCData ID is selected.

5. If the MCData server replies with a MCData functional alias resolution response message, the MCData client 1 abandons the MCData standalone session data request in step 2 and sends a new MCData standalone session data request towards the resolved MCData ID.

6. MCData server initiates the MCData standalone session data request towards the MCData users determined. The MCData standalone session data request towards the MCData user contains an emergency indicator if it is present in the received MCData standalone session data request from MCData client 1.

NOTE 4: MCData client 2 corresponds to the MCData user(s) after resolution of the functional alias.

NOTE 5: MCData client 2 does not set its emergency state as a result of receiving the MCData standalone session data request containing the emergency indicator.

7. The receiving MCData client 2 automatically accepts the MCData standalone session data request and responds with MCData standalone session data response towards MCData server.

8. MCData server forwards the MCData client 2 accepted response to the MCData Client 1 initiating the MCData standalone session data request.

9. MCData client 1 and MCData client 2 have successfully established media plane for data communication and the MCData client 1 transmits the SDS data.

10. If the payload is for MCData user consumption (e.g. is not application data, is not command instructions, etc.) then the MCData user of MCData client 2 may be notified. Otherwise if the payload is not for MCData user consumption, then the MCData user of MCData client 2 shall not be notified. The action taken when the payload contains application data or command instructions are specific based on the contents of the payload. Payload content received by MCData client 2 which is addressed to a known local non-MCData application that is not yet running shall cause the MCData client 2 to start the local non-MCData application (i.e., remote start application) and shall pass the payload content to the just started application.

11. If the MCData data disposition for delivery was requested by the user at MCData client 1, then the receiving MCData client initiates a MCData data disposition notification for delivery report. The MCData data disposition notification from MCData client 2 may be stored by the MCData server for disposition history interrogation from authorized MCData users.

12. MCData data disposition notification is sent to the disposition requesting user at MCData client 1.

13. If the MCData disposition for read was requested by the user at MCData client 1, then once the receiving user reads the data, the receiving MCData client 2 initiates a MCData disposition notification for read report. The MCData data disposition notification from MCData client 2 may be stored by the MCData server for disposition history interrogation from authorized MCData users.

14. MCData data disposition notification is sent to the disposition requesting user at MCData client 1.

7.4.2.4 One-to-one short data service session

7.4.2.4.1 General

A MCData user triggers an establishment of a MCData session with another MCData user for the exchange of SDS data. The target MCData user may be addressed using the functional alias that can be shared with other MCData users.

7.4.2.4.2 Procedure

The procedure in figure 7.4.2.4.2-1 describes the case where an MCData user is initiating data communication session with another MCData user for exchanging at least one SDS data transaction between them, with or without disposition request using MCData-SDS-1 and MCData-SDS-2 or MCData-SDS-3 reference points.

Pre-conditions:

1. MCData users on MCData client 1 and MCData client 2 are already registered for receiving MCData service.

2. Optionally, the MCData client may have activated functional alias to be used.

3. The MCData server may have subscribed to the MCData functional alias controlling server within the MC system for functional alias activation/de-activation updates.

Figure 7.4.2.4.2-1: One-to-one short data service session

1. User at MCData client 1 would like to initiate an SDS data communication session request for the chosen MCData user.

2. MCData client 1 sends a MCData session data request towards the MCData server. The MCData session data request contains one MCData user for one-to-one data communication as selected by the user at MCData client 1. The MCData session data request contains conversation identifier for message thread indication. The MCData session data request may include additional implementation specific information in the application metadata container. MCData user at MCData client 1 may include a functional alias within the SDS data transfer and addresses the target MCData client 2 using a functional alias.

i) The MCData session data request shall contain emergency indicator; and

ii) If MCData emergency state is not set already, MCData client 1 sets its MCData emergency state. The MCData emergency state of MCData client is retained until explicitly cancelled by the user of MCData client 1.

NOTE 1: While MCData client 1 is in the emergency state, all types of MCData one-to-one and group communications initiated by MCData client 1 are initiated as MCData emergency communications.

3. MCData server checks whether the MCData user at MCData client 1 is authorized to send MCData session data request. The MCData server also checks whether any policy is to be asserted to limit certain types of message or content to certain members due, for example, to location or user privilege. MCData server determines the eligible MCData user(s) after policy assertion for sending the MCData session data request. MCData server also verifies whether the provided functional alias of MCData client 1, if present, can be used and has been activated for the user. If functional alias is used to address that target MCData user, the MCData server resolves the functional alias to the corresponding MCData ID(s) for which the functional alias is active and proceed with step 4 otherwise proceed with step 6. The MCData server allows only two participating MCData clients for a standalone short data service.

NOTE 3: If the MCData server detects that the functional alias used as the target of the MCData session data request is simultaneously active for multiple MCData users, then the MCData server can proceed by selecting an appropriate MCData ID based on some selection criteria. The selection of an appropriate MCData ID is left to implementation. These selection criteria can include rejection of the SDS data transfer request, if no suitable MCData ID is selected.

4. The MCData server responds back to MCData client 1 with a functional alias resolution response message that contains the resolved MCData ID.

5. If the MCData server replies with a MCData functional alias resolution response message, the MCData client 1 abandons the MCData session data request in step 2 and sends a new MCData session data request towards the resolved MCData ID.

6. MCData server initiates the MCData session data request towards the MCData users determined. The MCData session data request towards the MCData user contains the emergency indicator if it is present in the received MCData session data request from MCData client 1.

NOTE 4: MCData client 2 corresponds to the MCData user(s) after resolution of the functional alias.

NOTE 5: MCData client 2 does not set its emergency state as a result of receiving the MCData session data request containing the emergency indicator.

7. If the emergency indicator is present, the receiving MCData client 2 notifies the user about the incoming MCData session data request.

8. The receiving MCData client 2 accepts the MCData session data request and responds with MCData session data response towards MCData server.

9. MCData server forwards the MCData client 2 accepted response to the MCData user initiating the MCData session data request.

10. and 11. MCData client 1 and MCData client 2 have successfully established media plane for data communication and either MCData client can transmit SDS data. The MCData data request may contain disposition request if indicated by the client sending data. If MCData data disposition was requested by the user, then the receiving MCData client initiates a MCData data disposition notification for delivery, read reports to the disposition requesting user. The MCData data disposition notification from MCData user may be stored by the MCData server for disposition history interrogation from authorized users.

12. and 13. If the payload is for MCData user consumption (e.g. is not application data, is not command instructions, etc.) then the MCData user of MCData client 2 may be notified, otherwise the MCData user of MCData client 2 shall not be notified.

14. After SDS data transaction is complete, the established media plane is released.

7.4.2.5 Group standalone short data service using signalling control plane

7.4.2.5.1 General

The initiation of a group standalone SDS to a selected group results in affiliated group members receiving the SDS data. The SDS payload data size is assumed to be below the configured maximum payload data size for SDS over signalling control plane.

7.4.2.5.2 Procedure

The procedure in figure 7.4.2.5.2-1 describes the case where an MCData user is initiating group standalone MCData data communication with or without disposition request, to a group.

Pre-conditions:

1. MCData users on MCData clients 1 to n belong to the same group and are already registered for receiving MCData service and affiliated.

2. Optionally, the MCData client may have activated functional alias to be used.

3. The MCData server may have subscribed to the MCData functional alias controlling server within the MC system for functional alias activation/de-activation updates.

Figure 7.4.2.5.2-1: Group standalone SDS using signalling control plane

1. The user at MCData client 1 initiates an SDS data transfer to multiple MCData users selecting a pre-configured group (identified by MCData group ID) and optionally particular members from that group.

2. MCData client 1 sends a MCData group standalone data request towards the MCData server. The MCData group data request contains MCData group ID as selected by the user at MCData client 1. The MCData group standalone data request contains conversation identifier for message thread indication. The MCData session data request may include additional implementation specific information in the application metadata container. The MCData group standalone data request may contain disposition request if indicated by the user at MCData client 1. MCData user at MCData client 1 may include a functional alias within the SDS data transfer.

If the MCData user at MCData client 1 initiates an MCData emergency short data service communication or the MCData emergency state is already set for the MCData client 1 (due to a previously triggered MCData emergency alert):

i) the MCData group standalone data request shall contain an emergency indicator;

ii) the MCData group standalone data request shall set an alert indicator if configured to send an MCData emergency alert while initiating an MCData standalone data request for the emergency short data service communication;

iii) if the MCData emergency state is not set already, MCData client 1 sets its MCData emergency state. The MCPTT emergency state is retained until explicitly cancelled; and

iv) once an MCData emergency communication has been initiated, the MCData group is considered to be in an in-progress emergency state until cancelled.

If the MCData user at MCData client 1 initiates an MCData imminent peril short data service communication:

i) the MCData group standalone data request shall contain imminent peril indicator; and

ii) once an MCData imminent peril communication has been initiated, the MCData group is considered to be in an in-progress imminent peril state until cancelled.

2a. If either emergency indicator or imminent peril indicator is present in the received MCData group standalone data request, the MCData server implicitly affiliates MCData client 1 to the MCData group if the client is not already affiliated.

3. MCData server checks whether the MCData user at MCData client 1 is authorized to send MCData group standalone data request. The MCData server resolves the MCData group ID to determine the members of that group and their affiliation status, based on the information from the group management server. The MCData server also checks whether any policy is to be asserted to limit certain types of message or content to certain members due, for example, to location or user privilege or affiliation. MCData server also verifies whether the provided functional alias, if present, can be used and has been activated for the user.

i) If an emergency indicator is present in the received MCData group standalone data request and if the MCData group is not in the in-progress emergency state, the MCData group is considered to be in the in-progress emergency state until cancelled; and

ii) If an imminent peril indicator is present in the received MCData group standalone data request and if the MCData group is not in the in-progress imminent peril state, the MCData group is considered to be in the in-progress imminent peril state until cancelled.

4. MCData server initiates the MCData group standalone data request towards each MCData client determined in Step 3. The MCData ID list shall not be included in a unicast downlink delivery to an individual MCData client. The Disposition Type IE shall not be included in a unicast downlink delivery to MCData clients who are not in the MCData ID list in step 2. The MCData group standalone data request towards each MCData client contains:

i) an emergency indicator, if it is present in the received MCData group standalone data request from the MCData client 1;

ii) an imminent peril indicator, if it is present in the received MCData group standalone data request from the MCData client 1; and

iii) an alert indicator, if requested to initiate an emergency alert in the received MCData group standalone data request from the MCData client 1.

5. If the payload is for MCData user consumption (e.g. is not application data, is not command instructions, etc.) then the MCData user of MCData clients 2 to n may be notified. Otherwise if the payload is not for MCData user consumption, then the MCData user of MCData clients 2 to n shall not be notified. The action taken when the payload contains application data or command instructions are specific based on the contents of the payload. Payload content received by MCData client 2 which is addressed to a known local non-MCData application that is not yet running shall cause the MCData client 2 to start the local non-MCData application (i.e., remote start application) and shall pass the payload content to the just started application.

6. If the MCData data disposition for delivery was requested by the user at MCData client 1, then the receiving MCData client(s) initiates a MCData data disposition notification for delivery report.

7. If the MCData data disposition for read was requested by the user at MCData client 1, then once the receiving user reads the data, the receiving MCData client 2 initiates a MCData data disposition notification for read report.

NOTE 1: On receiving MCData group standalone data request over MBMS, the receiving MCData client(s) shall check if the MCData ID list IE is included the receiving MCData client shall check if its own MCData ID is in the list. If not, step 6 and 7 are not required.

8. The MCData data disposition notification(s) from MCData client may be stored by the MCData server for disposition history interrogation from authorized MCData users. The MCData data disposition notification(s) from each MCData user may be aggregated.

9. Aggregated or individual MCData data disposition notification(s) is sent to the disposition requesting user at MCData client 1.

7.4.2.6 Group standalone short data service using media plane

7.4.2.6.1 General

The initiation of a group standalone SDS to a selected group results in affiliated group members receiving the SDS data. The SDS payload data size is assumed to be above the configured maximum payload data size for SDS over signalling control plane.

7.4.2.6.2 Procedure

The procedure in figure 7.4.2.6.2-1 describes the case where an MCData user is initiating group standalone MCData data communication with or without disposition request to a group.

Pre-conditions:

1. MCData users on MCData client 1 to n belong to the same group and are already registered for receiving MCData service and affiliated.

2. Optionally, the MCData client may have activated functional alias to be used.

3. The MCData server may have subscribed to the MCData functional alias controlling server within the MC system for functional alias activation/de-activation updates.

Figure 7.4.2.6.2-1: Group standalone SDS using media plane

1. User at MCData client 1 would like to initiate a SDS data transfer request to multiple MCData users selecting a pre-configured group (identified by MCData group ID) and optionally particular members from that group.

2. MCData client 1 sends a MCData group session standalone data request towards the MCData server. The MCData group session standalone data request contains target recipient(s) as selected by the user at MCData client 1. The MCData session group standalone data request contains conversation identifier for message thread indication. The MCData session group standalone data request may include additional implementation specific information in the application metadata container. The MCData session group standalone data request may contain disposition request if indicated by the user at MCData client 1. MCData user at MCData client 1 may include a functional alias within the SDS data transfer.

If the MCData user at MCData client 1 initiates an MCData emergency short data service communication or the MCData emergency state is already set for MCData client 1 (due to a previously triggered MCData emergency alert):

i) the MCData group session standalone data request shall contain an emergency indicator;

ii) the MCData group session standalone data request shall set the alert indicator if configured to send an MCData emergency alert while initiating an MCData standalone data request for the emergency short data service communication;

iii) if the MCData emergency state is not set already, MCData client 1 sets its MCData emergency state. The MCPTT emergency state is retained until explicitly cancelled; and

iv) once an MCData emergency communication has been initiated, the MCData group is considered to be in an in-progress emergency state until cancelled.

If the MCData user at MCData client 1 initiates an MCData imminent peril short data service communication:

i) the MCData group session standalone data request shall contain an imminent peril indicator; and

ii) once an MCData imminent peril communication has been initiated, the MCData group is considered to be in an in-progress imminent peril state until cancelled.

2a. If either an emergency indicator or an imminent peril indicator is present in received MCData group session standalone data request, the MCData server implicitly affiliates MCData client 1 to the MCData group if the client is not already affiliated.

3. MCData server checks whether the MCData user at MCData client 1 is authorized to send MCData session group standalone data request. The MCData server resolves the MCData group ID to determine the members of that group and their affiliation status, based on the information from the group management server. The MCData server also checks whether any policy is to be asserted to limit certain types of message or content to certain members due, for example, to location or user privilege. MCData server also verifies whether the provided functional alias, if present, can be used and has been activated for the user.

i) if an emergency indicator is present in the received MCData group session standalone data request and if the MCData group is not in the in-progress emergency state, the MCData group is considered to be in the in-progress emergency state until cancelled; and

ii) if an imminent peril indicator is present in the received MCData group session standalone data request and if the MCData group is not in the in-progress imminent peril state, the MCData group is considered to be in the in-progress imminent peril state until cancelled.

3a. The MCData server configures the priority of the underlying bearers for all participants in the MCData group.

4. MCData server initiates the MCData group session standalone data request towards each MCData user determined in Step 3. The MCData ID list shall not be included in a unicast downlink delivery to an individual MCData client. The Disposition Type IE shall not be included in a unicast downlink delivery to MCData clients who are not in the MCData ID list in step 2. The MCData group session standalone data request towards each MCData client contains:

i) an emergency indicator, if it is present in the received MCData group session standalone data request from the MCData client 1;

ii) an imminent peril indicator, if it is present in the received MCData group session standalone data request from the MCData client 1; and

iii) an alert indicator, if requested to initiate an emergency alert in the received MCData group session standalone data request from MCData client 1.

5. The receiving MCData clients 2 to n automatically accepts the MCData group session standalone data request and responds with MCData group standalone data response towards MCData server.

6. MCData server forwards the MCData clients 2 to n accepted response to the MCData user initiating the MCData group session standalone data request.

NOTE 1: Step 6 can occur at any time following step 4, and prior to step 7 depending on the conditions to proceed with the data transmission.

7. MCData client 1 and MCData server have successfully established media plane for data communication and the MCData client 1 transmits the SDS data.

8. MCData server distributes the data received from MCData client 1 to MCData clients 2 to n over the established media plane. After completion of the MCData transfer from MCData client 1, media plane resources associated to the data communication are released.

NOTE 2: MCData server is not required to wait for the complete reception of SDS data from MCData client 1 prior to initiating transmission to MCData client 2 to n.

9. If the payload is for MCData user consumption (e.g. is not application data, is not command instructions, etc.) then the MCData user of MCData client 2 to n may be notified. Otherwise if the payload is not for MCData user consumption, then the MCData user of MCData client 2 to n shall not be notified. The action taken when the payload contains application data or command instructions are specific based on the contents of the payload. Payload content received by MCData client 2 which is addressed to a known local non-MCData application that is not yet running shall cause the MCData client 2 to start the local non-MCData application (i.e., remote start application) and shall pass the payload content to the just started application.

10. If the MCData data disposition for delivery was requested by the user at MCData client 1, then the receiving MCData client(s) initiates a MCData data disposition notification for delivery report.

11. If the MCData data disposition for read was requested by the user at MCData client 1, then once the receiving user reads the data, the receiving MCData client 2 initiates a MCData data disposition notification for read report.

NOTE 3: On receiving MCData group standalone data request over MBMS, the receiving MCData client(s) shall check if the MCData ID list IE is included the receiving MCData client shall check if its own MCData ID is in the list. If not, step 6 and 7 are not required.

12. The MCData data disposition notification(s) from MCData client may be stored by the MCData server for disposition history interrogation from authorized MCData users. The MCData data disposition notification(s) from each MCData user may be aggregated.

13. Aggregated or individual MCData data disposition notification(s) is sent to the disposition requesting user at MCData client 1.

7.4.2.7 Group short data service session

7.4.2.7.1 General

The initiation of a group SDS to a selected group results in affiliated group members exchanging SDS data.

7.4.2.7.2 Procedure

The procedure in figure 7.4.2.7.2-1 describes the case where an MCData user is initiating SDS data communication session with an MCData group for exchanging SDS data transactions between the group participants, with or without disposition request, using MCData-SDS-1 and MCData-SDS-2 reference points.

Pre-conditions:

1. MCData users on MCData client 1 to n belong to the same group and are already registered for receiving MCData service and affiliated.

2. Optionally, the MCData client may have activated functional alias to be used.

3. The MCData server may have subscribed to the MCData functional alias controlling server within the MC system for functional alias activation/de-activation updates.

Figure 7.4.2.7.2-1: Group SDS session

1. User at MCData client 1 would like to initiate a SDS group data transfer request to multiple MCData users selecting a pre-configured group (identified by MCData group ID) and optionally particular members from that group.

2. MCData client 1 sends a MCData group data request towards the MCData server. The MCData group data request contains MCData group ID as selected by the user at MCData client 1. The MCData session data request contains conversation identifier for message thread indication. The MCData group data request may include additional implementation specific information in the application metadata container. MCData user at MCData client 1 may include a functional alias within the SDS data transfer.

i) the MCData group data request shall contain an emergency indicator;

ii) the MCData group data request shall set an alert indicator if configured to send an MCData emergency alert while initiating an MCData standalone data request for the emergency short data service communication; and

iii) if MCData emergency state is not set already, MCData client 1 sets its MCData emergency state. The MCPTT emergency state of MCData client 1 is retained until explicitly cancelled by the user of MCData client 1.

NOTE 1: While MCData client 1 is in the emergency state, all types of MCData one-to-one and group communications initiated by MCData client 1 are initiated as MCData emergency communications.

If the MCData user at MCData client 1 initiates an MCData imminent peril short data service communication:

i) the MCData group data request shall contain an imminent peril indicator.

2a. If either emergency indicator or imminent peril indicator is present in received MCData group data request, the MCData server implicitly affiliates MCData client 1 to the MCData group if the client is not already affiliated.

3. MCData server checks whether the MCData user at MCData client 1 is authorized to send MCData group data request. The MCData server resolves the MCData group ID to determine the members of that group and their affiliation status, based on the information from the group management server. The MCData server also checks whether any policy is to be asserted to limit certain types of message or content to certain members due, for example, to location or user privilege. MCData server also verifies whether the provided functional alias, if present, can be used and has been activated for the user.

i) if an emergency indicator is present in the received MCData group data request and if MCData group is not in in-progress emergency state, the MCData group is considered to be in the in-progress emergency state until cancelled;

NOTE 2: While the MCData group is in the in-progress emergency state, all types of MCData communications within the group are processed as emergency group communications by the MCData server. MCData group members that are not in the emergency state do not indicate emergency in group communication requests.

ii) if an imminent peril indicator is present in the received MCData group data request and if the MCData group is not in the in-progress imminent peril, the MCData group is considered to be in the in-progress imminent peril state until cancelled;

3a. The MCData server configures the priority of the underlying bearers for all participants in the MCData group.

4. MCData server initiates the MCData group data request towards each MCData user determined in Step 3. The MCData group data request towards each MCData client contains:

i) an emergency indicator if it is present in the received MCData group data request from the MCData client 1;

ii) an imminent peril indicator if it is present in the received MCData group data request from the MCData client 1; and

iii) an alert indicator if requested to initiate an emergency alert in the received MCData group data request from MCData client 1;

5. The receiving MCData clients 2 to n optionally notify the user about the incoming MCData session data request.

6. The receiving MCData client 2 to n accept or reject the MCData group data request and the corresponding result is in the MCData group data response towards MCData server.

7. MCData server forwards the MCData group data response received from MCData client 2 to n to the MCData user initiating the MCData session data request.

NOTE 3: Step 7 can occur at any time following step 4, and prior to step 8 depending on the conditions to proceed with the data transmission.

8. MCData client 1 and the MCData group data request accepted clients have successfully established media plane for data communication and either MCData client can transmit SDS data. The MCData data request may contain disposition request if indicated by the client sending data. If the payload is for MCData user consumption (e.g. is not application data, is not command instructions, etc.) then the SDS data receiving MCData users may be notified, otherwise those MCData users shall not be notified.

9. If MCData data disposition was requested by the user, then the SDS data receiving MCData client initiates a MCData data disposition notification for delivery, read reports to the disposition requesting user. The MCData data disposition notification from the receiving MCData clients may be stored by the MCData server for disposition history interrogation from authorized users.

10. Based on the MCData user action or conditions to release, the established media plane for SDS data exchange is released.

7.4.2.8 One-to-one SDS communication upgrade to an emergency one-to-one SDS communication

7.4.2.8.1 General

This clause is for adding procedures related to upgrading an existing MCData one-to-one SDS communication to an MCData emergency one-to-one SDS communication.

7.4.2.8.2 Procedure

The procedure in figure 7.4.2.8.2-1 describes the case where an authorized MCData user is upgrading an ongoing MCData one-to-one SDS communication to an MCData emergency one-to-one SDS communication. This procedure is applicable only when MCData one-to-one SDS communication is established as described in subclause 7.4.2.3 "One-to-one standalone short data service using media plane" or as described in subclause 7.4.2.4 "One-to-one short data service session".

Pre-conditions:

1. Both members of the MCData one-to-one SDS communication belong to the same MCData system.

2. MCdata one-to-one SDS communication is already in progress.

Figure 7.4.2.8.2-1 MCData one-to-one SDS communication upgraded to MCData emergency one-to-one SDS communication

1. The MCData user at MCData client 1 initiates an emergency. MCData client 1 sets its MCData emergency state. The MCData emergency state of MCData client 1 is retained until explicitly cancelled by the user of MCData client 1.

NOTE 1: While MCData client 1 is in the emergency state, all types of MCData one-to-one and group communications initiated by MCData client 1 are initiated as MCData emergency communications.

2. MCData client 1 requests the MCData server to upgrade the one-to-one MCData SDS communication to in-progress emergency by sending a MCData one-to-one SDS communication upgrade request.

3. The MCData server sends the MCData one-to-one SDS communication upgrade request towards MCData client 2, the MCData client of the other participant.

NOTE 2: MCData client 2 does not set its emergency state as a result of receiving the MCData one-to-one SDS communication upgrade request containing the emergency indicator.

4. The MCData user is notified of the in-progress emergency of the MCData emergency one-to-one SDS communication.

5. The receiving MCData client acknowledges the MCData one-to-one SDS communication upgrade request and sends MCData one-to-one SDS communication upgrade response to the MCData server.

6. The MCData server adjusts the priority of the underlying bearer for both participants of the MCData one-to-one SDS communication. The priority is retained until the communication session ends.

7. The MCData server sends MCData one-to-one SDS communication upgrade response to MCData client 1.

8. MCData client 1 and MCData client 2 continue with the MCData one-to-one SDS communication, which has been transformed into an MCData emergency one-to-one SDS communication.

7.4.2.9 Group SDS communication upgrade to a group emergency SDS communication

7.4.2.9.1 General

This clause is for adding procedures related to upgrading an existing MCData group SDS communication to an MCData emergency group SDS communication.

7.4.2.9.2 Procedure

The procedure in figure 7.4.2.9.2-1 describes the case where an authorized MCData user is upgrading an ongoing MCData group SDS communication to an MCData emergency group SDS communication. This procedure is applicable only when group MCData communication is established as described in subclause 7.4.2.6 "Group standalone short data service using media plane" or as described in subclause 7.4.2.7 "Group short data service session".

NOTE 1: For simplicity, a single MCData server is shown in place of a user home MCData server and a group hosting MCData server.

Pre-conditions:

1. The MCData group is previously defined on the group management server with MCData client 1, MCData client 2 and MCData client 3 affiliated to that MCData group.

2. All members of the MCData group belong to the same MCData system.

3. MCData group SDS communication is already in progress.

4. The initiating MCData client 1 has been configured to send an MCData emergency alert when upgrading an MCData emergency group communication.

Figure 7.4.2.9.2-1: MCData group SDS communication upgraded to MCData emergency group SDS communication

1. The MCData user at MCData client 1 initiates a group emergency. MCData client 1 sets its MCData emergency state. The MCData emergency state of MCData client 1 is retained until explicitly cancelled by the user of MCData client 1.

NOTE 2: While MCData client 1 is in the emergency state, all types of MCData one-to-one and group communications initiated by MCData client 1 are initiated as MCData emergency communications.

2. MCData client 1 requests the MCData server to upgrade the MCData group to an in-progress emergency state by sending a MCData group SDS communication upgrade request. The MCData client 1 sets the emergency indicator in the request. If configured to send an MCData alert when initiating an MCData emergency group SDS upgrade, the request also contains an indication that an MCData alert is to be initiated.

3. The MCData server sets the emergency state of the MCData group and adjusts the priority of the underlying bearer for all or selected participants in the MCData group SDS communication that receive the communication over unicast.

NOTE 3: The determination of the selected participants whose bearers have to be upgraded is left to implementation.

NOTE 4: While the MCData group is in the in-progress emergency state, all types of MCData communications within the group are processed as emergency group communications by the MCData server. MCData group members that are not in the emergency state do not indicate emergency in group communication requests.

4. MCData server sends the MCData group SDS communication upgrade request towards the MCData clients of each of those affiliated MCData group members. The request contains an indication of an MCData emergency alert if the request from the originator indicated MCData emergency alert.

5. MCData users are notified of the in-progress emergency state of the MCData group.

6. The receiving MCData clients send the MCData group SDS communication upgrade response to the MCData server to acknowledge the MCData group emergency request. For a multicast call, these acknowledgements are not sent.

7. The MCData server sends the MCData group SDS communication upgrade response to the MCData user 1 to confirm the upgrade request.

NOTE 5: Step 7 can occur at any time following step 3, depending on the conditions to proceed with the call.

MCData client 1, MCData client 2 and MCData client 3 continue with the MCData group SDS communication, which has been transformed into an MCData emergency group SDS communication.

7.4.2.10 Group SDS communication in-progress emergency group state cancel

7.4.2.10.1 General

This clause describes procedures related to MCData in-progress emergency group state cancel. The emergency state of the group can also be cancelled by the group FD in-progress emergency state cancellation procedure in subclause 7.5.2.13.2, or by the emergency alert cancellation procedure specified in 3GPP TS 23.280 [16], subclause 10.10.1.2.2.2.

7.4.2.10.2 Procedure

The procedure in figure 7.4.2.10.2-1 describes the case where an authorized MCData user cancels MCData group’s in-progress emergency.

Pre-conditions:

1. The MCData group is previously defined on the group management server with MCData client 1, MCData client 2 and MCData client 3 affiliated to that MCData group.

2. All members of the MCData group belong to the same MCData system.

3. MCData group members have been notified about the in-progress emergency.

4. The MCData group is in the in-progress emergency state and has prioritized bearer support.

5. MCData client 1 previously initiated the in-progress emergency for the group.

Figure 7.4.2.10.2-1: MCData group SDS in-progress emergency group state cancel

1. The user at the MCData client 1 initiates an MCData group SDS in-progress emergency group state cancel.

NOTE 1: An MCData user authorized to cancel in-progress emergencies on the MCData group can also be authorised to cancel the MCData emergency alert in addition to the initiator. However, only the initiator can cancel the initiator’s local MCData emergency state.

2. The MCData client 1 sends an MCData group SDS communication in-progress priority state cancel request to the MCData server. The MCData client 1 also resets the emergency indicator in the request to inform MCData server about cancellation of in-progress emergency group state.

NOTE 2: If an MCData emergency alert relating to MCData client 1 is in effect together with an MCData in-progress emergency group state on the MCData group, the MCData emergency alert of MCData client 1 can be cancelled at the same time. In that case, the MCData group SDS in-progress priority group state cancel request carries an indication that the emergency alert of MCData client 1 is also being cancelled.

NOTE 3: If an MCData group SDS communication in-progress priority state cancel request is received by the MCData server while a group member that is in the emergency state is transmitting, the MCData group SDS communication in-progress priority state cancel request is rejected by the MCData server.

3. The MCData server adjusts the priority of the underlying bearer; priority treatment is no longer required. The MCData server cancels/resets the emergency in-progress state of the MCData group.

4. The MCData server sends an MCData group SDS in-progress priority state cancel request to the MCData group members.

5. MCData group members are notified of the MCData group SDS in-progress emergency state cancel.

6. The receiving MCData clients send the MCData group SDS in-progress priority state cancel response to the MCData server to acknowledge the MCData in-progress emergency group state cancel. For a multicast call scenario, these acknowledgements are not sent.

7. The MCData server sends the MCData group SDS in-progress priority state cancel response to the MCData user 1 to confirm the MCData in-progress emergency group state cancel. If the MCData in-progress emergency group state cancel request (in step 2) contained the "Alert indicator" IE, the MCData client 1 resets its local emergency status.

NOTE 4: Step 7 can occur at any time following step 3, depending on the conditions to proceed with the call.

7.4.2.11 Group SDS communication upgrade to an imminent peril group SDS communication

7.4.2.11.1 General

This clause is for adding procedures related to upgrade to an imminent peril group SDS communication.

7.4.2.11.2 Procedure

This procedure is applicable only when group MCData SDS communication is established as described in subclause 7.4.2.6 "Group standalone short data service using media plane" or as described in subclause 7.4.2.7 "Group short data service session". The MCData service shall support the procedures and related information flows as specified in subclause 7.4.2.9 "Group SDS communication upgrade to a group SDS emergency communication" with the following clarifications:

– In step 2), the MCData client 1 sets the imminent peril indicator;

– In step 3), the bearers’ priority is adjusted as necessary, to correspond to an imminent peril priority which could be different than the setting used in the procedure in subclause 7.4.2.9; and

– In step 5), MCData users are notified of the in-progress imminent peril state of the MCData group.

7.4.2.12 Group SDS communication in-progress imminent peril group state cancel

7.4.2.12.1 General

This clause is for adding procedures related to group SDS communication in-progress imminent peril group state cancel.

7.4.2.12.2 Procedure

The MCData service shall support the procedures and related information flows as specified in subclause 7.4.2.10 "Group SDS communication in-progress emergency group state cancel" with the following clarifications:

– In step 2), the MCData client 1 sets imminent peril indicator; and

– In step 5), MCData users are notified of the group SDS communication in-progress imminent peril state cancel.

7.4.2.13 Providing data for a user entering an ongoing MCData group conversation

7.4.2.13.1 General

The MCData service shall support mechanisms that allow a MCData user be presented with the whole content of a group conversation in a group that he is a member of. This includes the content (messages) exchanged before the MCData user joins the group conversation.

7.4.2.13.2 Procedure

Figure 7.4.2.13.2-1 describes procedures for a MCData user joining late a group conversation.

Pre-conditions:

1. The MCData group is provisioned for lossless communication.

2. All members of the MCData group have an account created in the MCData message store.

3. MCData client 1, MCData client 2 and MCData client 3 are members of the same MCData group,

4. MCData client 1 and 2 are served by MCData server 1 and have registered and affiliated to the MCData group.

5. MCData client 3 is served by MCData server 2 and has not affiliated to the MCData group yet.

NOTE 1: The interactions of MCData client 1 and MCData client 2 to MCData message store are not shown in the figure.

Figure 7.4.2.13.2-1: Providing data for a user entering an ongoing MCData group conversation

1. A group conversation is initiated according to procedures in subclause 7.4.2.6, and all members of the group are invited into the communication whether affiliated or not. As MCData user 3 is not affiliated at this time, MCData server 2 accepts the invitation to the group conversation on behalf of MCData user 3.

2. The media plane is established for the group conversation. MCData server 2 is in the media plane to receive the conversation on behalf of MCData user 3.

3. MCData server 2 stores the received conversation to MCData user 3 account in the MCData message store.

NOTE 2: If the received conversation requests delivery notification the MCData server 2 will send message delivered to the message sender. If the received conversation requests read notification the MCData client 3 will send message read to the message sender once it has presented the message to the user.

4. MCData user 3 is online and using MCData client 3 to affiliate to the MCData group.

5. MCData client 3, through the message store client, synchronizes with the MCData user 3 account in the MCData message store.

6. MCData server 2 invites MCData client 3 to the MCData group conversation.

7. MCData user 3 joins the MCData group conversation.