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.