4.4 General handling of requests

22.1793GPPMission Critical Push to Talk (MCPTT) over LTERelease 17Stage 1TS

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.