5 MCVideo specific requirements
22.2813GPPMission Critical (MC) videoTS
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.
[R-5.1.1.1-002] 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
[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.
NOTE: This requirement refers to 3GPP action. Local, national and regional authorities can make additional video codecs mandatory within their jurisdiction.
[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.
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
[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.
NOTE: While a dispatcher remotely controls an MCVideo UE in the field, the local modification of parameters is forbidden.
[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
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.
NOTE: Existing protocols (e.g. TVNP) could be used.
[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
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 sub-clause 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
[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.
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.
[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
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.
NOTE: This ceases to apply if the video stream has terminated for any reason.
[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
[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.
NOTE: The second and the third MCVideo Users can be the same 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.
NOTE: It is not recommended to have both MCVideo push blacklisting and MCVideo push whitelisting activated at the same time.
[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
[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.
NOTE: If relevant, the MCVideo service builds a mosaic with all the video streams and provide the mosaic to all interested participants. All the associated audio streams will be provided in this case.
[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
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.2 MCVideo services requirements specific to on-network use
5.2.1 Video availability notification
5.2.1.1 Service description
This function aims at informing the user when there is a video file which he could be interested in. The notification might also enclose a description of the video as well as an indication of its operational importance.
In this service the video has been stored and is not part of an ongoing video transmission.
5.2.1.2 Requirements
[R-5.2.1.2-001] An authorized MCVideo User shall be able to notify an MCVideo Group of the availability of a video.
[R-5.2.1.2-002] An authorized MCVideo User shall be able to individually notify an MCVideo User outside an MCVideo Group that a video is available independently from any affiliation mechanism.
[R-5.2.1.2-003] The MCVideo service shall provide a mechanism for an authorized MCVideo User to retrieve and view a video that has been identified in a notification.
[R-5.2.1.2-004] The MCVideo availability notification may use another service (e.g. MCData).
[R-5.2.1.2-005] The MCVideo service shall only send video notifications to MCVideo Users authorized to view the video.
5.2.2 Replay of stored video
5.2.2.1 Service description
This function aims at offering video tape functions for a user viewing a video as well as an opportunity to choose and view video files stored on the server.
5.2.2.2 Requirements
[R-5.2.2.2-001] The MCVideo service shall provide an authorization mechanism for MCVideo Users and MCVideo Groups to view a remotely stored video.
[R-5.2.2.2-002] The MCVideo service shall provide a mechanism for an authorized MCVideo User to view a video with simple video player functions (e.g. pause rewind, forward).
[R-5.2.2.2-003] The MCVideo service shall provide a list of available and authorized videos for the MCVideo User.
[R-5.2.2.2-004] The MCVideo service shall provide a means to associate MCVideo User authorizations to each file for viewing, modifying and/or deleting the file.
NOTE: This mechanism might use groups of users.
5.2.3 Video storage control
5.2.3.1 Service description
Since mission critical video is sensitive data with varying local regulatory issues, an MCVideo system cannot allow videos to be viewed or copied by unauthorized people. As a consequence, there is a need to have a mechanism to automatically delete videos from a terminal as well as a mechanism to remotely delete videos from a terminal.
5.2.3.2 Requirements
[R-5.2.3.2-001] The MCVideo service shall provide a means for an administrator to remotely select and delete selected videos and associated data of an MCVideo User from the MCVideo UE.
[R-5.2.3.2-002] The MCVideo service shall provide a means by which all MCVideo data (including video related metadata) are periodically deleted from the MCVideo UE unless an action is taken by an authorized MCVideo User.
[R-5.2.3.2-003] The deletion period shall be configurable.
5.2.4 Capabilities additional to MCCoRe
5.2.4.1 Service description
This function aims at restricting use of video services to a specific authorized MCVideo User.
5.2.4.2 Requirements
[R-5.2.4.2-001] The MCVideo Service shall provide a mechanism for an MCVideo Administrator to restrict an MCVideo User’s video communication to MCVideo use only.
5.2.5 Video control by a dispatcher
5.2.5.1 Service description
Dispatchers need advanced capabilities for managing MCVideo services for MCVideo Users and fixed cameras under their control.
5.2.5.2 Requirements
[R-5.2.5.2-001] The MCVideo service shall provide a mechanism for a dispatcher of an MCVideo Group to request a monitoring camera to transmit a video to the dispatcher.
[R-5.2.5.2-002] The MCVideo service shall provide a mechanism for a dispatcher of an MCVideo Group to terminate the video transmission from the monitoring camera to the dispatcher.
[R-5.2.5.2-003] The MCVideo service shall provide a mechanism for a dispatcher of an MCVideo Group to request a monitoring camera to transmit a video to an authorized user.
[R-5.2.5.2-004] The MCVideo service shall provide a mechanism for a dispatcher of an MCVideo Group to terminate the video transmission from the monitoring camera to the authorized user.
[R-5.2.5.2-005] The MCVideo service shall provide a mechanism for a dispatcher to distribute a video to MCVideo Group Members.
[R-5.2.5.2-006] The MCVideo service shall provide a mechanism for a dispatcher to terminate the video distribution to MCVideo Group Members.
[R-5.2.5.2-007] The MCVideo service shall provide a mechanism for a dispatcher or an authorized user to build a mosaic from different video sources and transmit this mosaic in an MCVideo group communication.
[R-5.2.5.2-008] The MCVideo Service shall provide a means to obtain the video display capabilities available for an MCVideo User.
[R-5.2.5.2-009] The MCVideo service shall provide a mechanism to ensure that a target MCVideo User is able to watch a mosaic video before transmission to the user begins.
5.2.6 Transmission control
5.2.6.1 Overview
MCVideo provides a method of working where each video being sent is delivered as an invitation to the affiliated group members for them to elect to commence receiving or not as suits their situation. It is far better not to send video to a user who is unable to view it. Conflicting or simultaneous video communications would result in simultaneous (or near simultaneous) invitations to join and the users can choose which video communication, if any, to join. Forced reception of video can be configured by an authorised user. In this case, suitably authorised receiving users could be permitted to opt out of viewing, perhaps because they have a specific task to watch some other stream.
As a consequence a video group communication can allow the user to accept the video stream before receiving a video and can allow the user to choose from available video streams amongst a list of ongoing video streams available to the user.
5.2.6.2 Transmission control requirements
5.2.6.2.1 General
[R-5.2.6.2.1-001] The MCVideo service shall determine which Participant(s) are allowed to transmit a video stream.
[R-5.2.6.2.1-002] An authorized Participant shall be able to request to transmit to an MCVideo Group or an individual.
[R-5.2.6.2.1-003] When a request to transmit a video stream to an MCVideo Group is granted the MCVideo service shall send an invitation to all affiliated members of the selected group to allow them to accept to receive the video.
[R-5.2.6.2.1-004] An MCVideo Group shall have the flexibility to be configured to allow simultaneous transmitting MCVideo Group Members.
[R-5.2.6.2.1-005] MCVideo service shall provide a mechanism for the MCVideo Administrator to configure the maximum number of simultaneous transmissions in a single MCVideo Group.
NOTE: No limit is a valid setting.
[R-5.2.6.2.1-006] The MCVideo service shall determine who is allowed to transmit when there are requests to transmit more than the maximum number of simultaneous communications within the same group.
[R-5.2.6.2.1-007] The MCVideo service may withhold permission to transmit for service based pre-emptive capacity reasons.
[R-5.2.6.2.1-008] Following an MCVideo service request for permission to transmit on the Selected MCVideo Group, the Affiliated MCVideo Group Member that made and was granted the request shall be given an indication of being granted permission to transmit.
[R-5.2.6.2.1-009] Following an MCVideo Private Communication request for permission to transmit, an MCVideo User that is allowed to transmit shall be given an indication that the user is allowed to transmit to the targeted MCVideo User(s).
[R-5.2.6.2.1-010] When a user is not allowed to start a Group communication the request may be queued or rejected.
[R-5.2.6.2.1-011] Following an MCVideo Group service request for permission to transmit on the Selected MCVideo Group, an Affiliated MCVideo Group Member that made but was not granted the request shall be given an indication that permission to transmit was queued or rejected.
[R-5.2.6.2.1-012] Following an MCVideo Private Communication request for permission to transmit, an MCVideo User that is not allowed to transmit shall be given an indication that the permission to transmit was queued or rejected.
5.2.6.2.2 Receiving video streams
[R-5.2.6.2.2-001] When a video group communication is started using a particular MCVideo Group all affiliated group members for that same MCVideo group shall be sent an invitation notifying them of the new video stream.
[R-5.2.6.2.2-002] The MCVideo service shall provide a mechanism to include conditions for acceptance or rejection of the invitation (e.g. forced, unforced).
[R-5.2.6.2.2-003] In the case of unforced invitation to receive an MCVideo user shall receive the video stream of a MCVideo communication only after having accepted the invitation.
[R-5.2.6.2.2-004] MCVideo service shall provide a mechanism for the MCVideo Administrator to configure the maximum number of simultaneous streams received by an MCVideo User.
NOTE 1: No limit is a valid setting.
[R-5.2.6.2.2-005] As a configuration option, the MCVideo system shall provide a means for an authorized MCVideo user to automatically receive video communications.
NOTE 2: When configured for the User to receive a video stream automatically, the transmission starts without acceptance of the receiving MCVideo User.
[R-5.2.6.2.2-006] As a configuration option, the MCVideo service shall provide a means for an MCVideo user to automatically receive emergency video streams.
[R-5.2.6.2.2-007] As a configuration option, the MCVideo service shall provide a means for an authorized MCVideo user to automatically receive imminent peril video streams.
[R-5.2.6.2.2-008] An authorised user shall be able to configure an MCVideo group to support individual user/UE opt in to receive communications or mandatory/automatic reception.
[R-5.2.6.2.2-009] An MCVideo user shall be able to opt in to receive communications for any recently invited group communications for which the MCVideo user is affiliated.
NOTE 3: A list of recent invitations to opt in is stored and presented to the user on demand. Recent might be time limited, size of list limited or any other limit. Ceased communications is removed from the opt in invitation list.
[R-5.2.6.2.2-010] When a video private communication is started the receiving participant shall be given the option of accepting or rejecting the communication.
5.2.6.2.3 Entering an ongoing video stream
[R-5.2.6.2.3-001] The MCVideo service shall provide to the MCVideo User the list of ongoing/currently transmitting video group communications, for which he is affiliated, periodically and on demand.
[R-5.2.6.2.3-002] The MCVideo user shall be able to choose one or more video group communications subject to MCVideo settings and UE capabilities (e.g. MCVideo UE display capabilities).
[R-5.2.6.2.3-003] The MCVideo service shall provide a means to separately control the sound of the different video communications received.
5.2.6.2.4 Video streams reconfiguration and termination
[R-5.2.6.2.4-001] The MCVideo service shall make efficient use of resources (e.g. use of eMBMS).
[R-5.2.6.2.4-002] The MCVideo service shall provide a notification to a transmitting MCVideo Group Member if there are no other MCVideo Group Members who have affiliated to the MCVideo Group.
[R-5.2.6.2.4-003] The MCVideo service shall provide a notification to a transmitting MCVideo Group Member if there are no MCVideo Group Members receiving their communication.
NOTE: When an opt in communication is commenced, a reasonable time is allowed for other users to opt to receive the communication before such a notification is sent.
[R-5.2.6.2.4-004] The MCVideo service may interrupt the transmission of an MCVideo communication when there is no MCVideo User receiving it.
[R-5.2.6.2.4-005] The MCVideo service may restart the transmission of an MCVideo communication as soon as any affiliated/authorized user wants to receive the MCVideo communication.
5.2.7 Override
5.2.7.1 Overview
For MCVideo override is possible and useful but is different from MCPTT.
MCVideo might be operated in a combined way with MCPTT. Therefore, it is likely that the sending user will have the opportunity to state what their intention is for the video that they send. In this case it might not be necessary for other regular members of the group to receive the video but the dispatcher might always receive it. In this situation, when the group invitation is sent, individual users could request to join the video if it is useful to them and convenient. Override can then be achieved by the user realising, from the MCPTT call, that another video is more important and so switching over to receive the new one.
As an alternative to the invitation approach a forced approach is still possible but a group force of a video is an unpredictable option as some users might well be unable to view the video. Forced override is still possible in MCVideo. The video is announced as an invitation but includes a forced override indication. The system makes the forced override but, depending on configuration, the user might be able to review a list of allowed continuing video streams and go back to the one they are using.
MCVideo might operate in a group way with many members of the group sending video to a dispatcher (private call) and the dispatcher periodically selecting and sending video back to the group.
5.2.7.2 General aspects
[R-5.2.7.2-001] The MCVideo Service shall enable an MCVideo Service Administrator to create a hierarchy for determining which Participants, Participant types, and urgent transmission types, if any, shall be granted a request to override an active MCVideo Service transmission.
[R-5.2.7.2-002] The MCVideo Service shall enable an MCVideo Service Administrator to configure which MCVideo Service Group transmission(s) a Participant(s) receives for cases where an MCVideo Service transmission can be overridden and/or to configure to allow the Participant to select from available video streams.
[R-5.2.7.2-003] The MCVideo service shall enable the MCVideo Service Administrator to configure the MCVideo Service Group to limit the number of Participant(s) allowed to transmit at the same time into the same group.
[R-5.2.7.2-004] The MCVideo service shall provide a mechanism for an MCVideo Service Administrator to configure MCVideo Service Private Communications to pre-empt or not to pre-empt active received group communications.
[R-5.2.7.2-005] Any hierarchy used for granting a request to override an active MCVideo Service transmission shall contain at least four (4) levels.
[R-5.2.7.2-006] The transmitting Participant(s) shall be determined by the relative priorities of the Participants, number of allowed transmissions and Communication type based on configuration.
[R-5.2.7.2-007] The MCVideo service shall provide a mechanism for Participants, to override an active MCVideo Service transmission of a transmitting Participant based on configuration.
[R-5.2.7.2-008] If an MCVideo service transmission is overridden, the MCVideo Service shall provide a means of notifying the overridden Participant(s) that the transmission has been overridden.
[R-5.2.7.2-009] If the MCVideo Service Group limit for the number of Participant(s) allowed to communicate at the same time into the same group would otherwise be exceeded, the MCVideo service shall revoke transmit permissions for non-emergency communications using the relative priorities of the Participants, emergency state and video mode based on configuration.
5.2.8 Communication termination
[R-5.2.8-001] The MCVideo service shall enable an authorized MCVideo User to terminate the permission to transmit of a transmitting Participant at any time.
[R-5.2.8-002] A transmitting Participant shall be able to indicate to the MCVideo service that the Participant no longer wants to transmit.
[R-5.2.8-003] If a receiving Participant of an MCVideo Service Group Communication is pre-empted, the MCVideo Service may terminate the communication or continue the communication with an indication to the transmitting Participant that one or more receiving Participants was pre-empted.
NOTE 1: If the transmitting participant is pre-empted the communication stops.
[R-5.2.8-004] If MCVideo User(s) are pre-empted from an on-going MCVideo service communication as there is insufficient capacity to support their on-going participation, the MCVideo service may ensure that the MCVideo User(s) receive a notification that they have been removed from the communication for reasons of lack of capacity.
[R-5.2.8-005] The MCVideo service shall have a configurable limit for the length of time that a Participant transmits from a single request to transmit.
NOTE 2: Infinite is a valid setting for the transmit time limit.
[R-5.2.8-006] The MCVideo service shall enable an MCVideo Administrator to configure the limit for the length of time that a Participant transmits from a single request to transmit.
[R-5.2.8-007] The MCVideo service may provide a notification of intent to terminate a communication e.g. to give the user time to request a time limit extension.
[R-5.2.8-008] The MCVideo service may terminate a communication without previously sending a notification.
[R-5.2.8-009] The MCVideo service may include an indication of termination reason (e.g. time limit, administrator action) with any notification of intent to terminate or actual termination.
[R-5.2.8-010] An MCVideo UE shall provide, to the User, a notification of termination or intent to terminate including any reason given.
[R-5.2.8-011] The MCVideo service may include a request for more information with any notification of intent to terminate communication.
NOTE 3: For example, to allow the user to request additional time, if required.
[R-5.2.8-012] An MCVideo UE shall respond to a request for more information.
[R-5.2.8-012a] The response to a request for more information may include request for more time, indicate no foreseen end to the communication.
[R-5.2.8-013] The MCVideo service shall terminate an MCVideo Service Group Communication if any termination condition is met (e.g. last Participant leaving, second last Participant leaving, initiator leaving, time limit) or the minimum number of Affiliated MCVideo Service Group Members are not present.
5.3 MCVideo services requirements specific to off-network use
5.3.1 Private Communication Off-Network
5.3.1.1 Overview
Private Communications allow two MCVideo Users to communicate directly with each other without the use of MCVideo Groups. They leverage many of the functions and features of MCVideo Group Communication, such as MCVideo User identity and alias information, location information, encryption, privacy, priority, and administrative control. This capability establishes the ability to transmit unidirectional video between two MCVideo Users, but could be used to create a bi-directional video conferencing capability.
Two commencement modes of Private Communication are supported: Manual Commencement Private Communication and Automatic Commencement Private Communication.
Manual Commencement Private Communication mimics a telephone conversation where the receiving party receives a notification that they are being requested to join a Private Communication, and the receiving party might accept, reject, or ignore the Communication request. Once the Communication setup is accepted, the Private Communication is established.
Automatic Commencement Private Communication mimics the immediate setup and propagation of Group Communication operation between two users where the transmitting party initiates an Automatic Commencement Private Communication to another user and sends video without any additional Communication setup delay beyond Group Communication. If available and able to accept the Private Communication from the transmitting party, the receiving party immediately joins the Private Communication and processes the Communication transmitting party’s video.
5.3.1.2 Private Communication Off-Network general requirements
[R-5.3.1.2-001] The MCVideo service shall support Private Communications Off-Network.
[R-5.3.1.2-002] The MCVideo Service shall provide a mechanism for the Private Communication to be set up with the MCVideo UE designated by the receiving MCVideo User to be used for Private Communications when the receiving MCVideo User has signed on to the MCVideo service with multiple MCVideo UEs.
5.3.1.3 Private Communication Off-Network commencement requirements
[R-5.3.1.3-001] The MCVideo service shall provide a mechanism for an MCVideo User to cancel an MCVideo Private Communication prior to the Communication setup.
[R-5.3.1.3-002] The MCVideo service shall provide a means by which an authorized MCVideo User initiates an MCVideo Private Communication.
[R-5.3.1.3-003] The MCVideo service shall provide a means by which an MCVideo UE initiates an MCVideo Private Communication to any MCVideo User for which the MCVideo UE’s current MCVideo User is authorized.
NOTE: For off-network use, only an MCVideo UE within communication range (possibly via a ProSe UE-to-UE Relay) receives the transmission.
[R-5.3.1.3-004] The MCVideo service shall provide a means by which an MCVideo User initiates an Automatic Commencement Private Communication to any MCVideo User for which the MCVideo User is authorized.
5.3.1.4 Private Communication Off-Network termination
[R-5.3.1.4-001] The MCVideo service shall provide a mechanism for an MCVideo User to reject an MCVideo Private Communication.
[R-5.3.1.4-002] The MCVideo service shall provide a means by which an MCVideo User ends a Private Communication in which the MCVideo User is a Participant.
5.3.1.5 Private Communication Off-Network administration
[R-5.3.1.5-001] The MCVideo service shall provide a mechanism for an MCVideo Administrator to configure which MCVideo Users, within their authority, are authorized to place a Manual Commencement Private Communication.
[R-5.3.1.5-002] The MCVideo service shall provide a mechanism for an MCVideo Administrator to configure which MCVideo Users, within their authority, are authorized to place an Automatic Commencement Private Communication.
[R-5.3.1.5-003] The MCVideo service shall provide a mechanism for an MCVideo Administrator to configure for a particular authorized MCVideo User, a set of MCVideo Users under the same authority to which an MCVideo Private Communication can be made.
[R-5.3.1.5-004] The MCVideo service shall provide a mechanism for an MCVideo Administrator to configure the maximum duration for MCVideo Private Communications for MCVideo Users within their authority.
5.3.2 MCVideo Transmission Control Off-Network
5.3.2.1 Overview
MCVideo Transmission Control Off-Network provides a necessary capability for an authorized user of the
MCVideo 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 MCVideo user no longer wants to transmit. A transmit time limit is provided which allows an MCVideo Administrator to configure the limits for any transmission related to a single request to transmit. MCVideo Transmission Control Off-Network also provides an override capability based on a priority hierarchy to override an active MCVideo transmission of a transmitting Participant based on configuration.
5.3.2.2 General Aspects
[R-5.3.2.2-001] The MCVideo 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-5.3.2.2-002] An MCVideo Group shall have the flexibility to be configured to allow simultaneous transmitting MCVideo Group Members.
[R-5.3.2.2-003] The MCVideo service shall provide a mechanism for the MCVideo Service Administrator to configure the maximum number of simultaneous communications received by an off-network MCVideo User in a single MCVideo Group.
5.3.2.3 Requesting Permission to Transmit
[R-5.3.2.3-001] An authorized Participant shall be able to request to transmit to an MCVideo Group or an individual MCVideo User.
[R-5.3.2.3-002] The MCVideo service shall determine which Participant(s) are permitted to transmit when there are simultaneous requests for permission to transmit within the same group.
[R-5.3.2.3-003] Following an MCVideo request for permission to transmit on the Selected MCVideo Group, any Affiliated MCVideo User that made and was granted the request shall be given an indication of being allowed to transmit.
[R-5.3.2.3-004] Following an MCVideo request for permission to transmit on the Selected MCVideo Group, any Affiliated MCVideo 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-5.3.2.3-005] The MCVideo service when operating off-network shall provide a mechanism for an MCVideo Participant to cancel its MCVideo request to transmit at any stage, including before the request has been granted.
[R-5.3.2.3-006] The MCVideo service shall provide a mechanism for the MCVideo Administrator to configure parameter(s) relating to the automatic termination of an off-network MCVideo service request to transmit.
5.3.2.4 Override
[R-5.3.2.4-001] An MCVideo UE shall be pre-provisioned by an MCVideo Administrator and/or authorized user with the necessary information in order that override may operate during off-network MCVideo communication.
[R-5.3.2.4-002] The MCVideo service shall provide a mechanism for MCVideo 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 MCVideo transmission.
[R-5.3.2.4-003] The priority hierarchy used for granting a request to override an active MCVideo transmission shall contain at least four (4) levels.
[R-5.3.2.4-004] The MCVideo service shall provide a mechanism for Participants, to override an active MCVideo transmission of a transmitting Participant based on configuration.
[R-5.3.2.4-005] If an MCVideo transmission is overridden, the MCVideo Service shall provide a means of notifying the overridden Participant(s) that the transmission has been overridden.
[R-5.3.2.4-006] The MCVideo service shall provide a mechanism to enable an MCVideo Administrator to configure which MCVideo Group transmission(s) a Participant(s) receives, for cases where an MCVideo transmission can be overridden.
[R-5.3.2.4-007] If the MCVideo Group has been configured to only allow the overriding transmitting Participant to transmit, the MCVideo service shall revoke the transmit permission of the overridden transmitting Participant.
5.3.2.5 Terminating Permission to Transmit
[R-5.3.2.5-001] A transmitting Participant shall be able to indicate to the off-network MCVideo service that the Participant no longer wants to transmit.
[R-5.3.2.5-002] The off-network MCVideo service shall provide an indication to receiving Participants that the transmitting Participant has finished transmitting.
5.3.2.6 Transmit Time Limit
[R-5.3.2.6-001] The Off-Network MCVideo Service shall provide a mechanism for an MCVideo UE to be pre-provisioned by an MCVideo Administrator and/or authorized user with the necessary information in order that a transmit time limit function may operate during off-network MCVideo communication.
[R-5.3.2.6-002] The Off-Network MCVideo Service shall enable an MCVideo Administrator to configure the limits (e.g. elapsed time, quantity of data) for any transmission related to a single request to transmit.
[R-5.3.2.6-003] The Off-Network MCVideo 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-5.3.2.6-004] The Off-Network MCVideo Service shall provide an indication to the transmitting Participant a configurable amount before the transmit limit is reached.
[R-5.3.2.6-005] The Off-Network MCVideo Service shall provide an indication to the transmitting Participant that the Participant’s transmit limit has been reached.
[R-5.3.2.6-006] The Off-Network MCVideo Service shall remove the permission to transmit from the transmitting Participant when the Participant’s transmit limit has been reached.
5.4 Performance and quality requirements for on-network and off-network
5.4.1 MCVideo device and camera moving at high speed
5.4.1.1 Service description
Motion affects the length of time a desired target is shown in the video frame, and can cause the target to blur. The level of motion in a particular piece of video content can have a huge impact on the performance of a video coder. A moving camera might also produce video that is much more difficult to encode efficiently.
For public safety applications, if the video is considered “mission critical,” the loss or interruption of a video stream or any significant delay in the delivery of the video stream might be unacceptable for processing by the video decoder. Therefore, if a source of video content is in motion and handovers between radio coverage areas are necessary, then it is important that the handovers are handled in a manner to minimize loss, interruption and delay of the video stream.
5.4.1.2 Requirements
[R-5.4.1.2-001] The MCVideo Service shall support one-to-one video communications between authorized MCVideo UEs when the transmitting and/or receiving MCVideo UEs are moving at different speeds, from 0 km/h to 160km/h.
[R-5.4.1.2-002] The MCVideo Service shall support group video communications between authorized MCVideo UEs when the transmitting and/or receiving MCVideo UEs are moving at different speeds, from 0 km/h to 160km/h.
NOTE: It is assumed that communications in high speed trains might be possible with special design.
5.4.2 Latencies
[R-5.4.2-001] The MCVideo Service shall ensure that transmission of urgent real time video transmissions shall be started within 2 seconds after the request.
[R-5.4.2-002] The MCVideo Service shall ensure that the end-to-end delay from transmitting MCVideo UE to receiving MCVideo UE or console for urgent real time video transmissions shall be no more than 1 s.
[R-5.4.2-003] A sending MCVideo UE may be configured to begin storing video immediately from the time the user requests an MCVideo transmission. In this case the end to end delay shall not exceed 1 s plus the commencement delay (up to 2 s).
[R-5.4.2-004] The MCVideo Service shall ensure that the end-to-end delay from transmitted MCVideo UE to receiving MCVideo UE or console for non-urgent real time priority video transmissions shall be no more than 10 s.
[R-5.4.2-005] Synchronisation between video and audio when played at the MCVideo receiving UE or console shall be within 50 ms.