Content for TS 22.179 Word version: 19.3.0
4.4 General handling of requests
4.5 Overview of MCPTT UE and MCPTT User in the MCPTT Service
4.5.1 MCPTT User association to MCPTT UE in on-network mode
4.5.2 MCPTT User and MCPTT UE relationship
4.5.3 MCPTT Users accessing the service through non-3GPP access interface
4.5.4 Shareable MCPTT UEs and gateway UEs
4.5.5 MCPTT User association to MCPTT UE in off-network mode
...
...
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.
