A Push To Talk service provides an arbitrated method by which two or more users may engage in communication. Users may request permission to transmit (e.g., traditionally by means of a press of a button). The Mission Critical Push To Talk (MCPTT) service supports an enhanced PTT service, suitable for mission critical scenarios, based upon 3GPP system services. The requirements for Mission Critical Push To Talk (MCPTT) service defined within can also form the basis for a non-mission critical Push To Talk (PTT) service. The MCPTT Service is intended to support communication between several users (a group call), where each user has the ability to gain access to the permission to talk in an arbitrated manner. However, the MCPTT Service also supports Private Calls between pairs of users. The MCPTT Service builds on the existing 3GPP transport communication mechanisms provided by the 3GPP architectures to establish, maintain, and terminate the actual communication path(s) among the users. The MCPTT Service also builds upon service enablers: Group Communications System Enablers and Proximity Services. To the extent feasible, it is expected that the end user's experience to be similar regardless if the MCPTT Service is used under coverage of a 3GPP network or based on ProSe without network coverage. To clarify this intent, the requirements are grouped according to applicability to on-network use, off-network use, or both. Though the MCPTT Service primarily focuses on the use of the 3GPP system there might be users who access the MCPTT Service through non-3GPP access technology, dispatchers and administrators are examples of this. Dispatchers and administrators are special users who have particular admin and call management privileges which normal users might not have. In MCPTT dispatchers can use an MCPTT UE (i.e., 3GPP) or a non-3GPP access connection to the MCPTT Service based on a "dispatcher and Administrator" interface. Through this interface a user is able to access and manage the services related to on the network and those common to on the network and off the network. The MCPTT Service allows users to request the permission to talk (transmit voice/audio) and provides a deterministic mechanism to arbitrate between requests that are in contention (i.e., Floor control). When multiple requests occur, the determination of which user's request is accepted and which users' requests are rejected or queued is based upon a number of characteristics (including the respective priorities of the users in contention). MCPTT Service provides a means for a user with higher priority (e.g., MCPTT Emergency condition) to override (interrupt) the current talker. MCPTT Service also supports a mechanism to limit the time a user talks (hold the floor) thus permitting users of the same or lower priority a chance to gain the floor. The MCPTT Service provides the means for a user to monitor activity on a number of separate calls and enables the user to switch focus to a chosen call. An MCPTT Service user may join an already established MCPTT Group call (Late call entry). In addition the MCPTT Service provides the User ID of the current speaker(s) and user's Location determination features. The users of an MCPTT Service may have more stringent expectations of performance than the users of a commercial PTT service. MCPTT is primarily targeting to provide a professional Push To Talk service to e.g., public safety, transport companies, utilities or industrial and nuclear plants. In addition to this a commercial PTT service for non-professional use (e.g., groups of people on holiday) may be delivered through an MCPTT system. Based on their operational model, the performance and MCPTT features in use vary per user organization, where functionality which is more mission critical specific (e.g., Ambient Listening and Imminent Peril Call) might not be available to commercial customers. MCPTT Users expect to communicate with other MCPTT Users as outlined above, however MCPTT Users also need to be able to communicate with non MCPTT Users using their MCPTT UEs for normal telephony services.

Public safety workers often operate in groups and perform different tasks during the day/week. Many tasks and operations are controlled, assisted and/or coordinated by a dispatcher. For their communications public safety workers are organized in groups. People that are working together communicate in the same MCPTT Group, the group communication helping them to coordinate quickly. People with different tasks often communicate in separate MCPTT Groups. Many of the public safety tasks are routine tasks, that are handled by standard procedures and communication structures, using dedicated MCPTT Groups. Communication structures and MCPTT Groups are also prepared for the handling of large incidents and control of large events. Similarly there are MCPTT Groups and procedures for coordination with public safety workers from other organizations and/or other countries. The standard procedures and communication structures help the public safety workers to do their work successfully. This results in a long list of (>100) MCPTT Groups available to a public safety worker, from which the correct one is selected depending on the task. To help the public safety worker to quickly find and select the correct MCPTT Group for the task, the MCPTT Groups in the radio are often structured in folders and/or accessible via key-shortcuts. In addition to pre-established MCPTT Groups that users select, there are also provisions in MCPTT systems to merge MCPTT Groups and to select on behalf of a user which group they should be using and for a dispatcher to push them onto it. The large number of MCPTT Groups provisioned on devices is helpful for the device to be able to operate on the network and off the network. However the ability to provision over the air is also seen as a very useful feature, as currently Land Mobile Radio devices often have to be locally re-programmed, rather than updated over the air.

An MCPTT Service provides Group Call and Private Call capabilities, which have various process flows, states and permissions associated with them. The Figure 4.3.1, Figure 4.3.2, and Figure 4.3.3 indicate the high level flows, states and permissions associated with Group Calls and Private Calls. The diagrams apply to the on-network case and off-network case, as from a user perspective the service and concepts should appear similar on the network and off the network. From a technical perspective there might be differences between the on-network states and off-network states (e.g., off the network Affiliation might not require notifying an application server of a user's affiliation and there might also be other differences in the detail depending on the extent to which the off-network capabilities can match the on-network capabilities). If an MCPTT User wants to communicate with an MCPTT Group they have to be allowed to access the MCPTT Group (i.e., be an MCPTT Group Member), they then have to affiliate and then can have an MCPTT Group as their Selected MCPTT Group. If an MCPTT User is only affiliated to a group this is so that they can receive from the group, however if an MCPTT User has a Selected MCPTT Group this is their group for transmitting on. The differences in states enable an MCPTT User to receive from multiple MCPTT Groups, but specify which MCPTT Group they would like to transmit on.

It is possible for an MCPTT User to be affiliated with one or more MCPTT Groups. Normally, while in operation, an MCPTT User informs the MCPTT Service about which MCPTT Groups he would like to be affiliated to. These affiliations remain in effect until the MCPTT User removes them, or changes them, or signs out of the service. Some MCPTT Users have permanent affiliations to certain MCPTT Groups and those affiliations are set up implicitly (i.e., automatically) when operating on the network. For those users, the MCPTT Group affiliation starts when the MCPTT Service successfully signs in the user and ends when the MCPTT User's explicit or implicit (e.g., due to inactivity or the turning off of all its devices) request to sign out of the MCPTT Service is acknowledged. Every time a PTT request is granted a user can start an MCPTT transmission or "talk burst". An MCPTT Group Call consists of one or more MCPTT transmissions. Whether two consecutive transmissions from same or different users are part of the same call, or the second transmission starts a new call, depends on the configurable maximum length of the inactivity period between the consecutive MCPTT transmissions. This inactivity period can be seen as a Hang Time that starts at the end of the preceding transmission. While this timer is running, the resources associated with the call stay assigned to the call (except in case of pre-emption), which could reduce the latency of future floor requests for this group versus groups who are not involved in a call. When a new transmission starts during the inactivity period, the timer is stopped, reset and restarted again at the end of that transmission. The MCPTT Service recognizes a number of "special" group calls including: Broadcast Group Call, Emergency Group Call and Imminent Peril group call. A Broadcast Group Call can be seen as a special group call with only one MCPTT transmission. While the In-progress Emergency state or In-progress Imminent Peril state is active, the inactivity period is conceptually set to infinity; i.e., the resources assigned to calls during these states are never released (except in case of pre-emption). An MCPTT Emergency Group Call or an Imminent Peril group call can be seen as having an unspecified number of transmissions: essentially, all the transmissions to a group during In-progress Emergency state or In-progress Imminent Peril are part of the same MCPTT Group Call. Conditions on starting ("commencement") and continuing an MCPTT call can be established. Usually at least the call initiator (but also other users) are kept informed via notifications of the starting, stopping, queuing, etc., of a call. In general, commencement conditions are related to the presence on the call (i.e., participation) of certain members of the group, and/or of a minimum number of members, as well as on the availability of resources (e.g., GBR bearers) of proper ARP. If the commencement conditions are not met, the call does not start (it can be queued or rejected). Normally, commencement conditions are not checked for individual transmission within a call. Continuation conditions are similar (though not required to be identical) to commencement conditions and get re-evaluated when pre-emption, degradation of priority, motion out of communication range, de-selection of the group or de-affiliation (explicit or implicit) occur. If the continuation conditions are not met, the call stops.