Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 22.280  Word version:  18.1.0

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

 

5.9  MCX Service User ProfileWord‑p. 21

[R-5.9-001]
The MCX Service shall ensure that each MCX User has at least one associated MCX Service User Profile that records the MCX User's: information, including permissions and privileges with respect to the MCX Service.
[R-5.9-002]
The MCX Service shall provide a means for an MCX Service Administrator to manage the MCX Service User Profile for MCX Users within their authority.
Up

5.9a  Functional alias |R15|Word‑p. 22

5.9a.1  Overview |R17|Word‑p. 22

A functional alias is a user selectable alias that is tied to the assignment or task of the user. A MCX User can activate one or multiple functional aliases at the same time. The activation of the functional alias(es) will take place after the user has signed in to the MCX Service using the MCX User ID.
The same functional alias can be assigned for use to multiple users depending on MCX Service Administrator settings. A functional alias can be taken over by an authorized MCX User, depending on MCX Service Administrator settings. These two capabilities are mutually exclusive and can not be configured for the same functional alias.
A functional alias can be used to identify for example the driver(s) of a particular train, identified by train number and the role of the user on that train.
Each functional alias that is active on the MCX Service system is unique for addressing purposes. For example, if there are two drivers of TRAIN29 (e.g. DRIVER1_TRAIN29, DRIVER2_TRAIN29), then each active functional alias should be uniquely addressable.
A functional alias can be structured into meaningful elements (e.g. user.agency@organization.country, role.mission@department.company, function.equipment.ID@city, label1.label2.label3@firstname.familyname). Based on one or more of these elements in the functional alias, specific sets of MCX users can be selected fore.g. regrouping purposes.
Up

5.9a.2  Requirements |R17|Word‑p. 22

[R-5.9a-001]
The MCX Service shall provide a mechanism for the MCX User to activate one or more functional alias(es) for use by the MCX Users within that MCX Service system (i.e. the primary MCX Service system of the functional alias).
[R-5.9a-001a]
The MCX Service system shall be able to use the functional alias as a unique identifier for MCX Users as Participant of an MCX Service Group, e.g. to display a functional alias as speaker identification or for the use in group member lists.
[R-5.9a-001b]
The MCX Service system shall provide a mechanism for an MCX User to assign a functional alias for use on an MCX Service Group.
[R-5.9a-001c]
The MCX Service system shall provide a mechanism for an MCX User to assign an activated functional alias for an outgoing MCX Private communication.
[R-5.9a-002]
The MCX User shall be reachable by its functional alias(es) from within the MCX Service system where the functional alias was activated.
[R-5.9a-002a]
An MCX User shall be reachable by its functional alias from the primary MCX system while migrated to partner MCX Service systems.
[R-5.9a-003]
The MCX Service shall provide a mechanism for the MCX User to deactivate a functional alias.
[R-5.9a-004]
The MCX Service shall upon request provide the MCX User a list of functional aliases from which the user can select for activation/deactivation.
[R-5.9a-005]
The MCX Service shall provide a mechanism for an MCX Service Administrator to create, delete, manage functional aliases, and for each functional alias indicate either if it can be simultaneously active for multiple MCX Users up to a per-alias configurable number, or if it is allowed to be taken over by an authorized MCX User, or none of these two options.
[R-5.9a-006]
If an MCX User attempts to activate a functional alias that is already active for another MCX User, and is not allowed to be simultaneously active for multiple MCX Users or the number of simultaneous MCX Users is reached to the upper limit, the MCX Service shall inform the MCX User that the functional alias is already in use.
[R-5.9a-007]
If an MCX User attempts to activate a functional alias that is already active for at least one other MCX User, and that functional alias is allowed to be simultaneously active for multiple MCX Users and the upper limit of number of simultaneous MCX Users is not reached, the MCX Service shall activate the functional alias for the MCX user and inform all other MCX User(s) with the same functional alias.
[R-5.9a-008]
If an authorized MCX User attempts to activate a functional alias that is already used by another MCX User, and that functional alias is allowed to be taken over, and is not indicated for simultaneous activation to multiple MCX Users, the MCX Service shall offer the MCX User to take over the functional alias from the MCX User using the alias.
[R-5.9a-008a]
If an authorized MCX User attempts to activate a functional alias that is already active for at least one other MCX User, and the upper limit of number of simultaneous MCX Users is reached, the MCX Service shall reject the MCX User's request.
[R-5.9a-009]
If an authorized MCX User takes over the functional alias that is already active for another MCX User, the MCX Service shall activate the functional alias to the MCX User and inform the previous MCX User that the alias has been deactivated.
[R-5.9a-010]
The MCX Service shall allow the MCX User to perform an activation/deactivation of an unlisted functional alias that is defined in the MCX Service system.
[R-5.9a-011]
An authorized MCX User shall be able to interrogate the MCX Service system of the alias(es) active for a certain MCX User.
[R-5.9a-012]
The MCX Service shall provide a mechanism for an MCX Service Administrator to authorize a MCX User to activate, deactivate, interrogate and take over a functional alias.
[R-5.9a-013]
VOID
[R-5.9a-014]
The MCX Service shall allow the functional alias to be structured as a combination of organizationally meaningful elements (e.g. user.agency@organization.country, role.mission@department.company, function.equipment.ID@city, label1.label2.label3@firstname.familyname).
[R-5.9a-015]
The MCX Service system shall allow an MCX Service Administrator to make use of information (e.g. operational schedules, locations, velocity or direction) from external sources to create or delete a functional alias.
[R-5.9a-016]
The MCX Service system shall allow the MCX Service Administrator to assign a communication priority for a functional alias.
[R-5.9a-017]
The MCX Service system shall allow the MCX Service Administrator to assign a time limit to a functional alias after which the functional alias will be deactivated.
[R-5.9a-018]
The MCX Service shall support automatic activation and de-activation of a functional alias based on the operational criteria (e.g. MCX User ID, login/logoff from the MCX Service system, specific external information supplied by external systems).
[R-5.9a-019]
The MCX Service shall provide a mechanism for an MCX Service Administrator to define a functional alias with related geographic areas that can be associated to MCX Users for the purpose of routing Location dependent communications, as part of handling MCX Service Private Communication requests, when the determination of the receiving party is based on the initiating MCX User's current Location.
[R-5.9a-020]
The MCX Service shall provide a mechanism for an MCX Service Administrator to configure for a particular functional alias, a set of functional aliases under the same authority to which a Private Communication (without Floor control) can be made by an MCX User registered to this particular functional alias.
[R-5.9a-021]
The MCX Service shall provide a mechanism for an MCX Service Administrator to configure for a particular functional alias, a set of functional aliases under the same authority from which Private Communication (without Floor control) is allowed to an MCX User registered to this particular functional alias.
[R-5.9a-022]
For private calls to functional aliases the authorizations in clause 5.9a.2 shall replace the authorizations defined in clause 6.7.3.
[R-5.9a-023]
The MCX Service system shall support private calls and private emergency calls to a functional alias simultaneously activated by multiple MCX Users.
[R-5.9a-024]
The MCX Service system shall enable an MCX Service Administrator to select the mechanism to be used for handling of private calls to functional aliases that are allowed to be simultaneously active for multiple MCX Users.
[R-5.9a-025]
The MCX Service system shall be able to provide a mechanism to inform the MCX User about the functional alias activation/deactivation status (e.g. activation/deactivation accepted, activation/deactivation pending, activation/deactivation rejected).
[R-5.9a-026]
The MCX Service shall provide the functional alias(es) of the transmitting MCX Service Group Member that enter the communication late in accordance with subclause 5.3.
[R-5.9a-027]
The MCX Service shall provide a Location information report for every authorized MCX User associated with one functional alias in accordance with subclause 6.12.
[R-5.9a-028]
The MCX Service shall provide the functional alias(es) associated with the MCX Service User ID, of the transmitting Participant to the receiving MCX Users (UEs) unless the transmitting Participant's identity is restricted in accordance with subclause 6.4.3.
[R-5.9a-029]
The MCX Service shall provide, upon request, the list of currently affiliated members of an MCX group which encompasses the MCX Service User ID and the associated functional alias(es) of each member in accordance with subclause 6.4.5.
[R-5.9a-030]
The MCX Service shall provide a mechanism for the enforcement of uniqueness of a functional alias within a Mission Critical organisation in accordance with subclause 6.9.
[R-5.9a-031]
The MCX Service shall provide a mechanism for an authorized MCX User to obtain a list of functional aliases currently activated in the system either periodically or as a onetime request.
Up

5.10  Support for multiple devicesWord‑p. 24

[R-5.10-001]
The MCX Service shall allow an MCX User to log in to multiple MCX UEs concurrently.
[R-5.10-001a]
The MCX Service shall be able to allow the MCX Service Administrator to limit the number of simultaneous logins of MCX Users to multiple MCX UEs on a per-MCX service basis.
[R-5.10-001b]
The MCX Service shall be able to allow the MCX Service Administrator to limit the number of simultaneous logins of an MCX User to multiple MCX UEs on a per MCX User basis.
[R-5.10-002]
The MCX Service shall ensure that the MCX User logs into each MCX UE separately.
Up

5.11  LocationWord‑p. 24

[R-5.11-001]
The MCX Service shall support obtaining and conveying Location information describing the position of the MCX UE.
[R-5.11-002]
The MCX Service should support obtaining and conveying high accuracy Location information describing the position of the MCX UE.
[R-5.11-002a]
The MCX Service shall be able to provide a mechanism for obtaining high accuracy Location information by integrating position information from multiple external sources (e.g. magnetometers, orientation sensors, GNSS)
[R-5.11-003]
The MCX Service shall provide for the flexibility to convey future formats of Location information.
[R-5.11-004]
The MCX Service shall provide a means for MCX Service Administrators to manage the privacy of Location information for MCX Users within their authority.
[R-5.11-005]
An authorized MCX User shall be able to control the supplying of Location information by the MCX UE for MCX Service communications.
[R-5.11-006]
The conveyed Location information shall be the most recently obtained information about the position of the MCX UE at the time of the Location information conveyance.
[R-5.11-007]
The MCX Service shall be capable of configuring and re-configuring one or more Location information update triggers (i.e., identified conditions that, when satisfied, cause the MCX UE to report its current Location information).
[R-5.11-008]
The MCX Service shall be able to modify Location information update triggers of an MCX User while the MCX User is on the network.
[R-5.11-009]
The MCX Service shall provide a means for an MCX UE to send a Location information update whenever a trigger condition is satisfied (e.g., initial registration, distance travelled, elapsed time, cell change, tracking area change, PLMN change, MCX Service communication initiation).
[R-5.11-010]
The MCX Service shall provide a means for an MCX UE to send a Location information update whenever the MCX User initiates an MCX Service Emergency Alert.
[R-5.11-011]
The MCX Service shall provide a means for an MCX UE to send a Location information update whenever the MCX User initiates an MCX Service Emergency Group Communication.
[R-5.11-012]
The MCX Service shall provide a means for an MCX UE to send a Location information update if the MCX User is in an MCX Service Emergency State and a configured amount of time has passed since the previous location information update.
[R-5.11-013]
The MCX Service shall provide a means for an MCX UE to send a Location information update whenever a trigger condition is satisfied while the MCX User is in MCX Service Emergency State (e.g., initial registration, distance travelled, elapsed time, cell change, tracking area change, PLMN change, MCX Service communication initiation).
[R-5.11-014]
The MCX Service shall provide a means for an MCX Service Administrator to define geographical areas to be used for Location information update triggers for MCX Users within their authority.
[R-5.11-015]
The MCX Service shall provide a means for an MCX UE in a predefined area to send a Location information update whenever a trigger condition configured in an MCX User's active MCX Service User Profile is satisfied (e.g., initial registration, distance travelled, elapsed time, cell change, tracking area change, PLMN change, MCX Service communication initiation).
Up

5.12  SecurityWord‑p. 25

[R-5.12-001]
The MCX Service shall provide a means to support the confidentiality and integrity of all user traffic and signalling at the application layer.
[R-5.12-002]
The MCX Service shall support MCX User with globally unique identities, independent of the mobile subscriber identity (IMSI) assigned by a 3GPP network operator to UEs.
[R-5.12-003]
The MCX Service identities shall be part of the MCX Service application service domain.
[R-5.12-004]
The MCX Service identities shall form the basis of the MCX Service application layer security for the MCX Service.
[R-5.12-005]
The MCX Service shall provide the MCX User with a mechanism to perform a single authentication for access to all authorized features.
[R-5.12-006]
The MCX Service shall provide a means for an authorized MCX UE to access selected MCX Service features prior to MCX User authentication.
[R-5.12-007]
The MCX Service shall require authentication of the MCX User before service access to all authorized MCX Service features is granted.
[R-5.12-008]
Subject to regulatory constraints, the MCX Service shall provide a means to support confidentiality, message integrity, and source authentication for some information exchanges (e.g., MCX Service User Profile management, kill commands) that have the potential to disrupt the operation of the target MCX UE.
[R-5.12-009]
The MCX Service shall provide a means to support end-to-end security for all media traffic transmitted between MCX UEs.
[R-5.12-010]
End-to-end security shall be supported both within and without network coverage and regardless of whether the traffic is transmitted directly or via the network infrastructure.
[R-5.12-011]
Subject to regulatory constraints, the MCX Service shall provide a cryptographic key management service(s).
[R-5.12-012]
The cryptographic key management service(s) shall support both pre-provisioning and over-the-air provisioning of cryptographic keys.
[R-5.12-013]
The cryptographic key management service(s) shall ensure that cryptographic keys are confidentiality protected, integrity protected and authenticated when delivered over-the-air.
[R-5.12-014]
The MCX Service shall provide end-to-end confidentiality and integrity protection to the MCX User Profile when transferred to and/or from and while stored on an MCX Server, an MCX UE or both.
Up

5.13  Media qualityWord‑p. 26

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

5.14  Relay requirementsWord‑p. 26

[R-5.14-001]
The MCX Service shall be able to use ProSe Relay capabilities defined in TS 22.278 and TS 22.468.
[R-5.14-002]
An MCX UE which is unable to gain service from a 3GPP network should attempt to make use of one or more suitable ProSe UE-to-Network Relay(s) in its proximity (see subclause 6.18).
[R-5.14-003]
In off-network situations ProSe UE-to-UE Relay functionality shall be supported (see subclause 7.15) between MCX UEs.
[R-5.14-004]
The MCX Service shall provide a means for an MCX UE in a robot to have a ProSe UE-to-Network Relay capability.

5.15  Gateway requirementsWord‑p. 26

[R-5.15-001]
The MCX Service system shall be accessible via gateway MCX UEs by MCX Users.
[R-5.15-001a]
The MCX Service system shall provide a mechanism to uniquely identify a gateway MCX UE.
[R-5.15-002]
Gateway MCX UEs shall ensure that the content of communications between the MCX Service System and an MCX User attached to the gateway MCX UEs is unaltered.
[R-5.15-003]
Gateway MCX UEs shall handle the communication traffic attributes, e.g. priority and QoS, of an MCX User attached to a gateway MCX UE independently of other MCX Users concurrently attached to the same gateway MCX UE.
[R-5.15-004]
Multiple Gateway MCX UEs shall be able to operate within the same area (e.g., site of an incident or accident, overlapping coverage, adjacent cells, etc.).
[R-5.15-005]
MCX Users shall be able to select gateway MCX UEs, in case multiple, accessible gateway MCX UEs are available.
[R-5.15-006]
An MCX User shall be able to access multiple gateway MCX UEs simultaneously from a single device while restricting a MCX Service to one gateway (e.g., MCPTT on gateway UE 1, MCData and MCVideo on gateway UE 2).
Up

5.16  Control and management by Mission Critical OrganizationsWord‑p. 27

5.16.1  OverviewWord‑p. 27

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

5.16.2  General requirementsWord‑p. 27

[R-5.16.2-001]
The MCX Service shall be able to support multiple Mission Critical Organizations, each with their own MCX Users and MCX Service Groups, on the same MCX Service system.
[R-5.16.2-002]
The MCX Service shall provide a mechanism by which Mission Critical Organizations designate and manage (i.e., add, delete, change authorizations, etc.) MCX Service Administrators with authority to manage users, groups, other MCX Service Administrators, security controls, and other mission affecting parameters (e.g., authorizations and priorities) of the MCX Service.
[R-5.16.2-003]
The MCX Service shall protect the operational privacy of Mission Critical Organizations by providing effective separation between the administrative and security management (e.g., key) parameters of those organizations except as authorized by the Mission Critical Organizations involved.
[R-5.16.2-004]
The MCX Service shall protect the administrative and security management parameters of Mission Critical Organizations from viewing and manipulation by individuals (including those within and outside of the mission critical organization) not explicitly authorized by the Mission Critical Organization.
[R-5.16.2-005]
The MCX Service shall provide a mechanism by which Mission Critical Organizations may share subsets of their administrative and security parameters with other Mission Critical Organizations.
Up

5.16.3  Operational visibility for Mission Critical OrganizationsWord‑p. 27

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

5.16.4  Sharing of administrative configuration between Mission Critical Organizations |R18|Word‑p. 27

Mission Critical Organizations can deploy their own 3GPP standardized mobile, local, countrywide or national broadband mission critical communications systems. In order to grant visiting MCX Service Users access to a Partner MCX Service System and its services, a mechanism is required, which allows the exchange of administrative configuration between connected MCX Service Systems.
[R-5.16.4-001]
An MCX Service shall provide a mechanism to allow an authorised MCX User to request MCX User configuration changes in one or more Partner MCX Service Systems (e.g., priorities, authorizations).
[R-5.16.4-002]
An MCX Service shall provide a mechanism to allow an authorised MCX User to evaluate and respond to requests for configuration changes from Partner MCX Service Systems.
[R-5.16.4-003]
An MCX Service shall provide a mechanism to allow an authorised MCX User to configure automatic responses to categories of requests for configuration changes from Partner MCX Service Systems (e.g., particular users, or groups).
[R-5.16.4-004]
An MCX Service shall provide a mechanism to allow an authorised MCX User to request configuration information (e.g., users, groups, security level) from Partner MCX Service Systems.
[R-5.16.4-005]
An MCX Service shall provide a mechanism to allow an authorised MCX User to send configuration information to Partner MCX Service Systems.
[R-5.16.4-006]
An MCX Service shall provide a mechanism to allow an authorised MCX User to exchange operationally relevant information for specific MCX Users, e.g., MCX User capability information, with Partner MCX Service Systems.
[R-5.16.4-007]
An MCX Service System shall provide a mechanism to allow secure exchange of administrative and security related information with interconnected MCX Service systems without compromising the integrity and security of either system.
[R-5.16.4-008]
An MCX Service System shall provide a mechanism to allow exchange of administrative and security related information with interconnected MCX Service systems without exposing the internal network topology of either system.
Up

5.17  General administrative – groups and usersWord‑p. 28

[R-5.17-001]
The MCX Service shall provide a mechanism for an MCX Service Administrator to create and define the membership of MCX Service Groups.
[R-5.17-002]
The MCX Service shall provide a mechanism for an MCX Service Administrator to authorize a user to request an MCX Service Group Communication to one or more MCX Service Groups.
[R-5.17-003]
The MCX Service shall provide a mechanism for an MCX Service Administrator to determine MCX Users who have the role of a particular Participant type on an MCX Service Group.
[R-5.17-004]
The MCX Service shall provide mechanisms for an MCX Service Administrator to assign and amend the identifying information of an MCX Service Group (e.g., name, alias).
[R-5.17-005]
The MCX Service shall provide a mechanism for an MCX Service Administrator to assign and amend the identifying information of MCX Service User Profiles (e.g., name, identifier, alias).
[R-5.17-006]
The MCX Service shall provide a mechanism to notify MCX Users when they become a member of an MCX Service Group or their membership of an MCX Service Group is removed. This notification shall include any provisions required by the MCX User to use the MCX Service Group if the MCX User has been added to the MCX Service Group or remove provisions if the MCX User has been removed from the MCX Service Group.
[R-5.17-007]
The MCX Service shall provide mechanisms for an MCX Service Administrator to create, amend, delete, and suspend MCX Service User Profiles.
[R-5.17-008]
The MCX Service shall enable an MCX Service Administrator to configure which MCX Service Group Members are authorized to select to transmit to an MCX Service Group.
Up

5.18  Open interfaces for MCX servicesWord‑p. 28

5.18.1  OverviewWord‑p. 28

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

5.18.2  RequirementsWord‑p. 28

[R-5.18.2-001]
The MCX Service shall be securely accessible via an open interface by an external application.
[R-5.18.2-002]
The MCX Service shall restrict external access based on MCX Service permissions and authorizations.
[R-5.18.2-003]
The open interface for MCX Services shall support control and indication of communication priority.
[R-5.18.2-004]
The MCX Service shall be able to authenticate the MCX User connecting to the MCX Service through the open interface.
Up

5.19  Media forwardingWord‑p. 29

5.19.1  Service descriptionWord‑p. 29

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

5.19.2  RequirementsWord‑p. 29

[R-5.19.2-001]
An MCX Service shall provide a mechanism for an authorized MCX User to forward media received within an MCX Group to another MCX User or another MCX Group.
[R-5.19.2-002]
An MCX Service shall provide a mechanism for an authorized MCX User to forward media received from an MCX User to another MCX User or to an MCX Group.
[R-5.19.2-003]
The MCX Service shall provide a mechanism for a MCX UE (whose current user is authorized) to forward a received real time communication in an MCX Group communication to a Group Broadcast Group.

5.20  Receipt notificationWord‑p. 29

5.20.1  Service descriptionWord‑p. 29

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

5.20.2  RequirementsWord‑p. 29

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

5.21  Additional services for MCX Service communicationsWord‑p. 29

5.21.1  Remotely initiated MCX Service communicationWord‑p. 29

5.21.1.1  OverviewWord‑p. 29

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

5.21.1.2  RequirementsWord‑p. 30

[R-5.21.1.2-001]
The MCX Service shall provide a mechanism for an authorized MCX User (e.g. dispatch operator) to remotely initiate an MCX Service Private Communication or MCX Service Group Communication from another user's MCX UE.
[R-5.21.1.2-002]
The MCX Service shall provide a mechanism for an authorized MCX User (e.g. dispatch operator) to request remote activation of an MCX Service Group Communication from another user's (e.g. officer in the field with wearable camera) MCX UE.
[R-5.21.1.2-003]
The MCX Service shall provide a mechanism for an authorized MCX User (e.g. officer in the field with wearable camera) to accept or deny access to an MCX Service Group Communication from their MCX UE.
[R-5.21.1.2-004]
The MCX Service shall provide a mechanism for an MCX User to request an authorized MCX User (e.g., a dispatcher) to send an MCX Communication (e.g., video or data) to the MCX UE (downlink pull).
Up

5.21.2  Remotely terminated MCX Service communicationWord‑p. 30

5.21.2.1  RequirementsWord‑p. 30

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

Up   Top   ToC