Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑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.8  File removal using HTTP by authorized user |R16|p. 129

7.5.2.8.1  Generalp. 129
The media storage client uses HTTP to remove a file that was previously uploaded to the MCData content server.
7.5.2.8.2  Procedure for single MCData systemp. 129
The procedure in Figure 7.5.2.8.2-1 describes the case where a MCData user is removing the file that was previously uploaded to the MCData content server.
Pre-conditions:
  1. The MCData user on the media storage client is registered for receiving MCData service.
  2. The file has been successfully uploaded by the MCData user using the procedures defined in subclause 7.5.2.2.
  3. The MCData content server has the ability to verify if the requesting MCData user is authorised to remove.
Reproduction of 3GPP TS 23.282, Fig. 7.5.2.8.2-1: File removal using HTTP by authorised user
Up
Step 1.
The user on the media storage client decides to remove a file that was previously uploaded.
Step 2.
The URL of the file to be removed is included in the request sent to the media storage function on the MCData content server.
Step 3.
The MCData content server remove the file indicated by the URL.
Step 4.
The MCData content server informs the media storage client if the file is successfully removed.
7.5.2.8.3  Procedure for interconnection between MCData systemsp. 129
The procedure in Figure 7.5.2.8.3-1 describes the case where an MCData user removes the file that was previously uploaded to the primary MCData system MCData content server, and where the file has been made available in the partner MCData system MCData content server.
Pre-conditions:
  1. The MCData user on the media storage client is registered for receiving MCData service.
  2. The file has previously been uploaded to the MCData content server in the primary MCData system of MCData client 1.
  3. The file has been successfully transferred to the MCData content server in the partner MCData system.
Reproduction of 3GPP TS 23.282, Fig. 7.5.2.8.3-1: File removal using HTTP by authorized user
Up
Step 1.
The user on the media storage client decides to remove a file that was previously uploaded.
Step 2.
The URL of the file to be removed is included in the request sent to the media storage function on the primary MCData content server.
Step 3.
The primary MCData content server removes the file indicated by the URL.
Step 4.
As the primary MCData content server has recorded that the file has previously been sent to the partner MCData system, the primary MCData content server sends the MCData remove file request by user to the partner MCData content server, containing the URL of the file which was stored on the primary MCData content server.
Step 5.
The partner MCData content server removes the file indicated by the URL.
Step 6.
The partner MCData content server informs the primary MCData content server that the file has been successfully removed.
Step 7.
The primary MCData content server informs the media storage client if the file is successfully removed.
Up

7.5.2.9Void

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

7.5.2.10.1  Generalp. 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  Procedurep. 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
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

Up   Top   ToC