Content for  TS 23.282  Word version:  19.3.0

The user at MCData client 1 wants to initiate an SDS data transfer to multiple MCData users with/without end-to-end encryption supported, and either by providing the list of MCData users in the request or by providing the certain criteria in the request.

The MCData client 1 sends a Determine ad hoc group request towards the MCData server of the primary MCData system. The Determine ad hoc group request contains either the criteria to be applied by the MCData server of the primary MCData system for determining the list of MCData users or the list of MCData users as selected by the user at MCData client 1. The request may also contain the indicator for data transfer is for emergency, imminent peril and the application identifier for which the data transfer is intended.

If the ad hoc group communication is supported, the MCData server of the primary MCData system checks whether the MCData user at MCData client 1 is authorized to initiate a Determine ad hoc group request. If not authorized, the MCData server rejects the Determine ad hoc group request as specified in the step 9. If the request contains the list of MCData users as selected by the user at MCData client 1, the MCData server of the primary MCData system validates whether the number of MCData users provided in the request are within the configured limit. If not within the configured limit, the MCData server rejects the Determine ad hoc group request as specified in the step 9.

If the request contains the criteria, the MCData server of primary MCData system determines the list of MCData users for ad hoc group standalone short data service from the primary MCData system and determines the partner MCData system to be involved in the ad hoc group standalone short data service based on the criteria and according to local policy if required. This information element to determine the ad hoc group member contains the criteria, indicator identifying pre-defined criteria, or a combination of both.

The MCData server of primary MCData system involves the partner MCData system based on the agreement, based on the criteria for determining the list of MCData users, and according to local policy if required. It sends the ad hoc group standalone data get userlist request to the MCData server of partner MCData system. This request carries the criteria received in the Determine ad hoc group request.

The MCData server of partner MCData system determines the list of MCData users satisfying the criteria and sends the response containing the list of MCData users satisfying the criteria. The MCData server of partner MCData system may apply local policies if any while determining the participants satisfying the criteria. The determination of list of MCData users is performed only once.

The MCData server of primary MCData system compiles the list of MCData users for ad hoc group standalone short data service from primary MCData system and from partner MCData system, if requested.

The MCData server of the primary MCData system forms the ad hoc group by using MCData users' information received in the Determine ad hoc group request and list of MCData users to be part of ad hoc group. The MCData server further determines the preconfigured group to be used for the configuration (e.g. security related information) of the ad hoc group if end-to-end encryption is required. The MCData server selects an MCData ad hoc group ID for the newly formed ad hoc group and optionally assign the time to live value. The ad hoc group members can communicate in the ad hoc group until the time to live value is expired. The MCData server ensure the list of MCData users determined in the step 7 are within the configured limit.

The MCData server of the primary MCData system send the Determine ad hoc group response message to MCData client 1 containing the below:

1. The MCData ad hoc group ID (only included when the Determine ad hoc group request is succesful);
2. The MCData group ID of the pre-configured group whose configuration is to be applied for this Ad hoc group standalone short data service if end-to-end encryption is required (only included when the Determine ad hoc group request is succesful); and
3. Result of whether the Determine ad hoc group request successful or failure.

If the Determine ad hoc group request not authorized or result not succesful, the MCData client 1 shall not proceed with remaining steps for the data transfer as specified in the clause 7.17.6.3 and 7.17.6.4.

The user at MCData client 1 wants initiates an SDS data transfer to ad hoc group members from primary MCData system.

The MCData client 1 shall determine the preconfigured group if end-to-end encryption is required and an ad hoc group by executing the procedures as described in the clause 7.17.6.2.

MCData client 1 sends an Ad hoc group standalone data request towards the MCData server. The request shall contain the MCData ad hoc group ID as determined in the step 2, the conversation identifier for message thread indication, may include additional implementation specific information in the application metadata container, may contain disposition request if indicated by the user at MCData client 1 and may include associated functional alias of the user at MCData client 1. If end-to-end encryption is required, the request shall contain the Preconfigured MCData group ID as determined in the step 2. If the end-to-end encryption is not required then include the payload without encryption and if required then include the payload with encryption based on the Preconfigured MCData group ID as determined in the step 2. If the MCData user at MCData client 1 initiates an emergency ad hoc group standalone short data service or the MCData emergency state is already set for the MCData client 1 (due to a previously triggered MCData emergency alert):

1. the Ad hoc group standalone data request shall contain an emergency indicator;
2. 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
3. once an emergency SDS data transfer has been initiated, the ad hoc group is considered to be in an in-progress emergency state until SDS data transfer is completed and the time to live value of ad hoc group expires.

If the MCData user at MCData client 1 initiates an imminent peril ad hoc group standalone short data service:

1. the Ad hoc group standalone data request shall contain imminent peril indicator; and
2. once an emergency SDS data transfer has been initiated, the ad hoc group is considered to be in an in-progress imminent peril state until SDS data transfer is completed and the time to live value of ad hoc group expires.

If the ad hoc group communication is supported, the MCData server checks whether the MCData user at MCData client 1 is authorized to send Ad hoc group standalone data request. If not authorized, the MCData server rejects the Ad hoc group standalone data request as specified in the step 9. The MCData server checks whether any policy is to be asserted to limit certain types of message or content to certain members, for example, to location or user privilege. The MCData server also verifies whether the provided functional alias can be used and has been activated for the user.

The MCData server considers the the ad hoc group memebers as implicitly affiliated to the ad hoc group.

1. If an emergency indicator is present in the received Ad hoc group standalone data request and if the ad hoc group is not in the in-progress emergency state, the ad hoc group is considered to be in the in-progress emergency state until SDS data transfer is completed and the time to live value of ad hoc group expires; and
2. If an imminent peril indicator is present in the received Ad hoc group standalone data request and if the ad hoc group is not in the in-progress imminent peril state, the ad hoc group is considered to be in the in-progress imminent peril state until SDS data transfer is completed and the time to live value of ad hoc group expires; and

The MCData server initiates a Ad hoc group standalone data request towards each of the target MCData users. While sending the Ad hoc group standalone data request, the MCData server shall remove the information elements that are not required to be conveyed to the target MCData clients (e.g. MCData ID list). The request should contain the ad hoc group ID, pre-configured group if end-to-end encryption is required and time to live value for the ad hoc group. The primary MCData server removes the ad hoc group information from the dynamic data once the time to live value is expired and thus the ad hoc group ceases to exist then the procedure stops.

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 as described in the step 6 to step 9 of clause 7.4.2.5.2.

The user at MCData client 1 of the primary MCData system wants initiates an SDS data transfer to ad hoc group members from primary and partner MCData systems.

Same steps as described in the steps 2 to 5 of clause 7.17.6.3.2.

The MCData server of the primary MCData system initiates an Ad hoc group standalone data request towards each of the target MCData users in the primary MCData system and the partner MCData system. While sending the Ad hoc group standalone data requests, the MCData server of the primary MCData system shall remove the information elements that are not required to be conveyed to the target MCData clients (e.g. MCData ID list). The request should contain the ad hoc group ID, pre-configured group if end-to-end encryption is required and time to live value for the ad hoc group. The primary MCData server removes the ad hoc group information from the dynamic data once the time to live value is expired and thus the ad hoc group ceases to exist then the procedure stops.

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 M and MCData clients 1 to N may be notified. Otherwise if the payload is not for MCData user consumption, then the MCData user of MCData clients 2 to M and MCData clients 1 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 clients 2 to M and MCData clients 1 to N which is addressed to a known local non-MCData application that is not yet running shall cause the clients 2 to M and MCData clients 1 to N 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 of the primary MCData system, then the receiving MCData client(s) initiates a MCData data disposition notification for delivery report as described in the step 6 to step 9 of clause 7.4.2.5.2.