A communication system

Description of equivalent WO 2005122470 A1

A COMMUNICATION SYSTEM

Field of the Invention

[0001] The present invention relates to a communication system and in particular but not exclusively to a communication system for use in a push-to-talk over cellular network.

Background of the Invention

[0002] A communication system can be seen as a facility that enables communication sessions between two or more entities such as user equipment and/or other nodes associated with the communication system. The communication may comprise, for example, communication of voice, data, multimedia and the like. A session may, for example, be a telephone call type session between users, a multi-way conference session, or a communication session between user equipment and an application server^" (AS) such as a service provider server.

[0003] A communication system typically operates in accordance with a given standard or specification which sets out what the various entities associated with the communication system are permitted to do and how that should be achieved. For example, the standard or specification may define if the user, or more precisely, user equipment is provided with a circuit switched service and/or a packet switched service. Communication protocols and/or parameters which shall be used for the connection may also be defined. In other words, a specific set of rules on which the communication can be based is defined to enable communication.

[0004] Communication systems providing wireless communication for user equipment are known. An example of a wireless system is the public land mobile network (PLMN) . PLMNs are commonly based on cellular technology. In cellular systems, a base transceiver station (BTS) or similar access entity services mobile user equipment (UE) via a wireless interface between these entities. The communication on the wireless interface between the user equipment and elements of the communication network can be based on an appropriate communication protocol. The operation of the base station apparatus and other apparatus required for the communication can be controlled by one or several control entities. The various control entities may be interconnected.

[0005] One or more gateway nodes may be provided for connecting the cellular access network to other networks, for example to a public switched telephone network (PSTN) and/or other communication networks such as an IP (Internet Protocol) and/or other packet switched data networks . In such arrangements, the mobile communications network provides an access network enabling a user with wireless user equipment to access external networks, hosts, or services offered by specific service providers.

[0006] An example of the type of services that may be offered to a user such as a subscriber to a communication system is the so called multimedia service. Some of the communication systems enabled to offer multimedia services are known as internet protocol multimedia networks . IP multimedia functionalities can be provided by means of an IP multimedia core network subsystem (IMS) . The IMS includes various network entities for the provision of multimedia services. IMS services are intended to offer, amongst other services, IP based packet data communication sessions between mobile user equipment .

[0007] In a packet data network, a packet data carrier may be established to carry traffic flows over the network. An example of such a packet data carrier is a packet data protocol (PDP) context.

[0008] Various types of services are provided by means of different application servers (AS) over IMS. Some of these services may be time critical . An example of a time critical service that may be provided over the IMS is the so-called direct voice communication service. One example of this type of service is the ^λpush-to-talk over cellular' (PoC) service also known as the PTT (push-to-talk service) . The direct voice communication services are intended to use the capabilities of the IMS to enable IP connections for user equipment and other parties to the communication, such as other user equipment or entities associated with the network. The service allows users to engage in immediate communication with one or more users .

[0009] The principle behind push-to-talk over cellular

(PoC) communication systems is one where the capabilities of a walkie-talkie system are implemented within a standard cellular phone. Users simply select the person or groups of persons they wish to talk to from their phone and press the push to talk key on their mobile phone to start talking. The activation may be via a specific button, tangent or any other appropriate key of the keyboard. Similar principals apply with devices having touch sensitive or sound activated user interfaces. While the user speaks, the other user or users may listen. Bi-directional communication may be offered since all parties of the communication session may similarly communicate voice data with the PoC application server. Turns to speak are requested by activating the push to talk button or the like. The response time of connection is almost instantaneous .

[0010] Push-to-talk calls are typically half-duplex communications, i.e. while one user speaks the others listen. The turn to speak is granted by pressing the push-to-talk key on a first come first served basis or based on priorities. Push-to-talk calls are usually connected without the recipient answering and typically received through the phone's built in loud speaker.

[0011] As this system is integrated within the cellular telecommunication system this provides a coverage area greater than that provided using traditional two-way radio systems. The push-to-talk service may be implemented using push-to-talk servers in a IP multimedia subsystem (IMS) system. The push to talk service is based on multi-unicasting. Each transmitting handset sends packet data traffic to a dedicated push-to-talk server (a participating server) . A controlling server receives the traffic and manages the shared floor for a group call . The controlling server duplicates the traffic to be received by all recipients. No multi-casting is performed either in the

GPRS access network or over the radio access network.

[0012] The push to talk over cellular telecommunication system such as described within the push to talk over cellular draft provisions such as the OMA Push to talk over Cellular (PoC) -Architecture' .

[0013] Groups of communicating user equipment using the PoC system can be created in various ways . The Internet Engineering Task Force (IETF) defines one such system using session initiation protocol (SIP) or Conference Policy Control Protocol (CPCP) . Voice and data control traffic once the groups are set up is carried through a real time protocol (RTP) streaming bearer. The PoC system uses transport protocols based on those described in IETF RFC 3550. The RTP protocol describes the architecture of the data packets and the syntax of the data stored within the packets passing the voice and data information from user to user.

[0014] The issue of privacy and anonymity over a PoC network has not been addressed. A user of a PoC network may wish to send a message and withhold their identity from the final destination whilst still being able to communicate an identity to one or more intermediaries.

[0015] Although there exists some SIP protocols for example ITEF RFC 3323 and ITEF RFC 3325 which enable users to withhold their identity whilst setting up an IMS connection there has been no discussion of how the data in a PoC network maintains the user's anonymity.

[0016] Furthermore there is no method available to enable a user, having joined a group, to request to talk within a group while also requesting that their identity is hidden from the other members of the group. This needs to be carried out while still transmitting their identity to the participating and controlling servers of the push-to-talk over cellular (PoC) system. The passing of identities allows the group to be monitored by authorised parties in order to discourage illegal activities from taking place while the users' identity is hidden.

[0017] It is the aim of embodiment of the present invention to address or at least mitigate the problems described above.

Summary of the Invention

[0018] There is provided according to the present invention a communication system comprising: a first and second user equipment in communication over a shared floor; and a server means for managing the shared floor; wherein the server means is arranged to detect an anonymity request from the first user equipment, and responsive to said anonymity request to prevent the second user equipment from identifying the first user equipment from user plane messages transmitted from the first user equipment to the second user equipment . [0019] The first user equipment may be arranged to initiate a connection with of the second user equipment via said server means using a first protocol .

[0020] The first protocol may be a session initiation protocol (SIP) .

[0021] The first user equipment is preferably arranged to communicate over an existing connection with said second user equipment via said server means using a second protocol .

[0022] The second protocol may be a real time control protocol (RTCP) .

[0023] The user plane messages are preferably transmitted using said second protocol .

[0024] The communications system may comprise a push-to- talk over cellular communications system.

[0025] The user plane message is preferably a floor control message .

[0026] The user plane message is preferably a floor taken message .

[0027] The user plane message is preferably a media message . [0028] The server means may be arranged to remove identification of the first user from said user plane message.

[0029] The server means may be further arranged to insert into said user plane message a unique anonymous token.

[0030] The unique anonymous token is preferably stored within said the user plane message as at least part of a source description item.

[0031] The server means is preferably arranged to remove identification of the first user from said user plane message prior to transmitting to the second user equipment.

[0032] The user plane messages from the first user equipment may include identification information comprising at least one of a URI of the user equipment and a display name of the user equipment .

[0033] The anonymity request is preferably contained within at least one of: a subtype of the message; a payload type of the message; an additional SDES field within the message; an additional customised field.

[0034] The user plane message is preferably a floor request or talk request message. [0035] The server means may comprise a controlling server and a participating server, wherein the controlling server is arranged to receive the anonymity request from the first user, and the participating server is arranged to transmit the user plane message.

[0036] The controlling server is preferably arranged to transmit a second user plane message to said participating server, said second user plane message comprises the identity of the first user equipment and a privacy indication, wherein said participating server is arranged to receive said second user plane message and responsive to said privacy indication to prevent the second user equipment from identifying the first user equipment .

[0037] The second user plane message privacy indication is preferably provided by at least one of : a subtype of the message; a payload type of the message; an additional SDES field within the message; an additional customised field.

[0038] According to a second aspect of the present invention there is provided server means arranged to operate in a communications system, said communications system further comprising a first and second user equipment in communication over a shared floor, wherein said server means is arranged to manage the shared floor, and further arranged to detect an anonymity request from the first user equipment, and responsive to said anonymity request to prevent the second user equipment from identifying the first user equipment from user plane messages transmitted from the first user equipment to the second user equipment . [0039] According to a third aspect of the present invention there is provided user equipment arranged to operate in a communications system over a shared floor, said communications system further comprising server means arranged to manage the shared floor, wherein at least one of the user equipment is arranged to receive from said server means a user plane message preventing the at least one of the user equipment from identifying at least one other user equipment.

[0040] According to a fourth aspect of the present invention there is provided a method of communication, within a communications system comprising a first and second user equipment in communication over a shared floor and server means arranged to manage the shared floor, said method comprising the steps of: receiving at said server means a request for anonymity from the first user equipment, preventing the second user equipment from identifying the first user equipment from user plane messages transmitted from the first user equipment to the second user equipment.

[0041] According to a fifth aspect of the present invention there is provided a communication system comprising: a first and second user equipment in communication over a shared floor; and a controlling server for managing the shared floor; at least one participating server for serving said second user equipment; wherein the controlling server is arranged to detect an anonymity request from the first user equipment, and to insert into user plane messages from the first user equipment a privacy indication and when the participating server is responsive to said privacy indication to prevent the second user equipment from identifying the first user equipment .

Brief Description of the Drawings

[0042] For a better understanding of the present invention and how the same may be carried into effect, reference will now be made by way of example only to the accompanying drawings in which:

[0043] Figure 1 shows a schematic view of a typical communications network incorporating an embodiment of the present invention;

[0044] Figure 2 shows a schematic view of the push-to-talk communications network as implemented within the communications network of Figure 1;

[0045] Figure 3 shows a flow diagram showing a floor control procedure incorporating a first embodiment of the present invention;

[0046] Figure 4 shows a schematic view of RTCP ^Λ talk request' data packet incorporating a first embodiment of the present invention;

[0047] Figure 5 shows a schematic view of a RTCP "floor taken' data packet incorporating the first embodiment of the present invention; and

[0048] Figure 6 shows a schematic view of a ^λ PRIV source description data packet incorporating a further embodiment of the present invention. Detailed Description of Embodiments of the Present Invention

[0049] Certain embodiments of the present invention will be described by way of example, with reference to the exemplifying architecture of a third generation (3G mobile communication system) . However it will be understood that embodiments may be applied to any other suitable forms of communication system.

[0050] The third generation partnership project (3GPP) has defined a reference architecture for the third generation (3G) core network which will provide the users of user equipment with access to multimedia services. This core network is divided into three principal domains. These are the circuit switched (CS) domain, the packet switched (PS) domain and the internet protocol multimedia subsystem (IMS) domain.

[0051] Figure 1 shows an IP multimedia network 45 for offering IP multimedia services to IP multimedia network subscribers. IP multimedia subsystem (IMS) functionalities may be provided by a core network (CN) subsystem including various entities for the provision of the service. The third generation partnership project (3GPP) has defined the use of the general packet radio service (GPRS) for offering IP connectivity to IMS services. Accordingly, a GPRS based system will be used in the following example of a possible backbone communication network enabling the IMS services.

[0052] A mobile communication system such as the 3G cellular system is typically arranged to serve a plurality of mobile user equipment, usually via a wireless interface between the user equipment and base stations of the communication system. The mobile communication system may logically be divided between a radio access network (RAN) and a core network (CN) . The core network entities typically include various control entities and gateways for enabling the communication via a number of radio access networks and also for interfacing a single communication system with one or more communication systems such as with other cellular systems and/or fixed line communications systems.

[0053] In figure 1, the intermediate mobile communication network provides packet switched data transmission in the packet switched domain between a support node 33,42 and mobile user equipment 30,44. Different sub networks are in turn connected to an external data network, for example to a packet switched data network (PSDN) via gateway GPRS support nodes (GGSN) 34, 40. The GPRS services thus allow transmission of packet data between mobile data terminals and/or external data networks. More particularly, the exemplifying general packet radio services operation environment comprise one or more sub network service areas, which are interconnected by GPRS back bone networks 32 and 41. A sub network comprises a number of packet data service nodes (SN) . In this embodiment, the service nodes will be referred to as serving GPRS support nodes (SGSN) . Each of the SGSNs 33, 42 is connected to at least one mobile communication network, typically to base station systems 31,43. Although not shown for clarity reasons, the connection may be provided by way of radio network controllers or other access system controllers such as base station controllers in such a way that packet services can be provided for mobile user equipment via several base stations . [0054] Base stations 31 and 43 are arranged to transmit signals to and receive signals from mobile user equipment 30 and 44 of mobile users i.e. subscribers, via respective wireless interfaces. Correspondingly, each of the mobile user equipment is able to transmit signals to and receive signals from the base stations via the wireless interface. In the simplified representation of figure 1, the base stations 31 and 43 belong to respective radio access networks (RAN) . In the arrangement shown, each of the user equipment 30 and 44 may access the IMS network 45 via the two access networks associated with the base stations 31 and 43 respectively. It should be appreciated that, although figure 1 only shows the base stations of two radio access networks, a typical mobile communication network usually includes a number of radio access networks.

[0055] The IMS domain is for ensuring that multimedia services are adequately managed. The IMS domain commonly supports the session initiation protocol (SIP) as developed by the internet engineering task force (IETF) . Session initiation protocol (SIP) is an application-layer control protocol for creating, modifying and terminating sessions with one or more participants (end point) . SIP was generally developed to allow for the initiation of a session between two or more end points in the Internet by making these end points aware of the session semantics. A user connected to an SIP base communication system may communicate with various entities of the communication system based on standardised SIP messages . User equipment or users that run certain applications on the user equipment are registered with the SIP backbone so that an invitation to a particular session can be correctly delivered to these end points. SIP provides a registration mechanism for devices and users and it applies mechanisms such as location servers and registrars to route the session invitations appropriately. Examples of proper possible sessions that may be provided by SIP signalling include internet multimedia conferences, internet telephone calls and multimedia distribution.

[0056] User equipment within the radio access network may communicate with a radio network controller via radio network channels which are typically referred to as radio bearers. Each user equipment may have one or more radio channels open at any one time with the radio network controller. Any appropriate mobile user equipment adapted for internet protocol (IP) communication maybe used to connect to the network. For example, a user may access the cellular network by means of user equipment such as a personal computer, personal data assistant (PDA) , mobile station (MS) , portable computer, combinations thereof or the like.

[0057] User equipment is used for tasks such as making and receiving phone calls, for receiving and sending data from and to a network and for experiencing for example multimedia content. User equipment is typically provided with a processor and memory for accomplishing these tasks. User equipment may include an antenna for wirelessly receiving and transmitting signals from and to base stations of the mobile communication network. User equipment may also be provided with a display for displaying images and other graphical information for the user of the mobile user equipment. A speaker may also be provided. The operation of the user equipment may be controlled by means of a suitable user interface such as key pad, voice commands, touch sensitive screen or pad, combinations thereof or the like.

[0058] The user equipment 30 and 44 of figure 1 are configured to enable the use of push to talk types of services. An activation function that may be required by a push to talk service can be provided by one of the buttons on the keypad of the mobile station 30 and 44 or by a specific key or button such as the type known from - ^λwalkie-talkie' devices .

[0059] It should be appreciated that figure 1 only shows two user equipment for clarity. In practice, a number of user equipment may be in simultaneous communication with each base station. User equipment may have several simultaneous sessions, for example a number of SIP sessions and activated PDP contexts. For example, the user may have a phone call and be simultaneously connected to at least one other service.

[0060] Overall communication between user equipment in an access entity and the GGSN is provided by a PDP context. Each PDP context provides a communication pathway between a particular user and a GGSN. Once the PDP context is established, it can typically carry multiple flows. Each flow normally represents, for example, a particular service and/or media component of a particular service. The PDP context therefore often represents a logical communication pathway for one or more flows across the network. To implement the PDP context between user equipment and the serving GPRS support node, radio access bearers need to be established which commonly allow for data transfer for the user equipment .

[0061] Communication systems have developed such that services may be provided for user equipment by means of various functions of the IMS network 45 that are handled by network entities and served by the servers. In the current 3G wireless multimedia network architectures, it is assumed that several different servers are for handling different functions. These include functions such as the call session control functions (CSCF) . The call session control functions can be divided into various categories such as a proxy call session control function (P-CSCF) 35, 39, interrogating call session control function (I -CSCF) 37 and serving call session control function (S-CSCF) 36, 38.

[0062] The user equipment 30, 44 may connect via the GPRS network to application servers that are generally connected to the IMS. In figure 1, such an application server is provided by a push-to-talk-over cellular (PoC) services server 50. The PoC server can in some embodiments of the present invention be implemented as server means comprising a series of participating PoC servers connected to a controlling PoC server. The participating PoC servers transmit and receive data traffic from the user equipment and also transmit and receive data traffic from the controlling PoC server. The controlling PoC server transmits and receives data traffic from the participating PoC servers and controls access to the PoC shared floor dependent on the information received from the participating servers. In a further embodiment of the present invention one participating PoC server also acts as a controlling PoC server.

[0063] Figure 2 shows a further view of the communications system of Figure 1 with regards to the push-to-talk over cellular (PoC) system. Figure 2 shows a network of user equipment units UEl 30, UE2 44, UE3 102, UE4 104 communicating over a push-to-talk over cellular telecommunication system. UEl 30 is connected to the first participating PoC server 101, which is connected to the controlling PoC server 50. UE2 44 is connected to the second participating PoC server 103 which is connected to the controlling PoC server 50. UE3 102 is connected to the third participating PoC server 105 which is connected to the controlling PoC server 50. UE4 104 is connected to the fourth participating PoC server 107 which is connected to the controlling PoC server 50. In such a system the mobile user equipment UEl, UE2 , UE3 , and UE4 can be from four different IMS networks.

[0064] The PoC participating servers 101, 103, 105, 107 and controlling PoC server 50 provide push-to-talk over cellular (PoC) services over the IMS network 45. The push-to-talk service is an example of the so called direct voice communication service. Users who wish to use the PoC service may need to subscribe to an appropriate PoC server.

[0065] The direct voice communication services are intended to use the capabilities of the GPRS back bone and the control functions of the multimedia subsystem for enabling IP connections with the user equipment UEl 30, UE2 44, UE3 102, UE4 104. The PoC server may be operated by the operator of the

IMS system or a third party service provider.

[0066] A user may open the communication link, for example, by pressing a specific activation button on the user equipment UEl 30. While the user of the UEl 30 speaks, the users of UE2 44, UE3 102, and UE4 104 listen. The user of the user equipment UE2 44 may then reply in a similar manner. The signalling between the user equipment and the appropriate call session control functions is routed via the GPRS network. The user plane session sets up signalling for the user equipment and is routed via the participating PoC servers 101, 103, 105, 107 and controlled by the controlling PoC server 50. In other words, the PoC server controls both the control plane (for signalling) and the User plane (for user data) of the PoC user. The control plane traffic between the participating PoC server and the user equipment may be routed via the IMS whilst the user plane traffic between the user equipment and the PoC server may be routed from the GPRS system to the PoC server on interfaces 54 and 56 (as shown in Figure 1) .

[0067] As discussed earlier the push-to-talk service is based on multi-unicasting. Each transmitting user equipment UEl 30, UE2 44, UE3 102, UE4 104 sends packet data traffic to a dedicated push-to-talk server and in case of a group call, the server then duplicates the traffic to all recipients. In order to control the communications system user plane' messages can be passed from one user to the rest of the system and vice versa. One type of data communications packet in the user plane is that of informing which user is transmitting or has received permission to use the floor. This information could be a "floor taken' message. This "floor taken' information is received by the user equipment which will receive RTP traffic from the user who has taken control of the floor. These control packets are based on a real time control protocol (RTCP) packet, a subset of the real time protocols (RTP) described earlier.

[0068] In order to aid the understanding of the present invention we shall describe a situation where the users UEl 30, UE2 44, UE3 102, and UE4 104 are involved in a group communication, and the user using user equipment UE4 104 wishes to talk whilst requesting that his/her identity is hidden from the others .

[0069] With regards to Figure 3 a flow diagram is shown describing an embodiment of the present invention in action. For clarity the PoC Client A refers in this example to the user equipment UE4 104, the participating PoC server A refers to the participating PoC server 107, the controlling PoC server X refers to the controlling PoC server 50, the PoC server B refers to the first participating PoC servers 101, and the PoC Client B refers to the respective user equipment UEl 30. Although a one-to-one communication is described within this example it is appreciated that the same method can be applied to a one-to-many communication where the controlling PoC server copies the message to each of the receiving parties .

[0070] In the first step 201 the PoC Client A 104 transmits a "talk request' message to the participating PoC server A 107. This "talk request' message includes the talking party or user identity of the client A and an anonymity request.

[0071] The second step 203 occurs after the participating PoC server A 107 has received the talk request. In this step the participating PoC server A 107 forwards the "talk request' including the talking party identity and the anonymity request to the controlling PoC server X 50.

[0072] The controlling PoC server X 50 may carry out authorisation of the client to determine that the client is authorised to participate in the PoC communications group. If the PoC Client A 104 is permitted to talk i.e. there is no other user occupying the floor then the controlling PoC server X 50 initiates a first step 205 and a second step 207.

[0073] The controlling PoC servers initiated first step 205 is where the controlling PoC server X 50 forwards a "floor taken' message to the participating PoC server B 101. The

"floor taken' message includes the talking party identity together with the anonymity request from client A 104.

[0074] The controlling PoC servers initiated second step 207 is where the controlling PoC server X 50 transmits a "talk granted' message to the participating PoC server A 107. In other embodiments of the present invention the controlling PoC server X 50 transmits a "floor granted' message which is processed by the system in a manner similar to a "talk granted' message. In the following step 209 the participating PoC server A transmits the "talk granted' message received from the previous step towards the PoC Client A 104. This

"talk granted' message allows the client A to send a talk burst within the group, i.e. to broadcast to the group any message it wishes to send.

[0075] The participating PoC server B 101 receives the "floor taken' message from the controlling PoC server X 50 including the talking party identity and anonymity request information. The participating PoC server B 101 recognises the anonymity request and removes the identity of the talking party from the "floor taken' message. The participating PoC server B 101 generates a new "floor taken' message within this step 251. The participating PoC server B 101 then transmits this new "floor taken' message containing no identifying features of the user to the PoC Client B 30 in step 211.

[0076] With regards to Figures 4 and 5 examples of the

"talk request' message including the talking party identity and anonymity request and the "floor taken' messages are shown .

[0077] With respect to Figure 4 a real time control protocol (RTCP) based packet such as that used passing a "talk request' data packet incorporating a first embodiment of the present invention is shown.

[0078] The "talk request' RTCP packet is transmitted from the PoC Client A 104 to the participating PoC server 107, and forwarded by the participating PoC server A 107 to the controlling PoC server X 50 in order to request from the controlling server permission to transmit speech to the other users .

[0079] The "talk request' RTCP packet comprises a datagram 32 bits in width. The first line of the datagram comprises a series of information values, a version indicator (V) 303 (2 bits), a padding bit (P) (1 bit) 305, a source count 307A (5 bits) , a payload type (PT) (8 bits) 309, and a length indicator (LENGTH) 311.

[0080] As defined in IETF RFC3550 section 6.5 the version indicator 303 indicates the version of the RTP being used, in this example version 2. The padding bit 305 indicates if the packet contained one or more padding octets. The source count is used to identify a subtype that defines which of the various RTCP packets the present one is. In the example shown in Figure 4 the value of 10000 indicates this is a modified "talk request' RTCP packet, the modification being that the user requesting the talk request wishes to maintain anonymity to the other users of the group. The payload type (PT) 107 defines the format of the RTCP payload, in the example shown the payload type is equal to APP or 204. The length indicator (LENGTH) 311 describes the length of the packet in 32 bit words, not counting the first word. In this example the length is equal to two further 32 bit words.

[0081] The second line of the datagram comprises a synchronisation source identifier (SSRC) 313, which identifies the synchronisation source for the originator of the packet . In the example shown where the packet is a "talk request' packet the SSRC 313 is that for the PoC Client A 104. [0082] The third and final line of the RTCP packet comprises the displayed address "name' 315 for the user equipment. The "name' field can also be used to indicate the application release version.

[0083] This packet once received by the participating server A at the end of step 201 is then forwarded in step 203 to the controlling PoC server X 50.

[0084] With respect to Figure 5 a real time control protocol (RTCP) based packet such as that used passing a

"floor taken' message data packet incorporating a first embodiment of the present invention is shown.

[0085] According to the method described earlier there are two types of "floor taken' messages used. The first type of

"floor taken' RTCP packet transmitted from the controlling PoC Server 50 through the network to a participating PoC server, e.g. the first participating PoC server 103. The second type is transmitted from the participating PoC server to the user equipment, e.g. UEl 30, and prepares the user equipment to receive RTP packets from the user equipment which has been granted the floor. Both the first and second types can be described with respect to Figure 5.

[0086] The "floor taken' RTCP packet comprises a datagram 32 bits in width. [0087] The first line of the datagram comprises a series of information values, a version indicator (V) 303 (2 bits) , a padding bit (P) (1 bit) 305, a source count (5 bits) 307b, a payload type (PT) (8 bits) 309, and a length indicator (length) 311b.

[0088] As defined in IETF RFC 3550 section 6.5 the version indicator 303 indicates the version of the RTP being used, in this example version 2. The padding bit 305 indicates if the packet contains one or more padding octets. The source count 307b is used to identify a subtype that defines which of the various RTCP packets the present one is. In the example shown in figure 5 the value of 10010 indicates that this is a modified "floor taken' RTCP packet where the user requested anonymity (as compared to the subtype 00010 indicating a regular "floor taken' RTCP packet) . The payload type (PT) 309 defines the format of the RTCP payload, in the example shown the payload type is equal to APP or 204. The length indicator (length) 109 describes the length of the packet in 32 bit words, not counting the first word.

[0089] The second line of the datagram comprises a synchronisation source identifier (SSRC) 313b, which identifies the synchronisation source for the originator of the packet . In the example shown where the packet is a modified "floor taken' packet the SSRC 313b is that for the controlling PoC server 50.

[0090] The third line of the RTCP packet comprises the displayed address (name) 315b for the push-to-talk over cellular (PoC) server. The "name' field can also be used to indicate the application release version.

[0091] The fourth and further lines of the packet comprises an information block 317.

[0092] For the first type of "floor taken' message the information block comprises two source description (SDES) items .

[0093] The first source description item 321 comprises the canonical name (CNAME) . The canonical name comprises the canonical name of the user 323. The canonical name of the user 323 is defined as the unique identifier assigned to the user/user equipment combination. An example of such a unique identifier would be the SIP uniform resource indicator (URI) such as that shown in Fig 5, "dave.bowman@poc.operator.com'.

[0094] The second source description item 325 comprises the display name (name) . The display name comprises the display name of the user 327. The display name of the user 327 is an identifier displayed by the user equipment indicating the user/user equipment combination. An example of such an identifier would be the alphanumeric string such as that shown in Fig 5 "DaveB' .

[0095] Once the participating PoC server B 103 has received the floor taken anonymously packet the participating PoC server B processes the "floor taken' message to remove the canonical name (CNAME) and display name (NAME) of the user.

The CNAME and NAME values may be in some embodiments of the present invention given unique anonymous names. In such a situation it would be possible for the user to maintain their anonymity, but authorities still be able to link the message to a particular user given the particular relationship between the unique anonymous name and the user name .

[0096] In further embodiments of the present invention the subtype of the "floor taken' message reverts to the normal subtype for a "floor taken' message. In such an embodiment it is therefore possible to prevent the receiving user equipment detecting that the transmitting user equipment has requested anonymity.

[0097] In such a situation described above the user is capable of maintaining anonymity when requested in front of other clients or user equipment, but still be capable of being monitored by authorised parties at the controller.

[0098] Although the above example has been described in terms of providing an anonymity request within the subtype field of a RTCP floor control packet it can be appreciated that in other embodiments of the present invention, the indicator can be located within other parts of the floor control message.

[0099] In one further embodiment, the request for anonymity is indicated by the use of a modified payload type. The controlling PoC server and participating PoC servers are able to recognise this modified payload type to provide the required anonymity.

[0100] In another further embodiment the request for anonymity may be indicated by the provision of additional SEDS fields incorporating an anonymous or alternative identity from the user.

[0101] In further embodiments of the present invention the request for anonymity within the floor control message can be indicated by adding additional customised fields to the packet .

[0102] In the example of adding an additional SDES field including the anonymous identity the first type "floor taken' message sent from the controlling PoC server 50 to the participating PoC server B 103 carries the anonymous information together with the SDES field containing the anonymous ID of the user. The second type "floor taken' message from the participating PoC server 103 to the receiving PoC client 30 includes only the anonymous information, i.e. the ID of the user is removed prior to forwarding to the PoC Client B 30.

[0103] In further embodiments of the present invention the anonymous or alternative identity is provided not as an additional SDES field but is concatenated to the original SDES field information in order to form a compound SDES field. For example the display name in the first type of "floor taken' message can contain the data, ""name+++anonymousID" , where the "name' is the display name of the user, the string "+++' a separator and " anonymousID' the name passed to the other users in the second type of "floor taken' message.

[0104] In further embodiments of the present invention the anonymity information or packet or element is piggybacked with the known "floor taken' packet. In such an embodiment a first

"floor taken' RTCP packet comprising source description information comprising canonical user name and display user name is concatenated with a second packet containing anonymity information to form a compound RTCP packet.

[0105] In a further embodiment of the present invention a "floor taken' RTCP packet as known in the art is followed directly by a second RTCP packet containing anonymity information. This second packet is a predefined real time control protocol (RTCP) application (APP) packet.

[0106] In a further embodiment the anonymity identifier source description item PRIV produces a PoC specific private extension transporting the anonymity information.

[0107] With reference to Figure 6 an example of a PRIV message packet including the anonymity information is shown. The PRIV packet 501 comprises a value string 503 which contains the anonymity information, i.e. the indicator and/or any anonymity ID. [0108] In further embodiments of the present invention the canonical name of the user can be the Tel URL/URI of the user.

The Tel URL/URI is the SIP equivalent to the telephone number of the user equipment as used in the public switched telephone network (PSTN) .

[0109] In further embodiments of the present invention the controlling PoC server remembers an instance during a user's initialisation where the user requested anonymity. This request can be carried out using the SIP protocols described within IETF RFC 3325 and/or IETF RFC 3323. In this embodiment the controlling PoC server examines any talk or floor request messages and applies the privacy as requested by the user, i.e. the controlling PoC server transmits a "floor taken' message as if it had received a "talk request' message containing an anonymity request .

[0110] Embodiments of the present invention may use other types of floor control ■ messages or indeed other types of messages to provide the described information. Examples of other types of messages include media messages.

[0111] Embodiments of the present invention may further use protocols other then RTCP for transmitting user and control plane messages.

[0112] In further embodiments of the present invention, where the controlling server is transmitting to a user equipment serviced by a participating server within an untrusted network, the controlling PoC server carries out the tasks of stripping any identifying feature from the forwarded messages before forwarding the message onto the untrusted network participating server.

[0113] In other embodiments of the present invention the user equipment can transmit an anonymous value as the users display name. In these embodiments the system is arranged not to strip the anonymous value but to simply forward the value. Thus the user still maintains their privacy within such a system.