WO2009052859A1

WO2009052859A1 - Floor control in poc telecommunication system

Info

Publication number: WO2009052859A1
Application number: PCT/EP2007/061423
Authority: WO
Inventors: Mattias Jonsson; Micael Berg
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2007-10-24
Filing date: 2007-10-24
Publication date: 2009-04-30

Abstract

The present invention relates to a method for floor control in a push-to-talk over cellular (PoC) communication system. The present invention also relates to a PoC telecommunication system for floor control and a PoC Client (PoC-C) and a PoC Server (PoC-S) in the PoC system enabling said floor control. The system comprises at least one first PoC client (PoC-C A) in a first user equipment and a first PoC server (PoC-S (C)) performing a controlling function. A floor control command is sent to the PoC-S (C) from the PoC-C A that includes a request or a release of a floor access. The PoC- C A is allowed to send 6A-6D on the floor one talk burst in the system at least to a second PoC client (PoC-C B) installed in a second user equipment. The floor control command is sent for the purpose of the PoC-C A requesting or releasing a floor on which the talk burst can be sent. When the PoC-S (C) decides to grant a floor access it sends 4A,4B a talk burst confirmation to the PoC-C A and informs about the acknowledgement of said request. The first PoC client (PoC-C A) then sends 6A-6D the burst including voice media in the communication system at least to the second PoC client (PoC-C B). What particularly characterizes the method according to the present invention is that the first PoC client includes the floor control command into at least one compact floor control data packet which also comprises the voice media. The first PoC client further sends the compact floor control data packet to the first PoC server (PoC-S (C)) following an activation 1 or deactivation 7 of the first PoC client on the first user equipment.

Description

Title: Floor control in PoC telecommunication system

TECHNICAL FIELD

The present invention relates to a method for improved floor control. The present invention also relates to a PoC telecommunication system, a PoC Client and a PoC Server in the PoC system enabling said method.

BACKGROUND

Push to talk over Cellular networks (PoC) is a technology intended to provide rapid communications for business and consumer customers of mobile networks. PoC provides a direct one-to-one and one-to-many voice communication service over cellular networks. The fact that it is a one-way communication means that when one person speaks the others listen. The opportunity to speak is granted by pressing a Push-To-Talk (PTT) key on the cellular phone. This means that PoC is not a conference call in which the all members can speak at the same time.

PoC is half duplex communications — while one person speaks, the other(s) listen(s). There is only communication in one direction at the time and not simultaneously. PoC adds functionality for individual half-duplex transmissions to be sent to another party on the system. There is no need for establishing a call session. Since the system is half-duplex (utilizing a single frequency) only one user can transmit by PTT at a time.

Regular call sessions utilize full-duplex communications, allowing customers to call other persons on for instance a mobile network and be able to simultaneously talk and hear the other party. Such communications in require a communication session to be established, for instance by dialing a phone number and the other party answering the call. The connection remains active until either party ends the call or the connection is dropped due to signal loss or a network outage. Full-duplex operation on mobile phone networks is made possible by using separate frequencies for transmission and reception.

Push-to-talk (i.e. Walkie talkie) has been available for a long time but in PoC the cellular network and the cellular phones are used for the service. This brings new business opportunities in voice communication. Business benefits for the cellular operators with PoC are that it is a completely new voice service complementing the rich service portfolio of GSM/WCDMA (Global System for Mobile communication/Wide Code Division Multiple Access). It enriches the IP (Internet Protocol) multimedia communication sessions. It gives the operator an opportunity to develop a voice service offering without having to change conventional voice services. This allows the operator to increase the number of subscribers and increase the possibilities for service charging.

The fact that no call session is established means that network resources are not reserved two-ways during the whole session. The resources are reserved one-way for the duration of the PTT session rather than for the entire call session. As an example in full-duplex call 10 minutes air time is used for a 10 min call session. With PoC 3 min of air time is used for a one hour call session. This means that the network and air interface resources available can provide voice services for more subscribers are the same time which is a main benefit for the operator.

In contrast with regular phone calls, PoC provides an "always-on" connection which means that a conversation can start immediately pushing a Push To Talk (PTT) button on the phone. The immediate connection promotes efficient, spontaneous and occasional communication. Another main benefit is that the coverage area is provided by the GSM/WCDMA access networks coverage. Consequently, PoC can be used between users spread out, even being in different countries. Another end-user benefit is the possibility of creating spontaneous group communication due to the fact that with PoC is quick and easy to create and activate talk groups. PoC is often based on half-duplex Voice over IP (VoIP) technology using an IP-capable network. VoIP are protocols that provide the service of routing voice conversations over the Internet and through any other IP-based network. VoIP can facilitate tasks which are more difficult to achieve using traditional networks. Such tasks are the ability of VoIP to transmit more that one telephone call through the same telephone line, VoIP being location independent (only an internet connection is needed to get a connection to a VoIP provider) and VoIP phones being able to integrate with other services available, such as video sharing and interactive network gaming.

PoC based on VoIP is an integral part of the IP Multimedia communication portfolio of services offered through the IP Multimedia Subsystem (IMS). IMS, see figure 1 , is developed to interact with existing core networks. It is an architectural framework originally designed for delivering IP multimedia services to end users over fixed and mobile networks using open standards. Such services are VoIP, video, pictures and these in combination with existing services. IMS is access independent which means that if can operates with for instance different air interfaces such as GSM and WCDMA.

Examples of access network which IMS can operate with are GSM and Universal Mobile Telecommunication System (UMTS) Radio Access Network (RAN). RAN comprises an antenna and the base station equipment together with a Radio Network Controller (RNC). IMS enables the operators to mix and match equipment and applications from multiple vendors. Figure 1 illustrates how a GSM or UMTS user equipments (UE) 10, 11 accesses the transport layer TL of the core network via a RAN (not shown). A gateway GPRS (General Packet Radio Services) support Node (GGSN) in TL acts as interface between RAN and IMS. It converts incoming packets from SGSN (Serving GPRS Support Node) into an appropriate packet data protocol (PDP) and sends them into the packet data network which is here the IMS. GGSN and SGSN is part of the IP backbone in the core network. SGSN is responsible for the delivery of data packets from and to the UE 10, 11. In figure 1 there is an example of two core networks (left and right) including respectively IMS and IP backbones when the UEs 10, 11 access different core networks.

IMS includes tools and functions needed to handle numerous non- standardized services in a standardized way in order to ensure interoperability, access awareness, policy and charging control (PCC), security and quality of service (QoS). The role of IMS is to provide secure and reliable means for terminals and applications to reach, negotiate and communicate with each other.

The core of IMS is two main nodes: the Call Session Control Function (CSCF) and the Home Subscriber Server (HSS). CFCS is the heart of the IMS architecture and processes the Session Initiation Protocol (SIP) signalling used in IMS. HSS is a master database that contains user and subscriber information to support the networks handling of sessions.

SIP is an application layer signalling (control) protocol used in IMS for creating, modifying and terminating sessions with one or more participants. SIP is also described as a peer-to-peer since two SIP endpoints can communicate without and intervening SIP infrastructure. SIP can be used for instance in PoC, VoIP and multimedia sessions. SIP is independent of the underlying transport layer which means that it can run on for instance Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). SIP clients use TCP or UDP to connect to SIP application servers in IMS and other SIP endpoint (end-to-end communication).

CFCS provide session control (such as a call session) which includes secure routing of SIP messages, monitoring the SIP sessions and communicating with the policy architecture to support media authorization. CFCS also interacts with HSS.

The different roles of CFCS are serving (S-CFCS), interrogating (I-CFCS) and Proxy (P-CFCS), see figure 1. S-CFCS makes sure to pass information between the end points involved in the session through their associated P- CFCS, route, translate, maintaining the session, interacting with other sessions and handle charging. I-CFCS is the first point of contact for home networks to IMS. I-CFCS selects an S-CFCS and routes the SIP request from the home network to the assigned S-CFCS. P-CFCS is a SIP proxy server the first point of contact with IMS for a mobile user terminal. P-CFCS provides secure SIP signalling and is an interface towards PCC architecture.

All applications and services in IMS are executed in SIP application servers. Application servers are implemented above the standardized IMS architecture. One server can handle one single service or several services. Services from different servers can also be combined. The application servers host and execute services and uses SIP to interface with S-CFCS.

In the Open Mobile Alliance (OMA) PoC standard network architecture for the PoC a functional entity is the SIP-based PoC application server PoC-S connected to IMS, see figure 1 , via S-CSCF. The PoC servers handle application specific tasks such as floor control (the reservation of talk spurts for one speaker at the time) and also operate as interface to the operator's management systems. PoC server comprises the application level AL functionality for the PoC service above the IMS layer. The PoC servers shall or may be able to perform a number of different functions mentioned in the OMA PoC v 1 specification.

Another functional entity is the PoC client (PoC-C A/PoC-C B) installed in each UE 10, 11 , see figure 1. The PoC client is software which understands the PoC protocol and is able to talk to the server PoC-S. The client is used to access the PoC service. It for instance allows session initiation, participation and release. It also performs registration and authentication in the IMS-based core network and sends and receives talk bursts. The client is further able to record voice media from the UE's microphone and play media in the UEs speaker. The PoC client shall or may be able to do a number of other things mentioned in the OMA PoC v 1 specification. The PoC-S can act alone or in synergy with several other PoC-S. The server:

- Routes media between users. All media is routed through one or more servers. The servers keep subscription information and know which clients to route to.

- Handles floor control. PoC supports only half-duplex, only one user may speak at the time. When a user has started to speak the others must wait until the speaking part releases the floor.

- Handles user's group subscriptions. The users may subscribe on one or more groups. If media from several groups are sent in the same time the media mixing is handled by the clients.

The PoC server PoC-S can have two different functions. The determination of the function/role that a particular PoC server shall have takes place at PoC session setup, see figure 4, and lasts for the duration of the whole session. When a one-to-one or one-to-many ad hoc group session is initiated by a PoC client, its corresponding server shall take a controlling function/role. In case of chat and pre-established groups, the host of the group or chat performs controlling.

In a single and multiple network environment one-to-one PoC session, a PoC server may perform both controlling function PoC-S (C) and participating function PoC-S (P), see figure 1 - 3. However, only one PoC server performs the controlling function while the one or more servers can perform a participating function. The controlling PoC server can handle a number of SIP sessions (one for each participant in the PoC session) and media and talk burst communication paths in one PoC session. The participating function is performed once per PoC client for each incoming or outgoing session.

When the PoC server only has a controlling function, it does not communicate directly with the client for the session signalling. Instead it communicates via the PoC server performing the participating function for that PoC client. When the PoC has both a controlling and participating function in communicates directly with the client. The participating PoC server always has a direct communication path with a client and a controlling PoC server.

Figure 1 - 3 illustrates the different functions of the OMA PoC entities PoC Server PoC-S and PoC Client. As shown the PoC server performing the controlling function PoC-S (C) routes media and media-related signalling such as talk burst control messages to the PoC client in each UE 10, 11 via the PoC server PoC-S (P) performing the participating function of that client. The UE 10, 11 has a PTT button for easy access via RAN. The handset has the PoC client installed.

Figure 1 and 2 illustrate the example of a one-to-one communication between two UEs 10 and 11 while figure 3 illustrates a one-to-many communication. As seen in figure 1 the media and the signalling is routed from the PoC client PoC-C A of the first UE 10 via RAN (not shown) and the IP backbone (SGSN/GGSN) to the IMS (CFCS) of the first core network to a PoC participating application server PoC-S (P) A. The media and the media- related signalling is then routed by the controlling server PoC-S (C) to the PoC-S (P) B for the second core network of the second UE, via IMS all the way down to the PoC client B for a UE 11. The procedure can be performed both ways. In one-to-many communication you simply add an extra UE 11 on the right side and optionally an extra PoC-S (P) on the right side (the UEs sometimes run on the same PoC-S (P). As disclosed in figure 3 it may also be that the two or more UEs 11 run different core networks which means different IMS and IP backbones in TL.

Figure 2 illustrates the routing of media and media-related signalling in a one- to-one PoC session. The IP backbones and the IMS are stripped off. The controlling and the participating PoC-S may be the same server 18. The data is routed from the client PoC-C A, via the servers PoC-S (P) A and PoC-S (C) of the first core network, to the PoC-S (P) B server of the second core network and finally to the PoC-C B client.

Figure 3 illustrate the routing of media and media-relates signalling in one-to- many session. Also here the IP backbones and the IMS are stripped off and also here the controlling and the participating PoC-S may be the same server 18. The data is routed from the sending UE 10 via its participating server PoC-S (P) to the controlling server PoC-S (C). The data is further routed to the participating servers of the respective UE 11 and to the client PoC-C B installed in the equipments. When the participating servers are located in different core networks, see also figure 1 and 2, the data is routed through an external public network 12.

A PoC session corresponds to all talk bursts within a PoC session initiated, see figure 4, by a PTT activation from an inviting PoC client in a UE 10, 11. Before one of the PoC clients in participating in the session can send the talk burst it shall request (with the PoC server) the permission to send a talk burst. The PoC server confirms or rejects the request in dependence if any of the present clients within the session has a permission to send a burst or not. There are also other rules for rejection and permission mentioned in the OMA PoC v 1 specification.

The talk burst request procedure at PoC Session initialisation is illustrated in figure 4. When the PTT button is pressed 1 on the first UE 10 a PoC session establishment is performed 2A for the first UE 10 and performed 2B for the second UE 11. Then a talk burst confirmation is then sent 3A, 3B from the controlling server PoC-S (C) to the client PoC-C A in the UE 10. Client PoC- C A then notifies the user of the first equipment about the establishment by sending 3C a talk proceed notification. The talk burst from the first UE is also received 4A, 4B by the client PoC-C B in the second UE 11 and PoC-C B then notifies the user of the second equipment by sending 4C a talker identification notification. If an acknowledgement is required this is sent 5 to the participating server P-C-S (P) B for PoC-C B. Finally the user of the first UE 10 can start sending media 6A - 6D to the user of the second UE 11. Figure 4 illustrates a one-to-one session. However, the same procedure is used also in a one-to-many session (see figure 3). In such a case there are N numbers of PoC-C B clients.

The talk burst request confirmed procedure during a PoC session is illustrated in figure 5. Also in figure 5, the procedure is corresponding for a one-to-many session (see figure 3). When the PTT button is pressed 1 on the first UE 10, the controlling PoC-S (C) is running idle 2 at the moment, a talk burst request is sent 3A, 3B to the controlling server. If the controlling server decides to grant the request the same procedure as illustrated in figure 4 is performed. Consequently, a talk burst confirm 4A, 4B and a talk proceed notification 4C are sent. Moreover, the talk burst is also received 5A, 5B by the client PoC-C B and the user of the second equipment is notified 4C by a talker identification notification. Finally media can be sent 6A - 6D. No acknowledgement is needed in this procedure.

There is a reference point PoC-3 between the PoC Client and the PoC server PoC-S for enabling transport of media and media-related signalling between the two. The protocols for PoC-3 are Real Time Protocol RTP and Real Time Control Protocol RTCP. RTP is used for media transport while RTCP is used talk burst control procedures, see figure 4 and 5. RTP is a common way of sending media over a network, for instance audio and video data. Streaming services on Internet often use RTP ad RTP is decided to be the standard protocol for PoC by OMA. RTPC is the controlling channel of RTP and it is used to tell how well the streaming works. If there are lots of lost packages the PoC client can the PoC-S by using the RTCP channel.

The POC-3 reference point exists between a PoC client a PoC-S accessing the IMS serving the PoC Client, see figure 1. There is also a reference point PoC-4 the PoC Servers. The protocols for the POC-4 reference point are also RTP/RTCP When communication in a PoC Session, RTP Media is transferred, see procedure 6A - 6D in figure 4 - 5 between several Participants in a half-duplex fashion. Each Participant receives all RTP Media that is transmitted by any other Participant in the PoC Session.

RTP Media and Talk Burst Control signalling RTCP passes across the POC- 3 and POC-4. All RTP Media to and from all PoC Clients in a PoC Session is sent through the Controlling PoC Function PoC-S (C), see figure 1. If the Participating PoC Function PoC-S (P) is inserted in the transport path between the Controlling PoC Function and a PoC Client, all RTP Media to and from the PoC Client flows through the Participating PoC Function. Talk Burst Control and RTP Media replication are handled by PoC-S (C).

The floor control behaviour is defined by OMA PoC v 1. The talk burst request packets, reference 3A/3B in figure 5, is sent on the RTCP channel in order to receive floor access. Floor access means the permission of the person activating the PTT button to speak. When the floor access is permitted and acknowledged by PoC-S (C), references 4A-4B and 5A/5B, the media packets can be sent, references 6A-6D on the RTP channel. Media- related signalling (such as floor status) during the talk burst is sent on the RTCP channel. The media packets may as an alternative be sent on the same time as the talk burst request packets. The messages are then synchronized by PoC-S (C). The procedure of talk burst requests and media transmission is for instance described in US 2006/0229093 and US 2005/0265313.

The common solution of requesting for floor access in a PoC session, see reference 3A/3B in figure 5, and waiting for acknowledgement ACK, reference 4A/4B before media is sent means that the user that wants to send a talk burst has to wait after the PTT button is pressed before he can speak. When the talk proceed notification 4C is sent the user can start to speak, 6A - 6D. This roundtrip can take from 0.4 to 1 second per request which means that the voice packet must wait for floor access before it can be sent. SUMMARY

The object of the present invention is consequently to solve the mentioned problems and provide a method for improved floor control. The mentioned problems are solved by a PoC telecommunication system, a PoC Client and a PoC Server in the PoC system enabling said method.

In order to solve the mentioned problems the present invention relates to a method for floor control in a push-to-talk over cellular (PoC) communication system. The system comprises at least one first PoC client installed in a first user equipment and a first PoC server performing a controlling function. The first PoC client sends a floor control command to the first PoC server which at least includes a request or a release of a floor access. The first PoC client is allowed to send on the floor at least one talk burst in the communication system at least to a second PoC client which is installed in a second user equipment. The floor control command is at least sent for the purpose of the first PoC client requesting or releasing a floor on which the talk burst can be sent. When the first PoC server decides to grant a floor access it sends a talk burst confirmation to the first PoC client and informs about the acknowledgement of said request. The first PoC client then sends the talk burst including voice media in the communication system at least to the second PoC client.

What particularly characterizes the method according to the present invention is that the first PoC client includes the floor control command into at least one compact floor control data packet which also comprises the voice media. The first PoC client further sends the compact floor control data packet to the first PoC server following an activation or deactivation of the first PoC client on the first user equipment.

In order to solve the mentioned problems the present invention also relates to a push-to-talk over cellular (PoC) client which is adapted for floor control. The PoC client is included in a PoC communication system which further comprises a PoC server (PoC-S (C)) which is adapted to perform a controlling function. A first PoC client is installed in a first user equipment. The first PoC client is adapted to send a floor control command to the first PoC server which at least includes a request or a release of a floor access. On said floor the first PoC client is allowed to send at least one talk burst in the communication system at least to a second PoC client which is installed in a second user equipment. The floor control command is at least sent for the purpose of the first PoC client requesting or releasing a floor on which the talk burst can be sent. The first PoC client is further adapted to, when receiving a talk burst confirmation from the PoC-S-(C), send the talk burst including voice media in the communication system at least to the second PoC client.

What particularly characterizes the PoC client according to the present invention is that the first PoC client is adapted to include the floor control command into at least one compact floor control data packet also comprising the voice media. The first PoC client is further adapted to send the compact floor control data packet to the first PoC server following an activation or deactivation of the first PoC client on the first user equipment.

In order to solve the mentioned problems the present invention also relates to a push-to-talk over cellular (PoC) server which is adapted for floor control.

The PoC server is included in a communication system which further comprises at least one first PoC client installed in a first user equipment. A first PoC server in the system is adapted to perform a controlling function.

The first PoC server is further adapted to receive a floor control command from the first PoC client which at least includes a request or a release of a floor access. On said floor the first PoC client is allowed to send at least one talk burst in the communication system at least to a second PoC client which is installed in a second user equipment. The floor control command is at least sent for the purpose of the first PoC client requesting or releasing a floor, on which the talk burst can be sent. The first PoC server is further adapted to, when deciding to grant a floor access, send a talk burst confirmation to the first PoC client informing about the acknowledgement of said request.

What particularly characterizes the first PoC server according to the present invention is that it is adapted to receive from the first PoC client a compact floor control data packet or packets including the floor control command, the packet also comprising voice media.

In order to solve the mentioned problems the present invention finally relates to a push-to-talk over cellular (PoC) communication system which is adapted for floor control. The system comprises at least one first PoC client installed in a first user equipment and a first PoC server performing a controlling function. The first PoC client is adapted to send a floor control command to the first PoC server which at least includes a request or a release of a floor access. The first PoC client is allowed to send on the floor at least one talk burst in the communication system at least to a second PoC client which is installed in a second user equipment. The floor control command is at least sent for the purpose of the first PoC client requesting or releasing a floor on which the talk burst can be sent. When the first PoC server decides to grant a floor access it is further adapted to send a talk burst confirmation to the first PoC client and inform about the acknowledgement of said request. The first PoC client is further adapted to then send the talk burst including voice media in the communication system at least to the second PoC client.

What particularly characterizes the system according to the present invention is that the first PoC client is adapted to include the floor control command into at least one compact floor control data packet also comprising the voice media. The first PoC client is further adapted to send the compact floor control data packet to the first PoC server following an activation or deactivation of the first PoC client on the first user equipment.

One advantage with the present invention relates to less signalling. Due to the fact that the talk burst request is part of the media packet and not sent in beside, every packet sent is counted. No packet is sent without media "payload". The first packet sent from the client contains media and the last sent packet also contains media. In this way you will not loose time waiting for returning status packets before you are able to send your media.

Another advantage relates to redundancy. In UDP you are not sure if the data comes through to the destination and you need to add some ACK procedure on the application level. If you for example send a floor request message before you send the media you must wait until the ACK or not ACK (NACK) returns. If the UDP packet went lost in the binary cyber world and no ACK or NACK is returned, you will have to resend the request within a specified timeout. This is the traditional way to handle these tasks. According to the invention you keep on sending the floor request + media until ACK or NACK is returned. In other words you do not sit still and wait.

A further advantage relates to simple routing. Due to the fact that all information for routing is available in the header of each packet the routing is very simple to achieve in the server. The header contains the group address and the only thing the server has to do is look-up the subscribers for the specific group and forwards the message.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows a schematic view of a PoC communication network with an IMS system.

Figure 2 shows a schematic view of the relationship between PoC-S (C) performing the server function, PoC-S (P) server performing the participating function and the PoC client.

Figure 3 shows a schematic view of a stripped PoC communication network according to figure 1 for a one-to-many PoC session.

Figure 4 shows a talk burst request procedure at PoC session initialisation according to OMA PoC ver 1. Figure 5 shows a talk burst request confirmed procedure during a PoC session.

Figure 6 shows a floor control protocol stack according to the present invention.

Figure 7 shows a compact floor control packet according to the present invention.

Figure 8 shows a talk burst request confirmed procedure during a PoC session according the present invention.

Figure 9 shows an IPA connected to the user equipment according to a separate embodiment.

DETAILED DESCRIPTION

The invention will now be described in detail with reference to embodiments described in the detailed description and shown in the drawings.

The embodiments refer to a method and a PoC telecommunication system for floor control and a PoC Client and a PoC Server (PoC-S) in the PoC system enabling said method. The system, and the PoC Client and a PoC

Server (PoC-S) in the PoC system are adapted to perform the method steps as described in the method. It should be understood by a person skilled in the art that the fact the PoC system and in particular the system parts (PoC Client and PoC Server (PoC-S)) perform a method step means that they are adapted to perform said step.

The present invention relates to a method for floor control in a push-to-talk over cellular (PoC) communication system. The present invention also relates to a system comprising at least one first PoC client (PoC-C A) installed in a first user equipment and a first PoC server PoC-S (C) performing a controlling function. Such a server is shown in figure 1 - 3. The first PoC client sends 3A, 3B, see figure 8, a floor control command to the first PoC server (PoC-S (C)). The command includes a request or a release of a floor access. The command may also contain other parts. On said floor the first PoC client is allowed to send at least one talk burst in the communication system at least to a second PoC client (PoC-C B), which is installed in a second user equipment 11. The floor control command is sent for the purpose of the first PoC client requesting or releasing a floor on which the talk burst can be sent and it may also be sent for other purposes.

When the first PoC server (PoC-S (C)) decides to grant a floor access it then sends 4A, 4B a talk burst confirmation to the first PoC client (PoC-C A) and informs about the acknowledgement of said request. Such a confirmation is sent in the form of an ACK, which is an acknowledgement code in the invention used to inform the first PoC client that the floor access in granted.

When the first PoC client (PoC-C A) receives confirmation it then sends the talk burst including voice media in the communication system at least to the second PoC client (PoC-C B). A Talk Burst is the flow of media from a PoC Client that has the permission to send media.

The main problem that the present invention focuses on is that the system has to wait for acknowledgement ACK, reference 4A/4B in figure 8, before media can be sent. This means that the user that wants to send a talk burst has to wait after the PTT button is pressed before he can speak. This roundthp can take from 0.4 to 1 second per request which means that the voice packet must wait for floor access before it can be sent. The object is to solve this problem by providing a method and device for floor control.

The problem is solved by means of the first PoC client (PoC-C A) including the floor control command (FC) into at least one compact floor control data packet (13) also comprising the voice media. The first PoC client (PoC-C A) then sends the compact floor control data packet to the first PoC server following an activation (1 ) or deactivation (7) of the first PoC client (PoC-C A) on the first user equipment (10).

One advantage is that due to the fact that the talk burst request is part of the media packet and not sent in beside, every packet sent is counted. No packet is sent without media "payload". The first packet sent from the client contains media and the last sent packet also contains media. In this way you will not loose time waiting for returning status packets before you are able to send your media. Moreover, in UDP you are not sure if the data comes through to the destination and you need to add some ACK procedure on the application level. Since you now instead keep on sending the floor request + media until ACK or NACK is returned you will not sit and wait. If the UDP packet went lost in the binary cyber world and no ACK or NACK is returned, you will no longer wait for a specified timeout before resending. Finally, since all information for routing is available, in the packet header of each packet, the routing is very simple to achieve in the server.

The compact floor control data packet 13, see figure 7, comprises Real Time Protocol (RTP) media and a User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) header, the media being sent using RTP. RTP is the common way to send streaming media (voice, video) over the internet.

According to the present invention the compact floor control data packet 13 now includes a group address in the form of group address header (ADD). From this header the first PoC server identifies the user equipment 11 or user equipments including the second PoC client (PoC-C B) and which should receive the media from the first user equipment 10. Since the header contains the group address the only thing the server has to do is look-up the subscribers for the specific group in a database and forwards the message to these UEs 11. The group address header may preferably be two bytes long.

According to the present invention the compact floor control data packet 13 further includes the floor control command, in form of a floor control command header FC, see figure 7. The floor control command header (FC) is preferably four bits long.

The compact the compact floor control data packet 13 also includes a protocol version header V, see figure 7. From the header V the first PoC server (PoC-S (C)) is informed about the version of a compact floor control protocol (FC+ADD) used by the group address header (ADD) and the floor control command header (FC). This protocol is introduced as a new protocol and included in a layer in the protocol stack between the User Datagram

Protocol (UDP) or Transmission Control Protocol (TCP) layer and the Real Time Protocol (RTP) layer, the media being sent using RTP. The protocol stack is shown in figure 6. The header V is preferably 4 bits long.

The first PoC client (PoC-C A) is installed in the first user equipment 10 and the activation 1 or deactivation 7 of the first PoC client (PoC-C A) on the first user equipment 10 is performed by pressing respectively releasing a Push- To-TaIk button (PTT) on the first user equipment 10. All user equipments that want to make a PoC talk burst has to have a button or any similar (software- based) interface, to activate the burst.

The sequence for the improved floor control in the PoC communication system will now be described with reference to figure 8. The PoC session has already been activated in a PoC session initialisation illustrated in figure 4.

When the first PoC client (PoC-C A) is activated 1 it first 2 starts to record the voice media received by the microphone in the first user equipment 10 and encodes this media. The media is encoded to be sent with RTP. Then the first PoC client checks which group address the user of the first user equipment 10 wants to communicate with. From this address the first PoC server (PoC-S (C)) identifies the at least one user equipment 11 including the second PoC client (PoC-C B), which should receive the talk burst from the first user equipment 10. The first PoC client (PoC-C A) then includes the floor control command and the group address into the at least one compact floor control data packet, comprising the voice media recorded and sends (3A,3B), see figure 8, the packet 13, see figure 7, to the first PoC server (PoC-S (C)). In this step the floor control command consists in a floor request, which means that the first PoC client requests for floor access to send a talk burst. From the activation of the button PTT the compact floor control data packets 13 are continuously streamed 3A, 3B by the first PoC client (PoC-C A). A packet could be 10 - 100 ms or even longer which influences the streaming.

When receiving the compact floor control data packet or packets 13, the first PoC server (PoC-S (C)) checks if the floor is available and if this is true returns (4A,4B) an ACK message and if this is false returning (4A,4B) a NACK message to the first PoC client (PoC-C A). ACK is an acknowledgement code in the invention used to inform the first PoC client that the floor access in granted while with NACK the floor access is denied. If the first PoC client (PoC-C A) receives an ACK message, the floor control command (FC) is changed to a notification about continuous talk burst. If the first PoC client (PoC-C A) receives an NACK message it immediately stops sending compact floor control data packets and notifies the user of the user equipment 10 that the floor is busy.

When the first data packet 13 is received, the PoC-S immediately decides if it should give floor access to the first PoC client (PoC-C A) and returns with the ACK or NACK message. At the same time, if floor access is approved, the PoC-S routes the received packet to the second PoC client (PoC-C B) in the at least one collected second user equipment 11 , identified by the group address. In this way you will not loose time waiting for returning ACK/NACK messages packets before you are able to send your media.

When the first PoC client (PoC-C A) is deactivated 7, see figure 8, it stops to record the voice media received by the microphone in the first user equipment 10 and encode this media. It further changes the floor control command to a floor release. The first PoC client (PoC-C A) includes the changed floor control command and the group address into a last compact floor control data packet, comprising the last voice media recorded before the deactivating and sends (10A,10B), see figure 8, the packet to the first PoC server (PoC-S (C)).

The second PoC client (PoC-C B) in the at least second user equipment 11 included in the group address sends 11A,11 B, see figure 8, an ACK to the first PoC server (PoC-S (C)) that the floor is released when receiving the last compact floor control data packet 13. Here the ACK is used to acknowledge the receipt of the packet 13.

The first PoC server (PoC-S (C)) according to the present invention forwards (6C,6D,10C,10D) the compact floor control data packets 13 received by the first PoC client (PoC-C A) to the at least one second user equipment 11 , including the second PoC client (PoC-C B) and identified by the group address. These packets also includes the group address ADD and the floor control command FC.

The floor control command and the group address are included into all compact floor control data packets following the activation and/or deactivation of the first PoC client (PoC-C A) on the first user equipment 10. The packet always comprises a FC header and the command changes depending of if the packet relates to a floor request, a notification about continuous talk burst or a floor release.

When the second PoC client (PoC-C B) in the at least second user equipment 11 receives the compact floor control data packet it decodes the voice media and sends it to the speaker of the second user equipment 11.

The embodiments refer to a method and a PoC telecommunication system for floor control and a PoC Client and a PoC Server (PoC-S) in the PoC system enabling said method. The system, and the PoC Client and a PoC Server (PoC-S) in the PoC system are adapted to perform the method steps as described in the method.

The push-to-talk over cellular (PoC) client is adapted for the floor control. The first PoC client (PoC-C A) is adapted to send 3A, 3B the floor control command to the first PoC server (PoC-S (C)), which at least includes the request or the release of the floor access. On said floor the first PoC client (PoC-C A) is allowed to send 6A-6D at least the one talk burst in the communication system at least to the second PoC client (PoC-C B) which is installed in the second user equipment 11. The first PoC client is further adapted to, when receiving the talk burst confirmation from the PoC-S-(C), send 6A-6D the talk burst including voice media in the communication system at least to the second PoC client (PoC-C B). What particularly characterizes the first PoC client is that it is adapted to include the floor control command FC into at least the one compact floor control data packet 13 also comprising the voice media. The first PoC client is further adapted to send the compact floor control data packet 13 to the first PoC server (PoC-S (C)) following the activation 1 or deactivation 7 of the first PoC client (PoC-C A) on the first user equipment 10.

The push-to-talk over cellular (PoC) server (PoC-S (C)) is adapted for the floor control. The PoC-S (C) is adapted to perform the controlling function.

The first PoC server (PoC-S (C)) included in the system is further adapted to receive 3A, 3B the floor control command from the first PoC client (PoC-C A), which at least includes the request or the release of the floor access. The first

PoC server (PoC-S (C)) is also adapted to, when deciding to grant a floor access, send 4A, 4B the talk burst confirmation to the first PoC client (PoC-C

A) informing about the acknowledgement of said request. What particularly characterizes the first PoC server (PoC-S (C)) is that it is adapted to receive from the first PoC client (PoC-C A) the compact floor control data packet or packets including the floor control command FC, the packet also comprising voice media. The push-to-talk over cellular (PoC) communication system is adapted for floor control. The system comprises at least the first PoC client (PoC-C A) installed in the first user equipment 10 and the PoC server (PoC-S (C)) performing the controlling function. The first PoC client is adapted to send 3A, 3B the floor control command to the first PoC server (PoC-S (C)), which at least includes the request or the release of the floor access. The first PoC client is allowed to send 6A-6D on the floor at least the one talk burst in the communication system at least to a second PoC client (PoC-C B), which is installed in the second user equipment. The floor control command is at least sent for the purpose of the first PoC client requesting or releasing the floor, on which the talk burst can be sent. When the first PoC server (PoC-S (C)) decides to grant the floor access it is further adapted to send 4A, 4B a talk burst confirmation to the first PoC client (PoC-C A) and inform about the acknowledgement of said request. The first PoC client (PoC-C A) is further adapted to then send the talk burst including voice media in the communication system, at least to the second PoC client (PoC-C B).

What particularly characterizes the system is that the first PoC client (PoC-C A) is adapted to include the floor control command FC into at least the one compact floor control data packet 13, also comprising the voice media. The first PoC client (PoC-C A) is further adapted to send the compact floor control data packet to the first PoC server (PoC-S (C)) following the activation 1 or deactivation 7 of the first PoC client (PoC C A) on the first user equipment 10.

In a further embodiment of the present invention a PoC session is not set up before the method for floor control over the PoC communication session is performed. Instead dynamic groups are used which means that each group has a unique address and the user may listen to one or several group addresses.

This enables the PoC to work more like traditional PTT, such as walkie-talkie. In contrary to the OMA PoC ver 1 specification, you do not have to set up sessions before you speak and you do not have predefined groups. Instead you just talk on a defined channel and all users that listen to that channel receive the information. This is simple, fast and dynamic.

The user selects one or several dynamic groups that he/she wants to listen to, and when the group is selected the PoC client notifies the first PoC server

(PoC-S (C)). Thereafter the user is ready to receive data from the dynamic group or groups. The dynamic addresses are stored by the PoC-S and any user equipment 10, 11 allowed to access can select and participate in such a group. The dynamic addresses therefore correspond to the channels of analogue PTT, such as walkie-talkie. When the address is selected the method according to the present invention can be performed, see figure 8.

In this embodiment is that a radio channel approach is achieved, such as in walkie-talkie. Moreover, one RTP media based PoC server can receive data from several sources and channels. The embodiment also enables easy phoritization between different "channels". Moreover, to session establishment is needed and it is easy to configure firewalls.

Another embodiment relates to an intelligent PTT accessory (IPA) being connected to the user equipment 10 as a separate accessory and comprising the PoC client. The connection may be wireless such as Bluetooth or by wire. The user equipment being connected to an IPA functions as a modem for PTT communication, see figure 9. IPA is intended for the blue-light segment. As shown in figure 9 data 14 and voice 15 is communicated from the external public network 12, see also figure 3, to the user equipment. Via the communication link 17, the data and voice is then transmitted to the IPA so that the PoC client in the IPA can process the information. The user 16 can operate both the user equipment 10 and the IPA. As shown the IPA is preferably positioned suitable on the user's body outside the clothes, while the user equipment 10 can be placed in a pocket or holder somewhere in the clothes. One problem solved by this embodiment is that the need to radio-certify the user equipment for each operator, which normally is expensive. Another problem solved is the need to use AMR vocoders which consume a lot of bandwidth. Furthermore direct mode is enabled and a hardware support for encryption is provided.

The IPA built on a common chip-set and has the following features:

- Push-to-Talk (PTT)

- Channel/Group selection

- Emergency button.

- Speaker microphone

- Advanced hands free profile, you can use IPA for calling.

- Headset connector

- Weather proof and rugged

- Analogue/digital radio for direct mode

- Hardware support for vocoders and encryption.

One advantage is that the IPA can with mechanical changes be adapted to different kinds of customer environments. The police have perhaps a more sophisticated unit compared with fire fighters that are happy with one large button with "PTT" marked on it. Another advantage is that it is easy to customize. Moreover it is fast since it is dedicated for PTT. Furthermore, no or limited radio certification is needed which increases the cost. It is also easy to adapt to different IP networks such as WLAN, WIMAX and TAR. Finally it works with any handset on any IP enabled network. It will also be appreciated by the person skilled in the art that various modifications may be made to the described embodiments without departing from the scope of the present invention.

Claims

1. A method for floor control in a push-to-talk over cellular (PoC) communication system comprising at least one first PoC client (PoC-C A) installed in a first user equipment (10) and a first PoC server (PoC-S (C)) performing a controlling function,

the first PoC client (PoC-C A) sending (3A, 3B) a floor control command to the first PoC server (PoC-S (C)) at least including a request or a release of a floor access on which floor the first PoC client is allowed to send (6A-6D) at least one talk burst in the communication system at least to a second PoC client (PoC-C B) being installed in a second user equipment (11 ),

the floor control command at least being sent for the purpose of the first PoC client requesting or releasing a floor on which the talk burst can be sent,

the first PoC server (PoC-S (C)) when deciding to grant a floor access sends a talk burst confirmation (4A,4B) to the first PoC client (PoC-C A) informing about the acknowledgement of said request,

the first PoC client (PoC-C A) then sending (6A-6D) the talk burst including voice media in the communication system at least to the second PoC client (PoC-C B),

characterized in that

the first PoC client (PoC-C A) including the floor control command (FC) into at least one compact floor control data packet (13) also comprising the voice media,

the first PoC client (PoC-C A) sending the compact floor control data packet to the first PoC server (PoC-S (C)) following an activation (1 ) or deactivation (7) of the first PoC client (PoC-C A) on the first user equipment (10).

2. Method according to claim 1 wherein the compact floor control data packet (13) comprises Real Time Protocol (RTP) media and a User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) header, the media being sent using RTP.

3. Method according to any of the preceding claims wherein the compact floor control data packet (13) includes a group address in the form of group address header (ADD), the first PoC server (PoC-S (C)) from the header (ADD) identifying the at least one user equipment (11 ) including the second PoC client (PoC-C B) which should receive the media from the first user equipment (10).

4. Method according to claim 3 wherein the group address (ADD) header is two bytes long.

5. Method according to any of the preceding claims wherein the compact floor control data packet (13) includes the floor control command in form of a floor control command header (FC).

6. Method according to claim 5 wherein the floor control command header (FC) is four bits long.

7. Method according to any of the claims 3 - 4 and any of the claims 5- 6 wherein the compact floor control data packet (13) includes a protocol version header (V), the first PoC server (PoC-S (C)) from the header (V) being informed about the version of a compact floor control protocol (FC+ADD) used by the group address header (ADD) and the floor control command header (FC).

8. Method according to claim 7 wherein the protocol version header is 4 bits long.

9. Method according to any of the claims 7 - 8 wherein the compact floor control protocol (FC+ADD) is included in a layer in the protocol stack between the User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) layer and the Real Time Protocol (RTP) layer, the media being sent using RTP.

10. Method according to any of the preceding claims wherein the activation (1 ) or deactivation (7) of the first PoC client (PoC-C A) on the first user equipment (10) is performed by pressing respectively releasing a Push-To- TaIk button (PTT) on the first user equipment (10).

11. Method according to any of the preceding claims wherein when the first PoC client (PoC-C A) is activated (1 ) it performs the steps (2) of:

- starting to record the voice media received by the microphone in the first user equipment (10) and encode this media,

- checking which group address the user of the first user equipment (10) wants to communicate with, from which address the first PoC server (PoC-S (C)) identifies the at least one user equipment (11 ) including the second PoC client (PoC-C B) which should receive the talk burst from the first user equipment (10),

the first PoC client (PoC-C A) including the floor control command and the group address into the at least one compact floor control data packet comprising the voice media recorded and sending (3A,3B) the packet (13) to the first PoC server (PoC-S (C)).

12. Method according to claim 11 wherein the floor control command consists in a floor request.

13. Method according to any of the claims 11 - 12 wherein the compact floor control data packets (13) following the activation (1 ) of the first PoC client (PoC-C A) on the first user equipment (10) is continuously streamed (3A,3B) by the first PoC client (PoC-C A).

14. Method according to any of the claims 11 - 13 wherein the first PoC server (PoC-S (C)) when receiving the compact floor control data packet or packets (13) checks if the floor is available and if this is true returning (4A, 4B) an ACK message and if this is false returning (4A₁ 46) a NACK message to the first PoC client (PoC-C A).

15. Method according to claim 14 wherein when the first PoC client (PoC-C A) receives an ACK message the floor control command (FC) is changed to a notification about continuous talk burst.

16. Method according to claim 14 wherein when the first PoC client (PoC-C A) receives an NACK message it immediately stops sending compact floor control data packets.

17. Method according to any of the claims 14 - 16 wherein the first PoC server (PoC-S (C)) following the returning of the ACK message forwards (5A, 5B) the compact floor control data packets, received by the first PoC client (PoC-C A) until the ACK is sent, to the at least one collected second user equipment (11) identified by the group address.

18. Method according to any of the claims 11 - 17 wherein when the first PoC client (PoC-C A) is deactivated (7) it performs the steps of:

- stopping to record the voice media received by the microphone in the first user equipment (10) and encode this media,

- changing the floor control command to a floor release,

the first PoC client (PoC-C A) including the changed floor control command and the group address into a last compact floor control data packet comprising the last voice media recorded before the deactivating and sending (1OA, 1OB) the packet to the first PoC server (PoC-S (C)).

19. Method according to claim 18 wherein the second PoC client (PoC-C B) in the at least second user equipment (11) when receiving the last compact floor control data packet (13) sends (11A,11B) an ACK to the first PoC server (PoC-S (C)) that the floor is released.

20. Method according to any of the claims 11 - 19 wherein the first PoC server (PoC-S (C)) forwards (6C,6D,10C,10D) the compact floor control data packets (13) received by the first PoC client (PoC-C A) to the at least one second user equipment (11) including the second PoC client (PoC-C B) and identified by the group address.

21. Method according to any of the claims 11 - 20 wherein the floor control command and the group address is included into all compact floor control data packets following the activation and/or deactivation of the first PoC client (PoC-C A) on the first user equipment (10).

22. Method according to any of the claims 11 - 21 wherein when the second PoC client (PoC-C B) in the at least second user equipment (11) receive the compact floor control data packet it decodes the voice media and sends it to the speaker of the second user equipment (11).

23. A push-to-talk over cellular (PoC) client being adapted for floor control, the PoC client being included in a PoC communication system further comprising a first PoC server (PoC-S (C) performing a controlling function, a first PoC client (PoC-C A) being installed in a first user equipment (10),

the first PoC client (PoC-C A) being adapted to send (3A.3B) a floor control command to the first PoC server (PoC-S (C)) at least including a request or a release of a floor access on which floor the first PoC client (PoC- C A) is allowed to send (6A-6D) at least one talk burst in the communication system at least to a second PoC client (PoC-C B) being installed in a second user equipment (11 ),

the floor control command at least being sent for the purpose of the first PoC client (PoC-C A) requesting or releasing a floor on which the talk burst can be sent,

the first PoC client (PoC-C A) further being adapted to, when receiving a talk burst confirmation from the first PoC server (PoC-S (C)), send (6A-6D) the talk burst including voice media in the communication system at least to the second PoC client (PoC-C B),

characterized in that

the first PoC client (PoC-C A) further being adapted to include the floor control command (FC) into at least one compact floor control data packet (13) also comprising the voice media,

the first PoC client (PoC-C A) further being adapted to send the compact floor control data packet to the first PoC server (PoC-S (C)) following an activation (1) or deactivation (7) of the first PoC client (PoC-C A) on the first user equipment (10).

24. PoC client according to claim 23 wherein the first PoC client (PoC-C A) on the first user equipment (10) is adapted to perform the activation (1) or deactivation (7) when pressing respectively releasing a Push-To-Talk button (PTT) on the first user equipment (10).

25. PoC client according to any of the claims 23 - 24 wherein when the first PoC client (PoC-C A) is activated (1) it is adapted to perform the steps (2) of:

- checking which group address the user of the first user equipment (10) wants to communicate with, from which address the first PoC server (PoC-S

(C)) identifies the at least one user equipment (11) including the second PoC client (PoC-C B) which should receive the talk burst from the first user equipment (10),

the first PoC client (PoC-C A) further being adapted to include the floor control command and the group address into the at least one compact floor control data packet comprising the voice media recorded and send (3A.3B) the packet (13) to the first PoC server (PoC-S (C)).

26. PoC client according to any of the claims 23 - 25 wherein the first PoC-C (PoC-C A) is adapted to continuously stream (3A.3B) the compact floor control data packets (13) following the activation (1) of the first PoC client.

27. PoC client according to any of the claims 23 - 26 wherein when the first PoC client (PoC-C A) is adapted to change the floor control command (FC) to a notification about continuous talk burst when receiving an ACK message from the first PoC server (PoC-S (C)).

28. PoC client according to any of the claims 23 - 27 wherein when the first PoC client (PoC-C A) is adapted to immediately stop the sending of compact floor control data packets when receiving an NACK message from the first PoC server (PoC-S (C)).

29. PoC according to any of the claims 23 - 28 wherein when the first PoC client (PoC-C A) is deactivated (7) it is adapted to perform the steps of:

- changing the floor control command to a floor release,

the first PoC client (PoC-C A) further being adapted to include the changed floor control command and the group address into a last compact floor control data packet comprising the last voice media recorded before the deactivating and sending (1 OA, 1OB) the packet to the first PoC server (PoC-S (C)).

30. PoC client according to claim 29 wherein the second PoC client (PoC-C B) in the at least second user equipment (11) when receiving the last compact floor control data packet (13) is adapted to send (11 A, 11B) an ACK to the first PoC server (PoC-S (C)) that the floor is released.

31. PoC client according to any of the claims 23 - 30 wherein the second PoC client (PoC-C B) in the at least second user equipment (11) when receiving the compact floor control data packet is adapted to decode the voice media and send it to the speaker of the second user equipment (11).

32. A push-to-talk over cellular (PoC) server (PoC-S (C)) being adapted for floor control, the PoC-S (C) being included in a communication system further comprising at least one first PoC client (PoC-C A) installed in a first user equipment (10),

a first PoC Server (PoC-S (C)) in the system being adapted to perform a controlling function,

the first PoC server (PoC-S (C)) further being adapted to receive (3A.3B) a floor control command from the first PoC client (PoC- C A) at least including a request or a release of a floor access on which floor the first PoC client (PoC-C A) is allowed to send (6A-6D) at least one talk burst in the communication system at least to a second PoC client (PoC-C B) being installed in a second user equipment (11),

the first PoC server (PoC-S (C)) further being adapted to when deciding to grant a floor access send (4A.4B) a talk burst confirmation to the first PoC client (PoC-C A) informing about the acknowledgement of said request,

characterized in that

the first PoC server (PoC-S (C)) is further adapted to receive from the first PoC client (PoC-C A) a compact floor control data packet or packets (13) including the floor control command (FC) and the packet also comprising voice media.

33. PoC-S according to claim 32 wherein the PoC-S (PoC-S (C)) is adapted to when receiving the compact floor control packet or packets (13) check if the floor is available and if this is true returning (4A.4B) an ACK message and if this is false returning (4A.4B) a NACK message to the first PoC client (PoC-C A).

34. PoC-S according to daim 33 wherein the first PoC server (PoC-S (C)) following the returning of the ACK message is adapted to forward (5A.5B) the compact floor control data packets, received by the first PoC client (PoC-C A) until the ACK is sent, to the at least one collected second user equipment (11) identified by the group address.

35. PoC-S according to any of the claim 32 - 34 wherein the first PoC server (PoC-S (C)) is adapted to forward (6C, 6D, 1OC, 1OD) the compact floor control data packets (13) received by the first PoC client (PoC-C A) to the at least one second user equipment (11) including the second PoC client (PoC- C B) and identified by the group address.

36. A push-to-talk over cellular (PoC) communication system being adapted for floor control and comprising at least one first PoC client (PoC-C A) installed in a first user equipment (10) and a first PoC server (PoC-S (C)) performing a controlling function,

the first PoC client (PoC-C A) being adapted to send (3A, 3B) a floor control command to the first PoC server (PoC-S (C)) at least including a request or a release of a floor access on which floor the first PoC client is allowed to send (6A-6D) at least one talk burst in the communication system at least to a second PoC client (PoC-C B) being installed in a second user equipment (11),

the first PoC server (PoC-S (C)) being adapted to, when deciding to grant a floor access send (4A, 4B) a talk burst confirmation to the first PoC client (PoC-C A), inform about the acknowledgement of said request, the first PoC client (PoC-C A) further being adapted to then send (6A-6D) the talk burst including voice media in the communication system at least to the second PoC client (PoC-C B)₁

characterized in that