Content for  TS 22.179  Word version:  19.2.0

Top   Top   Up   Prev   Next
0…   4…   4.3   4.4…   4.6…   5…   5.6…   5.7…   5.8…   6…   6.4…   6.6…   6.8…   6.12…   6.16…   7…   7.11…   A…


4.6  Overview of MCPTT prioritiesp. 20

4.6.1  MCPTT priority modelp. 20

Many non-public safety 3GPP users today subscribe to one particular priority and QoS level of service (e.g., "gold", "silver" or "bronze"), which always provides fixed differentiation. This model, effective and relatively straightforward for non-public safety users, falls short when it comes to the needs of the public safety applications.
MCPTT Priority and QoS is situational. The MCPTT Service is intended to provide a real-time priority and QoS experience for MCPTT calls, as public safety users have significant dynamic operational conditions 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 3GPP system.
Another feature of a mission critical service is transparency of interactions between the users and the system. A first responder that needs to change the QoS of his communications is not to be distracted from his mission due to complicated UE behaviours or service interactions. Instead, the service acts in an anticipatory and adaptive manner to provide the proper quality of experience to the user, automatically, or with simple and minimal interaction.
The mission critical service is also expected to provide the ability to interface with public safety systems (e.g., Computer Aided Dispatch) in order to determine the user's state (e.g., incident severity), environment and conditions and to affect the most appropriate priority and QoS experience for the user.
The MCPTT Priority handling for on-network use for MCPTT Calls is conceptually modelled as shown in Figure 4.6.1-1. The conceptual model identifies three areas of prioritization: prioritization between and within calls, inter-system prioritization, and prioritization at the transport layer (3GPP system and UE). At the Application Layer a generic, network side, functional entity, "MCPTT Priority and QoS Control", processes with each request static, preconfigured information about users and groups participating in MCPTT, as well as dynamic (or situational) information about them. Based on the results of this processing, the "MCPTT Priority and QoS Control" provides information to and directs interactions with other functional entities, systems, or layers to ensure, to the extent possible, that from a quality of experience point of view, calls and transmissions are handled properly in accordance to established policy rules.
Copy of original 3GPP image for 3GPP TS 22.179, Fig. 4.6.1-1: A conceptual on-network MCPTT priority model
The User Static Attributes include information categorizing the user, possibly by several criteria (e.g., first responder, second responder, supervisor, dispatcher, administrator), as well as jurisdictional boundaries and possibly a preconfigured system-wide individual priority level.
The Group Static Attributes include information about the nature/type of the group and the owning organization(s), the jurisdictional boundaries for transmitters and receivers within the group, the normal hours of operation for the group, pre-emption dispositions relative to other groups, and the default minimum priority of the group, i.e., the minimum priority characteristics that are provided to all the Participants in a group call associated with this group, regardless of their individual priority characteristics.
The User Dynamic Attributes include the user/Participant's operational status (e.g., on/off duty), his location, the type of incident (e.g., MCPTT Emergency or Imminent Peril) he might be involved in and whether or not he initiated it, whether or not he is individually involved in a formally managed incident and if yes, the boundaries of the incident area, the incident severity and his assigned role in the resolution of the incident.
The Group Dynamic Attributes include the type of incident (e.g., MCPTT Emergency or Imminent Peril), if any, the group is currently handling and in case of involvement in a formally managed incident the boundaries of the incident area and the incident severity.

4.6.2  Generic processing of priority informationp. 20

This functionality applies to MCPTT Call initiations and transmissions for the management of potentially contended resources (e.g., GBR bearers) and also for Floor control during an MCPTT Group Call.
Each request for exclusive access to resource(s) or for preferential treatment over a contending request arrives accompanied by priority information. This information stays associated with the companion request, whether the request is granted or is queued. The priority information is used for comparison between requests and facilitates the adding and removing of requests from queues and/or authorized interruption of service associated with a previously granted request, if still active. For each request, whether initially queued or not, the requesting party is informed (directly or indirectly) when his request is granted or denied. Other users/Participants are also notified of the disposition of a request and the notification includes the identity of the requestor, as needed. In addition, each requestor can be notified of the position of his request in the queue and he is allowed to cancel his requests while queued.

4.6.3  Handling of MCPTT priority information for Floor controlp. 21

Floor control is applied in the context of a single MCPTT Call and is triggered by a Participant request for the permission to transmit. Priority information accompanies each grant request.

4.6.4  Handling of MCPTT priority information for interactions at the transport layerp. 21

At the Transport Layer, the MCPTT Service uses3GPP controls to adapt the overall behaviour of the MCPTT System to the needs for resources and/or preferential treatment over other contenders, based on the priority information accompanying the request.
The following four controls are available, to be used as necessary, based on the phase of the MCPTT call:
  • 3GPP system Access Controls;
  • UE Access Controls;
  • 3GPP system Admission Controls; and
  • 3GPP system Scheduling Controls.
3GPP system Access Controls and UE Access Controls are used to allow preferential treatment of public safety UEs in situations of access congestion. The controls use priority and QoS mechanisms (e.g., using mechanisms like Access Class Barring, Service Specific Access Control, Access Control for Circuit Switched Fallback, Extended Access Barring).
Admission Controls are used for the establishment and maintenance of the priority levels and of the pre-emption vulnerability and capability of bearers associated with transmissions and calls. At the start of an MCPTT call, the MCPTT Service requires bearers with proper ARP and pre-emption characteristics are in place prior to the call proceeding.
Scheduling Controls (e.g., QCI and bandwidth for the bearers) are used for assuring the appropriate QoS necessary for meeting the Participants' expectation in the perceived quality of the delivered information, primarily in terms of when the service starts and the real-time characteristics of the delivered traffic (e.g., perceived delay, choppiness, clarity).

4.6.5  Handling of MCPTT priority information for interactions with non-3GPP PTT systemsp. 21

An MCPTT call can be mixed, with some Participants served by one network/system and other Participants served by a different network(s)/system(s). In general the systems can be quite different. For example, some Participants use MCPTT/LTE, while others could use a P25-based system.

4.6.6  MCPTT priority for Private Callp. 21

The MCPTT Service uses User Static Attributes of the Participants, potentially adjusted based on User Dynamic Attributes, if applicable. By default, the priority of an MCPTT Private Call is the same as the priority of the originator of the call. Similar to group calls there are MCPTT Emergency Private Calls (with Floor control), which also have a similarly high priority. These are used where there is immediate danger to the user and are typically used to communicate with a dispatcher.

4.7  Overview of MCPTT identifiersp. 22

The main identifiable entities in use by the MCPTT Service are Mission Critical Organizations, MCPTT Groups, MCPTT Users, and MCPTT Administrators. The UEs are identified at the transport or network layer, but in some situations they might also be identified by the MCPTT Service. Each identifiable entity is distinct from all others and has an identifier (ID) associated to it, unique within a proximate identity domain. Those domains correspond to identifiable entities and can be nested within other domains in a multi-level hierarchical fashion. For example an MCPTT User might have an identifier unique within the domain corresponding to a Mission Critical Organization. The top-down concatenation of identifiers can generate unique identifiers within larger contexts, eventually leading to the identifiers being globally unique.
Each identifier can be associated with one or more aliases, which can be used for displaying and selection purposes. Some aliases are shortened equivalents of the identifier used for efficient signalling and are not intended for human interactions. At a minimum, each entity has one alias (default) which is the alphanumeric representation of its identifier. Most entities have a main alias, which is the entity's name. Some aliases can be pictures, icons or other graphic representations. It is up to the implementation to decide if aliases have to be unique and if so, within which domain. Finally, some aliases are public, can be created/deleted only by authorized persons and are available to the MCPTT Service, while other aliases are private, can be created/deleted by their owners and might be residing only on certain UEs or be part of some private address books.
It is possible in principle for User IDs, Group IDs, as well as for aliases, to be defined system wide with certain values, but have different values for each application: e.g., the system wide User ID might be different from the MCPTT User ID and different from the video User ID for the same user. However, this type of separation might not be beneficial, and in practice only one identifier is likely to be used.
For simplicity, the term "User ID" is employed to identify an MCPTT User, without distinction of whether it is an identifier or an alias.

Up   Top   ToC