A communication system

The present invention relates to a communication system, and particularly to a communication system used for a push-to-talk service via a cellular network, but does not exclude others.

A communication system can be seen as a feature that enables a communication session between two or more entities such as user equipment and / or other nodes associated with the communication system. Communication includes, for example, communication of voice, data, multimedia, and their analogs. The session may be, for example, a telephone call type session between users, a multi-dimensional conference session, or a communication session between a user device and an application server (AS) such as a service provider server.

Typically, a communication system operates according to a particular standard or specification that defines what the various entities associated with the communication system can do and how it is desirable to achieve it. For example, a standard or specification can define whether a user, or more specifically a user device, can use circuit-switched services and / or packet-switched services. Communication protocols and / or parameters to be used for the connection may also be defined. In other words, a set of specific rules that communication can base on to enable communication is defined.

Communication systems that provide wireless communication to user devices are known. An example of a wireless system is the Public Land Mobile Network (PLMN). PLMNs are usually based on cellular technology. In a cellular system, a base station (BTS) or similar connecting entity serves a mobile user device (UE) via a wireless interface between them. Communication on the wireless interface between the user device and the elements of the communication network can be based on the appropriate communication protocol. The operation of the base station equipment and other equipment required for communication can be controlled by one or several control entities. Various control entities can be interconnected.

To connect a cellular network to other networks, such as public switched telephone networks (PSTNs) and / or other communication networks such as IP (Internet Protocol), and / or other packet exchange data networks, 1 The above gateway nodes can be used. In such a configuration, the mobile communication network provides a connection network so that a user with a wireless user device can connect to an external network, host or service provided by a particular service provider. ..

An example of a service type provided to a user, such as a subscriber of a communication system, is a so-called multimedia service. Some communication systems that can provide multimedia services are known as Internet Protocol multimedia networks. IP multimedia functionality can be provided by the IP Multimedia Subsystem (IMS). IMS includes various network entities for the provision of multimedia services. The IMS service is intended to provide IP-based packet data communication sessions between mobile user devices among the services.

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

Different types of services are provided by different application servers (ASs) through IMS. Time is important for some of these services. An example of a time-critical service that can be provided via IMS is the so-called direct voice communication service. An example of this type of service is the "Push-to-Talk" (PoC) service, also known as the PTT (Push-to-Talk Service). Direct voice communication services are intended to harness the power of IMS to allow IP connections between user equipment and other communication partners such as other user equipment or network-related entities. This service allows users to instantly communicate with one or more users.

The principle behind push-to-talk (PoC) communication systems over cellular networks is to implement the capabilities of walkie-talkie on standard mobile phones. The user simply selects the person or group of people he / she wants to talk to from his / her mobile phone and presses the push-to-talk key on his / her mobile phone to talk. The operation can be performed using a particular button, tangent or any other suitable key on the keyboard. Similar principles apply to devices with touch sensors or voice user interfaces. When one user talks, another user can hear it. Two-way communication is provided because all participants in a communication session can similarly send and receive voice data to and from the PoC application server. The order of remarks is requested by manipulating the push-to-talk button or its analogs. The connection response time is almost instantaneous.

Push-to-talk calls are typically half-duplex communication. That is, while one user is speaking, the other users only listen. The order of speech is allowed on a first-come, first-served basis or by priority by pressing the push-to-talk key. Push-to-talk calls are usually connected without a receiver response and are typically heard through a speaker built into the mobile phone.

Since this system is built into a cellular communication system, it offers a wider range of coverage than traditional two-way wireless systems. Push-to-talk services can be implemented using push-to-talk servers within the IP Multimedia Subsystem (IMS). The push-to-talk service is based on multi-unicast. Each transmitting mobile phone transmits a packet data traffic to a dedicated push-to-talk server (participating server). The control server receives traffic and manages a shared floor for group calls. The control server replicates the traffic so that it can be received by all recipients. Multicast is not performed on either the GPRS connection network or the wireless connection network.

Push-to-talk via cellular communication systems is described in the provisional push-to-talk via cellular communication systems such as "OMA Push to talk over Cellular (PoC) -Architecture".

Groups of user devices that communicate using a PoC system are created in a variety of ways. The Internet Engineering Task Force (IETF) has defined one such system that uses such a Session Initiation Protocol (SIP) or Conference Policy Control Protocol (CPCP). Once the group is set up, the Real-Time Transport Protocol (RTP) streaming bearer carries voice and data control traffic. The PoC system uses a transfer protocol based on the IETF RFC 3550. RTP describes the architecture of a data packet and the syntax of the data stored in the packet that forwards voice and data information from user to user.

<p> Privacy and anonymity issues on PoC networks have not been addressed so far. A user of a PoC network may want to send a message, not give his identity to the final destination, and still notify one or more intermediaries of the identity.</p><p> There are several SIP protocols, such as IETF RFCs 3323 and 3325, that allow users to retain their identity while setting up an IMS connection, but how data in the Poc network maintains user anonymity? No discussion has been made.</p><p> Furthermore, there is no way to require users who join a group to talk to the group, while requesting other members of the group to keep their identity confidential. This, on the other hand, must still be done while sending its identity to the participating and control servers of the push-to-talk (PoC) system over the cellular network. Allow authorities to monitor the group by forwarding the identity to prevent illegal activity when the user's identity is confidential.</p><p> An object of the embodiments of the present invention is to treat or at least alleviate the above-mentioned problems.</p>

<p> According to the present invention, the first user device and the second user device that communicate via the shared floor and the server means for managing the shared floor are provided so as to detect the anonymity request from the first user device. The second user apparatus is subjected to the first user apparatus by at least one user plane message transmitted from the first user apparatus to the second user apparatus in response to the anonymity request and constitutes the server means. A communication system that constitutes the server means is provided so as to prevent the identification of the server means.</p><p> The first user device may be configured to initiate a connection with the second user device via the server means using the first protocol.</p><p> The first protocol may be Session Initiation Protocol (SIP).</p><p> The first user device is configured to communicate with the second user device over an existing connection via the server means, preferably using a second protocol.</p><p> The second protocol may be RTP Control Protocol (RTCP).</p><p> The at least one user plane message is preferably transmitted using the second protocol.</p><p> The communication system may constitute a push-to-talk communication system via a cellular network.</p><p> The user plane message is preferably a floor control message.</p><p> The user plane message is preferably a floor acquisition message.</p><p> The user plane message is preferably a media message.</p><p> The server means may be configured to remove the identification information of the first user from the at least one user plane message.</p><p> The server means may be further configured to insert a unique anonymous token into the at least one user plane message.</p><p> The unique anonymous token is preferably stored in the at least one user plane message, preferably at least as part of a source description item.</p><p> Preferably, the server means is configured to remove the identification information of the first user from the at least one user plane message before transmitting the at least one user plane message to the second user apparatus.</p><p> The at least one user plane message from the first user device may include identification information including a unified resource identifier (URI) of the user device and a display name of the user device.</p><p> Preferably, the subtype of the at least one user plane message, the payload type of the at least one user plane message, the additional source description (SDES) field in the at least one user plane message, and the additional dedicated field. At least one of them includes the anonymity request.</p><p> The user plane message is preferably a floor request message or a speech request message.</p><p> The server means includes a control server and a participating server, the control server is configured to receive the anonymity request from the first user apparatus, and the participating server receives the at least one user plane message. It may be configured to transmit.</p><p> Preferably, the control server is configured to transmit a second user plane message including the identification information of the first user device and privacy instruction information to the participating server, and the second user device is the second user. It is configured to prevent receiving a plain message and identifying the first user device in response to the privacy instruction information.</p><p> Preferably, by at least one of the subtype of the second user plane message, the payload type of the second user plane message, the additional SDES field in the second user plane message, and the add-only field. 2 Provides user plane message privacy instruction information.</p><p> According to the second aspect of the present invention, the server means is configured to operate in the communication system, and the communication system further includes a first user device and a second user device that communicate with each other via a shared floor. The server means is transmitted from the first user device to the second user device in response to the anonymity request by managing the shared floor and detecting the anonymity request from the first user device. A server means configured to prevent the first user device from being identified by at least one user plane message is provided.</p><p> According to the third aspect of the present invention, the user device is configured to operate in a communication system via a shared floor, and the communication system is configured to manage the user device and the shared floor. At least one of the user devices is configured to receive a user plane message from the server means that prevents the at least one user device from identifying at least one other user device. User equipment is provided.</p><p> According to the fourth aspect of the present invention, a communication method in a communication system including a first user device and a second user device that communicate via a shared floor and a server means configured to manage the shared floor. The second is due to the step of receiving the anonymity request from the first user device in the server means and at least one user plane message transmitted from the first user device to the second user device. A method is provided that has a step of preventing the user device from identifying the first user device.</p><p> According to the fifth aspect of the present invention, at least one that provides services to the first user device and the second user device that communicate via the shared floor, the control server that manages the shared floor, and the second user device. With one participating server, the control server detects anonymity request from the first user device, inserts privacy instruction information into a user plane message from the first user device, and participates in at least one of the participants. A communication system is provided that is configured to prevent the second user device from identifying the first user device when the server responds to the privacy instruction information.</p>

In order to better understand the present invention and how the same effect can be obtained, the accompanying drawings are referred to herein solely for illustrative purposes.

An embodiment of the present invention will be described as an example with reference to the architecture of the third generation (3G mobile communication system) as an example. However, it should be understood that the examples are applicable to any other suitable form of communication system.

The 3rd Generation Partnership Project (3GPP) has defined a reference architecture for 3rd generation (3G) core networks that allows users of user equipment to connect to multimedia services. This core network is divided into three main areas. It is a circuit-switched (CS) area, a packet-switched (PS) area, and an Internet Protocol multimedia subsystem (IMS) area.

Figure 1 shows the IP multimedia network 45, which provides IP multimedia services to IP multimedia network subscribers. IP Multimedia Subsystem (IMS) functionality can be provided by the Core Network (CN) subsystem, which contains various entities for service delivery. The 3rd Generation Partnership Project (3GPP) defined the use of General Packet Radio Service (GPRS), which provides IP connectivity to IMS services. Therefore, the GPRS system is used below as an example of a backbone communication network that may enable IMS services.

Mobile communication systems, such as typically 3G cellular systems, are typically configured to serve multiple user devices via a wireless interface between the user device and the base station of the communication system. The mobile communication system can be logically divided into a radio connection network (RAN) and a core network (CN). Typically, a core network entity allows communication with various control entities over multiple wirelessly connected networks, and one communication system can be one or more, such as other cellular systems and / or fixed line communication systems. Includes a gateway that allows you to interface with the communication system.

In FIG. 1, the intermediary mobile communication network provides packet-switched data transmission in a packet-switched region between support nodes 33,42 and mobile user devices 30,44. Various subnetworks are then connected to the external data network, for example to connect to a packet-switched data network (PSDN) via gateway GPRS support nodes (GGSN) 34,40. In this way, the GPRS service allows the transmission of packet data between mobile data terminals and / or external data networks. More specifically, the operating environment of the illustrated general packet radio service includes one or more subnetwork service ranges, and each service range is interconnected by GPRS backbone networks 32 and 41. The subnetwork contains several packet data service nodes (SNs). In this embodiment, the service node is referred to as a service providing GPRS support node (SGSN). SGSNs 33, 42 are each connected to at least one mobile communication network, typically base station systems 31, 43. Not shown for clarity, allowing packet services to be provided to mobile user equipment via several base stations by a wireless network controller, or other connected system controller such as a base station controller. , That connection can be provided.

Base stations 31 and 43 are configured to send and receive signals to and from mobile users, i.e., subscriber mobile user devices 30 and 44, via their respective wireless interfaces. Therefore, each mobile user device can send and receive signals to and from the base station via the wireless interface. In the simplified Figure 1, base stations 31 and 43 belong to their respective radio access networks (RANs). In the configured configuration, user devices 30 and 44 can be connected to the IMS network 45 via two connection networks associated with base stations 31 and 43, respectively. Although Figure 1 shows only the base stations of two wirelessly connected networks, it should be recognized that a typical mobile communication network usually contains several wirelessly connected networks.

The IMS domain is to ensure that multimedia services are properly managed. The IMS domain typically supports 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 points). In general, SIP was developed so that a session can be started between two or more endpoints in the Internet by making these endpoints aware of the meaning of the session. Users connected to a SIP-based communication system can communicate with various entities in the communication system based on standardized SIP messages. The user device running the application on the user device, the user, is registered in the SIP backbone so that invitations to a particular session are correctly delivered to their endpoints. SIP provides a registration mechanism for devices and users, and provides mechanisms such as location servers and registries so that session invitations can be delivered appropriately. Examples of suitable possible sessions can be provided by SIP signal notifications, including Internet multimedia conferences, Internet telephone calls, and multimedia distribution.

A user device in a wirelessly connected network can communicate with a wireless network controller, typically via a wireless network channel called a wireless bearer. Each user device can use one or more wireless channels at the same time with the wireless network controller at any time. Any suitable mobile user device adapted for Internet Protocol (IP) communication can be used to connect to the network. For example, a user can connect to a cellular network by a user device such as a personal computer, a personal digital assistant (PDA), a mobile computer (MS), a portable computer, a combination thereof or the like.

User devices are used for processing such as making and receiving telephone calls, sending and receiving data to and from networks, and experiencing multimedia contents, for example. Typically, the user equipment includes a processor and memory for performing these processes. The user device may include an antenna for wirelessly transmitting and receiving signals to and from a base station of a mobile communication network. The user device may also include a display for displaying images and other graphic information to the user of the mobile user device. A speaker may be provided. The operation of the user device can be controlled by an appropriate user interface such as a keypad, voice command, touch screen or touch pad, a combination thereof, or the like.

The user devices 30 and 44 in FIG. 1 are configured to use push-to-talk type services. The operational functions required for the push-to-talk service can be provided by one of the keypad buttons on the mobile devices 30 and 44, or by a specific key or a type of button known as a "walkie-talkie" device.

Recognize that Figure 1 shows only two user devices for clarity. In reality, several user devices can communicate with each base station at the same time. The user device can have several simultaneous sessions, for example several SIP sessions and an activated PDP context. For example, a user can connect to at least one other service at the same time while making a call.

The entire communication between the user equipment and the GGSN within the connecting entity is provided by the PDP context. Each PDP context provides a communication path between a particular user and the GGSN. Once the PDP context is established, it can typically carry multiple flows. Each flow usually means, for example, a specific service and / or a media component of a specific service. Therefore, the PDP context often refers to the logical communication path of one or more flows through the network. In order to implement the PDP context between the user equipment and the service providing GPRS support node, it is usually necessary to establish a wireless connection bearer that enables data transfer of the user equipment.

Communication systems have been developed so that they can be serviced to user equipment by the various functions of the IMS network 45, which are processed by network entities and serviced by servers. In the current 3G wireless multimedia network architecture, it is believed that several different servers handle different functions. These include features such as the Call Session Control Function (CSCF). The call session control functions are the proxy call session control function (P-CSCF) 35,39, the interrogating call session control function (I-CSCF) 37, and the service provision call session control function (S-CSCF) 36, It can be divided into various categories such as 38.

User devices 30 and 44 can be connected to an application server that is generally connected to IMS via a GPRS network. In Figure 1, such an application server is a push-to-talk (PoC) service server 50 over a cellular network. In some embodiments of the invention, the PoC server can be implemented as a server means that constitutes a series of participating PoC servers connected to the control PoC server. The participating PoC server sends and receives data traffic to and from the user device, and also sends and receives data traffic to and from the control PoC server. The control PoC server sends and receives data traffic to and from the participating PoC server, and controls the connection to the PoC shared floor according to the information received from the participating server. In a further embodiment of the invention, one participating PoC server also acts as a control PoC server.

Figure 2 shows a further diagram of the communication system of Figure 1 for a push-to-talk (PoC) system over a cellular network. Figure 2 shows the networks of user devices UE1 30, UE2 44, UE3 102, and UE4 104 that communicate via a push-to-talk communication system via a cellular network. UE1 30 is connected to the first participating PoC server 101, and the first participating PoC server is connected to the control PoC server 50. UE2 44 is connected to the second participating PoC server 103, and the second participating PoC server is connected to the control PoC server 50. UE3 102 is connected to the third participating PoC server 105, and the third participating PoC server is connected to the control PoC server 50. UE4 104 is connected to the 4th participating PoC server 107, and the 4th participating PoC server is connected to the control PoC server 50. In such a system, the mobile user devices UE1, UE2, UE3, UE4 may belong to four different IMS networks.

The PoC participating servers 101, 103, 105, 107 and the control PoC server 50 provide a push-to-talk (PoC) service via the cellular network via the IMS network 45. The push-to-talk service is an example of a so-called direct voice communication service. Users who want to use the PoC service need to subscribe to an appropriate PoC server.

The direct voice communication service is intended to utilize the capabilities of the GPRS backbone and the control capabilities of the multimedia subsystem to enable IP connectivity between the user equipment UE1 30, UE2 44, UE3 102, UE4 104. ing. The PoC server may be operated by the operator of the IMS system, or may be operated by a third-party service provider.

For example, the user can open a communication link by pressing a specific operation button on the user device UE1 30. While the UE1 30 user is speaking, the UE2 44, UE3 102, and UE4 104 users only listen. The user of the user device UE2 44 can then answer in a similar way. Signal notifications between the user device and the appropriate call session control function are delivered via the GPRS network. The user plane session sets the signal notification of the user device, is delivered via the participating PoC servers 101, 103, 105, 107, and is controlled by the control PoC server 50. In other words, the PoC server controls both the control plane (for signal notification) and the PoC user's user plane (for user data). The control plane traffic between the participating PoC server and the user equipment is delivered via IMS, while the user plane traffic between the user equipment and the PoC server is delivered from the GPRS system to the PoC server on interfaces 54 and 56. (See Figure 1).

As mentioned earlier, push-to-talk services are based on multi-unicast. Each transmitting user device UE1 30, UE2 44, UE3 102, UE4 104 sends the packet data traffic to a dedicated push-to-talk server, and in the case of a group call, the server then duplicates the traffic for all recipients. To do. To control the communication system, "user plane" messages can be forwarded 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 "floor acquisition" message. This "floor acquisition" information is received by the user equipment that receives the RTP traffic from the user who acquired the control of the floor. These control packets are based on the RTP Control Protocol (RTCP) packets that are paired with the Real-Time Transport Protocol (RTP) described earlier.

In order to help the understanding of the present invention, the user devices UE1 30, UE2 44, UE3 102, UE4 104 are involved in group communication, and the user using the user device UE4 104, on the other hand, keeps his / her identification information secret from others. Explain the situation in which you want to speak, demanding that.

FIG. 3 is a flow chart illustrating an embodiment of the present invention in operation. To be clear, in this example PoC client A points to user equipment UE4 104, participating PoC server A points to participating PoC server 107, control PoC server X points to control PoC server 50, and PoC server B. Points to the first participating PoC server 101, and PoC client B points to the corresponding user device UE1 30. One-to-one communication is described in this example, but the same method can be applied to one-to-many communication in which the controlling PoC server replicates the message to each recipient.

In the first step 201, the PoC client A 104 sends a "speak request" message to the participating PoC server A 107. This "speak request" message includes the user identification information and anonymity request of the speaker, that is, client A.

The second step 203 occurs after the participating PoC server A 107 receives the speech request. In this step, participating PoC server A 107 transfers a "speaking request" including speaker identification information and anonymity request to control PoC server X 50.

The control PoC server X 50 can authorize the client to determine if it is authorized to join the PoC communication group. When PoC Client A 104 is allowed to speak, i.e. no other user occupies the floor, Control PoC Server X 50 initiates Step 205 and Step 207.

In the first step 205, which is started by the control PoC server, the control PoC server X 50 forwards the "get floor" message to the participating PoC server B 101. The "Get Floor" message contains speaker identification information and anonymity request from client A 104.

In the second step 207, which is started by the control PoC server, the control PoC server X 50 sends a "speaking permission" message to the participating PoC server A 107. In another embodiment of the invention, the control PoC server X 50 sends a "floor permission" message that the system processes in a manner similar to the "speak permission" message. In the next step 209, the participating PoC server A sends the "speaking permission" message received from the previous step to the PoC client A 104. This "speak permission" message allows client A to send a speech burst into the group, i.e. broadcast any message that it wishes to send.

Participating PoC server B 101 receives a "get floor" message from control PoC server X 50, including speaker identification information and anonymity request. Participating PoC server B 101 recognizes the anonymity request and removes the speaker's identification information from the "Get Floor" message. Participating PoC server B 101 generates a new "Get Floor" message in step 251. Participating PoC server B 101 then sends this new "get floor" message to PoC client B 30 in step 211, which does not include the user-identifying feature.

Figures 4 and 5 show examples of "speak request" messages and "floor acquisition" messages that include speaker identification information and anonymity requests.

FIG. 4 shows a packet based on the RTP Control Protocol (RTCP) that uses the step of forwarding a "speak request" data packet, which implements the first embodiment of the present invention.

A "speak request" RTCP packet is sent from PoC client A 104 to participating PoC server A 107 and is controlled by participating PoC server A 107 to request permission from the control server to send speech to other users PoC server X 50 Transferred to.

A "speak request" RTCP packet contains a 32-bit wide datagram. The first line of the datagram is the version specifier (V) 303 (2 bits), the padding bit (P) 305 (1 bit), the number of sources 307a (5 bits), and the payload type (PT) 309. Contains (8 bits) and a set of information values that are length specifiers (LENGTH) 311.

As specified in IETF RFC3550 Chapter 6.5, version indicator 303 indicates the version of RTP used, which is version 2 in this example. The padding bit 305 indicates whether the packet contains one or more padding octets. The number of sources is used to identify the subtype that defines which of the various RTCP packets this packet is. In the example shown in Figure 4, the value 10000 indicates that it is a modified "speak request" RTCP packet, which modifies that the user requesting speech wants to remain anonymous to other users in the group. Is shown. Payload type (PT) 107 defines the format of the RTCP payload, and in the example shown, the payload type is APP or 204. The length specifier (LENGTH) 311 describes the packet length in 32-bit units and does not include the first word. In this example, the length is 2 (32 bits) words.

The second line of the datagram is the Sync Source Identifier (SSRC) 313, which identifies the sync source of the packet's source. In the example shown, the packet is a "speak request" packet, and SSRC313 points to PoC client A 104.

The third and last lines of the RTCP packet include the user device display address "name" 315. The Name field is also used to indicate the release version of the application.

Once the participating server receives this packet at the end of step 201, it is then forwarded to control PoC server X 50 in step 203.

FIG. 5 shows a packet based on the RTP Control Protocol (RTCP) that uses the step of forwarding a "floor acquisition" data packet, which implements the first embodiment of the present invention.

Two types of "floor acquisition" messages are used according to the method described above. The first type of "floor acquisition" RTCP packet is transmitted from the control PoC server 50 to the participating PoC server, for example, the first participating PoC server 103, via the network. The second type is sent from the participating PoC server to the user equipment, eg UE1 30, and prepares the user equipment to receive RTP packets from the floor-authorized user equipment. Both Type 1 and Type 2 are illustrated in FIG.

A "floor capture" RTCP packet contains a 32-bit wide datagram.

The first line of the datagram is the version specifier (V) 303 (2 bits), the padding bit (P) 305 (1 bit), the number of sources 307b (5 bits), and the payload type (PT) 309. Contains (8 bits) and a set of information values that are length specifiers (LENGTH) 311b.

As specified in IETF RFC3550 Chapter 6.5, version indicator 303 indicates the version of RTP used, which is version 2 in this example. The padding bit 305 indicates whether the packet contains one or more padding octets. The number of sources 307b is used to identify the subtype that defines which of the various RTCP packets this packet is. In the example shown in Figure 5, the value 10010 is a modified "floor capture" RTCP packet, indicating that the user is requesting anonymity (unlike subtype 00010, which indicates a regular "floor capture" RTCP packet). Shown. Payload type (PT) 309 defines the format of the RTCP payload, and in the example shown, the payload type is APP or 204. The length specifier (LENGTH) 311b describes the packet length in 32-bit units and does not include the first word.

The second line of the datagram is the Synchronous Source Identifier (SSRC) 313b, which identifies the synchronous source of the packet's source. In the example shown, the packet is a modified "floor acquisition" packet, and SSRC313b represents the control PoC server 50.

The third line of the RTCP packet contains the display address (name) 315b of the push-to-talk (PoC) server over the cellular network. The Name field is also used to indicate the release version of the application.

The fourth and subsequent lines of the packet contain information block 317.

For Type 1 "Get Floor" messages, the information block contains two Source Description (SDES) items.

The first source description item 321 contains a canonical name (CNAME). The standard form name includes the standard form name of user 323. The standard form name of user 323 is defined as a unique identifier specified for the combination of user and user equipment. An example of such a unique identifier is a SIP Unified Resource Identifier (URI) such as "dave.bowman@poc.operator.com" shown in Figure 5.

The second information source description item 325 includes a display name (name). The display name includes the display name of the user 327. The display name of the user 327 is an identifier displayed by the user device, which indicates the combination of the user and the user device. An example of such an identifier is an alphanumeric character string such as "Dave B" shown in FIG.

Once the participating PoC server B 103 receives the floor acquisition anonymous packet, the participating PoC server B processes the "floor acquisition" message and deletes the user's canonical name (CNAME) and display name (NAME). In some embodiments of the invention, the CNAME and NAME values may be specific unique anonymous names. In such cases, the user can maintain his anonymity, but the authorities still send the message to the particular user, provided that there is a particular relationship between the unique anonymous name and the username. Can be tied.

In a further embodiment of the present invention, the subtype of the "floor acquisition" message is returned to the normal "floor acquisition" message subtype. Thus, in such an embodiment, the receiving user device can therefore be prevented from detecting that the transmitting user device has requested anonymity.

In such situations, the user can maintain anonymity when requested in front of another client, the user's device, but can still be monitored by the authorities on the controller.

The above example was described to provide an anonymity request within the subtype field of the RTCP floor control packet, but in other embodiments of the invention, the directive is placed elsewhere in the floor control message. Please be aware that you can also do it.

In one further embodiment, the anonymity request is directed using the modified payload type. The controlling PoC server and the participating PoC server can recognize this modified payload type and provide the required anonymity.

In another further embodiment, the anonymity request can be directed by providing an additional SEDS field that incorporates the user's anonymity or alternative identification information.

In a further embodiment of the invention, the anonymity request in the floor control message can be indicated by adding an additional dedicated field to the packet.

In the example of adding an additional SDES field containing anonymous identification information, the Type 1 "floor acquisition" message sent from control PoC server 50 to participating PoC server B 103 carries the SDES field containing the user's anonymous ID along with the anonymous information. To do. The Type 2 "Get Floor" message sent from the participating PoC server 103 to the receiving PoC client B 30 contains only anonymous information. That is, the user's ID is deleted before being transferred to PoC client B 30.

In a further embodiment of the invention, anonymity or alternative identification information is provided in conjunction with the original SDES field information rather than as an additional SDES field to form a decoded SDES field. For example, the display name of the Type 1 "floor acquisition" message can contain the data "name +++ anonymousID", where "name" is the user's display name, "+++". Is the separator, and "anonymous ID" is the name that is forwarded to other users in the Type 2 "Get Floor" message.

In a further embodiment of the invention, anonymous information, or packets, or elements are carried on top of known "floor acquisition" packets. In such an embodiment, a composite RTCP packet in which a second packet containing anonymous information is concatenated with a first "floor acquisition" packet containing information source description information including a standard user name and a display user name. To form.

In a further embodiment of the invention, the "floor acquisition" RTCP packet known in the prior art is followed by a second RTCP packet containing the anonymous information directly. This second packet is a given RTP Control Protocol (RTCP) application (APP) packet.

In a further embodiment, the anonymous identifier source description item PRIV forms a PoC-specific dedicated extension that transfers anonymous information.

Figure 6 shows an example of a PRIV message packet containing anonymous information. PRIV packet 501 contains anonymous information, i.e. a numeric string 503 containing an anonymity and / or any anonymous ID.

In a further embodiment of the invention, the user's canonical name may be the user's TEL URL / URI. The TEL URL / URI is the equivalent in SIP, which corresponds to the telephone number of the user device used in the Public Switched Telephone Network (PSTN).

In a further embodiment of the invention, the control PoC server stores an instance during user initialization where the user requires anonymity. This request is made using the SIP protocol described in IETF RFC 3325 and / or IETF RFC 3323. In this embodiment, the control PoC server inspects any speech request message or floor request message and applies the privacy requested by the user. That is, the control PoC server sends a "floor acquisition" message as if it had received a "speak request" message including an anonymity request.

The embodiments of the present invention can provide information described using other types of floor control messages or indeed other types of messages. Examples of other types of messages include media messages.

The embodiments of the present invention can further use protocols other than RTCP to transmit user plane messages or control plane messages.

In a further embodiment of the invention, when the controlling PoC server sends a message to a serviced user device in an untrusted network, the controlling PoC server forwards the message to the participating PoC server in the untrusted network. Before doing so, perform the process of removing any identification features from the forwarded message.

In another embodiment of the present invention, the user device can transmit an anonymous numerical value as a user's display name. In these examples, the system is configured to simply transfer the number without deleting the anonymous number. In this way users can still maintain their privacy within such a system.

<figref num="1">It is the schematic of the typical communication network which incorporated the Example of this invention.</figref><figref num="2">It is a schematic diagram of the push-to-talk communication network implemented in the communication network of FIG.</figref><figref num="3">It is a flow chart which shows the floor control procedure which incorporated the 1st Embodiment of this invention.</figref><figref num="4">It is the schematic of the RTCP "speaking request" data packet which incorporated the 1st Embodiment of this invention.</figref><figref num="5">It is the schematic of the RTCP "floor acquisition" data packet which incorporated the 1st Embodiment of this invention.</figref><figref num="6">It is the schematic of the "PRIV" information source description data packet which incorporated the further embodiment of this invention.</figref>