6 MCX Service requirements specific to on-network use

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

6.1 General administrative – groups and users

[R-6.1-001] The MCX Service shall provide a mechanism for an MCX Service Administrator to limit the total number (Nc6) of MCX Service Group Members of an MCX Service Group.

[R-6.1-002] The MCX Service shall provide a mechanism for an MCX Service Administrator to remove MCX Service Groups from the MCX Service system.

[R-6.1-003] The MCX Service shall provide a mechanism for an MCX Service Administrator to disable and re-enable MCX Service Groups.

[R-6.1-004] The MCX Service shall provide a mechanism to log MCX Service Administrators’ activities (e.g., cryptographic key updates, MCX Service User Profile changes, password changes, invalid access attempts).

[R-6.1-005] The MCX Service shall provide a mechanism for an MCX Service Administrator to define geographic areas that can be associated to dispatchers for the purpose of routing Location dependent communications and alerts, as part of handling MCX Service Private Communication requests and MCX Service Group Communications, when the receiving/alerted party is based on the MCX User’s current Location.

6.2 MCX Service communications

6.2.1 Notification and acknowledgement for MCX Service Group Communications

[R-6.2.1-001] The MCX Service shall be capable of allowing an MCX Service Group Communication to proceed without prior acknowledgement by any MCX User of that MCX Service Group.

[R-6.2.1-002] The MCX Service shall provide a notification and acknowledgement function for an MCX User currently affiliated to an MCX Service Group to acknowledge receipt of an MCX Service Group Communication, if configured to do so.

[R-6.2.1-003] The MCX User’s acknowledgement may require direct interaction of the MCX UE with the human user, or may be automatically executed by the MCX UE, in accordance with policy established by an MCX Service Administrator.

[R-6.2.1-004] If the MCX Service has knowledge that some affiliated members of a group cannot be Participants in an MCX Service Group Communication, the MCX Service shall provide an indication to the requester that the communication is proceeding without all affiliated members, and shall provide the list of the missing members based on policy established by the MCX Service Administrator.

[R-6.2.1-005] If MCX User(s) are excluded from an MCX Service communication as there is insufficient capacity to support their participation the MCX Service shall notify the MCX User(s) that they have been excluded from the communication for reasons of lack of capacity.

6.2.2 Queuing

[R-6.2.2-001] The MCX Service shall prioritize the transmit request queue based on the type of communication (e.g., group, private), urgency of the communication (e.g., general group, MCX Service Emergency, Imminent Peril), attributes (e.g., priority level) of the MCX Service Group (if a group communication), and attributes (e.g., priority level) of the requesting MCX User.

[R-6.2.2-002] When prioritizing the transmit queue, the MCX Service may assign higher priority to communications of the MCX Service Groups and MCX Users operating within the boundaries of their jurisdictions, if known.

[R-6.2.2-003] When prioritizing the transmit queue, the MCX Service may assign higher priority to communications of the MCX Service Groups and MCX Users during hours of operation or while on duty, if known.

[R-6.2.2-004] The MCX Service shall allow MCX Users with queued requests for permission to transmit to cancel their requests.

[R-6.2.2-005] If an MCX Service Group Communication request to transmit has been queued, the MCX Service shall provide, upon request, that MCX User’s current position in the queue.

[R-6.2.2-006] If a request for an MCX Service Group Communication is queued, the MCX Service shall provide an indication to the requester when the communication continues.

6.3 General requirements

[R-6.3-001] A PLMN shall support multiple MCX Service systems.

[R-6.3-002] An MCX Service system shall be capable of providing MCX Services to MCX Users in multiple PLMNs.

[R-6.3-003] The MCX Service shall provide a means by which changes performed by an MCX Service Administrator take effect immediately.

[R-6.3-004] The MCX Service shall provide a means by which changes performed by an MCX Service Administrator take effect at a specified date/time.

6.4 General MCX Service Group Communications

6.4.1 General aspects

[R-6.4.1-001] Interruption to an MCX Service Group Communication shall be minimized when participants move from one area to another.

6.4.2 Group status/information

[R-6.4.2-001] The MCX Service shall provide a mechanism by which an authorized MCX User determines which MCX Service Groups have at least one other MCX User affiliated.

[R-6.4.2-002] The MCX Service shall provide a mechanism by which an authorized MCX UE determines what MCX Service Groups have at least one active receiving member.

[R-6.4.2-003] The MCX Service shall provide a mechanism by which an authorized MCX UE determines that a number (Nc1) of receiving members are present for an MCX Service Group.

[R-6.4.2-004] The MCX Service shall provide a mechanism by which an authorized MCX UE determines that a particular receiving member(s) is present for an MCX Service Group.

[R-6.4.2-005] The MCX Service shall provide a notification, for example audio and/or visual, to a user that there are no members on an MCX Service Group being used/monitored by the user and that the user is the only user affiliated to that MCX Service Group.

[R-6.4.2-006] The MCX Service shall provide a mechanism by which an authorized MCX User can determine which MCX Service Group(s) another MCX User has affiliated to.

[R-6.4.2-007] The MCX Service shall provide a mechanism by which an authorized MCX User can determine which MCX Service Group(s) another MCX User has selected.

6.4.3 Identification

[R-6.4.3-001] The MCX Service shall provide the MCX Service User ID, associated MCX Service User ID alias(es), MCX Service Group ID, group aliases and, if available, the identity of the Mission Critical Organization name of the transmitting Participant to the receiving MCX UEs unless the transmitting Participant’s identity is restricted.

[R-6.4.3-002] The MCX Service shall present users with human readable identifiers (with a minimum length of Nc3) for MCX Users (i.e., MCX Service User ID alias(es)) and for the MCX Service Groups (i.e., group alias(es)).

6.4.4 Membership/affiliation

[R-6.4.4-001] The MCX Service shall support automatic affiliation of the MCX UE to a Group-Broadcast Group or User-Broadcast Group within that MCX Service.

[R-6.4.4-002] The MCX Service shall support an MCX User’s ability to revoke their affiliation with an MCX Service Group.

[R-6.4.4-002a] The MCX Service shall enable an MCX User to revoke their affiliation with a specific MCX Service Group on specific MCX UEs.

[R-6.4.4-003] The MCX Service shall be able to prevent the MCX User having registered a specific Functional Alias from revoking their affiliation with a specific MCX Service Group.

[R-6.4.4-004] The MCX Service shall be able to prevent the MCX User to revoke their affiliation with a specific MCX Service Group if the MCX User is the only MCX User in the MCX Service Group registered a specific Functional Alias.

6.4.5 Membership/affiliation list

[R-6.4.5-001] The MCX Service shall provide, upon request, the list of currently affiliated members on an MCX Service Group to an authorized user regardless of the user’s affiliation.

[R-6.4.5-002] The MCX Service shall provide a mechanism for an MCX Service Administrator to authorize an MCX User to request the list of currently affiliated members on an MCX Service Group regardless of the MCX User’s affiliation or group membership.

[R-6.4.5-003] The MCX Service shall provide, upon request, the list of currently affiliated members of an MCX Service Group to an authorized MCX UE.

[R-6.4.5-003a] The MCX Service shall provide a mechanism to enable an authorized MCX User to automatically receive any changes made to the list of currently affiliated members for an MCX Service Group.

[R-6.4.5-004] When a list of affiliated members is provided, the list shall reference each member by MCX Service User ID and/or associated aliases.

[R-6.4.5-005] The MCX Service shall provide, upon request, the current list of members of an MCX Service Group to an authorized user.

[R-6.4.5-006] The MCX Service shall provide, upon request, the current list of members of an MCX Service Group to an authorized MCX UE regardless of the MCX UE’s membership.

[R-6.4.5-007] The MCX Service shall provide a mechanism for an MCX Service Administrator to authorize an MCX User to request the complete list of members of an MCX Service Group, regardless of the MCX User’s membership.

[R-6.4.5-008] When a list of members is provided, the list shall reference each member by MCX Service User ID and/or associated aliases.

6.4.6 Authorized user remotely changes another MCX User’s affiliated and/or Selected MCX Service Group(s)

6.4.6.1 Mandatory change

[R-6.4.6.1-001] The MCX Service shall provide a mechanism that allows an authorized MCX User (e.g., dispatcher) to change an on-network MCX User’s Selected MCX Service Group(s) and then the MCX Service shall send a notification to the on-network MCX User.

[R-6.4.6.1-002] The MCX Service shall provide a mechanism that allows an authorized MCX User (e.g., dispatcher) to make changes to the group(s) that an on-network MCX User is affiliated to and then the MCX Service shall send a notification to the on-network MCX User.

[R-6.4.6.1-003] The MCX Service shall provide a mechanism that allows an authorized MCX User (e.g., dispatcher) to change multiple other on-network MCX Users’ Affiliated MCX Service Group(s) to a specific MCX Service Group, and the MCX Service shall notify this to the on-network MCX Users.

[R-6.4.6.1-004] The MCX Service shall provide a mechanism that allows an authorized MCX User (e.g., dispatcher) to change multiple other on-network MCX Users’ Selected MCX Service Group(s) to a specific MCX Service Group, and the MCX Service shall notify this to the on-network MCX Users.

6.4.6.2 Negotiated change

[R-6.4.6.2-001] The MCX Service shall provide a mechanism that allows an authorized MCX User (e.g., dispatcher) to send a notification that proposes that another on-network MCX User should affiliate to a specific MCX Service Group.

[R-6.4.6.2-002] The MCX Service shall provide a mechanism that allows an authorized MCX User (e.g., dispatcher) to send a notification that proposes that multiple other on-network MCX Users should affiliate to a specific MCX Service Group.

[R-6.4.6.2-003] The MCX Service shall provide a mechanism that allows an authorized MCX User (e.g., dispatcher) to send a notification that proposes that another on-network MCX User should select a specific MCX Service Group.

[R-6.4.6.2-004] The MCX Service shall provide a mechanism that allows an authorized MCX User (e.g., dispatcher) to send a notification that proposes that multiple on-network MCX Users should select a specific MCX Service Group.

[R-6.4.6.2-005] The MCX Service shall provide a mechanism to the on-network MCX User to accept or reject a proposed change in selected or affiliated MCX Service Group(s).

[R-6.4.6.2-006] The MCX Service shall provide a notification to the authorized MCX User (e.g., dispatcher) if the change that they proposed to another on-network MCX User(s) affiliated/Selected MCX Service Group was accepted/rejected by the MCX User(s).

6.4.7 Prioritization

[R-6.4.7-001] The MCX Service shall provide a mechanism to establish, dynamically and in real-time, the relative priorities of different MCX Service Group Communications with respect to transport.

[R-6.4.7-002] The MCX Service shall provide a mechanism to establish, dynamically and in real-time, the relative priorities of different MCX Service Group Communications with respect to presentation.

[R-6.4.7-003] The MCX Service shall provide a mechanism to establish, dynamically and in real-time, the relative priorities of MCX Service Groups Communications and other traffic with respect to transport.

[R-6.4.7-004] The MCX Service shall provide a mechanism to establish, dynamically and in real-time, the relative priorities of MCX Service Groups Communications and other traffic with respect to presentation.

6.4.8 Relay requirements

[R-6.4.8-001] The MCX UE-to-Network Relay service shall provide on-network MCX Service to MCX UEs not currently connected to the serving network.

6.4.9 Administrative

[R-6.4.9-001] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure the conditions under which MCX Service communications shall be terminated (e.g., last Participant leaving, second last Participant leaving, initiator leaving).

NOTE: A Participant can leave an ongoing MCX Service Group communication e.g. because the Participant is de-affiliating from the MCX Service Group.

[R-6.4.9-002] The MCX Service shall provide a mechanism for MCX Service Administrators to configure the maximum allowed time duration for MCX Service Group communications to remain active.

[R-6.4.9-003] The MCX Service shall provide a mechanism for an MCX Service Administrator to determine how many MCX Users shall remain participating for MCX Service Group Communications to remain active.

[R-6.4.9-004] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure MCX Service Groups to be receive-only for specified MCX Service Group Members.

[R-6.4.9-005] The MCX Service shall provide a mechanism for an MCX Service Administrator to set the preferred codecs for an MCX Service Group.

[R-6.4.9-006] The MCX Service shall provide a mechanism for an MCX Service Administrator to confine use of an MCX Service Group to MCX Service Group Members in a particular geographic area.

6.5 Broadcast Group

6.5.1 General Broadcast Group Communication

[R-6.5.1-001] The MCX Service shall deliver an on-Network Broadcast Group Communication within that MCX Service to the members of a Broadcast Group who are on-Network, and who may be all of the MCX Service system users, or a subset thereof.

[R-6.5.1-002] The MCX Service shall support Broadcast Group Communications within that MCX Service to a dynamically defined geographic area.

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

[R-6.5.2-001] The MCX Service shall optionally support termination of all, or a subset of, subordinate group communications within that MCX Service upon initiation of a Broadcast Group Communication transmitted on a Group-Broadcast Group.

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

[R-6.5.3-001] The MCX Service shall optionally support termination of all group communications within that MCX Service that are not MCX Service Emergency Group Communications involving those users within the user hierarchy upon initiation of a Broadcast Group Communication transmitted on a User-Broadcast Group.

6.6 Dynamic group management (i.e., dynamic regrouping)

6.6.1 General dynamic regrouping

[R-6.6.1-001] Group Regroup and User Regroup operations shall be manageable by authorized MCX Users.

[R-6.6.1-002] The temporary group formed by Group Regroup or User Regroup operations shall persist until torn down by an authorized MCX User.

[R-6.6.1-003] The priority of the temporary group formed by a Group Regroup or User Regroup operations shall be established by the creator of the group within bounds established by MCX Service Administrators.

[R-6.6.1-004] The MCX Service shall enable an MCX Service Administrator to grant and to revoke the authorization of an MCX User to be able to perform dynamic regrouping operations.

[R-6.6.1-005] The MCX Service shall enable an MCX Service Administrator to configure whether a temporary group is encrypted.

[R-6.6.1-006] The temporary group formed by Group Regroup or User Regroup operations shall be treated like any other MCX Service Group, except the ability for a temporary group formed by a Group Regroup operation to be included in another Group Regroup operation.

6.6.2 Group regrouping

6.6.2.1 Service description

Group regrouping enables dispatchers or any authorized user to temporarily combine MCX Service Groups. A dispatcher uses group regrouping for different reasons.

Due to an incident in an area it can be necessary to temporarily enable MCX Users from different MCX Service Groups to communicate to each other to coordinate. After the incident the dispatcher cancels the group regrouping and the MCX Users continue with their original configured MCX Service Groups.

During quiet periods control room managers can decide to combine MCX Service Groups and handle their operations and communications with one dispatcher. In the busier period the group regrouping is cancelled and the MCX Service Groups are handled by separate dispatchers.

MCX Service Groups that are being combined in a Group Regroup operation may belong to the same or different MCX servers and may have different security and priority levels, different floor control methods, as well as different operational characteristics (e.g. different call start criteria, different call or session hang timers, different transmit time limits, different override settings, different floor control parameters such as queue depth, queing policy and time-to-live in the queue). However, the newly created temporary MCX Service Group can have only a single security level, priority level, floor control method, and set of operational characteristics. The MCX Service will apply the proper setting of those parameters for the new MCX Service Group.

6.6.2.2 Requirements

[R-6.6.2.2-001] The MCX Service shall provide a means of dynamically combining a multiplicity of groups into a new, temporary group (i.e., to perform a "Group Regroup operation").

[R-6.6.2.2-002] The MCX Service shall notify MCX Users when and how any of their affiliated groups are affected by a Group Regroup operation including notification of modified security, priority, floor control, and other operational characteristics.

[R-6.6.2.2-003] The MCX Service shall provide notification and information to an authorized MCX User if that user is attempting to Group Regroup MCX Service Groups of different security levels, priority levels, and/or floor control methods.

[R-6.6.2.2-004] The MCX Service shall enable an authorized MCX User to set the security level of the Group created from a Group Regroup operation. Where an MCX User does not specify the security level the MCX Service shall default the security level to be set to the lowest security level of the constituent Groups.

[R-6.6.2.2-005] The MCX Service shall notify Affiliated MCX Service Group Members of a constituent MCX Service Group when the security level of the MCX Service Group that they are using lowers as a result of a Group Regroup operation.

[R-6.6.2.2-006] The MCX Service shall enable an authorized MCX User to set the priority level of the group formed from a Group Regroup operation. Where an MCX User does not specify the priority level the MCX Service shall default the priority level to be set to the highest priority level of the constituent Groups.

[R-6.6.2.2-007] Broadcast Groups shall be able to be included in a Group Regroup operation.

[R-6.6.2.2-008] The MCX Service shall enable an authorized MCX User or MCX Service Administrator to configure default settings and rules for the operational characteristics of temporary MCX Service Groups resulting from Group Regroup operations (e.g. call start criteria, hang time).

[R-6.6.2.2-009] The MCX Service shall enable an authorized MCX User to specify the operational characteristics of temporary MCX Service Groups resulting from Group Regroup operations either explicitly, or via pre-defined implicit rules, or via pre-configured default values, or, in case all the constituent Groups have in common the same operational characteristics, to use the common settings.

[R-6.6.2.2-010] The MCX Service shall enable an authorized MCX User to set the floor control method of the Group created from a Group Regroup operation when the Group Regroup includes one or more groups configured for audio cut-in operation. Where an MCX User does not specify the floor control method the MCX Service shall default to using normal floor control for the Group Regroup (i.e. do not use audio cut-in).

[R-6.6.2.2-011] The MCX Service shall prevent an authorized MCX User from including a temporary group in a Group Regroup operation.

[R-6.6.2.2-012] The MCX Service shall prevent an authorized MCX User from including a MCX Group that is already part of an existing Group Regroup in a different Group Regroup operation.

[R-6.6.2.2-013] The MCX Service shall be configurable either to prevent or to allow all authorized MCX Users from including a MCX Group that is in emergency state in a Group Regroup operation.

6.6.3 Temporary Broadcast Groups

[R-6.6.3-001] The MCX Service shall enable an authorized MCX User to create a temporary Group-Broadcast Group from a multiplicity of MCX Service Groups within that MCX Service.

[R-6.6.3-001a] The MCX Service shall enable an authorized MCX User to create a temporary User-Broadcast Group from a multiplicity of MCX Users within that MCX Service.

[R-6.6.3-001b] The MCX Service shall enable an authorized MCX User to create a temporary Broadcast Group from a combination of a multiplicity of MCX Service Groups and a multiplicity of MCX Users within that MCX Service.

[R-6.6.3-002] The MCX Service shall only allow the creator of the temporary Broadcast Group to transmit on it.

6.6.4 User regrouping

6.6.4.1 Service description

6.6.4.1.1 User regrouping controlled by dispatcher or authorized user

There is a need for a mechanism for combining MCX Users into a new MCX Service Group under control by a dispatcher or authorized user to support ad-hoc communication needs.

In the operational MCX Service environment, most tasks are covered by standard procedures and communication structures, and MCX Users can easily access the MCX Service Groups to handle their tasks.

Exceptionally it could happen that there is an urgent need for a dedicated set of individual MCX Users to communicate in an MCX Service Group, but that this is not foreseen in the communication structure. This could be due to extreme conditions or due to a cooperation that is outside normal procedures.

User Regrouping enables dispatchers or authorized users to instantaneously provide a dedicated MCX Service Group to these MCX Users to enable the required communication. Depending on configuration the MCX Users could be automatically affiliated to this MCX Service Group. After the operation this MCX Service Group is removed by the dispatcher or authorized user.

6.6.4.1.2 Automatic user regrouping

There is also a need to for an automatic mechanism that determines a set of individual MCX Users to become members of a MCX Service Group and to automatically become affiliated to that MCX Service Group.

These individual MCX Users are selected automatically by the MCX Service based on certain parameters (e.g. location, geographic area, participant type, direction of movement, speed). If MCX Service Group members do not meet the parameters anymore they will automatically be de-affiliated from the MCX Service Group and removed from the MCX Service Group member list. The remaining MCX Service Group members and the MCX Service Group member(s) removed will be informed accordingly. Conversely, MCX Users that are starting to meet the parameters (e.g due to location changes) will automatically be added and affiliated to the MCX Service Group. The MCX Service Group members and the added MCX Service Group member(s) will be informed accordingly.

6.6.4.2 Requirements

[R-6.6.4.2-001] The MCX Service shall provide a means for combining a multiplicity of MCX Users into a new, temporary group (i.e., to perform a "User Regroup operation").

[R-6.6.4.2-002] The MCX Service shall provide a means for combining a multiplicity of MCX Users into a new, temporary group based on a parameter or a combination of parameters (e.g., particular geographic area, Participant type, initiation of urgent type communication such as MCX Emergency Alert or MCX Emergency Group Communication).

[R-6.6.4.2-002a] The MCX Service shall provide a means for automatically combining a multiplicity of MCX Users into a temporary MCX Service Group based on certain criteria. For example, the criteria may include one or more parameters from the list below:

– A specific element or combination of specific elements in the functional alias of a MCX User

– Location (including speed and heading) of a MCX User

– Location or particular geographic area specified by an MCX Service Administrator

– MCX Service configuration (e.g. MCX User responsible for a certain geographic area or MCX User responsible for a certain MCX Service Group)

[R-6.6.4.2-002b] The MCX Service shall be able to automatically update the memberslist of a temporary MCX Service Group based on certain criteria i.e. to remove MCX Users no more meeting the criteria and add MCX Users starting to meet the criteria. For example, the criteria may include one or more parameters from the list below:

– A specific element or combination of specific elements in the functional alias of a MCX User

– Location (including speed and heading) of a MCX User

– Location or particular geographic area specified by an MCX Service Administrator

– MCX Service configuration (e.g. MCX User responsible for a certain geographic area or MCX User responsible for a certain MCX Service Group)

[R-6.6.4.2-003] The MCX Service shall provide a mechanism to preconfigure the parameters for a particular User Regroup operation, such that an authorized MCX User activates this preconfigured User Regroup and communicates with this temporary group with minimal delay.

NOTE: An example of the use of this functionality is for an MCX User to communicate with particular other MCX Users within a predefined radius of the MCX User’s Location. This functionality is likely to be for urgent type communications such as MCX Service Emergency Group Communications.

[R-6.6.4.2-004] The MCX Service shall notify MCX Users when they are affected by a User Regroup operation.

[R-6.6.4.2-005] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure whether an MCX Service system shall automatically affiliate the MCX Users included in the temporary group created by the User Regroup operation.

6.6.5 Dynamic Group Participation

6.6.5.1 Service description

Dynamic group participation enables control of group affiliation, de-affiliation, and selection on MCX Service Groups based on various combinations of criteria. For highly mobile MCX UEs, such as those used in railway communication, the group affiliation and selection needs to change, for example, when a train crosses a controlling area border.

6.6.5.2 Requirements

[R-6.6.5.2-001] The MCX Service shall enable an MCX User to automatically affiliate to one or more MCX Service Groups based on one, or a combination of, criteria.

[R-6.6.5.2-002] The MCX Service shall be able to automatically affiliate an MCX User to one or more MCX Service Groups based one, or a combination of, criteria.

[R-6.6.5.2-003] The MCX Service shall enable an MCX User to automatically choose the Selected MCX Service Group based on one, or a combination of, criteria.

[R-6.6.5.2-004] The MCX Service shall be able to automatically choose the Selected MCX Service Group of an MCX User based on one, or a combination of, criteria.

[R-6.6.5.2-005] The MCX Service shall enable an MCX User to automatically de-affiliate from one or more currently affiliated groups based on a change to one, or a combination of, criteria.

[R-6.6.5.2-006] The MCX Service shall be able to automatically de-affiliate an MCX User from one or more currently affiliated groups based on a change to one, or a combination of, criteria.

[R-6.6.5.2-007] The MCX Service shall be able to prevent an MCX User de-affiliating from specific currently affiliated groups based on one, or a combination of, criteria.

NOTE: Examples of criteria for the above requirements could include one or more parameters from the list below:

– A specific element or combination of specific elements in the functional alias of a MCX User

– Location (including speed and heading) of a MCX User

– Location or particular geographic area specified by an MCX Service Administrator

– MCX Service configuration (e.g. MCX User responsible for a certain geographic area or MCX User responsible for a certain MCX Service Group)

[R-6.6.5.2-008] The MCX Service shall enable an MCX User to select on specific MCX UEs whether automatic affiliation and/or de-affiliation is allowed.

6.7 Private Communication

6.7.1 Overview

Private Communications can use some form of Floor control or not.

6.7.2 General requirements

[R-6.7.2-001] The MCX Service should provide a mechanism for authorized MCX Users to query whether a particular MCX User is present on the network.

[R-6.7.2-002] The MCX Service should provide a mechanism for an MCX Service Administrator to configure which MCX Users, within their authority, are authorized to place a Private Communication (without Floor control).

[R-6.7.2-003] The MCX Service should provide a mechanism for authorized MCX Users to query whether a particular MCX User is capable of participating in a Private Communication.

[R-6.7.2-004] The MCX Service shall provide a mechanism by which an MCX User can make a Private Communication to the local dispatcher based on the MCX User’s current Location.

[R-6.7.2-005] The MCX Service shall provide a mechanism for the Private Communication to be set up with the MCX UE designated by the receiving MCX User to be used for Private Communications when the receiving MCX User has signed on to the MCX Service with multiple MCX UEs.

6.7.3 Administrative

[R-6.7.3-001] The MCX Service should provide a mechanism for an MCX Service Administrator to configure whether the presence on the network of a particular MCX User is available.

[R-6.7.3-002] The MCX Service should provide a mechanism for an MCX Service Administrator to configure which MCX Users may determine whether a particular MCX User is present on the network.

[R-6.7.3-003] The MCX Service should provide a mechanism for an MCX Service Administrator to configure whether the ability to participate in Private Communications of a particular MCX User is available.

[R-6.7.3-004] The MCX Service should provide a mechanism for an MCX Service Administrator to configure which MCX Users may determine whether a particular MCX User is capable of participating in a Private Communication.

[R-6.7.3-005] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure which MCX Users, within their authority, are authorized to place a Manual Commencement Private Communication (without Floor control).

[R-6.7.3-006] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure which MCX Users, within their authority, are authorized to place an Automatic Commencement Private Communication (without Floor control).

[R-6.7.3-007] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure for a particular authorized MCX User, a set of MCX Users under the same authority to which a Private Communication (without Floor control) can be made by this particular MCX User.

[R-6.7.3-007a] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure for a particular authorized MCX User, a set of MCX Users under the same authority from which Private Communication (without Floor control) is allowed to this particular MCX User.

[R-6.7.3-008] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure the maximum duration for Private Communication for MCX Users within their authority.

NOTE: The maximum duration can be set to infinite.

6.7.4 Prioritization

[R-6.7.4-001] The MCX Service shall provide a mechanism to establish, dynamically and in real-time, the relative priorities of Private Communications and Group Communications with respect to transport.

[R-6.7.4-002] The MCX Service shall provide a mechanism to establish, dynamically and in real-time, the relative priorities of Private Communications and Group Communications with respect to presentation.

[R-6.7.4-003] The MCX Service shall provide a mechanism to establish, dynamically and in real-time, the relative priorities of different Private Communications with respect to transport.

[R-6.7.4-004] The MCX Service shall provide a mechanism to establish, dynamically and in real-time, the relative priorities of different Private Communications with respect to presentation.

[R-6.7.4-005] The MCX Service shall provide a mechanism to establish, dynamically and in real-time, the relative priorities of Private Communications and other traffic with respect to transport.

[R-6.7.4-006] The MCX Service shall provide a mechanism to establish, dynamically and in real-time, the relative priorities of Private Communications and other traffic with respect to presentation.

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

6.7.5 Private Communication (without Floor control) commencement requirements

[R-6.7.5-001] The MCX Service shall provide a means by which an MCX UE initiates a Private Communication (without Floor control) to any MCX User for which the MCX UE’s current MCX User is authorized.

[R-6.7.5-002] The MCX Service shall provide a means by which an MCX User initiates an Automatic Commencement Private Communication (without Floor control) to any MCX User for which the MCX User is authorized.

[R-6.7.5-003] The MCX Service shall provide a means by which the transmitting authorized MCX User is notified the receiving MCX User received the Private Communication (without Floor control) request.

6.7.6 Private Communication (without Floor control) termination

[R-6.7.6-001] The MCX Service shall provide a mechanism for an MCX User to reject a Private Communication (without Floor control).

[R-6.7.6-002] The MCX Service shall provide a means by which an MCX User ends a Private Communication (without Floor control) in which the MCX User is a Participant.

6.8 MCX Service priority requirements

6.8.1 General

[R-6.8.1-001] The MCX Service shall support multiple MCX Service Application priorities, which are mapped to priority levels, based on network operator policy.

[R-6.8.1-002] MCX Service shall support multiple pre-emptive priorities.

[R-6.8.1-003] The MCX Service shall provide a mechanism for MCX Service Administrators to create, a pre-emption hierarchy for MCX Service Group transmissions and their associated users (i.e., to facilitate local management of the service and its resources).

[R-6.8.1-004] The MCX Service shall support MCX Service Groups with the permission to pre-empt other MCX Service communications.

[R-6.8.1-005] In case of resource shortage a communication made to a group with pre-emption permissions shall be given resources to complete this communication by pre-empting lower priority communications.

NOTE: An MCX Service communication that needs the use of pre-emption still needs to satisfy the communication setup requirements.

[R-6.8.1-006] MCX Service shall support queuing and retention by priority.

[R-6.8.1-007] The MCX Service shall provide a mechanism for an MCX Service Administrator to establish the priority hierarchy and characteristics of MCX Service Group transmissions.

[R-6.8.1-008] The MCX Service shall enable an MCX Service Administrator to prioritize MCX Service Groups in relation to other MCX Service Groups (with respect to transport and presentation).

[R-6.8.1-009] The MCX Service shall enable an MCX Service Administrator to set the priority for a subset of a Mission Critical Organization’s MCX Service Groups relative to other subsets of a Mission Critical Organization’s MCX Service Groups subordinate to the MCX Service Administrator’s authority.

[R-6.8.1-010] When determining priority for an MCX Service communication, the MCX Service shall use the MCX User/Participant’s attributes (e.g., first/second responder, supervisor, dispatcher, on/off duty) and the MCX Service Group’s attributes (e.g., type of group, owning organization of the group, MCX Service Emergency, Imminent Peril).

[R-6.8.1-011] When determining priority for an MCX Service transmission, the MCX Service shall use the MCX User/Participant’s attributes (e.g., first/second responder, supervisor, dispatcher, on/off duty) and the MCX Service Group’s attributes (e.g., type of group, owning agency of the group, MCX Service Emergency, Imminent Peril).

[R-6.8.1-012] The MCX Service shall provide a means for the attributes used for determining the priority for MCX Users and Groups to influence the Priority and QoS for all MCX UEs associated with the MCX User.

[R-6.8.1-013] Based on the attributes used for determining the priority for MCX Users and Groups, the MCX Service shall provide consistent and deterministic priority for all MCX Users within their Primary MCX Service System.

[R-6.8.1-014] Based on the attributes used for determining the priority for MCX Users and Groups, subject to roaming capabilities and operator agreement, the MCX Service shall provide consistent and deterministic priority for all MCX Users that roam into Partner MCX Service Systems.

[R-6.8.1-015] The MCX Service shall provide a means for an MCX User to monitor the attributes used for determining priority of his/her communications and transmissions.

[R-6.8.1-016] The MCX Service shall provide a means for an authorized MCX User to monitor and affect a change of the attributes used for determining the priority of another MCX User’s communications and transmissions.

6.8.2 3GPP system access controls

[R-6.8.2-001] The 3GPP system shall, subject to operator policy, provide a means for the MCX Service to influence the modification of the access parameters used by the network to admit MCX UEs within a defined area.

NOTE: It is believed that the existing UE network access mechanisms could be utilized to meet the above requirement.

6.8.3 3GPP system admission controls

[R-6.8.3-001] The 3GPP system shall, subject to operator policy, provide a means for the MCX Service to influence the selection and/or modification of admission and retention controls for the bearers assigned or about to be assigned to an MCX UE based on the MCX User’s and MCX Service Group attributes used for the priority determination.

NOTE: It is believed that the existing 3GPP mechanisms for network priority and QoS could be utilized to meet the above requirement.

6.8.4 3GPP system scheduling controls

[R-6.8.4-001] The 3GPP system shall, subject to operator policy, provide a means for the MCX Service to influence the selection and/or modification of the bearer scheduling controls for the bearers assigned or about to be assigned to an MCX UE based on the MCX User’s and MCX Service Group attributes used for the priority determination.

NOTE: It is believed that the existing 3GPP mechanisms for network priority and QoS could be utilized to meet the above requirement.

6.8.5 UE access controls

[R-6.8.5-001] The MCX Service shall allow the MCX UE to temporarily modify selected 3GPP system access parameters, according to configuration established by an MCX Service Administrator in agreement with the operator’s policy.

NOTE: It is believed that the existing network access mechanisms, e.g., ACDC (see 3GPP TS 22.011 [7] and 3GPP TS 23.122 [8]), could be utilized to meet the above requirement.

6.8.6 Mobility and load management

6.8.6.1 Mission Critical mobility management according to priority

[R-6.8.6.1-001] A Mission Critical System shall minimize the interruption to an on-going MCX Service communication when the UE transitions its connection to that communication from one network to another, taking into account that priority management is done in the visited Mission Critical System.

[R-6.8.6.1-002] Mobility shall be subject to authorization from home and visited networks consistent with operational priority management mechanisms. The authorization may be pre-negotiated or in an ad hoc manner.

6.8.6.2 Load management

[R-6.8.6.2-001] MCX Users shall be able to use dedicated 3GPP networks as well as public 3GPP networks. When possible, private 3GPP networks are preferably used. But public 3GPP networks may be used e.g., when no private 3GPP network coverage is available or for lower priority data flows while under an overloaded private 3GPP network coverage.

[R-6.8.6.2-002] MCX Services shall be able to propose, according to operational priorities and available resources, adjustments in quality of service and delay of communications.

[R-6.8.6.2-003] MCX Services shall be able to propose to request to pre-empt other on-going communications (for communications that can be pre-empted).

[R-6.8.6.2-004] MCX Services shall be able to notify users of actions taken by the dispatcher that result in a change in priority for a data flow.

[R-6.8.6.2-005] MCX Services shall be able to notify users when the network is not able to provide the requested quality of service.

6.8.7 Application layer priorities

6.8.7.1 Overview

Dispatchers from different critical communication organizations access the same networks and network resources. Depending on the event, the priority is given to an organization and/or a group rather than to another. For instance, in case of a fire priority is given to the fire brigades dealing with it, while in case of a criminal arrest priority is given to the police officers in charge of the arrest.

6.8.7.2 Requirements

[R-6.8.7.2-001] The MCX Service system shall be able to give application priorities to each communication according to the event in addition to the priority given according to groups.

[R-6.8.7.2-002] The 3GPP system shall inform the MCX Service system if a new MCX Service communication cannot be set up.

[R-6.8.7.2-003] The MCX Service system shall assign to each communication:

– an application layer pre-emption capability;

– a capability to be pre-empted; and

– an application layer priority value.

[R-6.8.7.2-004] If there are no MCX Service communications with the capability to be pre-empted, the MCX Service communications with the lowest application layer priorities may be terminated, even if the MCX Service communications are set as not pre-emptable.

[R-6.8.7.2-005] There shall be at least 8 and preferably 30 configurable levels of priority.

[R-6.8.7.2-006] The MCX Service shall enable the MCX User to request the priority level for each individual communication.

[R-6.8.7.2-007] The MCX Service system shall provide a mechanism that enables the MCX User to request any priority level up to the authorised priority level.

[R-6.8.7.2-008] The MCX Service system shall verify the priority level at communication setup against the maximum authorised priority level.

[R-6.8.7.2-009] The MCX Service system shall assign the defined priority level to a communication if the MCX User has not requested a priority level at setup.

[R-6.8.7.2-010] The MCX Service system shall assign the maximum authorised priority level to a communication if the MCX User has requested at setup a priority level higher than the maximum authorised priority level.

6.8.8 Communication types based on priorities

6.8.8.1 MCX Service Emergency Group Communication requirements

[R-6.8.8.1-001] The MCX Service shall be capable of requesting increased priority for all Participants of an MCX Service Emergency Group Communication.

[R-6.8.8.1-002] The MCX Service may inform affiliated group members that an MCX Service Emergency Group Communication was requested but resources were not available for the communication to be granted.

[R-6.8.8.1-003] The MCX Service shall provide a mechanism for an MCX Service Emergency Group Communication to transmit to a temporary MCX Service Group created by a preconfigured User Regroup operation.

NOTE: This type of MCX Service Emergency Group Communication could be used by MCX Users who need to communicate urgently to specific other MCX Users within a predefined radius of their current Location.

[R-6.8.8.1-004] The MCX Service shall ensure that if there is an MCX Emergency Group Communication on one of the MCX Groups that an MCX User is affiliated to, but that user is already in a Private Communication, that the MCX User is notified of the MCX Emergency Group Communication. In the case of MCPTT the Emergency Group Communication is immediately connected to the receiving user except when the existing Private Communication is with Floor control.

6.8.8.2 MCX Service Emergency Private Communication requirements

[R-6.8.8.2-001] The MCX Service shall ensure that MCX Emergency Private Communication have the highest priority over all other Private Communications.

[R-6.8.8.2-002] The MCX Service shall be capable of requesting increased priority for the Participants of an MCX Emergency Private Communication.

[R-6.8.8.2-003] The MCX Service shall be capable of changing a Private Communication in progress to an MCX Emergency Private Communication.

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

6.8.8.3 Imminent Peril Group Communication requirements

[R-6.8.8.3-001] The MCX Service shall be capable of requesting increased priority for all Participants of an Imminent Peril group communication.

[R-6.8.8.3-002] The MCX Service shall maintain knowledge of the Affiliated MCX Service Group Member(s) that initiated the Imminent Peril group communication.

[R-6.8.8.3-003] The MCX Service shall maintain an In-progress Imminent Peril condition for a group from the time the initial Imminent Peril group communication was requested until the In-progress Imminent Peril condition is cancelled.

Editor’s Note: Whether imminent peril and MCX Service Emergency Group Communications can be generalized is FFS.

6.8.8.4 MCX Service Emergency Alert

6.8.8.4.1 Requirements

[R-6.8.8.4.1-001] The MCX Service may allow MCX UEs that are unauthorized, not registered, or authenticated to activate the MCX Service Emergency Alert capability.

[R-6.8.8.4.1-002] The MCX User shall be notified that the MCX Service Emergency Alert was received by the MCX Service.

[R-6.8.8.4.1-003] The MCX Service shall be configurable on how the user is notified (e.g., visual, audio).

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

[R-6.8.8.4.1-005] The MCX Service shall inform an MCX UE of active MCX Service Emergency Alerts after successful registration/authentication with the MCX Service.

[R-6.8.8.4.1-006] The MCX Service shall provide a mechanism for an MCX Service Emergency Alert to transmit to a temporary MCX Service Group created by a preconfigured User Regroup operation.

NOTE: This type of MCX Service Emergency Alert could be used by MCX Users who need to communicate urgently to specific other MCX Users within a predefined radius of their current Location.

6.8.8.4.2 MCX Service Emergency Alert cancellation requirements

[R-6.8.8.4.2-001] The MCX Service shall allow authorized users to cancel any MCX UE’s MCX Service Emergency Alert from the system.

[R-6.8.8.4.2-002] The MCX Service shall provide a mechanism for an MCX Service Administrator to authorize a user to cancel, from the system, an MCX Service Emergency Alert initiated by another MCX User.

6.8.8.5 Ad hoc Group Communication requirements

[R-8.8.8.5-001] The In-progress Emergency condition for a MCX Service Ad hoc Group Communication shall be cancelled when the communication is terminated.

6.9 IDs and aliases

[R-6.9-001] The MCX Service shall provide a mechanism for permanent and temporary assignment of IDs and aliases.

[R-6.9-002] The MCX Service shall provide a mechanism for the enforcement of uniqueness of IDs and aliases.

[R-6.9-003] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure IDs and aliases.

[R-6.9-004] The MCX Service shall provide the MCX Service User ID and /or associated aliases, the identity of the Selected MCX Service Group, and, if available, the identity of the Mission Critical Organization name of the transmitting MCX User to all MCX UEs that are receiving for display by each MCX UE.

6.10 MCX Service User Profile management

[R-6.10-001] The MCX Service shall be able to dynamically modify one or more pieces of information within the MCX Service User Profile (e.g., the list of MCX Service Groups for which the user has access credentials) while in use by the MCX User.

[R-6.10-002] The MCX Service shall provide a means by which an MCX Service Administrator designates that new or updated MCX Service User Profiles are to be installed at the MCX UE for immediate use by the MCX User.

[R-6.10-003] The MCX Service shall provide a means by which an MCX Service Administrator designates a particular time and date when new or updated MCX Service User Profiles are to be installed at the MCX UE for use by the MCX User.

[R-6.10-004] The MCX Service User Profile shall be construed to be sensitive user information and shall be provided end-to-end confidentiality and integrity protection when transferred between the MCX Service and MCX UE.

6.11 Support for multiple devices

[R-6.11-001] The MCX Service shall provide a notification to the MCX User if the MCX User is already logged on to another MCX UE.

[R-6.11-002] The MCX Service shall provide the mechanisms to allow an MCX User to log off remotely from other MCX UEs.

[R-6.11-003] The MCX Service shall provide the mechanism to allow an authorized MCX User to remotely log off another MCX User from an MCX UE.

6.12 Location

[R-6.12-001] The MCX Service shall provide Location information of the transmitting MCX UE to receiving MCX UEs subject to privacy restrictions.

[R-6.12-002] The MCX Service shall support conveyance of Location information provided by 3GPP location services.

[R-6.12-003] The MCX Service shall provide a means for an authorized MCX User to restrict the dissemination of his Location information.

[R-6.12-004] The MCX Service shall provide end-to-end confidentiality of Location information.

[R-6.12-005] The MCX Service shall provide authentication of messages carrying Location information.

[R-6.12-006] The MCX Service shall provide a means for an authorized MCX User to activate a one-time Location information report of an MCX User and periodic Location information update reports of an MCX User or a specific Functional Alias.

[R-6.12-007] The MCX Service shall provide a means for an authorized MCX User to deactivate periodic Location information update report of an MCX User.

6.13 Security

6.13.1 Overview

Security covers areas designed to protect the confidentiality, integrity, and availability of information that is processed, stored, and transmitted. The security requirements listed here cover the areas of cryptographic protocols, authentication, access control, regulatory issues and storage control.

6.13.2 Cryptographic protocols

[R-6.13.2-001] The MCX Service shall employ open cryptographic standards, subject to applicable local policy (e.g., Federal Information Processing Standards (FIPS) 140-2).

[R-6.13.2-002] The MCX Service shall allow for update to new cryptographic operations and methods without making obsolete existing operations and methods, or requiring upgrade of all user equipment simultaneously.

[R-6.13.2-003] The MCX Service shall allow for the coexistence of a multiplicity of cryptographic suites.

NOTE 1: A "cryptographic suite" is a consistent collection of cryptographic operations (e.g., encryption and message authentication) spanning the totality of required cryptographic operations for MCX Service. That is, if MCX Service requires a stream cipher, a message authentication code, and a secure hash, then counter-mode AES-256, CMAC with AES-256 as an underlying cipher, and SHA-512 would constitute a cryptographic suite for MCX Service.

NOTE 2: The definition and identification of cryptographic suites and algorithms need not all be within the scope of 3GPP.

6.13.3 Authentication

[R-6.13.3-001] The MCX Service shall provide a means by which an MCX UE can require authentication of the MCX Service.

6.13.4 Access control

[R-6.13.4-001] The MCX Service shall support suspending or disabling of access from an MCX UE or an MCX User to the MCX Service.

[R-6.13.4-002] An MCX User who has a profile that has been deleted or suspended shall be prevented from using that MCX Service User Profile to access the MCX Service.

[R-6.13.4-003] The MCX Service shall provide a mechanism to temporarily disable an MCX UE remotely by the MCX Service Administrator or an authorized MCX User.

[R-6.13.4-004] The MCX Service shall only allow a user to affiliate to or select an enabled MCX Service Group (i.e., not disabled).

[R-6.13.4-005] A temporarily disabled MCX UE, which has limited access capability per Mission Critical Organization policy, shall be able to be re-enabled by the MCX Service Administrator or an authorized MCX User.

[R-6.13.4-006] The MCX Service shall provide a mechanism to re-enable a temporarily disabled MCX UE by the MCX Service Administrator or an authorized MCX User.

[R-6.13.4-007] The MCX Service shall provide a mechanism to permanently disable an MCX UE by the MCX Service Administrator or an authorized MCX User.

[R-6.13.4-008] The permanently disabled MCX UE shall remove all MCX Service User Profiles stored in the MCX UE.

[R-6.13.4-009] The permanently disabled MCX UE shall have no access to MCX Services.

[R-6.13.4-010] The security solution for the MCX Service shall minimize the impact of a compromised MCX UE on other MCX UEs.

6.13.5 Regulatory issues

[R-6.13.5-001] The MCX Service shall support lawful interception.

6.13.6 Storage control

[R-6.13.6-001] The MCX Service shall provide all relevant security for media storage (e.g., video or data) on the MCX UE (e.g., data encryption, access only to authorized MCX Group Members).

6.14 Interactions for MCX Service Group Communications and MCX Service Private Communications

[R-6.14-001] The MCX Service shall allow an MCX UE to be receiving and transmitting in one MCX Private Communication (without Floor control) while simultaneously receiving transmissions from other MCX Group communications within the same MCX service.

[R-6.14-002] The MCX Service shall allow an MCX UE to be receiving and transmitting in one MCX Private Communication (without Floor control) while simultaneously receiving transmissions from other MCX Private Communications (with Floor control) within the same MCX service.

6.15 Additional services for MCX Service communications

6.15.1 Discreet listening capabilities

[R-6.15.1-001a] The MCX Service shall provide discreet listening capabilities without noticeable impact on or knowledge of the target MCX User, or the members of the target MCX Service Group including Ad hoc groups, and all other unauthorized MCX Users.

[R-6.15.1-001] The MCX Service shall provide a mechanism for an authorized MCX User to receive MCX Service Private Communication transmissions to and from a specific target MCX User that is within the authority of the authorized MCX User.

[R-6.15.1-002] The MCX Service shall provide a mechanism for an authorized MCX User to receive MCX Service Group Communication transmissions to and from a specific target MCX User that is within the authority of the authorized MCX User.

[R-6.15.1-002a] The MCX Service shall provide a mechanism for an authorized MCX User to receive MCX Service Ad hoc Group Communication transmissions to and from a specific target MCX User that is within the authority of the authorized MCX User.

[R-6.15.1-003] Subject to regulatory constraints and operator security policies, the MCX Service shall allow to be configured not to provide transmissions from MCX Users who are communicating with the discreet listening target MCX User, and who are not themselves targets of discreet listening.

[R-6.15.1-004] The MCX Service shall provide a mechanism for an authorized MCX User to receive MCX Service Group transmissions from a specific MCX Service Group that is within the authority of the authorized MCX User.

NOTE: Permission to activate discreet listening can include multiple levels of authorization, but this is outside the scope of 3GPP.

6.15.2 Ambient listening

6.15.2.1 Overview of ambient listening

Ambient listening is a feature that allows an authorized MCX User, typically a dispatcher, to cause an MCX UE to initiate a communication which results in no indication on the MCX UE that it is transmitting. Ambient listening can be initiated by an authorized MCX User who wants to be "listened" to by another remote authorized MCX User or can be initiated by a remote authorized MCX User who wants to "listen" to another MCX User. The purpose of this feature allows a dispatcher to "listen" to activities at the Location of the remote MCX UE to find out what is happening around that MCX UE without providing an indication to the MCX User or people around the user (whom the MCX User does not want to make aware of this action) that this is happening. This type of communication is different from other types of communications, as for ambient listening information is only transmitted to one party in the communication (i.e., a dispatcher or an authorized MCX User that is acting in a similar role to a dispatcher).

This is used for stolen MCX UEs, monitoring officers, officer safety and particular operations, where it is important that the MCX UE does not indicate what is happening.

6.15.2.2 Ambient listening requirements

6.15.2.2.1 General ambient listening requirements

[R-6.15.2.2.1-001] The MCX UE that is being listened to shall be the only transmitting party in the Private Communication.

[R-6.15.2.2.1-002] For an MCX UE that is being listened to there shall be no indication on the MCX UE that it is transmitting.

[R-6.15.2.2.1-003] If someone attempts to turn off an MCX UE that is being listened to it shall appear to be turned off even while Ambient Listening continues to be active.

6.15.2.2.2 Remotely initiated ambient listening requirements

[R-6.15.2.2.2-001] The MCX Service shall provide a mechanism to allow an MCX Service Administrator and/or an authorized user to set up Ambient Listening on a remote MCX UE within their authority.

[R-6.15.2.2.2-002] The MCX Service shall ensure that Ambient Listening triggered remotely is terminated only by the remote authorized MCX User (e.g., a dispatcher).

6.15.2.2.3 Locally initiated ambient listening requirements

[R-6.15.2.2.3-001] The MCX Service shall provide a mechanism to allow an authorized MCX User to use the MCX UE that the MCX User is currently using to initiate Ambient Listening to another authorized MCX User (e.g., a dispatcher).

[R-6.15.2.2.3-002] The MCX Service shall ensure that Ambient Listening triggered locally can be terminated by the MCX User being listened to or by the remote MCX Service Administrator and/or authorized user, who was the listening Participant.

6.15.3 Remotely initiated MCX Service Communication

6.15.3.1 Overview

A Remotely initiated MCX Service 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 manually. 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.

There are two typical use cases for this feature.

The first one is the case where a user could have been incapacitated. This could be both accidentally, say a traffic accident, or deliberately, for example a violent attack. In both cases it would be necessary to remotely initiate a communication from the MCX UE in order to allow another user or a group of users to "listen" to what is happening to prepare assistance. The communication that is set up is either a Private Communication or a Group Communication, and the communication could optionally be visible to the remote MCX UE’s user.

The second one is the case of a stolen MCX UE. Here it is just necessary to activate the MCX UE so that a dispatcher can "listen" to any background communication in order to make an analysis of the situation. In this situation, the initiation of the communication from the remote MCX UE, typically a Private Communication in that case, is not visible by that MCX UE’s user.

Other use cases, such as undercover operations, discreet surveillance of users or investigations, could exist depending on the missions of the critical communications users and on legislations.

The behaviour of the remotely initiated Communication is not different from a normal communication initiated by the local MCX User. The same rules for resource allocation and interactions with other services apply, but the initiator of the feature can have the capability to request a pre-emptive or high priority for that Communication to ensure it is set up even in case of resource congestion or to limit disturbance by other services.

6.15.3.2 Requirements

[R-6.15.3.2-001] The MCX Service shall provide a mechanism for an MCX Service Administrator and/or authorized MCX User to cause an MCX UE that is within their authority to initiate an MCX Private Communication to the MCX Service Administrator and/or authorized MCX User and then begin transmitting to the MCX Service Administrator or authorized MCX User.

[R-6.15.3.2-002] The MCX Service shall provide a mechanism for an MCX Service Administrator and/or authorized user to provide a notification to the user of the MCX UE when a remote MCX Private Communication is initiated.

[R-6.15.3.2-003] The MCX Service shall provide a mechanism for an MCX Service Administrator and/or authorized user to cause an MCX UE that is within their authority to initiate an MCX Service Group Communication and then to begin transmitting to the Affiliated MCX Service Group Members.

[R-6.15.3.2-004] The MCX Service shall provide a mechanism for an MCX Service Administrator and/or authorized user to provide a notification to the user of the MCX UE when a remote MCX Service Group Communication is initiated.

6.15.4 Recording and audit requirements

[R-6.15.4-001] The MCX Service shall provide a mechanism for a Mission Critical Organization to log the metadata of the MCX Service Group Communications and MCX Service Private Communications under the organization’s authority.

[R-6.15.4-002] Metadata shall be logged for both the transmitting Participant and the receiving Participant(s).

[R-6.15.4-003] The MCX Service shall provide a mechanism for a Mission Critical Organization to record the transmissions of the Group Communications and Private Communications under the organization’s authority.

[R-6.15.4-004] The MCX Service shall provide a mechanism for a Mission Critical Organization to log at least the following metadata per communication: depending on service this may include; start time, date, MCX User ID, functional alias(es), MCX Group ID, Location information of the transmitting Participant, end time or duration, end reason, type of communication (e.g., MCX Service Emergency, regroup, private) and success/failure indication.

[R-6.15.4-005] If an MCX Service Group Communication or MCX Service Private Communication uses end-to-end confidentiality, the MCX Service shall provide a mechanism for a Mission Critical Organization to maintain the end-to-end confidentiality when the MCX Service Group Communication or MCX Service Private Communication is logged.

[R-6.15.4-006] The MCX Service shall provide a mechanism for a Mission Critical Organization to log the metadata of non-communication related user activities under the agency’s authority.

[R-6.15.4-007] The MCX Service shall provide a mechanism for a Mission Critical Organization to log at least the following non-communication activity types: MCX Service Emergency Alert, MCX Service Emergency Alert cancellation, In-progress Emergency cancellation, registration state change, overridden event, user remote logout, changing another user’s affiliations, affiliation change, change of Selected MCX Service Group, (de)activation of functional alias(es) and User and Group Regroup operations.

[R-6.15.4-008] The MCX Service shall provide a mechanism for a Mission Critical Organization to log at least the following metadata per non-communication activity: time, date, MCX Service User identity, activity type and pertinent information about the activity (e.g. MCX User/Group ID(s) included in the temporary group created by the User/Group Regroup operation). The following metadata should be logged if applicable to the activity type: MCX Service Group ID, Location information of the MCX User, affiliation list, target MCX Service User ID and success/failure indication.

[R-6.15.4-009] The MCX Service shall provide a mechanism for a Mission Critical Organization to log metadata for all failed authorization attempts (e.g., invalid login password) by an MCX User.

[R-6.15.4-010] The MCX Service shall provide a mechanism to collect metadata for network access events (e.g., pre-emption of the 3GPP system bearer services, loss of signal, failed registration attempts).

[R-6.15.4-011] The MCX Service shall provide recording and audit functions for all types of MCX Service group communication (e.g., normal group, regroup group, Ad hoc group).

6.15.5 MCX Service Ad hoc Group Communication

6.15.5.1 Overview

Due to an incident in an area, or a special operation, it can be necessary to coordinate MCX Users using Group Communication where these users do not normally work together and do not share any groups in common. MCX Service Ad hoc Group Communication enables authorized users to combine a random set of MCX Users into a group communication. The main characteristics of this ad hoc group communication are:

a) The ad hoc group does not exist until it is spontaneously created during the communication.

b) The ad hoc group ceases to exist when the communication terminates.

c) The ad hoc group does not support ‘persistent state’ communication, e.g. emergency state.

A single communication consists of one or more media transmissions until explicitly terminated by various means. MCX Users that are being combined in an ad hoc group communication may be served by the same or different MCX systems and may normally use MCX Service Groups with different security and priority levels, different floor control methods, and other different operational characteristics. The MCX Service Ad hoc Group Communication will use a common security level, priority level, floor control method, and set of operational characteristics for the participants during a communication. As with any group communication, the priority level can change dynamically.

The ad hoc group is used for a single communication or for an emergency alert and it does not persist when the communication is terminated or when the emergency alert is cancelled. Authorized users can recreate the ad hoc group for subsequent communications, or request creation of a permanent MCX Service Group from the participants in the ad hoc group communication.

NOTE: When the MCX Service Ad hoc Communication is terminated the list of participants may be retained for ease of initiating another ad hoc communication with the same participants.

6.15.5.2 General aspects

[R-6.15.5.2-001] The MCX Service shall provide a mechanism for an authorized MCX User to combine an ad hoc multiplicity of MCX Users into a MCX Service Ad hoc Group Communication.

NOTE: Selection of the list of MCX Users can be manual, or automatic based on certain criteria (e.g., location). This is left for implementation.

[R-6.15.5.2-002] An MCX Service Ad hoc Group Communication is a type of MCX Service Group communication and shall support MCX Service Group Communication mechanisms for call processing (e.g., transmit request queuing, hang time, broadcast mode).

[R-6.15.5.2-003] MCX Service Ad hoc Group Communications shall be terminated using the same mechanisms as MCX Service Group communications (e.g., initiator release, server release, hang time expiration).

[R-6.15.5.2-004] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure additional conditions under which MCX Service Ad hoc Group Communication shall be terminated (e.g., last Participant leaving, second last Participant leaving, initiator leaving).

[R-6.15.5.2-005] When an MCX Service Ad hoc Group Communication is terminated the group shall not persist.

[R-6.15.5.2-005a] When an MCX Service Emergency Alert based on ad hoc group is cancelled, the group shall not persist.

[R-6.15.5.2-006] The MCX Service shall provide a mechanism for the initiator of a MCX Service Ad hoc Group Communication to indicate which MCX Users have to mandatorily acknowledge the setup request before the media transmission proceeds.

[R-6.15.5.2-007] The MCX Service shall provide a mechanism for an authorized initiator of a MCX Service Ad hoc Group Communication to define the communication parameters for the Ad hoc Group Communication (e.g. priority, hang time, broadcast/non-broadcast)

[R-6.15.5.2-008] MCX Service Ad hoc Group Communications shall be able to support the same urgency as MCX Service Group communication (e.g., general group, emergency, imminent peril).

[R-6.15.5.2-009] MCX Service Ad hoc Group Communications shall support the applicable security requirements as identified in sub-clause 5.12.

[R-6.15.5.2-010] The MCX Service shall provide a mechanism for the initiator of an MCX Service Ad hoc Group Communication to request that the list of participants is suppressed.

[R-6.15.5.2-011] The MCX Service shall provide a mechanism for authorized MCX Users to create a permanent MCX Service Group from the members of the MCX Service Ad hoc Group communication.

[R-6.15.5.2-012] The MCX Service shall provide a mechanism for the initiator to add or remove participants during an in progress MCX Service Ad hoc Group communication.

[R-6.15.5.2-013] The MCX Service shall provide a mechanism for a participant to join an in progress MCX Service Ad hoc Group communication.

[R-6.15.5.2-014] The MCX Service shall provide a mechanism for the initiator of an MCX Service Ad hoc Group Communication to request that the list of participants be determined and updated by the MCX Service system using pre-defined criteria.

6.15.5.3 Administrative

[R-6.15.5.3-001] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure which MCX Users, within their authority, are authorized to initiate a MCX Service Ad hoc Group Communication.

[R-6.15.5.3-002] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure the maximum number of MCX Users who can participate in a MCX Service Ad hoc Group Communication.

[R-6.15.5.3-003] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure which MCX Users are authorized to participate in a MCX Service Ad hoc Group Communication. [TS 22.280 R-6.7.2-003]

[R-6.15.5.3-004] The MCX Service shall provide a mechanism for an MCX Service Administrator to define the default parameters for MCX Service Ad hoc Group communication (e.g., priority, hang time, broadcast mode).

[R-6.15.5.3-005] The MCX Service shall provide a mechanism for an MCX Service Administrator to configure whether MCX Service Ad hoc Group Communication is allowed on the MCX system regardless of individual MCX User authorizations.

6.15.5.4 Notification and acknowledgement for MCX Service Ad hoc Group Communications

[R-6.15.5.4-001] The MCX Service shall provide mechanisms for notification and acknowledgement of MCX Service Ad hoc Group Communications as defined in section 6.2.1.

NOTE: For MCX Service Ad hoc Group Communications a participant is considered an affiliated member of the group during communication setup.

6.16 Interaction with telephony services

[R-6.16-001] The MCX Service shall provide a mechanism to allow an MCX Service Administrator to configure whether an MCX User using an MCX UE is able to make and/or receive telephony calls, including public emergency calls.

[R-6.16-002] The MCX Service shall provide a mechanism for an MCX User authorized to use telephony services to block incoming telephony calls.

6.17 Interworking

6.17.1 Non-3GPP access

[R-6.17.1-001] Subject to security and operational constraints and limitations of the underlying access technology, the MCX Service shall provide a mechanism to allow IP-based non-3GPP access to the MCX Service system.

NOTE: An example of non-3GPP access is a dispatcher connecting to the system via a console.

6.17.2 Interworking between MCX Service systems

[R-6.17.2-001] An MCX Service shall provide mechanisms to allow an MCX User to operate in a Partner MCX Service System, subject to authorization from both the Partner and the Primary MCX Service Systems of the MCX User.

[R-6.17.2-002] The authentication of an MCX User with an MCX Service in a Partner MCX Service System shall be based on security parameters obtained from the Primary MCX Service System of the MCX User.

NOTE 1: This is an application layer authentication and not 3GPP network authentication.

[R-6.17.2-003] Any functionality needed from the visited PLMN network is subject to roaming capabilities and operator agreement.

[R-6.17.2-004] An MCX Service shall provide mechanisms to allow an MCX User on the Primary MCX Service System to affiliate and communicate in an MCX Service Group from a Partner MCX Service System, subject to authorization from the Primary MCX Service System and the Partner MCX Service System where the MCX Service Group is defined.

[R-6.17.2-005] An MCX Service shall provide mechanisms to allow a roaming MCX User to affiliate and communicate in an MCX Service Group from the Partner MCX Service System, subject to authorization from the Partner MCX Service System where the MCX Service Group is defined.

[R-6.17.2-006] An MCX Service shall provide mechanisms to allow an MCX User that receives service from a Partner MCX Service System to affiliate and communicate in an MCX Service Group from another Partner MCX Service System, subject to authorization from the Partner MCX Service System where the MCX Service Group is defined.

[R-6.17.2-007] End to end security of an MCX Service Group communication (including in Partner MCX Service Systems) shall be based on parameters obtained from the MCX Service system where the MCX Service Group is defined.

6.17.3 Interworking with non-MCX Service systems

6.17.3.1 GSM-R

[R-6.17.3.1-001] The MCX Service system shall enable bilateral interworking for MCX User positioning information and location information provided for a GSM-R mobile station [9], [10].

[R-6.17.3.1-002] The MCX Service system shall enable interworking with a GSM-R system that is compliant with the UIC GSM-R (EIRENE) standards [9] and EN 301 515 [10].

NOTE: The impact on GSM-R needs to be minimised.

[R-6.17.3.1-003] The MCX Service system shall enable interworking between functional alias and alternative addressing scheme used in GSM-R.

[R-6.17.3.1-004] A GSM-R user shall be reachable using the corresponding functional alias activated by the MCX Service system.

[R-6.17.3.1-005] The MCX Service shall allow an MCX User to be reachable by a functional alias on the MCX Service system or on the GSM-R system.

6.17.3.2 External systems

[R.6.17.3.2-001] The MCX Service system shall support a mechanism for the MCX Service Administrator to also allow the usage of functional alias and/or MCX User Identity as addressing scheme for use by non-MCX services (e.g. Machine Type Communication).

[R.6.17.3.2-002] The MCX Service system shall enable interworking with PLMN and PSTN telephony services.

6.18 MCX Service coverage extension using ProSe UE-to-Network Relays

[R-6.18-001] A ProSe-enabled UE authorized to act as a ProSe UE-to-Network Relay shall, if authorized, support the bi-directional relay of signalling (control plane) and data (user plane) between an MCX UE and the on-network MCX Service.

[R-6.18-002] A ProSe UE-to-Network Relay authorized to act as an MCX Service relay shall advertise, at the ProSe interface, those MCX Services (Groups) which it is currently relaying.

[R-6.18-003] An MCX UE which is unable to gain service from a 3GPP network shall search for ProSe UE-to-Network Relay(s) offering MCX Services for the affiliated MCX Service Groups of the MCX User.

[R-6.18-004] A ProSe UE-to-Network Relay authorized to support MCX Service coverage extension relay between an MCX UE and the on-network MCX Service shall provide a mechanism for an off-network MCX UE to affiliate to one or more MCX Service Groups using the on-network MCX Service.

[R-6.18-005] The ProSe UE-to-Network Relay that has enabled an MCX UE to affiliate to an MCX Service Group using the on-network MCX Service shall subsequently support the bi-directional relay of signalling (control plane) and data (user plane) between the MCX UE and the on-network MCX Service for that MCX Service Group.

[R-6.18-006] A ProSe UE-to-Network Relay authorized to support the bi-directional relay of signalling (control plane) and data (user plane) between an MCX UE and the on-network MCX Service shall provide a mechanism for an off-network MCX UE to initiate and/or receive Private Communications using the on-network MCX Service.

6.19 Additional MCX Service requirements

6.19.1 Communication rejection and queuing

Requests to transmit appear in MCX Services in many forms and under many circumstances.  Normally, requests to transmit are accompanied by priority information that is used to arbitrate the decision to assign resources for the transmission amongst competing requests to transmit.  Upon arrival, a request to transmit is immediately granted, rejected, or queued.  If queued, a request to transmit is normally granted when conditions which caused the queue are removed, or it can be dropped automatically for a number of reasons, or it can be cancelled by an authorized user who is usually the initiator of the request to transmit. When a request to transmit is rejected, it can be re-requested either manually by user action or automatically.

6.19.1.1 Requirements

[R-6.19.1.1-001] The MCX Service shall provide a mechanism to queue any MCX request to transmit.

[R-6.19.1.1-002] The MCX Service shall provide a mechanism to reject MCX request to transmit with a cause indication.

[R-6.19.1.1-003] The MCX Service shall notify the requesting MCX Participant and may notify one or more authorized users when a communication is queued, when a communication is rejected, when communications has started after being de-queued.

[R-6.19.1.1-004] The MCX Service shall provide a mechanism for an MCX User to remove its MCX request to transmit from the MCX request queue.

[R-6.19.1.1-005] The MCX Service shall provide a mechanism for an authorised user to remove another user’s MCX request to transmit from the MCX request queue.

[R-6.19.1.1-005a] The MCX Service shall provide a mechanism for an authorised user to clear the entire MCX request queue.

[R-6.19.1.1-006] An MCX Service User shall be notified when his request to transmit is removed from the MCX request queue.

[R-6.19.1.1-007] The MCX Service shall provide a mechanism for an MCX Administrator to configure service parameter(s) (e.g., timer) for automatic removal of an MCX request to transmit from any MCX request queue.