Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.282  Word version:  19.4.0

Top   Top   Up   Prev   Next
1…   5…   6…   6.6…   7…   7.4…   7.4.2.7…   7.4.3…   7.5…   7.5.2.5…   7.5.2.10…   7.5.3…   7.6…   7.7…   7.8…   7.9…   7.13…   7.13.3.14…   7.13.4…   7.14…   7.17…   7.17.3.1.4…   7.17.3.2…   7.17.3.2.5…   7.17.4…   7.17.6…   A…   B… 
7.4.2.7 Group short data service session  7.4.2.8 One-to-one SDS communication upgrade to an emergency one-to-one SDS communication  7.4.2.9 Group SDS communication upgrade to a group emergency SDS communication  7.4.2.10 Group SDS communication in-progress emergency group state cancel  7.4.2.11 Group SDS communication upgrade to an imminent peril group SDS communication  7.4.2.12 Group SDS communication in-progress imminent peril group state cancel  7.4.2.13 Providing data for a user entering an ongoing MCData group conversation 
...

 

7.4.2.7  Group short data service session  p. 81

7.4.2.7.1  General  p. 81
The initiation of a group SDS to a selected group results in affiliated group members exchanging SDS data.
7.4.2.7.2  Procedure  p. 81
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.
Reproduction of 3GPP TS 23.282, Fig. 7.4.2.7.2-1: Group SDS session
Figure 7.4.2.7.2-1: Group SDS session
Up
Step 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.
Step 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.
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 data request shall contain an emergency indicator;
  2. 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
  3. 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.
If the MCData user at MCData client 1 initiates an MCData imminent peril short data service communication:
  1. the MCData group data request shall contain an imminent peril indicator.
Step 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.
Step 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.
  1. 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;
  2. 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;
Step 3a.
The MCData server configures the priority of the underlying bearers for all participants in the MCData group.
Step 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:
  1. an emergency indicator if it is present in the received MCData group data request from the MCData client 1;
  2. an imminent peril indicator if it is present in the received MCData group data request from the MCData client 1; and
  3. an alert indicator if requested to initiate an emergency alert in the received MCData group data request from MCData client 1;
Step 5.
The receiving MCData clients 2 to n optionally notify the user about the incoming MCData session data request.
Step 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.
Step 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.
Step 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.
Step 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.
Step 10.
Based on the MCData user action or conditions to release, the established media plane for SDS data exchange is released.
Up

7.4.2.8  One-to-one SDS communication upgrade to an emergency one-to-one SDS communication |R16|  p. 84

7.4.2.8.1  General  p. 84
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  p. 84
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.
Reproduction of 3GPP TS 23.282, Fig. 7.4.2.8.2-1: MCData one-to-one SDS communication upgraded to MCData emergency one-to-one SDS communication
Figure 7.4.2.8.2-1: MCData one-to-one SDS communication upgraded to MCData emergency one-to-one SDS communication
Up
Step 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.
Step 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.
Step 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.
Step 4.
The MCData user is notified of the in-progress emergency of the MCData emergency one-to-one SDS communication.
Step 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.
Step 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.
Step 7.
The MCData server sends MCData one-to-one SDS communication upgrade response to MCData client 1.
Step 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.
Up

7.4.2.9  Group SDS communication upgrade to a group emergency SDS communication |R16|  p. 85

7.4.2.9.1  General  p. 85
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  p. 85
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".
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.
Reproduction of 3GPP TS 23.282, Fig. 7.4.2.9.2-1: MCData group SDS communication upgraded to MCData emergency group SDS communication
Figure 7.4.2.9.2-1: MCData group SDS communication upgraded to MCData emergency group SDS communication
Up
Step 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.
Step 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.
Step 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.
Step 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.
Step 5.
MCData users are notified of the in-progress emergency state of the MCData group.
Step 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.
Step 7.
The MCData server sends the MCData group SDS communication upgrade response to the MCData user 1 to confirm the upgrade request.
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.
Up

7.4.2.10  Group SDS communication in-progress emergency group state cancel |R16|  p. 87

7.4.2.10.1  General  p. 87
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 subclause 10.10.1.2.2.2 of TS 23.280.
Up
7.4.2.10.2  Procedure  p. 87
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.
Reproduction of 3GPP TS 23.282, Fig. 7.4.2.10.2-1: MCData group SDS in-progress emergency group state cancel
Figure 7.4.2.10.2-1: MCData group SDS in-progress emergency group state cancel
Up
Step 1.
The user at the MCData client 1 initiates an MCData group SDS in-progress emergency group state cancel.
Step 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.
Step 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.
Step 4.
The MCData server sends an MCData group SDS in-progress priority state cancel request to the MCData group members.
Step 5.
MCData group members are notified of the MCData group SDS in-progress emergency state cancel.
Step 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.
Step 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.
Up

7.4.2.11  Group SDS communication upgrade to an imminent peril group SDS communication |R16|  p. 89

7.4.2.11.1  General  p. 89
This clause is for adding procedures related to upgrade to an imminent peril group SDS communication.
7.4.2.11.2  Procedure  p. 89
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.
Up

7.4.2.12  Group SDS communication in-progress imminent peril group state cancel |R16|  p. 89

7.4.2.12.1  General  p. 89
This clause is for adding procedures related to group SDS communication in-progress imminent peril group state cancel.
7.4.2.12.2  Procedure  p. 89
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 |R17|  p. 89

7.4.2.13.1  General  p. 89
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  p. 89
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.
Reproduction of 3GPP TS 23.282, Fig. 7.4.2.13.2-1: Providing data for a user entering an ongoing MCData group conversation
Figure 7.4.2.13.2-1: Providing data for a user entering an ongoing MCData group conversation
Up
Step 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.
Step 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.
Step 3.
MCData server 2 stores the received conversation to MCData user 3 account in the MCData message store.
Step 4.
MCData user 3 is online and using MCData client 3 to affiliate to the MCData group.
Step 5.
MCData client 3, through the message store client, synchronizes with the MCData user 3 account in the MCData message store.
Step 6.
MCData server 2 invites MCData client 3 to the MCData group conversation.
Step 7.
MCData user 3 joins the MCData group conversation.
Up

Up   Top   ToC