Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.282  Word version:  19.0.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.3…   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.3…   7.17.3.2…   7.17.4…   7.17.6…   A…   B…

 

7.17.6  Ad hoc group standalone short data service using signalling control plane |R19|p. 253

7.17.6.1  Information flowsp. 253

7.17.6.1.1  Determine ad hoc group request (MCData client - MCData server)p. 253
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. 254
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. 254
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. 255
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. 256
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. 256
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. 257

7.17.6.2.1  Determine the ad hoc group and preconfigured group for end-to-end encryptionp. 257
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.
Copy of original 3GPP image for 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. 259

7.17.6.3.1  Generalp. 259
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. 259
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.
Copy of original 3GPP image for 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. 261

7.17.6.4.1  Generalp. 261
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. 261
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.
Copy of original 3GPP image for 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

Up   Top   ToC