Content for  TS 23.282  Word version:  19.6.0

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

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.

1. 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):
   1. The MCData standalone data request shall contain emergency indicator; and
   2. 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.

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.

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

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.

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.

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.

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.

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

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.

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

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

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.

1. 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):
   1. The MCData standalone session data request shall contain emergency indicator; and
   2. 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.

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.

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

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.

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.

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

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

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

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.

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.

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

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.

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

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

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.

1. 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):
   1. The MCData session data request shall contain emergency indicator; and
   2. 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.

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.

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

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.

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.

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

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

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

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.

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.

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

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.

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):

1. the MCData group standalone data request shall contain an emergency indicator;
2. 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;
3. if the MCData emergency state is not set already, MCData client 1 sets its MCData emergency state. The MCData emergency state is retained until explicitly cancelled; and
4. 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:

1. the MCData group standalone data request shall contain imminent peril indicator; and
2. 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.

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.

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.

1. 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
2. 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.

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:

1. an emergency indicator, if it is present in the received MCData group standalone data request from the MCData client 1;
2. an imminent peril indicator, if it is present in the received MCData group standalone data request from the MCData client 1; and
3. an alert indicator, if requested to initiate an emergency alert in the received MCData group standalone data request from the MCData client 1.

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.

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.

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

Aggregated or individual MCData data disposition notification(s) is sent to the disposition requesting user at MCData client 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.

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):

1. the MCData group session standalone data request shall contain an emergency indicator;
2. 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;
3. if the MCData emergency state is not set already, MCData client 1 sets its MCData emergency state. The MCData emergency state is retained until explicitly cancelled; and
4. 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:

1. the MCData group session standalone data request shall contain an imminent peril indicator; and
2. 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.

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.

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.

1. 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
2. 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.

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

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:

1. an emergency indicator, if it is present in the received MCData group session standalone data request from the MCData client 1;
2. an imminent peril indicator, if it is present in the received MCData group session standalone data request from the MCData client 1; and
3. an alert indicator, if requested to initiate an emergency alert in the received MCData group session standalone data request from MCData client 1.

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.

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

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

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.

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.

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.

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

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