The MCData service supports the ability to transmit SDS messages automatically towards the selected recipient user (private communication) or members of the selected MCData group. The MCData server may still reject the sent message (e.g. if there is no authority to send). For MCData types other than SDS using signalling control plane, the MCData service invokes a transmission request grant approach before data is permitted to be transmitted. The MCData service provides configurable limits for the maximum amount of data for and/or maximum amount of time that an MCData user can transmit in a single request, which may be configured by the MCData administrator. For congestion control, related to transmission requests, the MCData service may perform the following:

• reject the data transmission requests and then shall notify the MCData user of the rejection;
• queue the data transmission requests; or
• at any time, withhold the permission to transmit data automatically.

The MCData service shall notify the transmitting MCData group member if there are no other MCData group members affiliated to the MCData group. The MCData service supports the lossless communication, and it can be configured by the MCData administrator for the private communication and group communication. The lossless communication can be supported only if the user has a valid and active MCData message store account. If the lossless communication is configured for private communication and if the MCData communication cannot be delivered to the MCData user (e.g. if the recipient is not available at the time of data delivery or network congestion), it shall be made available to the MCData user by storing it in the MCData user's personal account in the MCData message store. If a MCData group is configured for lossless communication, all members of the selected MCData group shall receive the MCData communication, at a time dependent on affiliation status. An affiliated group member of this MCData group shall receive the MCData communication when they are sent. A group member that is not affiliated during MCData communication, the MCData communication shall be made available by storing it in the group member's personal account in the MCData message store. If a MCData group is not configured for lossless communication, only the affiliated members of the selected MCData group shall receive the MCData communication. In order to support lossless communication, below are the conditions that needs to be satisfied:

• Lossless communication is provisioned
• MCData user has the valid MCData message store account
• Store communication into message store configuration parameter is enabled
• MCData user has requested to store the MCData communication into MCData message store

The MCData service shall support the ability to receive small amounts of data automatically. The MCData service may store data waiting for delivery in a temporary store, and notify availability to the receiving MCData users, i.e. deferred delivery. The data which is temporarily stored may be configured with "time to live" value, and subsequently, the data may be purged from the temporary store upon expiry of "time to live". When a MCData user has an active MCData message store account and has activated lossless communication, the MCData service deferred delivery shall not be used when the user is offline. The recipient individual user (private communication) or affiliated members of the MCData group(s) shall be notified of the list of available data either on request or periodically. The MCData service shall provide a mechanism for the MCData user to select data to be downloaded from the list corresponding to the temporary store, subject to limitations such as expiry time and size. The MCData service shall support the ability to automatically deliver files with a size less than a configured threshold value (i.e. auto-receive). The data size for auto-receive shall be configured by the MCData administrator.

The MCData service shall support SDS capability for one-to-one and group communications. The SDS capability shall support messages with a maximum payload of at least 1000 bytes. The supported message types shall include text, binary, or hyperlinks. Multiple message types may be interleaved within in a single message payload. The payload shall support inclusion of location information of the sending MCData user, with or without user or application provided data. The MCData service shall support messages to be sent over the signalling plane or the media plane. The SDS capability shall allow for multiple related messages to be correlated and sequenced within the MCData service. The MCData user shall be able to selectively request read and delivery receipt indication for the sent messages. The message delivery history information should be made available to an authorized MCData user. The MCData service may support aggregation of disposition notifications when SDS messages are sent to multiple recipients.

The MCData service shall support distribution of files for one-to-one and group communications. The MCData service shall allow the MCData user to send a file or a URL of a file to another MCData user. The source of the file can originate either from an MCData client or from a network functional entity. The generated URL shall be a reference to a stored file to allow for subsequent retrieval. The file storage policy may determine the availability of the file to be retrieved, and is subject to expiry time and size limitations. When the file delivery request is set by the sending user to mandatory download, the MCData service shall proceed to deliver the file to the recipient when possible. The file distribution mechanisms shall support both unicast and broadcast delivery methods. The MCData service shall support aggregation of download completed reports when files are distributed to multiple recipients. The MCData service shall support mechanisms for detection and recovery of lost data. A receiving MCData client should be able to:

• detect and report when a transfer did not complete properly and request retransmission;
• identify and re-request the missing parts of an incompletely received file; and
• accept partial retransmissions and use them to reconstitute the original file.

When employing MBMS delivery:

• MCData may use the MB2 interface specified in TS 23.468. See also Group Communication Delivery Method in TS 26.346; or
• if MBMS user services and Download Delivery Method (see TS 26.346) are utilized, MCData shall use the xMB interface specified in TS 26.348.

For the MBMS path, Figure 5.4-1 shows both the MB2 and the xMB interfaces.

The MCData service may support data streaming capability for one-to-one and group communications. The MCData service may allow the MCData user to send a data stream or a URL of a data stream to another MCData user. The source of the data stream can originate either from an MCData client or from a network functional entity. For a data stream originating at a network functional entity, the data stream may be provided by an MCData user. The data streaming mechanisms shall support both unicast and broadcast delivery methods. When the data streaming request is set to automatic reception, the MCData service may not require consent from the receiving MCData user. The MCData user may be able to apply controls (i.e. start, stop, cancel) to the streams, and on a per recipient basis. The stream may be terminated through an explicit user control (i.e. stop, cancel operation) or by reaching the end of the streamed content.

MCData groups may be configured with one or more MCData sub-services (e.g. SDS, FD, DS) as specified within the MCData service. When an MCData user affiliates to an MCData group, the MCData user is affiliated to each of those MCData sub-services configured in the MCData group. The list of MCData sub-services configured for an MCData group shall be included in the MCData group configuration data. MCData group affiliation shall be as specified in clause 5.2.5 of TS 23.280. In addition, the following requirements shall be fulfilled by the MCData service for MCData users affiliated to MCData groups:

• MCData users receive notifications for participating in MCData sub-services and invitations for their affiliated MCData group(s).
• MCData users select an affiliated MCData group to initiate a new message, file distribution, data stream, etc.
• MCData users receive messages, files, data streams, enhanced status updates, etc, from their affiliated MCData group(s).

The conversation management:

1. shall include a service indication for conversation management in each SDS and FD transaction.
2. may be comprised of SDS transactions or FD transactions or a combination of both.
3. shall include a conversation identifier in each SDS and FD transaction.
4. shall treat conversation between different set of users (either in one-to-one or group) as a separate conversation.
5. shall treat conversation between the same set of users (either in one-to-one or group), but with a different conversation identifier as a separate conversation.

Disposition requests and notifications can be sent "in-band" using the same mechanism used for transport of the data, or can be sent "out-of-band" when the mechanism used for transport of the data is no longer available. For standalone SDS and FD, the MCData UE shall use the signalling plane for disposition request and disposition notifications. For session SDS, the MCData UE shall use:

• the media plane for disposition request and disposition notifications; and
• the signalling plane for disposition notifications when the media plane is no longer available.

MCData message store is used by MCData users to store their MCData communications permanently; it shall provide secured storage area for each authorized MCData user having a user account. The storage area is identified by the MCData user's MCData ID. The MCData message store shall allow an MCData user to access only the storage area that he is authorized to access. A user (i.e. a dispatcher) other than the user account holder shall be able to access the account holder's storage area if authorized. During an active MCData communication, the participating function on the MCData server of a MCData user participant shall, if the configuration to store the MCData communication is enabled for and if requested by the MCData user, deposit messages and files exchanged in the conversation to the MCData user's storage area in the MCData message store. When depositing the MCData communication into the MCData message store, if no such MCData user account is available on the MCData message store the MCData server shall create the user's account first and then deposit the MCData communications. The MCData message store shall support user account creation and deposit MCData communications operations from the MCData server after successful authentication and authorization. The MCData message store shall support the message store client to retrieve, update, delete, search and synchronize MCData communications stored in the MCData message store, after successful authentication and authorization. The MCData user shall have an option if he wants to store the MCData communications in the MCData message store or not. Based on the request from MCData user, messages and files exchanged in an active MCData communication shall be stored as objects in the MCData message store. A stored object shall contain the following information:

1. The message or file itself; and
2. Associated metadata, consisting of:
   1. information retrieved from the information elements of the message or file, such as MCData IDs, Conversation identifier etc.; and
   2. other information, such as object identifier, content type (message or file), status ("seen", "received by", "read by", "downloaded by" etc).

If a file is distributed indirectly with a URL in a message, when this message is stored in the MCData user's account in the MCData message store, it could be stored as:

1. an object as the original message with the URL; or
2. an object as the message with a revised URL that the URL indicates where the file, retrieved from the MCData content server, is stored separately in the MCData user's storage account. With proper security and authorization, this URL can be accessible by other network entities such as the MCData content server.

When a MCData user logs onto a UE with successful authentication and authorization and obtains the user service profile, the message store client on the UE shall synchronize with the user's account on the MCData message store, either automatically or manually (i.e. interacts with the user on which option to synchronize or no synchronization at all), before any MCData service starts.

IP connectivity service enables the exchange of IP Data using MCData transport service and provides the transport of IP Data for e.g. data hosts, servers, etc. that do not have mission critical communication capabilities. The exchange of IP Data is not limited in a transaction.

The corresponding MCData client enables bidirectional IP Data communication with the support of the IP connectivity service and thus forms the gateway to data hosts or servers. Therefore, the IP connectivity MCData client requests the MCData transport service with the associated QoS requirement and communication priority. An authorised MCData client supporting IP connectivity capabilities is able to bar incoming IP connectivity requests either on demand or by providing a list of excluded origins identified by the MCData ID and, if available, by the functional alias. For IP connectivity, the MCData server may support following limitation to exchange IP Data:

• limit the total data volume between the authorized MCData clients, divided by transmission and reception;
• max time limit, e.g. total minutes or allow exchange between predefined start and end time.

IP connectivity MCData service supports MCData transport services for one-to-one and group communication. The IP address allocation necessary for user-IP connectivity MCData transport service is independent to the IP address allocation of the individual data hosts attached with the MCData client supporting IP connectivity capabilities. The required IP address pools for the user-IP connectivity MCData service are managed by the IP connectivity MCData transport service.

The MBMS user service architecture offers a set of delivery methods to applications, specified in TS 26.346. The MBMS download delivery method is used for the delivery of files over MBMS and provides reliability control by means of forward-error-correction. The MCData File Distribution capability can use the MBMS download delivery method by including, in the MC service-on network architecture (subclause 5.2.6 of TS 23.280), the MBMS user service architecture (TS 26.346), with the MCData server assuming the role of the content provider. The MCData server may determine the MBMS broadcast area based on the cell identities of the affiliated group members received over GC1. When the xMB interface is used, the MCData server uses the xMB mission critical extension, specified in TS 26.348 to control the QoS and the MBMS broadcast area of the MBMS user services. The MCData server also provides a file delivery manifest over xMB-C (see subclause 5.6.2 of TS 26.348) describing the list of files to be broadcasted, and, for each file, the target completion date and the number of repetitions. The MBMS user service metadata, which provides the delivery and schedule parameters, are returned to the MCData server after the MBMS session creation or update, under the form of a SA file (Annex L.3A from TS 26.346). The MCData server signals this SA file, together with the service id and the uri of the file to be received to the targeted MCData clients.

MBMS delivery via MB2 applies to MCData services that use media plane for user traffic delivery.

A MCData user may request a delivery report (such as delivered, message read, or file downloaded etc.) when sending a MCData data (i.e. a message or a file). The recipient((s) shall respond with the proper delivery status response(s) (such as delivered, message read, or file downloaded etc.) according to what is requested in the delivery report. The sender of the MCData data may include multiple delivery status (such as delivered, message read, or file downloaded etc.) in the delivery report and the recipient(s) shall respond accordingly. When the recipient is offline and receives a MCData data with request for delivery report, the delivery status response(s) shall follow one of the two principles below:

1. If the deferred delivery is used to deliver the MCData data, the delivery status response(s) shall be determined and responded by the recipient when the data is delivered. The MCData server may send a provisional delivery status report (such as the recipient is offline and the data will be delivered when the recipient is online or discarded due to timeout etc.) to inform the sender about the data delivery progress.
2. If the data is delivered with lossless communication, the MCData server shall respond with a delivered status report to the sender once the data is deposited into the recipient's MCData message store account. If the message read or file downloaded status is requested, the recipient shall respond it when the data is synced on the user device and processed by the recipient.