Content for TS 22.179 Word version: 19.3.0
6 MCPTT Service requirements specific to on-network use
6.1 General administrative - groups and users
6.2 MCPTT calls
6.2.1 Commencement modes for MCPTT Group calls
6.2.2 Queuing
6.2.3 Floor control
6.2.3.1 General aspects
6.2.3.2 Requesting permission to transmit
6.2.3.3 Override
6.2.3.3.1 General aspects
6.2.3.3.2 Override - one transmitting Participant
6.2.3.3.3 Override - simultaneously Transmitting MCPTT Group Members
6.2.3.4 Terminating permission to transmit
6.2.3.5 Transmit time limit
6.2.3.6 Audio cut-in on designated MCPTT Groups
6.2.3.6.1 Overview
6.2.3.6.2 Requirements
6.2.3.6.3 Requesting permission to transmit
6.2.3.6.4 Terminating permission to transmit
6.2.3.6.5 Transmit time limit
6.2.3.7 MCPTT Groups configured for multi-talker control
6.2.3.7.1 Overview
6.2.3.7.2 General aspects
6.2.3.7.3 Requesting permission to transmit
6.2.3.7.4 Override
6.2.4 Call termination
6.3 General requirements
...
...
6 MCPTT Service requirements specific to on-network use p. 33
6.1 General administrative - groups and users p. 33
[R-6.1-001]
Void
[R-6.1-002]
Void
[R-6.1-003]
Void
[R-6.1-004]
Void
[R-6.1-005]
Void
[R-6.1-006]
Void
[R-6.1-007]
Void
6.2 MCPTT calls p. 34
6.2.1 Commencement modes for MCPTT Group calls p. 34
[R-6.2.1-001]
The MCPTT Service shall be capable of allowing an MCPTT Group call setup request to proceed without prior acknowledgement by any MCPTT User of that MCPTT Group.
[R-6.2.1-001a]
The MCPTT Service shall be capable of allowing an MCPTT Group Call setup request to proceed only if a minimum number of MCPTT Group Members are currently affiliated.
[R-6.2.1-001b]
The MCPTT Service shall be capable of allowing an MCPTT Group Call setup request to proceed only if specific MCPTT Group Member(s) are currently affiliated.
[R-6.2.1-002]
An MCPTT User currently affiliated to an MCPTT Group shall acknowledge receipt of an MCPTT Group call setup request, if requested to do so by the MCPTT Service.
[R-6.2.1-003]
The MCPTT User's acknowledgement may require direct interaction of the MCPTT UE with the human user, or may be automatically executed by the MCPTT UE, in accordance with policy established by an MCPTT Administrator.
[R-6.2.1-004]
The MCPTT Service shall be capable of requiring that a minimum number of Affiliated MCPTT Group Members acknowledges receipt of the MCPTT Group call setup request before the audio transmission proceeds.
[R-6.2.1-005]
The MCPTT Service shall be capable of requiring that specific MCPTT Users acknowledge receipt of the MCPTT Group call setup request before the audio transmission proceeds, regardless of the affiliation state of those users.
[R-6.2.1-006]
The MCPTT Service shall be capable of requiring that all MCPTT Users that are both affiliated to the MCPTT Group and in a given geographical area acknowledge receipt of an MCPTT Group call setup request before the audio transmission proceeds.
[R-6.2.1-007]
The MCPTT Service shall provide a mechanism for an MCPTT Administrator to determine the subset of Affiliated MCPTT Group Members that shall acknowledge receipt of the MCPTT Group call setup request before the audio transmission proceeds.
[R-6.2.1-008]
If an MCPTT Group Call setup request requires acknowledgement from Affiliated MCPTT Group Members, and the required MCPTT Group Members do not acknowledge the call setup within a configured time (the "acknowledged call setup timeout"), the MCPTT Service may proceed with the call and then may notify the initiating MCPTT User that the acknowledgements did not include all required members.
[R-6.2.1-009]
If an MCPTT Group Call setup request requires acknowledgement from Affiliated MCPTT Group Members, and the required MCPTT Group Members do not acknowledge the call setup within a configured time, the MCPTT Service may abandon the call and then may notify the initiating MCPTT User that the acknowledgements did not include all required members.
[R-6.2.1-010]
If an MCPTT Group Call setup request requires acknowledgement from Affiliated MCPTT Group Members, the initiating MCPTT User shall at any time have the option of allowing the call to proceed regardless of the state of the acknowledgements (i.e., to "convert" the call to an unacknowledged call).
[R-6.2.1-010a]
If an MCPTT Group Call setup request requires acknowledgement from Affiliated MCPTT Group Members, and the required MCPTT Group Members did not acknowledge the call setup within a configured time, the MCPPT Service shall be able to provide the list of MCPTT Group Members who did not acknowledge the call to the initiating MCPTT User.
[R-6.2.1-011]
If an MCPTT Group Call setup request requires acknowledgement from Affiliated MCPTT Group Members, the acknowledged call setup timeout shall be established by an MCPTT Administrator.
[R-6.2.1-012]
If an MCPTT Group Call setup request requires acknowledgement from Affiliated MCPTT Group Members, the behaviour in response to the expiration of the acknowledged call setup timeout shall be established by an MCPTT Administrator.
[R-6.2.1-013]
If an MCPTT Group Call setup request requires acknowledgement from Affiliated MCPTT Group Members, the MCPTT Service shall support an indefinite (i.e., infinite) call setup timeout.
[R-6.2.1-014]
If the MCPTT Service has knowledge that some affiliated members of a group can not be Participants in an unacknowledged MCPTT Group Call, the MCPTT Service shall provide an indication to the requester that the call is proceeding without all affiliated members, and shall provide the list of the missing members based on policy established by the MCPTT Administrator.
[R-6.2.1-015]
If MCPTT User(s) are excluded from an MCPTT call as there is insufficient capacity to support their participation the MCPTT Service shall ensure that the MCPTT User(s) receive a notification that they have been excluded from the call for reasons of lack of capacity.
6.2.2 Queuing p. 35
[R-6.2.2-001]
Void
[R-6.2.2-002]
Void
[R-6.2.2-003]
Void
[R-6.2.2-004]
Void
[R-6.2.2-005]
Void
[R-6.2.2-006]
Void
6.2.3 Floor control p. 35
6.2.3.1 General aspects p. 35
[R-6.2.3.1-001]
The Floor control functionality in an MCPTT Service shall determine at a point in time which Participant(s) are allowed to transmit to other Participant(s).
[R-6.2.3.1-002]
Receiving Participant(s) shall receive audio from one transmitting Participant. The only exception is if an MCPTT Group is configured to allow simultaneous Transmitting MCPTT Group Members in override.
[R-6.2.3.1-003]
The MCPTT Service shall provide a mechanism for the MCPTT Administrator to configure the number (maximum of N9) of simultaneous audios received by an MCPTT User in a single MCPTT Group.
6.2.3.2 Requesting permission to transmit p. 35
[R-6.2.3.2-001]
An authorized Participant shall be able to request to transmit to an MCPTT Group or an individual Participant.
[R-6.2.3.2-002]
At call setup the MCPTT Service shall provide a notification, for example audio and/or visual, to the MCPTT Group Member attempting to transmit that there are no other Group Members who have affiliated to the MCPTT Group.
[R-6.2.3.2-003]
The Floor control functionality shall determine the transmitting Participant(s) when there are simultaneous requests for permission to transmit within the same call.
[R-6.2.3.2-004]
Following an MCPTT Request for permission to transmit on the Selected MCPTT Group, the Affiliated MCPTT Group Member that made and was granted the request shall be given an indication of being allowed to transmit.
[R-6.2.3.2-005]
Following an MCPTT Request for permission to transmit on the Selected MCPTT Group, an Affiliated MCPTT Group Member that made and was not granted the request shall be given an indication that permission to transmit was rejected or queued.
[R-6.2.3.2-006]
The depth of the Floor control queue shall be configurable.
[R-6.2.3.2-007]
Following an MCPTT Private Call (with Floor control) request for permission to transmit, the MCPTT User that is allowed to transmit shall be given an indication that the user is allowed to transmit to the targeted MCPTT User.
[R-6.2.3.2-008]
Following an MCPTT Private Call (with Floor control) request for permission to transmit, an MCPTT User that is not allowed to transmit shall be given an indication that the permission to transmit was rejected or queued.
[R-6.2.3.2-009]
The MCPTT Service shall provide an indication to receiving Participants that the transmitting Participant is starting to transmit.
[R-6.2.3.2-010]
The MCPTT Service shall provide a mechanism for an MCPTT Participant to remove its MCPTT Request from the Floor control queue.
[R-6.2.3.2-011]
The MCPTT Service shall provide a mechanism for removal (i.e., request accepted, request denied, or expiration of a timer) of an MCPTT Request from the Floor control queue.
[R-6.2.3.2-012]
The MCPTT Service shall provide a mechanism for the MCPTT Administrator to configure the parameter(s) of the Floor control queue for an MCPTT Group (i.e., timer).
6.2.3.3 Override p. 36
6.2.3.3.1 General aspects p. 36
[R-6.2.3.3.1-001]
The MCPTT Service shall enable MCPTT Administrators to create a priority hierarchy for determining what Participants, Participant types, and urgent transmission types shall be granted a request to override an active MCPTT transmission.
[R-6.2.3.3.1-002]
The MCPTT Service shall enable an MCPTT Administrator to configure which MCPTT Group transmission a Participant(s) receives, overriding and/or overridden for cases where an authorized Participant overrides an MCPTT transmission.
[R-6.2.3.3.1-003]
The MCPTT Service shall enable the MCPTT Administrator to configure the MCPTT Group to allow only the overriding Participant to transmit or to allow both the overriding and overridden Participant to transmit.
[R-6.2.3.3.1-004]
The MCPTT Service shall provide a mechanism for an MCPTT Administrator to configure MCPTT Private Calls (with Floor control) to allow only the overriding Participant to transmit or to allow both the overriding and overridden Participant to transmit.
[R-6.2.3.3.1-005]
The priority hierarchy used for granting a request to override an active MCPTT transmission shall contain at least four (4) levels.
[R-6.2.3.3.1-006]
The transmitting Participant shall be determined by the relative Floor control priorities of the Participants and Call type based on priority (e.g MCPTT Emergency).
[R-6.2.3.3.1-007]
The MCPTT Service shall provide a mechanism for Participants, to override an active MCPTT transmission of a transmitting Participant when the priority level of the overriding Participant or Call type based on priority (e.g MCPTT Emergency) are ranked higher than the priority level of the transmitting Participant or Call type based on priority.
[R-6.2.3.3.1-008]
If an authorized Participant overrides an MCPTT transmission, the MCPTT Service shall provide a means of notifying the overridden Participant(s) that the transmission has been overridden.
6.2.3.3.2 Override - one transmitting Participant p. 36
[R-6.2.3.3.2-001]
If the MCPTT Group has been configured to only allow the overriding transmitting Participant, the MCPTT Service shall revoke the transmit permission of the overridden transmitting Participant.
6.2.3.3.3 Override - simultaneously Transmitting MCPTT Group Members p. 37
[R-6.2.3.3.3-001]
If the MCPTT Group has been configured to allow both overriding and overridden transmitting Participants, authorized receiving Participants shall be enabled to listen to both the overriding and overridden Participant transmissions, dependent on configuration.
[R-6.2.3.3.3-002]
The MCPTT Service shall allow successive overrides of an MCPTT Group Call when the request to override is made by an MCPTT User having a higher Floor control priority than the currently transmitting Participants.
[R-6.2.3.3.3-003]
In the case of successive overrides, the MCPTT Service shall enable only two transmissions, one overriding transmission, from the highest priority MCPTT User, and one overridden transmission, chosen from among the two overridden Participants based upon configured rule(s). (i.e., this could be based simply on priority of user, it could be based on a policy that an overridden MCPTT Emergency transmission shall remain as the overridden transmission or a rule could be established that the MCPTT system shall not allow two dispatchers to be both the overriding and overridden transmitters.).
6.2.3.4 Terminating permission to transmit p. 37
[R-6.2.3.4-001]
The MCPTT Service shall enable an authorized MCPTT User to terminate the permission to transmit of a transmitting Participant at any time.
[R-6.2.3.4-002]
A transmitting Participant shall be able to indicate to the MCPTT Service that the Participant no longer wants to transmit.
[R-6.2.3.4-003]
The MCPTT Service shall provide an indication to receiving Participants that the transmitting Participant has finished transmitting.
6.2.3.5 Transmit time limit p. 37
[R-6.2.3.5-001]
The MCPTT Service shall enable an MCPTT Administrator to configure the limit for the length of time that a Participant transmits from a single request to transmit.
[R-6.2.3.5-002]
The Floor control functionality shall have a configurable limit for the length of time that a Participant transmits from a single request to transmit.
[R-6.2.3.5-003]
The Floor control functionality shall provide an indication to the transmitting Participant that the Participant is within a configurable amount of time before his transmit time limit is reached.
[R-6.2.3.5-004]
The Floor control functionality shall provide an indication to the transmitting Participant that the Participant's transmit time limit has been reached.
[R-6.2.3.5-005]
The Floor control functionality shall remove the permission to transmit from the transmitting Participant when the Participant's transmit time limit has been reached.
6.2.3.6 Audio cut-in on designated MCPTT Groups |R14| p. 37
6.2.3.6.1 Overview p. 37
The audio cut-in feature applies to specially designated MCPTT Groups and results in Floor control for that group allowing any participant within the MCPTT Group to interrupt any other participant. In particular the audio cut-in feature means that the last Participant to request the floor is assigned the floor immediately and there is only ever one talker on the call at a particular point in time. Audio cut-in is often used for teams escorting VIPs where timeliness is essential to allow teams to react as quickly as possible.
Other than the difference in floor control logic, the MCPTT Groups configured to support audio cut-in behave in the same way as other MCPTT Groups with group management, affiliation, selection of a group, requesting the floor, the notifications received related to Floor control etc working in the same way.
6.2.3.6.2 Requirements p. 38
[R-6.2.3.6.2-001]
The MCPTT Group shall be configurable to allow audio cut-in.
[R-6.2.3.6.2-002]
When an MCPTT Group has been configured to support audio cut-in, the Floor control functionality shall give the floor to the MCPTT Group Member that has selected that MCPTT Group and made the most recent request to transmit in that MCPTT Group.
[R-6.2.3.6.2-003]
When an MCPTT Group has been configured to support audio cut-in the Floor control functionality shall restrict the number of talkers in the group to one.
[R-6.2.3.6.2-004]
When an MCPTT Group has been designated to support audio cut-in the MCPTT Group shall not support any form of floor control queuing and associated functionality.
[R-6.2.3.6.2-005]
When the current talker is interrupted by a request to transmit on an MCPTT Group supporting audio cut-in, the talk request of the interrupted talker shall end.
[R-6.2.3.6.2-006]
Void
[R-6.2.3.6.2-007]
Void
6.2.3.6.3 Requesting permission to transmit p. 38
[R-6.2.3.6.3-001]
An authorized Participant shall be able to request to transmit to an MCPTT Group configured to support audio cut-in.
[R-6.2.3.6.3-002]
At call setup the MCPTT Service shall provide a notification, for example audio and/or visual, to the MCPTT Group Member attempting to transmit that there are no other Group Members who have affiliated to the MCPTT Group configured to support audio cut-in.
[R-6.2.3.6.3-003]
Following an MCPTT Request for permission to transmit on the Selected MCPTT Group configured to support audio cut-in, the Affiliated MCPTT Group Member that made and was granted the request shall be given an indication of being allowed to transmit.
[R-6.2.3.6.3-004]
The MCPTT Service shall provide an indication to receiving Participants that the transmitting Participant is starting to transmit on a group configured for audio cut-in.
6.2.3.6.4 Terminating permission to transmit p. 38
[R-6.2.3.6.4-001]
The MCPTT Service shall enable an authorized MCPTT User to terminate the permission to transmit of a transmitting Participant at any time on a group configured for audio cut-in.
[R-6.2.3.6.4-002]
A transmitting Participant shall be able to indicate to the MCPTT Service that the Participant no longer wants to transmit on a group configured for audio cut-in.
[R-6.2.3.6.4-003]
The MCPTT Service shall provide an indication to receiving Participants that the transmitting Participant has finished transmitting on a group configured for audio cut-in.
6.2.3.6.5 Transmit time limit p. 38
[R-6.2.3.6.5-001]
The MCPTT Service shall enable an MCPTT Administrator to configure the limit for the length of time that a Participant transmits from a single request to transmit on a group configured for audio cut-in.
[R-6.2.3.6.5-002]
The Floor control functionality for a group configured for audio cut-in shall have a configurable limit for the length of time that a Participant transmits from a single request to transmit.
[R-6.2.3.6.5-003]
The Floor control functionality for a group configured for audio cut-in shall provide an indication to the transmitting Participant that the Participant is within a configurable amount of time before his transmit time limit is reached.
[R-6.2.3.6.5-004]
The Floor control functionality for a group configured for audio cut-in shall provide an indication to the transmitting Participant that the Participant's transmit time limit has been reached.
[R-6.2.3.6.5-005]
The Floor control functionality for a group configured for audio cut-in shall remove the permission to transmit from the transmitting Participant when the Participant's transmit time limit has been reached.
6.2.3.7 MCPTT Groups configured for multi-talker control |R15| p. 39
6.2.3.7.1 Overview p. 39
The multi-talker control applies to designated MCPTT Groups and results in allowing several Participants talking simultaneously within the MCPTT Group. For example, Multi-talker control is used by railway communication e.g. during shunting operation.
Except for Floor control as specified in clause 6.2.3.1, clause 6.2.3.2, clause 6.2.3.3 and clause 6.2.3.6 all other requirements specified in clause 6.2.3 floor control are applicable to all types of MCPTT Groups configured to support multi-talker control
When an MCPTT Group is configured for multi-talker control, the requirements listed below apply.
6.2.3.7.2 General aspects p. 39
[R-6.2.3.7.2-001]
An MCPTT Group shall be configurable to allow multi-talker control.
[R-6.2.3.7.2-002]
The MCPTT Service shall provide a mechanism for multiple MCPTT Users to talk simultaneously in an MCPTT Group configured for multi-talker control.
[R-6.2.3.7.2-003]
The MCPTT Service shall determine which Participant(s) are allowed to transmit to all other Participant(s) in an MCPTT Group configured for multi-talker control.
[R-6.2.3.7.2-004]
The MCPTT Service shall support all Participant(s) to receive audio from all other Participant(s) that are transmitting in an MCPTT Group configured for multi-talker control.
[R-6.2.3.7.2-005]
The MCPTT Service shall provide a mechanism for the MCPTT Administrator to configure the maximum number of simultaneous talkers in an MCPTT Group configured for multi-talker control.
[R-6.2.3.7.2-006]
The MCPTT Service shall allow an authorized MCPTT User to change the maximum number of simultaneous talkers at any time during a group call in an MCPTT Group configured for multi-talker control.
[R-6.2.3.7.2-007]
The MCPTT Service shall allow an authorized MCPTT User to change the priority hierarchy of simultaneous talkers at any time during a group call in an MCPTT Group configured for multi-talker control.
[R-6.2.3.7.2-008]
In case the maximum number of simultaneous talkers is reduced by an authorized MCPTT User, the permission to talk will be revoked, until the new maximum number of simultaneous talkers is met.
6.2.3.7.3 Requesting permission to transmit p. 39
[R-6.2.3.7.3-001]
The MCPTT Service shall enable authorized Participants to request to transmit to an MCPTT Group configured for multi-talker control.
[R-6.2.3.7.3-002]
At call setup the MCPTT Service shall provide a notification, for example audio and/or visual, to the MCPTT Group Member attempting to transmit that there are no other Group Members who have affiliated to the MCPTT Group configured for multi-talker control.
[R-6.2.3.7.3-003]
The MCPTT Service shall determine the transmitting Participant(s) when there are simultaneous requests for permission to transmit within the same call for an MCPTT Group configured for multi-talker control.
[R-6.2.3.7.3-004]
Following an MCPTT Request for permission to transmit on the Selected MCPTT Group configured for multi-talker control the MCPTT Service shall provide an Affiliated MCPTT Group Member that made and was granted the request an indication of being allowed to transmit.
[R-6.2.3.7.3-004a]
Following an MCPTT Request for permission to transmit on the Selected MCPTT Group configured for multi-talker control the MCPTT Service shall provide an Affiliated MCPTT Group Member that made and was denied the request, the reason for denial.
[R-6.2.3.7.3-004b]
Following an MCPTT Request for permission to transmit on the Selected MCPTT Group configured for multi-talker control the MCPTT Service shall provide an Affiliated MCPTT Group Member that made and was queued the request, the position in the queue.
[R-6.2.3.7.3-005]
Once in the queue, the MCPTT service shall provide to an Affiliated MCPTT Group Member, the position in the queue on demand.
6.2.3.7.4 Override p. 40
6.2.3.7.4.1 General aspects p. 40
[R-6.2.3.7.4.1-001]
If the number of MCPTT Users requesting the permission to talk exceeds the maximum number of simultaneous talkers in an MCPTT Group configured for multi-talker control, the MCPTT Service shall apply the override mechanism.
[R-6.2.3.7.4.1-002]
The MCPTT Service shall enable MCPTT Administrators to create a priority hierarchy for determining what Participants, Participant types (e.g., dispatcher) and urgent transmission types shall be granted a request to override an active MCPTT transmission on an MCPTT Group configured for multi-talker control.
[R-6.2.3.7.4.1-003]
The priority hierarchy used for granting a request to override an active MCPTT transmission on a group configured for multi-talker control shall contain at least four (4) levels.
[R-6.2.3.7.4.1-004]
The transmitting Participant on an MCPTT Group a group configured for multi-talker control shall be determined by the relative priorities of the Participants and Call type based on priority (e.g., MCPTT Emergency).
[R-6.2.3.7.4.1-005]
Transmission requests of Participants with insufficient relative priority shall be rejected.
[R-6.2.3.7.4.1-006]
The MCPTT Service shall provide a mechanism for Participants, to override an active MCPTT transmission of a transmitting Participant when the priority level of the overriding Participant or Call type based on priority (e.g., MCPTT Emergency) are ranked higher than the priority level of the transmitting Participant or Call type based on priority for an MCPTT Group configured for multi-talker control.
[R-6.2.3.7.4.1-007]
If an authorized Participant overrides an MCPTT transmission, the MCPTT Service shall provide a means of notifying the overridden Participant(s) that the transmission has been overridden for an MCPTT Group configured for multi-talker control.
[R-6.2.3.7.4.1-008]
The MCPTT Service shall revoke the transmit permission of the overridden transmitting Participant on an MCPTT Group configured for multi-talker control.
6.2.4 Call termination p. 40
[R-6.2.4-001]
If a Participant of an MCPTT Group call is pre-empted, the MCPTT Service shall terminate the call or continue the call with an indication to the transmitting Participant that one or more receiving Participants was pre-empted.
[R-6.2.4-002]
If MCPTT User(s) are pre-empted from an ongoing MCPTT call as there is insufficient capacity to support their ongoing participation, the MCPTT Service shall ensure that the MCPTT User(s) receive a notification that they have been removed from the call for reasons of lack of capacity.
[R-6.2.4-003]
The MCPTT Service shall terminate a call after the Hang Time expires.
[R-6.2.4-004]
Void
[R-6.2.4-005]
The MCPTT Service shall provide an indication to the Participants that the call is within a configurable amount of time before the call time limit is reached.
[R-6.2.4-006]
The MCPTT Service shall release the call when the call time limit has been reached.
[R-6.2.4-007]
The MCPTT Service shall provide an indication to the Participants that the call time limit has been reached.
[R-6.2.4-008]
The MCPTT Service shall release an MCPTT Group call if any of the termination conditions are met (e.g., last Participant leaving, second last Participant leaving, initiator leaving) or the minimum number of Affiliated MCPTT Group Members are not present.
6.3 General requirements p. 41
[R-6.3-001]
Void
[R-6.3-002]
Void
[R-6.3-003]
Void
[R-6.3-004]
Void
