Content for TS 22.281 Word version: 16.0.0
5 MCVideo specific requirements
5.1 MCVideo services common for on network and off network
5.1.1 Video characteristics
5.1.2 Video parameters remote control
5.1.3 Video remote control including camera discovery
5.1.4 Video processing capabilities
5.1.5 Robots video remote control
5.1.6 MCVideo Profile management and administration
5.1.7 Capabilities additional to MCCoRe
5.1.8 MCVideo capability information sharing
5.1.9 Video push and pull services
5.1.10 Video streams availability and characteristics
5.1.11 Video conferencing
5.1.12 Additional security requirements for MCVideo
5 MCVideo specific requirements
5.1 MCVideo services common for on network and off network
5.1.1 Video characteristics
5.1.1.1 Operational recommendations and requirements for video codecs for the MCVideo service
[R-5.1.1.1-001]
The video codecs for the MCVideo service should be able to compress/record variable (from very low to very high) resolution video information acquired in real-time:
- in conditions of varied mobility (from static to highly mobile); and
- in conditions of optical and thermal illuminations varying from dimly lit to glare and high brightness.
The MCVideo service shall use video coding and decoding that enables license plate reading, facial and fingerprint recognition and overview of scenes.
[R-5.1.1.1-002a]
The MCVideo service shall support MCVideo UEs that are capable of only receiving videos (e.g. do not have a camera).
[R-5.1.1.1-002b]
The MCVideo service shall support MCVideo UEs that are capable of only transmitting videos (e.g. traffic camera).
[R-5.1.1.1-002c]
The MCVideo service shall support MCVideo UEs that are capable of transmitting and receiving videos.
[R-5.1.1.1-002d]
The MCVideo service shall support transportation of all 3GPP mandated video frame rates and resolutions.
[R-5.1.1.1-003]
The video codecs for the MCVideo service should be able to work effectively in an environment that allows for the transfer of stored or just acquired video information or both, including the capability of rapidly trading image resolution and chromaticity for transfer latency and bandwidth.
[R-5.1.1.1-004]
MCVideo UEs should support rendering of video clips in industry-standard widely-used formats.
[R-5.1.1.1-005]
The video codecs for the MCVideo service should be able to decompress video information, in a manner that enables detail-oriented intelligibility of the information.
[R-5.1.1.1-006]
The video encoders for the MCVideo service should provide both automatic adaptive and manual setting of its working parameters across wide ranges of values and be able to immediately and predictably reflect the changes in values.
[R-5.1.1.1-007]
The video codecs for the MCVideo service should provide video compression ratios and quality at least comparable to what it is customarily and reasonably expected from H.264 [6] compliant video codec implementations.
[R-5.1.1.1-008]
Subject to capability, capacity and configuration, it should be possible for MCVideo UEs to support the generation, storage, transmission and rendering of uncompressed video information or of video information losslessly compressed.
[R-5.1.1.1-009]
The MCVideo service shall provide a mechanism for an authorised MCVideo User or MCVideo Administrator to configure and to temporarily reconfigure the preferred video codec, default video resolution and default video frame rate for an MCVideo Group.
[R-5.1.1.1-010]
The MCVideo service shall provide a mechanism for an authorised MCVideo User or MCVideo Administrator to configure, in preference order, the allowed sets of video codec(s), corresponding video resolution(s) and video frame rate(s) for an MCVideo Group.
[R-5.1.1.1-011]
The MCVideo service shall provide a mechanism for automatic negotiation between MCVideo UEs for the establishment of a common video codec, corresponding video resolution(s) and video frame rate(s) for the duration of an MCVideo communication.
[R-5.1.1.1-012]
The MCVideo service shall support video resolution at least from 320 x 240 at 10 frames per second up to and beyond 1280 x 720 at 30 frames per second.
[R-5.1.1.1-012a]
An MCVideo UE that is able to transmit video may support a video resolution from 320 x 240 at 10 frames per second up to and beyond 1280 x 720 at 30 frames per second.
[R-5.1.1.1-012b]
An MCVideo UE that is able to receive videos shall support as a minimum, the reception, decoding and rendering of all 3GPP mandated video frame rates and resolutions.
[R-5.1.1.1-013]
The MCVideo service should enable high definition rendering of the video information with quality at least corresponding to video format 1080p (1920 × 1080 pixels HDTV resolution).
[R-5.1.1.1-014]
The MCVideo service should support the video capturing and storing of video information for objects moving at speeds of up to 150 km/h, with the ability to extract images of quality necessary for license plate reading.
[R-5.1.1.1-015]
The MCVideo service shall support mutual adaptation between the video codecs and the video information carrying bearer in terms of video resolution, frame rate and QoS characteristics (e.g. bandwidth, error rate).
[R-5.1.1.1-016]
The MCVideo service shall support UE entering the video communication late to identify the video resolution and frame rate being used and be able to start video capture, storage, encoding, transmission, reception, decoding and rendering with minimal delay upon entering the video communication.
[R-5.1.1.1-017]
The MCVideo service should support combined handling of video and audio information.
[R-5.1.1.1-018]
The MCVideo service shall support separate handling of video and audio information, including the ability to cipher, transport, store and deliver video and audio separately.
[R-5.1.1.1-019]
The MCVideo service shall enable uploaded images to be integrity protected on a per-frame basis and inter-frame basis.
5.1.1.2 End-user criteria and requirements for the selection of a video codec for MCVideo service Word‑p. 13
[R-5.1.1.2-001]
A single video codec for global interoperability shall be specified as mandatory. Other video codecs may be specified as optional where benefits over the global interoperability video codec are identified.
[R-5.1.1.2-002]
The global interoperability video codec shall be widely available and have a good in-field track record of availability, reliability, quality and responsiveness acquired over a substantive period of time of actual use as prescribed.
[R-5.1.1.2-003]
The global interoperability video codec shall have been extensively tested in all the potentially deployable operation modes.
[R-5.1.1.2-004]
The complexity, processing power and energy consumption of the global interoperability video codec should be in the "small" range for the specific task at hand, when other video codecs are used for comparison.
[R-5.1.1.2-005]
Based on the capabilities of the active UE(s) in possession of a user, each media component of a transmission received by the user shall be playable on at least one of the active UEs.
5.1.1.3 Video modes
5.1.1.3.1 Description
Although MCVideo requires low latency video streams not all video streams need to comply with the same low latency. There are some situations where the latency is less important but it is very important to capture what is visible in front of the camera at the precise time. These different requirements do not necessarily relate to the level of situational Emergency and so there is a difference in a MCVideo service between Emergency and urgency.
To avoid dimensioning a service to only cope with the most urgent requirements all the time and to avoid having the user community invoke Emergency just to mark a video as low latency, video modes are introduced.
5.1.1.3.2 Requirements
[R-5.1.1.3.2-001]
Based on authorized user or Administrator designation or based on profile information, the MCVideo transmissions shall be identifiable in one of three video modes i) urgent real time, ii) non-urgent real time, iii) non real time.
[R-5.1.1.3.2-002]
The MCVideo service shall provide a mechanism for an authorized MCVideo User or Administrator to set the video mode for an MCVideo Group.
[R-5.1.1.3.2-003]
The MCVideo service shall provide a mechanism for an authorized MCVideo User or Administrator to configure the allowed video modes for an MCVideo Group.
A single video codec for global interoperability shall be specified as mandatory. Other video codecs may be specified as optional where benefits over the global interoperability video codec are identified.
[R-5.1.1.2-002]
The global interoperability video codec shall be widely available and have a good in-field track record of availability, reliability, quality and responsiveness acquired over a substantive period of time of actual use as prescribed.
[R-5.1.1.2-003]
The global interoperability video codec shall have been extensively tested in all the potentially deployable operation modes.
[R-5.1.1.2-004]
The complexity, processing power and energy consumption of the global interoperability video codec should be in the "small" range for the specific task at hand, when other video codecs are used for comparison.
[R-5.1.1.2-005]
Based on the capabilities of the active UE(s) in possession of a user, each media component of a transmission received by the user shall be playable on at least one of the active UEs.
5.1.1.3.1 Description
Although MCVideo requires low latency video streams not all video streams need to comply with the same low latency. There are some situations where the latency is less important but it is very important to capture what is visible in front of the camera at the precise time. These different requirements do not necessarily relate to the level of situational Emergency and so there is a difference in a MCVideo service between Emergency and urgency.
To avoid dimensioning a service to only cope with the most urgent requirements all the time and to avoid having the user community invoke Emergency just to mark a video as low latency, video modes are introduced.
5.1.1.3.2 Requirements
[R-5.1.1.3.2-001]
Based on authorized user or Administrator designation or based on profile information, the MCVideo transmissions shall be identifiable in one of three video modes i) urgent real time, ii) non-urgent real time, iii) non real time.
[R-5.1.1.3.2-002]
The MCVideo service shall provide a mechanism for an authorized MCVideo User or Administrator to set the video mode for an MCVideo Group.
[R-5.1.1.3.2-003]
The MCVideo service shall provide a mechanism for an authorized MCVideo User or Administrator to configure the allowed video modes for an MCVideo Group.
5.1.2 Video parameters remote control
5.1.2.1 Remote modification of real time video quality
5.1.2.1.1 Service description
Circumstances can affect the quality of the video connection and it should therefore be possible to adapt the video connection parameters to those circumstances in an effective manner.
Mission critical control room operators and dispatchers will use video to analyse and control incidents in the field. The dispatcher might need to adapt the video quality to the purpose and for efficient use of 3GPP network resources. In the same way, an incident might be remotely managed by an officer in the field, using videos received from users involved in the incident and other sources. If only an overview of the scene is needed, a low video quality might be all that is needed. If there is a need to read a license plate or to recognize something in the scene, a very high definition video may be required. Those adaptations will have to be done in real time.
5.1.2.1.2 Requirements Word‑p. 14
[R-5.1.2.1.2-001]
The MCVideo service shall provide a mechanism for authorized MCVideo Users to remotely modify video settings in real time, through parameter modification (e.g. resolution modification) and through codec renegotiation.
[R-5.1.2.1.2-002]
The MCVideo service shall minimize the interruption and video information loss due to video parameter changes and codec renegotiation during video capture, transmission and rendering.
[R-5.1.2.1.2-003]
The MCVideo service shall provide a mechanism for authorized MCVideo Users to locally modify video quality, through parameter modification.
[R-5.1.2.1.2-004]
The MCVideo service shall provide a mechanism for an MCVideo Administrator to authorize an MCVideo User to modify the video settings of the transmitted video stream of another MCVideo User.
[R-5.1.2.1.2-005]
The MCVideo service shall provide a mechanism to negotiate a change of codec being used during the video transmission.
[R-5.1.2.1.2-006]
The MCVideo service shall provide a mechanism for an MCVideo Administrator to authorize an MCVideo User to renegotiate a codec during a video transmission.
[R-5.1.2.1.2-007]
The MCVideo service shall support signaling such that video capabilities or parameters for a camera can be remotely controlled on an MCVideo UE (e.g. to capture video, video clips, images of sufficient quality to perform the purpose intended).
The MCVideo service shall provide a mechanism for authorized MCVideo Users to remotely modify video settings in real time, through parameter modification (e.g. resolution modification) and through codec renegotiation.
[R-5.1.2.1.2-002]
The MCVideo service shall minimize the interruption and video information loss due to video parameter changes and codec renegotiation during video capture, transmission and rendering.
[R-5.1.2.1.2-003]
The MCVideo service shall provide a mechanism for authorized MCVideo Users to locally modify video quality, through parameter modification.
[R-5.1.2.1.2-004]
The MCVideo service shall provide a mechanism for an MCVideo Administrator to authorize an MCVideo User to modify the video settings of the transmitted video stream of another MCVideo User.
[R-5.1.2.1.2-005]
The MCVideo service shall provide a mechanism to negotiate a change of codec being used during the video transmission.
[R-5.1.2.1.2-006]
The MCVideo service shall provide a mechanism for an MCVideo Administrator to authorize an MCVideo User to renegotiate a codec during a video transmission.
[R-5.1.2.1.2-007]
The MCVideo service shall support signaling such that video capabilities or parameters for a camera can be remotely controlled on an MCVideo UE (e.g. to capture video, video clips, images of sufficient quality to perform the purpose intended).
5.1.2.2 Video capabilities information management
5.1.2.2.1 Service description
In order to enable remote control of video cameras in the field, there is a need to exchange those video capability parameters and to allow control of a subset of those parameters.
5.1.2.2.2 Requirements
[R-5.1.2.2.2-001]
The MCVideo service shall require authentication of the MCVideo User before granting service access to remotely control the video capabilities of a remote MCVideo UE.
[R-5.1.2.2.2-002]
The MCVideo service shall provide a mechanism by which an authorized MCVideo User can obtain and display the video capabilities of another MCVideo UE.
[R-5.1.2.2.2-003]
The MCVideo service shall provide a mechanism by which an authorized MCVideo User can limit what information to receive about a remote MCVideo UE.
[R-5.1.2.2.2-004]
The MCVideo service shall provide a mechanism for a MCVideo Administrator to authorize an MCVideo User to receive and display the capabilities of a remote MCVideo UE.
[R-5.1.2.2.2-005]
The MCVideo service shall support signaling such that a set of camera capabilities or parameters of an MCVideo UE can be displayed on a remote MCVideo UE.
5.1.3 Video remote control including camera discovery Word‑p. 15
5.1.3.1 Remote camera control
5.1.3.1.1 Service description
In addition to video parameters control, there is a need to remotely control the camera views (Pan, Tilt, Zoom). The technical solution need to leverage already existing standards.
In addition, a user will need to be able to capture and store video from a remote camera.
5.1.3.1.2 Requirements
[R-5.1.3.1.2-001]
The MCVideo service shall provide a mechanism for an MCVideo user to remotely control a camera on another MCVideo UE subject to relevant authorization.
[R-5.1.3.1.2-002]
The MCVideo service shall support signalling such that a set of video capabilities or parameters for a camera can be selected on an MCVideo UE (e.g. capture video, video clips and images of sufficient quality to perform the intended purpose).
[R-5.1.3.1.2-003]
The MCVideo service shall provide a mechanism through which an authorized MCVideo User can control camera functions not specifically related to the video stream e.g. Pan, Tilt and Zoom (PTZ), including being able to place a capable camera in and out of an automatic detection, activation and tracking mode.
[R-5.1.3.1.2-004]
The MCVideo service shall provide a mechanism for an MCVideo Administrator to authorize an MCVideo User to remotely activate another MCVideo User's camera.
5.1.3.2 Camera discovery
5.1.3.2.1 Service description
When arriving at an incident and/or affiliating to a group related to the incident, an authorized user wants to discover the cameras he/she can connect to and control.
The presence, exact location, addressing information, video coverage area and capabilities of cameras might not always be known to MCVideo Users. However, an authorized MCVideo User might want to discover and establish communication in order to avail himself of the video information provided by such cameras. The MCVideo service might need to control access of various users (or types of users) to different sets of cameras. For example, a remotely located medical expert might be granted access to cameras within ambulances at an incident scene, but not to security surveillance cameras. Within its allowed set of cameras, a user mightwant to find a subset that meets certain criteria. This can be achieved by establishing categories and associating them to various cameras. An interested user could then specify the categories of interest and the MCVideo Service would identify to the user cameras of the specified categories. Examples of categories include certain technical capabilities of the camera (e.g. self-activated camera, wide field of view etc.)and areas of use (traffic, security surveillance).
5.1.3.2.2 Requirements
[R-5.1.3.2.2-001]
An MCVideo UE shall be capable to discover, negotiate service, controlling parameters and capabilities, and to start receiving, storing and displaying video transmitted from another MCVideo UE.
[R-5.1.3.2.2-002]
An MCVideo UE shall be discoverable subject to permissions and authorization, capable of negotiating service, controlling parameters and capabilities, and remotely controlling another MCVideo UE.
[R-5.1.3.2.2-003]
The MCVideo service shall allow an MCVideo User to discover, determine the status, working parameters and capabilities and to negotiate service of MCVideo UEs within sets authorized to the MCVideo User.
[R-5.1.3.2.2-004]
The MCVideo service shall allow an MCVideo user to discover an MCVideo UE based on specified categories to which the MCVideo UE belongs.
5.1.3.3 Communications remote control Word‑p. 16
5.1.3.3.1 Service description
Authorized users will need to be able to remotely control video communications.
5.1.3.3.2 Requirements
[R-5.1.3.3.2-001]
The MCVideo service shall provide a mechanism for an authorised MCVideo User to remotely start and stop local recording of video.
[R-5.1.3.3.2-002]
The MCVideo service shall provide a mechanism for an authorised MCVideo User to remotely set triggers for automatic commencement of video transmission to authorised MCVideo Users; such triggers to include motion detection, time of day, face recognition, licence plate recognition, location and speed.
[R-5.1.3.3.2-003]
The MCVideo service shall provide a mechanism for an authorised MCVideo User to remotely start and stop playback of recorded video (including in low resolution fast-forward mode).
[R-5.1.3.3.2-004]
The MCVideo service shall provide a mechanism for an authorised MCVideo User to remotely initiate transmission of a selected part of a recorded video to authorised MCVideo Users.
5.1.4 Video processing capabilities
5.1.4.1 Service description
There is a need to have processing capabilities in order to enhance the user experience.
5.1.4.2 Requirements
[R-5.1.4.2-001]
The MCVideo system shall have video processing capabilities including combining different video streams, to show them on a single display unit, provide digital zoom within a video stream, adapt the size and resolution of a video stream to the size and resolution of the screen or window, record video and make stills of different video streams.
[R-5.1.4.2-002]
The MCVideo service shall provide a mechanism for recording video content for video processing purpose.
[R-5.1.4.2-003]
The MCVideo service shall provide a mechanism for capturing video content using coordinated multiple video cameras.
[R-5.1.4.2-004]
The MCVideo service shall provide a mechanism for determining in a reasonably indisputable way whether or not presented video content was captured with multiple cameras and at the same time.
[R-5.1.4.2-005]
The MCVideo service shall provide a mechanism for simultaneous activation and control of multiple video cameras.
[R-5.1.4.2-006]
The MCVideo service should support rendering video content in stereo 3D.
5.1.5 Robots video remote control
5.1.5.1 Service description
Robots 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 to manage videos from robots which can take advantage of different transport technologies such as a 3GPP system. The MCVideo service, working in conjunction with existing robot control capabilities, will provide mechanisms to do that.
The following subclause aims at defining requirements to ensure robot video control communication can be provided through a 3GPP system.
It is expected that there will be different manufacturers for robots. As a consequence a well-known transport framework is needed in order to ensure easy integration of new robots.
5.1.5.2 Requirements Word‑p. 17
[R-5.1.5.2-001]
A robot may be equipped with an MCVideo UE and provide functions of an MCVideo UE, such as remote control of video parameters.
[R-5.1.5.2-002]
The MCVideo service shall provide a mechanism to control the video settings of a robot.
[R-5.1.5.2-003]
The MCVideo service shall support aerial unmanned vehicles at an altitude of up to 150 meter above the floor.
[R-5.1.5.2-004]
The MCVideo service, in coordination with the MCData Service, shall be able to give different priorities to the communication for controlling the MCVideo UEs, the communication for controlling/driving the robot, the communication for controlling the video transmission from the robot and the video transmitted by the robot, depending also on who it is transmitted to (e.g. pilot, a dispatcher or a group).
[R-5.1.5.2-005]
The MCVideo service shall provide a minimum of four levels of latencies for controlling video:
-
When the MCVideo UE is in an aerial unmanned vehicle, during take-off and landing, the video control latency shall remain under 100 ms.
-
When the MCVideo UE is in an aerial unmanned vehicle, while flying, the video control latency shall remain under 300 ms.
-
When the MCVideo UE is in an aquatic or submarine unmanned vehicle, the video control latency shall remain under 500 ms.
-
When the MCVideo UE is in a terrestrial unmanned vehicle moving at less than 120km/h, the video control latency shall remain under 400 ms.
[R-5.1.5.2-006]
The MCVideo service shall provide a latency of the video transmission less than 500 ms when the video is used by the pilot.
[R-5.1.5.2-007]
Void.
5.1.6 MCVideo Profile management and administration
5.1.6.1 Service description
This clause describes the specific user profile management for MCVideo.
5.1.6.2 Requirements
[R-5.1.6.2-001]
The MCVideo service shall ensure that each MCVideo User has at least one associated MCVideo User Profile that contains the MCVideo's authorizations for video control, for example permissions to turn on/off cameras and displays, to enable video and audio transmission to authorized targets, to use normal controls for recording and/or playing the video, to raise and lower the resolution and the width of the visual field of the recording and of the transmission, to change the position of the visual field of the camera and to activate / deactivate motion sensors that can trigger the automatic activation of cameras.
5.1.7 Capabilities additional to MCCoRe Word‑p. 18
5.1.7.1 Leaving and rejoining an in progress video communication
5.1.7.1.1 Service description
Considering that video distribution will take significant amount of resources, and considering an operational user may in many cases not be available to watch a video, the system needs to provide an efficient means to manage entering and leaving video communications.
5.1.7.1.2 Requirements
[5.1.7.1.2-001]
The MCVideo service shall provide a means for a receiving MCVideo User to cancel receipt of a video stream on an MCVideo UE.
[5.1.7.1.2-002]
The MCVideo service shall provide a means for an MCVideo User to redirect on demand or in pre-determined fashion the receipt of a video stream between a receiving MCVideo UE and a video mail box.
[5.1.7.1.2-003]
The MCVideo service shall provide a means for an MCVideo User to rejoin a previously cancelled video stream.
[5.1.7.1.2-004]
When an MCVideo User cancels receipt of a video stream and has no other MCVideo UE receiving that video stream, an indication shall be sent to the sending MCVideo User as notification that the receiving user in question has left the video stream.
[5.1.7.1.2-005]
When an MCVideo User rejoins an ongoing video stream on a first MCVideo UE, an indication shall be sent to the sending MCVideo User as notification that the receiving user in question has rejoined the video stream.
[5.1.7.1.2-006]
If all receiving members of a video stream have left the video stream, the sending user shall be given an indication that all users have left and given the choice to end the video stream or continue sending the video for storage available for subsequent download by other users.
5.1.8 MCVideo capability information sharing
5.1.8.1 Service description
Before trying to remotely access the video capabilities of a UE, it might be useful to know about its capability in order to be sure the operational purpose can be achieved.
5.1.8.2 Requirements
[R-5.1.8.2-001]
Subject to permissions and authorization, the MCVideo service shall provide a means to share information about video capabilities (e.g. codecs) of MCVideo UEs under the control of members of a selected group.
[R-5.1.8.2-002]
Subject to permissions and authorizations, the MCVideo service shall provide a means to share current status of MCVideo UE activity (e.g. receiving video, transmitting video, or recording video) between the members of a selected group.
5.1.9 Video push and pull services
5.1.9.1 Video pull service
5.1.9.1.1 Service description
Users need the capability to pull a video from a source which might be a UE in the field, or a video storage server . In this service, a user requests another user to transmit a video stored or directly taken from the camera.
5.1.9.1.2 Requirements Word‑p. 19
[R-5.1.9.1.2-001]
The MCVideo service shall provide a mechanism for an authorized MCVideo User (e.g. dispatcher) to request an MCVideo UE to transmit a video to the requester, or to another authorized party or to both (uplink pull).
5.1.9.2 Video push service
5.1.9.2.1 Service description
Users need the capability to push a video to another user.
5.1.9.2.2 Requirements
[R-5.1.9.2.2-001]
The MCVideo service shall provide a mechanism for an authorized MCVideo User to push video to another MCVideo User.
[R-5.1.9.2.2-002]
The MCVideo service shall provide a mechanism for an MCVideo administrator to authorize an MCVideo user to push a video to another MCVideo user.
[R-5.1.9.2.2-003]
The MCVideo service shall provide a mechanism for an authorized MCVideo User to enable and to disable the automatic sending of notification to a second MCVideo User that a video is being pushed to a third MCVideo User.
[R-5.1.9.2.2-004]
The MCVideo service shall provide a mechanism for an MCVideo User to enable and to disable being notified about video being pushed to specific MCVideo Users.
[R-5.1.9.2.2-005]
The MCVideo service shall provide a mechanism for an MCVideo User to enable and to disable the reception of video of specific categories.
[R-5.1.9.2.2-006]
The MCVideo service shall provide a mechanism for an authorized MCVideo User to manage, activate and de-activate a blacklist for MCVideo push whereby if that authorized user has activated MCVideo push blacklisting and an incoming MCVideo push is received from an MCVideo user whose ID is configured in this list then the MCVideo push request from the sending MCVideo user is denied.
[R-5.1.9.2.2-007]
The MCVideo service shall provide a mechanism for an authorized MCVideo User to manage, activate and de-activate a whitelist for MCVideo push whereby if that authorized MCVideo user has activated MCVideo push whitelisting and an incoming MCVideo push is received from an MCVideo user whose ID is not configured in this list then the MCVideo push request from the sending MCVideo user is denied.
[R-5.1.9.2.2-008]
The MCVideo service shall provide a mechanism for an MCVideo User to suspend and to resume receiving an incoming video stream from an MCVideo push.
[R-5.1.9.2.2-009]
The MCVideo video push service shall allow the MCVideo user to configure the MCVideo UE either to automatically accept an incoming MCVideo push request or to prompt the user as to whether to manually accept or reject the incoming MCVideo push request from the sending MCVideo user.
[R-5.1.9.2.2-010]
The MCVideo service shall provide a mechanism for an MCVideo administrator to authorize an MCVideo user to use the MCvideo push blacklist and whitelist feature.
5.1.10 Video streams availability and characteristics
5.1.10.1 Service description
Users need to be informed of the existence and the technical and operational details of group video streams in progress. The user can then decide to join the stream or not, based on the information provided.
5.1.10.2 Requirements Word‑p. 20
[R-5.1.10.2-001]
The MCVideo service shall provide a mechanism for an authorized MCVideo User to forward details of a received video stream to other MCVideo users so that, if authorized, they may also join the MCVideo stream.
[R-5.1.10.2-002]
The MCVideo service shall provide a mechanism for an administrator and for an authorized user, or both, to locally and remotely assign specific category tags and access permissions to a specific MCVideo UE (e.g. a certain video camera) within their domain that can be used by authorized MCVideo Users to discover, select and address that MCVideo UE.
[R-5.1.10.2-003]
The MCVideo service shall provide a mechanism for an administrator and for an authorized user, or both, to locally and remotely assign specific category tags and access permissions to a specific video clip within their domain that can be used by authorized MCVideo users to view that video clip.
[R-5.1.10.2-004]
The MCVideo service shall provide a mechanism for the advertising and distribution of category tags associated with a specific MCVideo UE or a video clip.
[R-5.1.10.2-005]
The MCVideo service shall provide a mechanism for an MCVideo User to use and control each of his MCVideo UEs independently of the others.
[R-5.1.10.2-006]
The MCVideo service shall provide a mechanism for an MCVideo User to enable and to disable the alerting and displaying of notifications addressed to MCVideo UEs under his control.
[R-5.1.10.2-007]
The MCVideo service shall support a mechanism by which an external observer is prevented from determining whether or not an MCVideo UE is performing video capture, transmission, or both.
[R-5.1.10.2-008]
The MCVideo service shall be able to provide an integrity protected timestamped detailed log of all performed and attempted activities for each user of the MCVideo Service.
[R-5.1.10.2-009]
The MCVideo service shall be able to add and integrity protect meta-data to a video stream (e.g. time stamps, location coordinates, parameter settings, authorship information) at the time of the video capture and recording, such that the authenticity and accuracy of the recording cannot be disputed.
[R-5.1.10.2-010]
The MCVideo service shall provide a mechanism by which limits on information transfer parameters (e.g. bandwidth) can be set and adjusted dynamically in order to prevent or alleviate depletion of communication resources (e.g. congestion).
5.1.11 Video conferencing
5.1.11.1 Service description
For small groups working on the same operation, there is a need to have a video conferencing service. This service allows a group with limited size to exchange synchronized voice and video.
5.1.11.2 Requirements
[5.1.11.2-001]
The MCVideo service shall provide a video conferencing feature.
[5.1.11.2-002]
The MCVideo service shall provide a mechanism to limit the maximum number of Participants in a video conference.
[5.1.11.2-003]
The MCVideo service shall provide a means for an authorized User or Administrator to configure the maximum number of participants in a video conference.
[5.1.11.2-004]
Each participant in an MCVideo video conference shall be able to simultaneously transmit video and associated synchronized voice to all other video conference participants.
[5.1.11.2-005]
Each participant in a video conference, subject to UE display capabilities, shall be able to receive videos from all other participants.
[5.1.11.2-006]
Each participant in a video conference shall be able to choose and display a subset of video streams provided by other participants, while continuing to receive audio streams from all participants.
[5.1.11.2-007]
Each participant in a video conference shall be able to disable video and use the video conferencing service as a voice-only conference service.
5.1.12 Additional security requirements for MCVideo Word‑p. 21
5.1.12.1 General
Videos for public safety are critical and there is a need for them to be trustable. For evidentiary purposes Public Safety videos need to be certified as authentic and not tampered. The integrity of video data is of particular importance.
5.1.12.2 Requirements
[R-5.1.12.2-001]
The MCVideo service shall provide means for the generation, handling and storing of video material with evidentiary potential in a manner that guarantees its authenticity.
[R-5.1.12.2-002]
The MCVideo service shall provide means for tamper detection for video material with evidentiary potential.
[R-5.1.12.2-003]
The MCVideo service should provide means for tamper protection for video material with evidentiary potential.
[R-5.1.12.2-004]
The MCVideo service shall provide a mechanism by which security related information generated based on securely communicated data from the MCVideo server can be embedded in created videos and subsequently integrity protected, at the time of the video creation by the MCVideo capable UE.
[R-5.1.12.2-005]
The MCVideo service shall provide the ability for MCVideo server and MCVideo capable UEs to exchange MCData among themselves via secure links during the creation of videos.
[R-5.1.12.2-006]
MCVideo capable UEs shall be able to use location, time, subscription identity, device identity and information provided from outside the UE to generate and use security data for videos created by the UE.
5.1.3.1 Remote camera control
5.1.3.1.1 Service description
In addition to video parameters control, there is a need to remotely control the camera views (Pan, Tilt, Zoom). The technical solution need to leverage already existing standards.
In addition, a user will need to be able to capture and store video from a remote camera.
5.1.3.1.2 Requirements
[R-5.1.3.1.2-001]
The MCVideo service shall provide a mechanism for an MCVideo user to remotely control a camera on another MCVideo UE subject to relevant authorization.
[R-5.1.3.1.2-002]
The MCVideo service shall support signalling such that a set of video capabilities or parameters for a camera can be selected on an MCVideo UE (e.g. capture video, video clips and images of sufficient quality to perform the intended purpose).
[R-5.1.3.1.2-003]
The MCVideo service shall provide a mechanism through which an authorized MCVideo User can control camera functions not specifically related to the video stream e.g. Pan, Tilt and Zoom (PTZ), including being able to place a capable camera in and out of an automatic detection, activation and tracking mode.
[R-5.1.3.1.2-004]
The MCVideo service shall provide a mechanism for an MCVideo Administrator to authorize an MCVideo User to remotely activate another MCVideo User's camera.
5.1.3.2 Camera discovery
5.1.3.2.1 Service description
When arriving at an incident and/or affiliating to a group related to the incident, an authorized user wants to discover the cameras he/she can connect to and control.
The presence, exact location, addressing information, video coverage area and capabilities of cameras might not always be known to MCVideo Users. However, an authorized MCVideo User might want to discover and establish communication in order to avail himself of the video information provided by such cameras. The MCVideo service might need to control access of various users (or types of users) to different sets of cameras. For example, a remotely located medical expert might be granted access to cameras within ambulances at an incident scene, but not to security surveillance cameras. Within its allowed set of cameras, a user mightwant to find a subset that meets certain criteria. This can be achieved by establishing categories and associating them to various cameras. An interested user could then specify the categories of interest and the MCVideo Service would identify to the user cameras of the specified categories. Examples of categories include certain technical capabilities of the camera (e.g. self-activated camera, wide field of view etc.)and areas of use (traffic, security surveillance).
5.1.3.2.2 Requirements
[R-5.1.3.2.2-001]
An MCVideo UE shall be capable to discover, negotiate service, controlling parameters and capabilities, and to start receiving, storing and displaying video transmitted from another MCVideo UE.
[R-5.1.3.2.2-002]
An MCVideo UE shall be discoverable subject to permissions and authorization, capable of negotiating service, controlling parameters and capabilities, and remotely controlling another MCVideo UE.
[R-5.1.3.2.2-003]
The MCVideo service shall allow an MCVideo User to discover, determine the status, working parameters and capabilities and to negotiate service of MCVideo UEs within sets authorized to the MCVideo User.
[R-5.1.3.2.2-004]
The MCVideo service shall allow an MCVideo user to discover an MCVideo UE based on specified categories to which the MCVideo UE belongs.
5.1.3.3 Communications remote control Word‑p. 16
5.1.3.3.1 Service description
Authorized users will need to be able to remotely control video communications.
5.1.3.3.2 Requirements
[R-5.1.3.3.2-001]
The MCVideo service shall provide a mechanism for an authorised MCVideo User to remotely start and stop local recording of video.
[R-5.1.3.3.2-002]
The MCVideo service shall provide a mechanism for an authorised MCVideo User to remotely set triggers for automatic commencement of video transmission to authorised MCVideo Users; such triggers to include motion detection, time of day, face recognition, licence plate recognition, location and speed.
[R-5.1.3.3.2-003]
The MCVideo service shall provide a mechanism for an authorised MCVideo User to remotely start and stop playback of recorded video (including in low resolution fast-forward mode).
[R-5.1.3.3.2-004]
The MCVideo service shall provide a mechanism for an authorised MCVideo User to remotely initiate transmission of a selected part of a recorded video to authorised MCVideo Users.
5.1.3.3.1 Service description
Authorized users will need to be able to remotely control video communications.
5.1.3.3.2 Requirements
[R-5.1.3.3.2-001]
The MCVideo service shall provide a mechanism for an authorised MCVideo User to remotely start and stop local recording of video.
[R-5.1.3.3.2-002]
The MCVideo service shall provide a mechanism for an authorised MCVideo User to remotely set triggers for automatic commencement of video transmission to authorised MCVideo Users; such triggers to include motion detection, time of day, face recognition, licence plate recognition, location and speed.
[R-5.1.3.3.2-003]
The MCVideo service shall provide a mechanism for an authorised MCVideo User to remotely start and stop playback of recorded video (including in low resolution fast-forward mode).
[R-5.1.3.3.2-004]
The MCVideo service shall provide a mechanism for an authorised MCVideo User to remotely initiate transmission of a selected part of a recorded video to authorised MCVideo Users.
5.1.4.1 Service description
There is a need to have processing capabilities in order to enhance the user experience.
5.1.4.2 Requirements
[R-5.1.4.2-001]
The MCVideo system shall have video processing capabilities including combining different video streams, to show them on a single display unit, provide digital zoom within a video stream, adapt the size and resolution of a video stream to the size and resolution of the screen or window, record video and make stills of different video streams.
[R-5.1.4.2-002]
The MCVideo service shall provide a mechanism for recording video content for video processing purpose.
[R-5.1.4.2-003]
The MCVideo service shall provide a mechanism for capturing video content using coordinated multiple video cameras.
[R-5.1.4.2-004]
The MCVideo service shall provide a mechanism for determining in a reasonably indisputable way whether or not presented video content was captured with multiple cameras and at the same time.
[R-5.1.4.2-005]
The MCVideo service shall provide a mechanism for simultaneous activation and control of multiple video cameras.
[R-5.1.4.2-006]
The MCVideo service should support rendering video content in stereo 3D.
5.1.5.1 Service description
Robots 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 to manage videos from robots which can take advantage of different transport technologies such as a 3GPP system. The MCVideo service, working in conjunction with existing robot control capabilities, will provide mechanisms to do that.
The following subclause aims at defining requirements to ensure robot video control communication can be provided through a 3GPP system.
It is expected that there will be different manufacturers for robots. As a consequence a well-known transport framework is needed in order to ensure easy integration of new robots.
5.1.5.2 Requirements Word‑p. 17
[R-5.1.5.2-001]
A robot may be equipped with an MCVideo UE and provide functions of an MCVideo UE, such as remote control of video parameters.
[R-5.1.5.2-002]
The MCVideo service shall provide a mechanism to control the video settings of a robot.
[R-5.1.5.2-003]
The MCVideo service shall support aerial unmanned vehicles at an altitude of up to 150 meter above the floor.
[R-5.1.5.2-004]
The MCVideo service, in coordination with the MCData Service, shall be able to give different priorities to the communication for controlling the MCVideo UEs, the communication for controlling/driving the robot, the communication for controlling the video transmission from the robot and the video transmitted by the robot, depending also on who it is transmitted to (e.g. pilot, a dispatcher or a group).
[R-5.1.5.2-005]
The MCVideo service shall provide a minimum of four levels of latencies for controlling video:
-
When the MCVideo UE is in an aerial unmanned vehicle, during take-off and landing, the video control latency shall remain under 100 ms.
-
When the MCVideo UE is in an aerial unmanned vehicle, while flying, the video control latency shall remain under 300 ms.
-
When the MCVideo UE is in an aquatic or submarine unmanned vehicle, the video control latency shall remain under 500 ms.
-
When the MCVideo UE is in a terrestrial unmanned vehicle moving at less than 120km/h, the video control latency shall remain under 400 ms.
[R-5.1.5.2-006]
The MCVideo service shall provide a latency of the video transmission less than 500 ms when the video is used by the pilot.
[R-5.1.5.2-007]
Void.
A robot may be equipped with an MCVideo UE and provide functions of an MCVideo UE, such as remote control of video parameters.
[R-5.1.5.2-002]
The MCVideo service shall provide a mechanism to control the video settings of a robot.
[R-5.1.5.2-003]
The MCVideo service shall support aerial unmanned vehicles at an altitude of up to 150 meter above the floor.
[R-5.1.5.2-004]
The MCVideo service, in coordination with the MCData Service, shall be able to give different priorities to the communication for controlling the MCVideo UEs, the communication for controlling/driving the robot, the communication for controlling the video transmission from the robot and the video transmitted by the robot, depending also on who it is transmitted to (e.g. pilot, a dispatcher or a group).
[R-5.1.5.2-005]
The MCVideo service shall provide a minimum of four levels of latencies for controlling video:
- When the MCVideo UE is in an aerial unmanned vehicle, during take-off and landing, the video control latency shall remain under 100 ms.
- When the MCVideo UE is in an aerial unmanned vehicle, while flying, the video control latency shall remain under 300 ms.
- When the MCVideo UE is in an aquatic or submarine unmanned vehicle, the video control latency shall remain under 500 ms.
- When the MCVideo UE is in a terrestrial unmanned vehicle moving at less than 120km/h, the video control latency shall remain under 400 ms.
The MCVideo service shall provide a latency of the video transmission less than 500 ms when the video is used by the pilot.
[R-5.1.5.2-007]
Void.
5.1.6.1 Service description
This clause describes the specific user profile management for MCVideo.
5.1.6.2 Requirements
[R-5.1.6.2-001]
The MCVideo service shall ensure that each MCVideo User has at least one associated MCVideo User Profile that contains the MCVideo's authorizations for video control, for example permissions to turn on/off cameras and displays, to enable video and audio transmission to authorized targets, to use normal controls for recording and/or playing the video, to raise and lower the resolution and the width of the visual field of the recording and of the transmission, to change the position of the visual field of the camera and to activate / deactivate motion sensors that can trigger the automatic activation of cameras.
5.1.7.1 Leaving and rejoining an in progress video communication
5.1.7.1.1 Service description
Considering that video distribution will take significant amount of resources, and considering an operational user may in many cases not be available to watch a video, the system needs to provide an efficient means to manage entering and leaving video communications.
5.1.7.1.2 Requirements
[5.1.7.1.2-001]
The MCVideo service shall provide a means for a receiving MCVideo User to cancel receipt of a video stream on an MCVideo UE.
[5.1.7.1.2-002]
The MCVideo service shall provide a means for an MCVideo User to redirect on demand or in pre-determined fashion the receipt of a video stream between a receiving MCVideo UE and a video mail box.
[5.1.7.1.2-003]
The MCVideo service shall provide a means for an MCVideo User to rejoin a previously cancelled video stream.
[5.1.7.1.2-004]
When an MCVideo User cancels receipt of a video stream and has no other MCVideo UE receiving that video stream, an indication shall be sent to the sending MCVideo User as notification that the receiving user in question has left the video stream.
[5.1.7.1.2-005]
When an MCVideo User rejoins an ongoing video stream on a first MCVideo UE, an indication shall be sent to the sending MCVideo User as notification that the receiving user in question has rejoined the video stream.
[5.1.7.1.2-006]
If all receiving members of a video stream have left the video stream, the sending user shall be given an indication that all users have left and given the choice to end the video stream or continue sending the video for storage available for subsequent download by other users.
5.1.8 MCVideo capability information sharing
5.1.8.1 Service description
Before trying to remotely access the video capabilities of a UE, it might be useful to know about its capability in order to be sure the operational purpose can be achieved.
5.1.8.2 Requirements
[R-5.1.8.2-001]
Subject to permissions and authorization, the MCVideo service shall provide a means to share information about video capabilities (e.g. codecs) of MCVideo UEs under the control of members of a selected group.
[R-5.1.8.2-002]
Subject to permissions and authorizations, the MCVideo service shall provide a means to share current status of MCVideo UE activity (e.g. receiving video, transmitting video, or recording video) between the members of a selected group.
5.1.9 Video push and pull services
5.1.9.1 Video pull service
5.1.9.1.1 Service description
Users need the capability to pull a video from a source which might be a UE in the field, or a video storage server . In this service, a user requests another user to transmit a video stored or directly taken from the camera.
5.1.9.1.2 Requirements Word‑p. 19
[R-5.1.9.1.2-001]
The MCVideo service shall provide a mechanism for an authorized MCVideo User (e.g. dispatcher) to request an MCVideo UE to transmit a video to the requester, or to another authorized party or to both (uplink pull).
The MCVideo service shall provide a mechanism for an authorized MCVideo User (e.g. dispatcher) to request an MCVideo UE to transmit a video to the requester, or to another authorized party or to both (uplink pull).
5.1.9.2 Video push service
5.1.9.2.1 Service description
Users need the capability to push a video to another user.
5.1.9.2.2 Requirements
[R-5.1.9.2.2-001]
The MCVideo service shall provide a mechanism for an authorized MCVideo User to push video to another MCVideo User.
[R-5.1.9.2.2-002]
The MCVideo service shall provide a mechanism for an MCVideo administrator to authorize an MCVideo user to push a video to another MCVideo user.
[R-5.1.9.2.2-003]
The MCVideo service shall provide a mechanism for an authorized MCVideo User to enable and to disable the automatic sending of notification to a second MCVideo User that a video is being pushed to a third MCVideo User.
[R-5.1.9.2.2-004]
The MCVideo service shall provide a mechanism for an MCVideo User to enable and to disable being notified about video being pushed to specific MCVideo Users.
[R-5.1.9.2.2-005]
The MCVideo service shall provide a mechanism for an MCVideo User to enable and to disable the reception of video of specific categories.
[R-5.1.9.2.2-006]
The MCVideo service shall provide a mechanism for an authorized MCVideo User to manage, activate and de-activate a blacklist for MCVideo push whereby if that authorized user has activated MCVideo push blacklisting and an incoming MCVideo push is received from an MCVideo user whose ID is configured in this list then the MCVideo push request from the sending MCVideo user is denied.
[R-5.1.9.2.2-007]
The MCVideo service shall provide a mechanism for an authorized MCVideo User to manage, activate and de-activate a whitelist for MCVideo push whereby if that authorized MCVideo user has activated MCVideo push whitelisting and an incoming MCVideo push is received from an MCVideo user whose ID is not configured in this list then the MCVideo push request from the sending MCVideo user is denied.
[R-5.1.9.2.2-008]
The MCVideo service shall provide a mechanism for an MCVideo User to suspend and to resume receiving an incoming video stream from an MCVideo push.
[R-5.1.9.2.2-009]
The MCVideo video push service shall allow the MCVideo user to configure the MCVideo UE either to automatically accept an incoming MCVideo push request or to prompt the user as to whether to manually accept or reject the incoming MCVideo push request from the sending MCVideo user.
[R-5.1.9.2.2-010]
The MCVideo service shall provide a mechanism for an MCVideo administrator to authorize an MCVideo user to use the MCvideo push blacklist and whitelist feature.
5.1.10 Video streams availability and characteristics
5.1.10.1 Service description
Users need to be informed of the existence and the technical and operational details of group video streams in progress. The user can then decide to join the stream or not, based on the information provided.
5.1.10.2 Requirements Word‑p. 20
[R-5.1.10.2-001]
The MCVideo service shall provide a mechanism for an authorized MCVideo User to forward details of a received video stream to other MCVideo users so that, if authorized, they may also join the MCVideo stream.
[R-5.1.10.2-002]
The MCVideo service shall provide a mechanism for an administrator and for an authorized user, or both, to locally and remotely assign specific category tags and access permissions to a specific MCVideo UE (e.g. a certain video camera) within their domain that can be used by authorized MCVideo Users to discover, select and address that MCVideo UE.
[R-5.1.10.2-003]
The MCVideo service shall provide a mechanism for an administrator and for an authorized user, or both, to locally and remotely assign specific category tags and access permissions to a specific video clip within their domain that can be used by authorized MCVideo users to view that video clip.
[R-5.1.10.2-004]
The MCVideo service shall provide a mechanism for the advertising and distribution of category tags associated with a specific MCVideo UE or a video clip.
[R-5.1.10.2-005]
The MCVideo service shall provide a mechanism for an MCVideo User to use and control each of his MCVideo UEs independently of the others.
[R-5.1.10.2-006]
The MCVideo service shall provide a mechanism for an MCVideo User to enable and to disable the alerting and displaying of notifications addressed to MCVideo UEs under his control.
[R-5.1.10.2-007]
The MCVideo service shall support a mechanism by which an external observer is prevented from determining whether or not an MCVideo UE is performing video capture, transmission, or both.
[R-5.1.10.2-008]
The MCVideo service shall be able to provide an integrity protected timestamped detailed log of all performed and attempted activities for each user of the MCVideo Service.
[R-5.1.10.2-009]
The MCVideo service shall be able to add and integrity protect meta-data to a video stream (e.g. time stamps, location coordinates, parameter settings, authorship information) at the time of the video capture and recording, such that the authenticity and accuracy of the recording cannot be disputed.
[R-5.1.10.2-010]
The MCVideo service shall provide a mechanism by which limits on information transfer parameters (e.g. bandwidth) can be set and adjusted dynamically in order to prevent or alleviate depletion of communication resources (e.g. congestion).
The MCVideo service shall provide a mechanism for an authorized MCVideo User to forward details of a received video stream to other MCVideo users so that, if authorized, they may also join the MCVideo stream.
[R-5.1.10.2-002]
The MCVideo service shall provide a mechanism for an administrator and for an authorized user, or both, to locally and remotely assign specific category tags and access permissions to a specific MCVideo UE (e.g. a certain video camera) within their domain that can be used by authorized MCVideo Users to discover, select and address that MCVideo UE.
[R-5.1.10.2-003]
The MCVideo service shall provide a mechanism for an administrator and for an authorized user, or both, to locally and remotely assign specific category tags and access permissions to a specific video clip within their domain that can be used by authorized MCVideo users to view that video clip.
[R-5.1.10.2-004]
The MCVideo service shall provide a mechanism for the advertising and distribution of category tags associated with a specific MCVideo UE or a video clip.
[R-5.1.10.2-005]
The MCVideo service shall provide a mechanism for an MCVideo User to use and control each of his MCVideo UEs independently of the others.
[R-5.1.10.2-006]
The MCVideo service shall provide a mechanism for an MCVideo User to enable and to disable the alerting and displaying of notifications addressed to MCVideo UEs under his control.
[R-5.1.10.2-007]
The MCVideo service shall support a mechanism by which an external observer is prevented from determining whether or not an MCVideo UE is performing video capture, transmission, or both.
[R-5.1.10.2-008]
The MCVideo service shall be able to provide an integrity protected timestamped detailed log of all performed and attempted activities for each user of the MCVideo Service.
[R-5.1.10.2-009]
The MCVideo service shall be able to add and integrity protect meta-data to a video stream (e.g. time stamps, location coordinates, parameter settings, authorship information) at the time of the video capture and recording, such that the authenticity and accuracy of the recording cannot be disputed.
[R-5.1.10.2-010]
The MCVideo service shall provide a mechanism by which limits on information transfer parameters (e.g. bandwidth) can be set and adjusted dynamically in order to prevent or alleviate depletion of communication resources (e.g. congestion).
5.1.11 Video conferencing
5.1.11.1 Service description
For small groups working on the same operation, there is a need to have a video conferencing service. This service allows a group with limited size to exchange synchronized voice and video.
5.1.11.2 Requirements
[5.1.11.2-001]
The MCVideo service shall provide a video conferencing feature.
[5.1.11.2-002]
The MCVideo service shall provide a mechanism to limit the maximum number of Participants in a video conference.
[5.1.11.2-003]
The MCVideo service shall provide a means for an authorized User or Administrator to configure the maximum number of participants in a video conference.
[5.1.11.2-004]
Each participant in an MCVideo video conference shall be able to simultaneously transmit video and associated synchronized voice to all other video conference participants.
[5.1.11.2-005]
Each participant in a video conference, subject to UE display capabilities, shall be able to receive videos from all other participants.
[5.1.11.2-006]
Each participant in a video conference shall be able to choose and display a subset of video streams provided by other participants, while continuing to receive audio streams from all participants.
[5.1.11.2-007]
Each participant in a video conference shall be able to disable video and use the video conferencing service as a voice-only conference service.
5.1.12 Additional security requirements for MCVideo Word‑p. 21
5.1.12.1 General
Videos for public safety are critical and there is a need for them to be trustable. For evidentiary purposes Public Safety videos need to be certified as authentic and not tampered. The integrity of video data is of particular importance.
5.1.12.2 Requirements
[R-5.1.12.2-001]
The MCVideo service shall provide means for the generation, handling and storing of video material with evidentiary potential in a manner that guarantees its authenticity.
[R-5.1.12.2-002]
The MCVideo service shall provide means for tamper detection for video material with evidentiary potential.
[R-5.1.12.2-003]
The MCVideo service should provide means for tamper protection for video material with evidentiary potential.
[R-5.1.12.2-004]
The MCVideo service shall provide a mechanism by which security related information generated based on securely communicated data from the MCVideo server can be embedded in created videos and subsequently integrity protected, at the time of the video creation by the MCVideo capable UE.
[R-5.1.12.2-005]
The MCVideo service shall provide the ability for MCVideo server and MCVideo capable UEs to exchange MCData among themselves via secure links during the creation of videos.
[R-5.1.12.2-006]
MCVideo capable UEs shall be able to use location, time, subscription identity, device identity and information provided from outside the UE to generate and use security data for videos created by the UE.
5.1.12.1 General
Videos for public safety are critical and there is a need for them to be trustable. For evidentiary purposes Public Safety videos need to be certified as authentic and not tampered. The integrity of video data is of particular importance.
5.1.12.2 Requirements
[R-5.1.12.2-001]
The MCVideo service shall provide means for the generation, handling and storing of video material with evidentiary potential in a manner that guarantees its authenticity.
[R-5.1.12.2-002]
The MCVideo service shall provide means for tamper detection for video material with evidentiary potential.
[R-5.1.12.2-003]
The MCVideo service should provide means for tamper protection for video material with evidentiary potential.
[R-5.1.12.2-004]
The MCVideo service shall provide a mechanism by which security related information generated based on securely communicated data from the MCVideo server can be embedded in created videos and subsequently integrity protected, at the time of the video creation by the MCVideo capable UE.
[R-5.1.12.2-005]
The MCVideo service shall provide the ability for MCVideo server and MCVideo capable UEs to exchange MCData among themselves via secure links during the creation of videos.
[R-5.1.12.2-006]
MCVideo capable UEs shall be able to use location, time, subscription identity, device identity and information provided from outside the UE to generate and use security data for videos created by the UE.
