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.5.2.10 Group standalone file distribution using the MBMS download delivery method  7.5.2.11 One-to-one FD communication upgrade to an emergency FD communication  7.5.2.12 Group FD communication upgrade to an emergency group FD communication  7.5.2.13 Group FD communication in-progress emergency group state cancel  7.5.2.14 Group FD communication upgrade to an imminent peril group FD communication  7.5.2.15 Group FD communication in-progress imminent peril group state cancel 
...

 

7.5.2.10  Group standalone file distribution using the MBMS download delivery method |R16|  p. 131

7.5.2.10.1  General  p. 131
The initiation of a group standalone FD to a selected group results in affiliated group members receiving the file data over MBMS.
The first steps of the procedure are identical to the procedure Group standalone file distribution using HTTP (7.5.2.6). Based on the density and distribution of target group members, the MCData server may decide to deliver the file over MBMS.
The MBMS download delivery method is described in clause 7 of TS 26.346.
Up
7.5.2.10.2  Procedure  p. 131
The procedure in Figure 7.5.2.10.2-1 describes the case where a MCData user is initiating group standalone data communication for sending a file to multiple MCData users, with or without download completed report request.
Pre-conditions:
  1. The MCData users on the MCData client 1 to n belong to the same group and are already registered for receiving MCData service and affiliated.
  2. The file to be distributed is uploaded to the media storage function on the MCData content server using the procedure defined in subclause 7.5.2.2.
Reproduction of 3GPP TS 23.282, Fig. 7.5.2.10.2-1: Group standalone FD using the MBMS download delivery method
Figure 7.5.2.10.2-1: Group standalone FD using the MBMS download delivery method
Up
Step 1-3.
Steps 1-3 are the same as in the procedure for Group standalone FD using HTTP (clause 7.5.2.6).
Step 4.
The MCData server executes the procedure described in subclause 7.3.5. The MCData server defines, in the MBMS session properties (subclause 5.4 of TS 26.348), the ingest mode to provide the file into the BM-SC via xMB-U. As described in clause 7.3.5.3.3, the MCData server decides how the file stored in the MCData content server is provided for distribution over the MBMS session.
If the pull ingest mode is defined, the MCData server may provide in this step the file list. As described in TS 26.348, the file list includes, among other information, the file URL to be used by the BM-SC to fetch the file and the earliest fetch time. The earliest fetch time may be configured with a long enough delay so that the MBMS session is established and steps 6 to 8 are executed before the delivery over MBMS. The MCData server can also update the MBMS session with the file list in a later step.
If the push ingest mode is defined, the MCData server obtains the URL from the BM-SC to be used to push the file via xMB-U. The MCData server ingests the content into the BM-SC after the MBMS session is established and steps 6 to 8 are performed.
Step 5.
The MCData server initiates the MCData group standalone FD over MBMS request towards each MCData user determined in step 3. The request is sent over unicast or within an MBMS bearer for application level control signalling.
Step 6.
The receiving MCData clients 2 to n notify the users about the incoming MCData group standalone FD request (including file metadata, if present).
Step 7.
The MCData clients 2 to n automatically send accepted MCData group standalone FD response when the incoming request included mandatory download indication.
Step 8.
The MCData server forwards the MCData group standalone FD responses to the MCData client 1.
Step 9.
The MCData clients receive the file delivered over MBMS.
Step 10.
If losses occurred during the file delivery over MBMS, the MCData clients may download the missing parts using the procedures defined in subclause 7.5.2.3.
Step 11.
The MCData clients, after reception, initiate MCData download completed reports for reporting file download completed, if requested by the user at MCData client 1.
Step 12.
The MCData file download completed reports from the MCData clients may be stored by the MCData server for download history interrogation from authorized MCData users. The MCData file download completed report from each MCData user may be aggregated.
Step 13.
Aggregated or individual MCData download completed reports are sent by the MCData server to the MCData user at MCData client 1.
Up

7.5.2.11  One-to-one FD communication upgrade to an emergency FD communication |R16|  p. 132

7.5.2.11.1  General  p. 132
This clause is for adding procedures related to upgrading an existing one-to-one FD communication to an emergency one-to-one FD communication.
7.5.2.11.2  Procedure  p. 133
The procedure in Figure 7.5.2.11.2-1 describes the case where an authorized MCData user is upgrading a MCData one-to-one FD communication to a MCData emergency one-to-one FD communication. This procedure is applicable only when MCData one-to-one file distribution communication is established as described in subclause 7.5.2.5 "One-to-one file distribution using media plane".
Pre-conditions:
  1. Both members of the one-to-one FD communication belong to the same MCData system.
  2. One-to-one FD communication is already in progress.
Reproduction of 3GPP TS 23.282, Fig. 7.5.2.11.2-1: One-to-one FD communication upgrade to an emergency one-to-one FD communication
Figure 7.5.2.11.2-1: One-to-one FD communication upgrade to an emergency one-to-one FD 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 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 one-to-one FD communication to in-progress emergency by sending a MCData one-to-one FD upgrade request.
Step 3.
The MCData server sends the MCData one-to-one FD upgrade request towards MCData client 2.
Step 4.
The MCData user of MCData client 2 is notified of the in-progress emergency of the MCData emergency one-to-one FD communication.
Step 5.
The MCData client 2 acknowledges the MCData one-to-one FD upgrade request and sends MCData one-to-one FD 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 FD communication. The priority is retained until the communication ends.
Step 7.
The MCData server sends MCData one-to-one FD upgrade response to MCData client 1.
Step 8.
MCData client 1 and MCData client 2 continue with the MCData one-to-one FD communication, which has been transformed into an MCData emergency one-to-one FD communication.
Up

7.5.2.12  Group FD communication upgrade to an emergency group FD communication |R16|  p. 134

7.5.2.12.1  General  p. 134
This clause is for adding procedures related to upgrading an existing MCData group FD communication to an MCData emergency group FD communication.
7.5.2.12.2  Procedure  p. 134
The procedure in Figure 7.5.2.12.2-1 describes the case where an authorized MCData user is upgrading an onging MCData group FD communication to an MCData emergency group FD communication. This procedure is applicable only when group MCData FD communication is established as described in subclause 7.5.2.7 "Group standalone file distribution using media plane".
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 are affiliated to that MCData group.
  2. All members of the MCData group belong to the same MCData system.
  3. An MCData group FD 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.5.2.12.2-1: MCData group FD communication upgraded to an MCData emergency group FD communcation
Figure 7.5.2.12.2-1: MCData group FD communication upgraded to an MCData emergency group FD communcation
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 FD 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 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 FD communication that receive the communication over unicast.
Step 4.
MCData server sends the MCData group FD 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 FD 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 FD 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 FD communication, which has been transformed into an MCData emergency group FD communication.
Up

7.5.2.13  Group FD communication in-progress emergency group state cancel |R16|  p. 136

7.5.2.13.1  General  p. 136
This clause describes procedures related to an MCData in-progress emergency group state cancel. The emergency state of the group can also be cancelled by the group SDS in-progress emergency state cancellation procedure in subclause 7.4.2.10.2, or by the emergency alert cancellation procedure specified in subclause 10.10.1.2.2.2 of TS 23.280.
Up
7.5.2.13.2  Procedure  p. 136
The procedure in Figure 7.5.2.13.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.5.2.13.2-1: MCData group FD in-progress emergency group state cancel
Figure 7.5.2.13.2-1: MCData group FD in-progress emergency group state cancel
Up
Step 1.
The user at the MCData client 1 initiates an MCData group FD in-progress emergency group state cancel.
Step 2.
The MCData client 1 sends an MCData group FD in-progress priority state cancel request to the MCData server. The MCData client 1 also resets 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 FD in-progress priority state cancel request to the MCData group members.
Step 5.
MCData group members are notified of the MCData group FD in-progress emergency state cancel.
Step 6.
The receiving MCData clients send the MCData group FD 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 FD 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.5.2.14  Group FD communication upgrade to an imminent peril group FD communication |R16|  p. 138

7.5.2.14.1  General  p. 138
This clause is for adding procedures related to an imminent peril group FD communication.
7.5.2.14.2  Procedure  p. 138
This procedure is applicable only when group MCData communication is established as described in subclause 7.5.2.7 "Group standalone file distribution using media plane". The MCData service shall support the procedures and related information flows as specified in subclause 7.5.2.12 "Group FD communication upgrade to an emergency group FD 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.5.2.12; and
  • In step 5), MCData users are notified of the in-progress imminent peril state of the MCData group.
Up

7.5.2.15  Group FD communication in-progress imminent peril group state cancel |R16|  p. 138

7.5.2.15.1  General  p. 138
This clause is for adding procedures related to an imminent peril group state cancel.
7.5.2.15.2  Procedure  p. 138
The MCData service shall support the procedures and related information flows as specified in subclause 7.5.2.13 "Group FD communication in-progress emergency group state cancel" with the following clarifications:
  • In step 2), the MCData client 1 sets the imminent peril indicator; and
  • In step 5), MCData users are notified of the in-progress imminent peril state cancel.

Up   Top   ToC