The present document provides the service requirements for operation of the MCData service. MCData makes use of capabilities included in Group Communication System Enablers, Proximity Services, Isolated E-UTRAN operation for Public Safety and Mission Critical Services Common Requirements with additional requirements specific to the MCData Service. The MCData Service can be used for public safety applications and maritime safety applications and also for general commercial applications (e.g., utility companies, railways and maritime usage). The requirements in this specifications do not apply to GSM or UMTS.
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
Conversation:
A series of messages that are linked to the same topic within a group or one-to-one data communication.
Conversation ID:
An identifier that uniquely identifies a conversation within a group or one-to-one data communication.
MCData Conversation Hang Time:
The time from the transmission of an MCData message after which a subsequent MCData message is no longer considered to be linked to the previous one.
MCData System:
The collection of applications, services, and enabling capabilities required to provide Mission Critical Data for a Mission Critical Organization.
For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
IOPS
MCData defines a service for Mission Critical Data services. As well as voice services, current mission critical users have been increasing their use of data services, including low throughput services on legacy networks and data services on commercial networks. This need will continue to grow with the creation of the new multimedia services. The MCData service needs to provide a means to manage all data connections of mission critical users in the field and provide relevant resources to the ones who need it. For example mission critical users already use event manager software along with the voice system. The migration to 3GPP networks will allow mission critical users to operate current and new data services whilst relying on the fundamental capabilities of mission critical communication such as defined for MCPTT in [4] and included into MCCoRe [3].
The MCData Service provides a set of communication services that will be directly used by the user or functions that will be called by external applications in control rooms.
The MCData Service will reuse functions including end-to-end encryption, key management, authentication of the sender, etc. defined in [3] in order to provide group communications for data services. As for all mission critical services, users affiliate to groups in order to receive communications directed to the group.
In addition, the MCData Service will provide a set of generic capabilities such as: messaging, file distribution, data streaming, IP proxy, etc. Also, the MCData Service will provide specific services such as conversation management, data base enquiries, internet access, robots control.
The MCData Service is expected to have open interfaces in the network. It needs also to provide an opportunity for a variety of multimedia applications using the MCData Service.
MCData makes frequent use of a set of capabilities and enablers that allows for many end user services to be built on a common foundation. Several generic capabilities are defined for use in the MCData Service. These capabilities can be used on their own to transfer files, messages and other content to individuals and affiliated members of groups or combined with other services, through an application, to provide complete end users services as determined by the authorities implementing the service. The MCData generic capabilities are common for on-network and off-network.
It is not intended to invent new protocols for the MCData Service. Where existing protocols are efficient and sufficient, the service should make use of these protocols.
The SDS feature of the MCData Service could be considered as a basic protocol carrying a limited size, but variable content, payload message. This message could be text or could be marked for extensible purposes including short binary messages for application communication. Messaging could be one-to-one messaging or could be group messaging using groups as specified in MCCoRe.
The MCData Service shall provide an SDS feature for conveyance of limited size, variable content, messages.
[R-5.2.2-002]
The MCData SDS shall provide a group service to affiliated members with policy assertion capabilities (e.g. certain types of message or content may only be relevant to certain members of a group due, for example, to location).
[R-5.2.2-003]
The MCData SDS shall provide a one to one service with policy assertion capabilities (e.g. policy to limit certain types of message or content to certain users due, for example, to location or user privilege).
[R-5.2.2-004]
The MCData SDS shall provide the option to include a content payload of at least [1000] characters of 8 bit text or [500] characters of 16 bit text or [250] characters of 32 bit text and the necessary character encoding information (for example to identify alphabet used).
[R-5.2.2-005]
The MCData SDS shall provide the option to include a content payload of at least [1000] characters of hyperlink or interleaved text and hyperlink(s) to allow subsequent access to linked content (which may be a large file).
[R-5.2.2-006]
The MCData SDS shall provide the option to include a content payload of at least [1000] bytes of binary data to be used by a local running application and the necessary addressing detail to identify the intended application.
[R-5.2.2-007]
The MCData SDS shall provide a message thread indication so that multiple message flows can be managed independently.
[R-5.2.2-008]
When replying to a message on the MCData SDS or sending any message which should be coupled with previously sent or received messages or message flows; the message thread indication shall use the same indication as was used for those previous messages.
[R-5.2.2-009]
The MCData SDS shall provide a selectable read receipt indication. When requested, the receiving entity shall provide receipt indication for delivered and read messages as appropriate.
[R-5.2.2-010]
The MCData SDS shall provide a configurable read receipt indication. When configured, the receiving entity shall provide receipt indication addressed to the application for delivered and read messages as appropriate.
[R-5.2.2-011]
The MCData SDS shall permit delivery history interrogation for suitably authorized users.
[R-5.2.2-012]
The MCData SDS shall provide the option to add a field indicating location of the sending user/UE.
[R-5.2.2-013]
The MCData SDS shall allow empty messages including only a field indicating location of the sending user/UE.
SDS content received in a UE, addressed to a known local application that is not yet running shall cause the UE to start the local application and pass the content to the application. This could be used to start an application and pass to it the initial data.
[R-5.2.3-002]
The MCData SDS shall provide the capability to remotely start a local application (e.g. situational awareness). This may be through specific use of binary payload on theSDS.
File distribution is a fundamental capability of the MCData Service. File distribution can be used to provide a standalone file transfer capability or can be invoked by a controlling application to support the purpose of the application.
The MCData Service shall provide a file distribution capability.
[R-5.3.2-002]
The MCData file distribution capability shall provide a service to allow a user to send a file to any combination of individual users and/or affiliated groups.
[R-5.3.2-003]
The MCData file distribution capability shall provide an option for each recipient to choose to receive the file or not (e.g. by storing the file and sending a link (URL) to all relevant members).
[R-5.3.2-004]
The MCData file distribution capability shall allow a user to reject to receive the file where appropriate.
[R-5.3.2-005]
The MCData file distribution capability shall provide a sending user selectable indication for mandatory download so that the UE, for all relevant receiving members, will automatically download the file.
[R-5.3.2-006]
The MCData file distribution capability shall provide download complete indications for each recipient successfully downloading the file.
[R-5.3.2-007]
The MCData file distribution capability shall allow the sender to select to send the file immediately to all chosen users.
[R-5.3.2-008]
The MCData file distribution capability shall make use of available system delivery efficiencies for distribution of common information to users within a specific geographic area and able to receive at the same time.
[R-5.3.2-009]
The MCData file distribution capability shall allow a user to cancel distribution of files they have sent, but have not been delivered.
[R-5.3.2-010]
The MCData file distribution capability shall allow an authorised user to cancel distribution of files being sent or waiting to be sent.
Data streaming is a fundamental capability of the MCData Service. Data streaming can be used to provide a standalone data streaming capability or can be invoked by a controlling application to support the purpose of the application.
The MCData Service shall provide a data streaming capability.
[R-5.4.2-002]
The MCData data streaming capability shall provide an option that allows each recipient to choose to receive the data stream or not (e.g. by sending a link (URL) to all relevant members).
[R-5.4.2-003]
The MCData data streaming capability shall allow a user to reject to receive the datastream.
[R-5.4.2-004]
The MCData data streaming capability shall provide a sending user selectable indication for automatic reception by the UE.
[R-5.4.2-005]
The MCData data streaming capability shall provide start and stop records to the sender for each recipient successfully receiving the data stream.
[R-5.4.2-006]
The MCData data streaming capability shall make use of available system delivery efficiencies for streaming of common information to users within the same relevant area and able to receive at the same time.
[R-5.4.2-007]
The MCData data streaming capability shall allow a user to cancel streaming of data they have initiated including data remaining buffered in the system waiting to be streamed.
[R-5.4.2-008]
The MCData data streaming capability shall allow an authorised user to terminate streaming of data being sent and cancel streaming of data remaining buffered in the system waiting to be streamed.
[R-5.4.2-009]
The MCData data streaming capability shall provide setup time of:
Less than 1 second for immediate setup of a data communication.
Less than 3 second for normal setup of a data communication.
IP connectivity can be used for MCData applications that are based on the IP client-server paradigm. The UE can contain a client using a service in the network (e.g. a police officer accessing a server on the police Intranet from his mobile phone). The UE can also contain a server that is accessed by other UEs (e.g. a mobile information display that is controlled by a police officer from his mobile phone). As an UE for MCData application can be an unmanned device, or device without user interface, authorization of IP data transport can be provided remotely by an authorized user for the UE.
The MCData Service shall enable an MCData user to initiate transport of IP data towards a server in the network or another MCData user.
[R-5.5.2-002]
The MCData Service shall enable incoming transport of IP data towards an MCData user, initiated by another MCData user.
[R-5.5.2-003]
The MCData Service shall enable an authorized person for an MCData user to authorize initiation of transport of IP data from that MCData user to specific destinations. This authorization may be preconfigured or may be provided by the authorized person when IP data transport to a new destination is initiated. Authorization may be revoked on demand by the authorized person.
[R-5.5.2-004]
The MCData Service shall enable a MCData user or authorized person for this MCData user to authorize initiation of incoming transport of IP data from specific other MCData users. This authorization may be preconfigured, or may be provided by the authorized person when IP data transport from a new destination is initiated. Authorization may be revoked on demand by the authorized person.
[R-5.5.2-005]
The MCData Service shall support incoming and outgoing IP data transport for a MCData user with a higher per packet priority .
[R-5.5.2-006]
The MCData Service shall enable an authorized person to remotely authorize the use of higher per packet priority for a particular MCData user.
A group of people can be involved in different activities in an operational situation. As a consequence, there is a need to manage different activities and to easily retrieve data exchanged around one activity. Therefore conversation management is applied to all messaging and file transfer. Conversation management can be seen as an aggregation of related MCData transmissions for a given activity.
The system will not be able to manage an infinite number of conversations. Rather than simply limiting the number of conversations and asking users to send a notification when the conversation ends, it is proposed here to limit the time of a conversation.
The MCData Service shall provide a conversation management feature for each MCData User.
[R-6.1.1.2-002]
The MCData conversation management service shall be available for group communication as well as for one-to-one communications.
[R-6.1.1.2-003]
The MCData Service conversation management feature shall use the SDS and file distribution generic capabilities.
[R-6.1.1.2-004]
A conversation shall be identified through a unique conversation ID.
[R-6.1.1.2-005]
The MCData Service conversation management feature shall provide an MCData Conversation Hang Time after which the last message/file shall no longer be correlated to the previous.
[R-6.1.1.2-006]
The MCData Conversation Hang Time shall be available to the user.
[R-6.1.1.2-007]
The MCData Conversation Hang Time shall be configurable for each MCData User and each MCData Group.
[R-6.1.1.2-008]
The MCData Service conversation management feature shall allow multiple parallel conversations for the same group or the same pair of users.
[R-6.1.1.2-009]
The MCData Service shall provide a mechanism for an MCData User to request to receive a "message delivered" and/or "message read" disposition notifications for all outgoing messages and all file transfers for a specific private conversation of the MCData User.
[R-6.1.1.2-009a]
The MCData Service shall provide a mechanism for an MCData User to request to receive "message delivered" and/or "message read" disposition notifications for all outgoing messages and all file transfers for a specific conversation in a group that the MCData User is affiliated to."
[R-6.1.1.2-009b]
The MCData Service shall provide a mechanism for the MCData User to request the disposition notifications either per message, or during a time window or for the whole conversation.
[R-6.1.1.2-009c]
The MCData Service shall provide a mechanism for an authorized MCData User to request to receive or to stop to receive "message delivered" and/or "message read" disposition notifications for all messages and all file transfers for a specific conversation in a group that the authorized MCData User is affiliated to.
[R-6.1.1.2-009d]
The MCData Service shall provide a mechanism for an authorized MCData User to request to receive or to stop to receive "message delivered" and/or "message read" disposition notifications for all messages and all file transfers for all conversations in a group that the authorized MCData User is affiliated to.
[R-6.1.1.2-010]
The MCData Service shall make use of SDS and file distribution capability to provide relevant access to delivery history and delivery efficiencies.
[R-6.1.1.2-011]
If configured by the MCX Administrator the MCData Service shall be able to provide a MCX User the data that had previously been distributed in an ongoing MCData group conversation before this MCX User had affiliated or joined.
Robots as defined in TS 22.281 will be used more and more to provide unique services to mission critical organizations. Critical communications users need, as a consequence, a common communication framework for robots which can take advantage of different transport technologies such as a 3GPP system. The MCData Service, working in conjunction with existing robot control capabilities, will provide mechanisms to do that.
The following sub-clause aims at defining requirements to ensure robot control communication can be provided through a 3GPP system.
We expect different manufacturers for robots. As a consequence a well-known transport framework is needed in order to ensure easy integration of new robots.
The MCData Service shall enable the control of robots.
[R-6.1.2.1.2-002]
The MCData Service shall provide a common transmission framework to use and control robots.
[R-6.1.2.1.2-003]
The MCData Service shall provide a default control latency depending on the robots type under
50 ms for an aerial unmanned vehicle;
200 ms for an aquatic or submarine unmanned vehicle; and
400 ms for a terrestrial unmanned vehicle.
[R-6.1.2.1.2-004]
The MCData Service shall be able to simultaneously manage multiple robots and robot types.
[R-6.1.2.1.2-005]
Void.
[R-6.1.2.1.2-006]
The MCData Service shall support management of an aerial unmanned vehicle at an altitude of up to 150 m above the floor.
[R-6.1.2.1.2-007]
The MCData Service shall have a default priority scheme for each kind of robot (aerial, aquatic, submarine or terrestrial unmanned vehicles).
[R-6.1.2.1.2-008]
The MCData Service shall be able to provide relevant priorities to different MCData communications according to the default priority scheme without additional configuration.
[R-6.1.2.1.2-009]
The MCData Service default priority scheme shall ensure that data exchanged for controlling a robot has relevant high priority amongst user data and cannot be pre-empted.
[R-6.1.2.1.2-010]
The MCData Service default priority scheme shall ensure that essential robots telemetry data (such as position when out of sight) has also a high priority and cannot be pre-empted.
[R-6.1.2.1.2-011]
The essential telemetry data shall be identified and minimized in order not to forbid critical operational data to be transmitted.
Robots as defined in [6] (e.g., aerial, aquatic, submarine and terrestrial unmanned vehicles) will need to be identified across the organization in order to share who is doing what.
There will also be a need to exchange information specific to different robots.
The MCData Service shall provide a means to identify robots used by a Mission Critical Organization.
[R-6.1.2.2.2-002]
The MCData Service shall provide a mechanism for an authorized user to get identifying information for one or more robots associated with all MCData UEs that are under the coverage of the MCData System. Location information may be also sent with identifying data.
[R-6.1.2.2.2-003]
The MCData Service shall provide to an MCData authorized User a means to get the location of each robot associated with any MCData UE under the coverage of the MCData System.
[R-6.1.2.2.2-004]
The MCData Service shall be able to provide characteristics (free formatted information transported by 3GPP) of an MCData UE associated with a given robot to the authorized user.
Mission Critical Service users need to share status information specific to their activities. For instance status can be: available, in operation on site, going to the operation site, or just arrived. When working in a group, there is a need to constantly share this information.
The MCData Service shall determine which Participant(s) are allowed to transmit data.
[R-6.2.2.1-002a]
The MCData Service shall provide a mechanism so that small data items can be automatically sent to the chosen receiving users (private communication) or to affiliated members of the Selected MCData group.
[R-6.2.2.1-002b]
The MCData Service shall provide a mechanism so that when an MCData request to transmit is granted, the data can be automatically sent on to the chosen receiving users (private communication) or to affiliated members of the Selected MCData group (i.e. without prior acceptance from the receiving user).
[R-6.2.2.1-002c]
The MCData Service shall provide a mechanism so that when an MCData request to transmit is granted the data can be temporarily stored in the system and an invitation to receive is sent to the chosen receiving users (private communication) or to affiliated members of the Selected MCData group.
[R-6.2.2.1-002d]
The MCData Service may provide a configurable default time to live value for data waiting to be delivered to a receiving user.
[R-6.2.2.1-002e]
The MCData Service may terminate all remaining invitations to receive after expiry of the time to live.
[R-6.2.2.1-003]
The MCData Service shall provide a mechanism for the MCData Administrator to configure the maximum data size for automatic data transmission.
[R-6.2.2.1-004]
When an MCData UE has begun to transmit data or when the data transmission has completed the MCData Service shall begin to send the data to all affiliated members of the selected group.
[R-6.2.2.1-005]
The MCData Service may withhold permission to transmit for service based pre-emptive capacity reasons.
[R-6.2.2.1-006]
Following an MCData Service request for permission to transmit on the Selected MCData Group, an Affiliated MCData Group Member that made but was not granted the request shall be given an indication that permission to transmit was not given at that time.
[R-6.2.2.1-007]
When a user is not allowed to start a communication the request may be queued or rejected.
The MCData Service shall provide, periodically and on demand, to the MCData User the list of available recently invited data group communications for which he is affiliated.
[R-6.2.2.3-002]
The MCData user shall be able to affiliate to one or more MCData Groups subject to MCData settings and UE capabilities.
The MCData Service shall make efficient use of resources.
[R-6.2.2.4-002]
The MCData Service shall provide a notification to a transmitting MCData Group Member if there are no other MCData Group Members who have affiliated to the MCData Group.
[R-6.2.2.4-003]
Following a notification that there are no other MCData Group Members affiliated to the MCData Group and if the transmitting MCData Group Member does not terminate their request to transmit, the MCData Service may either (terminate the permission to transmit) or (allow the transmission to continue and store the transmitted data for a time to live time and deliver invitations to receive to subsequent affiliating members).
When operating on network it should be possible to implement a centralised enhanced status system to track the enhanced status of many users. This would use communication from the users to a centralised system. Other users could interrogate or subscribe to changes from this centralised system.
The MCData Service shall provide a means to share, in real-time, operational status information to a single MCData User or centralised enhanced status system.
[R-6.2.4.2-002]
The MCData Service shall allow an authorised user to subscribe for status update reports of users within their domain.
[R-6.2.4.2-003]
The MCData Service shall allow an authorised user to publish status updates on behalf of another MCData User within their domain.
The MCData Service shall enable an authorized MCData User to terminate the transmission of a transmitting participant at any time.
[R-6.2.3-002]
A transmitting participant shall be able to indicate to the MCData Service that the participant no longer wants to transmit.
[R-6.2.3-003]
If a transmitting participant of an MCData Service Group Communication is pre-empted, the MCData Service shall terminate the communication.
[R-6.2.3-004]
If MCData User(s) are pre-empted from an on-going MCData Service communication as there is insufficient capacity to support their on-going participation, the MCData Service shall provide the MCData User(s) with a notification that they have been removed from the communication for reasons of lack of capacity.
[R-6.2.3-005]
The MCData Service shall have a configurable limit for the maximum amount of data or time that a Participant transmits from a single request to transmit.
[R-6.2.3-006]
The MCData Service shall enable an MCData Administrator to configure the limits for a transmission that a Participant transmits from a single request to transmit.
[R-6.2.3-007]
The MCData Service may provide a notification of intent to terminate a communication e.g. to give the user time to request an extension.
[R-6.2.3-008]
The MCData Service may terminate a communication without previously sending a notification.
[R-6.2.3-009]
The MCData Service may include an indication of termination reason (e.g. data volume limit, administrator action, time limit expiry) with any notification of intent to terminate or actual termination.
[R-6.2.3-010]
An MCData UE shall provide, to the MCData User, a notification of intent to terminate including any reason given.
[R-6.2.3-010a]
An MCData UE may provide, to the MCData User, a notification of termination including any reason given.
[R-6.2.3-011]
The MCData Service may include a request for more information with any notification of intent to terminate communication.
[R-6.2.3-012]
An MCData UE shall respond to a request for more information.
[R-6.2.3-012a]
The response to the request for more information may include an indication of the amount of data still to be transmitted.
[R-6.2.3-013]
The MCData Service shall terminate an MCData Service Group Communication if any termination condition occurs.
Private Communications off-network allows two MCData Users to communicate directly with each other without the use of the network. Private Communications off-network is generally applicable to all of the MCData subservices (SDS, file distribution capability, data streaming capability, IP connectivity).
The MCData service shall support Private Communications Off-Network.
[R-6.3.1.2-002]
The MCData service shall provide a mechanism for an MCData User to cancel an MCData Private Communication prior to the Communication setup.
[R-6.3.1.2-003]
The MCData service shall provide a means by which an authorized MCData User initiates an MCData Private Communication.
[R-6.3.1.2-004]
The MCData service shall provide a means by which an MCData UE initiates an MCData Private Communication to any MCData User for which the MCData UE's current MCData User is authorized.
[R-6.3.1.2-005]
The MCData service shall provide a mechanism for an MCData User to reject an MCData Private Communication.
[R-6.3.1.2-006]
The MCData service shall provide a means by which an MCData User ends a Private Communication in which the MCData User is a Participant.
[R-6.3.1.2-007]
The MCData service shall provide a mechanism for an MCData Administrator to configure for a particular authorized MCData User, a set of MCData Users under the same authority to which an MCData Private Communication can be made.
[R-6.3.1.2-008]
The MCData service shall provide a mechanism for an MCData Administrator to configure the maximum duration for MCData Private Communications for MCData Users within their authority.
MCData Transmission Control Off-Network provides a necessary capability for an authorized user of the MCData service to request to transmit, receive an indication of being allowed to transmit or not being allowed to transmit and terminate a request to transmit when the MCData user no longer wants to transmit. A transmit time limit is provided which allows an MCData Administrator to configure the limits for any transmission related to a single request to transmit. MCData Transmission Control Off-Network also provides an override capability based on a priority hierarchy to override an active MCData transmission of a transmitting Participant based on configuration. The MCData Transsmission Control Off-Network capability does not apply to all of the MCData subservices (SDS, file distribution capability, data streaming capability, IP connectivity).
The MCData service when operating off-network shall determine at a point in time which off-network Participant(s) are allowed to transmit to other off-network Participants.
[R-6.3.2.2-002]
An MCData Group shall have the flexibility to be configured to allow simultaneous transmitting MCData Group Members.
[R-6.3.2.2-003]
The MCData service shall provide a mechanism for the MCData Service Administrator to configure the maximum number of simultaneous communications received by an off-network MCData User in a single MCData Group.
An authorized Participant shall be able to request to transmit to an MCData Group or an individual MCData User.
[R-6.3.2.3-002]
The MCData service shall determine which Participant(s) are permitted to transmit when there are simultaneous requests for permission to transmit within the same group.
[R-6.3.2.3-003]
Following an MCData request for permission to transmit on the Selected MCData Group, any Affiliated MCData User that made and was granted the request shall be given an indication of being allowed to transmit.
[R-6.3.2.3-004]
Following an MCData request for permission to transmit on the Selected MCData Group, any Affiliated MCData User that made and was not granted the request shall be given an indication that permission to transmit was not given at that time.
[R-6.3.2.3-005]
Following an MCData Private Communication request for permission to transmit, an MCData User that is allowed to transmit shall be given an indication that the user is allowed to transmit to the targeted MCData User(s).
[R-6.3.2.3-006]
Following an MCData Private Communication request for permission to transmit, an MCData User that is not allowed to transmit shall be given an indication that the permission to transmit was queued or rejected.
[R-6.3.2.3-007]
The MCData service when operating off-network shall provide a mechanism for an MCData Participant to cancel its MCData request to transmit at any stage, including before the request has been granted.
[R-6.3.2.3-008]
The MCData service shall provide a mechanism for the MCData Administrator to configure parameter(s) relating to the automatic termination of an off-network MCData service request to transmit.
An MCData UE shall be pre-provisioned by an MCData Administrator and/or authorized user with the necessary information in order that override may operate during off-network MCData communication.
[R-6.3.2.4-002]
The MCData service shall provide a mechanism for MCData Administrators to create a priority hierarchy for determining what Participants, Participant types, and urgent transmission types, when operating off the network, be granted a request to override an active off-network MCData transmission.
[R-6.3.2.4-003]
The priority hierarchy used for granting a request to override an active MCData transmission shall contain at least four (4) levels.
[R-6.3.2.4-004]
The MCData service shall provide a mechanism for Participants, to override an active MCData transmission of a transmitting Participant based on configuration.
[R-6.3.2.4-005]
If an MCData transmission is overridden, the MCData Service shall provide a means of notifying the overridden Participant(s) that the transmission has been overridden.
[R-6.3.2.4-006]
The MCData service shall provide a mechanism to enable an MCData Administrator to configure which MCData Group transmission(s) a Participant(s) receives, for cases where an MCData transmission can be overridden.
[R-6.3.2.4-007]
If the MCData Group has been configured to only allow the overriding transmitting Participant to transmit, the MCData service shall revoke the transmit permission of the overridden transmitting Participant.
The Off-Network MCData Service shall provide a mechanism for an MCData UE to be pre-provisioned by an MCData Administrator and/or authorized user with the necessary information in order that a transmit time limit function may operate during off-network MCData communication.
[R-6.3.2.6-002]
The Off-Network MCData Service shall enable an MCData Administrator to configure the limits (e.g. elapsed time, quantity of data) for any transmission related to a single request to transmit.
[R-6.3.2.6-003]
The Off-Network MCData Service shall have configurable limits (e.g. elapsed time, quantity of data), including indefinite, for any transmission related to a single request to transmit (e.g. elapsed time, quantity of data).
[R-6.3.2.6-004]
The Off-Network MCData Service shall provide an indication to the transmitting Participant a configurable amount before the transmit limit is reached.
[R-6.3.2.6-005]
The Off-Network MCData Service shall provide an indication to the transmitting Participant that the Participant's transmit limit has been reached.
[R-6.3.2.6-006]
The Off-Network MCData Service shall remove the permission to transmit from the transmitting Participant when the Participant's transmit limit has been reached.