CN1989734A - A communication system - Google Patents

Abstract

A communication system including a first and second user equipment in communication over a shared floor and a server means for managing the shared floor. According to the system, the server means is arranged to detect an anonymity request from the first user equipment and, responsive to the 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. The shared floor may relate to a push-to-talk over cellular (PoC) service.

Description

Communication Systems

technical field

The present invention relates to a communication system, and particularly but not exclusively to a communication system for use in push-to-talk over a cellular network.

Background technique

A communication system may be viewed as a tool that enables a communication session between two or more entities, such as user equipment and/or other nodes associated with the communication system. Such communications may include, for example, voice communications, data communications, multimedia communications, and so forth. A session may be, for example, a telephone call type session between users, a multiparty conference session, or a communication session between a user device and an Application Server (AS), such as a service provider server.

A communication system typically operates according to a given standard or specification that sets forth what those various entities associated with the communication system are allowed to do and how that operation is done. For example, the standard or specification may define whether to provide the user, or more precisely, whether to provide circuit-switched services and/or packet-switched services to the user equipment. It is also possible to define the communication protocol and/or parameters to be used for the connection. In other words, a set of specific rules on which the communication can be based is defined to enable communication.

Communication systems providing wireless communication for user equipment are known. One example of a wireless system is a Public Land Mobile Network (PLMN). PLMNs are usually based on cellular technology. In a cellular system, a base transceiver station (BTS) or similar access entity provides services to mobile user equipment (UE) over a radio interface between these entities. Communication on the wireless interface between the user equipment and elements of the communication network may be based on a suitable communication protocol. The operation of the base station equipment and other equipment required for this communication can be controlled by one or several control entities. Different control entities can be connected to each other.

One or more gateway nodes may be provided to connect the cellular access network to other networks, for example to the Public Switched Telephone Network (PSTN) and/or to networks such as IP (Internet Protocol) and/or other packet switched data networks other communication networks. In this configuration, the mobile communication network provides an access network that enables users with wireless user equipment to access services provided by external networks, hosts, or specific service providers.

An example of a type of service that may be provided to a user such as a subscriber of a communication system is so-called multimedia service. Certain communication systems capable of providing multimedia services are called Internet Protocol Multimedia Networks. IP Multimedia functions may be provided by means of an IP Multimedia Core Network Subsystem (IMS). The IMS includes different network entities to provide multimedia services. Among other services, IMS services are used to provide IP-based packet data communication sessions between mobile user equipment.

In a packet data network, packet data bearers can be established to carry traffic on the network. One example of such a packet data carrier is a Packet Data Protocol (PDP) context.

Different types of services are provided by means of different Application Servers (AS) on the IMS. Some of these operations may be time critical. One example of a time-critical service that can be provided via IMS is the so-called direct voice communication service. An example of such a service is the 'Push to Talk over Cellular' (PoC) service, also known as PTT (Push to Talk). Direct voice communication services are used to enable IP connectivity between user equipment and other parties to the communication, such as other user equipment or entities associated with the network, utilizing the capabilities of the IMS. This service allows users to communicate with one or more users instantly.

The principle behind a Push-to-talk over Cellular (PoC) communication system is the implementation of the capabilities of a wireless walkie-talkie system in a standard cellular telephone. Users simply select the person or group of people to talk to from their phone and press the push-to-talk key on their mobile phone to start the call. Activation may be through specific buttons, tangents or other suitable keyboard keys. Similar principles apply to devices with tactile-sensitive or sound-activated user interfaces. When the user speaks, one or more other users can listen. Since all parties to the communication session can equally communicate voice data with the PoC application server, two-way communication can be provided. A turn to speak can be requested by activating a push-to-talk button, etc. The response time of the connection is almost instantaneous.

Push-to-talk calls are usually half-duplex communications, ie, when one user speaks, the other listens. Turns to speak are authorized on a first-come, first-served or priority basis by pressing a push-to-talk button. Push-to-talk calls usually go through without the recipient answering, and are usually received through the phone's built-in speaker.

Since this system is integrated within the cellular telecommunication system, this provides a larger coverage area than using conventional two-way wireless systems. The push-to-talk service can be realized by using the push-to-talk server in the IP Multimedia Subsystem (IMS) system. The push-to-talk service is based on multipoint unicast. Each sending handset sends packet data traffic to a dedicated push-to-talk server (participating server). A control server receives this traffic and manages the shared floor for group calls. The control server replicates the traffic to be received by all receivers. Multicasting is not performed in the GPRS access network nor on the wireless access network.

For example, the PTT telecommunications system described in PTT has drafted regulations such as 'OMA Push to talk over Cellular (PoC)-Architecture'.

Groups of communicating user equipments utilizing the PoC system can be created in different ways. The Internet Engineers Task Force (IETF) defines one such system using Session Initiation Protocol (SIP) or Conference Policy Control Protocol (CPCP). Once the group is set up, voice and data control traffic is carried over real-time protocol (RTP) streaming bearers. The PoC system uses a transport protocol based on that described in IETF RFC 3550. The RTP protocol describes the structure of data packets, and the syntax of the data stored in packets of voice and data information passed from user to user.

The issues of confidentiality and anonymity have not been resolved on the PoC network. Users of a PoC network may wish to send messages without providing their identity to the final destination, while still being able to pass the identity to one or more intermediaries.

Although there are certain SIP protocols such as lTEF RFC 3323 and ITEF RFC 3325 that enable users not to provide their identity while establishing an IMS connection, there is no discussion on how data in PoC networks can keep users anonymous.

Furthermore, there is no way for a user who has joined a group to request to speak in the group while also requesting to hide their identity from other members of the group. This needs to be performed while still sending its identity to the Participation and Control Server of the Push to Talk over Cellular (PoC) system. In order to prevent illegal activities while hiding the user's identity, the transfer of identity allows the group to be monitored by authorized parties.

Embodiments of the present invention aim to solve or at least alleviate the above-mentioned problems.

Contents of the invention

According to the present invention there is provided a communication system comprising: first and second user equipment communicating over a shared floor; and server means for managing the shared floor; wherein the server means is configured to detect an anonymous request from the user equipment, and in response to the anonymous request, prevent the second user equipment from identifying the identity of the first user equipment in a user plane message sent from the first user equipment to the second user equipment.

The first user equipment may be configured to use the first protocol to initiate a connection with the second user equipment through the above server device.

The first protocol may be Session Initiation Protocol (SIP).

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

The second protocol may be Real Time Control Protocol (RTCP).

User plane messages are preferably sent using the second protocol described above.

The communication system may include a push-to-talk over wireless communication system.

The user plane messages are preferably floor control messages.

The user plane message is preferably a floor take message.

User plane messages are preferably media messages.

The server device may be configured to remove the identity of the first user from the aforementioned user plane message.

The server device may also be configured to insert a unique anonymous token in the aforementioned user plane messages.

The unique anonymous token is preferably stored as at least a part of the source description item in the above-mentioned user plane message.

The server means is preferably configured to remove the identity of the first user from the above-mentioned user plane message before sending it to the second user equipment.

The user plane message from the first user equipment may include identification information including at least one of a URI of the user equipment and a display name of the user equipment.

The anonymous request is preferably contained in at least one of the following: a subtype message; a payload type message; an additional SDES field within the message; an additional custom field.

The user plane message is preferably a floor request or a talk request message.

The server means may comprise a control server and a participation server, wherein the control server is configured to receive anonymous requests from the first user and the participation server is configured to send user plane messages.

The control server is preferably configured to send a second user plane message to said participating server, said second user plane message comprising the identity of the first user equipment and a confidentiality indication, wherein said participating server is configured to receive said second user plane message, and In response to the aforementioned indication of confidentiality, the second user equipment is prevented from identifying the identity of the first user equipment.

The second user plane message confidentiality indication is preferably provided by at least one of: a subtype message; a payload type message; an additional SDES field within the message; an additional custom field.

According to a second aspect of the present invention there is provided a server device configured to operate in a communication system, said communication system further comprising first and second user equipment communicating over a shared floor, wherein said server device is configured to manage The shared floor, and is further configured to detect an anonymous request from the first user equipment and, in response to said anonymous request, prevent the second user equipment from identifying the second user equipment in a user plane message sent from the first user equipment to the second user equipment. An identity of a user device.

According to a third aspect of the present invention, there is provided a user equipment configured to operate in a communication system on a shared floor, the communication system further comprising a server device configured to manage the shared floor, wherein at least one of the user equipment It is configured to receive a user plane message from said server device preventing the at least one user equipment from identifying the identity of at least one other user equipment.

According to a fourth aspect of the present invention there is provided a communication method within a communication system comprising first and second user equipment communicating on a shared floor and a server device configured to manage the shared floor, the above method The method includes the following steps: receiving an anonymous request from the first user equipment at the server device, preventing the second user equipment from identifying the identity of the first user equipment in a user plane message sent from the first user equipment to the second user equipment.

According to a fifth aspect of the present invention, there is provided a communication system, comprising: first and second user equipment communicating over a shared floor; and a control server for managing the shared floor; for serving the above-mentioned at least one participating server of two user equipments; wherein the control server is configured to detect an anonymous request from the first user equipment and to insert a confidentiality indication in a user plane message from the first user equipment, and when the participating server responds to said confidentiality Preventing the second user equipment from identifying the identity of the first user equipment when the sex indication is used.

Description of drawings

For a better understanding and practice of the invention, reference will now be made to the accompanying drawings, by way of example only, in which:

Figure 1 shows a schematic diagram of a typical communication network incorporating an embodiment of the present invention;

Figure 2 shows a schematic diagram of a push-to-talk communication network implemented within the communication network of Figure 1;

Fig. 3 shows a flow chart representing the right-to-speak control program incorporating the first embodiment of the present invention;

Figure 4 shows a schematic diagram of an RTCP 'speak request' data packet incorporating the first embodiment of the present invention;

Fig. 5 shows a schematic diagram of the RTCP 'right to speak' data packet combined with the first embodiment of the present invention; and

Fig. 6 shows a schematic diagram of a 'PRIV' source description data packet in conjunction with another embodiment of the present invention.

Detailed ways

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

The 3rd Generation Partnership Project (3GPP) has defined a baseline architecture for a 3rd generation (3G) core network that will provide users of user equipment with access to multimedia services. This core network is divided into three main domains. There are Circuit Switched (CS) domains, Packet Switched (PS) domains and Internet Protocol Multimedia Subsystem (IMS) domains.

Figure 1 shows an IP multimedia network 45 for providing IP multimedia services to IP multimedia network subscribers. IP Multimedia Subsystem (IMS) functionality may be provided by a Core Network (CN) subsystem comprising various entities for providing services. The Third Generation Partnership Project (3GPP) has defined the use of the General Packet Radio Service (GPRS) for providing IP connectivity for IMS services. Therefore, a GPRS based system will be used in the following example of a possible backbone communication network supporting IMS services.

Mobile communication systems, such as 3G cellular systems, are usually configured to serve a plurality of mobile user equipment, usually over a radio interface between the user equipment and a base station of the communication system. A mobile communication system can be logically divided into a Radio Access Network (RAN) and a Core Network (CN). Core network entities typically include various control entities and are used to enable communication over multiple radio access networks and to interface a single communication system with one or more communication systems such as other cellular systems and/or fixed line communication systems gateway.

In FIG. 1, an intermediate mobile communication network provides packet-switched data transmission in the packet-switched domain between support nodes 33,42 and mobile user equipment 30,44. The different sub-networks are then connected to an external data network, for example via a Gateway GPRS Support Node (GGSN) 34, 40 to a Packet Switched Data Network (PSDN). The GPRS service thus allows the transmission of packet data between mobile data terminals and/or external data networks. More specifically, the exemplary GPRS operating environment includes one or more sub-network service areas interconnected by GPRS backbone networks 32 and 41 . The sub-network includes many packet data service nodes (SN). In this embodiment, the Service Node will be called Serving GPRS Support Node (SGSN). Each of the SGSNs 33,42 is connected to at least one mobile communication network, typically to a base station system 31,43. Although not shown for clarity, the connection may be provided by means of a radio network controller or other access system controller such as a base station controller, in this way packet services may be provided to mobile user equipment through several base stations.

The base stations 31 and 43 are configured to transmit signals to and receive signals from mobile users, ie subscribers' mobile user equipment 30 and 44, via respective radio interfaces. Accordingly, each mobile user equipment is capable of sending signals to and receiving signals from the base station via the radio interface. In the simplified representation of Fig. 1, base stations 31 and 43 belong to respective radio access networks (RAN). In the configuration shown, each of the user equipments 30 and 44 has access to the IMS network 45 through two access networks associated with the base stations 31 and 43 respectively. It will be appreciated that although Fig. 1 only shows the base stations of two radio access networks, a typical mobile communication network usually includes many radio access networks.

The IMS domain is used to ensure adequate management of multimedia services. IMS domains typically support the Session Initiation Protocol (SIP) developed by the Internet Engineers Task Force (IETF). Session Initiation Protocol (SIP) is an application layer control protocol for creating, modifying and terminating sessions with one or more participants (endpoints). SIP was generally developed to allow the initiation of a session between two or more end points in the Internet by making those end points aware of session semantics. A user connected to a SIP-based communication system can communicate with various entities of the communication system based on standardized SIP messages. A user device, or a user running an application on a user device, registers with the SIP backbone so that invitations for a particular session can be properly submitted to these endpoints. SIP provides a registration mechanism for devices and users, and it applies mechanisms such as location servers and registrars to route session invitations appropriately. Examples of correct possible sessions that may be provided by SIP signaling include Internet multimedia conferencing, Internet telephony calls, and multimedia distribution.

User equipment within a radio access network can communicate with a radio network controller over a radio network channel, commonly referred to as a radio bearer. There may be one or more open radio channels between each user equipment and the radio network controller at any time. Any suitable mobile user equipment adapted for Internet Protocol (IP) communications may be used to connect to the network. For example, a user may rely on user equipment such as a personal computer, personal data assistant (PDA), mobile station (MS), portable computer, or combinations thereof, to access a cellular network.

User equipment is used for tasks such as making and receiving telephone calls, receiving and sending data from and to a network, and experiencing, for example, multimedia content. User equipment is typically equipped with processors and memory to perform these tasks. The user equipment may comprise an antenna to wirelessly receive signals from and transmit signals to a base station of the mobile communication network. The user equipment may also be equipped with a display for displaying images and other graphical information to the user of the mobile user equipment. It can also be equipped with speakers. The operation of the user equipment may be controlled by means of a suitable user interface, such as a keypad, voice commands, a touch-sensitive screen or pad, combinations thereof, and the like.

The user equipment 30 and 44 of Figure 1 are configured to enable use of push-to-talk services. Activation functions that may be required for a push-to-talk service may be provided by buttons on the keypads of the mobile stations 30 and 44, or by specific keys or buttons of the same type as a 'walkie-talkie' device, for example.

It will be appreciated that Figure 1 shows only two user equipments for clarity. In fact, many user equipments can communicate with each base station at the same time. A user equipment can have several simultaneous sessions, eg many SIP sessions and active PDP contexts. For example, a user can make a phone call and be connected to at least one other service at the same time.

All communication between the user equipment in the access entity and the GGSN is provided by the PDP context. Each PDP context provides a communication path between a specific user and the GGSN. Once a PDP context is established, it is usually capable of carrying multiple flows. Each flow typically represents, for example, a specific service and/or a service-specific media component. A PDP context thus often represents a logical communication path for one or more flows through the network. In order to realize the PDP context between the user equipment and the serving GPRS support node, it is necessary to establish a radio access bearer which generally allows user equipment data transfer.

The development of communication systems makes it possible to provide services to user equipment by means of different functions of the IMS network 45 handled by network entities and served by servers. In the current 3G wireless multimedia network architecture, it is assumed that several different servers are used to handle different functions. This includes functions such as the Call Session Control Function (CSCF). Call session control functions can be divided into different categories such as 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.

The user equipment 30, 44 may be connected via the GPRS network to an application server usually connected to the IMS. In FIG. 1 , this application server is provided by a Push to Talk over Cellular (PoC) service server 50 . In some embodiments of the invention, the PoC server may be implemented as a server device comprising a series of participating PoC servers connected to the controlling PoC server. The participating PoC servers send and receive data traffic from the user equipment, and also send and receive data traffic from the controlling PoC server. The Control PoC Server sends and receives data traffic from the Participating PoC Servers and controls access to the PoC Shared Floor depending on the information received from the Participating Servers. In another embodiment of the present invention, a participating PoC server also functions as a controlling PoC server.

Figure 2 shows a further diagram of the communication system of Figure 1 in relation to a Push-to-talk over Cellular (PoC) system. Figure 2 shows a network of user equipment units UE1 30, UE2 44, UE3 102, UE4 104 communicating over a Push to Talk over Cellular telecommunication system. UE1 30 is connected to a first participating PoC server 101, which is connected to a controlling PoC server 50. UE2 44 is connected to a second participating PoC server 103 connected to the controlling PoC server 50. UE3 102 is connected to a third participating PoC server 105 connected to the controlling PoC server 50. The UE4 104 is connected to a fourth participating PoC server 107 connected to the controlling PoC server 50 . In such a system, the mobile user equipments UE1, UE2, UE3 and UE4 may be from four different IMS networks.

The PoC participating servers 101 , 103 , 105 , 107 and the controlling PoC server 50 provide Push-to-talk over Cellular (PoC) services through the IMS network 45 . Push-to-talk services are examples of so-called direct voice communication services. Users who wish to use the PoC service may need to subscribe to an appropriate PoC server.

The direct voice communication service is used to utilize the performance of the GPRS backbone and the control function of the multimedia subsystem to realize the IP connection with the user equipment UE1 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.

The user can open the communication link, for example, by pressing a specific activation button on the user equipment UE130. When the user of UE1 30 speaks, the users of UE2 44, UE3 102 and UE4 104 listen. Then, the user of the user equipment UE2 44 can answer in a similar manner. Signaling between the user equipment and the appropriate call session control function is routed through the GPRS network. User plane sessions are set up for user equipment signaling and routed through the participating PoC servers 101 , 103 , 105 , 107 and controlled by the controlling PoC server 50 . In other words, the PoC server controls the PoC user's control plane (for signaling) and user plane (for user data). Participating in the control plane traffic between the PoC server and the user equipment can be routed through the IMS, while the user plane traffic between the user equipment and the PoC server is routed from the GPRS system to the PoC server on interfaces 54 and 56 (as shown in Figure 1 Show).

As mentioned above, the push-to-talk service is based on multipoint unicast. Each sending User Equipment UE1 30, UE2 44, UE3 102, UE4 104 sends packet data traffic to a push-to-talk dedicated server, and in case of a group call, the server then replicates this traffic for all recipients. To control the communication system, 'user plane' messages can be passed from one user to the rest of the system and vice versa. One type of data communication packet in the user plane is to inform which user is sending or which user has received permission to use the floor. This information may be a 'speaking taken' message. This 'Floor Taken' message is received by user equipment that is going to receive RTP traffic from a user who has taken control of the floor. These control packets are based on the previously described Real Time Control Protocol (RTCP) packets, a subset of the Real Time Protocol (RTP).

To help understand the invention, a situation will be described where the users UE1 30, UE2 44, UE3 102, UE4 104 are all related to a group communication, and the user using the user equipment UE4 104 wishes to speak and at the same time requests to hide his identity from other parties.

Referring to Figure 3, a flow chart describing the operation of one embodiment of the present invention is shown. For clarity, in this example PoC client A refers to user equipment UE4 104, participating PoC server A refers to participating PoC server 107, controlling PoC server X refers to controlling PoC server 50, PoC server B refers to the first participating PoC server 101, and PoC Client B refers to the corresponding user equipment UE130. Although a one-to-one communication is described in this example, it will be appreciated that the same approach can be applied to a one-to-many communication where the PoC server is controlled to replicate the message for each recipient.

In a first step 201, the PoC Client A104 sends a 'Speak Request' message to the participating PoC Server A107. This 'speak request' message includes Client A's speaker or user identity, and a request for anonymity.

The second step 203 takes place after the participating PoC server A 107 has received the speak request. In this step, the participating PoC server A107 forwards the 'Request to Speak' including the identity of the speaking party and a request for anonymity to the controlling PoC server X50.

The controlling PoC server X50 may perform authentication of the client to determine that the client is authorized to participate in the PoC communication group. If the PoC client A104 is allowed to speak, ie no other users occupy the floor, the controlling PoC server X50 initiates the first step 205 and the second step 207 .

The first step 205 initiated by the controlling PoC server is that the controlling PoC server X50 forwards a 'speaking right acquired' message to the participating PoC server B101. The 'take the floor' message includes the speaker identity and anonymity request from client A 104.

The second step 207 initiated by the controlling PoC server is that the controlling PoC server X50 sends a 'speak authorized' message to the participating PoC server A107. In other embodiments of the invention, the controlling PoC server X50 sends a 'Speak Authorized' message which is processed by the system in a similar manner to the 'Speak Authorized' message. In the following step 209, the participating PoC server A sends to the PoC client A 104 the 'speak authorized' message received in the previous step. This 'speak authorized' message allows client A to send talk bursts within the group, i.e. broadcast any message it wants to send to the group.

Participating PoC server B101 receives the 'speaking right acquisition' message including speaker identity and anonymity request information from controlling PoC server X50. Participating PoC Server B 101 recognizes the anonymous request and removes the speaker's identity from the 'take the floor' message. Participating PoC server B101 generates a new 'speaking right acquired' message in step 251 . Then, the participating PoC server B101 sends this new 'speaking right acquisition' message that does not include the user identification feature to the PoC client B30 in step 211.

With respect to Figures 4 and 5, examples of 'request to speak' and 'take floor' messages including speaker identity and a request for anonymity are shown.

With respect to Figure 4, packets based on the Real Time Control Protocol (RTCP), such as for delivering 'speak request' data packets, are shown in connection with a first embodiment of the invention.

The 'Speak Request' RTCP packet is sent from the PoC Client A 104 to the Participating PoC Server 107 and is forwarded by the Participating PoC Server A 107 to the Controlling PoC Server X50 in order to request permission from the Controlling Server to send speech to other users.

The 'Request to Speak' RTCP packet consists of a 32 bit wide datagram. The first line of the datagram includes a series of information values, version indicator (V) 303 (2 bits), padding bits (P) (1 bit) 305, source count 307A (5 bits), payload type (PT ) (8 bits) 309, and a length indicator (LENGTH) 311.

As defined in IETF RFC 3550 section 6.5, the version indicator 303 indicates the version of RTP to use, in this example version 2. Pad bits 305 indicate whether the packet contains one or more pad octets. The source count is used to identify which subtype defines which of the various RTCP packets the current packet is. In the example shown in Figure 4, a value of 10000 indicates that this is a 'talk request' RTCP packet modified in that the user requesting the talk request wishes to remain anonymous to the other users of the group. The payload type (PT) 107 defines the format of the RTCP payload, which is equal to APP or 204 in the example shown. 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 additional 32-bit words.

The second line of the datagram includes a synchronization source identifier (SSRC) 313, which identifies the synchronization source to the originator of the packet. In the example shown, the packet is a 'Speak Request' packet and SSRC 313 is the identifier of PoC Client A 104.

The third and last line of the RTCP packet includes the address 'name' 315 presented for the user equipment. The 'Name' field can also be used to indicate the application release version.

At the end of step 201 , once this packet is received by participating server A, it is forwarded in step 203 to the controlling PoC server X50.

With respect to Fig. 5, packets based on the Real-Time Control Protocol (RTCP), such as for delivering a 'Speaking Taken' message data packet, are shown in connection with the first embodiment of the present invention.

According to the method described above, two types of 'speaking taken' messages are used. A first type of 'take the floor' RTCP packet is sent over the network from the controlling PoC server 50 to the participating PoC server, eg the first participating PoC server 103 . The second type is sent from participating PoC servers to user equipment, such as UE 130, and prepares the user equipment to receive RTP packets from user equipment that has been granted the floor. Both the first and the second type can be described with respect to FIG. 5 .

'Take the floor' RTCP packets consist of datagrams with a width of 32 bits.

The first line of the datagram includes a series of information values, version indicator (V) 303 (2 bits), padding bits (P) (1 bit) 305, source count (5 bits) 307b, payload type (PT ) (8 bits) 309, and a length indicator (length) 311b.

As defined in IETF RFC 3550 section 6.5, the version indicator 303 indicates the version of RTP to use, in this example version 2. Pad bits 305 indicate whether the packet contains one or more pad octets. The source count 307b is used to identify which subtype defines which of the various RTCP packets the current packet is. In the example shown in Figure 5, the value 10010 indicates that this is a modified 'Take the floor' RTCP packet where the user requests anonymity (in contrast to the subtype 00010 of the 'Take the floor' RTCP packet which represents the rule) . The payload type (PT) 309 defines the format of the RTCP payload, which is equal to APP or 204 in the example shown. The length indicator (length) 109 describes the length of the packet in 32-bit words, not counting the first word.

The second line of the datagram includes a synchronization source identifier (SSRC) 313b, which identifies the synchronization source for the originator of the packet. In the example shown, the packet is a modified 'Take the Floor' packet and the SSRC 313b is the identifier of the controlling PoC server 50.

The third line of the RTCP packet includes the address (name) 315b presented for the Push-to-talk over Cellular (PoC) server. The 'Name' field can also be used to indicate the application release version.

The fourth and other lines of the packet include an information block 317 .

For the first type of 'speaking taken' message, the information block includes two Source Description (SDES) items.

The first source description item 321 includes a canonical name (CNAME). The name of the specification includes the name of user 323's specification. The canonical name of a user 323 is defined as a unique identifier assigned to that user/user device combination. An example of such a unique identifier is a SIP Uniform Resource Indicator (URI), such as that shown in FIG.

'dave.bowman@poc.operator.com'.

The second source description item 325 includes a display name (name). The display name includes the user's 327 display name. The display name of a user 327 is an identifier displayed by the user device to represent the user/user device combination. An example of such an identifier is an alphanumeric string, such as 'DaveB' shown in FIG. 5 .

Once Participating PoC Server B 103 has received the Floor Take Anonymous Packet, Participating PoC Server B processes the 'Floor Take' message to delete the user's canonical name (CNAME) and display name (NAME). In some embodiments of the invention, the CNAME and NAME values may give a unique anonymous name. In this case, the user may remain anonymous to the user, but the authorizing party can still link the message to the specific user given the specific relationship between the unique anonymous name and the user's name.

In other embodiments of the invention, the subtype of the 'speaking taken' message reverts to the normal subtype of the 'speaking taken' message. In such an embodiment, it is thus possible to prevent the receiving user equipment from detecting that the sending user equipment has requested anonymity.

In the above case, the user can remain anonymous in front of other clients and user devices after the request, but can still be monitored by authorized parties at the controller.

Although the above examples have been described by providing an anonymous request within the subtype field of the RTCP floor control packet, it will be appreciated that in other embodiments of the invention the indicator may be located within other parts of the floor control message.

In another embodiment, an anonymous request is indicated using a modified payload type. The controlling PoC server and participating PoC servers are able to recognize this modified payload type to provide the required anonymity.

In another embodiment, an anonymous request may be indicated by providing an additional SEDS field in combination with an anonymous or alternative identity from the user.

In another embodiment of the present invention, the anonymous request in the floor control message may be indicated by adding an additional custom field to the packet.

In an example of adding an additional SDES field that includes an anonymous identity, a first type of 'take the floor' message sent from the controlling PoC server 50 to the participating PoC server B 103 carries the anonymous information along with an SDES field containing the user's anonymous ID . A second type of 'speaking taken' message from the participating PoC server 103 to the receiving PoC client 30 includes only anonymous information, ie the user's ID is removed before being forwarded to the PoC client B30.

In other embodiments of the present invention, the anonymous or optional identity is not provided as an additional SDES field, but is combined with the original SDES field information in order to form a compound SDES field. For example, the display name in the first type of 'speaking taken' message can contain the data, "name +++ anonymous ID", where 'name' is the user's display name and the string '+++' is the delimited character, and the 'anonymous ID' is the name sent to the other user in the second type of 'take the floor' message.

In other embodiments of the present invention, the anonymous information or groups or elements are enhanced on the basis of known 'speaking' groups. In such an embodiment, a first 'take the floor' RTCP packet including source descriptive information including the canonical user name and the displayed user name is combined with a second packet containing anonymous information to form a compound RTCP packet.

In another embodiment of the present invention, a 'take the floor' RTCP packet known in the art is directly followed by a second RTCP packet containing anonymous information. This second packet is a predetermined Real-Time Control Protocol (RTCP) Application (APP) packet.

In another embodiment, the anonymous identifier source description item PRIV generates a PoC-specific private extension that conveys the anonymous information.

Referring to FIG. 6, an example of a PRIV message packet including anonymous information is shown. The PRIV packet 501 includes a value string 503 containing the anonymous information, ie the indicator and/or any anonymous ID.

In another embodiment of the invention, the user's canonical name may be the user's Tel URL/URI. The Tel URL/URI is the SIP equivalent of the user equipment telephone number used in the Public Switched Telephone Network (PSTN).

In another embodiment of the present invention, the controlling PoC server remembers the fact that the user requested anonymity during user initiation. This request can be implemented using the SIP protocol described in IETF RFC3325 and/or IETF RFC3323. In this embodiment, the controlling PoC server checks for any speak or floor request messages and applies confidentiality should the user request it, i.e. the controlling PoC server sends a 'speak taken' message if it receives a 'speak request' message containing an anonymous request. 'information.

Embodiments of the invention may use other types of floor control messages, or even other types of messages, to provide the information. Examples of other types of messages include media messages.

Embodiments of the present invention may also use other protocols than RTCP to send user and control plane messages.

In another embodiment of the present invention, wherein the control server sends a message to the user equipment served by the participating server in the untrusted network, the control PoC server completes the information from the forwarded message before forwarding the message to the participating server in the untrusted network. Remove any task of identifying features.

In other embodiments of the invention, the user device may send the anonymous value as the user display name. In these embodiments, rather than the system being configured to strip out the anonymous value, the value is simply forwarded. Thus, within such a system, users still maintain their confidentiality.

Claims (26)

1. A communication system comprising: first and second user devices communicating over the shared floor; and a server device for managing the shared floor; Wherein, the server device is configured to detect an anonymous request from the first user equipment, and Wherein, in response to the anonymous request, the server device is configured to prevent the second user equipment from identifying the identity of the first user equipment from at least one user plane message sent by the first user equipment to the second user equipment. 2. The system according to claim 1, wherein the first user equipment is configured to initiate a connection with the second user equipment through the server device using a first protocol. 3. The communication system of claim 2, wherein the first protocol comprises Session Initiation Protocol (SIP). 4. The system of claim 1, wherein the first user equipment is configured to communicate with the second user equipment over an existing connection through the server means using a first protocol. 5. The system of claim 4, wherein the second protocol comprises Real Time Control Protocol (RTCP). 6. The system of claim 4, wherein the at least one user plane message is sent using the second protocol. 7. The system of claim 1, wherein the communication system comprises a push-to-talk over wireless communication system. 8. The system of claim 7, wherein the at least one user plane message comprises a floor control message. 9. The system of claim 8, wherein the at least one user plane message comprises a floor take message. 10. The system of claim 7, wherein the at least one user plane message comprises a media message. 11. The system according to claim 8, wherein said server means is configured to delete the identity of the first user from said at least one user plane message. 12. The system of claim 11, wherein the server device is further configured to insert a unique anonymous token in the at least one user plane message. 13. The system of claim 12, wherein the unique anonymous token is stored in the at least one user plane message as at least part of a source description item. 14. The system according to claim 1, wherein the server means is configured to delete the identity of the first user from the at least one user plane message before sending it to the second user equipment. 15. The system of claim 1, wherein the at least one user plane message from the first user equipment comprises a Uniform Resource Identifier (URI) of the first user equipment and a display name of the first user equipment Identification information of at least one of . 16. The system of claim 1, wherein the anonymous request is comprised of at least one of the following: a subtype of the at least one user plane message; the payload type of the at least one user plane message; an additional source description (SDES) field within the at least one user plane message; and Additional custom fields. 17. The system of claim 1, wherein the at least one user plane message comprises a floor request or a speak request message. 18. The system according to claim 1, wherein the server device comprises: control server; and A participating server, wherein the control server is configured to receive the anonymous request from the first user device, and wherein the participating server is configured to send the at least one user plane message. 19. The system according to claim 18, wherein the control server is configured to send a second user plane message to the participating server, the second user plane message including the identity of the first user equipment and a confidentiality indication, wherein The participating server is configured to receive the second user plane message and, in response to the indication of confidentiality, prevent the second user equipment from identifying the first user equipment. 20. The system of claim 18, wherein the second user plane message confidentiality indication is provided by at least one of: the subtype of the second user plane message; the payload type of the second user plane message; an additional SDES field in the second user plane message; Additional custom fields. 21. A server device configured to operate in a communication system, the communication system further comprising a first user device and a second user device communicating over a shared floor, wherein: The server means is configured to manage the shared floor to detect an anonymous request from the first user device, and in response to the anonymous request, prevent the second user device from sending from the first user device to the second user device The identity of the first user equipment is identified in at least one user plane message of . 22. A user equipment configured to operate in a communication system on a shared floor, the communication system comprising: the User Equipment; and Server means configured to manage the shared floor, wherein at least one of the user equipments is configured to receive a user plane message from said server means preventing the at least one user equipment from identifying the identity of at least one other user equipment. 23. A method of communicating within a communication system comprising first and second user equipment communicating over a shared floor, and server means configured to manage the shared floor, said method comprising the steps of: receiving an anonymous request from the first user equipment at said server device; and The second user equipment is prevented from identifying the identity of the first user equipment from at least one user plane message sent by the first user equipment to the second user equipment. 24. A communication system comprising: first and second user equipment communicating over the shared floor; a control server for managing the shared floor; and at least one participating server for serving said second user equipment, wherein the control server is configured to detect an anonymous request from the first user equipment, insert a confidentiality indication in a user plane message from the first user equipment, and, when the at least one participating server responds to the confidentiality indication, The second user equipment is prevented from identifying the identity of the first user equipment. 25. A server configured to operate in a communication system, the communication system further comprising first and second user devices communicating over a shared floor, wherein the server is configured to manage a shared floor to detect an anonymous request from the first user device and, in response to the anonymous request, prevent the second user device from sending from the first user device to the second user device The identity of the first user equipment is identified in at least one user plane message of . 26. A user equipment configured to operate in a communication system on a shared floor, the communication system comprising: A server configured to manage the shared floor, wherein at least one of the user equipments is configured to receive a user plane message from said server preventing the at least one user equipment from identifying the identity of at least one other user equipment.

Images