7.5.2 File distribution for on-network

23.2823GPPFunctional architecture and information flows to support Mission Critical Data (MCData)Release 18Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.5.2.1 Information flows for file distribution

7.5.2.1.1 MCData upload data request

Table 7.5.2.1.1-1 describes the information flow for the MCData upload data request sent from the media storage client to the MCData content server.

Table 7.5.2.1.1-1: MCData upload data request

Information element	Status	Description
MCData ID	M	The identity of the MCData user uploading data
Content (see NOTE)	O	Content to upload
Content reference (see NOTE)	O	URL reference of the content stored in the MCData message store account of the MCData user
Emergency indicator	O	Indicates that the data request is for MCData emergency communication
NOTE: Either the Content or the Content reference must be present.

7.5.2.1.2 MCData upload data response

Table 7.5.2.1.2-1 describes the information flow for the MCData upload data response sent from the MCData content server to the media storage client.

Table 7.5.2.1.2-1: MCData upload data response

Information element	Status	Description
MCData ID	M	The identity of the MCData user requesting to upload data
Upload confirmation	M	An indication whether the upload to the content storage is successful or not
Content reference	O	URL reference of the content stored (see NOTE).
NOTE: Content reference shall be present when the upload confirmation is successful.

7.5.2.1.3 MCData download data request

Table 7.5.2.1.3-1 describes the information flow for the MCData download data request sent from the MCData media storage client to the MCData content server.

Table 7.5.2.1.3-1: MCData download data request

Information element	Status	Description
MCData ID	M	The identity of the MCData user downloading data
Content reference	M	URL reference to the content to download
Emergency indicator	O	Indicates that the data request is for MCData emergency communication

7.5.2.1.4 MCData download data response

Table 7.5.2.1.4-1 describes the information flow for the MCData download data response sent from the MCData content server to the media storage client.

Table 7.5.2.1.4-1: MCData download data response

Information element	Status	Description
MCData ID	M	The identity of the MCData user requesting to download data
Content (see NOTE)	O	Requested content to download
Result	M	Indicates success or failure of MCData download data request
NOTE: Content shall be present when the result of the MCData download data request indicates success.

7.5.2.1.5 MCData FD request (using HTTP)

Table 7.5.2.1.5-1 describes the information flow for the MCData FD request (in subclause 7.5.2.4.2) sent from the MCData client to the MCData server.

Table 7.5.2.1.5-1: MCData FD request (using HTTP) from MCData client to MCData server

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending the file
Functional alias	O	The functional alias associated with MCData user sending the file
MCData ID (see NOTE)	O	The identity of the MCData user receiving the file
Functional alias (see NOTE)	O	The associated functional alias of the MCData user identity towards which the data is sent.
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Disposition indication	O	Indicates whether file download completed report is expected or not
Download indication	O	Indicates mandatory download
Application metadata container	O	Implementation specific information that is communicated to the recipient
Content reference	M	URL reference to the content and file metadata information
Emergency indicator	O	Indicates that the data request is for MCData emergency communication
Deposit file indication	O	Indicates whether the file to be stored into the MCData message store account of the MCData user
NOTE: Either the MCData ID or the functional alias must be present.

Table 7.5.2.1.5-2 describes the information flow for the MCData FD request (in clause 7.5.2.4.2) sent from an MCData server to a partner MCData server.

Table 7.5.2.1.5-2: MCData FD request (using HTTP) from an MCData server to MCData server

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending the file
Functional alias	O	The associated functional alias of the MCData user identity sending the file
MCData ID	M	The identity of the MCData user receiving the file
Functional alias	O	The associated functional alias of the MCData user identity towards which the data is sent.
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Disposition indication	O	Indicates whether file download completed report is expected or not
Download indication	O	Indicates mandatory download
Application metadata container	O	Implementation specific information that is communicated to the recipient
Content reference	M	URL reference to the content and file metadata information
Emergency indicator	O	Indicates that the data request is for MCData emergency communication

Table 7.5.2.1.5-3 describes the information flow for the MCData FD request (in clause 7.5.2.4.2) sent from the MCData server to the MCData client.

Table 7.5.2.1.5-3: MCData FD request (using HTTP) from MCData server to MCData client

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending the file
Functional alias	O	The associated functional alias of the MCData user sending the file
MCData ID	M	The identity of the MCData user receiving the file
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Disposition indication	O	Indicates whether file download completed report is expected or not
Download indication	O	Indicates mandatory download
Application metadata container	O	Implementation specific information that is communicated to the recipient
Content reference	M	URL reference to the content and file metadata information
Emergency indicator	O	Indicates that the data request is for MCData emergency communication

7.5.2.1.6 MCData FD response (using HTTP)

Table 7.5.2.1.6-1 describes the information flow for the MCData FD response (in subclause 7.5.2.4.2) sent from the MCData client to the MCData server, from the MCData server to another MCData client and from an MCData server to a partner MCData server.

Table 7.5.2.1.6-1: MCData FD response (using HTTP)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending FD request
MCData ID	M	The identity of the MCData user sending response
Conversation Identifier	M	Identifies the conversation
Result	O	Indicates if the request is accepted or not

7.5.2.1.7 MCData download completed report

Table 7.5.2.1.7-1 describes the information flow for the MCData download completed report sent from the MCData client to the MCData server, from the MCData server to another MCData client and from an MCData server to a partner MCData server.

Table 7.5.2.1.7-1: MCData download completed report

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending FD request
MCData ID	M	The identity of the MCData user sending response
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	M	Identifies the original MCData transaction to which the current transaction is a reply to
Disposition confirmation	M	An indication that the client has completed downloading file

7.5.2.1.7A MCData aggregated download completed report

Table 7.5.2.1.7A-1 describes the information flow for the MCData aggregated download completed report sent from the MCData server to the MCData client, indicating the result of a request for a file delivery to an MCData group.

Table 7.5.2.1.7A-1: MCData aggregated download completed report

Information element	Status	Description
MCData ID	M	The identity of the MCData user that sent the FD request
Number of Aggregated Reports	M	Total number of received individual completed reports
Number of Successful Deliveries	O	Number of received individual completed reports indicating success
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	M	Identifies the original MCData transaction which the current transaction is a reply to
Successful MCData ID list	O (NOTE)	List, partial or full, of MCData users who successfully received the file delivery
Unsuccessful MCData ID list	O (NOTE)	List, partial or full, of MCData users who reported failure to fully receive the file delivery successfully
NOTE: No more than one of these information elements may be present.

7.5.2.1.8 MCData FD request (using media plane)

Table 7.5.2.1.8-1 describes the information flow for the MCData FD request (in subclause 7.5.2.5.2) sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.5.2.1.8-1: MCData FD request (using media plane/MCData client to MCData server)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending the file
Functional alias	O	The functional alias associated with MCData user sending the file
MCData ID (see NOTE 1)	O	The identity of the MCData user receiving the file
Functional alias (see NOTE 1)	O	The associated functional alias of the MCData user identity towards which the data is sent.
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Disposition indication	O	Indicates whether file download completed report is expected or not
Download indication	O	Indicates mandatory download (i.e. auto accept this media plane setup request)
Application metadata container	O	Implementation specific information that is communicated to the recipient
SDP offer (see NOTE 2)	M	Media parameters offered
Requested priority	O	Application priority level requested for this communication session
Emergency indicator	O	Indicates that the data request is for MCData emergency communication
NOTE 1: Either the MCData ID or the functional alias must be present. NOTE 2: Includes file metadata.

Table 7.5.2.1.8-2: MCData FD request (using media plane/MCData server to MCData server)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending the file
Functional alias	O	The associated functional alias of the MCData user identity sending the file
MCData ID	M	The identity of the MCData user receiving the file
Functional alias	O	The associated functional alias of the MCData user identity towards which the data is sent.
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Disposition indication	O	Indicates whether file download completed report is expected or not
Download indication	O	Indicates mandatory download (i.e. auto accept this media plane setup request)
Application metadata container	O	Implementation specific information that is communicated to the recipient
SDP offer (see NOTE)	M	Media parameters offered
Requested priority	O	Application priority level requested for this communication session
Emergency indicator	O	Indicates that the data request is for MCData emergency communication
NOTE: Includes file metadata.

Table 7.5.2.1.8-3: MCData FD request (using media plane/MCData server to MCData client)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending the file
Functional alias	O	The associated functional alias of the MCData user identity sending the file
MCData ID	M	The identity of the MCData user receiving the file
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Disposition indication	O	Indicates whether file download completed report is expected or not
Download indication	O	Indicates mandatory download (i.e. auto accept this media plane setup request)
Application metadata container	O	Implementation specific information that is communicated to the recipient
SDP offer (see NOTE)	M	Media parameters offered
Requested priority	O	Application priority level requested for this communication session
Emergency indicator	O	Indicates that the data request is for MCData emergency communication
NOTE: Includes file metadata.

7.5.2.1.9 MCData FD response (using media plane)

Table 7.5.2.1.9-1 describes the information flow for the MCData FD response (in subclause 7.5.2.5.2) sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.5.2.1.9-1: MCData FD response (using media plane)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending FD request
MCData ID	M	The identity of the MCData user sending response
Conversation Identifier	M	Identifies the conversation
SDP answer	M	Media parameters selected
Establishment reason	O	Reason for establishment or rejection

7.5.2.1.10 MCData group standalone FD request (using HTTP)

Table 7.5.2.1.10-1 describes the information flow for the MCData group standalone FD request (in subclause 7.5.2.6.2) sent from the MCData client to the MCData server.

Table 7.5.2.1.10-1: MCData group standalone FD request (using HTTP) from MCData client to MCData server

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending the file
Functional alias	O	The functional alias associated with MCData user sending the file
MCData group ID	M	The MCData group ID to which the file is to be sent
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Disposition indication	O	Indicates whether file download completed report is expected or not
Download indication	O	Indicates mandatory download
Application metadata container	O	Implementation specific information that is communicated to the recipient
Content reference	M	URL reference to the content and file metadata information
Emergency indicator (see NOTE 1)	O	Indicates that the data request is for MCData emergency communication
Alert indicator (see NOTE 2)	O	Indicates whether an emergency alert is to be sent
Imminent peril indicator (see NOTE 1)	O	Indicates that the data request is for MCData imminent peril communication
NOTE 1: If used, only one of these information elements shall be present. NOTE 2: This information element may be present only when Emergency indicator is present.

Table 7.5.2.1.10-2 describes the information flow for the MCData group standalone FD request (in subclause 7.5.2.6.2) sent from the MCData server to the MCData client.

Table 7.5.2.1.10-2: MCData group standalone FD request (using HTTP) from MCData server to MCData client

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending the file
Functional alias	O	The functional alias associated with MCData user sending the file
MCData group ID	M	The MCData group ID to which the file is to be sent
MCData ID	M	The identity of the MCData user receiving the file
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Disposition indication	O	Indicates whether file download completed report is expected or not
Download indication	O	Indicates mandatory download
Application metadata container	O	Implementation specific information that is communicated to the recipient
Content reference	M	URL reference to the content and file metadata information
Emergency indicator (see NOTE 1)	O	Indicates that the data request is for MCData emergency communication
Alert indicator (see NOTE 2)	O	Indicates whether an emergency alert is to be sent
Imminent peril indicator (see NOTE 1)	O	Indicates that the data request is for MCData imminent peril communication
NOTE 1: If used, only one of these information elements shall be present. NOTE 2: This information element may be present only when Emergency indicator is present.

7.5.2.1.11 MCData group standalone FD response (using HTTP or MBMS download delivery method)

Table 7.5.2.1.11-1 describes the information flow for the MCData group standalone FD response (in subclause 7.5.2.6.2) sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.5.2.1.11-1: MCData group standalone FD response (using HTTP)

Information element	Status		Description
MCData ID	M		The identity of the MCData user sending FD request
MCData group ID	M	The MCData group ID to which the file is to be sent
MCData ID	M		The identity of the MCData user sending response
Conversation Identifier	M		Identifies the conversation
Result	M		Indicates if the request is accepted or not

7.5.2.1.12 MCData group standalone FD request (using media plane)

Table 7.5.2.1.12-1 describes the information flow for the MCData group standalone FD request (in subclause 7.5.2.7.2) sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.5.2.1.12-1: MCData group standalone FD request (using media plane/MCData client to MCData server)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending the file
Functional alias	O	The functional alias associated with MCData user sending the file
MCData group ID	M	The MCData group ID to which the data is to be sent
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Disposition indication	O	Indicates whether file download completed report is expected or not
Download indication	O	Indicates mandatory download (i.e. auto accept this media plane setup request)
Application metadata container	O	Implementation specific information that is communicated to the recipient
SDP offer (see NOTE 3)	M	Media parameters offered
Requested priority	O	Application priority level requested for this communication session
Emergency indicator (see NOTE 1)	O	Indicates that the data request is for MCData emergency communication
Alert indicator (see NOTE 2)	O	Indicates whether an emergency alert is to be sent
Imminent peril indicator (see NOTE 1)	O	Indicates that the data request is for MCData imminent peril communication
NOTE 1: If used, only one of these information elements shall be present. NOTE 2: This information element may be present only when Emergency indicator is present. NOTE 3: Includes file metadata.

Table 7.5.2.1.12-2: MCData group standalone FD request (using media plane/MCData server to MCData client)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending the file
Functional alias	O	The functional alias associated with MCData user sending the file
MCData group ID	M	The MCData group ID to which the data is to be sent
MCData ID	M	The identity of the MCData user receiving the file
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Disposition indication	O	Indicates whether file download completed report is expected or not
Download indication	O	Indicates mandatory download (i.e. auto accept this media plane setup request)
Application metadata container	O	Implementation specific information that is communicated to the recipient
SDP offer (see NOTE 3)	M	Media parameters offered
Requested priority	O	Application priority level requested for this communication session
Emergency indicator (see NOTE 1)	O	Indicates that the data request is for MCData emergency communication
Alert indicator (see NOTE 2)	O	Indicates whether an emergency alert is to be sent
Imminent peril indicator (see NOTE 1)	O	Indicates that the data request is for MCData imminent peril communication
NOTE 1: If used, only one of these information elements shall be present. NOTE 2: This information element may be present only when Emergency indicator is present. NOTE 3: Includes file metadata.

7.5.2.1.13 MCData group standalone FD response (using media plane)

Table 7.5.2.1.13-1 describes the information flow for the MCData group standalone FD response (in subclause 7.5.2.7.2) sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.5.2.1.13-1: MCData group standalone FD response (using media plane)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending FD request
MCData group ID	M	The MCData group ID to which the file is to be sent
MCData ID	M	The identity of the MCData user sending response
Conversation Identifier	M	Identifies the conversation
SDP answer	M	Media parameters selected

7.5.2.1.14 MCData remove file request by user

Table 7.5.2.1.14-1 describes the information flow for the MCData remove file request by user sent from the media storage client to the media storage function of the MCData content server, and from the MCData content server to another MCData content server in a partner MCData system.

Table 7.5.2.1.14-1: MCData remove file request by user

Information element	Status	Description
MCData ID (see NOTE 1)	O	The identity of the MCData user removing file
Partner MCData system identity (see NOTE 2)	O	The identity of the partner MCData system where the file has also been downloaded
Content reference	M	URL of the content to be removed
NOTE 1: The identity of the MCData user removing the file is present when sent from MCData client to MCData content server NOTE 2: The identity of the partner MCData system is present when sent from MCData content server to MCData content server.

7.5.2.1.15 MCData remove file response by user

Table 7.5.2.1.15-1 describes the information flow for the MCData remove file response by user sent from the media storage function of the MCData content server to the media storage client, and from the MCData content server to another MCData content server in a partner MCData system.

Table 7.5.2.1.15-1: MCData remove file response by user

Information element

Status

Description

MCData ID (see NOTE 1)

The identity of the MCData user removing file

Partner MCData system identity (see NOTE 2)

The identity of the partner MCData system where the file has also been downloaded

Result

Indicates the success or failure of the file removal

NOTE 1: The identity of the MCData user removing the file is present when sent from MCData content server to MCData client

NOTE 2: The identity of the partner MCData system is present when sent from MCData content server to MCData content server.

7.5.2.1.16 Void

7.5.2.1.17 Void

7.5.2.1.18 MCData remove file notify

Table 7.5.2.1.18-1 describes the information flow for the MCData remove file notify sent from the MCData server to the MCData client that the shared file has been removed.

Table 7.5.2.1.18-1: MCData remove file notify

Information element	Status	Description
MCData ID	M	The identity of the MCData user uploaded the file
Content reference	M	URL of the content that has been removed
Reason	O	The reason the file is removed

7.5.2.1.19 MCData file retrieve request

Table 7.5.2.1.19-1 describes the information flow for the MCData file retrieve request sent from an MCData content server in a partner MCData system to an MCData content server in the primary MCData system of the source of the content.

Table 7.5.2.1.19-1: MCData file retrieve request

Information element	Status	Description
Content reference	M	URL reference to the content to download

7.5.2.1.20 MCData file retrieve response

Table 7.5.2.1.20-1 describes the information flow for the MCData file retrieve response sent from the MCData content server in the primary MCData system of the source of the content to an MCData content server in a partner MCData system.

Table 7.5.2.1.20-1: MCData file retrieve response

Information element	Status	Description
Content (see NOTE)	O	Requested content to download
Result	M	Indicates success or failure of MCData download data request
NOTE: Content shall be present when the result of the MCData file retrieve request indicates success.

7.5.2.1.21 MCData group standalone FD over MBMS request

Table 7.5.2.1.21-1 describes the information flow for the MCData group standalone FD request (in subclause 7.5.2.6.2) sent from the MCData server to another MCData client.

Table 7.5.2.1.21-1: MCData group standalone FD over MBMS request

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending the file
MCData group ID	M	The MCData group ID to which the file is to be sent
Conversation Identifier	M	Identifies the conversation
Transaction Identifier	M	Identifies the MCData transaction
Reply Identifier	O	Identifies the original MCData transaction to which the current transaction is a reply to
Disposition indication	O	Indicates whether file download completed report is expected or not
Download indication	M	Indicates mandatory download
Application metadata container	O	Implementation specific information that is communicated to the recipient
Content reference	M	URL reference to the content and file metadata information
MBMS user service id	M	Id of the MBMS user service delivering the file
MBMS content URI	M	URI upon which the content is delivered in the MBMS user service

7.5.2.1.22 MCData one-to-one FD upgrade request

Table 7.5.2.1.22-1 describes the information flow for the MCData one-to-one FD upgrade request sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.5.2.1.22-1: MCData one-to-one FD upgrade request

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data (when initiated by MCData client); The identity of the MCData user receiving data (when initiated by MCData server).
Functional alias	O	The associated functional alias of the MCData user sending data or receiving data.
Conversation Identifier	M	Identifies the conversation
Emergency indicator	M	Indicates that the data request is for MCData emergency communication

7.5.2.1.23 MCData one-to-one FD upgrade response

Table 7.5.2.1.23-1 describes the information flow for the MCData one-to-one FD upgrade response sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.5.2.1.23-1: MCData one-to-one FD upgrade response

Information element

Status

Description

MCData ID

The identity of the MCData user sending data (when initiated by MCData client);

The identity of the MCData user receiving data (when initiated by MCData server).

Conversation Identifier

Identifies the conversation

7.5.2.1.24 MCData group FD upgrade request

Table 7.5.2.1.24-1 describes the information flow for the MCData group FD upgrade request sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.5.2.1.24-1: MCData group FD upgrade request (MCData client to MCData server)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending the upgrade request
Functional alias	O	The associated functional alias of the MCData user sending data or receiving data.
MCData group ID	M	The MCData group ID on which the emergency upgrade request is made
Conversation Identifier	M	Identifies the conversation
Emergency indicator (see NOTE 1)	O	Indicates that the data request is for MCData emergency communication
Alert indicator (see NOTE 2)	O	Indicates whether an emergency alert is to be sent
Imminent peril indicator (see NOTE 1)	O	Indicates that the data request is for MCData imminent peril communication
NOTE 1: If used, only one of these information elements shall be present. NOTE 2: This information element may be present only when Emergency indicator is present.

Table 7.5.2.1.24-2: MCData group FD upgrade request (MCData server to MCData client)

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending the upgrade request
Functional alias	O	The associated functional alias of the MCData user sending data or receiving data.
MCData group ID	M	The MCData group ID on which the emergency upgrade request is made
MCData ID	M	The identity of the MCData user receiving the upgrade request
Conversation Identifier	M	Identifies the conversation
Emergency indicator (see NOTE 1)	O	Indicates that the data request is for MCData emergency communication
Alert indicator (see NOTE 2)	O	Indicates whether an emergency alert is to be sent
Imminent peril indicator (see NOTE 1)	O	Indicates that the data request is for MCData imminent peril communication
NOTE 1: If used, only one of these information elements shall be present. NOTE 2: This information element may be present only when Emergency indicator is present.

7.5.2.1.25 MCData group FD upgrade response

Table 7.5.2.1.25-1 describes the information flow for the MCData group FD upgrade response sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.5.2.1.25-1: MCData group FD upgrade response

Information element	Status	Description
MCData ID	M	The identity of the MCData user sending data (when initiated by MCData client); The identity of the MCData user receiving data (when initiated by MCData server).
MCData group ID	M	The MCData group ID on which the emergency upgrade request is made
Conversation Identifier	M	Identifies the conversation

7.5.2.1.26 MCData group FD in-progress priority state cancel request

Table 7.5.2.1.26-1 describes the information for the MCData group FD in-progress priority state cancel request sent from the MCData client to the MCData server and from the MCData server to another MCData client.

Table 7.5.2.1.26-1: MCData group FD in-progress priority state cancel request (MCData client to MCData server)

Information Element	Status	Description
MCData ID	M	The identity of the cancelling MCData User
MCData group ID	M	The MCData group ID on which the MCData in-progress emergency state is to be cancelled.
Emergency indicator (see NOTE 1)	O	Indicates that the data request is for MCData emergency communication
Alert indicator (see NOTE 2)	O	Indicates whether an emergency alert is to be sent
Imminent peril indicator (see NOTE 1)	O	Indicates that the data request is for MCData imminent peril communication
Conversation Identifier	M	Identifies the conversation
NOTE 1: If used, only one of these information elements shall be present. NOTE 2: This information element may be present only when Emergency indicator is present.

Table 7.5.2.1.26-2: MCData group FD in-progress priority state cancel request (MCData server to MCData client)

Information Element	Status	Description
MCData ID	M	The identity of the cancelling MCData User
MCData group ID	M	The MCData group ID on which the MCData in-progress emergency state is to be cancelled.
MCData ID	M	The identity of the MCData user receiving the cancel request
Emergency indicator (see NOTE 1)	O	Indicates that the data request is for MCData emergency communication
Alert indicator (see NOTE 2)	O	Indicates whether an emergency alert is to be sent
Imminent peril indicator (see NOTE 1)	O	Indicates that the data request is for MCData imminent peril communication
Conversation Identifier	M	Identifies the conversation
NOTE 1: If used, only one of these information elements shall be present. NOTE 2: This information element may be present only when Emergency indicator is present.

7.5.2.1.27 MCData group FD in-progress priority state cancel response

Table 7.5.2.1.27-1 describes the information flow for the MCData group FD in-progress priority state cancel response sent from the MCData server to the MCData client.

Table 7.5.2.1.27-1: MCData group FD in-progress priority state cancel response information elements

Information Element	Status	Description
MCData ID	M	The identity of the cancelling party
MCData group ID	M	The MCData group ID on which the MCData in-progress emergency in-progress is to be cancelled.
Conversation Identifier	M	Identifies the conversation

7.5.2.1.28 MCData file upload request

Table 7.5.2.1.28-1 describes the information flow for the MCData file upload request sent from the MCData client to the MCData server.

Table 7.5.2.1.28-1: MCData file upload request

Information element	Status	Description
MCData ID	M	The identity of the MCData user uploading the file
Transaction Identifier	M	Identifies the MCData transaction
Access information	M	Provides access resource details to be used by the MCData client for the file upload, e.g. IP address and port
MCData content server information	M	Provides information about the target MCData content server, where the file is intended to be uploaded, e.g. URI or IP address, and port (e.g. standard port 80 for HTTP)
Emergency indicator	O	Indicates that the request is for an MCData emergency communication

7.5.2.1.29 MCData file upload response

Table 7.5.2.1.29-1 describes the information flow for the MCData file upload response sent from the MCData server to the MCData client.

Table 7.5.2.1.29-1: MCData file upload response

Information element	Status	Description
MCData ID	M	The identity of the MCData user requesting to upload the file
Transaction Identifier	M	Identifies the MCData transaction
File upload confirmation	M	Indicates whether the file upload to the MCData content server can proceed or not

7.5.2.1.30 MCData file upload completion status

Table 7.5.2.1.30-1 describes the information flow for the MCData file upload completion status sent from the MCData client to the MCData server.

Table 7.5.2.1.30-1: MCData file upload completion status

Information element	Status	Description
MCData ID	M	The identity of the MCData user uploading the file
Transaction Identifier	M	Identifies the MCData transaction
File upload status	M	Indicates the file upload to the MCData content server is completed

7.5.2.1.31 MCData file download request

Table 7.5.2.1.31-1 describes the information flow for the MCData file download request sent from the MCData client to the MCData server.

Table 7.5.2.1.31-1: MCData file download request

Information element	Status	Description
MCData ID	M	The identity of the MCData user downloading the file
Transaction Identifier	M	Identifies the MCData transaction
Access information	M	Provides access resource details to be used by the MCData client for the file download, e.g. IP address and port
MCData content server information	M	Provides information about the target MCData content server, where the file is intended to be downloaded from, e.g. URI or IP address, and port (e.g. standard port 80 for HTTP)
Content reference	M	URL reference to the content to download
Emergency indicator	O	Indicates that the request is for an MCData emergency communication

7.5.2.1.32 MCData file download response

Table 7.5.2.1.32-1 describes the information flow for the MCData file download response sent from the MCData server to the MCData client.

Table 7.5.2.1.32-1: MCData file download response

Information element	Status	Description
MCData ID	M	The identity of the MCData user requesting to dowload the file
Transaction Identifier	M	Identifies the MCData transaction
File download confirmation	M	Indicates whether the file download from the MCData content server can proceed or not

7.5.2.1.33 MCData file availability request

Table 7.5.2.1.33-1 describes the information flow for the MCData file availability request sent from the MCData server to the MCData content server.

Table 7.5.2.1.33-1: MCData file availability request

Information element	Status	Description
Content reference	M	URL reference of the file required to check its availability in the MCData content server

7.5.2.1.34 MCData file availability response

Table 7.5.2.1.34-1 describes the information flow for the MCData file availability response sent from the MCData content server to the MCData server.

Table 7.5.2.1.34-1: MCData file availability response

Information element	Status	Description
Content reference	M	URL reference of the file required to check its availability in the MCData content server
Result	M	Indicates whether the file is available or not

7.5.2.2 File upload using HTTP

7.5.2.2.1 General

The media storage client uses HTTP for a standalone data file upload towards the MCData content server.

7.5.2.2.2 Procedure for uploading the file residing in the local storage of the MCData UE

The procedure in figure 7.5.2.2.2-1 describes the case where an MCData user is uploading a file to media storage function on the MCData content server.

Pre-conditions:

1. The MCData user on the media storage client is registered for receiving MCData service.

2. The MCData content server has the ability to verify if the requesting MCData user is authorised to upload.

Figure 7.5.2.2.2-1: Uploading of the file residing in MCData UE using HTTP

1. The user at the media storage client initiates a file upload request of the chosen file. If MCData emergency state is already set for the media storage client (due to previously triggered MCData emergency alert), the media storage client sets emergency indicator in the request. The media storage client verifies that the size of the file is within the maximum data size for FD for the intended MCData FD request (by checking the group configuration for a group FD request and by checking the service configuration for a one-to-one FD request).

2. The file to be uploaded is received by the media storage client and sent to the media storage function on the MCData content server for storing using the MCData upload data request.

3. The MCData content server stores the file and provides a MCData upload data response indicating success (along with file URL to the media storage client) or failure.

7.5.2.2.3 Procedure for uploading the file residing in the MCData message store

The procedure in figure 7.5.2.2.3-1 describes the case where an MCData user is uploading a file to media storage function on the MCData content server from his or her MCData message store account.

Pre-conditions:

1. The Media storage client knows the URL of the file residing in the MCData message store account of the user.

Figure 7.5.2.2.3-1: Uploading of the file residing in MCData message store using HTTP

1. The user at the media storage client initiates a file upload request of the file residing in his MCData message store account.

2. The URL of the file which needs to be retrieved from the MCData message store account of the user is sent to the media storage function on the MCData content server using the MCData upload data request.

3. The MCData content server fetches the file from the MCData message store account of the user using the URL provided in the MCData upload data request.

4. The MCData content server stores the retrieved file content into its repository.

5. The MCData content provides a MCData upload data response indicating success (along with file URL to the media storage client) or failure.

7.5.2.2.4 Procedure for file upload including request of network resources with required QoS

The procedure in figure 7.5.2.2.4-1 describes the case where an MCData client sends a request to the MCData server for the upload of a file from the media storage client on the MCData client to the media storage function on the MCData content server. The MCData server can, therefore, request network resources with the required QoS for the corresponding file upload.

Pre-conditions:

1. The MCData user on the MCData client is registered on the MCData server for receiving MCData service.

2. The MCData client is required to upload a file to the MCData content server over network resources with required QoS.

3. The MCData client knows its IP address/port to be used for the file upload as well as the URI or IP address/port of the target MCData content server.

NOTE: How the MCData client knows the IP addresses and ports to be used for the file upload is implementation specific and out of the scope of this specification.

Figure 7.5.2.2.4-1: File upload using HTTP over network resources with required QoS

1. The MC user on the MCData client intends to upload a file to the MCData content server for file distribution. The MCData client verifies that the size of the file is within the maximum data size for FD for the intended MCData FD request (e.g., by checking the group configuration for a group FD request or the service configuration for a one-to-one FD request). If the MCData emergency state is already set for the MCData client, the MCData client sets the emergency indicator in the request.

2. The MCData client sends the MCData file upload request to the MCData server. This request contains information about the MCData client (including IP address and port to be used for the file upload), and the target MCData content server (including associated URI or IP address, and port).

3. The MCData server verifies that the corresponding MCData client is authorized to upload files to the corresponding MCData content server.

4. If the MCData client is authorized for the file upload, the MCData server sends a request to the 3GPP system for the allocation of network resources with the required QoS for the corresponding file upload communication between the MCData client and the MCData content server. For that, the MCData server performs policy and charging control (PCC) procedures, e.g., over the Rx reference point as described in 3GPP TS 23.203 [14] for the case of an EPS system.

5. The MCData server sends a MCData file upload response to the MCData client indicating if it can proceed with the file upload to the MCData content server.

6. The media storage client on the MCData client sends an MCData upload data request to the media storage function on the MCData content server to upload the file.

7. The MCData content server provides an MCData upload data response to the MCData client indicating if the file was successfully stored (along with file URL) or failure.

8. The MCData client provides to the MCData server an MCData file upload completion status indicating that the file upload is completed.

9. Based on the MCData file upload completion status, the MCData server requests to the 3GPP system to release the network resources allocated for the corresponding file upload.

7.5.2.3 File download using HTTP

7.5.2.3.1 General

The media storage client uses HTTP for a standalone data file download from the MCData content server.

7.5.2.3.2 Procedure for file download from the MCData content server

The procedure in figure 7.5.2.3.2-1 describes the case where an MCData user is downloading a file from the media storage function of the MCData content server.

Pre-conditions:

1. The MCData user on the media storage client is registered for receiving MCData service.

Figure 7.5.2.3.2-1: File download using HTTP

1. The user at the media storage client initiates a file download request available at the indicated URL.

2. The file available at the URL (received in MCData FD request or MCData group standalone FD request) is requested to be downloaded by the media storage client from the media storage function on the MCData content server using a MCData download data request. If emergency indicator is set in received in MCData FD request or MCData group standalone FD request, the media storage client sets emergency indicator in MCData download data request.

NOTE: The media storage client can perform partial download requests to complete the missing parts after an incomplete file transfer.

3. The media storage function on the MCData content server may apply reception control policy and provides a MCData download data response including the file to the media storage client.

7.5.2.3.3 Procedure for file download including request of network resources with required QoS

The procedure in figure 7.5.2.3.3-1 describes the case where an MCData client sends a request to the MCData server for the download of a file from the media storage client on the MCData client to the media storage function on the MCData content server. The MCData server can, therefore, request network resources with the required QoS for the corresponding file download.

Pre-conditions:

1. The MCData user on the MCData client is registered on the MCData server for receiving MCData service.

2. The MCData client has been requested to download a file using HTTP and has received the corresponding file URL (via an MCData FD request or MCData group standalone FD request).

3. The MCData client is required to download a file from the MCData content server over network resources with required QoS.

NOTE 1: It is implementation specific whether an MCData system enables that network resources with required QoS are required for file downloads.

4. The MCData client knows its IP address/port to be used for the file download as well as the URI or IP address/port of the target MCData content server.

NOTE 2: How the MCData client knows the IP addresses and ports to be used for the file download is implementation specific and out of the scope of this specification.

Figure 7.5.2.3.3-1: File download using HTTP over network resources with required QoS

1. The MC user on the MCData client intends to download a file from the MCData content server based on a received MCData FD request or MCData group standalone FD request. If the MCData emergency state is already set for the MCData client, the MCData client sets the emergency indicator in the request.

2. The MCData client sends the MCData file download request to the MCData server. This request contains information about the MCData client (including IP address and port to be used for the file download), and the target MCData content server (including associated URI or IP address, and port). The request also contains the corresponding file URL on the MCData content server.

3. The MCData server may verify, based on the received file URL, whether the file is available in the MCData content server via the MCData-FD-5 reference point. For that, the MCData server sends an MCData file availability request to the MCData content server. Upon the receipt of the request, the MCData content server provides an MCData file availability response to the MCData server. If the MCData server identifies that the corresponding file is not available in the MCData content server, the MCData server provides a response to the MCData client indicating that the file download request cannot proceed due to the unavailability of the file in the MCData content server.

4. The MCData server verifies that the corresponding MCData client is authorized to download the file from the corresponding MCData content server.

5. If the MCData client is authorized for the file download, the MCData server sends a request to the 3GPP system for the allocation of network resources with the required QoS for the corresponding file download communication between the MCData client and the MCData content server. For that, the MCData server performs policy and charging control (PCC) procedures, e.g., over the Rx reference point as described in 3GPP TS 23.203 [14] for the case of an EPS system.

6. The MCData server sends a MCData file download response to the MCData client indicating whether it can proceed with the file download from the MCData content server.

7. The media storage client on the MCData client sends an MCData download data request to the media storage function on the MCData content server to download the corresponding file.

8. The MCData content server provides an MCData download data response to the MCData client including the file for the case of a successful response.

9. The MCData client provides to the MCData server an MCData download completed report indicating that the file download is completed.

10. Based on the MCData download completed report, the MCData server requests to the 3GPP system to release the network resources allocated for the corresponding file download.

7.5.2.4 One-to-one file distribution using HTTP

7.5.2.4.1 General

The MCData client uses HTTP file distribution to download a file that is uploaded by another MCData client. The procedure is appropriate for both mandatory and non-mandatory download cases. The target MCData user may be addressed using the functional alias that can be shared with other MCData users.

7.5.2.4.2 Procedure for single MCData system

The procedure in figure 7.5.2.4.2-1 describes the case where a MCData user is initiating one-to-one data communication for sending file to the other MCData user, with or without download completed report request.

Pre-conditions:

1. The MCData users on the MCData client 1 and the MCData client 2 are already registered for receiving MCData service.

2. The file to be distributed is uploaded to media storage function on MCData content server using the procedures defined in subclause 7.5.2.2.

3. The MCData client may have activated functional alias to be used.

4. The MCData server has subscribed to the MCData functional alias controlling server within the MC system for functional alias activation/de-activation updates.

Figure 7.5.2.4.2-1: One-to-one file distribution using HTTP

1. The user at the MCData client 1 initiates a file distribution request to the chosen MCData user.

2. The MCData client 1 sends a MCData FD request towards the MCData server. The MCData FD request contains content payload in the form of file URL and may contain the file metadata information. The MCData FD request contains one MCData user for one-to-one data communication as selected by the user at MCData client 1. The MCData FD request contains conversation identifier for message thread indication. The MCData FD request may include additional implementation specific information in the application metadata container. If MCData user at MCData client 1 has requested to mandatory download at the recipient side, then MCData FD request contains mandatory download indication. If the MCData user at MCData client has requested to deposit the file content into his/her MCData message store account, then MCData FD request contains deposit file indication set. The MCData FD request may contain download completed report indication if selected by the user at MCData client 1. The MCData user at MCData client 1 may include a functional alias within the FD data transfer and may address the target MCData client 2 using a functional alias.

a) If the MCData user at the MCData client 1 initiates an MCData emergency file distribution using HTTP or MCData emergency state is already set for the MCData client 1 (due to previously triggered MCData emergency alert):

i) The MCData FD request shall contain emergency indicator; and

ii) If MCData emergency state is not set already, MCData client 1 sets its MCData emergency state. The MCData emergency state of MCData client 1 is retained until explicitly cancelled by the user of MCData client 1.

NOTE 1: While MCData client 1 is in the emergency state, all types of MCData one-to-one and group communications initiated by MCData client 1 are initiated as MCData emergency communications.

3. MCData server checks whether the MCData user at MCData client 1 is authorized to send MCData FD request and that the size of the file is below maximum data size for FD from the service configuration. MCData server verifies whether the provided functional alias of MCData client 1, if present, can be used and has been activated for the user. If functional alias is used to address that target MCData user, the MCData server resolves the functional alias to the corresponding MCData IDs for which the functional alias is active and proceed with step 4 otherwise proceed with step 6.

NOTE 2: If the MCData server detects that the functional alias used as the target of the MCData FD request is simultaneously active for multiple MCData users, then the MCData server can proceed by selecting an appropriate MCData ID based on some selection criteria. The selection of an appropriate MCData ID is left to implementation. These selection criteria can include rejection of the MCData FD request, if no suitable MCData ID is selected.

5. The MCData server responds back to MCData client 1 with a functional alias resolution response message that contains the resolved MCData ID.

6. If the MCData server replies with a MCData functional alias resolution response message, the MCData client 1 assumes the MCData FD request in step 2 is rejected and sends a new MCData FD request towards the resolved MCData ID.

7. MCData server initiates the MCData FD request towards MCData client 2. The MCData FD request towards the MCData user contains an emergency indicator if it is present in the received MCData FD request from MCData client 1. If the deposit file indication information element is set to true in the received MCData FD request, MCData server shall follow the procedure as defined in the subclause 7.13.3.8 with the retrieve file indication element set to true while depositing this MCData communication to the MCData message store account of the user at MCData client 1.

NOTE 3: MCData client 2 does not set its emergency state as a result of receiving the MCData FD request containing the emergency indicator.

8. The receiving MCData client 2 notifies the user about the incoming MCData FD request (including file metadata, if present) which may be either accepted or rejected or ignored.

9. The MCData user 2 may provide a response (accept or reject) or not (ignore) to the notification, then MCData client 2 sends the MCData FD response to the MCData server. The MCData client 2 automatically sends an accepted MCData FD response when the received request includes a mandatory download indication.

10. The MCData server forwards the MCData FD response to the MCData client 1.

11. The Media storage client on the MCData client 2 downloads the file from the MCData content server using the procedures defined in subclause 7.5.2.3, either automatically (for mandatory download) or based upon the MCData user 2 subsequent action. The MCData client 2 records file download completed and notifies the MCData user 2.

12. The MCData client 2 provides an MCData download completed report for reporting file download completed, if requested by the user at MCData client 1.

13. The received MCData file download completed report from the MCData client 2 may be stored by the MCData server for download history interrogation from authorized MCData users. The MCData download completed report is sent by the MCData server to the MCData user at MCData client 1, if requested by the MCData client 1.

7.5.2.4.3 Procedure with interconnection between MCData systems

The procedure in figure 7.5.2.4.3-1 describes the case where a MCData user initiates a one-to-one data communication for sending a file to another MCData user where that other MCData user is receiving MCData service on a partner MCData system, and where interconnection is in use between the two MCData systems. In this procedure, the file has not previously been downloaded in the partner MC system.

Pre-conditions:

1. The MCData users on the MCData client 1 and the MCData client 2 are already service authorized and receiving MCData service. MCData client 1 is receiving service on its primary MCData system, and MCData client 2 is receiving MCData service in the partner MCData system of MCData client 1.

2. The file to be distributed has been uploaded to the media storage function on the MCData content server in the primary MCData system of MCData client 1 using the procedures defined in subclause 7.5.2.2.

3. There is a service agreement between the primary and partner MCData systems to allow files to be shared between MCData content servers in the two systems.

4. The MCData client may have an activated functional alias to be used.

5. The MCData server may have subscribed to the MCData functional alias controlling server within the MC system for functional alias activation/de-activation updates.

Figure 7.5.2.4.3-1: One-to-one file distribution using HTTP with interconnection

1. The user at the MCData client 1 initiates a file distribution request to the MCData user at MCData client 2.

2. MCData client 1 sends an MCData FD request towards the primary MCData server. The MCData FD request contains content payload in the form of a file URL with the necessary access authorization information and may contain the file metadata information. The MCData FD request indicates the target MCData user for the one-to-one data communication. The MCData FD request contains a conversation identifier for message thread indication. If the MCData user at MCData client 1 has requested to mandatory download at the recipient side, then the MCData FD request contains the mandatory download indication. The MCData FD request may contain a request for a download completed report indication if selected by the user at MCData client 1. The MCData user at MCData client 1 may include a functional alias within the FD data transfer and may address the target MCData client 2 using a functional alias.

3. MCData server checks whether the MCData user at MCData client 1 is authorized to send the MCData FD request and that the size of the file is below maximum data size for FD from the service configuration. MCData server verifies whether the provided functional alias of MCData client 1, if present, can be used and has been activated for the user.

4. The MCData server may verify whether the corresponding file is available in the MCData content server via the MCData-FD-5 reference point using the received file URL in the MCData FD request. For that, the MCData server sends an MCData file availability request to the MCData content server. Upon the receipt of the request, the MCData content server provides an MCData file availability response to the MCData server. If the MCData server identifies that the corresponding file is not available in the MCData content server, the MCData server provides a response to the MCData client 1 indicating that the file distribution request cannot proceed due to the unavailability of the file in the MCData content server.

5. The MCData server in the primary MCData system initiates the MCData FD request towards the MCData server in the partner MCData system, which contains the URL of the file which is stored in the primary MCData content server. The request includes the necessary access authorization information as MCData client 2 will retrieve the file while receiving service in the partner MCData system.

NOTE 1: The contents of and mechanisms to use the authorization information are outside the scope of the present document.

NOTE 2: With the use of the functional alias for addressing the target MCData clients, the partner MCData system is to be determined by the primary MCData system.

6. If functional alias is used to address that target MCData user, the MCData server in the partner MCData system resolves the MCData IDs of the functional alias. The resulting list contains all associated MCData IDs/MCData users that may share this functional alias. The MCData server in the partner MCData system now checks which MCData users have FD capabilities and which are authorized to receive a file. The partner MCData server sends the MCData FD request to the MCData users determined. The file URL being provided in MCData FD request to the MCData users determined is prepended with server URI of the partner MCData content server, such that the URL identifies a file location in the partner MCData content server.

NOTE 3: Determination of the target MCData client is based on the associated MCData IDs that share a functional alias and other criteria.

7. The receiving MCData client 2 may notify the user about the incoming MCData FD request (including file metadata, if present) which may be either accepted, rejected or ignored.

8. The MCData user 2 may provide a response (accept or reject) or not (ignore) to the notification, then the MCData client 2 sends the MCData FD response to the partner MCData server. The MCData client 2 automatically sends an accepted MCData FD response when the received request includes a mandatory download indication.

9. The partner MCData server forwards the MCData FD response to the MCData server in the primary MCData system.

10. The primary MCData server forwards the MCData FD response to MCData client 1.

11. MCData client 2 requests the file from the partner MCData content server.

NOTE 4: Step 11 may occur any time after step 8, before or after steps 9 and 10.

12. The partner MCData content server checks whether the file is stored locally, and if this is not the case, sends an MCData file retrieve request to the primary MCData content server. The MCData file retrieve request contains the URL of the file location in the primary MCData system, generated by removing the prepended local path from the requested URL.

NOTE 5: The means of proving authorization for the request is outside the scope of the present document.

13. The primary MCData content server responds to the partner MCData content server with an MCData file retrieve response which contains the content of the file to be retrieved. File metadata may include the lifetime of the file. The primary MCData content server records that the file has been sent to the indicated partner MCData system.

NOTE 6: The partner MCData content server may store the local copy of the file in case future requests arise until the expiry time sent from primary MCData system for the file is reached or until a request is received to delete the file.

14. The partner MCData content server sends the file to MCData client 2 in the MCData download data response. MCData client 2 records file download completed and notifies MCData user 2.

15. The MCData client 2 provides an MCData download completed report for reporting file download completed, if this was requested by the user at MCData client 1 in the initial MCData FD request.

16. The MCData download completed report is sent to the primary MCData server. The partner MCData server may store the download completed report for download history interrogation from authorized MCData users in the partner MCData system.

17. The received MCData download completed report is sent by the primary MCData server to the MCData user at MCData client 1, if requested by the MCData client 1. The MCData file download completed report from the MCData client 2 may be stored by the primary MCData server for download history interrogation from authorized MCData users in the primary MCData system.

7.5.2.5 One-to-one file distribution using media plane

7.5.2.5.1 General

The MCData client uses the media plane for a standalone data file download from another MCData client. The procedure is appropriate for both mandatory and non-mandatory download cases. The target MCData user may be addressed using the functional alias that can be shared with other MCData users.

7.5.2.5.2 Procedure

The procedure in figure 7.5.2.5.2-1 describes the case where an MCData user is initiating one-to-one data communication for sending file to the other MCData user, with or without download completed report request.

Pre-conditions:

1. The MCData users on the MCData client 1 and the MCData client 2 are already registered for receiving MCData service.

2. Optionally, the MCData client may have an activated functional alias to be used.

3. The MCData server has subscribed to the MCData functional alias controlling server within the MC system for functional alias activation/de-activation updates.

Figure 7.5.2.5.2-1: One-to-one file distribution using media plane

1. The user at the MCData client 1 initiates a file distribution request to the chosen MCData user.

2. MCData client 1 sends a MCData FD request towards the MCData server. File metadata information is included in the SDP. The MCData FD request contains one MCData user for one-to-one data communication as selected by the user at MCData client 1. The MCData FD request contains conversation identifier for message thread indication. The MCData FD request may include additional implementation specific information in the application metadata container. MCData FD request may contain mandatory download indication. The MCData FD request may contain download completed report indication if selected by the user at MCData client 1. MCData user at MCData client 1 may include a functional alias within the FD data transfer and may address the target MCData client 2 using a functional alias.

a) If the MCData user at the MCData client 1 initiates an MCData emergency file distribution communication or MCData emergency state is already set for the MCData client 1 (due to previously triggered MCData emergency alert):

i) The MCData FD request shall contain emergency indicator; and

NOTE 1: While MCData client 1 is in the emergency state, all types of MCData one-to-one and group communications initiated by MCData client 1 are initiated as MCData emergency communications.

3. MCData server checks whether the MCData user at MCData client 1 is authorized to send MCData FD request. MCData server verifies whether the provided functional alias of MCData client 1, if present, can be used and has been activated for the user. If functional alias is used to address that target MCData user, the MCData server resolves the functional alias to the corresponding MCData ID(s) for which the functional alias is active and proceed with step 4 otherwise proceed with step 6.

4. The MCData server responds back to MCData client 1 with a functional alias resolution response message that contains the resolved MCData ID.

5. If the MCData server replies with a MCData functional alias resolution response message, the MCData client 1 assumes the MCData FD request in step 2 is rejected and sends a new MCData FD request towards the resolved MCData ID.

6. The MCData server also applies transmission and reception control and the necessary policy to ensure that appropriate data is transmitted between the MCData UEs.

7. MCData server initiates the MCData FD request towards the MCData users determined. The MCData FD request towards the MCData user contains the emergency indicator if it is present in the received MCData FD request from MCData client 1.

NOTE 3: MCData client 2 does not set its emergency state as a result of receiving the MCData FD request containing the emergency indicator.

8. The receiving MCData client 2 notifies the user about the incoming MCData FD request which may be either accepted or rejected or ignored. If the request includes mandatory download indication in the MCData FD request an accepted response is assumed.

9. If the target MCData user 2 provides a response (accept or reject) to the notification, then MCData client 2 sends the MCData FD response to the MCData server. MCData client 2 automatically sends accepted MCData FD response when the incoming request included mandatory download indication.

10. MCData server forwards the MCData FD response from MCData client 2 back to MCData client 1.

11. MCData client 1 distributes the file over the established media plane to MCData server.

12. MCData server distributes the file received from MCData client 1 to MCData client 2 over the established media plane. File download report is shared by the MCData client 2, if requested by the user at MCData client 1. After file transaction is completed, the media plane is released. The MCData client 2 records file download completed and notifies MCData user 2.

NOTE 4: MCData server is not required to wait for the complete download of file from MCData client 1 prior to initiating file distribution to MCData client 2.

13. MCData client 2 initiates a MCData download completed report for reporting file download completed, if requested by the user at MCData client 1.

14. The MCData file download completed report from MCData client may be stored by the MCData server for download history interrogation from the authorized MCData users. MCData download completed report is sent by the MCData server to the user at MCData client 1.

7.5.2.6 Group standalone file distribution using HTTP

7.5.2.6.1 General

The initiation of a group standalone FD using HTTP to a selected group, results in affiliated group members receiving the file data.

7.5.2.6.2 Procedure

The procedure in figure 7.5.2.6.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 from the MCData user.

Pre-conditions:

1. The MCData users on the MCData clients 1 to n belong to the same MCData group and are already registered for receiving MCData service and affiliated to the group.

2. 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.

3. The MCData client may have an activated functional alias to be used.

4. The MCData server has subscribed to the MCData functional alias controlling server within the MC system for functional alias activation/de-activation updates.

Figure 7.5.2.6.2-1: Group standalone FD using HTTP

1. The user at the MCData client 1 initiates a file distribution request to multiple MCData users selecting a pre-configured group (identified by MCData group ID) and optionally particular members from that group.

2. The MCData client 1 sends a MCData group standalone FD request towards the MCData server. The MCData FD request contains content payload in the form of file URL and may contain the file metadata information. The MCData group standalone data request contains either the selected MCData group ID or the target recipients as selected by the user at MCData client 1. The MCData group standalone FD request contains conversation identifier for message thread indication. The MCData group standalone FD request may include additional implementation specific information in the application metadata container. If MCData user at MCData client 1 has requested to mandatory download at the recipient side, then MCData group standalone FD request contains mandatory download indication. The MCData group standalone FD request may contain a download completed report indication if selected by the user at MCData client 1. The MCData user at MCData client 1 may include a functional alias within the FD data transfer. If the MCData user at MCData client has requested to deposit the file content into his/her MCData message store account, then MCData FD request contains deposit file indication set.

If the MCData user at MCData client 1 initiates an MCData emergency FD communication or the MCData emergency state is already set for the MCData client 1 (due to a previously triggered MCData emergency alert):

i) the MCData group standalone FD request shall contain an emergency indicator;

ii) the MCData group standalone FD request shall set an alert indicator if configured to send an MCData emergency alert while initiating an MCData group standalone FD request for the emergency FD communication; and

iii) if the MCData emergency state is not set already, MCData client 1 sets its MCData emergency state. The MCData emergency state of MCData client 1 is retained until explicitly cancelled by the user of MCData client 1.

NOTE 1: While MCData client 1 is in the emergency state, all types of MCData one-to-one and group communications initiated by MCData client 1 are initiated as MCData emergency communications.

If the MCData user at MCData client 1 initiates an MCData imminent peril FD communication:

i) the MCData group standalone FD request shall contain an imminent peril indicator.

2a. If either emergency indicator or imminent peril indicator is present in the received MCData group standalone FD request, the MCData server implicitly affiliates MCData client 1 to the MCData group if the client is not already affiliated.

3. MCData server checks whether the MCData user at MCData client 1 is authorized to send an MCData group standalone FD request and that the size of the file is below maximum data size for FD from the group configuration. MCData server verifies whether the provided functional alias, if present, can be used and has been activated for the user. If the MCData group ID is used, the MCData server resolves the MCData group ID to determine the members of that group and their affiliation status, based on the information from the group management server.

i) If an emergency indicator is present in the received MCData group standalone FD request and if the MCData group is not in the in-progress emergency state, the MCData group is considered to be in the in-progress emergency state until cancelled; and

NOTE 2: While the MCData group is in the in-progress emergency state, all types of MCData communications within the group are processed as emergency group communications by the MCData server. MCData group members that are not in the emergency state do not indicate emergency in group communication requests.

ii) If an imminent peril indicator is present in the received MCData group standalone FD request and if the MCData group is not in the in-progress imminent peril state, the MCData group is considered to be in the in-progress imminent peril state until cancelled.

4. The MCData server may verify whether the corresponding file is available in the MCData content server (not shown in the figure) via the MCData-FD-5 reference point using the received file URL in the MCData group standalone FD request. For that, the MCData server sends an MCData file availability request to the MCData content server. Upon the receipt of the request, the MCData content server provides an MCData file availability response to the MCData server. If the MCData server identifies that the 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 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.

5. MCData server initiates the MCData group standalone FD request towards each MCData user determined in step 3. The MCData group standalone FD request towards each MCData client contains:

i) an emergency indicator if it is present in the received MCData group standalone FD request from the MCData client 1;

ii) an imminent peril indicator if it is present in the received MCData group standalone FD request from the MCData client 1; and

iii) an alert indicator if requested to initiate an emergency alert in the received MCData group standalone FD request from the MCData client 1.

6. The receiving MCData clients 2 to n notify the user about the incoming MCData group standalone FD request (including file metadata, if present) which may be either accepted or rejected or ignored.

7. 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 MCData group standalone FD response to the MCData server. MCData client 2 to n automatically sends accepted MCData group standalone FD response when the incoming request included mandatory download indication.

8. The MCData server forwards the MCData group standalone FD responses to the MCData client 1.

NOTE 3: Step 8 can occur at any time following step 5, and prior to step 9 depending on the conditions to proceed with the file transmission.

9. The media storage client on the MCData client(s) accepting the request downloads the file from the MCData content server (not shown in the figure) using the procedures defined in subclause 7.5.2.3, either automatically (for mandatory download) or based upon the MCData user subsequent action. The MCData clients successfully receiving the file through the media storage clients, record file download completed and notify the MCData users.

10. The MCData clients, receiving the file through the media storage client, provide MCData download completed reports for reporting file download completed, if requested by the user at MCData client 1.

11. The MCData file download completed reports from MCData clients may be stored by the MCData server for download history interrogation from the authorized MCData users. The MCData file download completed report from each MCData user may be aggregated.

12. Aggregated or individual MCData download completed reports are sent by the MCData server to the MCData user at MCData client 1, if requested by the MCData client 1.

7.5.2.7 Group standalone file distribution using media plane

7.5.2.7.1 General

The initiation of a group standalone FD using media plane to a selected group, results in affiliated group members receiving the file data.

7.5.2.7.2 Procedure

The procedure in figure 7.5.2.7.2-1 describes the case where an MCData user is initiating group standalone data communication for sending 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. Optionally, the MCData client may have an activated functional alias to be used.

3. The MCData server has subscribed to the MCData functional alias controlling server within the MC system for functional alias activation/de-activation updates.

Figure 7.5.2.7.2-1: Group standalone FD using media plane

2. MCData client 1 sends a MCData group standalone FD request towards the MCData server. File metadata information is included in the SDP. The MCData group standalone data request contains target recipient(s) as selected by the user at MCData client 1. The MCData group standalone FD request contains conversation identifier for message thread indication. The MCData group standalone FD request may include additional implementation specific information in the application metadata container. MCData group standalone FD request may contain mandatory download indication. The MCData group standalone FD request may contain download completed report indication if selected by the user at MCData client 1. MCData user at MCData client 1 may include a functional alias within the FD data transfer.

If the MCData user at MCData client 1 initiates an MCData emergency file distribution communication or the MCData emergency state is already set for the MCData client 1 (due to a previously triggered MCData emergency alert):

i) the MCData group standalone FD request shall contain an emergency indicator;

iii) 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.

NOTE 1: While MCData client 1 is in the emergency state, all types of MCData one-to-one and group communications initiated by MCData client 1 are initiated as MCData emergency communications.

If the MCData user at MCData client 1 initiates an MCData imminent peril file distribution communication:

i) the MCData group standalone FD request shall contain an imminent peril indicator.

2a. If either emergency indicator or imminent peril indicator is present in the received MCData group standalone data request, the MCData server implicitly affiliates MCData client 1 to the MCData group if the client is not already affiliated.

3. MCData server checks whether the MCData user at MCData client 1 is authorized to send MCData group standalone FD request. MCData server verifies whether the provided functional alias, if present, can be used and has been activated for the user. The MCData server resolves the MCData group ID to determine the members of that group and their affiliation status, based on the information from the group management server.

4. The MCData server also applies transmission and reception control and the necessary policy to ensure that appropriate data is transmitted between the MCData UEs.

5. MCData server initiates the MCData group standalone FD request towards each MCData user determined in step 3. The MCData group standalone data request towards each MCData client contains:

i) an emergency indicator if it is present in the received MCData group standalone FD request from the MCData client 1;

ii) an imminent peril indicator if it is present in the received MCData group standalone FD request from the MCData client 1; and

iii) an alert indicator if requested to initiate an emergency alert in the received MCData group standalone FD request from the MCData client 1.

6. The receiving MCData clients 2 to n notifies the user about the incoming MCData group standalone FD request which may be either accepted or rejected or ignored. If the request includes mandatory download indication in the MCData group standalone FD request an accepted response is assumed.

7. If the target MCData user on MCData clients 2 to n provides a response (accept or reject) to the notification, then the respective MCData client sends the MCData group standalone FD response to the MCData server. MCData client 2 to n automatically sends accepted MCData group standalone FD response when the incoming request included mandatory download indication.

8. MCData server forwards the MCData group standalone FD response to the MCData client 1.

NOTE 3: Step 8 can occur at any time following step 5, and prior to step 9 depending on the conditions to proceed with the file transmission.

9. MCData client 1 and MCData server have successfully established media plane for file transmission and the MCData client 1 transmits the file data.

10. MCData server distributes the file received from MCData client 1 to MCData clients 2 to n over the established media plane. Distribution of file can be via unicast or via MBMS bearer(s). For distribution via MBMS bearer(s), the procedure described in subclause 7.3 Use of MBMS transmission (on-network) is executed. File download report is shared by the receiving MCData clients, if requested by the user at MCData client 1. After file transaction is completed, the media plane is released.

NOTE 4: MCData server is not required to wait for the complete download of file from MCData client 1 prior to initiating file distribution to MCData client 2.

11. The MCData clients successfully receiving the file, records file download completed and notifies MCData user.

12. MCData client 2 initiates a MCData download completed report for reporting file download completed, if requested by the user at MCData client 1.

13. The MCData file download completed report(s) from MCData client(s) may be stored by the MCData server for download history interrogation from the authorized MCData users. The MCData file download completed report from each MCData user may be aggregated.

14. Aggregated or individual MCData file download completed report is sent to the disposition requesting user at MCData client 1.

7.5.2.8 File removal using HTTP by authorized user

7.5.2.8.1 General

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 system

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.

Figure 7.5.2.8.2-1: File removal using HTTP by authorised user

1. The user on the media storage client decides to remove a file that was previously uploaded.

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.

3. The MCData content server remove the file indicated by the URL.

4. The MCData content server informs the media storage client if the file is successfully removed.

Editor’s note: It is FFS if and how the recipients of the file URL need to be notified if the file is no longer available to be downloaded.

7.5.2.8.3 Procedure for interconnection between MCData systems

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.

Figure 7.5.2.8.3-1: File removal using HTTP by authorized user

1. The user on the media storage client decides to remove a file that was previously uploaded.

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.

3. The primary MCData content server removes the file indicated by the URL.

NOTE: Step 3 may occur at any time following step 2 and before step 6.

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.

5. The partner MCData content server removes the file indicated by the URL.

6. The partner MCData content server informs the primary MCData content server that the file has been successfully removed.

7. The primary MCData content server informs the media storage client if the file is successfully removed.

Editor’s note: It is FFS if and how the recipients of the file URL need to be notified if the file is no longer available to be downloaded

7.5.2.9 Void

7.5.2.10 Group standalone file distribution using the MBMS download delivery method

7.5.2.10.1 General

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 3GPP TS 26.346 [21].

7.5.2.10.2 Procedure

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.

Figure 7.5.2.10.2-1: Group standalone FD using the MBMS download delivery method

1-3. Steps 1-3 are the same as in the procedure for Group standalone FD using HTTP (7.5.2.6).

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 3GPP TS 26.348 [19]), 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 3GPP TS 26.348 [19], 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.

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.

6. The receiving MCData clients 2 to n notify the users about the incoming MCData group standalone FD request (including file metadata, if present).

7. The MCData clients 2 to n automatically send accepted MCData group standalone FD response when the incoming request included mandatory download indication.

NOTE 1: When the UE is in idle mode, MCData clients may skip step 8.

NOTE 2: If the pull ingest mode was defined in step 5 and the file list has not been provided yet, the MCData server updates the MBMS session with the file list. If the push ingest mode was defined, the MCData server can start pushing the file for distribution over MBMS.

8. The MCData server forwards the MCData group standalone FD responses to the MCData client 1.

NOTE 3: Step 8 can occur at any time following step 6, and prior to step 10 depending on the conditions to proceed with the file transmission.

9. The MCData clients receive the file delivered over MBMS.

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.

NOTE 4: If the file is not successfully received over MBMS, e.g. due to a poor MBMS reception quality, the media storage client of the MCData client(s) can download the file using the procedure defined in subclause 7.5.2.3.

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.

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.

13. Aggregated or individual MCData download completed reports are sent by the MCData server to the MCData user at MCData client 1.

7.5.2.11 One-to-one FD communication upgrade to an emergency FD communication

7.5.2.11.1 General

This clause is for adding procedures related to upgrading an existing one-to-one FD communication to an emergency one-to-one FD communication.

7.5.2.11.2 Procedure

The procedure in figure 7.5.2.11.2-1 describes the case where an authorized MCData user is upgrading a MCData one-to-one FD communication to a MCData emergency one-to-one FD communication. This procedure is applicable only when MCData one-to-one file distribution communication is established as described in subclause 7.5.2.5 "One-to-one file distribution using media plane".

Pre-conditions:

1. Both members of the one-to-one FD communication belong to the same MCData system.

2. One-to-one FD communication is already in progress.

Figure 7.5.2.11.2-1 One-to-one FD communication upgrade to an emergency one-to-one FD communication

1. The MCData user at MCData client 1 initiates an emergency. MCData client 1 sets its MCData emergency state. The MCData emergency state of MCData client is retained until explicitly cancelled by the user of MCData client 1.

NOTE 1: While MCData client 1 is in the emergency state, all types of MCData one-to-one and group communications initiated by MCData client 1 are initiated as MCData emergency communications.

2. MCData client 1 requests the MCData server to upgrade the MCData one-to-one FD communication to in-progress emergency by sending a MCData one-to-one FD upgrade request.

3. The MCData server sends the MCData one-to-one FD upgrade request towards MCData client 2.

NOTE 2: MCData client 2 does not set its emergency state as a result of receiving the MCData one-to-one FD upgrade request containing the emergency indicator.

4. The MCData user of MCData client 2 is notified of the in-progress emergency of the MCData emergency one-to-one FD communication.

5. The MCData client 2 acknowledges the MCData one-to-one FD upgrade request and sends MCData one-to-one FD upgrade response to the MCData server.

6. The MCData server adjusts the priority of the underlying bearer for both participants of the MCData one-to-one FD communication. The priority is retained until the communication ends.

7. The MCData server sends MCData one-to-one FD upgrade response to MCData client 1.

8. MCData client 1 and MCData client 2 continue with the MCData one-to-one FD communication, which has been transformed into an MCData emergency one-to-one FD communication.

7.5.2.12 Group FD communication upgrade to an emergency group FD communication

7.5.2.12.1 General

This clause is for adding procedures related to upgrading an existing MCData group FD communication to an MCData emergency group FD communication.

7.5.2.12.2 Procedure

The procedure in figure 7.5.2.12.2-1 describes the case where an authorized MCData user is upgrading an onging MCData group FD communication to an MCData emergency group FD communication. This procedure is applicable only when group MCData FD communication is established as described in subclause 7.5.2.7 "Group standalone file distribution using media plane".

NOTE 1: For simplicity, a single MCData server is shown in place of a user home MCData server and a group hosting MCData server.

Pre-conditions:

1. The MCData group is previously defined on the group management server with MCData client 1, MCData client 2 and MCData client 3 are affiliated to that MCData group.

2. All members of the MCData group belong to the same MCData system.

3. An MCData group FD communication is already in progress.

4. The initiating MCData client 1 has been configured to send an MCData emergency alert when upgrading an MCData emergency group communication.

Figure 7.5.2.12.2-1: MCData group FD communication upgraded to an MCData emergency group FD communcation

1. The MCData user at MCData client 1 initiates a group emergency. MCData client 1 sets its MCData emergency state. The MCData emergency state of MCData client 1 is retained until explicitly cancelled by the user of MCData client 1.

NOTE 2: While MCData client 1 is in the emergency state, all types of MCData one-to-one and group communications initiated by MCData client 1 are initiated as MCData emergency communications.

2. MCData client 1 requests the MCData server to upgrade the MCData group to an in-progress emergency state by sending a MCData group FD upgrade request. The MCData client 1 sets the emergency indicator in the request. If configured to send an MCData alert when initiating an MCData emergency upgrade, the request also contains an indication that an MCData alert is to be initiated.

3. The MCData server sets the emergency state of the MCData group and adjusts the priority of the underlying bearer for all or selected participants in the MCData group FD communication that receive the communication over unicast.

NOTE 3: The determination of the selected participants whose bearers have to be upgraded is left to implementation.

NOTE 4: While the MCData group is in the in-progress emergency state, all types of MCData communications within the group are processed as emergency group communications by the MCData server. MCData group members that are not in the emergency state do not indicate emergency in group communication requests.

4. MCData server sends the MCData group FD upgrade request towards the MCData clients of each of those affiliated MCData group members. The request contains an indication of an MCData emergency alert if the request from the originator indicated MCData emergency alert.

5. MCData users are notified of the in-progress emergency state of the MCData group.

6. The receiving MCData clients send the MCData group FD upgrade response to the MCData server to acknowledge the MCData group emergency request. For a multicast call, these acknowledgements are not sent.

7. The MCData server sends the MCData group FD upgrade response to the MCData user 1 to confirm the upgrade request.

NOTE 5: Step 7 can occur at any time following step 3, depending on the conditions to proceed with the call.

MCData client 1, MCData client 2 and MCData client 3 continue with the MCData group FD communication, which has been transformed into an MCData emergency group FD communication.

7.5.2.13 Group FD communication in-progress emergency group state cancel

7.5.2.13.1 General

This clause describes procedures related to an MCData in-progress emergency group state cancel. The emergency state of the group can also be cancelled by the group SDS in-progress emergency state cancellation procedure in subclause 7.4.2.10.2, or by the emergency alert cancellation procedure specified in 3GPP TS 23.280 [16], subclause 10.10.1.2.2.2.

7.5.2.13.2 Procedure

The procedure in figure 7.5.2.13.2-1 describes the case where an authorized MCData user cancels MCData group’s in-progress emergency.

Pre-conditions:

1. The MCData group is previously defined on the group management server with MCData client 1, MCData client 2 and MCData client 3 affiliated to that MCData group.

2. All members of the MCData group belong to the same MCData system.

3. MCData group members have been notified about the in-progress emergency.

4. The MCData group is in the in-progress emergency state and has prioritized bearer support.

5. MCData client 1 previously initiated the in-progress emergency for the group.

Figure 7.5.2.13.2-1: MCData group FD in-progress emergency group state cancel

1. The user at the MCData client 1 initiates an MCData group FD in-progress emergency group state cancel.

NOTE 1: An MCData user authorized to cancel in-progress emergencies on the MCData group can also be authorised to cancel the MCData emergency alert in addition to the initiator. However, only the initiator can cancel the initiator’s local MCData emergency state.

2. The MCData client 1 sends an MCData group FD in-progress priority state cancel request to the MCData server. The MCData client 1 also resets emergency indicator in the request to inform MCData server about cancellation of in-progress emergency group state.

NOTE 2: If an MCData emergency alert relating to MCData client 1 is in effect together with an MCData in-progress emergency group state on the MCData group, the MCData emergency alert of MCData client 1 can be cancelled at the same time. In that case, the MCData group FD in-progress priority group state cancel request carries an indication that the emergency alert of MCData client 1 is also being cancelled.

NOTE 3: If an MCData group FD in-progress priority state cancel request is received by the MCData server while a group member that is in the emergency state is transmitting, the MCData group FD in-progress priority state cancel request is rejected by the MCData server.

3. The MCData server adjusts the priority of the underlying bearer; priority treatment is no longer required. The MCData server cancels/resets the emergency in-progress state of the MCData group.

4. The MCData server sends an MCData group FD in-progress priority state cancel request to the MCData group members.

5. MCData group members are notified of the MCData group FD in-progress emergency state cancel.

6. The receiving MCData clients send the MCData group FD in-progress priority state cancel response to the MCData server to acknowledge the MCData in-progress emergency group state cancel. For a multicast call scenario, these acknowledgements are not sent.

7. The MCData server sends the MCData group FD in-progress priority state cancel response to the MCData user 1 to confirm the MCData in-progress emergency group state cancel. If the MCData in-progress emergency group state cancel request (in step 2) contained the "Alert indicator" IE, the MCData client 1 resets its local emergency status.

NOTE 4: Step 7 can occur at any time following step 3, depending on the conditions to proceed with the call.

7.5.2.14 Group FD communication upgrade to an imminent peril group FD communication

7.5.2.14.1 General

This clause is for adding procedures related to an imminent peril group FD communication.

7.5.2.14.2 Procedure

This procedure is applicable only when group MCData communication is established as described in subclause 7.5.2.7 "Group standalone file distribution using media plane". The MCData service shall support the procedures and related information flows as specified in subclause 7.5.2.12 "Group FD communication upgrade to an emergency group FD communication" with the following clarifications:

– In step 2), the MCData client 1 sets the imminent peril indicator;

– In step 3), the bearers’ priority is adjusted as necessary, to correspond to an imminent peril priority which could be different than the setting used in the procedure in subclause 7.5.2.12; and

– In step 5), MCData users are notified of the in-progress imminent peril state of the MCData group.

7.5.2.15 Group FD communication in-progress imminent peril group state cancel

7.5.2.15.1 General

This clause is for adding procedures related to an imminent peril group state cancel.

7.5.2.15.2 Procedure

The MCData service shall support the procedures and related information flows as specified in subclause 7.5.2.13 "Group FD communication in-progress emergency group state cancel" with the following clarifications:

– In step 2), the MCData client 1 sets the imminent peril indicator; and

– In step 5), MCData users are notified of the in-progress imminent peril state cancel.