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.4 One-to-one file distribution using HTTP  7.5.2.4.1 General  7.5.2.4.2 Procedure for single MCData system  7.5.2.4.3 Procedure with interconnection between MCData systems  7.5.2.5 One-to-one file distribution using media plane  7.5.2.5.1 General  7.5.2.5.2 Procedure 
...

 

7.5.2.4  One-to-one file distribution using HTTP  p. 116

7.5.2.4.1  General  p. 116
The MCData client uses HTTP file distribution to download a file that is uploaded by another MCData client. The procedure is appropriate for both mandatory and non-mandatory download cases. The target MCData user may be addressed using the functional alias that can be shared with other MCData users.
7.5.2.4.2  Procedure for single MCData system  p. 116
The procedure in Figure 7.5.2.4.2-1 describes the case where a MCData user is initiating one-to-one data communication for sending file to the other MCData user, with or without download completed report request.
Pre-conditions:
  1. The MCData users on the MCData client 1 and the MCData client 2 are already registered for receiving MCData service.
  2. The file to be distributed is uploaded to media storage function on MCData content server using the procedures defined in subclause 7.5.2.2.
  3. The MCData client may have 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.4.2-1: One-to-one file distribution using HTTP
Figure 7.5.2.4.2-1: One-to-one file distribution using HTTP
Up
Step 1.
The user at the MCData client 1 initiates a file distribution request to the chosen MCData user.
Step 2.
The MCData client 1 sends a MCData 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 FD request contains one MCData user for one-to-one data communication as selected by the user at MCData client 1. The MCData FD request contains conversation identifier for message thread indication. The MCData 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 FD request contains mandatory download indication. 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. The MCData FD request may contain 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 and may address the target MCData client 2 using a functional alias.
  1. If the MCData user at the MCData client 1 initiates an MCData emergency file distribution using HTTP or MCData emergency state is already set for the MCData client 1 (due to previously triggered MCData emergency alert):
    1. The MCData FD request shall contain emergency indicator; and
    2. If 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.
Step 3.
MCData server checks whether the MCData user at MCData client 1 is authorized to send MCData FD request and that the size of the file is below maximum data size for FD from the service configuration. MCData server verifies whether the provided functional alias of MCData client 1, if present, can be used and has been activated for the user. If functional alias is used to address that target MCData user, the MCData server resolves the functional alias to the corresponding MCData IDs for which the functional alias is active and proceed with step 4 otherwise proceed with step 6.
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 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 corresponding 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.
Step 5.
The MCData server responds back to MCData client 1 with a functional alias resolution response message that contains the resolved MCData ID.
Step 6.
If the MCData server replies with a MCData functional alias resolution response message, the MCData client 1 assumes the MCData FD request in step 2 is rejected and sends a new MCData FD request towards the resolved MCData ID.
Step 7.
MCData server initiates the MCData FD request towards MCData client 2. The MCData FD request towards the MCData user contains an emergency indicator if it is present in the received MCData FD request from MCData client 1. 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 8.
The receiving MCData client 2 notifies the user about the incoming MCData FD request (including file metadata, if present) which may be either accepted or rejected or ignored.
Step 9.
The MCData user 2 may provide a response (accept or reject) or not (ignore) to the notification, then MCData client 2 sends the MCData FD response to the MCData server. The MCData client 2 automatically sends an accepted MCData FD response when the received request includes a mandatory download indication.
Step 10.
The MCData server forwards the MCData FD response to the MCData client 1.
Step 11.
The Media storage client on the MCData client 2 downloads the file from the MCData content server using the procedures defined in subclause 7.5.2.3, either automatically (for mandatory download) or based upon the MCData user 2 subsequent action. The MCData client 2 records file download completed and notifies the MCData user 2.
Step 12.
The MCData client 2 provides an MCData download completed report for reporting file download completed, if requested by the user at MCData client 1.
Step 13.
The received MCData file download completed report from the MCData client 2 may be stored by the MCData server for download history interrogation from authorized MCData users. The MCData download completed report is sent by the MCData server to the MCData user at MCData client 1, if requested by the MCData client 1.
Up
7.5.2.4.3  Procedure with interconnection between MCData systems |R16|  p. 118
The procedure in Figure 7.5.2.4.3-1 describes the case where a MCData user initiates a one-to-one data communication for sending a file to another MCData user where that other MCData user is receiving MCData service on a partner MCData system, and where interconnection is in use between the two MCData systems. In this procedure, the file has not previously been downloaded in the partner MC system.
Pre-conditions:
  1. The MCData users on the MCData client 1 and the MCData client 2 are already service authorized and receiving MCData service. MCData client 1 is receiving service on its primary MCData system, and MCData client 2 is receiving MCData service in the partner MCData system of MCData client 1.
  2. The file to be distributed has been uploaded to the media storage function on the MCData content server in the primary MCData system of MCData client 1 using the procedures defined in subclause 7.5.2.2.
  3. There is a service agreement between the primary and partner MCData systems to allow files to be shared between MCData content servers in the two systems.
  4. The MCData client may have an activated functional alias to be used.
  5. 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.5.2.4.3-1: One-to-one file distribution using HTTP with interconnection
Figure 7.5.2.4.3-1: One-to-one file distribution using HTTP with interconnection
Up
Step 1.
The user at the MCData client 1 initiates a file distribution request to the MCData user at MCData client 2.
Step 2.
MCData client 1 sends an MCData FD request towards the primary MCData server. The MCData FD request contains content payload in the form of a file URL with the necessary access authorization information and may contain the file metadata information. The MCData FD request indicates the target MCData user for the one-to-one data communication. The MCData FD request contains a conversation identifier for message thread indication. If the MCData user at MCData client 1 has requested to mandatory download at the recipient side, then the MCData FD request contains the mandatory download indication. The MCData FD request may contain a request for 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 and may address the target MCData client 2 using a functional alias.
Step 3.
MCData server checks whether the MCData user at MCData client 1 is authorized to send the MCData FD request and that the size of the file is below maximum data size for FD from the service configuration. MCData server verifies whether the provided functional alias of MCData client 1, if present, can be used and has been activated for the user.
Step 4.
The MCData server may verify whether the corresponding file is available in the MCData content server via the MCData-FD-5 reference point using the received file URL in the MCData 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 corresponding 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.
Step 5.
The MCData server in the primary MCData system initiates the MCData FD request towards the MCData server in the partner MCData system, which contains the URL of the file which is stored in the primary MCData content server. The request includes the necessary access authorization information as MCData client 2 will retrieve the file while receiving service in the partner MCData system.
Step 6.
If functional alias is used to address that target MCData user, the MCData server in the partner MCData system resolves the MCData IDs of the functional alias. The resulting list contains all associated MCData IDs/MCData users that may share this functional alias. The MCData server in the partner MCData system now checks which MCData users have FD capabilities and which are authorized to receive a file. The partner MCData server sends the MCData FD request to the MCData users determined. The file URL being provided in MCData FD request to the MCData users determined is prepended with server URI of the partner MCData content server, such that the URL identifies a file location in the partner MCData content server.
Step 7.
The receiving MCData client 2 may notify the user about the incoming MCData FD request (including file metadata, if present) which may be either accepted, rejected or ignored.
Step 8.
The MCData user 2 may provide a response (accept or reject) or not (ignore) to the notification, then the MCData client 2 sends the MCData FD response to the partner MCData server. The MCData client 2 automatically sends an accepted MCData FD response when the received request includes a mandatory download indication
Step 9.
The partner MCData server forwards the MCData FD response to the MCData server in the primary MCData system.
Step 10.
The primary MCData server forwards the MCData FD response to MCData client 1.
Step 11.
MCData client 2 requests the file from the partner MCData content server.
Step 12.
The partner MCData content server checks whether the file is stored locally, and if this is not the case, sends an MCData file retrieve request to the primary MCData content server. The MCData file retrieve request contains the URL of the file location in the primary MCData system, generated by removing the prepended local path from the requested URL.
Step 13.
The primary MCData content server responds to the partner MCData content server with an MCData file retrieve response which contains the content of the file to be retrieved. File metadata may include the lifetime of the file. The primary MCData content server records that the file has been sent to the indicated partner MCData system.
Step 14.
The partner MCData content server sends the file to MCData client 2 in the MCData download data response. MCData client 2 records file download completed and notifies MCData user 2.
Step 15.
The MCData client 2 provides an MCData download completed report for reporting file download completed, if this was requested by the user at MCData client 1 in the initial MCData FD request.
Step 16.
The MCData download completed report is sent to the primary MCData server. The partner MCData server may store the download completed report for download history interrogation from authorized MCData users in the partner MCData system.
Step 17.
The received MCData download completed report is sent by the primary MCData server to the MCData user at MCData client 1, if requested by the MCData client 1. The MCData file download completed report from the MCData client 2 may be stored by the primary MCData server for download history interrogation from authorized MCData users in the primary MCData system.
Up

7.5.2.5  One-to-one file distribution using media plane  p. 121

7.5.2.5.1  General  p. 121
The MCData client uses the media plane for a standalone data file download from another MCData client. The procedure is appropriate for both mandatory and non-mandatory download cases. The target MCData user may be addressed using the functional alias that can be shared with other MCData users.
7.5.2.5.2  Procedure  p. 121
The procedure in Figure 7.5.2.5.2-1 describes the case where an MCData user is initiating one-to-one data communication for sending file to the other MCData user, with or without download completed report request.
Pre-conditions:
  1. The MCData users on the MCData client 1 and the MCData client 2 are already registered for receiving MCData service.
  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.5.2-1: One-to-one file distribution using media plane
Figure 7.5.2.5.2-1: One-to-one file distribution using media plane
Up
Step 1.
The user at the MCData client 1 initiates a file distribution request to the chosen MCData user.
Step 2.
MCData client 1 sends a MCData FD request towards the MCData server. File metadata information is included in the SDP. The MCData FD request contains one MCData user for one-to-one data communication as selected by the user at MCData client 1. The MCData FD request contains conversation identifier for message thread indication. The MCData FD request may include additional implementation specific information in the application metadata container. MCData FD request may contain mandatory download indication. The MCData 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 and may address the target MCData client 2 using a functional alias.
  1. If the MCData user at the MCData client 1 initiates an MCData emergency file distribution communication or MCData emergency state is already set for the MCData client 1 (due to previously triggered MCData emergency alert):
    1. The MCData FD request shall contain emergency indicator; and
    2. If 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.
Step 3.
MCData server checks whether the MCData user at MCData client 1 is authorized to send MCData FD request. MCData server verifies whether the provided functional alias of MCData client 1, if present, can be used and has been activated for the user. If functional alias is used to address that target MCData user, the MCData server resolves the functional alias to the corresponding MCData ID(s) for which the functional alias is active and proceed with step 4 otherwise proceed with step 6.
Step 4.
The MCData server responds back to MCData client 1 with a functional alias resolution response message that contains the resolved MCData ID.
Step 5.
If the MCData server replies with a MCData functional alias resolution response message, the MCData client 1 assumes the MCData FD request in step 2 is rejected and sends a new MCData FD request towards the resolved MCData ID.
Step 6.
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 7.
MCData server initiates the MCData FD request towards the MCData users determined. The MCData FD request towards the MCData user contains the emergency indicator if it is present in the received MCData FD request from MCData client 1.
Step 8.
The receiving MCData client 2 notifies the user about the incoming MCData FD request which may be either accepted or rejected or ignored. If the request includes mandatory download indication in the MCData FD request an accepted response is assumed.
Step 9.
If the target MCData user 2 provides a response (accept or reject) to the notification, then MCData client 2 sends the MCData FD response to the MCData server. MCData client 2 automatically sends accepted MCData FD response when the incoming request included mandatory download indication.
Step 10.
MCData server forwards the MCData FD response from MCData client 2 back to MCData client 1.
Step 11.
MCData client 1 distributes the file over the established media plane to MCData server.
Step 12.
MCData server distributes the file received from MCData client 1 to MCData client 2 over the established media plane. File download report is shared by the MCData client 2, if requested by the user at MCData client 1. After file transaction is completed, the media plane is released. The MCData client 2 records file download completed and notifies MCData user 2.
Step 13.
MCData client 2 initiates a MCData download completed report for reporting file download completed, if requested by the user at MCData client 1.
Step 14.
The MCData file download completed report from MCData client may be stored by the MCData server for download history interrogation from the authorized MCData users. MCData download completed report is sent by the MCData server to the user at MCData client 1.
Up

Up   Top   ToC