6 MCData specific requirements

22.2823GPPMission Critical (MC) dataTS

6.1 MCData Services common for on network and off network

6.1.1 Conversation management including delivery notification

6.1.1.1 Service description

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.

6.1.1.2 Service requirements

[R-6.1.1.2-001] 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.

NOTE: For instance, if SDS and file distribution capability are combined for a conversation, the two thread indications are assumed to appear in the conversation as unique.

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

6.1.2 Robots

6.1.2.1 Robots remote control

6.1.2.1.1 Service description

Robots as defined in 3GPP TS 22.281 [6] 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.

6.1.2.1.2 Requirements

[R-6.1.2.1.2-001] 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.

NOTE: At this stage of the work, the latency is an end to end latency. The split between network latency and robot latency is left for stage 2. The latency is measured between the action of the pilot and the movement of the robot (not only MCData Service).

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

6.1.2.2 Robots communication

[R-6.1.2.2-001] The MCData Service shall support MCData communication between robots.

[R-6.1.2.2-002] The MCData Service shall support MCData communication between robots to be initiated and/or terminated by a controller.

6.1.2.2 Robot identification

6.1.2.2.1 Service description

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.

6.1.2.2.2 Requirements

[R-6.1.2.2.2-001] 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.

6.1.3 MCData enhanced status

6.1.3.1 Service description

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.

6.1.3.2 Requirements

[R-6.1.3.2-001] The MCData Service shall provide a means to share in real-time operational status information between members of a selected group.

[R-6.1.3.2-002] The possible operational status values shall be configurable.

[R-6.1.3.2-003] The minimum number of possible different operational status values shall be 32.

6.2 MCData Services requirements specific to on-network use

6.2.1 Database enquiries and secured internet access

6.2.1.1 Service description

Mission critical users are already using data applications today for which a priority management will need to be implemented.

6.2.1.2 Requirements

[R-6.2.1.2-001] The MCData Service shall provide controlled access to external services (e.g. data bases, web sites, event manager software).

[R-6.2.1.2-002] The MCData Service shall be able to select priorities to data flows for external services (e.g. data bases access, web sites, event manager software).

6.2.2 Transmission control requirements

6.2.2.1 General

[R-6.2.2.1-001] 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.

NOTE 1: This is for support of sending large data files, allowing the receiving user to choose when to receive.

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

NOTE 2: Where the MCData Service chooses to use eMBMS to broadcast the data to several users, the UE will need to be notified to select the relevant channel before the data is sent.

NOTE 3: The MCData Service might choose to temporarily store the transmitted data and deliver it independently to receiving users as appropriate.

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

6.2.2.2 Receiving data

[R-6.2.2.2-001] An MCData user shall be able to choose to download data for any recently invited group communications.

NOTE: A list of available data is stored and presented to the user on demand. The term, recent, might be time limited, size of list limited or any other limit.

6.2.2.3 Accessing data

[R-6.2.2.3-001] 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.

6.2.2.4 Data reconfiguration and termination

[R-6.2.2.4-001] 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).

6.2.4 MCData enhanced status on-network

6.2.4.1 Service description

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.

6.2.4.2 Requirements

[R-6.2.4.2-001] 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.

6.2.3 Communication termination

[R-6.2.3-001] 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.

NOTE 1: Infinite is a valid setting for the transmit data limit.

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

NOTE 2: For example to allow the UE to indicate the remaining data volume to send if known.

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

6.3 MCData Services requirements specific to off-network use

6.3.1 Private Communication Off-Network

6.3.1.1 Overview

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

6.3.1.2 Requirements

[R-6.3.1.2-001] 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.

NOTE: For off-network use, only an MCData UE within communication range (possibly via a ProSe UE-to-UE Relay) receives the transmission.

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

6.3.2 MCData Transmission Control Off-Network

6.3.2.1 Overview

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

6.3.2.2 General Aspects

[R-6.3.2.2-001] 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.

6.3.2.3 Requesting Permission to Transmit

[R-6.3.2.3-001] 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.

6.3.2.4 Override

[R-6.3.2.4-001] 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.

6.3.2.5 Terminating Permission to Transmit

[R-6.3.2.5-001] A transmitting Participant shall be able to indicate to the off-network MCData service that the Participant no longer wants to transmit.

[R-6.3.2.5-002] The off-network MCData service shall provide an indication to receiving Participants that the transmitting Participant has finished transmitting.

6.3.2.6 Transmit Time Limit

[R-6.3.2.6-001] 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.