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

Top   Top   Up   Prev   Next
1…   5…   6…   6.6…   7…   7.4…   7.4.2.1.10…   7.4.2.2…   7.4.2.5…   7.4.2.8…   7.4.3…   7.5…   7.5.2.1.12…   7.5.2.2…   7.5.2.4…   7.5.2.6…   7.5.2.8…   7.5.2.11…   7.5.2.14…   7.5.3…   7.6   7.7…   7.7.2.1.13…   7.7.2.2…   7.8…   7.9…   7.13…   7.13.3.1.19…   7.13.3.2…   7.13.3.8…   7.13.3.16…   7.13.4…   7.14…   7.14.2.2…   7.17…   7.17.2.13…   7.17.3…   7.17.3.1.4…   7.17.3.2…   7.17.3.2.4…   7.17.3.2.6…   7.17.4…   7.17.6…   7.17.7…   A…   B… 
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.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