PoC is a half-duplex, one-way communication method between participants and implies that one party speaks while the other parties listen; this requires a talk burst control mechanism, also known as floor control. The talk burst control mechanism in OMA PoC is a confirmed request/grant procedure within the PoC server performing the controlling PoC function, insuring that only one user is sending media at a given time. The talk burst control mechanism in OMA PoC forms a second control layer under the SIP layer. But since it has a very tight coupling to the media transfer this control layer is part of the media handling part of the PoC server. The Talk Burst Control Protocol (TBCP) that is used for talk burst control was developed by OMA (see ). The TBCP is based on RTCP APP packets which means that the protocol uses UDP for transport and may use the RTCP port negotiated at PoC session establishment. Seven control messages are required to handle four 'main' talk burst control procedures. The seven TBCP messages and the four 'main' talk burst control procedures are listed below.
• Talk burst Request - A PoC client requests that the PoC server performing the controlling PoC function shall allocate the media resources to his/her device.
• Talk burst Grant - The PoC server performing the controlling PoC function notifies the PoC client that it has been granted the floor and therefore has been granted permission to use the media resource.
• Talk burst Deny - The PoC server performing the controlling PoC function notifies a PoC client that it has been denied permission to use the media resource.
• Talk burst Taken - The PoC server performing the controlling PoC function notifies all PoC clients, except the PoC client that has been granted the floor, that the floor has been granted to another PoC client. Also the identification of the user that has been granted permission to use the media resource is communicated in the message.
• Talk burst Release - A PoC client notifies the PoC server performing the controlling PoC function that it is releasing the media resource, hence moving the PoC server performing the controlling PoC function into the 'Idle' state.
• Talk burst Idle - The PoC server performing the controlling PoC function notifies the PoC clients that no one owns the media resource, that the floor is open/available for users to request.
• Talk burst Revoke - This allows the PoC server performing the controlling PoC function to revoke the media resource from a PoC client. Typically this is used for preemption functionality, but it will also be used by the system to prevent overly long use of the floor resource.
The talk burst request procedure at session initialization. The Talk burst handler will treat the initial SIP INVITE request, derived from pressing the Push-to-talk button, as an implicit Talk burst Request and reply with Talk burst Granted ('start talking indication') or a Talk burst Deny if the floor is already taken in an ongoing session that the PoC client joins. In the case of Talk burst Granted, the Talk burst handler will send Talk burst Taken to all other users currently in the multi-party session. In the case of Talk burst Deny, if the user joins a PoC session during an ongoing talk burst the Talk burst handler will also send a Talk burst Taken message to the joining user to indicate who is talking in the PoC session. There is a slight possibility that two users can request the floor at the same time. In this case, the user of the first Talk burst Request message that reaches the Talk burst handler will get the floor. The Talk burst handler sends a Talk burst Grant message to the PoC client that got the floor and a Talk burst Deny to the PoC client that did not get the floor. It should be noted that in some cases where a PoC client rejoins a group call or is joining a so-called chat session the SIP INVITE request is not treated as an implicit Talk burst Request. But the PoC client is responded to with a TBCP message and in these cases there is a possibility that there is an ongoing PoC communication and thus the initial SIP INVITE request must be replied to with a Talk burst Taken, otherwise if the floor is idle the PoC client will get a Talk burst Idle message.
The talk burst request procedures. In the case when the invited user wants to talk, the user has to request the floor by pressing the Push-to-talk button, forcing the PoC client to send a Talk burst Request message. The Talk burst Request will be accepted if the floor is free and a Talk burst Grant message will be sent to the requesting PoC client. A Talk burst Taken message will be sent to the other PoC clients participating in the PoC session.
The talk burst release procedure. Once a PoC client sends a Talk burst Release message (when the PoC user releases the Push-to-talk button), a Talk burst Idle message will be sent to the other PoC clients participating in the PoC session. The Talk burst handler will repeatedly send Talk burst Idle messages until a Talk burst Request is received or start of a talk burst from a PoC user occurs. The Talk burst handler retransmits the Talk burst Idle packet to the PoC clients in the PoC session, according to exponential back-off in order to save resources over the air as well as in the mobile terminals. The maximum interval is configurable.
The talk burst revoke procedure. A user can control the floor for a limited time period, which is configurable. The Talk burst handler will send a stop talking indication included in a Talk burst Revoke message to a transmitting PoC client when the limit is reached. The Talk burst handler will stop transmitting the audio stream after a configurable time limit. The Talk burst Revoke message will include information about how long the user has to wait until the floor can be requested again.
Figure 8.8 exemplifies the four 'main' talk burst procedures. Beside the seven TBCP messages and four 'main' talk burst procedures there are a number of other TBCP messages and procedures defined to connect PoC clients that are using the pre-established session method (for more information on pre-established sessions, see Section 8.2.4) and to handle the optional feature, queuing of talk burst requests.
Was this article helpful?