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. MCVideo Quality: Real Time: Real-Time Video: Robot:

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 MCCoRe MCData MCPTT MCVideo PTZ TVNP

MCVideo defines a service for Mission Critical video communication using 3GPP transport networks. Mission Critical refers to meeting the needs of agencies providing Public Safety services such as, but not limited to, Police, Fire and Ambulance services. Those needs include high reachability, availability and reliability of the service, low latency, real-time operating capabilities, highly secured operations, inter-operability with other services and systems, private and group communications, handling of emergencies and ability to provide prioritization, pre-emption, queuing and QoS. Although the service is designed for transport over commercial and dedicated 3GPP networks it is not expected to be limited to use over 3GPP networks. However, performance over other transport networks has not been considered when producing this document. MCVideo service includes:

• Video capture and encoding of the video information;
• Secure streaming and storing of the video information;
• Video decoding and rendering of the video information;
• Processing of the video information, including the ability to annotate video frames and recognize video features;
• Mission critical and public safety level functionality (e.g. group sessions, affiliations, end-to-end confidentiality, emergency type communications) and performance (e.g. low latency);
• Transmission and control of the parameters relevant to those functions;
• Secure operation such that video information can be reasonably un-impeachable when used in evidentiary procedures;
• Definition and configuration of MCVideo groups and applications;
• Configuration of the MCVideo users' profiles and of the MCVideo UEs; and
• Interoperability with other services and systems.

While the streaming of video is part of the MCVideo Service, the non-real-time or offline transfer of a video clip stored as a file containing video data is covered by the MCData Service as defined in TS 22.282. An MCVideo video stream can be associated with a stand alone MCVideo group of users, or can be one of the streams of a multi-media MCX Service group. An MCVideo UE is a device that provides video acquisition (e.g. has a camera), video rendering (has a display) or both and normally also has some encoding / decoding, communication and storage capabilities.

MCVideo makes use of many of the same capabilities that were originally defined for MCPTT in TS 22.179 and now are mostly specified at stage 1 in the MCCoRe specification [3]. Such capabilities include, but are not limited to, Group Communication, Group Management, Affiliation, Security and Confidentiality. The MCVideo service also allows the same user to have multiple user profiles defined and to simultaneously use multiple UEs. However, the MCVideo Service also differs from MCPTT in some respects. In MCPTT there is a specific way of floor control to assert good order and appropriate use of priority to control and manage situations where multiple users in a group might attempt to speak at the same time. Simultaneous speech can degrade intelligibility of communications. The role of floor control is to manage who can transmit at a point in time and who will have to wait to speak to the group. In MCVideo the control approach is more varied. There is admission control to manage the appropriate access to network resources according to the user's priority and the UE's capabilities. In some cases, this may include control to restrict simultaneous video being sent from different users in the group (likely to be useful for network capacity/UE limitations). From a user perspective there is not the same need to restrict multiple simultaneous transmission and presentation of video within the same group, as if different streams are available at the UE then the user could choose which, to look at them simultaneously. It is assumed that users that are permitted to transmit video are generally allowed to send video to a group, unless there is a network capacity/UE restriction rule that places limitations on the number of videos to that group. In this case users would be trained in appropriate use of that choice. The point at which video is transmitted to a group may vary, e.g. a user may press to send video and wait until allowed by the network to stream to the affiliated group according to the admission control policy. However, the user may be able to "force" the immediate transmission of the video information, for example, by pressing and holding the button to send video. In this case the UE will take immediate action to capture the video for onward transmission as soon as permitted. Also the UE will communicate the immediate nature of the video to the network, which may choose to authorise the access and then locally store it for onward transmission or stream it immediately to the relevant group. In this case the video may be slightly delayed due to the start up delay. It is also possible for the user to mark their video communication as Emergency or Imminent Peril and this will immediately elevate the priority of video communications for this group above non emergency video. A further way that MCVideo differs from MCPTT is that group members may be configured not to automatically receive video. Video may be streamed up to the network and users invited to join when/if convenient/appropriate for them or only if they have access to a multicast enabled device. An example might be where a Police Officer driving to an incident is not able to view a video of the events unfolding, but his partner in the car can usefully receive and view the video. In this case MCVideo working together with MCPTT will provide a powerful solution to know which videos to receive for those best placed to receive them. This user reception function might be used to late join a video stream or with the store and forward capability for video.

Surveillance cameras could also use the MCVideo service in which case, in addition to the existing video storage and monitoring activity already used for the surveillance camera, authority may be given to users in the MCVideo system to connect to, control receive and forward video either to an individual or to a group. Surveillance includes the ability to locally and remotely activate video streaming automatically or on demand, to control the positioning, optical and video parameters of the camera and to recognize video features. The camera may be exclusively in the MCVideo system, or it may be accessed by connection from the MCVideo Service via an existing external interface for surveillance camera networks. In this latter case, the external interface is expected to provide requests for control and onward streaming of video, which will be managed together with the normal control network for those cameras. This external interface is outside of the control of 3GPP and existing standards may be used for part or all of the functionality of this interface e.g. TVNP.

MCVideo group communication aspects are very similar to MCPTT. Each user may be a member of several, even many, groups. Membership is determined by administration control and provides a user identity based level of authority to join a group. Each user chooses to affiliate to the groups that they want to receive video communication from. Once a user has successfully affiliated to a group they will begin to receive video communications directed to that group according to the video distribution approach used. A user who wishes to send video to a group shall select the relevant group and then they may send video to it. Groups may interwork with other MCX Service groups, so a single group could be configured for MCPTT and MCVideo and any other combination of MCX Services. The present document does not describe how that is managed, it could be a single group with a single affiliate message and separate attributes for each service or it may be different groups managed together by administrator control and linked in the UE to allow single user action to trigger the same action e.g. affiliate, for each relevant service. It shall be possible for services actions to be taken independently because some UE may not be capable of all of the linked services and some users may not be given access to some services or some groups for some services.

All MCVideo communications, video and supporting signalling and messaging which start and end entirely within MCVideo systems are protected by the security mechanisms used for other MCX Services and defined in MCCoRe. MCVideo communications to and from external end points may be security protected and routed through the normal MCVideo system and then forwarded into the required network for onward delivery to the external end point. Alternatively, such communication could just use the protection and routing provided by the transport network. Given the potential use of stored video information in evidentiary procedures, ensuring the integrity, confidentiality and accuracy of the video information and its associated meta-data is of paramount importance for MCVideo Data.

MCVideo has the same confidentiality requirements as for other MCX Services and are defined in MCCoRe [3].

All users have a unique identity and at least one alias for other MCServices. A single user can have the same or different aliases for any and every MCX Service and group that they are members of, but user identities and aliases for each user resolve to a unique identity even among multiple independent MCX Services in the same domain (e.g. State or Country. In this way, a user who identifies another user using one service will be able to make contact using a different service. For example, multiple groups and multiple Mission Critical organisations working in the same building might use a map application, which shows them where all the other users are. It should be possible for one user to be able to identify a nearby user from the map and request a video (via the MCVideo Service) of the situation from a certain vantage in order to take appropriate action. The other user may be in a combined group for the mapping application (MCData) but not currently known affiliated in any other group along with the requesting user. User identities requirements are specified in MCCoRe [3]. It is assumed in the present document that, even when there is no configured inter-service interworking action, the User ID for any user detected in any MCService can be used to establish video communication to that user, subject to the user being authorised for the MCVideo Service and the UE being MCVideo capable.

In general, an MCVideo UE can support several video codecs (or video codec operating modes) of which some could be optional, some could be locally/regionally mandated via regulation, and one is globally mandated via 3GPP implicit (by reference) or explicit (by detailed specification) standardization as the mandatory universal interoperability video codec. If MCVideo UEs participate in a video session, they may need to negotiate or rely on defaults or other rules to establish a common video codec for the video session. Transcoding is not desirable on grounds of complexity and efficiency and in order to enable end-to-end ciphering. The MCVideo service supports both combined (for efficiency and synchronization) and separate (for cases when the video component cannot or will not be received) handling of video and audio streams.