Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 22.280  Word version:  19.4.0

Top   Top   Up   Prev   Next
1…   5…   5.9…   6…   6.8…   7…   8…   A…

 

6.8  MCX Service priority requirementsp. 41

6.8.1  Generalp. 41

[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.
[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.
Up

6.8.2  3GPP system access controlsp. 42

[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.

6.8.3  3GPP system admission controlsp. 42

[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.

6.8.4  3GPP system scheduling controlsp. 42

[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.

6.8.5  UE access controlsp. 42

[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.

6.8.6  Mobility and load managementp. 42

6.8.6.1  Mission Critical mobility management according to priorityp. 42

[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 managementp. 42

[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.
Up

6.8.7  Application layer prioritiesp. 43

6.8.7.1  Overviewp. 43

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  Requirementsp. 43

[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.
Up

6.8.8  Communication types based on prioritiesp. 43

6.8.8.1  MCX Service Emergency Group Communication requirementsp. 43

[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.
[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.
Up

6.8.8.2  MCX Service Emergency Private Communication requirementsp. 44

[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.
Up

6.8.8.3  Imminent Peril Group Communication requirementsp. 44

[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.
Up

6.8.8.4  MCX Service Emergency Alertp. 44

6.8.8.4.1  Requirementsp. 44
[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.
Up
6.8.8.4.2  MCX Service Emergency Alert cancellation requirementsp. 45
[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 |R18|p. 45

[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 aliasesp. 45

[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.
Up

6.10  MCX Service User Profile managementp. 45

[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.
Up

6.11  Support for multiple devicesp. 45

[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  Locationp. 46

[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.
Up

6.13  Securityp. 46

6.13.1  Overviewp. 46

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 protocolsp. 46

[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.
Up

6.13.3  Authenticationp. 46

[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 controlp. 46

[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.
Up

6.13.5  Regulatory issuesp. 47

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

6.13.6  Storage controlp. 47

[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 Communicationsp. 47

[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 communicationsp. 47

6.15.1  Discreet listening capabilitiesp. 47

[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.
Up

6.15.2  Ambient listeningp. 48

6.15.2.1  Overview of ambient listeningp. 48

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.
Up

6.15.2.2  Ambient listening requirementsp. 48

6.15.2.2.1  General ambient listening requirementsp. 48
[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 requirementsp. 48
[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 requirementsp. 48
[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 Communicationp. 49

6.15.3.1  Overviewp. 49

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.
Up

6.15.3.2  Requirementsp. 49

[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.
Up

6.15.4  Recording and audit requirementsp. 49

[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).
Up

6.15.5  MCX Service Ad hoc Group Communication |R18|p. 50

6.15.5.1  Overviewp. 50

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:
  1. The ad hoc group does not exist until it is spontaneously created during the communication.
  2. The ad hoc group ceases to exist when the communication terminates.
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 and it does not persist when the communication is terminated. 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.
Up

6.15.5.2  General aspectsp. 50

[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.
[R-6.15.5.2-001a]
The MCX Service shall provide the reason for denial to an MCX user who was not authorised to initiate an MCX Service Ad hoc Group Communication.
[R-6.15.5.2-001b]
The participant of an MCX Ad hoc Group Communication who has activated several Functional Alias(es) shall receive only one communication based on the unique MCX Service ID.
[R-6.15.5.2-001c]
The MCX Service shall provide a mechanism for the participant of an Ad hoc Group Communication to determine the Functional Alias, through which this participant is addressed by the communication.
[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 by an authorised user or 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-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 and/or an authorised user 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.
[R-6.15.5.2-014a]
When the list of participants is determined or updated by the MCX Service system, the MCX Service shall provide a mechanism that monitors and ensures that the participants list is applied for an MCX Service Ad hoc Group communication, performing retries when needed.
[R-6.15.5.2-015]
The MCX Service shall provide a mechanism for a participant of an MCX Service Ad hoc Group Communication to provide his location information to an authorised participant of the same group.
Up

6.15.5.3  Administrativep. 52

[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.
Up

6.15.5.4  Notification and acknowledgement for MCX Service Ad hoc Group Communicationsp. 52

[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 clause 6.2.1.

6.15.6  MCX Service Ad hoc Group Emergency Alert |R18|p. 52

6.15.6.1  Overviewp. 52

Due to an incident in an area, or a special operation, it can be necessary to coordinate MCX Users using Ad hoc Group Emergency Alert where these users do not normally work together and do not share any groups in common. MCX Service Ad hoc Group Emergency Alert enables authorized users to combine a random set of MCX Users based on criteria into a group and to send an emergency alert to this set of MCX Users.
The main characteristics of the Ad hoc Group Emergency Alert are:
  1. The ad hoc group does not exist until it is spontaneously created at the initiation of the Ad hoc Group Emergency Alert.
  2. After initiation of the Ad hoc Group Emergency Alert the MCX User may be put into the MCX Service Emergency State.
  3. After initiation of the Ad hoc Group Emergency Alert the resulting ad hoc group may be used for group communications.
  4. The ad hoc group ceases to exist when the group communications in the ad hoc group have terminated, and the Ad hoc Group Emergency Alert has been cancelled.
    An authorised user is able to:
    1. Initiate an MCX Service Ad hoc Group Emergency Alert with participants satisfying specific criteria,
    2. Cancel an MCX Service Ad hoc Group Emergency Alert,
During an ongoing MCX Service Ad hoc Group Emergency Alert, the set of MCX Users may change dynamically based on these criteria (e.g., criteria may not longer be met, or criteria may be met for additional MCX users, and as a result users are removed from or added to the ongoing Ad hoc Group Emergency Alert).
Up

6.15.6.2  General aspectsp. 53

[R-6.15.6.2-001]
The MCX Service shall support an MCX Service Ad hoc Group Emergency Alert capability, which on initiation by an MCX User causes that MCX UE to send an MCX Service Ad hoc Group Emergency Alert and may put that MCX User into the MCX Service Emergency State.
[R-6.15.6.2-002]
The MCX Service shall provide a means for an authorized user to be able to activate the MCX Service Ad hoc Group Emergency Alert capability.
[R-6.15.6.2-002a]
The MCX Service shall provide the reason for denial to an MCX user who was not authorised to activate the MCX Service Ad hoc Group Emergency Alert.
[R-6.15.6.2-003]
The MCX Service Emergency Alert shall contain the following information: Location information, MCX Service User ID, Functional Alias, Criteria for determining list of participants, available MCX Services, additional information related to the alert, and the user's Mission Critical Organization name.
[R-6.15.6.2-004]
The MCX Service shall provide a mechanism for the initiator of an MCX Service Ad hoc Group Emergency Alert to request that the list of participants is to be determined and updated by the MCX Service system using pre-defined criteria.
[R-6.15.6.2-004a]
The MCX Service shall provide a mechanism for an authorised user to update the pre-defined criteria during an on-going Ad hoc Group Emergency Alert.
[R-6.15.6.2-005]
The MCX Service Ad hoc Group Emergency Alert shall be distributed to the list of participants determined by the MCX Service system.
[R-6.15.6.2-005a]
When the list of participants is determined and updated by the MCX Service system, the MCX Service shall provide notifications to the relevant participants and authorized users.
[R-6.15.6.2-005b]
When the list of participants is determined or updated by the MCX Service system, the MCX Service shall provide a mechanism that monitors and ensures that the participants list is applied for MCX Service Ad hoc Group Emergency Alert, performing retries when needed.
[R-6.15.6.2-006]
The MCX Service shall support MCX Service Ad hoc Group Emergency Alert cancellation by authorized MCX Users.
[R-6.15.6.2-007]
The MCX Service shall provide a mechanism for an authorised user which is participant of an active MCX Service Ad hoc Group Emergency Alert to set up group communications using the ad hoc group.
[R-6.15.6.2-008]
When an MCX Service Ad hoc Group Emergency Alert is cancelled and ongoing calls in the ad hoc group are terminated the ad hoc group shall not persist.
Up

6.15.6.3  Administrativep. 53

[R-6.15.6.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 Emergency Alert.
[R-6.15.6.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 Emergency Alert.
[R-6.15.6.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 Emergency Alert.
[R-6.15.6.3-004]
The MCX Service shall provide a mechanism for an MCX Service Administrator to define the default parameters for the ad hoc group resulting from the MCX Service Ad hoc Group Emergency Alert (e.g., priority, hang time, broadcast mode).
[R-6.15.6.3-005]
The MCX Service shall provide a mechanism for an MCX Service Administrator to configure whether MCX Service Ad hoc Group Emergency Alert is allowed on the MCX system regardless of individual MCX User authorizations.
Up

6.16  Interaction with telephony servicesp. 54

[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  Interworkingp. 54

6.17.1  Non-3GPP accessp. 54

[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.

6.17.2  Interworking between MCX Service systemsp. 54

[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.
[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.
[R-6.17.2-008]
The MCX Service shall enable to establish an MCX Service Ad hoc Group Emergency Alert and MCX Ad hoc Group Communication with Participants of multiple MC Systems, which are interconnected.
Up

6.17.3  Interworking with non-MCX Service systems |R16|p. 54

6.17.3.1  GSM-Rp. 54

[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].
[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.
Up

6.17.3.2  External systemsp. 55

[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 Relaysp. 55

[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.
Up

6.19  Additional MCX Service requirementsp. 55

6.19.1  Communication rejection and queuingp. 55

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.
Up

6.19.1.1  Requirementsp. 55

[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.
Up

Up   Top   ToC