Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑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.17.6  Ad hoc group standalone short data service using signalling control plane |R19|p. 260

7.17.6.1  Information flowsp. 260

7.17.6.1.1  Determine ad hoc group request (MCData client - MCData server)p. 260
Table 7.17.6.1.1-1 describes the information flow for the Determine ad hoc group request sent from the MCData client to the MCData server.
Information element Status Description
MCData IDMThe identity of the MCData user sending the request.
Functional aliasOThe associated functional alias of the MCData user sending request.
Encryption supportedMIndicates whether ad hoc group data transfer support requires end-to-end encryption.
MCData ID list (see NOTE 1, NOTE 2)OMCData IDs for the ad hoc group standalone short data service.
Criteria for determining the participants (see NOTE 2)OCarries the details of criteria or meaningful label identifying the criteria or the combination of both which will be used by the MCData server for determining the list of MCData users e.g., it can be a location based criteria to SDS data transfer in a particular area.
NOTE 1:
This element is included only when the the ad hoc group standalone short data service initiating client sends the list of MCData users.
NOTE 2:
Only one of these information elements is present.
Up
7.17.6.1.2  Determine ad hoc group response (MCData server - MCData client)p. 261
Table 7.17.6.1.2-1 describes the information flow Determine ad hoc group response from the MCData server to the MCData client. This response to provide the server assigned MCData ad hoc group ID and preconfigured group identity of preconfigured group from which the configurations to be used (e.g. security related information).
Information element Status Description
MCData IDMThe identity of the MCData user sending the request.
MCData ad hoc group ID (see NOTE 1)OThe MCData group ID to be associated with the ad hoc group standalone short data service which is genarted and assigned by the MCData server.
Preconfigured MCData group ID (see NOTE 2)OGroup identity whose configuration is to be applied for ad hoc group standalone short data service.
ResultMResult of the Determine ad hoc group request (success or failure).
NOTE 1:
If the result is success then this IE shall be included.
NOTE 2:
If the result is success and the end-to-end encryption is required, then this IE shall be included.
Up
7.17.6.1.3  Ad hoc group standalone data request (MCData client - MCData server)p. 261
Table 7.17.6.1.3-1 describes the information flow for the Ad hoc group standalone data request sent from the MCData client to the MCData server.
Information element Status Description
MCData IDMThe identity of the MCData user sending data
Functional aliasOThe associated functional alias of the MCData user sending data.
MCData ad hoc group ID (see NOTE 1)MThe MCData group ID to be associated with the ad hoc group standalone short data service
Preconfigured MCData group ID (see NOTE 2)O Group identity whose configuration is to be applied for ad hoc group standalone short data service.
Conversation IdentifierMIdentifies the conversation
Transaction IdentifierMIdentifies the MCData transaction
Emergency indicator (see NOTE 3)OIndicates that the data request is for emergency ad hoc group standalone short data service
Imminent peril indicator (see NOTE 3)OIndicates that the data request is for imminent peril ad hoc group standalone short data service
Disposition TypeOIndicates the disposition type expected from the receiver (i.e., delivered or read or both)
MCData ID list (see NOTE 4)O The specified MCData users who should send a disposition notification message.
Payload Destination TypeMIndicates whether the payload is for application consumption or MCData user consumption
LocationOLocation of the Originating MCData user sending the SDS
Application identifier (see NOTE 5)OIdentifies the application for which the payload is intended (e.g. text string, port address, URI)
Application metadata containerOImplementation specific information that is communicated to the recipient
PayloadMSDS content
Time to liveOIndicates how long the ad hoc group is persisted and members can respond to the data transfer (e.g. duration for 5 mins or till certain future time).
NOTE 1:
The MCData ad hoc group ID is determined prior to by using the Determine ad hoc group request.
NOTE 2:
If end-to-end encryption is required, then this element is included and the value is determined prior to by using the Determine ad hoc group request.
NOTE 3:
If used, only one of these information elements shall be present.
NOTE 4:
If Disposition Type IE is not present, this IE shall not be present. If Disposition Type IE is present but this IE is not, which indicates that all receivers shall respond with disposition notification message.
NOTE 5:
The application identifier shall be included only if the payload destination type indicates that the SDS message is for application consumption.
Up
7.17.6.1.4  Ad hoc group standalone data request (MCData server - MCData client)p. 262
Table 7.17.6.1.4-1 describes the information flow for the Ad hoc group standalone data request sent from the MCData server to the MCData client.
Information element Status Description
MCData IDMThe identity of the MCData user sending data
Functional aliasOThe associated functional alias of the MCData user sending data.
MCData ad hoc group IDMThe MCData group ID associated with ad hoc group standalone short data service
Preconfigured MCData group ID (see NOTE 1)O Group identity whose configuration is to be applied for this ad hoc group standalone short data service.
MCData IDMThe identity of the MCData user towards which the data is sent
Conversation IdentifierMIdentifies the conversation
Transaction IdentifierMIdentifies the MCData transaction
Emergency indicator (see NOTE 2)OIndicates that the data request is for emergency ad hoc group standalone short data service
Imminent peril indicator (see NOTE 2)OIndicates that the data request is for imminent peril ad hoc group standalone short data service
Disposition TypeOIndicates the disposition type expected from the receiver (i.e., delivered or read or both)
Payload Destination TypeMIndicates whether the payload is for application consumption or MCData user consumption
LocationOLocation of the Originating MCData user sending the SDS
Application identifier (see NOTE 3)OIdentifies the application for which the payload is intended (e.g. text string, port address, URI)
Application metadata containerOImplementation specific information that is communicated to the recipient
PayloadMSDS content
Time to liveOIndicates how long the ad hoc group is persisted and members can respond to the data transfer.
NOTE 1:
If end-to-end encryption is required, then this element is included.
NOTE 2:
If used, only one of these information elements shall be present.
NOTE 3:
The application identifier shall be included only if the payload destination type indicates that the payload is for application consumption.
Up
7.17.6.1.5  Ad hoc group standalone data get userlist (MCData server - MCData server)p. 263
Table 7.17.6.1.5-1 describes the information flow Ad hoc group standalone data get userlist from one MCData server to another MCData server.
Information element Status Description
MCData ad hoc group IDMThe MCData group ID associated with the ad hoc group standalone short data service
Criteria for determining the participantsMCarries the details of criteria or meaningful label identifying the criteria or the combination of both which will be used by the MCData server for determining the list of MCData users e.g., it can be a location based criteria to SDS data transfer in a particular area
Up
7.17.6.1.6  Ad hoc group standalone data get userlist response (MCData server - MCData server)p. 263
Table 7.17.6.1.6-1 describes the information flow Ad hoc group standalone data get userlist response from one MCData server to another MCData server.
Information element Status Description
MCData ad hoc group IDMThe MCData group ID associated with the ad hoc group standalone short data service
MCData ID listMList of MCData IDs meeting the criteria specified in the Ad hoc group standalone data get userlist
Up

7.17.6.2  Ad hoc group standalone short data service using signalling control plane common procedurep. 264

7.17.6.2.1  Determine the ad hoc group and preconfigured group for end-to-end encryptionp. 264
The procedure in Figure 7.17.6.2.1-1 describes about determining the MCData ad hoc group ID and preconfigured group identity of preconfigured group from which the configurations to be used (e.g. security related information).
Pre-conditions:
  1. The MCData users belong to primary MCData system and partner MCData system and already registered for receiving MCData service.
  2. Number of ad hoc group members receiving the SDS data should be within the configured limit.
Reproduction of 3GPP TS 23.282, Fig. 7.17.6.2.1-1: Determine ad hoc group and preconfigured group
Up
Step 1.
The user at MCData client 1 wants to initiate an SDS data transfer to multiple MCData users with/without end-to-end encryption supported, and either by providing the list of MCData users in the request or by providing the certain criteria in the request.
Step 2.
The MCData client 1 sends a Determine ad hoc group request towards the MCData server of the primary MCData system. The Determine ad hoc group request contains either the criteria to be applied by the MCData server of the primary MCData system for determining the list of MCData users or the list of MCData users as selected by the user at MCData client 1. The request may also contain the indicator for data transfer is for emergency, imminent peril and the application identifier for which the data transfer is intended.
Step 3.
If the ad hoc group communication is supported, the MCData server of the primary MCData system checks whether the MCData user at MCData client 1 is authorized to initiate a Determine ad hoc group request. If not authorized, the MCData server rejects the Determine ad hoc group request as specified in the step 9. If the request contains the list of MCData users as selected by the user at MCData client 1, the MCData server of the primary MCData system validates whether the number of MCData users provided in the request are within the configured limit. If not within the configured limit, the MCData server rejects the Determine ad hoc group request as specified in the step 9.
Step 4.
If the request contains the criteria, the MCData server of primary MCData system determines the list of MCData users for ad hoc group standalone short data service from the primary MCData system and determines the partner MCData system to be involved in the ad hoc group standalone short data service based on the criteria and according to local policy if required. This information element to determine the ad hoc group member contains the criteria, indicator identifying pre-defined criteria, or a combination of both.
Step 5.
The MCData server of primary MCData system involves the partner MCData system based on the agreement, based on the criteria for determining the list of MCData users, and according to local policy if required. It sends the ad hoc group standalone data get userlist request to the MCData server of partner MCData system. This request carries the criteria received in the Determine ad hoc group request.
Step 6.
The MCData server of partner MCData system determines the list of MCData users satisfying the criteria and sends the response containing the list of MCData users satisfying the criteria. The MCData server of partner MCData system may apply local policies if any while determining the participants satisfying the criteria. The determination of list of MCData users is performed only once.
Step 7.
The MCData server of primary MCData system compiles the list of MCData users for ad hoc group standalone short data service from primary MCData system and from partner MCData system, if requested.
Step 8.
The MCData server of the primary MCData system forms the ad hoc group by using MCData users' information received in the Determine ad hoc group request and list of MCData users to be part of ad hoc group. The MCData server further determines the preconfigured group to be used for the configuration (e.g. security related information) of the ad hoc group if end-to-end encryption is required. The MCData server selects an MCData ad hoc group ID for the newly formed ad hoc group and optionally assign the time to live value. The ad hoc group members can communicate in the ad hoc group until the time to live value is expired. The MCData server ensure the list of MCData users determined in the step 7 are within the configured limit.
Step 9.
The MCData server of the primary MCData system send the Determine ad hoc group response message to MCData client 1 containing the below:
  1. The MCData ad hoc group ID (only included when the Determine ad hoc group request is succesful);
  2. The MCData group ID of the pre-configured group whose configuration is to be applied for this Ad hoc group standalone short data service if end-to-end encryption is required (only included when the Determine ad hoc group request is succesful); and
  3. Result of whether the Determine ad hoc group request successful or failure.
If the Determine ad hoc group request not authorized or result not succesful, the MCData client 1 shall not proceed with remaining steps for the data transfer as specified in the clause 7.17.6.3 and 7.17.6.4.
Up

7.17.6.3  Ad hoc group standalone short data service using signalling control plane involving single MCData systemp. 266

7.17.6.3.1  Generalp. 266
The initiation of Ad hoc group standalone short data service using signalling control plane results in ad hoc group members from single MCData system receiving the SDS data. The SDS payload data size is assumed to be below the configured maximum payload data size for SDS over signalling control plane.
7.17.6.3.2  Procedurep. 266
The procedure in Figure 7.17.6.3.2-1 describes the case where an MCData user is initiating ad hoc group standalone short data service using signalling control plane with or without disposition request.
Pre-conditions:
  1. MCData users on MCData clients 1 to n belong to the same MCData system and are already registered for receiving MCData service.
  2. Number of ad hoc group members receiving the SDS data is within the configured limit.
  3. The preconfigured group identity and preconfigured group configuration (e.g. security related information) to be used for an ad hoc group have been preconfigured in the MCData client and other MCData users of ad hoc group have also received the relevant security related information.
Reproduction of 3GPP TS 23.282, Fig. 7.17.6.3.2-1: Ad hoc group standalone short data service involving single MCData system
Up
Step 1.
The user at MCData client 1 wants initiates an SDS data transfer to ad hoc group members from primary MCData system.
Step 2.
The MCData client 1 shall determine the preconfigured group if end-to-end encryption is required and an ad hoc group by executing the procedures as described in the clause 7.17.6.2.
Step 3.
MCData client 1 sends an Ad hoc group standalone data request towards the MCData server. The request shall contain the MCData ad hoc group ID as determined in the step 2, the conversation identifier for message thread indication, may include additional implementation specific information in the application metadata container, may contain disposition request if indicated by the user at MCData client 1 and may include associated functional alias of the user at MCData client 1. If end-to-end encryption is required, the request shall contain the Preconfigured MCData group ID as determined in the step 2. If the end-to-end encryption is not required then include the payload without encryption and if required then include the payload with encryption based on the Preconfigured MCData group ID as determined in the step 2.
If the MCData user at MCData client 1 initiates an emergency ad hoc group standalone short data service or the MCData emergency state is already set for the MCData client 1 (due to a previously triggered MCData emergency alert):
  1. the Ad hoc group standalone data request shall contain an emergency indicator;
  2. 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; and
  3. once an emergency SDS data transfer has been initiated, the ad hoc group is considered to be in an in-progress emergency state until SDS data transfer is completed and the time to live value of ad hoc group expires.
If the MCData user at MCData client 1 initiates an imminent peril ad hoc group standalone short data service:
  1. the Ad hoc group standalone data request shall contain imminent peril indicator; and
  2. once an emergency SDS data transfer has been initiated, the ad hoc group is considered to be in an in-progress imminent peril state until SDS data transfer is completed and the time to live value of ad hoc group expires.
Step 4.
If the ad hoc group communication is supported, the MCData server checks whether the MCData user at MCData client 1 is authorized to send Ad hoc group standalone data request. If not authorized, the MCData server rejects the Ad hoc group standalone data request as specified in the step 9. The MCData server checks whether any policy is to be asserted to limit certain types of message or content to certain members, for example, to location or user privilege. The MCData server also verifies whether the provided functional alias can be used and has been activated for the user.
Step 5.
The MCData server considers the the ad hoc group memebers as implicitly affiliated to the ad hoc group.
  1. If an emergency indicator is present in the received Ad hoc group standalone data request and if the ad hoc group is not in the in-progress emergency state, the ad hoc group is considered to be in the in-progress emergency state until SDS data transfer is completed and the time to live value of ad hoc group expires; and
  2. If an imminent peril indicator is present in the received Ad hoc group standalone data request and if the ad hoc group is not in the in-progress imminent peril state, the ad hoc group is considered to be in the in-progress imminent peril state until SDS data transfer is completed and the time to live value of ad hoc group expires; and
Step 6.
The MCData server initiates a Ad hoc group standalone data request towards each of the target MCData users. While sending the Ad hoc group standalone data request, the MCData server shall remove the information elements that are not required to be conveyed to the target MCData clients (e.g. MCData ID list). The request should contain the ad hoc group ID, pre-configured group if end-to-end encryption is required and time to live value for the ad hoc group. The primary MCData server removes the ad hoc group information from the dynamic data once the time to live value is expired and thus the ad hoc group ceases to exist then the procedure stops.
Step 7.
If the payload is for MCData user consumption (e.g. is not application data, is not command instructions, etc.) then the MCData user of MCData clients 2 to n may be notified. Otherwise if the payload is not for MCData user consumption, then the MCData user of MCData clients 2 to n shall not be notified. The action taken when the payload contains application data or command instructions are specific based on the contents of the payload. Payload content received by MCData client 2 which is addressed to a known local non-MCData application that is not yet running shall cause the MCData client 2 to start the local non-MCData application (i.e., remote start application) and shall pass the payload content to the just started application.
Step 8.
If the MCData data disposition for delivery was requested by the user at MCData client 1, then the receiving MCData client(s) initiates a MCData data disposition notification for delivery report as described in the step 6 to step 9 of clause 7.4.2.5.2.
Up

7.17.6.4  Ad hoc group standalone short data service using signalling control plane involving multiple MCData systemp. 268

7.17.6.4.1  Generalp. 268
The initiation of Ad hoc group standalone short data service using signalling control plane results in ad hoc group members from multiple MCData system receiving the SDS data. The SDS payload data size is assumed to be below the configured maximum payload data size for SDS over signalling control plane.
7.17.6.4.2  Procedurep. 268
The procedure in Figure 7.17.6.4.2-1 describes the case where an MCData user is initiating ad hoc group standalone short data service using signalling control plane with or without disposition request.
Pre-conditions:
  1. The security aspects of sharing the user information between primary and partner MCData systems shall be governed as per the service provider agreement between them. In this case, it is considered that the partner MCData system share their users' information to the primary MCData system.
  2. MCData users on MCData clients 1 to M belong to the primary MCData system and MCData users on MCData clients 1 to N belong to the partner MCData system and are already registered for receiving MCData service.
  3. The MCData server of the primary MCData system is where the authorized MCData user/dispatcher creates the ad hoc group.
  4. Number of ad hoc group members receiving the SDS data is within configured limit.
  5. The preconfigured group identity and preconfigured group configuration (e.g. security related information) to be used for an ad hoc group have been preconfigured in the MCData client and other MCData users of ad hoc group have also received the relevant security related information.
Reproduction of 3GPP TS 23.282, Fig. 7.17.6.4.2-1: Ad hoc group standalone short data service involving multiple MCData system
Up
Step 1.
The user at MCData client 1 of the primary MCData system wants initiates an SDS data transfer to ad hoc group members from primary and partner MCData systems.
Step 2-5.
Same steps as described in the steps 2 to 5 of clause 7.17.6.3.2.
Step 6-6a.
The MCData server of the primary MCData system initiates an Ad hoc group standalone data request towards each of the target MCData users in the primary MCData system and the partner MCData system. While sending the Ad hoc group standalone data requests, the MCData server of the primary MCData system shall remove the information elements that are not required to be conveyed to the target MCData clients (e.g. MCData ID list). The request should contain the ad hoc group ID, pre-configured group if end-to-end encryption is required and time to live value for the ad hoc group. The primary MCData server removes the ad hoc group information from the dynamic data once the time to live value is expired and thus the ad hoc group ceases to exist then the procedure stops.
Step 7-7a.
If the payload is for MCData user consumption (e.g. is not application data, is not command instructions, etc.) then the MCData user of MCData clients 2 to M and MCData clients 1 to N may be notified. Otherwise if the payload is not for MCData user consumption, then the MCData user of MCData clients 2 to M and MCData clients 1 to N shall not be notified. The action taken when the payload contains application data or command instructions are specific based on the contents of the payload. Payload content received by MCData clients 2 to M and MCData clients 1 to N which is addressed to a known local non-MCData application that is not yet running shall cause the clients 2 to M and MCData clients 1 to N to start the local non-MCData application (i.e., remote start application) and shall pass the payload content to the just started application.
Step 8.
If the MCData data disposition for delivery was requested by the user at MCData client 1 of the primary MCData system, then the receiving MCData client(s) initiates a MCData data disposition notification for delivery report as described in the step 6 to step 9 of clause 7.4.2.5.2.
Up

7.17.7  Ad hoc group standalone file distribution using HTTP procedures |R19|p. 269

7.17.7.1  Information flowsp. 269

7.17.7.1.1  Ad hoc group standalone FD request (MCData client - MCData server)p. 269
Table 7.17.7.1.1-1 describes the information flow for the Ad hoc group standalone FD request sent from the MCData client to the MCData server.
Information element Status Description
MCData IDMThe identity of the MCData user sending the FD request.
Functional aliasOThe associated functional alias of the MCData user sending the FD request.
MCData ad hoc group ID (see NOTE 1)MThe MCData group ID of the ad hoc group to which the file is to be sent.
Preconfigured MCData group ID (see NOTE 2)OThe identity of the MCData group whose configuration (e.g. security related information) is to be applied for ad hoc group file distribution.
Conversation IdentifierMIdentifies the conversation.
Transaction IdentifierMIdentifies the MCData transaction.
Emergency indicator (see NOTE 3)OIndicates that the standalone file distribution request is for emergency ad hoc group standalone file distribution service.
Imminent peril indicator (see NOTE 3)OIndicates that the standalone file distribution request is for imminent peril ad hoc group standalone file distribution service.
Disposition indicationOIndicates whether file download completed report is expected or not.
Download indicationOIndicates mandatory download.
LocationOLocation of the Originating MCData user sending the file.
Payload Destination TypeMIndicates whether the payload is for application consumption or MCData user consumption.
Application identifier (see NOTE 4)OIdentifies the application for which the payload is intended (e.g. text string, port address, URI).
Application metadata containerOImplementation specific information that is communicated to the recipient.
Content referenceMURL reference to the content and file metadata information.
Deposit file indicationOIndicates whether the file to be stored into the MCData message store account of the MCData user.
NOTE 1:
The MCData ad hoc group ID is determined prior to by using the Determine ad hoc group request.
NOTE 2:
If end-to-end encryption is required, then this element is included and the value is determined prior to by using the Determine ad hoc group request.
NOTE 3:
If used, only one of these information elements shall be present.
NOTE 4:
The application identifier shall be included only if the payload destination type indicates that the FD message is for application consumption.
Up
7.17.7.1.2  Ad hoc group standalone FD request (MCData server - MCData client)p. 270
Table 7.17.7.1.2-1 describes the information flow for the Ad hoc group standalone FD request sent from the MCData server to the MCData client.
Information element Status Description
MCData IDMThe identity of the MCData user sending the FD request.
Functional aliasOThe associated functional alias of the MCData user sending the FD request.
MCData ad hoc group IDMThe MCData group ID of the ad hoc group to which the file is to be sent.
Preconfigured MCData group ID (see NOTE 1)OThe identity of the MCData group whose configuration (e.g. security related information) is to be applied for ad hoc group file distribution.
MCData IDMThe identity of the MCData user towards which the FD request is sent.
Conversation IdentifierMIdentifies the conversation.
Transaction IdentifierMIdentifies the MCData transaction.
Emergency indicator (see NOTE 2)OIndicates that the standalone file distribution request is for emergency ad hoc group standalone file distribution service.
Imminent peril indicator (see NOTE 2)OIndicates that the standalone file distribution request is for imminent peril ad hoc group standalone file distribution service.
Disposition indicationOIndicates whether file download completed report is expected or not.
Download indicationOIndicates mandatory download.
LocationOLocation of the Originating MCData user sending the file.
Payload Destination TypeMIndicates whether the payload is for application consumption or MCData user consumption.
Application identifier (see NOTE 3)OIdentifies the application for which the payload is intended (e.g. text string, port address, URI).
Application metadata containerOImplementation specific information that is communicated to the recipient.
Content referenceMURL reference to the content and file metadata information.
Time to liveOIndicates how long the ad hoc group is persisted and members can respond to the file distribution (e.g. duration for 5 mins or until certain future time).
NOTE 1:
If end-to-end encryption is required, then this element is included.
NOTE 2:
If used, only one of these information elements shall be present.
NOTE 3:
The application identifier shall be included only if the payload destination type indicates that the FD message is for application consumption.
Up
7.17.7.1.3  Ad hoc group standalone FD request return (MCData server - MCData client)p. 271
Table 7.17.7.1.3-1 describes the information flow Ad hoc group standalone FD request return from the MCData server to the MCData client.
Information element Status Description
MCData IDMThe identity of the MCData user sending the FD request.
Functional aliasOThe associated functional alias of the MCData user sending the FD request.
Authorization resultMIndicate if authorization is success or failure.
Up
7.17.7.1.4  Ad hoc group standalone FD response (MCData client - MCData server, MCData server - MCData client)p. 272
Table 7.17.7.1.4-1 describes the information flow for the Ad hoc group standalone FD response sent from the MCData client to the MCData server and from the MCData server to another MCData client.
Information element Status Description
MCData ad hoc group IDMThe MCData group ID of the ad hoc group to which the file is to be sent.
MCData IDMThe identity of the MCData user sending FD response.
Conversation IdentifierMIdentifies the conversation.
Time to liveOIndicates how long the ad hoc group is persisted and members can respond to the file distribution (e.g. duration for 5 mins or until certain future time).
ResultMIndicates if the request is accepted or not.
Up

7.17.7.2  Ad hoc group standalone file distribution using HTTP involving single MCData systemp. 272

7.17.7.2.1  Generalp. 272
The initiation of Ad hoc group standalone file distribution using HTTP results in ad hoc group members from single MCData system receiving the file data.
7.17.7.2.2  Procedurep. 272
The procedure in Figure 7.17.7.2.2-1 describes the case where an MCData user is initiating ad hoc group standalone file distribution to multiple MCData users, with or without download completed report request from the MCData user.
Pre-conditions:
  1. The MCData users on MCData clients 1 to n belong to the same MCData system and are already registered for receiving MCData service.
  2. Number of ad hoc group members receiving the file data is within the configured limit.
  3. The MCData client 1 may have an activated functional alias to be used.
  4. 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. The ad hoc group identity and preconfigured group identity of preconfigured group from which the configurations to be used (e.g. security related information) are determined using the procedures defined in subclause 7.17.6.2.1
  5. The preconfigured group identity and preconfigured group configuration (e.g. security related information) to be used for an ad hoc group have been preconfigured in the MCData client 1 and other MCData clients of ad hoc group have also received the relevant security related information.
Reproduction of 3GPP TS 23.282, Fig. 7.17.7.2.2-1: Ad hoc group standalone file distribution involving single MCData system
Up
Step 1.
The user at MCData client 1 wants to initiate ad hoc standalone file distribution to ad hoc group members from primary MCData system.
Step 2.
The MCData client 1 sends an Ad hoc group standalone FD request towards the MCData server. The request shall contain the MCData ad hoc group ID as determined in the subclause 7.17.6.2.1, the conversation identifier for message thread indication, may include additional implementation specific information in the application metadata container, and may include associated functional alias of the user at MCData client 1. If end-to-end encryption is required, the request shall contain the Preconfigured MCData group ID as determined in the subclause 7.17.6.2.1. The request contains content payload in the form of file URL and may contain the file metadata information. If MCData user at MCData client 1 has requested to mandatory download at the recipient side, then the request contains mandatory download indication. The request may contain a download completed report indication if selected by the user at MCData client 1. If the MCData user at MCData client 1 has requested to deposit the file content into his/her MCData message store account, then the request contains deposit file indication set.
If the MCData user at MCData client 1 initiates an emergency ad hoc group standalone file distribution or the MCData emergency state is already set for the MCData client 1 (due to a previously triggered MCData emergency alert):
  1. the Ad hoc group standalone FD request shall contain an emergency indicator;
  2. 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; and
  3. once an emergency file distribution has been initiated, the ad hoc group is considered to be in an in-progress emergency state until file distribution is completed and the time to live value of ad hoc group expires.
If the MCData user at MCData client 1 initiates an imminent peril ad hoc group standalone file distribution:
  1. the Ad hoc group standalone FD request shall contain imminent peril indicator; and
  2. once an emergency file distribution has been initiated, the ad hoc group is considered to be in an in-progress imminent peril state until file distribution is completed and the time to live value of ad hoc group expires.
Step 3.
If the ad hoc group communication is supported, the MCData server checks whether the MCData user at MCData client 1 is authorized to send Ad hoc group standalone FD request. The MCData server checks whether any policy is to be asserted to limit certain types of message or content to certain members, for example, to location or user privilege. The MCData server also verifies whether the provided functional alias can be used and has been activated for the user.
Step 4.
The MCData server sends the Ad hoc group standalone FD request return to the MCData user at MCData client 1 containing the result of whether the Ad hoc group standalone FD request is authorized or not. If the Ad hoc group standalone FD request is not authorized, the MCData server and the MCData client 1 shall not proceed with the rest of the steps.
Step 5.
The MCData server considers the ad hoc group members as implicitly affiliated to the ad hoc group.
  1. If an emergency indicator is present in the received Ad hoc group standalone FD request and if the ad hoc group is not in the in-progress emergency state, the ad hoc group is considered to be in the in-progress emergency state until file distribution is completed and the time to live value of ad hoc group expires; and
  2. If an imminent peril indicator is present in the received Ad hoc group standalone FD request and if the ad hoc group is not in the in-progress imminent peril state, the ad hoc group is considered to be in the in-progress imminent peril state until file distribution is completed and the time to live value of ad hoc group expires.
Step 6.
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 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 request, the 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 7.
The MCData server initiates the Ad hoc group standalone FD request towards each of the target MCData users. While sending the Ad hoc group standalone FD request, the MCData server shall remove the information elements that are not required to be conveyed to the target MCData clients (e.g. MCData ID list). The request should contain the ad hoc group ID, pre-configured group if end-to-end encryption is required and time to live value for the ad hoc group. The primary MCData server removes the ad hoc group information from the dynamic data once the time to live value is expired and thus the ad hoc group ceases to exist then the procedure stops. 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 clients 2 to n notify the user about the incoming Ad hoc group standalone FD request (including file metadata, if present) which may be either accepted or rejected or ignored.
Step 9.
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 Ad hoc group standalone FD response to the MCData server. The MCData client 2 to n automatically sends accepted Ad hoc group standalone FD response when the incoming request included mandatory download indication.
Step 10.
The MCData server forwards the Ad hoc group standalone FD response to the MCData client 1.
Step 11.
The receiving MCData clients 2 to n download the file followed by providing download completed reports for reporting file download completed using the procedure as described in the step 9 to step 12 of subclause 7.5.2.6.
Step 12.
On receiving download completed reports from MCData clients 2 to n or time to live value is expired, the MCData server removes the ad hoc group information from the dynamic data held in the MCData server and the ad hoc group ceases to exist.
Up

7.17.7.3  Ad hoc group standalone file distribution using HTTP involving multiple MCData systemp. 275

7.17.7.3.1  Generalp. 275
The initiation of Ad hoc group standalone file distribution using HTTP results in ad hoc group members from multiple MCData system receiving the file data.
7.17.7.3.2  Procedurep. 275
The procedure in Figure 7.17.7.3.2-1 describes the case where an MCData user is initiating ad hoc group standalone file distribution to multiple MCData users, with or without download completed report request from the MCData user.
Pre-conditions:
  1. The security aspects of sharing the user information between primary and partner MCData systems shall be governed as per the service provider agreement between them. In this case, it is considered that the partner MCData system share their users' information to the primary MCData system.
  2. MCData users on MCData clients 1 to M belong to the primary MCData system and MCData users on MCData clients 1 to N belong to the partner MCData system and are already registered for receiving MCData service.
  3. The MCData server of the primary MCData system is where the authorized MCData user/dispatcher creates the ad hoc group.
  4. Number of ad hoc group members receiving the file data is within the configured limit.
  5. 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. The ad hoc group identity and preconfigured group identity of preconfigured group from which the configurations to be used (e.g. security related information) are determined using the procedures defined in subclause 7.17.6.2.1.
  6. The preconfigured group identity and preconfigured group configuration (e.g. security related information) to be used for an ad hoc group have been preconfigured in the MCData client and other MCData users of ad hoc group have also received the relevant security related information.
Reproduction of 3GPP TS 23.282, Fig. 7.17.7.3.2-1: Ad hoc group standalone file distribution involving multiple MCData system
Up
Step 1.
The user at MCData client 1 of the primary MCData system wants initiate ad hoc standalone file distribution to ad hoc group members from primary and partner MCData systems.
Step 2-6.
Same steps as described in the steps 2 to 6 of subclause 7.17.7.2.2.
Step 7a-7b.
The MCData server of the primary MCData system initiates an Ad hoc group standalone FD request towards each of the target MCData users in the primary MCData system and the partner MCData system. While sending the Ad hoc group standalone FD requests, the MCData server of the primary MCData system shall remove the information elements that are not required to be conveyed to the target MCData clients (e.g. MCData ID list). The request should contain the ad hoc group ID, pre-configured group if end-to-end encryption is required and time to live value for the ad hoc group. The primary MCData server removes the ad hoc group information from the dynamic data once the time to live value is expired and thus the ad hoc group ceases to exist then the procedure stops.
Step 8a-8b.
The receiving MCData clients 2 to M and MCData clients 1 to N notify the user about the incoming Ad hoc group standalone FD request (including file metadata, if present) which may be either accepted or rejected or ignored.
Step 9a-9b.
If the target MCData user on MCData clients 2 to M and MCData clients 1 to N provides a response (accept or reject) to the notification, then respective MCData clients send the Ad hoc group standalone FD response to the MCData server. The MCData clients 2 to M and MCData clients 1 to N automatically sends accepted Ad hoc group standalone FD response when the incoming request included mandatory download indication.
Step 10a-10b.
The MCData server forwards the Ad hoc group standalone FD response to the MCData client 1.
Step 11a-11d.
The receiving MCData clients 2 to M and MCData clients 1 to N download the file followed by providing download completed reports for reporting file download completed using the procedure as described in the step 9 to step 12 of subclause 7.5.2.6.
Up

Up   Top   ToC