5 MCX Service requirements common for on the network and off the network

22.2803GPPMission Critical Services Common Requirements (MCCoRe)Release 19Stage 1TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 General Group Communications requirements

5.1.1 General aspects

[R-5.1.1-001] The MCX Service shall allow an MCX User utilizing one or more MCX UE(s), concurrently, to sign-in and receive service on each of the MCX UE(s).

[R-5.1.1-002] The MCX Service shall provide a mechanism by which an MCX UE makes a MCX Service group transmission to any MCX Service Group(s) for which the current MCX User is authorized.

NOTE: For off-network use, only group members with MCX UEs within communication range receive the transmission.

[R-5.1.1-003] The MCX Service shall be able to notify the Affiliated MCX Service Group Members when the group communication is set up (e.g., this can be provided as an audible tone on the MCX UE).

[R-5.1.1-004] The MCX Service shall provide a mechanism to disable notifications (e.g., audible tone) on an MCX UE when receiving normal MCX Service Group Communications (not MCX Service Emergency or Imminent Peril Communications).

[R-5.1.1-005] At any moment in time in an MCX Service Group communication, only one Participant type shall be used per Participant.

[R-5.1.1-006] The MCX Service shall provide a mechanism for a dispatcher or authorized user to configure which content source shall be able to transmit the content to an MCX Service Group (e.g. video cameras near an incident).

5.1.2 Group/status information

[R-5.1.2-001] The MCX Service shall provide a mechanism by which an MCX Service UE determines in which of the MCX Service Groups for which it is authorized there is an on-going MCX Service Group Communication.

[R-5.1.2-002] The MCX Service shall provide a mechanism by which an authorized MCX User determines in which MCX Service Groups there is an on-going MCX Service Group Communication.

5.1.3 Group configuration

[R-5.1.3-001] The MCX Service shall allow the MCX Service Administrator to restrict who can be a member of specific MCX Service Groups, so that those MCX Service Groups shall be inaccessible to other users, including dispatchers or supervisors.

[R-5.1.3-002] The MCX Service shall enable a properly provisioned and authorized MCX UE operating on the network to receive its application layer level parameters (e.g., MCX Service Group ID, group keys) necessary for initiating and participating in Selected MCX Service Group and Private Communications at a future time, while off the network.

NOTE: This is a "run-time" requirement applicable to an already configured MCX UE, when MCX Service Groups and/or MCX Users, in addition to what was already configured, need to participate in future off-network communications.

5.1.4 Identification

[R-5.1.4-001] The MCX Service shall support identifiers using character sets for international languages specified via configuration.

5.1.5 Membership/affiliation

[R-5.1.5-001] The MCX Service shall provide a mechanism by which an MCX User determines the currently defined MCX Service Groups for which the MCX User is authorized.

[R-5.1.5-002] The MCX Service shall provide a mechanism by which an MCX UE determines the currently defined MCX Service Groups for which it is authorized.

[R-5.1.5-003] The MCX Service shall support an MCX User’s ability to affiliate to one or more MCX Service Groups.

[R-5.1.5-004] The MCX Service shall provide a mechanism for an MCX Service Administrator to limit the total number (Nc2) of MCX Service Groups that an MCX User can be affiliated to simultaneously.

[R-5.1.5-005] An MCX User may simultaneously be an MCX Service Group Member of one or more MCX Service Groups.

[R-5.1.5-006] The MCX Service shall provide a mechanism for an MCX Service Group Member to select zero or one Selected MCX Service Group.

[R-5.1.5-007] The MCX Service shall require that MCX Users affiliate with MCX Service Groups prior to participation in the communications of those groups.

[R-5.1.5-008] An MCX User shall be able to affiliate with a multiplicity of MCX Service Groups, subject to restrictions configured by the MCX Service Administrator.

5.1.6 Group Communication administration

[R-5.1.6-001] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure the maximum duration for MCX Service Group Communications for MCX Users within their authority.

5.1.7 Prioritization

[R-5.1.7-001] The MCX Service shall provide a mechanism to organize MCX Service Groups into a hierarchy(ies).

[R-5.1.7-002] The MCX Service shall provide a mechanism to prioritize MCX Service Group Communications based on the priorities associated with elements of the communication (e.g., service type, requesting identity, and target identity).

5.1.8 Charging requirements for MCX Service

[R-5.1.8-001] The MCX Service shall support charging for MCX Service Group Communications.

[R-5.1.8-002] Void

[R-5.1.8-003] The MCX Service shall support time-of-day sensitive charging based on actual resource utilization, provided QoS and provided priority.

[R-5.1.8-004] The MCX Service shall generate charging data that identifies the device(s) involved in a communication.

[R-5.1.8-005] The MCX Service shall support confidentiality of the charging between the service provider and the network operator.

[R-5.1.8-006] The MCX Service shall support confidentiality of the identity of the Mission Critical Organization.

[R-5.1.8-007] The MCX Service shall support reconciliation of the charging records between the service provider and the network operator.

[R-5.1.8-008] The MCX Service shall support offline charging.

[R-5.1.8-009] The MCX Service shall support online charging.

[R-5.1.8-010] The MCX Service shall be able to generate charging data for on-network mode.

[R-5.1.8-011] The MCX Service shall be able to generate charging data for off-network mode.

5.1.9 MCX Service Emergency Alert triggered by Location

[R-5.1.9-001] The MCX Service shall provide a mechanism for an MCX Service Emergency Alert to be triggered when an MCX UE moves into a predefined area.

[R-5.1.9-002] The MCX Service shall provide a mechanism for an MCX Service Emergency Alert to be cancelled when the MCX UE moves out of a predefined area or to remain active until cancelled by the MCX User.

5.2 Broadcast Group

5.2.1 General Broadcast Group Communication

[R-5.2.1-001] The MCX Service shall support Broadcast Group Communications within that MCX Service from authorized MCX Service Group Members as determined by the MCX Service Administrator.

[R-5.2.1-002] The MCX Service shall only allow the initiating MCX Service Group Member to transmit on a Broadcast Group Communication, unless overridden (e.g., by a supervisor).

5.2.2 Group-Broadcast Group (e.g., announcement group)

[R-5.2.2-001] The MCX Service shall provide for the creation of Group-Broadcast Groups within that MCX Service with up to Bc1 levels of group hierarchy.

[R-5.2.2-002] The MCX Service shall be configurable to create a Group-Broadcast Group from one or more Group-Broadcast Groups within that MCX Service with any other non-Broadcast Group from the same MCX Service.

[R-5.2.2-003] The MCX Service shall enable an MCX Service Administrator to create a Group-Broadcast Group.

[R-5.2.2-004] A Broadcast Group Communication transmitted on a Group-Broadcast Group shall have priority over Group Communications on its subordinate groups from the same MCX Service.

5.2.3 User-Broadcast Group (e.g., System Communication)

[R-5.2.3-001] The MCX Service shall provide for the creation of User-Broadcast Groups within that MCX Service with up to Bc2 levels of user hierarchy.

[R-5.2.3-002] A Broadcast Group Communication transmitted on a User-Broadcast Group shall have priority over Group Communications from the same MCX Service involving users within the user hierarchy.

5.3 Late communication entry

[R-5.3-001] The MCX Service shall provide a mechanism by which an Affiliated MCX Service Group Member can join an on-going MCX Service Group Communication.

[R-5.3-002] The MCX Service shall provide the identities of the transmitting MCX Service Group Member, and of the MCX Service Group and, if available, the aliases of the transmitting MCX Service Group Member and the identity of the Mission Critical Organization to the MCX UEs that enter the communication late.

[R-5.3-003] The MCX Service shall provide the transmitting MCX Service Group Member’s Location information to MCX UEs that are late entering a communication in progress, subject to permissions.

[R-5.3-004] If an MCX Service Group Communication proceeds without all Affiliated MCX Service Group Members (e.g., due to one or more members being temporarily out of coverage during the communication setup or in one or more higher priority communications), the MCX Service shall attempt to add those affiliated members as the communication proceeds and they become available.

[R-5.3-005] If during an on-going MCX Service Group Communication, additional MCX Service Group Members affiliate with the MCX Service Group, the MCX Service shall add those members to the Group Communication.

[R-5.3-006] When the late entry user(s) become(s) member of the Group communication, all participants may be notified about the late entry member joining the Group communication.

5.4 Receiving from multiple MCX Service communications

5.4.1 Overview

MCX Users receive communications traffic of their affiliated MCX Service Groups. This multiple receiving, called monitoring by some organizations, provides MCX Users current information about police, fire or critical medical events that are occurring within their jurisdictions. This is useful for dispatchers or those that might not be the primary support for that event at that moment. The information gained by monitoring might be useful for the dispatcher to determine any actions to take or be useful later if the MCX User is deployed to provide additional support for that event. The MCX User might be assigned to support the activities of more than one MCX Service Group on the same shift. This means that the MCX User receives multiple MCX Service Groups.

An MCX User with limited resources (e.g., a handheld UE) might find that using concurrent received MCX Service communications from multiple active MCX Service Groups becomes confusing. During periods of time when the MCX User is receiving communications from multiple MCX Service Groups, which MCX Service Group’s communication is presented to the MCX User is determined by the MCX User’s choice, the priority associated with the sender of the Selected MCX Service Group, other considerations or combinations of these. The MCX UE is aware of all the active groups to which the MCX User has affiliated and which is the selected group (if any). The identities of the other active receiving groups can be made available for display on the MCX UE. When the receive activity from the Selected MCX Service Group stops, the MCX UE might present the communications from another group per the MCX User’s choice or by other means.

If none of the multiple groups to which the MCX User has affiliated or selected is active, the MCX UE would continue to monitor for activity by any of the multiple affiliated or Selected MCX Service Groups. Monitoring for activity of multiple MCX Service Groups is also known as scanning and the list of the multiple groups is also known as a scan list.

5.4.2 Requirements

[R-5.4.2-001] The MCX Service shall allow an MCX UE to be receiving or transmitting in one MCX Service Group while simultaneously receiving additional MCX Service Groups.

[R-5.4.2-002] The MCX Service shall provide a mechanism to configure the number (Nc4) of MCX Service Group Communications to be simultaneously received by an MCX UE, authorized by an MCX Service Administrator and/or authorized user.

[R-5.4.2-003] The MCX Service shall provide a mechanism to configure the number (Nc5) of MCX Service Group Communications to be simultaneously received by an MCX User, authorized by an MCX Service Administrator and/or authorized user.s

[R-5.4.2-004] The MCX Service shall provide a mechanism for an MCX Service Administrator and/or authorized user to prioritize the order in which communications on multiple MCX Service Groups within an MCX Service User Profile are presented by the MCX user’s MCX UE.

[R-5.4.2-004A] The MCX Service shall provide a mechanism for an MCX Service Administrator and/or authorized user to prioritize the order in which multiple MCX Service Private Communications are presented by the MCX user’s MCX UE.

[R-5.4.2-004B] The MCX Service shall provide a mechanism for an MCX Service Administrator and/or authorized user to prioritize the order in which communications on MCX Service Groups within an MCX Service User Profile and MCX Service Private Communications are presented by the MCX user’s MCX UE.

[R-5.4.2-005] The MCX Service shall provide multiple MCX Service User IDs to an MCX UE when multiple MCX Service Groups that have a sender are received by the MCX UE.

[R-5.4.2-006] The MCX Service shall allow an authorized MCX UE to receive on-network MCX Service Group and off-network MCX Service Group Communications simultaneously.

[R-5.4.2-007] The MCX Service shall ensure that if there is an MCX Service Emergency Group Communication on one of the MCX Service Groups that an MCX User is affiliated to, but that user is already in a lower priority MCX Service Group Communication or Private Communication, that the MCX User automatically hears/displays the MCX Service Emergency Group Communication.

[R-5.4.2-007a] Depending on meaningful elements of a functional alias the MCX Service shall be able to restrict or allow MCX Users to be involved in more than one MCX Service Emergency Group Communication at a time.

[R-5.4.2-008] The MCX Service shall support reception and recording of multiple concurrent Private Communications by an authorized user (e.g., dispatch operator).

[R-5.4.2-009] The MCX Service shall provide a mechanism by which an MCX UE can receive and record multiple concurrent Private Communications from MCX users for which the current MCX User is authorized.

5.5 Private Communication

5.5.1 Private Communication general requirements

[R-5.5.1-001] The MCX Service shall provide a mechanism for a dispatcher or authorized user to configure which content source shall be able to send the content to an MCX User (e.g. video cameras near an incident).

5.5.2 Charging requirements for MCX Service

[R-5.5.2-001] The MCX Service shall support charging for Private Communications.

5.6 MCX Service priority requirements

5.6.1 Overview

MCX Service Emergency Group Communications and MCX Service Imminent Peril Group Communications are MCX Service Group Communications that provide the MCX User elevated priority towards obtaining resources of the MCX Service system. The MCX Service Emergency Private Communication similarly provides elevated priority to resources of the MCX Service system. The MCX Service Emergency Alert provides a notification of an MCX Service Emergency situation from an MCX UE, regardless if the MCX User is signed in with the MCX Service or not.

The MCX Service Emergency Alert is initiated from an MCX UE to inform the MCX Service of the MCX User’s immediate need of assistance due to the MCX User’s personal, life-threatening situation. If the MCX User is not properly authenticated, he/she is treated as a temporary MCX User with limited permissions. The MCX User initiates this notification by actuating an MCX User interface on the MCX UE. The notification to the MCX Service includes the MCX User’s ID, potentially an MCX Service Group ID, the user’s Mission Critical Organization name and the most current location available for the user’s MCX UE.

The MCX Service User Profile/group configuration determines which MCX Service Group ID is used, if any. If the MCX Service User Profile indicates that a dedicated (i.e., not used for everyday traffic) MCX Service Emergency Group is to be used, then the MCX Service Emergency communication traffic moves to a different group. MCX Users that support MCX Service Emergency situations monitor the dedicated MCX Service Emergency Group(s) for communications activity. If the MCX Service User Profile indicates that the Selected MCX Service Group is to be used, then its MCX Service Group ID is used, unless no group is selected for transmissions.

After the MCX User has initiated an MCX Service Emergency Alert, MCX Service Emergency Private Communication or MCX Service Emergency Group Communication, the MCX User is considered to be in the MCX Service Emergency State. The user remains in the MCX Service Emergency State until the MCX User cancels the MCX Service Emergency State.

An MCX Service Group Communication started by an MCX User while in the MCX Service Emergency State or previously started but followed by an MCX Service Emergency Alert becomes an MCX Service Emergency Group Communication. The MCX Service Group ID used for the MCX Service Emergency Group Communication is the same MCX Service Group ID included in the MCX Service Emergency Alert. An MCX User or dispatcher might initiate an MCX Service Emergency Group Communication without an MCX Service Emergency Alert. The start of an MCX Service Emergency Group Communication starts an In-progress Emergency condition for the MCX Service Group. Any subsequent MCX Service Group Communications made by any MCX Service Group Member of an MCX Service Group, which has an In-progress Emergency, is treated as an MCX Service Emergency Group Communication. MCX Service Emergency Group Priority is removed when the In-progress Emergency for the group is cancelled.

An MCX Service Private Communication started by an MCX User while in the MCX Service Emergency State becomes an MCX Service Emergency Private Communication.

MCX Service Imminent Peril Group Communications are differentiated from MCX Service Emergency Group Communications based on for whom the assistance is required. The MCX Service Emergency Group Communication is initiated by an MCX User for assistance for the MCX Service Emergency condition involving that user. An MCX Service Imminent Peril Group Communication is initiated by an MCX User for assistance to other MCX Users or persons of the general public observed to be in trouble and may soon need assistance.

There is no MCX Service Imminent Peril Alert and no MCX Service Imminent Peril State for MCX Users. The granting of an MCX Service Imminent Peril Group Communication starts an In-progress Imminent Peril condition for the MCX Service Group. Any subsequent MCX Service Group Communication made by any MCX Service Group Member of an MCX Service Group that has an In-progress Imminent Peril condition is treated as an MCX Service Imminent Peril Group Communication. MCX Service Imminent Peril Group Priority is removed when the In-progress Imminent Peril for the group is cancelled.

5.6.2 Communication types based on priorities

5.6.2.1 MCX Service Emergency and Imminent Peril general requirements

5.6.2.1.1 Overview

Emergency Group Communication and Imminent Peril Group Communication are MCX Service Group Communications that provide the MCX User elevated priority towards obtaining resources of the MCX Service system. The MCX Service Emergency Alert provides a notification of an MCX Service Emergency situation from an MCX UE, regardless if the user is signed in with the MCX Service or not. The MCX Service Emergency Alert is initiated from an MCX UE to inform the MCX Service of the user’s immediate need of assistance due to the user’s personal, life-threatening situation.

When multiple MCX Services are active in an MCX UE, the interaction of these features between the services needs to be considered. When an MCX User initiates an Emergency Group Communication, he/she may only want a subset of the active MCX Services to have emergency priority. Likewise, for Imminent Peril the North American user requirement is that only the active MCX Service receives Imminent Peril priority when the Imminent Peril condition is initiated. For example, if the MCX User is transmitting a video when he/she initiates Imminent Peril, then only the MCVideo service will be granted elevated priority.

5.6.2.1.2 Requirements

[R-5.6.2.1.2-001] When an MCX User initiates an MCX Service Emergency Group Communication, a subset of MCX Service applications (e.g. MCPTT, MCVideo) relevant to the MCX User and configured for the MCX Service Group, shall be used for MCX Service Emergency Group Communications.

[R-5.6.2.1.2-002] The MCX Service shall support an MCX Service Emergency Alert, which on initiation by an MCX User shall put that MCX User into the MCX Service Emergency State and cause that MCX UE to send an MCX Service Emergency Alert containing the following information: Location, MCX Service User ID, the user’s Mission Critical Organization name, the list of notification IDs (e.g. groups, other users), and the list of application service MCX Service Group IDs to be used for MCX Service Emergency Group Communication (i.e., user’s selected group or dedicated MCX Service Emergency Group).

[R-5.6.2.1.2-003] The MCX Service in the UE shall request Imminent Peril priority for the currently active MCX Service Application (e.g. MCPTT, MCVideo) when the MCX User requests an MCX Service Imminent Peril Group Communication.

[R-5.6.2.1.2-004] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure which MCX Service Applications (e.g. MCPTT, MCVideo) are used for MCX Service Emergency Group Communications by an MCX User when that user is in an MCX Service Emergency State.

[R-5.6.2.1.2-005] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure which MCX Service Applications (e.g. MCPTT, MCVideo) can be used for Imminent Peril Group Communication.

5.6.2.2 MCX Service Emergency Group Communication

5.6.2.2.1 MCX Service Emergency Group Communication requirements

[R-5.6.2.2.1-001] The MCX Service shall support MCX Service Emergency Group Communications from an authorized MCX Group Member on the currently Selected MCX Group or on an MCX Group designated for MCX Service Emergency Group Communications.

[R-5.6.2.2.1-002] When an MCX User initiates an MCX Service Emergency Group Communication this may trigger an MCX Service Emergency Alert for that MCX User.

[R-5.6.2.2.1-003] When an MCX User initiates an MCX Service Emergency Group Communication this shall put that MCX User into an MCX Service Emergency State.

[R-5.6.2.2.1-004] The MCX Service shall ensure that MCX Service Emergency Group Communications have the highest priority over all other MCX Service Group transmissions from the same MCX Service, except MCX Service System Communications, MCX Service Emergency Private Communications, and other MCX Service Emergency Group Communications.

[R-5.6.2.2.1-005] The MCX Service shall be capable of changing a group communication in progress to an MCX Service Emergency Group Communication.

[R-5.6.2.2.1-006] MCX Service Emergency Group Communications, including their content and signalling, shall have pre-emptive priority over all other types of MCX Service communications from the same MCX Service, except MCX Service System Communications, MCX Emergency Private Communications, and other MCX Service Emergency Group Communications.

[R-5.6.2.2.1-007] The MCX Service shall provide the MCX Service User ID of the initiator of an MCX Service Emergency Group Communication and an indication that it is an MCX Service Emergency Group Communication to Affiliated MCX Service Group Members.

[R-5.6.2.2.1-008] The MCX Service shall add the MCX Service Emergency priority to the group when an In-progress Emergency on that group is initiated.

[R-5.6.2.2.1-009] The MCX Service shall remove the MCX Service Emergency Priority associated with the group when an In-progress Emergency on that group is cancelled.

Editor’s Note: The interaction of MCX Service Emergency Communication and Imminent Peril Communication is FFS.

[R-5.6.2.2.1-010] The Affiliated MCX Service Group Members shall be notified when their group communication transitions to an In-progress Emergency.

[R-5.6.2.2.1-011] The MCX Service shall maintain knowledge of the Affiliated MCX Service Group Member(s) that initiated the MCX Service Emergency Group Communication(s) until the In-progress Emergency is cancelled.

[R-5.6.2.2.1-012] The MCX Service shall maintain an In-progress Emergency condition for a group from the time the initial MCX Service Emergency Group Communication was requested until the In-progress Emergency condition is cancelled.

[R-5.6.2.2.1-013] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure which MCX Service Group (i.e., user’s selected group or dedicated MCX Service Emergency Group) is used for the MCX Service Emergency Group Communication by an MCX User.

[R-5.6.2.2.1-014] While In-progress Emergency status is maintained for an MCX Service Group Communication, the MCX Service shall provide the MCX Service User ID of the initiator of the In-progress Emergency status and an indication that it is an MCX Service Emergency Group Communication to existing and Late communication entry Affiliated MCX Service Group Members.

5.6.2.2.2 MCX Service Emergency Group Communication cancellation requirements

[R-5.6.2.2.2-001] The MCX Service shall support cancellation of an In-progress Emergency by an authorized MCX User for an MCX Service Group.

[R-5.6.2.2.2-002] The MCX Service shall support cancellation of an In-progress Emergency for an MCX Service Group when criteria established by the MCX Service Administrator are met (e.g., timeout).

[R-5.6.2.2.2-003] The MCX Service shall support cancellation of an In-progress Emergency for an MCX Service Group and MCX Service Emergency State for an MCX User by the MCX Service Emergency Group Communication initiator.

[R-5.6.2.2.2-004] The MCX Service shall notify Affiliated MCX Service Group Members of the cancellation of the In-progress Emergency and the identity of the cancelling MCX User.

[R-5.6.2.2.2-005] The MCX Service shall provide a mechanism for an MCX Service Administrator to authorize an MCX User to cancel in-progress Emergencies.

5.6.2.3 MCX Service Imminent Peril Group Communication

5.6.2.3.1 MCX Service Imminent Peril Group Communication requirements

[R-5.6.2.3.1-001] The MCX Service shall support Imminent Peril group communications from authorized Affiliated MCX Service Group Members.

[R-5.6.2.3.1-002] The MCX Service (e.g. MCPTT, MCVideo) shall ensure that MCX Service Imminent Peril group communications have priority over all other MCX Service Group transmissions from the same MCX Service, except MCX Service System Communications, MCX Service Emergency Group Communications, MCX Service Emergency Private Communications, and other MCX Service Imminent Peril group communications.

[R-5.6.2.3.1-003] The MCX Service shall be capable of changing an MCX Service Group communication in progress to an Imminent Peril group communication.

[R-5.6.2.3.1-004] MCX Service Imminent Peril group communications, including their content and signalling, shall have pre-emptive priority over all other types of MCX Service communications from the same MCX Service, except MCX Service Emergency Group Communications, MCX Service Emergency Private Communications, MCX Service System Communications, and other MCX Service Imminent Peril group communications.

[R-5.6.2.3.1-005] The Affiliated MCX Service Group Members shall be notified when an MCX Service Group communications transitions to In-progress Imminent Peril status.

[R-5.6.2.3.1-006] While Imminent Peril status is maintained for an MCX Service Group communications, the MCX Service shall provide the MCX Service User ID of the initiator of the Imminent Peril status and an indication that it is an Imminent Peril group communication to existing and Late communication entry Affiliated MCX Service Group Members.

[R-5.6.2.3.1-007] The MCX Service shall add the Imminent Peril priority to the group when an In-progress Imminent Peril on that group is initiated.

[R-5.6.2.3.1-008] The MCX Service shall remove the Imminent Peril priority associated with the MCX Service Group when the In-progress Imminent Peril status of that MCX Service Group is cancelled.

Editor’s note: The interaction of MCX Service Emergency Communication and Imminent Peril Communication is FFS.

[R-5.6.2.3.1-009] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure which MCX Service Group (i.e., user’s selected group or dedicated imminent peril group) shall be used for the Imminent Peril communications for an MCX User.

5.6.2.3.2 MCX Service Imminent Peril Group Communication cancellation requirements

[R-5.6.2.3.2-001] The MCX Service shall support cancellation of an In-progress Imminent Peril by an authorized MCX User.

[R-5.6.2.3.2-002] The MCX Service shall provide a mechanism for an MCX Service Administrator to authorize MCX Service Users to cancel an In-progress Imminent Peril.

[R-5.6.2.3.2-003] The MCX Service shall support cancellation of an In-progress Imminent Peril by the Imminent Peril group communication initiator.

[R-5.6.2.3.2-004] The MCX Service shall support cancellation of an In-progress Imminent Peril when criteria created by the MCX Service Administrator are met.

5.6.2.4 MCX Service Emergency Alert

5.6.2.4.1 MCX Service Emergency Alert requirements

[R-5.6.2.4.1-001] The MCX Service shall support an MCX Service Emergency Alert capability, which on initiation by an MCX User shall put that MCX User into the MCX Service Emergency State and cause that MCX UE to send an MCX Service Emergency Alert.

[R-5.6.2.4.1-002] The MCX Service shall provide a means for an authorized user to be able to activate the MCX Service Emergency Alert capability.

[R-5.6.2.4.1-003] The MCX Service Emergency Alert shall contain the following information: Location, MCX Service User ID and MCX Service Group ID (i.e., user’s selected group or dedicated MCX Service Emergency Group, as per group configuration) and the user’s Mission Critical Organization name.

[R-5.6.2.4.1-004] The MCX Service Emergency Alert shall be distributed to affiliated members of the group that was used in the MCX Service Emergency Alert.

[R-5.6.2.4.1-004a] For an MCX Service Emergency Private Communication the MCX Service Emergency Alert shall be distributed to the MCX User that the communication was initiated to.

[R-5.6.2.4.1-004b] The group that was used in the MCX Service Emergency Alert may be an ad hoc group.

[R-5.6.2.4.1-005] The MCX Service shall provide a mechanism for an authorized MCX User to configure an MCX Service Emergency Alert to send a notification to MCX Users within a configurable geographic area of the MCX User entering the MCX Service Emergency State, independent of the MCX Service Group Membership.

[R-5.6.2.4.1-006] The MCX UE shall maintain knowledge of the MCX Service Emergency State, until cancelled.

[R-5.6.2.4.1-007] Until the MCX Service Emergency State is cancelled on the MCX UE, all MCX Service Group communications or Private Communications transmissions by the MCX User shall be an MCX Service Emergency Group Communication or Emergency Private Communication.

[R-5.6.2.4.1-008] The MCX UE shall be configurable as to which group (i.e., user’s selected group or dedicated MCX Service Emergency Group) or MCX User is used for the MCX Service Emergency communications.

[R-5.6.2.4.1-009] The MCX UE shall immediately affiliate to the group configured for MCX Service Emergency Group Communication, if not already affiliated to the group, after activating an MCX Service Emergency Alert.

[R-5.6.2.4.1-010] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure how an MCX User is notified of an incoming MCX Service Emergency Alert (e.g., visual, audio).

[R-5.6.2.4.1-011] The MCX Service shall provide a mechanism for an MCX User to configure, subject to MCX Service Policy, how they are notified of an incoming MCX Service Emergency Alert (e.g., visual, audio).

[R-5.6.2.4.1-012] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure which MCX Service Group (i.e., user’s selected group or dedicated MCX Service Emergency Group) or MCX User (e.g., dispatcher) is used for the MCX Service Emergency Alert by an MCX User.

[R-5.6.2.4.1-013] The MCX Administrator shall be able to configure whether the initiation of a MCX Service Emergency Alert shall also automatically trigger a MCX Service Emergency Group Communication.

5.6.2.4.2 MCX Service Emergency Alert cancellation requirements

[R-5.6.2.4.2-001] The MCX UE shall only provide a means for cancelling the MCX Service Emergency State locally by an authorized user of that MCX UE.

[R-5.6.2.4.2-002] The MCX Service shall support MCX Service Emergency Alert cancellation by authorized MCX Users.

[R-5.6.2.4.2-003] The MCX Service shall distribute MCX Service Emergency Alert cancellation to all affiliated members of the group identified in the cancellation.

[R-5.6.2.4.2-004] When the group identified in the cancellation is an ad hoc group, the ad hoc group shall not persist.

5.7 MCX Service User ID

[R-5.7-001] The MCX Service shall provide a mechanism for the creation and deletion of aliases for an MCX User and its associated MCX Service User Profiles by authorized parties.

[R-5.7-002] The MCX Service shall provide a mechanism for each MCX Service User ID to be associated with an alphanumeric identifier (with a minimum length of Nc3) (i.e., alias) assigned by an MCX Service Administrator.

[R-5.7-003] All UEs shall provide a configurable capability to display the MCX Service User ID, aliases associated with the MCX Service User ID, with the Selected MCX Service Group, and with the Mission Critical Organization name.

5.8 MCX UE management

[R-5.8-001] An MCX UE shall support one or more MCX Service User Profiles.

[R-5.8-002] The MCX Service shall provide a mechanism for an MCX Service Administrator and/or authorized MCX User to perform MCX UE Provisioning.

5.9 MCX Service User Profile

[R-5.9-001] The MCX Service shall ensure that each MCX User has at least one associated MCX Service User Profile that records the MCX User’s: information, including permissions and privileges with respect to the MCX Service.

NOTE: Examples of profile information include: their MCX Service User ID, which MCX Service Groups they are a member of, their Participant type, which authority they belong to, whether they can make/receive Private Communications.

[R-5.9-002] The MCX Service shall provide a means for an MCX Service Administrator to manage the MCX Service User Profile for MCX Users within their authority.

5.9a Functional alias

5.9a.1 Overview

A functional alias is a user selectable alias that is tied to the assignment or task of the user. A MCX User can activate one or multiple functional aliases at the same time. The activation of the functional alias(es) will take place after the user has signed in to the MCX Service using the MCX User ID.

The same functional alias can be assigned for use to multiple users depending on MCX Service Administrator settings. A functional alias can be taken over by an authorized MCX User, depending on MCX Service Administrator settings. These two capabilities are mutually exclusive and can not be configured for the same functional alias.

A functional alias can be used to identify for example the driver(s) of a particular train, identified by train number and the role of the user on that train.

Each functional alias that is active on the MCX Service system is unique for addressing purposes. For example, if there are two drivers of TRAIN29 (e.g. DRIVER1_TRAIN29, DRIVER2_TRAIN29), then each active functional alias should be uniquely addressable.

A functional alias can be structured into meaningful elements (e.g. user.agency@organization.country, role.mission@department.company, function.equipment.ID@city, label1.label2.label3@firstname.familyname). Based on one or more of these elements in the functional alias, specific sets of MCX users can be selected fore.g. regrouping purposes.

5.9a.2 Requirements

[R-5.9a-001] The MCX Service shall provide a mechanism for the MCX User to activate one or more functional alias(es) for use by the MCX Users within that MCX Service system (i.e. the primary MCX Service system of the functional alias).

[R-5.9a-001a] The MCX Service system shall be able to use the functional alias as a unique identifier for MCX Users as Participant of an MCX Service Group, e.g. to display a functional alias as speaker identification or for the use in group member lists.

[R-5.9a-001b] The MCX Service system shall provide a mechanism for an MCX User to assign a functional alias for use on an MCX Service Group.

[R-5.9a-001c] The MCX Service system shall provide a mechanism for an MCX User to assign an activated functional alias for an outgoing MCX Private communication.

[R-5.9a-002] The MCX User shall be reachable by its functional alias(es) from within the MCX Service system where the functional alias was activated.

[R-5.9a-002a] An MCX User shall be reachable by its functional alias from the primary MCX system while migrated to partner MCX Service systems.

[R-5.9a-003] The MCX Service shall provide a mechanism for the MCX User to deactivate a functional alias.

[R-5.9a-004] The MCX Service shall upon request provide the MCX User a list of functional aliases from which the user can select for activation/deactivation.

NOTE: The list may contain functional aliases based on a certain context, like location of the MCX User, operational schedule, etc.

[R-5.9a-005] The MCX Service shall provide a mechanism for an MCX Service Administrator to create, delete, manage functional aliases, and for each functional alias indicate either if it can be simultaneously active for multiple MCX Users up to a per-alias configurable number, or if it is allowed to be taken over by an authorized MCX User, or none of these two options.

[R-5.9a-006] If an MCX User attempts to activate a functional alias that is already active for another MCX User, and is not allowed to be simultaneously active for multiple MCX Users or the number of simultaneous MCX Users is reached to the upper limit, the MCX Service shall inform the MCX User that the functional alias is already in use.

[R-5.9a-007] If an MCX User attempts to activate a functional alias that is already active for at least one other MCX User, and that functional alias is allowed to be simultaneously active for multiple MCX Users and the upper limit of number of simultaneous MCX Users is not reached, the MCX Service shall activate the functional alias for the MCX user and inform all other MCX User(s) with the same functional alias.

[R-5.9a-008] If an authorized MCX User attempts to activate a functional alias that is already used by another MCX User, and that functional alias is allowed to be taken over, and is not indicated for simultaneous activation to multiple MCX Users, the MCX Service shall offer the MCX User to take over the functional alias from the MCX User using the alias.

[R-5.9a-008a] If an authorized MCX User attempts to activate a functional alias that is already active for at least one other MCX User, and the upper limit of number of simultaneous MCX Users is reached, the MCX Service shall reject the MCX User’s request.

[R-5.9a-009] If an authorized MCX User takes over the functional alias that is already active for another MCX User, the MCX Service shall activate the functional alias to the MCX User and inform the previous MCX User that the alias has been deactivated.

[R-5.9a-010] The MCX Service shall allow the MCX User to perform an activation/deactivation of an unlisted functional alias that is defined in the MCX Service system.

[R-5.9a-011] An authorized MCX User shall be able to interrogate the MCX Service system of the alias(es) active for a certain MCX User.

[R-5.9a-012] The MCX Service shall provide a mechanism for an MCX Service Administrator to authorize a MCX User to activate, deactivate, interrogate and take over a functional alias.

[R-5.9a-013] VOID

[R-5.9a-014] The MCX Service shall allow the functional alias to be structured as a combination of organizationally meaningful elements (e.g. user.agency@organization.country, role.mission@department.company, function.equipment.ID@city, label1.label2.label3@firstname.familyname).

[R-5.9a-015] The MCX Service system shall allow an MCX Service Administrator to make use of information (e.g. operational schedules, locations, velocity or direction) from external sources to create or delete a functional alias.

[R-5.9a-016] The MCX Service system shall allow the MCX Service Administrator to assign a communication priority for a functional alias.

[R-5.9a-017] The MCX Service system shall allow the MCX Service Administrator to assign a time limit to a functional alias after which the functional alias will be deactivated.

[R-5.9a-018] The MCX Service shall support automatic activation and de-activation of a functional alias based on the operational criteria (e.g. MCX User ID, login/logoff from the MCX Service system, specific external information supplied by external systems).

[R-5.9a-019] The MCX Service shall provide a mechanism for an MCX Service Administrator to define a functional alias with related geographic areas that can be associated to MCX Users for the purpose of routing Location dependent communications, as part of handling MCX Service Private Communication requests, when the determination of the receiving party is based on the initiating MCX User’s current Location.

[R-5.9a-020] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure for a particular functional alias or a specific element or combination of specific elements in the functional alias, a set of functional aliases under the same authority to which a Private Communication (without Floor control) can be made by an MCX User registered to this particular functional alias.

[R-5.9a-021] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure for a particular functional alias or a specific element or combination of specific elements in the functional alias, a set of functional aliases under the same authority from which Private Communication (without Floor control) is allowed to an MCX User registered to this particular functional alias.

[R-5.9a-022] For private calls to functional aliases the authorizations in clause 5.9a.2 shall replace the authorizations defined in clause 6.7.3.

[R-5.9a-023] The MCX Service system shall support private calls and private emergency calls to a functional alias simultaneously activated by multiple MCX Users.

[R-5.9a-024] The MCX Service system shall enable an MCX Service Administrator to select the mechanism to be used for handling of private calls to functional aliases that are allowed to be simultaneously active for multiple MCX Users.

[R-5.9a-025] The MCX Service system shall be able to provide a mechanism to inform the MCX User about the functional alias activation/deactivation status (e.g. activation/deactivation accepted, activation/deactivation pending, activation/deactivation rejected).

[R-5.9a-026] The MCX Service shall provide the functional alias(es) of the transmitting MCX Service Group Member that enter the communication late in accordance with sub-clause 5.3.

[R-5.9a-027] The MCX Service shall provide a Location information report for every authorized MCX User associated with one functional alias in accordance with sub-clause 6.12.

[R-5.9a-028] The MCX Service shall provide the functional alias(es) associated with the MCX Service User ID, of the transmitting Participant to the receiving MCX Users (UEs) unless the transmitting Participant’s identity is restricted in accordance with sub-clause 6.4.3.

[R-5.9a-029] The MCX Service shall provide, upon request, the list of currently affiliated members of an MCX group which encompasses the MCX Service User ID and the associated functional alias(es) of each member in accordance with sub-clause 6.4.5.

[R-5.9a-030] The MCX Service shall provide a mechanism for the enforcement of uniqueness of a functional alias within a Mission Critical organisation in accordance with sub-clause 6.9.

[R-5.9a-031] The MCX Service shall provide a mechanism for an authorized MCX User to obtain a list of functional aliases currently activated in the system either periodically or as a onetime request.

NOTE: The mechanism may allow for filtering criteria e.g. geographic area.

5.10 Support for multiple devices

[R-5.10-001] The MCX Service shall allow an MCX User to log in to multiple MCX UEs concurrently.

[R-5.10-001a] The MCX Service shall be able to allow the MCX Service Administrator to limit the number of simultaneous logins of MCX Users to multiple MCX UEs on a per-MCX service basis.

[R-5.10-001b] The MCX Service shall be able to allow the MCX Service Administrator to limit the number of simultaneous logins of an MCX User to multiple MCX UEs on a per MCX User basis.

[R-5.10-002] The MCX Service shall ensure that the MCX User logs into each MCX UE separately.

5.11 Location

[R-5.11-001] The MCX Service shall support obtaining and conveying Location information describing the position of the MCX UE.

[R-5.11-002] The MCX Service should support obtaining and conveying high accuracy Location information describing the position of the MCX UE.

[R-5.11-002a] The MCX Service shall be able to provide a mechanism for obtaining high accuracy Location information by integrating position information from multiple external sources (e.g. magnetometers, orientation sensors, GNSS)

[R-5.11-003] The MCX Service shall provide for the flexibility to convey future formats of Location information.

[R-5.11-004] The MCX Service shall provide a means for MCX Service Administrators to manage the privacy of Location information for MCX Users within their authority.

[R-5.11-005] An authorized MCX User shall be able to control the supplying of Location information by the MCX UE for MCX Service communications.

[R-5.11-006] The conveyed Location information shall be the most recently obtained information about the position of the MCX UE at the time of the Location information conveyance.

[R-5.11-007] The MCX Service shall be capable of configuring and re-configuring one or more Location information update triggers (i.e., identified conditions that, when satisfied, cause the MCX UE to report its current Location information).

[R-5.11-008] The MCX Service shall be able to modify Location information update triggers of an MCX User while the MCX User is on the network.

[R-5.11-009] The MCX Service shall provide a means for an MCX UE to send a Location information update whenever a trigger condition is satisfied (e.g., initial registration, distance travelled, elapsed time, cell change, tracking area change, PLMN change, MCX Service communication initiation).

[R-5.11-010] The MCX Service shall provide a means for an MCX UE to send a Location information update whenever the MCX User initiates an MCX Service Emergency Alert.

[R-5.11-011] The MCX Service shall provide a means for an MCX UE to send a Location information update whenever the MCX User initiates an MCX Service Emergency Group Communication.

[R-5.11-012] The MCX Service shall provide a means for an MCX UE to send a Location information update if the MCX User is in an MCX Service Emergency State and a configured amount of time has passed since the previous location information update.

[R-5.11-013] The MCX Service shall provide a means for an MCX UE to send a Location information update whenever a trigger condition is satisfied while the MCX User is in MCX Service Emergency State (e.g., initial registration, distance travelled, elapsed time, cell change, tracking area change, PLMN change, MCX Service communication initiation).

NOTE 1: The Location information update triggers for an MCX User in an MCX Service Emergency State might be different than the Location information update triggers used when the MCX User is not in an MCX Service Emergency State.

[R-5.11-014] The MCX Service shall provide a means for an MCX Service Administrator to define geographical areas to be used for Location information update triggers for MCX Users within their authority.

[R-5.11-015] The MCX Service shall provide a means for an MCX UE in a predefined area to send a Location information update whenever a trigger condition configured in an MCX User’s active MCX Service User Profile is satisfied (e.g., initial registration, distance travelled, elapsed time, cell change, tracking area change, PLMN change, MCX Service communication initiation).

NOTE 2: The Location information update triggers for an MCX User in a predefined area might be different than the Location information update triggers used when the MCX User is not in a predefined area.

5.12 Security

[R-5.12-001] The MCX Service shall provide a means to support the confidentiality and integrity of all user traffic and signalling at the application layer.

[R-5.12-002] The MCX Service shall support MCX User with globally unique identities, independent of the mobile subscriber identity (IMSI) assigned by a 3GPP network operator to UEs.

[R-5.12-003] The MCX Service identities shall be part of the MCX Service application service domain.

[R-5.12-004] The MCX Service identities shall form the basis of the MCX Service application layer security for the MCX Service.

[R-5.12-005] The MCX Service shall provide the MCX User with a mechanism to perform a single authentication for access to all authorized features.

[R-5.12-006] The MCX Service shall provide a means for an authorized MCX UE to access selected MCX Service features prior to MCX User authentication.

[R-5.12-007] The MCX Service shall require authentication of the MCX User before service access to all authorized MCX Service features is granted.

NOTE: The MCX Service features available are based on the authenticated user identity(s).

[R-5.12-008] Subject to regulatory constraints, the MCX Service shall provide a means to support confidentiality, message integrity, and source authentication for some information exchanges (e.g., MCX Service User Profile management, kill commands) that have the potential to disrupt the operation of the target MCX UE.

[R-5.12-009] The MCX Service shall provide a means to support end-to-end security for all media traffic transmitted between MCX UEs.

[R-5.12-010] End-to-end security shall be supported both within and without network coverage and regardless of whether the traffic is transmitted directly or via the network infrastructure.

[R-5.12-011] Subject to regulatory constraints, the MCX Service shall provide a cryptographic key management service(s).

[R-5.12-012] The cryptographic key management service(s) shall support both pre-provisioning and over-the-air provisioning of cryptographic keys.

[R-5.12-013] The cryptographic key management service(s) shall ensure that cryptographic keys are confidentiality protected, integrity protected and authenticated when delivered over-the-air.

[R-5.12-014] The MCX Service shall provide end-to-end confidentiality and integrity protection to the MCX User Profile when transferred to and/or from and while stored on an MCX Server, an MCX UE or both.

5.13 Media quality

[R-5.13-001] The MCX Service shall have the flexibility to be used with different codecs (audio / video).

5.14 Relay requirements

[R-5.14-001] The MCX Service shall be able to use ProSe Relay capabilities defined in TS 22.278 [5] and TS 22.468 [6].

[R-5.14-002] An MCX UE which is unable to gain service from a 3GPP network should attempt to make use of one or more suitable ProSe UE-to-Network Relay(s) in its proximity (see sub-clause 6.18).

[R-5.14-003] In off-network situations ProSe UE-to-UE Relay functionality shall be supported (see sub-clause 7.15) between MCX UEs.

[R-5.14-004] The MCX Service shall provide a means for an MCX UE in a robot to have a ProSe UE-to-Network Relay capability.

5.15 Gateway requirements

[R-5.15-001] The MCX Service system shall be accessible via gateway MCX UEs by MCX Users.

[R-5.15-001a] The MCX Service system shall provide a mechanism to uniquely identify a gateway MCX UE.

[R-5.15-002] Gateway MCX UEs shall ensure that the content of communications between the MCX Service System and an MCX User attached to the gateway MCX UEs is unaltered.

[R-5.15-003] Gateway MCX UEs shall handle the communication traffic attributes, e.g. priority and QoS, of an MCX User attached to a gateway MCX UE independently of other MCX Users concurrently attached to the same gateway MCX UE.

[R-5.15-004] Multiple Gateway MCX UEs shall be able to operate within the same area (e.g., site of an incident or accident, overlapping coverage, adjacent cells, etc.).

[R-5.15-005] MCX Users shall be able to select gateway MCX UEs, in case multiple, accessible gateway MCX UEs are available.

[R-5.15-006] An MCX User shall be able to access multiple gateway MCX UEs simultaneously from a single device while restricting a MCX Service to one gateway (e.g., MCPTT on gateway UE 1, MCData and MCVideo on gateway UE 2).

5.16 Control and management by Mission Critical Organizations

5.16.1 Overview

Clause 5.16 contains general requirements for management of the MCX Service by Mission Critical Organizations sharing the same MCX Service system, and more specific requirements pertaining to management controls and operational visibility, and to management of security services.

5.16.2 General requirements

[R-5.16.2-001] The MCX Service shall be able to support multiple Mission Critical Organizations, each with their own MCX Users and MCX Service Groups, on the same MCX Service system.

[R-5.16.2-002] The MCX Service shall provide a mechanism by which Mission Critical Organizations designate and manage (i.e., add, delete, change authorizations, etc.) MCX Service Administrators with authority to manage users, groups, other MCX Service Administrators, security controls, and other mission affecting parameters (e.g., authorizations and priorities) of the MCX Service.

[R-5.16.2-003] The MCX Service shall protect the operational privacy of Mission Critical Organizations by providing effective separation between the administrative and security management (e.g., key) parameters of those organizations except as authorized by the Mission Critical Organizations involved.

[R-5.16.2-004] The MCX Service shall protect the administrative and security management parameters of Mission Critical Organizations from viewing and manipulation by individuals (including those within and outside of the mission critical organization) not explicitly authorized by the Mission Critical Organization.

[R-5.16.2-005] The MCX Service shall provide a mechanism by which Mission Critical Organizations may share subsets of their administrative and security parameters with other Mission Critical Organizations.

NOTE: The purposes of these requirements protect the operational security of organizations while still allowing for interworking of MCX UE and Users under the control of the Mission Critical Organizations.

5.16.3 Operational visibility for Mission Critical Organizations

[R-5.16.3-001] The MCX Service shall provide a means by which an MCX Service Administrator associated with a Mission Critical Organization has visibility into the operational status of the service (e.g., during a natural disaster).

5.16.4 Sharing of administrative configuration between Mission Critical Organizations

Mission Critical Organizations can deploy their own 3GPP standardized mobile, local, countrywide or national broadband mission critical communications systems. In order to grant visiting MCX Service Users access to a Partner MCX Service System and its services, a mechanism is required, which allows the exchange of administrative configuration between connected MCX Service Systems.

NOTE: Administrative configuration is used for adding MCX Service Users into a Partner MCX Service System’s user and group databases, modifying security controls and other mission affecting parameters, and for enabling or disabling certain services for specific users. Relevant information can be exchanged, for example, prior to the visiting MCX Service Users arriving at a Partner MCX Service System or dynamically during events.

[R-5.16.4-001] An MCX Service shall provide a mechanism to allow an authorised MCX User to request MCX User configuration changes in one or more Partner MCX Service Systems (e.g., priorities, authorizations).

[R-5.16.4-002] An MCX Service shall provide a mechanism to allow an authorised MCX User to evaluate and respond to requests for configuration changes from Partner MCX Service Systems.

[R-5.16.4-003] An MCX Service shall provide a mechanism to allow an authorised MCX User to configure automatic responses to categories of requests for configuration changes from Partner MCX Service Systems (e.g., particular users, or groups).

[R-5.16.4-004] An MCX Service shall provide a mechanism to allow an authorised MCX User to request configuration information (e.g., users, groups, security level) from Partner MCX Service Systems.

[R-5.16.4-005] An MCX Service shall provide a mechanism to allow an authorised MCX User to send configuration information to Partner MCX Service Systems.

[R-5.16.4-006] An MCX Service shall provide a mechanism to allow an authorised MCX User to exchange operationally relevant information for specific MCX Users, e.g., MCX User capability information, with Partner MCX Service Systems.

NOTE: Capability information could include, but not limited to, information such as chemical, biohazard, medical or equipment handling capabilities for a specific MCX User.

[R-5.16.4-007] An MCX Service System shall provide a mechanism to allow secure exchange of administrative and security related information with interconnected MCX Service systems without compromising the integrity and security of either system.

[R-5.16.4-008] An MCX Service System shall provide a mechanism to allow exchange of administrative and security related information with interconnected MCX Service systems without exposing the internal network topology of either system.

5.17 General administrative – groups and users

[R-5.17-001] The MCX Service shall provide a mechanism for an MCX Service Administrator to create and define the membership of MCX Service Groups.

[R-5.17-002] The MCX Service shall provide a mechanism for an MCX Service Administrator to authorize a user to request an MCX Service Group Communication to one or more MCX Service Groups.

[R-5.17-003] The MCX Service shall provide a mechanism for an MCX Service Administrator to determine MCX Users who have the role of a particular Participant type on an MCX Service Group.

[R-5.17-004] The MCX Service shall provide mechanisms for an MCX Service Administrator to assign and amend the identifying information of an MCX Service Group (e.g., name, alias).

[R-5.17-005] The MCX Service shall provide a mechanism for an MCX Service Administrator to assign and amend the identifying information of MCX Service User Profiles (e.g., name, identifier, alias).

[R-5.17-006] The MCX Service shall provide a mechanism to notify MCX Users when they become a member of an MCX Service Group or their membership of an MCX Service Group is removed. This notification shall include any provisions required by the MCX User to use the MCX Service Group if the MCX User has been added to the MCX Service Group or remove provisions if the MCX User has been removed from the MCX Service Group.

[R-5.17-007] The MCX Service shall provide mechanisms for an MCX Service Administrator to create, amend, delete, and suspend MCX Service User Profiles.

[R-5.17-008] The MCX Service shall enable an MCX Service Administrator to configure which MCX Service Group Members are authorized to select to transmit to an MCX Service Group.

5.18 Open interfaces for MCX services

5.18.1 Overview

It is expected that data applications such as database access or event managers are or will be, enhanced thanks to the use of multimedia communications. As a consequence, there is a need for external applications to securely access and use MCX Services.

5.18.2 Requirements

[R-5.18.2-001] The MCX Service shall be securely accessible via an open interface by an external application.

NOTE: Access includes one or more of the following: ability to obtain information on demand or via notification, ability to set parameters, ability to control aspects of the service, and the ability to transmit/receive media to/from the service (e.g. video).

[R-5.18.2-002] The MCX Service shall restrict external access based on MCX Service permissions and authorizations.

[R-5.18.2-003] The open interface for MCX Services shall support control and indication of communication priority.

[R-5.18.2-004] The MCX Service shall be able to authenticate the MCX User connecting to the MCX Service through the open interface.

5.19 Media forwarding

5.19.1 Service description

When receiving any kind of media, a user may need to forward it to another user or to another group, subject to relevant authorization. That is to say to communicate between groups the user has to be a member of both groups. Video, messages, files, and streaming may be forwarded.

5.19.2 Requirements

[R-5.19.2-001] An MCX Service shall provide a mechanism for an authorized MCX User to forward media received within an MCX Group to another MCX User or another MCX Group.

[R-5.19.2-002] An MCX Service shall provide a mechanism for an authorized MCX User to forward media received from an MCX User to another MCX User or to an MCX Group.

[R-5.19.2-003] The MCX Service shall provide a mechanism for a MCX UE (whose current user is authorized) to forward a received real time communication in an MCX Group communication to a Group Broadcast Group.

5.20 Receipt notification

5.20.1 Service description

For an MCX Service such as MCVideo or MCData, a user may want to know when the MCX communication has been delivered and when it has been viewed.

5.20.2 Requirements

[R-5.20.2-001] The MCX Service shall provide a mechanism for the sender of a real time communication to receive a notification that the communication is being received and/or displayed.

5.21 Additional services for MCX Service communications

5.21.1 Remotely initiated MCX Service communication

5.21.1.1 Overview

A Remotely initiated MCX Communication is a feature that allows an authorized user, typically a dispatcher, to cause a remote MCX UE to initiate a communication by itself, without its user explicitly initiating the communication by depressing the MCX switch. The purpose of this feature allows the dispatcher to listen to activities at the Location of the remote MCX UE to find out what is happening around that MCX UE. This feature is also known as "Remote Unit Monitoring" in P25 systems.

5.21.1.2 Requirements

[R-5.21.1.2-001] The MCX Service shall provide a mechanism for an authorized MCX User (e.g. dispatch operator) to remotely initiate an MCX Service Private Communication or MCX Service Group Communication from another user’s MCX UE.

[R-5.21.1.2-002] The MCX Service shall provide a mechanism for an authorized MCX User (e.g. dispatch operator) to request remote activation of an MCX Service Group Communication from another user’s (e.g. officer in the field with wearable camera) MCX UE.

[R-5.21.1.2-003] The MCX Service shall provide a mechanism for an authorized MCX User (e.g. officer in the field with wearable camera) to accept or deny access to an MCX Service Group Communication from their MCX UE.

[R-5.21.1.2-004] The MCX Service shall provide a mechanism for an MCX User to request an authorized MCX User (e.g., a dispatcher) to send an MCX Communication (e.g., video or data) to the MCX UE (downlink pull).

NOTE: A video could be stored on the MCX UE or taken on line by the camera.

5.21.2 Remotely terminated MCX Service communication

5.21.2.1 Requirements

[R-5.21.2.1-001] The MCX Service shall provide a mechanism for an authorized MCX User (e.g. dispatch operator) to remotely terminate an MCX Service Private Communication or MCX Service Group Communication from another user’s MCX UE.