Content for TS 22.179 Word version: 17.1.0
4.4 General handling of requests
4.5 Overview of MCPTT UE and MCPTT User in the MCPTT Service
4.6 Overview of MCPTT priorities
4.7 Overview of MCPTT identifiers
...
...
4.4 General handling of requests p. 17
Request handling is by no means specific only to MCPTT Service, but it plays a central role in its functionality.
Requests appear in the MCPTT Service in many forms and under many circumstances: e.g., requests for the floor during a call, requests for starting a call, requests for resources. Conceptually, requests are accompanied by priority information that is used in the arbitration, in case of contention; see also subclause 4.6 for a brief explanation and examples on how priority processing is modelled.
Upon arrival, a request is immediately granted, denied, or queued.
If queued, a request can be dropped due to queue overflow (i.e., too many items queued) or can be cancelled by an authorized user, who is usually the initiator of the request. Either way, the net result is that the request is denied.
When a request denial is communicated, the request may be re-requested either manually by user action or automatically. In the automatic case, while the request remains denied, it may be automatically repeated a configurable number of times where a minimum time interval between re-transmissions may also be applied.
There are many "queuing disciplines" possible that govern the placement of items in a queue and their subsequent removal from the queue: e.g., FIFO, priority order. Assuming that the queuing discipline chosen places the highest priority requests towards the top of the queue, the granted request is either, depending on the design and configuration, the front-most entry in the queue or the first entry counting from the top that can be satisfied by the available resources. For example, if the topmost entry in the queue is awaiting for ten GBR bearers of given characteristics to become available and the second entry in the queue is waiting for seven GBR bearers to become available, and at some point in time eight GBR bearers become available, then it is possible that the second request is granted ahead of the first one, which continues to wait. Alternatively, neither the first request nor the second request is granted and the wait continues until at least ten GBR bearers become available, at which time the first request is granted while the second request continues to wait.
4.5 Overview of MCPTT UE and MCPTT User in the MCPTT Service p. 17
The MCPTT Service supports MCPTT User Profiles. The MCPTT User Profile contains important information related to the MCPTT User receiving the MCPTT Service, including the MCPTT User identity, which is globally unique and independent of the mobile subscriber identity (IMSI) assigned by a 3GPP network operator. Part of the content of the MCPTT User Profile (e.g., containing some display preferences, some UE audio settings, some address books) can be set/modified/updated by the MCPTT User, but significant portions might be set/modified/updated only by authorized persons. The MCPTT User Profile is stored permanently in database(s) associated with the infrastructure providing the MCPTT Service. Relevant parts of the profile might be downloaded to and cached temporarily or permanently on certain MCPTT UEs. When stored on an MCPTT UE, the MCPTT User Profile associated with an MCPTT User might be confidentiality and integrity protected, with the information available only to a trusted application client associated to the MCPTT User, upon authentication. The MCPTT User Profile information can be synchronized automatically or on demand between the cache on the MCPTT UE and the main copy held in the database(s) of the MCPTT Service infrastructure. The MCPTT User Profile is part of the MCPTT application service domain and forms the basis of MCPTT application layer security and identifies an MCPTT User to the MCPTT Service.
Each MCPTT User has at least one MCPTT User Profile, and possibly several. Typically, one of the MCPTT User Profiles is designated as the default MCPTT User Profile, to be used unless an MCPTT User Profile is explicitly selected. In general, a user profile is associated with a specific device, with a specific mode of operation (i.e., on the network or off the network) and/or with a specific situation (e.g., user being off-duty, in a certain city, or playing a certain role). When an MCPTT User Profile is synchronized between the infrastructure and an MCPTT device, information could be downloaded to the device and updated, as necessary. Subsequently and subject to permissions, the MCPTT User might choose a different associated MCPTT User Profile to be downloaded and stored on the device. Only one MCPTT User Profile is active at a time. Authorized users are allowed to create, delete and alter MCPTT User Profiles for an MCPTT User and/or pre-stored MCPTT User Profiles.
The MCPTT Service supports MCPTT UEs which connect to the MCPTT Service. The capabilities of an MCPTT UE are specified in the present document. The MCPTT Application that is resident on the MCPTT UE establishes this connection, employing application layer security in its connection to the MCPTT Service. An MCPTT UE is capable of operating in on-network and off-network modes.
4.5.1 MCPTT User association to MCPTT UE in on-network mode p. 18
Consistent with the 3GPP paradigm, when an MCPTT UE is powered on, it accesses the 3GPP system, and connects to the 3GPP network. During this phase, the credentials from a USIM application (or possibly, an ISIM application, if IMS is used) on a UICC associated with the MCPTT UE is used for authentication with an HSS. This is followed by the MCPTT Application, resident on the MCPTT UE, establishing a connection, employing application layer security in its connection to the MCPTT Service.
Possibilities for the MCPTT UE, when connecting to the MCPTT Service:
- An MCPTT UE, with credentials of an MCPTT User at the time of connection to the MCPTT Service, is able to authenticate using a specific MCPTT User identity (e.g., via an Identity Management service). After successful user authentication the MCPTT User Profiles are made available to the MCPTT UE for use in both on-network and off-network operation modes.
- An MCPTT UE, without credentials of a specific MCPTT User at the time of connection to the MCPTT Service, proceeds using a default identity associated with the MCPTT UE itself. In this case, the MCPTT Service is capable of assigning a temporary MCPTT User Identity to this MCPTT UE. Some level of authentication might be attempted, and, depending on the results, an appropriate MCPTT User Profile associated with this temporary MCPTT User Identity and with the circumstances of the access is made available to the MCPTT UE for use in both on-network and off-network operation modes.
- The MCPTT Administrator is able to retrieve hardware and software parameters to define specific parameters and attributes (e.g., groups, MCPTT Emergency behaviour, priority and QoS attributes) associated with a temporary MCPTT User Identity for operation of the MCPTT UE for use in both on-network and off-network operation modes.
4.5.2 MCPTT User and MCPTT UE relationship p. 18
A user can enter his identifying/authenticating credentials (e.g., user name/ password, PIN, biometrics, asserted identity from a remote, trusted device). This step typically gives the MCPTT User access to local information and applications stored on the MCPTT UE, and in particular, to the MCPTT client application.
The MCPTT Service allows the same MCPTT User to sign in (and stay simultaneously signed in) from different MCPTT UEs. For example, an incident manager or commander might use a portable phone, a command tablet, or a separate messaging unit.
4.5.3 MCPTT Users accessing the service through non-3GPP access interface p. 18
This document primarily focuses on MCPTT Users accessing and managing the MCPTT Service through MCPTT UEs, however there might be some dispatchers and administrators who might access the service through a non-3GPP access interface.
4.5.4 Shareable MCPTT UEs and gateway UEs p. 18
The conceptual model for shareable MCPTT UEs is that of a pool of UEs, each UE being interchangeable with any other, and users randomly choosing one or more UEs from the pool, each user for his temporary exclusive use. A shareable MCPTT UE can be used by user who can gain access to the MCPTT client application stored on it and can become an authenticated MCPTT User. A shareable MCPTT UE can serve only one MCPTT User at a time. An MCPTT User who signs into a shareable MCPTT UE that is already in-use causes the sign-off of the previous MCPTT User.
An MCPTT User can simultaneously have several active MCPTT UEs, which, from an MCPTT Service point of view, are addressable individually and/or collectively within the context of their association to the MCPTT User.
The conceptual model for a gateway UE is that of a UE capable of providing service to an MCPTT User employing a non-3GPP device. A gateway UE is usable simultaneously by multiple MCPTT Users. Unlike a shareable MCPTT UE, if a new person enters his valid credentials towards signing in the MCPTT Service, his successful signing in and becoming an MCPTT User does not affect the initial MCPTT Users already served by the gateway UE.
A gateway UE is typically installed in a vehicle (e.g., a police car, fire truck) and has wired and/or wireless connections to various devices in use by the MCPTT Users.
A gateway UE differs functionally from a ProSe relay node. In the ProSe paradigm, the relay node and the devices served by it are all (ProSe enabled) 3GPP UEs, and are "visible" to the 3GPP system as UEs. In the gateway UE paradigm, only the gateway UE is an 3GPP device and only it is "visible" at the 3GPP network layer.
Figure 4.5.4-1 shows schematically some of the relationships between MCPTT Users and MCPTT UEs.
4.5.5 MCPTT User association to MCPTT UE in off-network mode p. 19
A user can enter his identifying/authenticating credentials (e.g., user name/ password, PIN, biometrics, asserted identity from a remote, trusted device). This step typically gives the MCPTT User access to local information and applications stored on the MCPTT UE, and in particular, to the MCPTT client application.
After successful local user authentication an MCPTT User Profile, which was previously made available to the MCPTT UE, is used for off-network operation mode. This previously configured MCPTT User Profile information allows the MCPTT User to be identified using the same MCPTT User Identity as in the on-network mode.
An MCPTT UE, without credentials of a specific MCPTT User, operates in off-network mode, if so configured by an MCPTT Administrator. The MCPTT Administrator defines specific parameters and attributes (e.g., groups, MCPTT Emergency behaviour, priority and QoS attributes) associated with a temporary MCPTT User Identity for operation of the MCPTT UE in off-network operation mode.
4.6 Overview of MCPTT priorities p. 20
4.6.1 MCPTT priority model p. 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.
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 information p. 21
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 control p. 22
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 layer p. 22
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.
4.6.5 Handling of MCPTT priority information for interactions with non-3GPP PTT systems p. 22
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 Call p. 22
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 identifiers p. 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.
