10.12 Priority Management

23.2803GPPCommon functional architecture to support mission critical servicesRelease 18Stage 2TS

10.12.1 General

Mission critical priority and QoS management is situational. The MC Services provides a real-time priority and QoS experience for the MC users, who have significant dynamic operational requirements that determine their priority. For example, the type of incident a responder is serving or the responder’s overall shift role needs to strongly influence a user’s ability to obtain resources from the LTE system.

Priority treatment applies on both application layer as well as on transport layer. The details on how the priority level is evaluated and used is outside the scope of this specification. What is specified is the necessary mechanisms to apply the priority and QoS and map different priority parameters between different entities, for example to map application layer priority to transport layer priority.

One of the requirements for MC communication services is to coordinate the use of priority levels between the different MC service servers. This priority coordination is used to mitigate and manage the risk for network congestion situations.

10.12.2 Information flows

10.12.2.1 MC priority request

Table 10.12.1.1-1 describes the information flow MC priority request from one MC service server to an MC service server taking the priority arbitration role.

Table 10.12.1.1-1: MC priority request

Information element	Status	Description
Priority	M	Requested priority
Priority area	M	The geographical area for which the requested priority is required.
Type of service	O	The MC service type e.g. MCVideo, MCPTT or MCData

10.12.3 Procedure for priority coordination between multiple MC service servers

In deployment scenarios with multiple MC service servers of different or the same type it is required to coordinate the priorities used by the different servers. The procedure defined below provides the necessary coordination between MC service servers to manage high priority levels. One of the involved MC service servers is assigned the role of being a priority arbitrator among a group of MC service servers serving the same geographical area. The priority arbitrator may also compete for the same limited network resources. Prior to using this procedure all MC service servers need to be configured with information about which MC service server will act as the priority arbitrator and under what conditions (e.g. priority level) the priority arbitrator should be used. The use of this procedure is not mandated. MC systems that supports priority coordination between multiple MC service servers should support this procedure.

Pre-condition:

1. One of the MC service servers is assigned the role of the priority arbitrator.

2. It is assumed that all MC service servers are part of the same trusted domain.

3. A MC communication session is ongoing or is about to commence. The operational situation together with static and dynamic attributes requires the use of elevated priority for network resources.

Editor’s note: It is FFS if enforcement of the granted priority can be applied to MC service servers outside of the same trusted domain

Editor’s note: It is FFS how the MC service server 2 (priority arbitrator) knows about ongoing traffic.

Figure 10.12.3-1: Priority arbitration between multiple MC service servers

1. A need for high priority level is identified by the MC service server 1. The priority level identified is above the level of priority that the MC service server 1 can utilise without centralized priority arbitration.

2. The MC service server 1 sends a MC priority request to the MC service server being assigned the priority arbitrator role. The request includes the geographical area, duration, the priority level, service type and needed capacity.

3. The priority arbitrator determines whether to grant, reject or queue the request for elevated priority.

NOTE 1: How the priority arbitrator makes this determination is out of scope of the present document.

NOTE 2: One source of information for the priority arbitrator to evaluate the priority request, could be information received at the resource reservations over the Rx reference point. Example of such information is resource request failure and Retry-Interval AVP which could be an indication of RAN user plane congestion, see reference 3GPP TS 29.214 [27].

4. The priority arbitrator grants MC service server 1 the elevated priority

5. The priority arbitrator notifies other MC service servers about the elevated priority granted to other services.

NOTE 3: The behaviour of the MC service servers that receive this information is implementation specific. The MC service server may take this information into account when performing priority evaluations for the MC service clients managed by this MC service server.

6. The MC service server utilizes the elevated priority when requesting resources for new or existing MC service communication.

NOTE 4: The priority level granted to the MC service server 1 can be mapped to an applicable SIP priority header or a reservation priority AVP (when the MC service server use the Rx reference point directly).

7a-c. A priority notification may be sent to the MC service clients in the geographical area in which the priority was granted. Messages to MC service clients need to be sent from the MC service server serving each MC user. This message is preferably sent over a multicast bearer.

Editor’s note: How the clients could utilize such notifications is FFS.

8. The MC service server 1 identifies that the elevated priority is not needed.

9. The requested MC Priority is released from the MC service server 1.

10. The MC service server 2 (priority arbitrator) informs other MC servers that the elevated priority is released.

Editor’s note: It is FFS to include procedure for MC priority revoking.

Editor’s note: It is FFS to include procedure for MC priority queueing.