Content for TS 22.281 Word version: 16.0.0
1 Scope
2 References
3 Definitions and abbreviations
3.1 Definitions
3.2 Abbreviations
4 Overview
4.1 Description of the MCVideo service
4.2 Comparison with the MCPTT service
4.3 Video surveillance
4.4 Group Management/ Communication and Affiliation
4.5 Security
4.6 Confidentiality:
4.7 User identities and inter-working between MCServices
4.8 Non video aspects of the MCVideo service
4.9 Video codecs
...
...
1 Scope Word‑p. 7
The present document provides the service requirements for operation of the MCVideo service. MCVideo makes use of capabilities included in Group Communication System Enablers, Proximity Services, Isolated E UTRAN operation for Public Safety and Mission Critical Services Common Requirements with additional requirements specific to the MCVideo Service. The MCVideo Service can be used for public safety applications and maritime safety applications and also for general commercial applications (e.g. utility companies, railways and maritime usage). The requirements in this specifications do not apply to GSM or UMTS.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
-
References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
-
For a specific reference, subsequent revisions do not apply.
-
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2] Void.
[3]
TS 22.280: "Mission Critical Services Common Requirements (MCCoRe)".
[4]
TS 22.179: "Mission Critical Push To Talk (MCPTT); Stage 1".
[5]
TS 22.282: "Mission Critical Data services".
[6]
ITU-T Recommendation H.264: Advanced video coding for generic audiovisual services, v2, 2016".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
MCVideo Quality:
a measure of the distortion or artefacts in a video signal which impacts the ability of a Mission Critical Organisation to utilise the video for its intended purpose. For example if the purpose of the video is to capture license plates on vehicles in a range of outdoor conditions, video quality is measured in the ability of the video outputs to provide the specific information across a range of environmental conditions.
Real Time:
Of or relating to systems that update information at the same rate as they receive data, enabling them to direct or control a process such as video recording and display. Sometimes referred to as live or real life timing of events.
Real-Time Video:
Video viewed at the same time it is being shot.
Robot:
A machine that can perform a task automatically or via remote control such as an unmanned vehicle that can be aerial (e.g., Unmanned aerial vehicle (UAV), aerial drone), aquatic (e.g., unmanned surface vehicle (USV)), submarine, (e.g., unmanned underwater vehicles (UUV), underwater drone) or terrestrial (unmanned ground vehicle (UGV)).
3.2 Abbreviations Word‑p. 8
For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
IOPS
Isolated E-UTRAN Operation for Public Safety
MCCoRe
Mission Critical Services Common Requirements
MCData
Mission Critical Data
MCPTT
Mission Critical Push to Talk
MCVideo
Mission Critical Video
PTZ
Pan-Tilt-Zoom
TVNP
TV Network Protocol
4 Overview
4.1 Description of the MCVideo service
MCVideo defines a service for Mission Critical video communication using 3GPP transport networks. Mission Critical refers to meeting the needs of agencies providing Public Safety services such as, but not limited to, Police, Fire and Ambulance services. Those needs include high reachability, availability and reliability of the service, low latency, real-time operating capabilities, highly secured operations, inter-operability with other services and systems, private and group communications, handling of emergencies and ability to provide prioritization, pre-emption, queuing and QoS. Although the service is designed for transport over commercial and dedicated 3GPP networks it is not expected to be limited to use over 3GPP networks. However, performance over other transport networks has not been considered when producing this document.
MCVideo service includes:
-
Video capture and encoding of the video information;
-
Secure streaming and storing of the video information;
-
Video decoding and rendering of the video information;
-
Processing of the video information, including the ability to annotate video frames and recognize video features;
-
Mission critical and public safety level functionality (e.g. group sessions, affiliations, end-to-end confidentiality, emergency type communications) and performance (e.g. low latency);
-
Transmission and control of the parameters relevant to those functions;
-
Secure operation such that video information can be reasonably un-impeachable when used in evidentiary procedures;
-
Definition and configuration of MCVideo groups and applications;
-
Configuration of the MCVideo users' profiles and of the MCVideo UEs; and
-
Interoperability with other services and systems.
While the streaming of video is part of the MCVideo Service, the non-real-time or offline transfer of a video clip stored as a file containing video data is covered by the MCData Service as defined in TS 22.282.
An MCVideo video stream can be associated with a stand alone MCVideo group of users, or can be one of the streams of a multi-media MCX Service group.
An MCVideo UE is a device that provides video acquisition (e.g. has a camera), video rendering (has a display) or both and normally also has some encoding / decoding, communication and storage capabilities.
4.2 Comparison with the MCPTT service Word‑p. 9
MCVideo makes use of many of the same capabilities that were originally defined for MCPTT in TS 22.179 and now are mostly specified at stage 1 in the MCCoRe specification [3]. Such capabilities include, but are not limited to, Group Communication, Group Management, Affiliation, Security and Confidentiality. The MCVideo service also allows the same user to have multiple user profiles defined and to simultaneously use multiple UEs.
However, the MCVideo Service also differs from MCPTT in some respects. In MCPTT there is a specific way of floor control to assert good order and appropriate use of priority to control and manage situations where multiple users in a group might attempt to speak at the same time. Simultaneous speech can degrade intelligibility of communications. The role of floor control is to manage who can transmit at a point in time and who will have to wait to speak to the group. In MCVideo the control approach is more varied. There is admission control to manage the appropriate access to network resources according to the user's priority and the UE's capabilities. In some cases, this may include control to restrict simultaneous video being sent from different users in the group (likely to be useful for network capacity/UE limitations). From a user perspective there is not the same need to restrict multiple simultaneous transmission and presentation of video within the same group, as if different streams are available at the UE then the user could choose which, to look at them simultaneously. It is assumed that users that are permitted to transmit video are generally allowed to send video to a group, unless there is a network capacity/UE restriction rule that places limitations on the number of videos to that group. In this case users would be trained in appropriate use of that choice.
The point at which video is transmitted to a group may vary, e.g. a user may press to send video and wait until allowed by the network to stream to the affiliated group according to the admission control policy. However, the user may be able to "force" the immediate transmission of the video information, for example, by pressing and holding the button to send video. In this case the UE will take immediate action to capture the video for onward transmission as soon as permitted. Also the UE will communicate the immediate nature of the video to the network, which may choose to authorise the access and then locally store it for onward transmission or stream it immediately to the relevant group. In this case the video may be slightly delayed due to the start up delay. It is also possible for the user to mark their video communication as Emergency or Imminent Peril and this will immediately elevate the priority of video communications for this group above non emergency video.
A further way that MCVideo differs from MCPTT is that group members may be configured not to automatically receive video. Video may be streamed up to the network and users invited to join when/if convenient/appropriate for them or only if they have access to a multicast enabled device. An example might be where a Police Officer driving to an incident is not able to view a video of the events unfolding, but his partner in the car can usefully receive and view the video. In this case MCVideo working together with MCPTT will provide a powerful solution to know which videos to receive for those best placed to receive them. This user reception function might be used to late join a video stream or with the store and forward capability for video.
4.3 Video surveillance
Surveillance cameras could also use the MCVideo service in which case, in addition to the existing video storage and monitoring activity already used for the surveillance camera, authority may be given to users in the MCVideo system to connect to, control receive and forward video either to an individual or to a group. Surveillance includes the ability to locally and remotely activate video streaming automatically or on demand, to control the positioning, optical and video parameters of the camera and to recognize video features. The camera may be exclusively in the MCVideo system, or it may be accessed by connection from the MCVideo Service via an existing external interface for surveillance camera networks. In this latter case, the external interface is expected to provide requests for control and onward streaming of video, which will be managed together with the normal control network for those cameras. This external interface is outside of the control of 3GPP and existing standards may be used for part or all of the functionality of this interface e.g. TVNP.
4.4 Group Management/ Communication and Affiliation
MCVideo group communication aspects are very similar to MCPTT. Each user may be a member of several, even many, groups. Membership is determined by administration control and provides a user identity based level of authority to join a group. Each user chooses to affiliate to the groups that they want to receive video communication from. Once a user has successfully affiliated to a group they will begin to receive video communications directed to that group according to the video distribution approach used. A user who wishes to send video to a group shall select the relevant group and then they may send video to it.
Groups may interwork with other MCX Service groups, so a single group could be configured for MCPTT and MCVideo and any other combination of MCX Services. The present document does not describe how that is managed, it could be a single group with a single affiliate message and separate attributes for each service or it may be different groups managed together by administrator control and linked in the UE to allow single user action to trigger the same action e.g. affiliate, for each relevant service. It shall be possible for services actions to be taken independently because some UE may not be capable of all of the linked services and some users may not be given access to some services or some groups for some services.
4.5 Security Word‑p. 10
All MCVideo communications, video and supporting signalling and messaging which start and end entirely within MCVideo systems are protected by the security mechanisms used for other MCX Services and defined in MCCoRe. MCVideo communications to and from external end points may be security protected and routed through the normal MCVideo system and then forwarded into the required network for onward delivery to the external end point. Alternatively, such communication could just use the protection and routing provided by the transport network. Given the potential use of stored video information in evidentiary procedures, ensuring the integrity, confidentiality and accuracy of the video information and its associated meta-data is of paramount importance for MCVideo Data.
4.6 Confidentiality:
MCVideo has the same confidentiality requirements as for other MCX Services and are defined in MCCoRe [3].
4.7 User identities and inter-working between MCServices
All users have a unique identity and at least one alias for other MCServices. A single user can have the same or different aliases for any and every MCX Service and group that they are members of, but user identities and aliases for each user resolve to a unique identity even among multiple independent MCX Services in the same domain (e.g. State or Country. In this way, a user who identifies another user using one service will be able to make contact using a different service.
For example, multiple groups and multiple Mission Critical organisations working in the same building might use a map application, which shows them where all the other users are. It should be possible for one user to be able to identify a nearby user from the map and request a video (via the MCVideo Service) of the situation from a certain vantage in order to take appropriate action. The other user may be in a combined group for the mapping application (MCData) but not currently known affiliated in any other group along with the requesting user. User identities requirements are specified in MCCoRe [3].
It is assumed in the present document that, even when there is no configured inter-service interworking action, the User ID for any user detected in any MCService can be used to establish video communication to that user, subject to the user being authorised for the MCVideo Service and the UE being MCVideo capable.
4.8 Non video aspects of the MCVideo service
4.8.1 Relationship with other MCServices
As with MCPTT which has non-speech aspects to the service, in a similar way there are non-video aspects for the MCVideo service. Many of these services are in common with MCPTT such as Emergency Alert signalling, Location messaging etc. but some are also distinct such as video camera control (PTZ - Pan, Tilt, Zoom).
It may also be possible for some MCCoRe aspects to work in the same way between MCVideo and MCData, for example store and forward video.
4.8.2 Camera control Word‑p. 11
Camera control is specified in MCVideo but it is not intended to define a new PTZ protocol. Where protocols exist, these should be assumed for MCVideo e.g. TVNP for PTZ although TVNP is unlikely to be the only relevant standard so there should be provision to use alternative standards according to need.
4.8.3 Location
As with other MCServices, from time to time MCVideo Service providing UE location is required. Ideally the same location messaging for a MCService UE supporting multiple services could be used to update all relevant services at the same time. Location messaging requirements are defined at stage 1 in MCCoRe specification [3].
4.8.4 Emergency Alert
As with other MCServices, the MCVideo Service will use an Emergency Alert to indicate an emergency state and to gain transport network priority. When multiple services are operating together it should be configurable whether the Emergency state of one service affects or not the Emergency state of another service. This situation may be complex to handle between groups using different services. Operational requirements are defined in the Interworking clause of MCCoRe specification [3].
4.9 Video codecs
In general, an MCVideo UE can support several video codecs (or video codec operating modes) of which some could be optional, some could be locally/regionally mandated via regulation, and one is globally mandated via 3GPP implicit (by reference) or explicit (by detailed specification) standardization as the mandatory universal interoperability video codec. If MCVideo UEs participate in a video session, they may need to negotiate or rely on defaults or other rules to establish a common video codec for the video session. Transcoding is not desirable on grounds of complexity and efficiency and in order to enable end-to-end ciphering.
The MCVideo service supports both combined (for efficiency and synchronization) and separate (for cases when the video component cannot or will not be received) handling of video and audio streams.
- References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2] Void.
[3]
TS 22.280: "Mission Critical Services Common Requirements (MCCoRe)".
[4]
TS 22.179: "Mission Critical Push To Talk (MCPTT); Stage 1".
[5]
TS 22.282: "Mission Critical Data services".
[6]
ITU-T Recommendation H.264: Advanced video coding for generic audiovisual services, v2, 2016".
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
MCVideo Quality:
a measure of the distortion or artefacts in a video signal which impacts the ability of a Mission Critical Organisation to utilise the video for its intended purpose. For example if the purpose of the video is to capture license plates on vehicles in a range of outdoor conditions, video quality is measured in the ability of the video outputs to provide the specific information across a range of environmental conditions.
Real Time:
Of or relating to systems that update information at the same rate as they receive data, enabling them to direct or control a process such as video recording and display. Sometimes referred to as live or real life timing of events.
Real-Time Video:
Video viewed at the same time it is being shot.
Robot:
A machine that can perform a task automatically or via remote control such as an unmanned vehicle that can be aerial (e.g., Unmanned aerial vehicle (UAV), aerial drone), aquatic (e.g., unmanned surface vehicle (USV)), submarine, (e.g., unmanned underwater vehicles (UUV), underwater drone) or terrestrial (unmanned ground vehicle (UGV)).
3.2 Abbreviations Word‑p. 8
For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
IOPS
Isolated E-UTRAN Operation for Public Safety
MCCoRe
Mission Critical Services Common Requirements
MCData
Mission Critical Data
MCPTT
Mission Critical Push to Talk
MCVideo
Mission Critical Video
PTZ
Pan-Tilt-Zoom
TVNP
TV Network Protocol
Isolated E-UTRAN Operation for Public Safety
MCCoRe
Mission Critical Services Common Requirements
MCData
Mission Critical Data
MCPTT
Mission Critical Push to Talk
MCVideo
Mission Critical Video
PTZ
Pan-Tilt-Zoom
TVNP
TV Network Protocol
4.1 Description of the MCVideo service
MCVideo defines a service for Mission Critical video communication using 3GPP transport networks. Mission Critical refers to meeting the needs of agencies providing Public Safety services such as, but not limited to, Police, Fire and Ambulance services. Those needs include high reachability, availability and reliability of the service, low latency, real-time operating capabilities, highly secured operations, inter-operability with other services and systems, private and group communications, handling of emergencies and ability to provide prioritization, pre-emption, queuing and QoS. Although the service is designed for transport over commercial and dedicated 3GPP networks it is not expected to be limited to use over 3GPP networks. However, performance over other transport networks has not been considered when producing this document.
MCVideo service includes:
- Video capture and encoding of the video information;
- Secure streaming and storing of the video information;
- Video decoding and rendering of the video information;
- Processing of the video information, including the ability to annotate video frames and recognize video features;
- Mission critical and public safety level functionality (e.g. group sessions, affiliations, end-to-end confidentiality, emergency type communications) and performance (e.g. low latency);
- Transmission and control of the parameters relevant to those functions;
- Secure operation such that video information can be reasonably un-impeachable when used in evidentiary procedures;
- Definition and configuration of MCVideo groups and applications;
- Configuration of the MCVideo users' profiles and of the MCVideo UEs; and
- Interoperability with other services and systems.
4.2 Comparison with the MCPTT service Word‑p. 9
MCVideo makes use of many of the same capabilities that were originally defined for MCPTT in TS 22.179 and now are mostly specified at stage 1 in the MCCoRe specification [3]. Such capabilities include, but are not limited to, Group Communication, Group Management, Affiliation, Security and Confidentiality. The MCVideo service also allows the same user to have multiple user profiles defined and to simultaneously use multiple UEs.
However, the MCVideo Service also differs from MCPTT in some respects. In MCPTT there is a specific way of floor control to assert good order and appropriate use of priority to control and manage situations where multiple users in a group might attempt to speak at the same time. Simultaneous speech can degrade intelligibility of communications. The role of floor control is to manage who can transmit at a point in time and who will have to wait to speak to the group. In MCVideo the control approach is more varied. There is admission control to manage the appropriate access to network resources according to the user's priority and the UE's capabilities. In some cases, this may include control to restrict simultaneous video being sent from different users in the group (likely to be useful for network capacity/UE limitations). From a user perspective there is not the same need to restrict multiple simultaneous transmission and presentation of video within the same group, as if different streams are available at the UE then the user could choose which, to look at them simultaneously. It is assumed that users that are permitted to transmit video are generally allowed to send video to a group, unless there is a network capacity/UE restriction rule that places limitations on the number of videos to that group. In this case users would be trained in appropriate use of that choice.
The point at which video is transmitted to a group may vary, e.g. a user may press to send video and wait until allowed by the network to stream to the affiliated group according to the admission control policy. However, the user may be able to "force" the immediate transmission of the video information, for example, by pressing and holding the button to send video. In this case the UE will take immediate action to capture the video for onward transmission as soon as permitted. Also the UE will communicate the immediate nature of the video to the network, which may choose to authorise the access and then locally store it for onward transmission or stream it immediately to the relevant group. In this case the video may be slightly delayed due to the start up delay. It is also possible for the user to mark their video communication as Emergency or Imminent Peril and this will immediately elevate the priority of video communications for this group above non emergency video.
A further way that MCVideo differs from MCPTT is that group members may be configured not to automatically receive video. Video may be streamed up to the network and users invited to join when/if convenient/appropriate for them or only if they have access to a multicast enabled device. An example might be where a Police Officer driving to an incident is not able to view a video of the events unfolding, but his partner in the car can usefully receive and view the video. In this case MCVideo working together with MCPTT will provide a powerful solution to know which videos to receive for those best placed to receive them. This user reception function might be used to late join a video stream or with the store and forward capability for video.
4.3 Video surveillance
Surveillance cameras could also use the MCVideo service in which case, in addition to the existing video storage and monitoring activity already used for the surveillance camera, authority may be given to users in the MCVideo system to connect to, control receive and forward video either to an individual or to a group. Surveillance includes the ability to locally and remotely activate video streaming automatically or on demand, to control the positioning, optical and video parameters of the camera and to recognize video features. The camera may be exclusively in the MCVideo system, or it may be accessed by connection from the MCVideo Service via an existing external interface for surveillance camera networks. In this latter case, the external interface is expected to provide requests for control and onward streaming of video, which will be managed together with the normal control network for those cameras. This external interface is outside of the control of 3GPP and existing standards may be used for part or all of the functionality of this interface e.g. TVNP.
4.4 Group Management/ Communication and Affiliation
MCVideo group communication aspects are very similar to MCPTT. Each user may be a member of several, even many, groups. Membership is determined by administration control and provides a user identity based level of authority to join a group. Each user chooses to affiliate to the groups that they want to receive video communication from. Once a user has successfully affiliated to a group they will begin to receive video communications directed to that group according to the video distribution approach used. A user who wishes to send video to a group shall select the relevant group and then they may send video to it.
Groups may interwork with other MCX Service groups, so a single group could be configured for MCPTT and MCVideo and any other combination of MCX Services. The present document does not describe how that is managed, it could be a single group with a single affiliate message and separate attributes for each service or it may be different groups managed together by administrator control and linked in the UE to allow single user action to trigger the same action e.g. affiliate, for each relevant service. It shall be possible for services actions to be taken independently because some UE may not be capable of all of the linked services and some users may not be given access to some services or some groups for some services.
4.5 Security Word‑p. 10
All MCVideo communications, video and supporting signalling and messaging which start and end entirely within MCVideo systems are protected by the security mechanisms used for other MCX Services and defined in MCCoRe. MCVideo communications to and from external end points may be security protected and routed through the normal MCVideo system and then forwarded into the required network for onward delivery to the external end point. Alternatively, such communication could just use the protection and routing provided by the transport network. Given the potential use of stored video information in evidentiary procedures, ensuring the integrity, confidentiality and accuracy of the video information and its associated meta-data is of paramount importance for MCVideo Data.
4.6 Confidentiality:
MCVideo has the same confidentiality requirements as for other MCX Services and are defined in MCCoRe [3].
4.7 User identities and inter-working between MCServices
All users have a unique identity and at least one alias for other MCServices. A single user can have the same or different aliases for any and every MCX Service and group that they are members of, but user identities and aliases for each user resolve to a unique identity even among multiple independent MCX Services in the same domain (e.g. State or Country. In this way, a user who identifies another user using one service will be able to make contact using a different service.
For example, multiple groups and multiple Mission Critical organisations working in the same building might use a map application, which shows them where all the other users are. It should be possible for one user to be able to identify a nearby user from the map and request a video (via the MCVideo Service) of the situation from a certain vantage in order to take appropriate action. The other user may be in a combined group for the mapping application (MCData) but not currently known affiliated in any other group along with the requesting user. User identities requirements are specified in MCCoRe [3].
It is assumed in the present document that, even when there is no configured inter-service interworking action, the User ID for any user detected in any MCService can be used to establish video communication to that user, subject to the user being authorised for the MCVideo Service and the UE being MCVideo capable.
4.8 Non video aspects of the MCVideo service
4.8.1 Relationship with other MCServices
As with MCPTT which has non-speech aspects to the service, in a similar way there are non-video aspects for the MCVideo service. Many of these services are in common with MCPTT such as Emergency Alert signalling, Location messaging etc. but some are also distinct such as video camera control (PTZ - Pan, Tilt, Zoom).
It may also be possible for some MCCoRe aspects to work in the same way between MCVideo and MCData, for example store and forward video.
4.8.2 Camera control Word‑p. 11
Camera control is specified in MCVideo but it is not intended to define a new PTZ protocol. Where protocols exist, these should be assumed for MCVideo e.g. TVNP for PTZ although TVNP is unlikely to be the only relevant standard so there should be provision to use alternative standards according to need.
4.8.3 Location
As with other MCServices, from time to time MCVideo Service providing UE location is required. Ideally the same location messaging for a MCService UE supporting multiple services could be used to update all relevant services at the same time. Location messaging requirements are defined at stage 1 in MCCoRe specification [3].
4.8.4 Emergency Alert
As with other MCServices, the MCVideo Service will use an Emergency Alert to indicate an emergency state and to gain transport network priority. When multiple services are operating together it should be configurable whether the Emergency state of one service affects or not the Emergency state of another service. This situation may be complex to handle between groups using different services. Operational requirements are defined in the Interworking clause of MCCoRe specification [3].
4.9 Video codecs
In general, an MCVideo UE can support several video codecs (or video codec operating modes) of which some could be optional, some could be locally/regionally mandated via regulation, and one is globally mandated via 3GPP implicit (by reference) or explicit (by detailed specification) standardization as the mandatory universal interoperability video codec. If MCVideo UEs participate in a video session, they may need to negotiate or rely on defaults or other rules to establish a common video codec for the video session. Transcoding is not desirable on grounds of complexity and efficiency and in order to enable end-to-end ciphering.
The MCVideo service supports both combined (for efficiency and synchronization) and separate (for cases when the video component cannot or will not be received) handling of video and audio streams.
All MCVideo communications, video and supporting signalling and messaging which start and end entirely within MCVideo systems are protected by the security mechanisms used for other MCX Services and defined in MCCoRe. MCVideo communications to and from external end points may be security protected and routed through the normal MCVideo system and then forwarded into the required network for onward delivery to the external end point. Alternatively, such communication could just use the protection and routing provided by the transport network. Given the potential use of stored video information in evidentiary procedures, ensuring the integrity, confidentiality and accuracy of the video information and its associated meta-data is of paramount importance for MCVideo Data.
4.6 Confidentiality:
MCVideo has the same confidentiality requirements as for other MCX Services and are defined in MCCoRe [3].
4.7 User identities and inter-working between MCServices
All users have a unique identity and at least one alias for other MCServices. A single user can have the same or different aliases for any and every MCX Service and group that they are members of, but user identities and aliases for each user resolve to a unique identity even among multiple independent MCX Services in the same domain (e.g. State or Country. In this way, a user who identifies another user using one service will be able to make contact using a different service.
For example, multiple groups and multiple Mission Critical organisations working in the same building might use a map application, which shows them where all the other users are. It should be possible for one user to be able to identify a nearby user from the map and request a video (via the MCVideo Service) of the situation from a certain vantage in order to take appropriate action. The other user may be in a combined group for the mapping application (MCData) but not currently known affiliated in any other group along with the requesting user. User identities requirements are specified in MCCoRe [3].
It is assumed in the present document that, even when there is no configured inter-service interworking action, the User ID for any user detected in any MCService can be used to establish video communication to that user, subject to the user being authorised for the MCVideo Service and the UE being MCVideo capable.
4.8 Non video aspects of the MCVideo service
4.8.1 Relationship with other MCServices
As with MCPTT which has non-speech aspects to the service, in a similar way there are non-video aspects for the MCVideo service. Many of these services are in common with MCPTT such as Emergency Alert signalling, Location messaging etc. but some are also distinct such as video camera control (PTZ - Pan, Tilt, Zoom).
It may also be possible for some MCCoRe aspects to work in the same way between MCVideo and MCData, for example store and forward video.
4.8.2 Camera control Word‑p. 11
Camera control is specified in MCVideo but it is not intended to define a new PTZ protocol. Where protocols exist, these should be assumed for MCVideo e.g. TVNP for PTZ although TVNP is unlikely to be the only relevant standard so there should be provision to use alternative standards according to need.
4.8.3 Location
As with other MCServices, from time to time MCVideo Service providing UE location is required. Ideally the same location messaging for a MCService UE supporting multiple services could be used to update all relevant services at the same time. Location messaging requirements are defined at stage 1 in MCCoRe specification [3].
4.8.4 Emergency Alert
As with other MCServices, the MCVideo Service will use an Emergency Alert to indicate an emergency state and to gain transport network priority. When multiple services are operating together it should be configurable whether the Emergency state of one service affects or not the Emergency state of another service. This situation may be complex to handle between groups using different services. Operational requirements are defined in the Interworking clause of MCCoRe specification [3].
4.9 Video codecs
In general, an MCVideo UE can support several video codecs (or video codec operating modes) of which some could be optional, some could be locally/regionally mandated via regulation, and one is globally mandated via 3GPP implicit (by reference) or explicit (by detailed specification) standardization as the mandatory universal interoperability video codec. If MCVideo UEs participate in a video session, they may need to negotiate or rely on defaults or other rules to establish a common video codec for the video session. Transcoding is not desirable on grounds of complexity and efficiency and in order to enable end-to-end ciphering.
The MCVideo service supports both combined (for efficiency and synchronization) and separate (for cases when the video component cannot or will not be received) handling of video and audio streams.