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.1.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…   A…   B… 
7.5.2.6 Group standalone file distribution using HTTP  7.5.2.6.1 General  7.5.2.6.2 Procedure  7.5.2.7 Group standalone file distribution using media plane  7.5.2.7.1 General  7.5.2.7.2 Procedure 
...

 

7.5.2.6  Group standalone file distribution using HTTP  p. 123

7.5.2.6.1  General  p. 123
The initiation of a group standalone FD using HTTP to a selected group, results in affiliated group members receiving the file data.
7.5.2.6.2  Procedure  p. 123
The procedure in Figure 7.5.2.6.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 from the MCData user.
Pre-conditions:
  1. The MCData users on the MCData clients 1 to n belong to the same MCData group and are already registered for receiving MCData service and affiliated to the group.
  2. The file to be distributed is uploaded to the media storage function on the MCData content server using the procedures defined in subclause 7.5.2.2.
  3. The MCData client may have an activated functional alias to be used.
  4. The MCData server has 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.5.2.6.2-1: Group standalone FD using HTTP
Figure 7.5.2.6.2-1: Group standalone FD using HTTP
Up
Step 1.
The user at the MCData client 1 initiates a file distribution request to multiple MCData users selecting a pre-configured group (identified by MCData group ID) and optionally particular members from that group.
Step 2.
The MCData client 1 sends a MCData group standalone FD request towards the MCData server. The MCData FD request contains content payload in the form of file URL and may contain the file metadata information. The MCData group standalone data request contains either the selected MCData group ID or the target recipients as selected by the user at MCData client 1. The MCData group standalone FD request contains conversation identifier for message thread indication. The MCData group standalone FD request may include additional implementation specific information in the application metadata container. If MCData user at MCData client 1 has requested to mandatory download at the recipient side, then MCData group standalone FD request contains mandatory download indication. The MCData group standalone FD request may contain a download completed report indication if selected by the user at MCData client 1. The MCData user at MCData client 1 may include a functional alias within the FD data transfer. If the MCData user at MCData client has requested to deposit the file content into his/her MCData message store account, then MCData FD request contains deposit file indication set.
If the MCData user at MCData client 1 initiates an MCData emergency FD 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 FD request shall contain an emergency indicator;
  2. the MCData group standalone FD request shall set an alert indicator if configured to send an MCData emergency alert while initiating an MCData group standalone FD request for the emergency FD communication; and
  3. if the 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.
If the MCData user at MCData client 1 initiates an MCData imminent peril FD communication:
  1. the MCData group standalone FD request shall contain an imminent peril indicator.
Step 2a.
If either emergency indicator or imminent peril indicator is present in the received MCData group standalone FD 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 an MCData group standalone FD request and that the size of the file is below maximum data size for FD from the group configuration. MCData server verifies whether the provided functional alias, if present, can be used and has been activated for the user. If the MCData group ID is used, 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.
  1. If an emergency indicator is present in the received MCData group standalone FD 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 FD 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.
Step 4.
The MCData server may verify whether the corresponding file is available in the MCData content server (not shown in the figure) via the MCData-FD-5 reference point using the received file URL in the MCData group standalone FD request. For that, the MCData server sends an MCData file availability request to the MCData content server. Upon the receipt of the request, the MCData content server provides an MCData file availability response to the MCData server. If the MCData server identifies that the file is not available in the MCData content server, the MCData server provides a response to the MCData client 1 indicating that the file distribution request cannot proceed due to the unavailability of the file in the MCData content server and skip rest of the steps. If the deposit file indication information element is set to true in the received MCData FD request, MCData server shall follow the procedure as defined in the subclause 7.13.3.8 with the retrieve file indication element set to true while depositing this MCData communication to the MCData message store account of the user at MCData client 1.
Step 5.
MCData server initiates the MCData group standalone FD request towards each MCData user determined in step 3. The MCData group standalone FD request towards each MCData client contains:
  1. an emergency indicator if it is present in the received MCData group standalone FD request from the MCData client 1;
  2. an imminent peril indicator if it is present in the received MCData group standalone FD request from the MCData client 1; and
  3. an alert indicator if requested to initiate an emergency alert in the received MCData group standalone FD request from the MCData client 1.
Step 6.
The receiving MCData clients 2 to n notify the user about the incoming MCData group standalone FD request (including file metadata, if present) which may be either accepted or rejected or ignored.
Step 7.
If the target MCData user on MCData clients 2 to n provides a response (accept or reject) to the notification, then respective MCData client sends the MCData group standalone FD response to the MCData server. MCData client 2 to n automatically sends 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 media storage client on the MCData client(s) accepting the request downloads the file from the MCData content server (not shown in the figure) using the procedures defined in subclause 7.5.2.3, either automatically (for mandatory download) or based upon the MCData user subsequent action. The MCData clients successfully receiving the file through the media storage clients, record file download completed and notify the MCData users.
Step 10.
The MCData clients, receiving the file through the media storage client, provide MCData download completed reports for reporting file download completed, if requested by the user at MCData client 1.
Step 11.
The MCData file download completed reports from MCData clients may be stored by the MCData server for download history interrogation from the authorized MCData users. The MCData file download completed report from each MCData user may be aggregated.
Step 12.
Aggregated or individual MCData download completed reports are sent by the MCData server to the MCData user at MCData client 1, if requested by the MCData client 1.
Up

7.5.2.7  Group standalone file distribution using media plane  p. 126

7.5.2.7.1  General  p. 126
The initiation of a group standalone FD using media plane to a selected group, results in affiliated group members receiving the file data.
7.5.2.7.2  Procedure  p. 126
The procedure in Figure 7.5.2.7.2-1 describes the case where an MCData user is initiating group standalone data communication for sending 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. Optionally, the MCData client may have an activated functional alias to be used.
  3. The MCData server has 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.5.2.7.2-1: Group standalone FD using media plane
Figure 7.5.2.7.2-1: Group standalone FD using media plane
Up
Step 1.
The user at the MCData client 1 initiates a file distribution 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 standalone FD request towards the MCData server. File metadata information is included in the SDP. The MCData group standalone data request contains target recipient(s) as selected by the user at MCData client 1. The MCData group standalone FD request contains conversation identifier for message thread indication. The MCData group standalone FD request may include additional implementation specific information in the application metadata container. MCData group standalone FD request may contain mandatory download indication. The MCData group standalone FD request may contain download completed report indication if selected by the user at MCData client 1. MCData user at MCData client 1 may include a functional alias within the FD data transfer.
If the MCData user at MCData client 1 initiates an MCData emergency file distribution 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 FD request shall contain an emergency indicator;
  2. the MCData group standalone FD request shall set an alert indicator if configured to send an MCData emergency alert while initiating an MCData group standalone FD request for the emergency file distribution service communication; and
  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.
If the MCData user at MCData client 1 initiates an MCData imminent peril file distribution communication:
  1. the MCData group standalone FD request shall contain an imminent peril indicator.
Step 2a.
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.
Step 3.
MCData server checks whether the MCData user at MCData client 1 is authorized to send MCData group standalone FD request. MCData server verifies whether the provided functional alias, if present, can be used and has been activated for the user. 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.
  1. If an emergency indicator is present in the received MCData group standalone FD 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 FD 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.
Step 4.
The MCData server also applies transmission and reception control and the necessary policy to ensure that appropriate data is transmitted between the MCData UEs.
Step 5.
MCData server initiates the MCData group standalone FD request towards each MCData user determined in step 3. 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 FD request from the MCData client 1;
  2. an imminent peril indicator if it is present in the received MCData group standalone FD request from the MCData client 1; and
  3. an alert indicator if requested to initiate an emergency alert in the received MCData group standalone FD request from the MCData client 1.
Step 6.
The receiving MCData clients 2 to n notifies the user about the incoming MCData group standalone FD request which may be either accepted or rejected or ignored. If the request includes mandatory download indication in the MCData group standalone FD request an accepted response is assumed.
Step 7.
If the target MCData user on MCData clients 2 to n provides a response (accept or reject) to the notification, then the respective MCData client sends the MCData group standalone FD response to the MCData server. MCData client 2 to n automatically sends accepted MCData group standalone FD response when the incoming request included mandatory download indication.
Step 8.
MCData server forwards the MCData group standalone FD response to the MCData client 1.
Step 9.
MCData client 1 and MCData server have successfully established media plane for file transmission and the MCData client 1 transmits the file data.
Step 10.
MCData server distributes the file received from MCData client 1 to MCData clients 2 to n over the established media plane. Distribution of file can be via unicast or via MBMS bearer(s). For distribution via MBMS bearer(s), the procedure described in subclause 7.3 Use of MBMS transmission (on-network) is executed. File download report is shared by the receiving MCData clients, if requested by the user at MCData client 1. After file transaction is completed, the media plane is released.
Step 11.
The MCData clients successfully receiving the file, records file download completed and notifies MCData user.
Step 12.
MCData client 2 initiates a MCData download completed report for reporting file download completed, if requested by the user at MCData client 1.
Step 13.
The MCData file download completed report(s) from MCData client(s) may be stored by the MCData server for download history interrogation from the authorized MCData users. The MCData file download completed report from each MCData user may be aggregated.
Step 14.
Aggregated or individual MCData file download completed report is sent to the disposition requesting user at MCData client 1.
Up

Up   Top   ToC