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.13.3.14 Folder move operation  7.13.3.15 Folder list operation  7.13.3.16 Upload objects  7.13.3.17 Notify client to synchronize  7.13.3.18 Search folder  7.13.3.19 Retrieve folder content  7.13.3.20 Store file contents distributed using HTTP 
...

 

7.13.3.14  Folder move operation  p. 193

7.13.3.14.1  General  p. 193
A user can move an existing folder in his user account to a different location. All the child folders and objects stored in that folder will be moved to the new folder. The name of the new folder will be the same as the folder it moves from or the name provided in the request. This operation is only meaningful when the user account in the MCData message store is structured in the folder hierarchy.
7.13.3.14.2  Procedure  p. 193
The procedure in Figure 7.13.3.14.2-1 describes the case when a MCData user moves an existing folder in the MCData message store.
Pre-conditions:
  1. The MCData user has an account in the MCData message store.
  2. A successful authentication and authorization have been performed between the message store client and the MCData message store.
Reproduction of 3GPP TS 23.282, Fig. 7.13.3.14.2-1: Move a user folder
Figure 7.13.3.14.2-1: Move a user folder
Up
Step 1.
The MCData user would like to move an existing folder in his user account in the MCData message store to a new location, the message store client initiates a MCData move folder request toward the MCData message store. The folder identifiers of the source and destination folders and the new folder name are included in the request.
Step 2.
The MCData message store move the source folder to the destination with the new folder name. If no new folder name is provided in the request, the source folder name will be used. All the child folders and objects stored in this folder are also moved to the new folder.
Step 3.
The MCData message store returns the result in the MCData move folder response. The identifier of the new folder is returned in the response.
Up

7.13.3.15  Folder list operation  p. 194

7.13.3.15.1  General  p. 194
A user can view the folder structure in his user account in the MCData message store. The target folder hierarchy structure will be presented to the user; i.e. the folder and all its child folders. This operation is only meaningful when the user account in the MCData message store is structured in the folder hierarchy.
7.13.3.15.2  Procedure  p. 194
The procedure in Figure 7.13.3.15.2-1 describes the case when a MCData user lists an existing folder's hierarchy structure in the MCData message store.
Pre-conditions:
  1. The MCData user has an account in the MCData message store.
  2. A successful authentication and authorization have been performed between the message store client and the MCData message store.
Reproduction of 3GPP TS 23.282, Fig. 7.13.3.15.2-1: Folder list operation
Figure 7.13.3.15.2-1: Folder list operation
Up
Step 1.
The MCData user would like to view the folder strcture of a targeted folder in his user account in the MCData message store, the message store client initiates a MCData list folder request toward the MCData message store. The folder identifier of the target folder is included in the request.
Step 2.
The MCData message store retrieves the target folder and all its child folders. If no target folder name is provided in the request, the MCData message store will use the root folder as the target folder.
Step 3.
The MCData message store returns the result in the MCData list folder response.
Up

7.13.3.16  Upload objects  p. 195

7.13.3.16.1  General  p. 195
A MCData user, with an account in the MCData message store, involved in an off-network communication will store the communication as objects in a specific folder in the local message store on his UE. These objects can be uploaded to his user account in the MCData message store once he is connected to the network with MC data service again.
7.13.3.16.2  Procedure  p. 195
The procedure in Figure 7.13.3.16.2-1 describes the case when a message store client uploads new objects in its local message store to the MCData message store for a MCData user.
Pre-conditions:
  1. The MCData user has an account with the MCData message store.
  2. A successful authentication and authorization have been performed between the message store client and the MCData message store.
Reproduction of 3GPP TS 23.282, Fig. 7.13.3.16.2-1: Upload objects
Figure 7.13.3.16.2-1: Upload objects
Up
Step 1.
The message store client would like to upload new objecs in its local message store to the MCData message store. It initiates the MCData upload objects request toward the MCData message store. The uploaded objects and the target folder identifier where the objects will be stored are included in the request.
Step 2.
The MCData message store stores the uploaded objects to the target folder. If the target folder doesn't exist, the MCData message store will create it.
Step 3.
The MCData message store returns the result in the MCData upload objects response.
Up

7.13.3.17  Notify client to synchronize  p. 196

7.13.3.17.1  General  p. 196
MCData message store will send a notification to the MCData user when there are new objects in the MCData message store that need to be synchronized with his local message store.
7.13.3.17.2  Procedure using in-band connection  p. 196
The procedure in Figure 7.13.3.17.2-1 describes how the MCData message store notifies the message store client that there are new objects in the MCData message store need to be synchronized.
Pre-conditions:
  1. The MCData user has an account with the MCData message store.
  2. A successful authentication and authorization have been performed between the message store client and the MCData message store.
  3. The Message store client is in an ongoing session with the MCData message store.
Reproduction of 3GPP TS 23.282, Fig. 7.13.3.17.2-1: Notify client to synchronize using in-band connection
Figure 7.13.3.17.2-1: Notify client to synchronize using in-band connection
Up
Step 1.
The MCData message store receives new objects for the MCData user and decides to send a notification to inform the MCData user.
Step 2.
The MCData message store sends the MCData synchronization notification to the message store client.
7.13.3.17.3  Procedure using MCData notification server |R17|  p. 197
The procedure in Figure 7.13.3.17.3-1 describes how the MCData message store notifies the message notification client, using a MCData notification server, that there are new objects in the MCData message store needing to be synchronized. This procedure uses a web base notification mechanism in wide deployment today. The Message notification client requests the notification service from the MCData notification server and the MCData notification server returns with two URLs; one used by the service client to inform the service server where to send notification messages and the other one to use by the service client to PULL notification messages from the MCData notification server.
Pre-conditions:
  1. The MCData user has an account with the MCData message store.
  2. A successful authentication and authorization have been performed between the message store client and the MCData message store.
  3. The Message store client doesn't have an ongoing session with the MCData message store.
  4. The trust relationship between the MCData notification server and the MCData message store has been established.
  5. The MCData notification server has a trust relationship and connection with the PUSH Enabler server.
Reproduction of 3GPP TS 23.282, Fig. 7.13.3.17.3-1: Notify client to synchronize through MCData notification server
Figure 7.13.3.17.3-1: Notify client to synchronize through MCData notification server
Up
Step 1.
The Message notification client wants to create notification channels (i.e. endpoint URLs) to be used by the MCData message store to send notification messages and sends a Create notification channel request to the MCData notification server. The desired validity duration for the channels to be used and the notification channel type (PUSH or PULL) are included in the request.
Step 2.
The MCData notification server authenticates the Message notification client and authorizes its request.
Step 3.
The MCData notification server sends the Message notification client the Create notification channel response with the endpoint URLs that will be used by the MCData message store to send the notification messages and the Message notification client to receive the notification messages. The MCData notification server also includes what is the valid duration for these endpoint URLs to be used in the response.
Step 4.
If the notification type is PULL method, the message notification client sends the Open notification channel to the MCData notification server to start receiving the notification message. For certain PUSH method notification type (such as WebSockets) the message notification client requests the MCData notification server to start the PUSH notification service with its specific protocol that is outside the scope of this specification.
Step 5.
The message store client sends the Subscribe for notification request to the MCData message store asking to be notified if there are changes to its message store account. The callback URL returned from the MCData notification server in step 3 is included in the request for the MCData message store to use to send notification messages.
Step 6.
The MCData message store sends the Subscribe for notification response to the message store client to acknowledge the request.
Step 7.
The MCData user's message store account has changed and the MCData message store generates a notification message.
Step 8.
Using the callback URL, the MCData message store sends the notification message to the MCData notification server.
Step 9.
If the delivery method is PULL, the MCData notification server sends the notification message to the message notification client over the opened notification channel. If the delivery method is PUSH, the MCData notification server sends the notification message to the PUSH Enabler server (not shown in the Figure) to deliver to the message notification client.
The procedure in Figure 7.13.3.17.3-2 describes how the message notification client updates the validity duration of a notification channel and subscription to avoid its expiration, i.e. to extend its lifetime.
Pre-conditions:
  1. A notification channel has already been requested and established between the message notification client and MCData notification server.
  2. The message store client has a successful notification subscription with the MCData message store.
  3. The validity duration of the notification channel is about to expire.
Reproduction of 3GPP TS 23.282, Fig. 7.13.3.17.3-2: Update a notification channel
Figure 7.13.3.17.3-2: Update a notification channel
Up
Step 1.
The message notification client sends the Update notification channel request, including the desired new validity duration, to the MCData notification server.
Step 2.
The MCData notification server grants the request and sends the Update notification channel response to the message notification client. The new validity duration is included in the response.
Step 3.
The message store client sends the Update notification subscription request to the MCData message store with the new validity duration received from the MCData notification server in step 2.
Step 4.
The MCData message store sends the Update notification subscription response to the message store client and confirms the new validity duration.
The procedure in Figure 7.13.3.17.3-3 describes how the message notification client delete a notification channel and subscription that is no longer needed.
Pre-conditions:
  1. A notification channel has already been requested and established between the message notification client and MCData notification server.
  2. The message store client has a successful notification subscription with the MCData message store.
  3. The MCData user no longer wants to receive notifications from the MCData message store.
Reproduction of 3GPP TS 23.282, Fig. 7.13.3.17.3-3: Delete a notification channel
Figure 7.13.3.17.3-3: Delete a notification channel
Up
Step 1.
The message store client decides to stop receiving notifications from the MCData message store and sends the Delete notification subscription request to the MCData message store.
Step 2.
The MCData message store acknowledges the request and sends the Delete notification subscription response to the message store client.
Step 3.
The message notification client sends the Delete notification channel request to the MCData notification server.
Step 4.
The MCData notification server acknowledges the request and sends the Delete notification channel response to the message notification client.
Up

7.13.3.18  Search folder |R17|  p. 200

7.13.3.18.1  General  p. 200
The message store client can search stored folder(s) with certain criteria. This procedure allows the message store client to look for folder(s) that meet certain criteria such as when the folder is created. This procedure provides the message store client the ability to locate a specific folder(s) matching the search criteria to perform further operations.
7.13.3.18.2  Procedure  p. 201
The procedure in Figure 7.13.3.18.2-1 describes the case when a message store client searches and retrieves relevant stored objects from the MCData message store.
Pre-conditions:
  1. A successful authentication and authorization have been performed between the message store client and the MCData message store.
Reproduction of 3GPP TS 23.282, Fig. 7.13.3.18.2-1: Search folder
Figure 7.13.3.18.2-1: Search folder
Up
Step 1.
The message store client wants to retrieve message store folder(s) that meet certain criteria (such as when the folder(s) was created, certain keywords etc.) and initiates a MCData search folder request toward the MCData message store. The search criteria are included in the request.
Step 2.
The MCData message store identifies all folders that match the search criteria and returns them in the MCData search folder response.

7.13.3.19  Retrieve folder content |R17|  p. 201

7.13.3.19.1  General  p. 201
An MCData user can retrieve the content of a folder in the user's message store account. This procedure allows the message store client to retrieve the specific folder's content from the MCData message store.
7.13.3.19.2  Procedure  p. 201
The procedure in Figure 7.13.3.19.2-1 describes the case when a message store client retrieves the content of a specific folder in the MCData message store.
Pre-conditions:
  1. A successful authentication and authorization have been performed between the message store client and the MCData message store.
Reproduction of 3GPP TS 23.282, Fig. 7.13.3.19.2-1: retrieve folder content
Figure 7.13.3.19.2-1: retrieve folder content
Up
Step 1.
The message store client wants to retrieve the content of a specific folder and initiates a MCData retrieve folder content request toward the MCData message store. The requested folder identifier is included in the request.
Step 2.
The MCData message store locates the requested folder and returns the content of the folder (e.g. objects and subfolders) in the MCData retrieve folder content response.

7.13.3.20  Store file contents distributed using HTTP |R17|  p. 202

7.13.3.20.1  General  p. 202
An MCData user can store the received file content in his message store account. This procedure allows the message store client to request the MCData message store to retrieve the file from the media storage function of MCData content server and store into MCData message store account of the user.
7.13.3.20.2  Procedure for storing the file - receiver side  p. 202
The procedure in Figure 7.13.3.20.3-1 describes the case when a message store client requests the MCData message store to retrieve the file from media storage function of MCData content server and store into MCData message store account of the user.
Pre-conditions:
  1. A successful authentication and authorization have been performed between the message store client and the MCData message store.
  2. The configuration to store the MCData communication in MCData message store is enabled for the MCData user.
  3. MCData user has requested to store his MCData communication.
  4. The message store client knows the object identifier of the stored object.
Reproduction of 3GPP TS 23.282, Fig. 7.13.3.20.3-1: store file contents distributed using HTTP - receiver side
Figure 7.13.3.20.3-1: store file contents distributed using HTTP - receiver side
Up
Step 1.
The Message store client initiates MCData retrieve file to store locally request towards the MCData message store. The object identifier corresponding to the stored MCData FD communication is included in the request.
Step 2.
The MCData message store retrieves the file URL from the stored object and fetches the file content from the MCData content server.
Step 3.
The MCData message store stores the file content into the MCData user's storage area and update the object with the URL referencing the file content stored in the MCData user's storage area.
Step 4.
The MCData message store provides the MCData retrieve file to store locally response to the message store client. This response includes the URL of the file being stored in the MCData user's storage area.
Up

Up   Top   ToC