Content for TS 22.280 Word version: 19.6.0
8 Inter-MCX Service interworking
8.1 Inter-MCX Service interworking overview
8.2 Concurrent operation of different MCX Services
8.3 Use of unsharable resources within a UE
8.4 Single group with multiple MCX Services
8.5 Priority between services
9 Air ground air Communication
9.1 Service Description
9.2 Requirements
10 MCX Service in IOPS mode
8 Inter-MCX Service interworking p. 63
8.1 Inter-MCX Service interworking overview p. 63
Clause 8 describes interworking of one MCX Service with another.
The MCData Service as defined in TS 22.282 includes description of multiple independent applications and data transfer capabilities, which may themselves be subject to interworking limitations as identified in clause 8. Therefore, requirements in clause 8 should be used as guidance for MCData interworking between individual applications within that one MCX Service.
8.2 Concurrent operation of different MCX Services p. 64
8.2.1 Overview p. 64
In some cases, a User or UE will use multiple independent MCX Services. The intention in this case is that each service will operate totally independently of the other services and should not cause service, capability or capacity interaction problems. It is understood that different UE may have different abilities to cope with the demands of simultaneous services. The requirements in subclause 8.2.2 identify how to handle simultaneous services which are intended to be completely independent of each other but limits in total capacity to handle multiple services and multiple instances within a service is left for suppliers to characterise for their products.
Where independent functionality between services is constrained due to transport capacity limitations, those requirements are indicated in the subclause on Priority between Services.
When the constraint is due to the service itself (e.g. Audio embedded within a video and MCPTT speech both delivering audible signals) any potential conflict may be avoided by action in the network part of the service but these actions are not specified. In subclause 8.2.2 actions taken by a single UE in case of conflict not resolved in the network are specified.
8.2.2 Requirements p. 64
[R-8.2.2-001]
Except where expressly stated each MCX Service shall operate independently of each other MCX Service.
[R-8.2.2-002]
Any floor control facility remains completely independent for each of simultaneous MCX Services except where expressly stated.
[R-8.2.2-003]
A user shall be able to transmit on one MCX Service and receive on another without service interaction limitations.
[R-8.2.2-004]
A user shall be able to transmit on different MCX Services at essentially the same time without service interaction limitations.
[R-8.2.2-005]
A user shall be able to receive on different MCX Services at essentially the same time without service interaction limitations except where services are competing for the same unsharable resource which may include the display, audio transducers, etc.
[R-8.2.2-006]
When operating multiple MCX Services on the same network, radio resources shall be able to be utilized in an efficient manner for all MCX Services up to certain thresholds defined for each MCX Service and/or the combination of MCX Services. The radio resource allocation for each MCX Service and the combination of MCX Services shall be flexible based on demand, or allocated in a predefined manner.
[R-8.2.2-007]
The network shall be able to assign radio resources so that resources assigned to each MCX Service, or the combination of all MCX Services stays below a threshold, subject to the agreement between the 3GPP network operator and the Mission Critical Organization(s) (e.g., 3GPP network can be operated by Mission Critical Organization(s), or 3GPP network is operated by commercial operator), for resources to be used for MCX Services without impacting other non-MCX Services.
8.3 Use of unsharable resources within a UE p. 64
[R-8.3-001]
An MCX UE should be able to present audio from multiple sources (e.g. MCVideo, MCPTT) in a manner that is easily distinguished.
[R-8.3-002]
An MCX UE may enable the user (e.g. incident commander) to control the relative volumes and spatial rendering of concurrent audio sources (e.g. MCVideo, MCPTT) at the UE.
[R-8.3-003]
The MCX Service shall provide a mechanism for a MCX User to prioritize the use of contended resources (e.g. display, loudspeaker) in the UE (e.g. most recently selected MCX Service, MCPTT voice always has priority).
[R-8.3-004]
Communication marked as Emergency or Imminent Peril shall take priority use of contended resources in the UE over communication not marked as Emergency or Imminent Peril.
[R-8.3-005]
When a MCX Service is denied access to contended resource in the UE, an indication shall be given to the User to alert them of the situation.
[R-8.3-006]
When a MCX Service is denied access to contended resource in the UE, a facility shall be provided for the User to select their preferred MCX Service for access to contended resources for the duration of the limitation.
8.4 Single group with multiple MCX Services p. 65
8.4.1 Overview p. 65
It is useful to be able to configure any single group to be able to handle multiple MCX Services. In subclause 8.4 requirements are on the service to provide a solution that looks as though the services are working in a coupled and coordinated manner. The exact means of achieving this is not implied here. So, where a User may affiliate to a single group for two services, this could be a single affiliation indicating two services but handled together or it could be that the UE sends two affiliations, one for each service, in response to the single command to affiliate. There may also be other possibilities. In essence, the solution should look and feel like a combined service.
8.4.2 Requirements p. 65
[R-8.4.2-001]
Mission critical groups shall be able to use multiple MCX Services independently or in combination.
[R-8.4.2-002]
The MCX Service shall provide a mechanism by which an authorized MCX User can affiliate to a mission critical group using that MCX Service through a single logical group affiliation for any subset of MCX Services used by the group, or independently by MCX Service.
[R-8.4.2-003]
To support operation coordinated between mission critical services, an MCX Service used by a mission critical group shall be able to interact with another MCX Service used by the same group.
[R-8.4.2-004]
To support combined services where the operation is intended to be coordinated, each MCX Service shall be able to apply similar geographic restrictions in use for one MCX Service to also operate in the coordinated MCX Service(s).
[R-8.4.2-005]
The MCX Service shall provide a mechanism by which an authorized MCX User who is affiliated to multiple MCX Services in a single group can de-affiliate specific MCX UEs from each MCX Service independently.
8.4.3 Compatibility of UE p. 65
8.4.3.1 Advertising service capabilities required p. 65
[R-8.4.3.1-001]
The MCX Service shall provide a mechanism by which an MCX User of a UE can only affiliate to a Common MCX Service Group(s) for MCX Services that the MCX User's UE is capable of supporting.
[R-8.4.3.1-002]
The MCX Service shall provide a mechanism to advertise the service capabilities required to participate in a group e.g. choice of codec so that an MCX User can check the UE's compatibility before attempting to affiliate.
[R-8.4.3.1-003]
The MCX Service shall provide a mechanism for a UE to advertise its capability and limitation information when its MCX User affiliates to a group.
[R-8.4.3.1-004]
If the MCX User affiliates to a group, but its UE does not provide capability and limitation information, then the MCX Service shall assume that any MCX Service relevant content can be handled by that UE.
8.4.3.2 Conversion between capabilities p. 65
[R-8.4.3.2-001]
Where an MCX Service does not advertise the service capabilities required to participate in a group it is assumed that service capability itself is sufficient to take part in the group. For example if a specific codec is being used and a joining UE may not support that codec then the service will provide transcoding for UEs that support the service but do not support the codec.
8.4.4 Individual permissions for service access p. 66
[R-8.4.4-001]
When a UE makes a combined request to affiliate to a Common MCX Service Group the MCX Service may respond by permitting access to the group for some but not all MCX Services if appropriate.
8.4.5 Common alias and user identities or mappable p. 66
[R-8.4.5-001]
To support combined services where the operation is intended to be coordinated, it shall be possible for one MCX Service to access and communicate using user identifying information in use for a coordinated MCX Service.
8.4.6 Single location message p. 66
[R-8.4.6-001]
The MCX Service shall provide configuration and capability so that when a UE is affiliated to a Common MCX Service Group and some or all of the MCX Services periodically require location messages to be sent then each location message sent may be configured to apply to all MCX Services or to only one specific MCX Service.
[R-8.4.6-002]
The MCX Service shall provide configuration and capability so that when a UE is affiliated to multiple groups and some or all of the groups periodically require location messages to be sent then each location message sent may be configured to apply to all affiliated groups or may be applied to only one specific group.
[R-8.4.6-003]
The MCX Service shall provide configuration and capability so that when a UE is affiliated to multiple Common MCX Service Groups and some or all of the Common MCX Service Groups periodically require location messages to be sent then each location message sent may be configured to apply to all Common MCX Service Groups or may be applied to only one specific Common MCX Service Group.
8.5 Priority between services p. 66
8.5.1 Overview p. 66
The 3GPP priority system using ARP and QCI is expected to be used for relative priority treatment among communications at the transport level. Further application of priority will be invoked in and by the MCX Service system according to service related requirements e. g User and situation
8.5.2 Requirements p. 66
[R-8.5.2-001]
For on network communications, priority management shall manage all data flows from the different mission critical services together when applying priority decisions.
[R-8.5.2-002]
For off network communications, priority management shall manage all data flows from the different mission critical services together when applying priority decisions.
[R-8.5.2-003]
The MCX Service systems shall provide a mechanism to dynamically prioritize one MCX Service over another.
[R-8.5.2-004]
The MCX Services, in coordination with each other, shall be able to give appropriate priorities to the different communications according to User, content type, device type, participant type and operational situation.
[R-8.5.2-005]
MCX Services shall notify users of actions taken by the dispatcher that result in a change in priority for a data flow.
9 Air ground air Communication p. 67
9.1 Service Description p. 67
Mission critical users use aircrafts and helicopters for operational purpose. Being able to communicate in real time with helicopters and aircraft is a basic need.
Some traffic assumptions are provided in Annex D.
9.2 Requirements p. 67
[R-9.2-001]
The MCX Service shall support Air ground air Communication up to 15.000 ft with a speed up to [450]km/h.
10 MCX Service in IOPS mode p. 67
[R-10-001]
An MCX Service shall be able to provide services when operating in a 3GPP network in IOPS mode.
