poc user plane - stust.edu.tw

Transport Protocols V2.0.6 (2004-06)

Technical Specification

Push-to-Talk over Cellular (PoC) User Plane;Transport Protocols;

PoC Release 2.0;

Comneon, Ericsson, Motorola, Nokia, Siemens

Copyright Notification

No part may be reproduced except as authorized by written permission of the contributing companies.

© Comneon, Ericsson -Motorola - Nokia - Siemens All rights reserved.

Push-to-Talk over Cellular (PoC) User Plane

2 Transport Protocols V2.0.6 (2004-06)

Keywords Push-to-Talk over Cellular (PoC), User Plane,

RTP, Floor control



Contents Foreword ............................................................................................................................................................5 Introduction ........................................................................................................................................................5 1 Scope ........................................................................................................................................................6 2 References ................................................................................................................................................6 3 Definitions and abbreviations...................................................................................................................6 3.1 Definitions ......................................................................................................................................................... 6 3.2 Abbreviations..................................................................................................................................................... 6 3.3 Requirement vocabulary .................................................................................................................................... 7 4 Transport ..................................................................................................................................................7 4.1 UDP ................................................................................................................................................................... 7 4.1.1 Port numbers ................................................................................................................................................ 7 4.2 RTP.................................................................................................................................................................... 7 4.3 RTCP ................................................................................................................................................................. 7 4.3.1 RTCP usage in PoC...................................................................................................................................... 7 4.4 Transport Path.................................................................................................................................................... 8 5 Talk burst control .....................................................................................................................................9 5.1 General............................................................................................................................................................... 9 5.2 Floor control ...................................................................................................................................................... 9 5.2.1 Floor Request Procedure at Talk Session Initialization.............................................................................. 13 5.2.2 Floor Request Procedure ............................................................................................................................ 17 5.2.3 Floor Release Procedure............................................................................................................................. 19 5.2.4 Floor Revoke Procedure............................................................................................................................. 20 5.2.5 Incoming Talk Session in the Early Session Case...................................................................................... 21 5.2.6 Floor control packet types .......................................................................................................................... 22 5.3 Talker identification......................................................................................................................................... 27 5.3.1 Talker identification information in the Controlling PoC server................................................................ 27 5.3.2 Talker identification information in the UE ............................................................................................... 27 5.3.3 Unsuccessful cases ..................................................................................................................................... 28 5.4 Quality feedback.............................................................................................................................................. 29 5.5 Charging .......................................................................................................................................................... 29 5.6 Detection start of a talk burst ........................................................................................................................... 30 5.7 Detection end of talk burst............................................................................................................................... 30 5.7.1 Detection of end of talk burst in a UE........................................................................................................ 30 5.7.2 Detection of end of talk burst in the Controlling PoC server ..................................................................... 30 5.8 Leave/disconnect from an instant talk session using the early session procedure ........................................... 31 6 User plane adaptation .............................................................................................................................31 6.1 General............................................................................................................................................................. 31 6.2 Initialize the media parameters in the UE(s) and the Controlling and Participating PoC servers.................... 32 6.2.1 At the start of the talk session .................................................................................................................... 32 6.2.2 End user enters a talk session..................................................................................................................... 32 6.3 How the transmitting UE chooses the bit rate of the media stream ................................................................. 32 6.4 Adaptation during talk session......................................................................................................................... 33 6.4.1 New end user enters a instant group communication ................................................................................. 33 6.4.2 Link adaptation........................................................................................................................................... 33 7 Timers ....................................................................................................................................................34 7.1 Timers in the Controlling PoC server .............................................................................................................. 34 7.1.1 End of RTP media timer (T1) .................................................................................................................... 34 7.1.2 Stop-talking timer (T2)............................................................................................................................... 34 7.1.3 Floor revoked grace timer (T3) .................................................................................................................. 35 7.1.4 Inactivity timer (T4)................................................................................................................................... 35 7.1.5 Sender report timer (T5)............................................................................................................................. 36 7.1.6 Optional: Receiver report timer (T6).......................................................................................................... 36



7.1.7 Floor idle timer (T7)................................................................................................................................... 36 7.1.8 Floor revoke timer (T8).............................................................................................................................. 36 7.1.9 Retry-after timer (T9)................................................................................................................................. 37 7.2 Timers in the UE.............................................................................................................................................. 37 7.2.1 Floor release timer (T10)............................................................................................................................ 37 7.2.2 Floor request timer (T11) ........................................................................................................................... 37 7.1.8 UE retry-after timer (T12).......................................................................................................................... 38 7.1.9 Talk session BYE timer (T13).................................................................................................................... 38 7.1.10 Optional: UE End of RTP media timer (T14) ............................................................................................ 38



Foreword This Technical Specification has been produced in a collaboration between Comneon, Ericsson, Motorola, Nokia and Siemens.

Introduction This specification contains the procedures, flows and parameters for the Push-To-Talk over Cellular (PoC) media transport and control on the It and Itn interfaces as defined in the reference [2] as required in [1]. The procedures described in this document are between the UE, Participating PoC server function and Controlling PoC server function.

The user plane specification covers:

• The usage of transport protocols such as IP, UDP, RTP and the usage of the proper media payload format (Clause 4)

• The floor control mechanisms (Clause 5)

• The mechanisms for user plane adaptation (Clause 6)

• The timers that reside in the Controlling PoC server and in the UE(s) are defined in Clause 7



1 Scope This document describes the transport protocols for the user plane of the Push-to-Talk over Cellular (PoC) system. All user plane related technical aspects that are specific to a radio access standard (i.e. QoS negotiation, speech coder usage and payload format for the speech coder bits) are covered in a separate document.

This specification specifies the It and Itn interfaces.

This specification is part of PoC release 2.0.

2 References The following documents contain provisions, which through reference in this text, constitute provisions of the present document.

• References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.

• For a specific reference, subsequent revisions do not apply.

• For a non-specific reference, the latest version applies. In the case of a reference to an PoC document, a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1]. Push-to-Talk over Cellular(PoC); User requirements; PoC Release 2.0

[2]. Push-to-talk over Cellular (PoC); Architecture; PoC Release 2.0

[3]. Push-to-talk over Cellular (PoC); Signaling Flows - UE to Network Interface (UNI); PoC Release 2.0

[4]. Push-to-Talk over Cellular (PoC) User Plane; (E)GPRS/ UMTS Specification; PoC Release 2.0

[5]. IETF: User Datagram Protocol, RFC768, August 1980.

[6]. IETF: RTP: A Transport Protocol for Real-Time Applications, RFC3550, July 2003.

[7]. IETF: RTP Profile for Audio and Video Conferences with Minimal Control, RFC3551, July 2003.

[8]. IETF: SIP: Session Initialization Protocol, RFC3261, June 2002.

[9]. IETF: SDP: Session Description Protocol, RFC2327, April 1998.

[10]. Push-To-Talk over Cellular (PoC); Signaling Flows over Network-to-Network (NNI) interface; PoC Release 2.0

3 Definitions and abbreviations

3.1 Definitions Definitions for terms used in this document can be found in [2]..

3.2 Abbreviations Abbreviations for terms used in this document can be found in [2].



3.3 Requirement vocabulary Shall Indicates a mandatory requirement. Should Indicates a recommendation. May Indicates an optional requirement.

4 Transport

4.1 UDP UDP shall be used to transport the media payload that utilizes the application protocol RTP and the RTCP packets that are associated to the PoC session.

UDP is used as specified in [5].

4.1.1 Port numbers RTP/RTCP port-number pairs shall be negotiated using SDP parameters, see [3] and [9]. If the Participating PoC server will be present in the media path, then the Participating PoC server shall provide its RTP/RTCP port number pair for the user plane to the UE and the Controlling PoC server during the SIP session establishment phase (see[10]). If the Participating PoC server will not be present in the media path then, the Participating PoC server forwards to the Controlling PoC server the RTP/RTCP port number pair that it recevied from the UE and returns to the UE the RTP/RTCP port number pair that it received from the Controlling PoC server during the SIP session establishment phase (see [10]).

4.2 RTP The media shall be transported using the Real-time Transport Protocol (RTP) according to [6].

Each UE in a PoC session shall ensure a unique SSRC according to [6].

The media transport shall be compliant with the RTP profile defined in [7].

Since media is not mixed, the CSRC field(s) shall not be used.

4.3 RTCP RTCP shall be supported, details about RTCP are found in [6].

The SSRC field in a RTP packet produced by UE#n shall be identical to the SSRC field in a RTCP packet produced by UE#n.

4.3.1 RTCP usage in PoC The following list concludes the RTCP usage in PoC:

• RTCP BYE shall be used within the early session procedure to indicate the closing of an instant personal talk session or Ad-hoc instant group talk session.

• RTCP APP shall be used for floor control (see Sub-clauses 5.2).

• RTCP RR and SR shall be used for quality feedback (see Sub-clause 5.4), which may be used for user plane adaptation, see Clause 6.

• RTCP SR and RR may be used for charging purposes (see Sub-clause 5.5).



RTCP packets from a UE shall be terminated in the Controlling PoC server. Therefore, the Controlling PoC server shall generate RTCP packets to all members in a talk session. The Controlling PoC server shall not forward quality feedback information (e.g. RTCP SR) from a UE to the other UEs in the PoC-session. Instead it shall calculate own metrics to put in the RTCP SR packets. If the Participating PoC server is in the transport path for RTP packets, it shall be in the transport path for RTCP packets. The Participating PoC server shall forward all RTCP packets between the Controlling PoC server and the UE without change.

4.3.1.1 RTCP compound packets

RTCP packets, other than those used for floor control messages (i.e. SR, RR and BYE packets), shall be RTCP compound packets that must contain the RTCP SDES packet of the sender and a report packet (SR or RR) according to [6] (the report packet may be empty if no transmission has occurred since the last transmission of an report packet).

Floor control messages should not be sent in a compound packet with other RTCP messages, but multiple floor control messages may be sent in a single RTCP packet.

NOTE: The floor control function may be implemented separately from other standard RTCP message processing. By separating the floor control messages, it is easier for the Participating and Controlling PoC servers to forward these messages to the proper handling function.

4.3.1.2 RTCP SDES packets in PoC

The RTCP SDES packet shall contain the CNAME item carrying the URI of the user and may contain the NAME item carrying the display name of the user.

In Sub-clause 6.1 of Reference [6] it is stated that each compound RTCP packet shall include the SDES CNAME except when the compound RTCP packet is split for partial encryption. Since partial encryption is not used in PoC and the controlling PoC server has the ability to issue compound RTCP packets, the controlling PoC server shall have the ability to compile a valid SDES CNAME. According to Reference [6], a system with no user name like the controlling PoC server may include its fully qualified domain name or its IP-number in the CNAME item. Therefore, in PoC the RTCP SDES packets (not used for floor control) generated in the Controlling PoC server shall only contain the CNAME item giving the IP-address of the Controlling PoC server (encoded according to [6]).

4.4 Transport Path All media (RTP) and floor control messages (RTCP) flow through the Participating PoC server (if inserted in the transport path) and are terminated in the controlling PoC server. Floor control and media replication are Controlling PoC server functions. In this document, the PoC server shown in the call flows is the Controlling PoC server. The transport path between the UE and the Controlling PoC server is established on a per session basis (as specified in [3] and [10]). When the session is established, the Participating PoC server normally includes itself into the transport path to relay the RTP and RTCP packets between the UE and the Controlling PoC server and acts as a translator according to [6].



UE ParticipatingPoC Server

ControllingPoC Server

RTP and RTCPRTP and RTCP


Option 1

Option 2RTP and RTCP

RTP and RTCP

UEUE ParticipatingPoC ServerParticipatingPoC Server

ControllingPoC ServerControllingPoC Server



Option 1



Option 1


RTP and RTCP


RTP and RTCP

Figure 1: Transport Path Options

Figure 1 shows the 2 options for the transport path. Option 1 is the case where the Participating PoC server has inserted itself in the transport path. When the transport path includes the Participating PoC server, the Participating PoC server shall forward all RTP and RTCP packets between the UE and the Controlling PoC server, changing only the source and destination IP addresses and ports in IP packets. In option 2, the Participating PoC server has not inserted itself in the transport path. In this case the UE and Controlling PoC server send RTP and RTCP packets directly between them.

5 Talk burst control

5.1 General Talk burst control shall be applied. The talk burst control mechanisms that shall be used are:

• Floor control

• Talker identification

• Quality feedback

• Charging reports

In Sub-clauses 5.6 and 5.7 methods to detect the start of a talk burst and the end of a talk burst are presented. Detection of the start and the end of a talk burst is important for the operation of the speech coder and the scheduling of the RTCP SR and RR transmissions.

5.2 Floor control Floor control will use the RTCP ports (in the UE and PoC servers) negotiated at the SIP session establishment.

In PoC there are four main floor control procedures:

• Floor Request Procedure at Session Initialization



• Floor Request Procedures

• Floor Release Procedures

• Floor Revoke Procedures

For the PoC system, floor control will require seven control messages to ensure singular access to the PoC media resource. This floor control protocol is a confirmed request / grant procedure, insuring that only one user is streaming the PoC media at a given time. These messages consist of the following control methods:

• Floor Idle – The Controlling PoC server notifies the UEs that no one owns the media resource, that the floor is open / available for users to request.

• Floor Release – A UE notifies the Controlling PoC server that it is releasing the media resource. Hence moving the Controlling PoC server into the ”Idle” state.

• Floor Request – A UE requests that the Controlling PoC server shall allocate the media resources to his/her device.

• Floor Grant – The Controlling PoC server notifies the UE that it has been granted the floor and therefore has been granted permission to use the media resource.

• Floor Taken – The Controlling PoC server notifies all UEs, except the UE that has been granted the floor that the floor has been granted to another UE. In the case of early session the Floor Taken is also used as an indication of the beginning of the PoC session for the terminating UE. Also the the real or anonymous identity of the user that has been granted permission to use the media resource is communicated in the message.

• Floor Deny – The Controlling PoC server notifies a UE that it has been denied permission to use the media resource.

• Floor Revoke - Which allows the Controlling PoC server to revoke the media resource from a UE. Typically used for preemption functionality, but will also be used by the system to prevent overly long use of the floor resource.

The transport mechanism of UDP will be used to convey these messages. Within UDP, an RTCP APP payload structure shall be used to convey these seven floor control messages, as discussed in sub-clause 5.2.5. Since the floor control protocol is still built on a request / grant model, application timers (see Clause 7) will be used to manage error conditions. Floor Request should always be responded to by a Floor Grant, Taken or Deny, and Floor Releases should always be responded to by a Floor Idle message.

With the early session procedure Floor Taken should be always responded to by a RTCP BYE, when invited UE does not automatically accept the instant personal talk or Ad-hoc instant group talk (and in that case RTCP BYE packet indicates in the reason for leaving field that this a “Ringing” situation).

Additionally, reliability is ensured in the floor control protocol thru the following techniques thru timer-based retransmissions:

• UEs repeatedly send Floor Releases until Floor Idle or Floor Taken or RTP media packet is received (The floor release timer is defined in Sub-clause 7.2.1).

• UEs repeatedly send Floor Requests until Floor Grant / Taken/ Deny or RTP media packet is received (The floor request timer is defined in Sub-clause 7.2.2).

• With the early session procedure UEs repeatedly send RTCP BYE (the talk session BYE timer is defined in Sub-clause 7.2.4) until the UE notices end of Talk Burst (as defined in Sub-clause 5.7.1).

• The Controlling PoC server repeatedly sends Floor Idles until Floor Request is received from a UE, or Session Expiry (The floor idle timer is defined in Sub-clause 7.1.7).

• The Controlling PoC server repeatedly sends Floor Revokes during a short period of time after the Controlling PoC server has decided to revoke the floor from the user (the floor revoke timer is defined in Sub-clause 7.1.8).

The floor control call flows procedures described below are identical for group calls, with simply more user legs added to the flow, but the signaling methods are identical, with the only exception being that Chat Groups do not have the



same “short” session timers that are used in the group call or one-to-one calls. Chat Groups will have much longer timers to determine that the chat sessions should be torn down.

In Figure 2, Figure 3 and Figure 4 the floor control state transition diagrams for the normal operation in the UE, the general floor operation in the Controlling PoC server and the normal floor operation to a UE in the Controlling PoC server are presented.

U:has no floor

U:requestpending

U:has floor

U:releasepending

R:Grant

S:Request

S:Media

S:Release

R:Deny ORR:Taken ORR:Media

R:Idle ORR:Taken ORR:Media

T11 fired

T10 fired

R:Idle ORR:Taken ORR:Media

R:Revoke ANDStop sending media

U:any statewithout respective

transition

R:Revoke

NOTE: Since the UE “knows” when the floor is not idle, it is also possible for the UE to provide immediate feedback and reject the Floor Request (i.e. not sending any floor request message). It is highly recommended that UEs support this behaviour in the initial implementations.

NOTE: Timer T11 is the floor request timer, while timer T10 is the floor release timer.

Figure 2: UE state transition diagram for normal operation.



G:floor idle

R:Request ANDS:Grant (to granted UE) ANDS:Taken (to all other UEs)

G:floor taken

Timer T7 fired ANDS:Idle (to all UEs)

R:Release (from granted UE)

R:Media (from granted UE) ANDS:Media (to all other UEs)

G:release pending

R:Last media packet ANDS:Idle (to all UEs)

Timer T1 fired ANDS:Idle (to all UEs)

G:revoke pending

Timer T2 fired ANDS:Revoke (to granted UE)

{R: Last media packet ORTimer T3 fired} ANDS:Idle (to all UEs but the revoked one)

R:Media ANDS:Media R:Media AND

S:Media

R:Release(from granted UE)

NOTE: Timer T7 is the floor idle timer, timer T1 is the end of RTP media timer, timer T3 is the floor revoked grace timer and timer T2 is the stop-talking timer.

Figure 3: Controlling PoC server state transition diagram for general floor operation



U:has no floorand floor idle

U:has floor U:revokepending

R:RequestANDS:Grant

R:Media ANDS:Media (to all other UEs)

R:Request ANDS:Deny

R:Release ANDS:Idle

S:Revoke

U:has no floorand floor taken

R:Release ANDS:Taken

R:Release

U:revokewaiting

T9 fired ANDS:Taken

T9 fired ANDS:Idle

R:Request ANDS:Deny

Floor state change

R:Media AND S:Revoke

R:Media AND S:Revoke

U:has no floor but send media

T8 fired

R:Release ANDS:Taken

T8 firedS:Revoke

R:Release ANDS:Idle

T3 fired ORR:Release

R:Media ANDS:Media (to all other UEs)

NOTE: The Controlling PoC Server shall not send to the UE Floor Idle or Floor Taken messages in the revoke waiting state

NOTE: Timer T8 is the floor revoke timer, timer T9 is the retry-after timer and T3 is the floor revoked grace timer.

Figure 4: Controlling PoC server state transition diagram for normal floor operation to the UE.

5.2.1 Floor Request Procedure at Talk Session Initialization This sub-clause defines the floor control procedure of a UE when it is connected to a PoC session.

5.2.1.1 Floor Request procedure with early/late media procedure

The initial SIP INVITE message accepted by the Controlling PoC server is an implicit Floor Request. When the UE sends the initial SIP INVITE it shall go in to the request pending state according to Figure 2; the UE is not allowed to change state until it has received a floor control message from the Controlling PoC server. The UE shall change the state as according to the state diagram (see Figure 2). If the UE receives the Floor Grant, it means that the UE has been granted the floor (Figure 5), if it receives Floor Deny, Floor Taken or RTP media it means that the request has been denied and the UE has not been granted the floor (Figure 6). When the Controlling PoC server has accepted the SIP INVITE it shall act as if it has received a floor request.



NOTE: It is an implementation option that the Controlling PoC server for a chat group may deny the implicit Floor Request and send a Floor Deny followed by Floor Taken or Floor Idle to users when they join the chat group.

UE #1 PoC Server(s) UE #2

SIP session establishment with UE #1

UDP:RTCP:App: Floor Grant

Talker ID Notification

UDP:RTCP:App: Floor Taken ID=#1

Talk Proceed Notification

1

3

2

Press PoC button

A UDP:RTP:media streaming

B

SIP session establishment with UE#2

UDP:RTP:media streaming

Figure 5: Floor Request Procedure at the initialisation of the talk session.

• Step 1 - The Controlling PoC server determines that originating user (using UE#1) may have the floor, and issues Floor Grant message to the requesting UE and Floor Taken message(s) to all other UEs currently in the talk session. The Floor Taken packet containing the talker identification of the user that has been granted the resource (in this case, UE#1) (see Sub-clause 5.3.1).

• Step 2 – When the UE#1 has received Floor Grant and a SDP answer it may provide the user with a Talk Proceed Notification, and the user may begin speaking.

• Step 3 – When the UE#2 has received Floor Taken with the talker identity of the granted user, it may display the identity to the user.

The correlation point A in Figure 5 maps to the correlation point A in Figure 7, Figure 9, Figure 11 and Figure 15.

5.2.1.2 Floor Request procedure with early session procedure

The initial (early session) SIP INVITE message from the UE to the Participating PoC server shall not be treated as an implicit Floor Request.

When the UE sends the initial SIP REFER (to that early session) it shall go in to the request pending state. The UE is not allowed to change state until it has received a floor control message from the Controlling PoC server. The UE shall change the state as according to the state diagram (see Figure 2). If the UE receives the Floor Grant, it means that the UE has been granted the floor (Figure 5), if it receives Floor Deny, Floor Taken or RTP media it means that the request has been denied and the UE has not been granted the floor (Figure 6).

NOTE: For the case of the early session procedure, the boxes labeled SIP session establishment denotes the SIP signaling needed to set-up a talk session (e.g. the SIP REFER and the SIP 2xx response on the originating side, and in the case of early session for UE #2 there is no SIP signaling on the terminating side).

When the Controlling PoC server has accepted the SIP REFER or the SIP INVITE server, it shall act as if it has received a floor request.

• Step 1 - The Controlling PoC server determines that originating user (using UE#1) may have the floor, and issues Floor Grant message to the requesting UE and Floor Taken message(s) to all other UEs currently in the



talk session. The Floor Taken packet containing the talker identification of the user that has been granted the resource (in this case, UE#1) (see Sub-clause 5.3.1).

• Step 2 – When the UE#1 has received Floor Grant it may provide the user with a Talk Proceed Notification, and the user may begin speaking.


5.2.1.3 User joining during an ongoing talk burst

This sub-clause describes what shall happen when a user (UE#2 in Figure 6) joins a group communication during an ongoing talk burst.

PoC Server(s) UE #2

UDP:RTCP:App: Floor Deny

Press PoC Button

Talk RejectNotification2

3

1

Floor Already Granted

talk session establishment with UE#2

RTP Streaming

UDP:RTCP:App: Floor Taken Talker IDNotification

Figure 6: Floor Request Exception: user joins during ongoing talk burst.

• Step 1 - The user presses the PoC button to trigger the talk session establishment for the user and to request the floor.

• Step 2 - The Controlling PoC server denies this request via a Floor Deny. After the Floor Deny message has been sent, a Floor Taken packet containing the talker identity of the user that currently has the floor shall be transmitted (preferably the Floor Taken packet is piggy backed on the Floor Deny packet in a single RTCP packet).

• Step 3 - The UE#2 provides a floor request denied notification and a talker identification notification back to the user.

5.2.1.4 Quick key

This sub-clause describes the concept of quick key, which means that a user presses and then quickly releases the PoC button in order to indicate that the user wishes to start the session by listening instead of talking.




talk session establishment with UE #1

UDP:RTCP:App: Floor GrantTalker ID Notification

UDP:RTCP:App: Floor Idle

PoC Button Released

4

1

Press PoC button


5

UDP:RTCP:App: Floor Idle Floor Idle Notification Floor Idle

Notification

A B

2UDP:RTCP:App: Floor Release3

Figure 7: Floor Request Exception: quick key.

• Step 1 – The user for UE#1 press and releases the PoC button, this triggers a talk session establishment which is handled as a implicit request for the floor by the Controlling PoC server.

• Step 2 –The Controlling PoC server determines that originating user (using UE#1) may have the floor, and issue Floor Grant message and Floor Taken messages to the users in the session.

• Step 3 – When UE#1 receives the Floor Grant message; it shall immediately return a Floor Release message to the Controlling PoC server, without producing and distributing any RTP media.


• Step 5 – Upon receiving the Floor Release message, the Controlling PoC server starts to transmit Floor Idle messages to all members in the talk session. Upon receiving the Floor Idle message the UEs in the session provides a notification to the user that the floor is now idle.


5.2.1.5 Floor control message from the Controlling PoC server is lost

The floor control message (the Floor Grant in the normal case in Figure 5) from the Controlling PoC server may be lost. Therefore, the UE shall start the Floor Request timer (see Sub-clause 7.2.2) immediately after the talk session is established and hence start to periodically send Floor Request messages until a floor control message from the Controlling PoC server is received.

If the Floor Request timer expires while the user still is holding down the PoC button and the UE has not received a Floor Grant, Floor Taken or Floor Deny message, RTP media packets or RTCP packets from the Controlling PoC server, then a new Floor Request message is sent. In the case where the Floor Taken message is missed, the UE receives and replays the RTP media packets normally.



PoC Server(s) UE #2

UDP:RTCP:App: Floor Request

Press PoCButton

talk session establishment with UE#2

A

Figure 8: Floor Request Exception: floor message from Controlling PoC server is lost.

5.2.2 Floor Request Procedure

5.2.2.1 Floor Requested with Floor Idle

In the Figure 9 below, a Floor Request procedure is demonstrated. The initial conditions are that the Floor is in the idle state, with no users currently owning the media stream.


Floor Idle

UDP:RTCP:App: Floor Request

Press PoC Button

UDP:RTCP:App: Floor Grant Talker ID Notification

UDP:RTCP:App: Floor Taken ID = #1


1

45

2

3 A

Figure 9: Floor Request Procedure – One-to-One Call.

• Step 1 - The UE#1 presses the PoC button, which will generate a Floor Request message from the UE to the Controlling PoC server and start the ‘floor request timer’ (see Sub-clause 7.2.2). If the ‘floor request timer’ expires while the user still is holding down the PoC button and the UE has not received a Floor Grant, Floor Taken or Floor Deny message, RTP media packets or RTCP packets from the Controlling PoC server, then a new Floor Request message is sent. In the case where the Floor Taken message is missed, the UE receives and replays the RTP media packets normally.

• Steps 2/3 - The Controlling PoC server determines that UE#1 may have the floor (the resource is available), and issues Floor Grant and Floor Taken messages in steps 2 and 3. The Floor Taken message containing the talker identification of the user that has been granted the resource (in this case, User #1). The Floor Request is



sent periodically by UE#1 until a Floor Grant response is received by UE#1 and this is managed by the floor request timer, see Sub-clause 7.2.2.

• Step 4 - In step 4, the talker identification of the granted user is provided to the listening party, and is provided to the UE user.

• Step 5 - The user for UE#1is provided a Talk Proceed Notification, and the user may begin speaking.


5.2.2.2 Floor Requested with Floor Already Granted

In this procedure, the floor is already granted to a user on the call. A user (UE#2) attempts to request the floor that is already allocated. UE#2 may also be receiving RTP stream while making the request. In Figure 10 this case is illustrated.

PoC Server(s) UE #2

UDP:RTCP:App: Floor Requested


Press PoCButton

Talk RejectNotification

RTP Streaming

2

3 4

1

Floor AlreadyGranted

Figure 10: Floor Request Exception – Floor Already Granted.

• Step 1 - The user presses the PoC button to request the floor.

• Step 2 - The UE#2 client makes a Floor Request for the floor to the Controlling PoC server.

• Step 3 - The Controlling PoC server denies this request via a Floor Deny response (the Floor Request is periodically sent until a Floor Deny or Floor Taken or RTP media packet response is received by UE#2 and this is managed by the floor request timer, see Sub-clause 7.2.2).

• Step 4 - The UE#2 provides a floor request denied notification back to the user.

While this error case is shown and must be supported by the Controlling PoC server, it is also possible for the UE to provide immediate feedback and reject the floor request in the UE since the UE “knows” that the floor is not “Idle”. It is highly recommended that UEs support this behaviour in the initial implementations. In the future, it may be possible to request the floor when it is already granted, in order to allow pre-emption mechanisms to be supported in the Controlling PoC server.

5.2.2.3 Nearly Simultaneous Floor Requested with Floor Idle (Informative)

In the second case in Figure 11, the Floor is idle, but two users request the floor at nearly identical times. The Controlling PoC server processes the Floor Requests in a First Come First Served (FCFS) manner.




Floor Idle


UDP:RTCP:App: Floor Taken ID = #1

Press PoC Button

Talk Denied Notification



Press PoC Button


1 3 2

4

5

6

8

9


7Talker ID

Notification 10

A

Figure 11: Floor Request Exception – Nearly Simultaneous Floor Request.

• Steps 1/2 – Users press the PoC buttons on their devices at nearly the same time.

• Steps 3/4 – UE#1 and UE#2 send Floor Request messages to the Controlling PoC server.

• Steps 5/6 – The Controlling PoC server determines that UE#1 Request was received before UE#2 request, and provides a Floor Grant to UE#1 and a Floor Taken to UE#2 that UE#1 won the floor request.

• Step 7 – The Controlling PoC server sends a Floor Deny to UE#2, formally notifying UE#2 that it’s request was denied. UE#2 also can infer this from the Floor Taken with the talker identification indicating that another user obtained the floor (or by receiving RTP from another user). The Floor Deny message is required to insure that other race conditions are closed, where the floor was either Idle or Granted.

• Step 8 – The user for UE#1 is notified that it was granted the floor.

• Steps 9/10 – The user for UE#2 is notified that it was denied the floor, and the talker identification of the granted user.


5.2.3 Floor Release Procedure This sub-clause defines the floor release procedure, as shown in Figure 12. It is assumed that UE#1 owns the floor, and is releasing the media resource back to the Controlling PoC server.




FloorGranted

UDP:RTCP:App: Floor Release

Release PoC Button

UDP:RTCP:App: Floor IdleFloor Idle Notification

UDP:RTCP:App: Floor Idle Floor Idle Notification

1

46

3

5

RTP : Last Burst PacketRTP : Last Burst Packet 2

7

Figure 12: Floor Release Procedure.

• Step 1 – The User stops talking and releases the PoC button.

• Step 2 – The UE#1 stops the encoding of speech and determines the sequence number of the last RTP packet in the talk burst that where produced.

• Step 3 - UE#1 signals to the Controlling PoC server that it is releasing the floor via the Floor Release message. In that message the sequence number of the last RTP packet shall be included by the UE. As an option the Controlling PoC server may therefore decide which RTP packet that are the last in the talk burst and will therefore not discard RTP-packets that may arrive later than the Floor Release packet.

• Steps 4/5 - The Controlling PoC server indicates to both the UE#1 and UE#2 that the floor is idle. UE#1 uses the Floor Idle message as an acknowledgement to the Floor Release message sent previously. UE#2 client provides a Floor Idle Notification to the user. The Floor Release message is sent periodically by UE#1 to the Controlling PoC server until UE#1 receives a Floor Idle message (the floor release timer is described Sub-clause 7.2.1).

• Steps 6/7 – The UE clients notify the users that the floor is now open.

5.2.4 Floor Revoke Procedure The Floor Revoke procedure is expected to be used in the following cases;

• The Controlling PoC server has determined that the talker has had the floor too long (see the stop-talking timer in Sub-clause 7.1.2), or

• The Controlling PoC server is pre-empting the user from the floor (in support of pre-emption service in later releases).

These are examples of the need for the procedure, and is not an exhaustive list. In this flow it is assumed that the UE#1 has the floor. Some event is triggered in the Controlling PoC server such that the Controlling PoC server requires to revoke the floor from the UE. The order of these steps are not ensured due to the parallel nature of the service. So the steps for the floor revoke procedures are the following;




Floor Granted

UDP:RTCP:App: Floor Revoke

Floor IdleNotification


Floor RevokedNotification

1

3

4

52

UDP:RTCP:App: Floor IdleFloor IdleNotification6

UDP:RTCP:App: Floor Release1a


Floor Granted

UDP:RTCP:App: Floor Revoke

Floor IdleNotification


Floor RevokedNotification

1

3

4

52

UDP:RTCP:App: Floor IdleFloor IdleNotification6

UDP:RTCP:App: Floor Release1a

Figure 13: Floor Revoke Procedure.

• Step 1 – The Controlling PoC server sends a Floor Revoke to the UE#1. The Controlling PoC server will provide a ’grace timer’ (the floor revoked grace timer in Sub-clause 7.1.3), after which the media will be terminated for that user. The Controlling PoC server will continue to send Floor Revokes during a short time period (using the floor revoke timer in Sub-clause 7.1.8) The Controlling PoC server may determine that UE#1 abuses the service and shall therefore not be allowed to gain access to the floor until a certain amount of time have expired. In that case a retry-after timer associated with UE#1 is started (see Sub-clause 7.1.9). The amount of time that UE#1 cannot be granted the floor may be sent as additional information in the Floor Revoke packet (see Sub-clause 7.2.3).

• Step 1a (optional) – The UE may send a Floor Release message before the ’grace timer’ expires.

• Step 2 – When the Floor Release is received from UE#1 or the ‘grace timer’ expires, the Controlling PoC server sends the Floor Idle to all other users and the floor is “revoked” from the UE#1. If a Floor Release is not received from UE#1, the Controlling PoC server will ruthlessly revoke the media without an acknowledgement from the UE.

• Step 3 – The UE#2 notifies the user that the floor is now Idle.

• Step 4 – The UE#1 notifies the user that the floor has been revoked, so the user may back off the PoC button.

• Step 5 – The Floor Idle or Floor Taken may be provided to the UE#1 that has been revoked. The Floor Idle may delayed by the Controlling PoC server, to allow other users to gain access to the service, but this is at the discretion of the vendor implementation.

• Step 6 – The UE#1 provides a notification to the user that the floor is now again Idle/Taken.

5.2.5 Incoming Talk Session in the Early Session Case This sub-clause defines the incoming talk session indication in the case that the terminating party has made an early session, as shown in Figure 14:. It is assumed that UE#1 initiates the PoC session as described in the Signaling Flows [3] and the UE#2 has made an early session as described in the Signaling Flows [3].



UE #1 PoC Server UE #2

SIP session establishment with UE #1


Talker ID Notification



1

4

2

Press PoC button

A

UDP:RTP:media streaming 3

SIP session establishment with UE#2

UDP:RTP:media streaming

Figure 14: Incoming talk session in the case of Early Session.

• Step 1 – The PoC server sends the Floor Grant message to the inviting UE#1 as described in sub-clause 5.2.1.2.

• Step 2 – The UE#1 may give the Talk Proceeded Notification to the user #1 as described in sub-clause 5.2.1.2.

• Step 3 – The PoC server sends the Floor Taken message(s) to all invited UEs (=UE#2) as an indication of the incoming talk session.

• Step 4 – When he UE#2 has received the Floor Taken message, it may indicate to the user #2 that there is an incoming talk burst and the UE#2 may give a Talker ID Notification showing the identity of the inviting user.

5.2.6 Floor control packet types RTCP APP packet shall be used to send floor control messages.

The RTCP APP packet is depicted below. The definition of the fields in the RTCP APP packet is found in [6].

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| subtype | PT=APP=204 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | name (ASCII) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | application-dependent data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The length field in the RTCP header is the length of the packet in 32-bit words, not counting the first 32-bit word in which the length field resides.

The 4-byte ASCII string in the RTCP header shall be used to define the set of PoC floor control packets to be unique with respect to other APP packets that the application might receive.

For PoC the ASCII name string shall be: PoC1.

The use of application dependent data is described in the following sub clauses.

There exist 7 packet types for floor control messages:

• Floor Request

• Floor Grant



• Floor Taken

• Floor Deny

• Floor Revoke

• Floor Release

• Floor Idle

The floor control packet type identifier is included in the subtype field.

5.2.6.1 Floor Request

Floor Request is a request from a participating UE to get permission to transmit a talk-burst.

The following bit pattern in the subtype field shall be used for Floor Request: 00000.

No valid application-dependent data is defined for Floor Request for this version of PoC. Therefore, the Floor Request packet shall only consist of the mandatory 12 bytes of header information and the length field shall be set to two.

The SSRC field shall carry the SSRC of the UE that requests the floor.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|0 0 0 0 0| PT=APP=204 | length=2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of UE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | name=PoC1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.6.2 Floor Grant

An action from the Controlling PoC server to inform the requesting UE that it has been granted the floor.

The following bit pattern in the subtype field shall be used for Floor Grant: 00001.

No valid application-dependent data is defined for Floor Grant for this version of PoC. Therefore, the Floor Grant packet shall only consist of the mandatory 12 bytes of header information and the length field shall be set to two.

The SSRC field shall carry the SSRC of the Controlling PoC server.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|0 0 0 0 1| PT=APP=204 | length=2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of Controlling PoC server | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | name=PoC1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.6.3 Floor Taken

An action from the Controlling PoC server to inform non-requesting UE(s) that someone has been granted the floor.

Using the early session procedure, the Floor Taken informs the UE that it has been invited to a new instant personal talk session or Ad-hoc instant group talk session by an inviting user (i.e. by the granted user).

The following bit pattern in the subtype field shall be used for Floor Taken: 00010.



In the application dependent data, the Floor Taken shall carry two SDES items, namely the CNAME item and the NAME item to identify the UE that has been granted the floor. Therefore the length of the packet will vary depending on the size of the SDES items..

The CNAME identifier shall carry the URI of the user that has been granted the floor, while the NAME identifier shall carry the display name of the user that has been granted the floor. The SDES items and the proper encoding of the URI and the display name are described in [6]. If this is an anonymous chat group, the CNAME and NAME will be given unique anonymous names as defined in sub-clause 5.3.1.


0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|0 0 0 1 0| PT=APP=204 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of Controlling PoC server | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | name=PoC1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SDES item CNAME followed by SDES item NAME | : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.6.4 Floor Deny

Sent as an action from the Controlling PoC server to the requesting UE to inform that the floor request was denied.

The following bit pattern in the subtype field shall be used for Floor Deny: 00011.

Application-dependent data for Floor Deny includes a reason code possibly followed by a text-string (reason phrase) describing why the floor was denied. Therefore the length of the packet will vary depending on the size of the application dependent field.


0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|0 0 0 1 1| PT=APP=204 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of Controlling PoC server | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | name=PoC1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason code | Length | Reason Phrase | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The first 8 bits in the application-dependent data field is used for the reason code.

The length field gives the length of reason phrase in bytes. If the length field is set to 0, there is no reason phrase and the 16 bits after the length field shall be set to zero.

The Reason Phrase field may contain a text string with additional information. The text string shall use the same encoding as the text strings in the SDES item CNAME (see Ref. [6]):

5.2.6.4.1 Reason codes

5.2.6.4.1.1 Floor already in use

Indicates that the floor is already granted to another user.



The reason code shall be: 1 (decimal value).

5.2.6.4.1.2 Internal Controlling PoC server error

Indicates that the Controlling PoC server cannot grant the floor request due to an internal error.


5.2.6.4.1.3 Only one participant in the group

Indicates that the Controlling PoC server cannot grant the floor request, because the requesting party is the only participant in the group.


NOTE: As a response to the floor request message the Controlling PoC server may send a floor deny (only one participant) message or accept the request by a floor granted message and revoke the floor later, if no additional participants join the call. In the beginning of the group session, sending the floor deny in the case of only one participant is not always useful.

5.2.6.5 Floor Release

Sent as an action from the granted UE to the Controlling PoC server to release the floor.

The following bit pattern in the subtype field shall be used for Floor Release: 00100.

The application-dependent data field consists of 4 octets. The first 16 bits is the sequence number of the last RTP-packet in the talk burst. The last 16 bits in the application-dependent data field is padding and are set to zero.

Therefore, the length field shall be set to three.

The SSRC field shall carry the SSRC of the granted UE that wants to release the floor.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|0 0 1 0 0| PT=APP=204 | length=3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of granted UE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | name=PoC1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |sequence number of last packet | padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.6.6 Floor Idle

Sent as an action from the Controlling PoC server to participating UEs signaling that the floor is idle.

The following bit pattern in the subtype field shall be used for Floor Idle: 00101.

No valid application-dependent data is defined for Floor Idle for this version of PoC. Therefore, the Floor Idle packet shall only consist of the mandatory 12 bytes of header information and the length field shall be set to two.


0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|0 0 1 0 1| PT=APP=204 | length=2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of Controlling PoC server | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | name=PoC1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



5.2.6.7 Floor Revoke

Floor Revoke is sent from the Controlling PoC server to the granted UE to remove the floor.

The following bit pattern in the subtype field shall be used for Floor Revoke: 00110.

The application-dependent data field shall carry a reason code for why the floor has been revoked. Also additional information can be carried in the message, therefore the length of the packet may vary depending on the reason code.


0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|0 0 1 1 0| PT=APP=204 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of Controlling PoC server | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | name=PoC1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reason code | additional information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2.6.7.1 Reason codes

The first 16 bits in the application-dependent data field is used for the reason code. Thereafter additional information is added. Depending on the reason code, the number of octets conveying additional information differs.

5.2.6.7.1.1 Only one user

Indicates that the granted UE is the only UE in the session.


No additional information shall be included. Hence, the first 16 bits in the additional information field shall be populated with zeros.

5.2.6.7.1.2 Talk burst too long

Indicates that the user has talked too long, i.e. the stop-talking timer (Sub-clause 7.1.2) has expired.


As additional information the packet carry a retry-after field where the 16 bits in the additional information field is an integer number giving the time in seconds when the connection is anticipated to be available again. The timer length should be a few seconds longer than the timer value for the retry-after timer in the Controlling PoC server (Sub-clause 7.1.9).

Thus, a UE that receives a Floor Revoke with a retry-after field that is non-zero, should not try to transmit anything before the time given in the additional information field has expired. Therefore, a retry-after timer in the PoC client is needed, see Sub-clause 7.2.3.

NOTE: The retry-after timer functionality in the Controlling PoC server and in the UE is used to prevent a user to immediately re-take the precedence in the Controlling PoC server after the user has talked too long and received a Floor Revoke packet.

5.2.6.7.1.3 No access to floor

Indicates that the user has no access to the floor even though the UE is in the “has floor state” and transmits media.

Temporary loss of coverage for the granted UE may result in this case of different states in the UE and the PoC server. This happens when the loss of coverage is longer than the timer value of the “End of RTP media timer” (see Sub-clause 7.1.1).



If the floor is idle when the UE comes back to coverage and transmits speech, the PoC server shall send a Floor Revoke packet to the UE indicating that the UE has no access to the floor. If another user has been granted the floor when the UE comes back to coverage and transmits speech, the PoC server shall send a Floor Revoke packet to UE indicating that the UE has no access to the floor.


No additional information shall be included. Hence, the first 16 bits in the additional information field shall be populated with zeros.

5.2.6.8 Subtype bit pattern reserved for future use

The bit patterns representing 7 to 31 in decimal values (00111 through 11111) in the subtype field is reserved for future use.

5.3 Talker identification This sub-clause describes the procedures for handling the talker identity.

5.3.1 Talker identification information in the Controlling PoC server This sub-clause describes the procedure for the Controlling PoC server to collect the information about talker identification.

The identities of the users engaged in the talk session are collected by the Controlling PoC server in the process of establishing the SIP sessions with the UEs, including the initiators identities, which was received in the initial SIP INVITE. The Controlling PoC server shall keep a list of all participants’ identities including their SIP URI and display name. The Controlling PoC server shall also record the SSRC of the UE associated to the user. If this is an anonymous chat group, the Controlling PoC server will create a unique anonymous NAME and CNAME for each user. This identity will be used in the Floor Taken messages.

The Controlling PoC server includes the identity of the user who has been granted the floor in the Floor Taken message (see Sub-clause 5.2.6.3). In the Floor Taken message SDES items with of the users URI as well as the users display name is carried.

The SSRC becomes known to the Controlling PoC server when:

• It receives RTP media from the UE,

o At Correlation point B in Figure 5 in Sub-clause 5.2.1.

• Or it receives a floor control message or a RTCP compound packet from the UE,

o At Correlation point B in Figure 7 in Sub-clause 5.2.1.4.

o At Correlation point A in Figure 8 in Sub-clause 5.2.1.5.

o At the next Floor Request procedure (see Sub-clause 5.2.2) if the floor was denied due to the fact that the user tried to join the session during a talk burst (see Sub-clause 5.2.1.3).

The Controlling PoC server shall preserve the SSRCs in the RTP media packets from the UEs to allow the UEs to use this information to identify the user in case of Floor Taken message is lost.

5.3.2 Talker identification information in the UE This sub-clause describes the procedure in the UE for identifying the talking user in the talk session.

The UE shall receive the real or anonymous identity of the user that has been granted the floor in the Floor Taken message and it may display this information to the user. The UE may collect information about the other users, their identities and the SSRCs used by their UEs in order to be able to map a RTP media packet (with SSRC) in case the Floor Taken message is lost.



If the UE collects information about the other users, it should keep itself updated with the information provided by the Controlling PoC server. It should for instance store the latest mapping between user identity and SSRC.

UEPoC Server(s)

A1. RTCP: APP: Floor Taken

2. RTP: media streaming

NOTE: The signaling flow may be repeated for each participant in the talk session.

Figure 15: Identifying talking user in the UE.

1. At correlation point A the UE shall receive a Floor Taken message. This message shall include the talker identity of the user that has been granted the floor.

2. If the UE has no mapping between the received talker identity and the SSRC of the received RTP media, or the UE discovers that the SSRC of the UE that transmits media has changed, the UE may store the mapping between the received talker identity and the SSRC.


5.3.3 Unsuccessful cases

5.3.3.1 SSRC mapping not available

If the Floor Taken message is lost and the UE has no mapping between the talker identity and the SSRC the UE is not able to determine the identity of the user whose RTP media it is receiving. In this case the user identity is not shown.

5.3.3.2 SSRC collision

When a UE receives a RTP media with the same SSRC as its own, the UE shall conclude that there is a SSRC collision.

If a SSRC collision occurs, the UE shall behave as described in Reference [6]. This means that the UE shall transmit a RTCP BYE packet with the old SSRC in a compound packet with a SDES packet containing the new SSRC of the UE (and a report packet), the CNAME item and possibly the NAME item according to Sub-clause 4.3.1.2. The RTCP BYE packet shall not carry any reason for leaving string.

The Controlling PoC server shall receive the RTCP BYE and remove the mapping between the old SSRC and the talker identity. The Controlling PoC server should not propagate the RTCP BYE to the other UEs in the talk session. The



Controlling PoC server shall recreate the mapping using the SDES packet or as per Sub-clause 5.3.1. The UE should recreate the mapping as per Sub-clause 5.3.2.

5.4 Quality feedback RTCP SR and RR shall be used for quality feedback as defined in [6] with the following modifications.

A RTCP SR shall be sent by the UE to the Controlling PoC server when releasing the floor.

When detecting end of talk burst (see Sub-clause 5.7), the Controlling PoC server should send a single RTCP SR to all UEs, except the UE that previously was granted the floor.

Upon detection of a RTCP SR from the Controlling PoC server the UE shall send a single RTCP RR to the Controlling PoC server. When the floor is idle, the UE should not send periodic RTCP RRs.

Hence, RTCP SR and RR in PoC shall not be sent periodically and shall not be sent during a talkburst.

The Controlling PoC server shall not send RTCP RR to the UEs.

The Controlling PoC server shall use the sender report timer to decide if the RTCP SR is lost (see Sub-clause 7.1.5).

The RTCP SR sent from the UE to the Controlling PoC server give information about the RTP packet transmission to the Controlling PoC server.

The RTCP SR sent from the Controlling PoC server to the UE(s) give information about the RTP packet transmission from the Controlling PoC server to the UE and the receiver statistics (in the report block) of the last transmission from the UE to the Controlling PoC server (monitors the UE(s) UL).

The RTCP RR sent from the UE(s) to the Controlling PoC server give receiver statistics about the RTP packet transmission from the Controlling PoC server to the UE (monitors the UE(s) DL).

Quality feedback may be used for user plane adaptation (see Clause 6).

The RTCP SR and RR may also be used for charging (see Sub-clause 5.5).

RTCP SR shall be sent in a RTCP compound packet according to Sub-clause 4.3.1.1.

UE #1User plane

RTP mediaEnd user releases the PoC button

PoC server(s)UE #1Signaling plane

UE #2Signaling plane

UE #2User plane

Floor ReleaseRTP media

Floor Idle End of talk indication

RTCP RR

RTCP SRRTCP SR

Figure 16: RTCP SR and RR for quality feedback and for charging.

5.5 Charging RTCP RR and SR packets may be used for charging purposes. The RTCP SR packet shall be sent by the UE that sent RTP media and the RTCP RR packet shall be sent by the UE(s) that receive RTP media.



The RTCP RR packet shall be sent immediately after the UE(s) has detected the reception of a RTCP SR. The Controlling PoC server may have a receiver report timer that is used to decide if the RR packet is lost, see Sub-clause 7.1.6. This timer may be used to find out if a UE constantly do not send RR because of, for instance, fraud.

NOTE: The user plane flow for charging is shown in Figure 16.

5.6 Detection start of a talk burst The start of a talk burst is detected when a floor taken packet is received. If the floor control packet is lost, the M-bit in combination with the SSRC may be used to detect start of a talk burst.

A talk burst start is detected by a talk burst end followed with a combination of the M-bit set to one and a new SSRC.

NOTE: The M-bit shall be used, according to [6] and [7] to indicate talk spurt start (see Sub-clause 3.1 for definitions of talk burst and talk spurt) and a talk burst may contain several talk spurts.

If SSRC is the same as in previous talk burst, the new talk burst shall be identified by the M-bit in combination with the detection of the end of previous talk burst.

Upon detecting the start of the talk burst, the speech codec in the receiving UE(s) shall be reset before the decoding starts. This ensures correct states in the encoder and the decoder.

NOTE: For AMR, the M-bit will also be set for the first RTP packet as a consequence of the VAD/DTX (Voice Activity Detection / Discontinuous Transmission) -functionality and usage of the AMR payload format, see Sub-clause 5.1.2.1. Hence, no extra functionality needs to be implemented. For other codecs or other payload formats, the setting of the M-bit may need to be explicitly implemented.

5.7 Detection end of talk burst

5.7.1 Detection of end of talk burst in a UE Talk burst end is detected when the UE that currently are receiving RTP media and:

• The UE receives a Floor Idle packet (Sub-clause 5.2).

• The current RTP media stream stops and the UE receives a Floor Grant, a Floor Taken, or an RTCP SR packet from the Controlling PoC server (before having received a Floor Idle packet).

• The UE receives RTP media with a new SSRC.

When detecting end of talk burst the speech codec in the receiving UE(s) should be reset. This ensures correct states in the encoder and the decoder.

NOTE: Reset of a speech codec is a procedure in which the internal state variables of the codec are set to their defined initial values.

When receiving RTCP SR, the receiving UE(s) shall transmit a RTCP RR packet to the Controlling PoC server (see Sub-clauses, 5.4 and 5.5).

5.7.2 Detection of end of talk burst in the Controlling PoC server • Talk burst end is detected when the Controlling PoC server receives a Floor Release packet (see Sub-clause

5.2.3), an RTCP SR packet, or an RTCP BYE message.

• The ‘end of RTP media timer’ expires (see Sub-clause 7.1.1).



5.8 Leave/disconnect from an instant talk session using the early session procedure

This sub-clause describes the UE-to-Controlling PoC server and Controlling PoC server-to-UE procedures for leaving an instant personal talk session or an ad-hoc instant group talk session created when the UE use the early session procedure.

The UE shall indicate that the user leaves the instant personal talk or Ad-hoc instant group talk by sending a RTCP compound packet containing a BYE packet to the Controlling PoC server.

The Controlling PoC Server may force to disconnect a participant of an instant personal talk or Ad-hoc instant group talk by sending a RTCP compound packet containing a RTCP BYE packet (for example after an inactivity timer has been expired)

RTCP BYE packet shall indicate, on reason for leaving field, that this a disconnect transaction by inserting the string:

“Disconnect talk session”

NOTE: The citation marks, “”, shall not be inserted in the reason for leaving field.

The encoding of the string is described in [6].

6 User plane adaptation The UE can have knowledge about its own media capability (e.g. its own throughput). This information may be found from the QoS attributes in the UL and DL packet data session context.

However, initially the UE does not know the media capability of the other UE(s) in the session. Therefore, all UEs shall report its media capability to the Controlling PoC server that shall keep a record (the media capabilities list) of the media parameters of all UEs that are registered. The media capability of a UE is reported either in the SIP session establishment (for early session, this is during the initial SIP INVITE transaction. For an on-demand session, this is during the SIP INVITE transaction that establishes the talk session) or when performing a SIP re-INVITE or when performing a SIP UPDATE (see [3]).

In order to be able to guarantee a certain level of quality for the PoC service, an initial agreement shall be made between all involved UEs and the Controlling PoC server about the media parameters that should be used in the session, (e.g. the negotiation should make all members of the session adapt to the common lowest denominator in terms of bandwidth usage).

If RTP media is sent with a higher bit rate than the available bandwidth of the radio link, the result is lost IP-packets (due to the fact that transmission buffers fills up and when the buffers are completely filled data is dropped). The dropped data results in reduced perceived quality of the service. In these situations the media capabilities that were agreed upon, may need to be updated.

A reduction of the bit rate of the RTP media stream should be obtained by increasing the number of frames packetized in a RTP packet. Note that this operation increases the transmission delay in the service, which also reduces the perceived quality of the service.

6.1 General Only the media capability of the UEs downlink shall be reported to the Controlling PoC server.

Media capabilities of the UEs shall be reported to the Controlling PoC server by using SIP/SDP messages (which contains a set of media parameters).

The bullet list below shows the recommended media parameters (see definitions of the media parameters in Sub-clause 3.1) for PoC clients using the AMR codec:

• mode-set

• maxptime



• ptime

The Controlling PoC server shall determine a set of preferred media parameters that should be used in the talk session. The preferred media parameters should be the media parameters of the UE with the lowest media capability (throughput) in its downlink, which has joined into the talk session.

The Controlling PoC server shall report the set of preferred media parameters to the UEs in the talk session in a SIP/SDP payload.

User plane adaptation during a talk session (e.g. a change of the initially agreed media parameters, see Sub-clause 6.4) is optional in both UE and Controlling or Participating PoC server.

User plane adaptation may be triggered by roaming, due to poor QoS (obtained from the metrics measured for the RTCP SR and RR reports) or may be triggered when a new user enters the session.

NOTE: The user plane adaptation (e.g. the adaptation of media parameters) is meant to be slow, e.g. only a few changes of the media parameters should happen during a talk session.

6.2 Initialize the media parameters in the UE(s) and the Controlling and Participating PoC servers

6.2.1 At the start of the talk session Before the UE has reported its downlink media capabilities to its Participating PoC server, the media capabilities list shall be initialized with initial media capabilities.

The initial media capabilities may be based on subscription data, previously logged media capabilities or default values determined by the operator.

6.2.2 End user enters a talk session

6.2.2.1 Inviting user

When the inviting user joins a talk session, the UE shall notify its Participating PoC server about its media capability in the downlink by transmitting its media parameters as SDP parameters in the SIP INVITE message. The Participating PoC server will either forward this directly to the Controlling PoC server or make changes to include the Participating PoC server in the transport path.

The Controlling PoC server responds with a SIP 200 OK that contains a SIP/SDP payload that reports the granted media parameters that should be used by the UE. The Participating PoC server will either forward this directly to the UE or make changes to include the Participating PoC server in the transport path.

6.2.2.2 Invited user

If the Controlling PoC server invites the end user, the SIP INVITE from the Controlling PoC server to the Participating PoC server contains the SDP payload with the granted media parameters. The Participating PoC server will either forward this directly to the UE or make changes to include the Participating PoC server in the transport path.

The invited user(s) media capability is reported to its Participating PoC server in the SIP 200OK. The Participating PoC server will either forward this directly to the Controlling PoC server or make changes to include the Participating PoC server in the transport path.

6.3 How the transmitting UE chooses the bit rate of the media stream

The UE that is about to transmit will know the granted media capability (signaled by the Controlling PoC server). This UE may also know the media capability of its UL (for instance from the QoS attributes for its UL).



The UE shall choose the media parameters that correspond to:

MIN(its own UL media capability, the granted media capability)

where MIN denotes the minimum of in terms of bandwidth usage.

6.4 Adaptation during talk session

6.4.1 New end user enters a instant group communication The new UE sends a SIP INVITE or SIP 200OK (depending on the end user is an invited user or a inviting user, see Sub-clause 6.2.2) with SIP/SDP payload that reports the initial DL media capability of the UE to the Controlling PoC server.

The determination of media parameters in the Controlling PoC server should take into account the minimum DL media capabilities provided by both the new and the existing members in the group (e.g. the negotiation procedure should make all members of the group session adapt to the common lowest denominator in terms of bandwidth usage).

In the case that the media parameters of the new member force the Controlling PoC server to update all other group members, this shall done by a re-INVITE (SIP INVITE or SIP UPDATE) from the Controlling PoC server to all UEs in the group.

UE #1User plane

First talk request in the talk session (inviting user)


AB


UE #2User plane

Start listening indication

Media parameters

Media parameters

Figure 17: Media parameters are transmitted in the signaling plane when a new end user (UE #1) enters the talk session. In this case the Controlling PoC server updates the other member(s) of the talk session.

Correlation point A maps to correlation points A in Figure 29 and correlation point B maps to correlation point B in Figure 43 in PoC signaling flows (Ref. [3]).

6.4.2 Link adaptation RTCP SR and RR should be used to provide feedback on the quality of the data transmission. This functionality gives the Controlling PoC server and the UE(s) a possibility to adapt the media parameters if the frame loss rate in a link becomes high.

If a RTCP SR or RR packet is lost, no recovery process shall be initiated for the user plane adaptation. Hence, user plane adaptation shall only be performed upon successful reception of a SR or RR packet.

If the UE or the Controlling PoC server negotiates a new set of media parameters due to poor quality of reception, the UE or Controlling PoC server, after a while (if the quality of reception is good), may try to upgrade the media parameters back to the previous granted media parameters by using SIP INVITE or SIP UPDATE.

If the codec rate is to be changed two different methods are possible to use. Either is SIP signaling or in-band signaling, using the Codec Mode Request (CMR) field used to inform the clients that are currently receiving a media stream that they should use the new codec mode the next time they start transmitting (see [4]).



6.4.2.1 Uplink adaptation

The Controlling PoC server may monitor the UEs uplink (UL) capacity.

If the UEs UL has lower media capabilities than initially supposed, the Controlling PoC server may renegotiate media parameters to force the UE to increase the number of frames that it packetizes in RTP-packets.

The UE may try to renegotiate the number of frames to the original number of frames per packet after a certain time interval (e.g. after a certain number of talk spurts).

6.4.2.2 Downlink adaptation

The UE shall also calculate RR metrics to monitor its own downlink.

If the UEs DL RR metrics show poor quality of the PoC service, user plane adaptation may be performed.

Upon receiving the RTCP RR packet showing poor quality of the PoC service, the Controlling PoC server may negotiate a new set of media parameters with all UE(s) in the talk session.

The UE may negotiate a new set of media parameters using SIP INVITE. Then it is up to the Controlling PoC server to decide if a downgrade of the granted media parameters should be done.

7 Timers This clause presents the timers that reside in the Controlling PoC server and in the UE(s).

7.1 Timers in the Controlling PoC server

7.1.1 End of RTP media timer (T1) This timer shall reside in the Controlling PoC server.

The ‘end of RTP media timer’ shall start when the Controlling PoC server transmits the Floor Grant packet. If the Floor Request packet is re-transmitted from the UE that is to be granted the floor (see Sub-clause 7.2.2), a new Floor Grant packet shall be sent and then the ‘end of RTP media timer’ shall be reset and started again.

The ‘end of RTP media timer’ shall be reset and started again every time a RTP packet from the UE, that is granted the floor, reaches the Controlling PoC server.

When the ‘end of RTP media timer’ expires it shall be concluded that the talk burst, which it was started for, has stopped and that the state of the floor control in the Controlling PoC server can be set to idle.

The ‘end of RTP media timer’ is reset and stopped when the last RTP packet is received in the PoC server.

The ‘end of RTP media timer’ value shall be configurable by the operator. But the ‘end of RTP media timer’ length shall not be longer than 6 seconds.

NOTE: A suitable timeout time for the Controlling PoC server may be in the interval of 3 to 5 seconds.

7.1.2 Stop-talking timer (T2) The length of the talk burst is measured using the ‘stop-talking timer’. This timer shall reside in the Controlling PoC server. It shall start when the Controlling PoC server detects the start of a talk burst (Sub-clause 5.6) and shall be reset when the Controlling PoC server detects end of talk burst (Sub-clause 5.7). When the ‘stop-talking timer’ expires it shall be concluded that the user, the timer started for, has talked too long and the Controlling PoC server shall transmit a Floor Revoke message (see Sub-clause 5.2) to the transmitting UE.



When the ‘stop-talking timer’ expires, the Controlling PoC server shall send a Floor Revoke message but carry on sending the RTP media from the UE during a grace period (i.e. until the ‘floor revoked grace timer’ has expired), and thereafter stop to transmit the RTP stream from the transmitting UE to the other UE(s) in the session.

When the ‘stop-talking timer’ expires and the grace period has ended, the Controlling PoC server shall start to broadcast Floor Idle packets to the others UE(s) in the sessions, to signal that the talk burst has ended and that another user can request the floor.

The ‘stop-talking timer’ value should be configurable by the operator.

Figure 13 shows the signal flow that occurs when the ‘stop-talking timer’ expires.

NOTE: The timer setting may be implemented in such way that it is different for different users (depending on the subscription).

7.1.3 Floor revoked grace timer (T3) The ‘floor revoked grace timer’ resides in the Controlling PoC server.

When the Controlling PoC server has sent a Floor Revoke packet to a UE, the Controlling PoC server shall carry on sending the RTP media from the UE during a grace period. When the ‘floor revoked grace timer’ has expired, the Controlling PoC server shall change its state to idle and start to send Floor Idle packets.

The ‘floor revoked grace timer’ value should be configurable by the operator, but the timer value should be rather short, i.e. ~2-3 seconds.

7.1.4 Inactivity timer (T4) The ‘inactivity timer’ shall start when the Controlling PoC server decides that a talk burst ends, e.g. when receiving a Floor Release or when the ‘end of RTP media’ timer expires. The timer shall stop and be reset when receiving a Floor Request message or RTP media.

If timer expires, the Controlling PoC server shall terminate the talk session.

The value of the ‘inactivity timer’ shall be configurable by the operator. It may be different for different types of talk sessions (i.e. the on demand session type and the early session type) or based on configuration of a particular talk group.

A typical value for the ‘inactivity timer’ may be 30 seconds.

UE #1User plane


A


UE #2User plane

Figure 18: The inactivity timer has expired.

Correlation point A in Figure 18 maps to correlation point A in Figure 42 in PoC signaling flow document (Ref. [3]). This figure shows the signaling flow that occurs when the ‘inactivity timer’ expires.



7.1.5 Sender report timer (T5) This timer shall reside in the Controlling PoC server.

The timer shall be started when the talk burst ends. The timer shall be stopped and reset when receiving a SR report from the UE that started the ‘sender report timer’. When the ‘sender report timer’ expires the Controlling PoC server shall conclude that the SR report it was started for is lost. The action taken by the Controlling PoC server when this timer expires is implementation specific.

The value of the ‘sender report timer’ should be configurable by the operator.

7.1.6 Optional: Receiver report timer (T6) This is an optional timer that may reside in the Controlling PoC server.

The timer is started when the Controlling PoC server transmit the RTCP SR. The timer shall be stopped and reset when receiving a RR report from the UE that started the ‘receiver report timer’. When the ‘receiver report timer’ expires the Controlling PoC server shall conclude that the RR report it was started for is lost. The action taken by the Controlling PoC server when this timer expires is implementation specific.

NOTE: If a UE constantly is not sending RR it may be because of fraud (if RTCP is used for charging).

The value of the ‘receiver report timer’ should be configurable by the operator.

7.1.7 Floor idle timer (T7) The ‘floor idle timer’ reside in the Controlling PoC server.

The timer shall be started when the Controlling PoC server releases the floor and transmits the first Floor Idle packet to the participating UEs in the session. When the timer expires the Controlling PoC server shall send another Floor Idle packet to the UEs and the timer shall be reset and started again.

The ‘floor idle timer’ shall be stopped and reset when the Controlling PoC server detects a Floor Request message or start of a talk burst (Sub-clause 5.6), The ‘floor idle timer’ is also stopped when the ‘inactivity timer’ expires (the talk session is terminated).

The value of the ‘floor idle timer’ should be configurable by the operator. But it is strongly recommended that the ‘floor idle timer’ use exponential back off in order to save resources over the air as well as in the terminal.

One alternative is to use the Fibonacci number series.

1 2 2 11, 1, , 1n n nF F F F F n+ += = = + ≥ ,

Here, the proposal is to use the Fibonacci numbers from n=1 to n=11 as the time until the next Floor Idle is sent. This means that the time interval between the Floor Idle packets will be:

1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 seconds.

If the session still is running after that the time series above has passed, it is recommended that the Floor Idle packets are transmitted every 89 second until the Controlling PoC server detects a Floor Request or start of talk burst.

The ‘floor idle timer’ shall only permit a certain number of retransmissions of the Floor Idle in the case the talk session is kept active longer than sending the floor idle messages. The value range for the counter is 1 … 100. The default value is 9.

7.1.8 Floor revoke timer (T8) The ‘floor revoke timer’ reside in the Controlling PoC server.

The ‘floor revoke timer’ shall be started when the ‘stop-talking timer’ expires (the Controlling PoC server transmit the Floor Revoke packet to the UE). When the timer expires the Controlling PoC server shall send another Floor Revoke packet to the UE and the timer shall be reset and started again.



The value of the ‘floor revoke timer’ should be configurable by the operator.

NOTE: A typical timer value may be in the interval of 0.5 to 2 seconds.

The ‘floor revoke timer’ shall only permit a certain number of retransmissions of the Floor Revoke. The value range for the counter is 1 … 10. The default value is 3 and shall be configurable.

7.1.9 Retry-after timer (T9) The ‘retry-after timer’ resides in the Controlling PoC server.

The ‘retry-after timer’ shall be started when the ‘stop-talking timer’ expires (at this time the Controlling PoC server starts to transmit the Floor Revoke packet to the UE). When the ‘retry-after timer’ expires the Controlling PoC server shall permit the UE to be granted the floor if the UE sends a Floor Request packet. Hence, during the time-out period the UE is not allowed to be granted the floor and all such requests should be answered with Floor Deny packets.

The value of the ‘retry-after timer’ should be configurable by the operator.

NOTE: A typical timer value may be in the interval of 5 to 30 seconds.

To be able to show on the terminal that the user have no permission to request the floor for a certain time period, this timer value should be sent in the Floor Revoke packet and utilize the ‘UE retry-after timer’ for this purpose.

7.2 Timers in the UE

7.2.1 Floor release timer (T10) The ‘floor release timer’ resides in the UE.

The ‘floor release timer’ shall be started when the UE transmits Floor Release packet (Sub-clause 5.2.3). When the ‘floor release timer’ expires, a new Floor Release packet shall be transmitted and the timer shall be reset and started again.

The ‘floor release timer’ shall be stopped and reset when the UE receives a Floor Idle packet or when the UE detects the start of a talk burst (Sub-clause 5.6).

The value of the ‘floor release timer’ is implementation specific. But the ‘floor release timer’ shall not force the UE to continuing transmit Floor Release packets 6 seconds after the first Floor Release was transmitted.

NOTE: The ‘end of RTP media timer’ that resides in the Controlling PoC server has a maximum timer value of 6 seconds. When that timer expires, the Controlling PoC server will force the floor to be idle and there is no need to try to transmit Floor Release packets after that.

7.2.2 Floor request timer (T11) The ‘floor request timer’ resides in the UE.

The ‘floor request timer’ shall be started when the UE transmits Floor Request packet (Sub-clause 5.2.2). When the ‘floor request timer’ expires, a new Floor Request packet shall be transmitted and the timer shall be reset and started again.

The ‘floor request timer’ shall be stopped and reset when the UE receives a Floor Grant packet, a Floor Taken packet, a Floor Deny packet or when the UE detects the start of a talk burst from another UE (Sub-clause 5.6).

The value of the ‘floor request timer’ is implementation specific. The ‘floor request timer’ shall only permit a certain number of retransmissions of the Floor Request before the UE shall conclude that the Floor Request has timed out. When Floor Request has timed out, the user should be given the talk reject notification as if the Floor Request has been denied.

NOTE: The value of the ‘floor request timer’ should be low, maybe ~1 second (or even as low as 0.5 seconds). After having retransmitted the Floor Request for ~6 seconds the UE should be concluded that the Floor Request has timed out and the user have to press the PoC button again to request the floor.



7.2.3 UE retry-after timer (T12) The ‘UE retry-after timer’ shall reside in the UE.

If the retry-after field (see Sub-clause 5.2.6.7.1.2) with a value that differs from zero is received in a Floor Revoke packet, the UE shall prohibit the user to transmit RTP-media for the number of seconds that is given by the retry-after field.

The value given in the retry-after field should be the timer value of the ‘retry-after timer’ in the Controlling PoC server.

7.2.4 Talk session BYE timer (T13) The ‘talk session BYE timer’ resides in the UE.

The ‘talk session BYE timer’ shall be started when the UE transmits a RTCP BYE packet in order to stop an instant personal talk session or Ad-hoc instant group talk session when using the early session procedure. When the ‘talk session BYE timer’ expires, a new RTCP BYE packet (i.e. RTCP compound packet) shall be transmitted and the timer shall be reset and started again.

The ‘talk session BYE timer’ shall be stopped and reset when the UE receives a Floor Idle packet, a Floor Taken packet or when the UE detects the start of a talk burst from another UE (Sub-clause 5.6).

The value of the ‘talk session BYE timer’ is implementation specific. But the ‘talk session BYE timer’ shall not force the UE to continuing transmit RTCP BYE packets 6 seconds after the first RTCP BYE was transmitted.

NOTE: The ‘end of RTP media timer’ that resides in the Controlling PoC server has a maximum timer value of 6 seconds. When that timer expires, the Controlling PoC server will force the floor to be idle and there is no need to try to transmit RTCP BYE packets after that.

7.2.5 Optional: UE End of RTP media timer (T14) This is an optional timer in the UE and may be used to perform a similar function to the end of RTP media timer (T1) in the Controlling PoC server.

The ‘UE end of RTP media timer’ shall start when the UE receives an explicit or implicit Floor Taken message.

The ‘UE end of RTP media timer’ shall be reset and started again every time a RTP packet reaches the UE.

When the ‘UE end of RTP media timer’ expires it shall be concluded that the talk burst, which it was started for, has stopped and that the state of the floor control in the Controlling PoC server is now idle.

The ‘UE end of RTP media timer’ is reset and stopped when the last RTP packet is received in the PoC server.

The ‘UE end of RTP media timer’ value shall be configurable by the operator. But the ‘UE end of RTP media timer’ length should be longer than the ‘end of RTP media timer’ setting in the Controlling PoC server.



Annex A : Change history (informative)

Change history Date Subject/Comment Old New 2004-05-12

Agreed by Comneon, Ericsson, Motorola, Nokia, Siemens 2.0.5

2004-06-07

Removed “confidential” and “proprietary” notes and updated change history 2.0.5 2.0.6

poc user plane - stust.edu.tw

Documents