EP1759489A1 - Systeme de communication - Google Patents

Systeme de communication

Info

Publication number
EP1759489A1
EP1759489A1 EP05739800A EP05739800A EP1759489A1 EP 1759489 A1 EP1759489 A1 EP 1759489A1 EP 05739800 A EP05739800 A EP 05739800A EP 05739800 A EP05739800 A EP 05739800A EP 1759489 A1 EP1759489 A1 EP 1759489A1
Authority
EP
European Patent Office
Prior art keywords
user equipment
user
server
plane message
user plane
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP05739800A
Other languages
German (de)
English (en)
Inventor
Miikka Poikselka
Tapio Paavonen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Oyj
Original Assignee
Nokia Oyj
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GB0413106A external-priority patent/GB0413106D0/en
Priority claimed from US11/028,605 external-priority patent/US7889726B2/en
Application filed by Nokia Oyj filed Critical Nokia Oyj
Publication of EP1759489A1 publication Critical patent/EP1759489A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • H04L65/4061Push-to services, e.g. push-to-talk or push-to-video
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1822Conducting the conference, e.g. admission, detection, selection or grouping of participants, correlating users to one or more conference sessions, prioritising transmission
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/1016IP multimedia subsystem [IMS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • H04L65/403Arrangements for multi-party communication, e.g. for conferences
    • H04L65/4038Arrangements for multi-party communication, e.g. for conferences with floor control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/42008Systems for anonymous communication between parties, e.g. by use of disposal contact identifiers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08Upper layer protocols
    • H04W80/10Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/189Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M1/00Substation equipment, e.g. for use by subscribers
    • H04M1/57Arrangements for indicating or recording the number of the calling subscriber at the called subscriber's set
    • H04M1/571Blocking transmission of caller identification to called party
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/56Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H04W4/10Push-to-Talk [PTT] or Push-On-Call services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/40Connection management for selective distribution or broadcast
    • H04W76/45Connection management for selective distribution or broadcast for Push-to-Talk [PTT] or Push-to-Talk over cellular [PoC] services

Definitions

  • the present invention relates to a communication system and in particular but not exclusively to a communication system for use in a push-to-talk over cellular network.
  • a communication system can be seen as a facility that enables communication sessions between two or more entities such as user equipment and/or other nodes associated with the communication system.
  • the communication may comprise, for example, communication of voice, data, multimedia and the like.
  • a session may, for example, be a telephone call type session between users, a multi-way conference session, or a communication session between user equipment and an application server " (AS) such as a service provider server.
  • AS application server
  • a communication system typically operates in accordance with a given standard or specification which sets out what the various entities associated with the communication system are permitted to do and how that should be achieved.
  • the standard or specification may define if the user, or more precisely, user equipment is provided with a circuit switched service and/or a packet switched service.
  • Communication protocols and/or parameters which shall be used for the connection may also be defined. In other words, a specific set of rules on which the communication can be based is defined to enable communication.
  • PLMN public land mobile network
  • BTS base transceiver station
  • UE mobile user equipment
  • the communication on the wireless interface between the user equipment and elements of the communication network can be based on an appropriate communication protocol.
  • the operation of the base station apparatus and other apparatus required for the communication can be controlled by one or several control entities.
  • the various control entities may be interconnected.
  • One or more gateway nodes may be provided for connecting the cellular access network to other networks, for example to a public switched telephone network (PSTN) and/or other communication networks such as an IP (Internet Protocol) and/or other packet switched data networks .
  • PSTN public switched telephone network
  • IP Internet Protocol
  • the mobile communications network provides an access network enabling a user with wireless user equipment to access external networks, hosts, or services offered by specific service providers.
  • IP multimedia functionalities can be provided by means of an IP multimedia core network subsystem (IMS) .
  • IMS IP multimedia core network subsystem
  • the IMS includes various network entities for the provision of multimedia services. IMS services are intended to offer, amongst other services, IP based packet data communication sessions between mobile user equipment .
  • a packet data carrier may be established to carry traffic flows over the network.
  • An example of such a packet data carrier is a packet data protocol (PDP) context.
  • PDP packet data protocol
  • Various types of services are provided by means of different application servers (AS) over IMS. Some of these services may be time critical .
  • An example of a time critical service that may be provided over the IMS is the so-called direct voice communication service.
  • One example of this type of service is the ⁇ push-to-talk over cellular' (PoC) service also known as the PTT (push-to-talk service) .
  • the direct voice communication services are intended to use the capabilities of the IMS to enable IP connections for user equipment and other parties to the communication, such as other user equipment or entities associated with the network.
  • the service allows users to engage in immediate communication with one or more users .
  • PoC walkie-talkie communication systems
  • a walkie-talkie system is one where the capabilities of a walkie-talkie system are implemented within a standard cellular phone. Users simply select the person or groups of persons they wish to talk to from their phone and press the push to talk key on their mobile phone to start talking. The activation may be via a specific button, tangent or any other appropriate key of the keyboard. Similar principals apply with devices having touch sensitive or sound activated user interfaces. While the user speaks, the other user or users may listen. Bi-directional communication may be offered since all parties of the communication session may similarly communicate voice data with the PoC application server. Turns to speak are requested by activating the push to talk button or the like. The response time of connection is almost instantaneous .
  • Push-to-talk calls are typically half-duplex communications, i.e. while one user speaks the others listen. The turn to speak is granted by pressing the push-to-talk key on a first come first served basis or based on priorities. Push-to-talk calls are usually connected without the recipient answering and typically received through the phone's built in loud speaker.
  • the push-to-talk service may be implemented using push-to-talk servers in a IP multimedia subsystem (IMS) system.
  • IMS IP multimedia subsystem
  • the push to talk service is based on multi-unicasting.
  • Each transmitting handset sends packet data traffic to a dedicated push-to-talk server (a participating server) .
  • a controlling server receives the traffic and manages the shared floor for a group call .
  • the controlling server duplicates the traffic to be received by all recipients. No multi-casting is performed either in the
  • Groups of communicating user equipment using the PoC system can be created in various ways .
  • the Internet Engineering Task Force (IETF) defines one such system using session initiation protocol (SIP) or Conference Policy Control Protocol (CPCP) .
  • SIP session initiation protocol
  • CPCP Conference Policy Control Protocol
  • Voice and data control traffic once the groups are set up is carried through a real time protocol (RTP) streaming bearer.
  • RTP real time protocol
  • the PoC system uses transport protocols based on those described in IETF RFC 3550.
  • the RTP protocol describes the architecture of the data packets and the syntax of the data stored within the packets passing the voice and data information from user to user.
  • a user of a PoC network may wish to send a message and withhold their identity from the final destination whilst still being able to communicate an identity to one or more intermediaries.
  • a communication system comprising: a first and second user equipment in communication over a shared floor; and a server means for managing the shared floor; wherein the server means is arranged to detect an anonymity request from the first user equipment, and responsive to said anonymity request to prevent the second user equipment from identifying the first user equipment from user plane messages transmitted from the first user equipment to the second user equipment .
  • the first user equipment may be arranged to initiate a connection with of the second user equipment via said server means using a first protocol .
  • the first protocol may be a session initiation protocol (SIP) .
  • SIP session initiation protocol
  • the first user equipment is preferably arranged to communicate over an existing connection with said second user equipment via said server means using a second protocol .
  • the second protocol may be a real time control protocol (RTCP) .
  • RTCP real time control protocol
  • the user plane messages are preferably transmitted using said second protocol .
  • the communications system may comprise a push-to- talk over cellular communications system.
  • the user plane message is preferably a floor control message .
  • the user plane message is preferably a floor taken message .
  • the user plane message is preferably a media message .
  • the server means may be arranged to remove identification of the first user from said user plane message.
  • the server means may be further arranged to insert into said user plane message a unique anonymous token.
  • the unique anonymous token is preferably stored within said the user plane message as at least part of a source description item.
  • the server means is preferably arranged to remove identification of the first user from said user plane message prior to transmitting to the second user equipment.
  • the user plane messages from the first user equipment may include identification information comprising at least one of a URI of the user equipment and a display name of the user equipment .
  • the anonymity request is preferably contained within at least one of: a subtype of the message; a payload type of the message; an additional SDES field within the message; an additional customised field.
  • the user plane message is preferably a floor request or talk request message.
  • the server means may comprise a controlling server and a participating server, wherein the controlling server is arranged to receive the anonymity request from the first user, and the participating server is arranged to transmit the user plane message.
  • the controlling server is preferably arranged to transmit a second user plane message to said participating server, said second user plane message comprises the identity of the first user equipment and a privacy indication, wherein said participating server is arranged to receive said second user plane message and responsive to said privacy indication to prevent the second user equipment from identifying the first user equipment .
  • the second user plane message privacy indication is preferably provided by at least one of : a subtype of the message; a payload type of the message; an additional SDES field within the message; an additional customised field.
  • server means arranged to operate in a communications system, said communications system further comprising a first and second user equipment in communication over a shared floor, wherein said server means is arranged to manage the shared floor, and further arranged to detect an anonymity request from the first user equipment, and responsive to said anonymity request to prevent the second user equipment from identifying the first user equipment from user plane messages transmitted from the first user equipment to the second user equipment .
  • user equipment arranged to operate in a communications system over a shared floor, said communications system further comprising server means arranged to manage the shared floor, wherein at least one of the user equipment is arranged to receive from said server means a user plane message preventing the at least one of the user equipment from identifying at least one other user equipment.
  • a method of communication within a communications system comprising a first and second user equipment in communication over a shared floor and server means arranged to manage the shared floor, said method comprising the steps of: receiving at said server means a request for anonymity from the first user equipment, preventing the second user equipment from identifying the first user equipment from user plane messages transmitted from the first user equipment to the second user equipment.
  • a communication system comprising: a first and second user equipment in communication over a shared floor; and a controlling server for managing the shared floor; at least one participating server for serving said second user equipment; wherein the controlling server is arranged to detect an anonymity request from the first user equipment, and to insert into user plane messages from the first user equipment a privacy indication and when the participating server is responsive to said privacy indication to prevent the second user equipment from identifying the first user equipment .
  • Figure 1 shows a schematic view of a typical communications network incorporating an embodiment of the present invention
  • Figure 2 shows a schematic view of the push-to-talk communications network as implemented within the communications network of Figure 1;
  • Figure 3 shows a flow diagram showing a floor control procedure incorporating a first embodiment of the present invention
  • Figure 4 shows a schematic view of RTCP ⁇ talk request' data packet incorporating a first embodiment of the present invention
  • Figure 5 shows a schematic view of a RTCP "floor taken' data packet incorporating the first embodiment of the present invention.
  • Figure 6 shows a schematic view of a ⁇ PRIV source description data packet incorporating a further embodiment of the present invention. Detailed Description of Embodiments of the Present Invention
  • the third generation partnership project (3GPP) has defined a reference architecture for the third generation (3G) core network which will provide the users of user equipment with access to multimedia services.
  • This core network is divided into three principal domains. These are the circuit switched (CS) domain, the packet switched (PS) domain and the internet protocol multimedia subsystem (IMS) domain.
  • CS circuit switched
  • PS packet switched
  • IMS internet protocol multimedia subsystem
  • FIG. 1 shows an IP multimedia network 45 for offering IP multimedia services to IP multimedia network subscribers.
  • IP multimedia subsystem (IMS) functionalities may be provided by a core network (CN) subsystem including various entities for the provision of the service.
  • CN core network
  • 3GPP third generation partnership project
  • GPRS general packet radio service
  • a GPRS based system will be used in the following example of a possible backbone communication network enabling the IMS services.
  • a mobile communication system such as the 3G cellular system is typically arranged to serve a plurality of mobile user equipment, usually via a wireless interface between the user equipment and base stations of the communication system.
  • the mobile communication system may logically be divided between a radio access network (RAN) and a core network (CN) .
  • the core network entities typically include various control entities and gateways for enabling the communication via a number of radio access networks and also for interfacing a single communication system with one or more communication systems such as with other cellular systems and/or fixed line communications systems.
  • the intermediate mobile communication network provides packet switched data transmission in the packet switched domain between a support node 33,42 and mobile user equipment 30,44.
  • Different sub networks are in turn connected to an external data network, for example to a packet switched data network (PSDN) via gateway GPRS support nodes (GGSN) 34, 40.
  • the GPRS services thus allow transmission of packet data between mobile data terminals and/or external data networks.
  • the exemplifying general packet radio services operation environment comprise one or more sub network service areas, which are interconnected by GPRS back bone networks 32 and 41.
  • a sub network comprises a number of packet data service nodes (SN) .
  • the service nodes will be referred to as serving GPRS support nodes (SGSN) .
  • Each of the SGSNs 33, 42 is connected to at least one mobile communication network, typically to base station systems 31,43. Although not shown for clarity reasons, the connection may be provided by way of radio network controllers or other access system controllers such as base station controllers in such a way that packet services can be provided for mobile user equipment via several base stations .
  • Base stations 31 and 43 are arranged to transmit signals to and receive signals from mobile user equipment 30 and 44 of mobile users i.e. subscribers, via respective wireless interfaces.
  • each of the mobile user equipment is able to transmit signals to and receive signals from the base stations via the wireless interface.
  • the base stations 31 and 43 belong to respective radio access networks (RAN) .
  • RAN radio access networks
  • each of the user equipment 30 and 44 may access the IMS network 45 via the two access networks associated with the base stations 31 and 43 respectively.
  • FIG 1 only shows the base stations of two radio access networks, a typical mobile communication network usually includes a number of radio access networks.
  • the IMS domain is for ensuring that multimedia services are adequately managed.
  • the IMS domain commonly supports the session initiation protocol (SIP) as developed by the internet engineering task force (IETF) .
  • Session initiation protocol (SIP) is an application-layer control protocol for creating, modifying and terminating sessions with one or more participants (end point) .
  • SIP was generally developed to allow for the initiation of a session between two or more end points in the Internet by making these end points aware of the session semantics.
  • a user connected to an SIP base communication system may communicate with various entities of the communication system based on standardised SIP messages .
  • User equipment or users that run certain applications on the user equipment are registered with the SIP backbone so that an invitation to a particular session can be correctly delivered to these end points.
  • SIP provides a registration mechanism for devices and users and it applies mechanisms such as location servers and registrars to route the session invitations appropriately. Examples of proper possible sessions that may be provided by SIP signalling include internet multimedia conferences, internet telephone calls and multimedia distribution.
  • User equipment within the radio access network may communicate with a radio network controller via radio network channels which are typically referred to as radio bearers. Each user equipment may have one or more radio channels open at any one time with the radio network controller. Any appropriate mobile user equipment adapted for internet protocol (IP) communication maybe used to connect to the network.
  • IP internet protocol
  • a user may access the cellular network by means of user equipment such as a personal computer, personal data assistant (PDA) , mobile station (MS) , portable computer, combinations thereof or the like.
  • User equipment is used for tasks such as making and receiving phone calls, for receiving and sending data from and to a network and for experiencing for example multimedia content.
  • User equipment is typically provided with a processor and memory for accomplishing these tasks.
  • User equipment may include an antenna for wirelessly receiving and transmitting signals from and to base stations of the mobile communication network.
  • User equipment may also be provided with a display for displaying images and other graphical information for the user of the mobile user equipment.
  • a speaker may also be provided.
  • the operation of the user equipment may be controlled by means of a suitable user interface such as key pad, voice commands, touch sensitive screen or pad, combinations thereof or the like.
  • the user equipment 30 and 44 of figure 1 are configured to enable the use of push to talk types of services.
  • An activation function that may be required by a push to talk service can be provided by one of the buttons on the keypad of the mobile station 30 and 44 or by a specific key or button such as the type known from - ⁇ walkie-talkie' devices .
  • figure 1 only shows two user equipment for clarity.
  • a number of user equipment may be in simultaneous communication with each base station.
  • User equipment may have several simultaneous sessions, for example a number of SIP sessions and activated PDP contexts.
  • the user may have a phone call and be simultaneously connected to at least one other service.
  • Each PDP context provides a communication pathway between a particular user and a GGSN. Once the PDP context is established, it can typically carry multiple flows. Each flow normally represents, for example, a particular service and/or media component of a particular service. The PDP context therefore often represents a logical communication pathway for one or more flows across the network.
  • radio access bearers need to be established which commonly allow for data transfer for the user equipment .
  • Communication systems have developed such that services may be provided for user equipment by means of various functions of the IMS network 45 that are handled by network entities and served by the servers.
  • IMS network 45 functions of the IMS network 45 that are handled by network entities and served by the servers.
  • CSCF call session control functions
  • the call session control functions can be divided into various categories such as a proxy call session control function (P-CSCF) 35, 39, interrogating call session control function (I -CSCF) 37 and serving call session control function (S-CSCF) 36, 38.
  • P-CSCF proxy call session control function
  • I -CSCF interrogating call session control function
  • S-CSCF serving call session control function
  • the user equipment 30, 44 may connect via the GPRS network to application servers that are generally connected to the IMS.
  • an application server is provided by a push-to-talk-over cellular (PoC) services server 50.
  • PoC push-to-talk-over cellular
  • the PoC server can in some embodiments of the present invention be implemented as server means comprising a series of participating PoC servers connected to a controlling PoC server.
  • the participating PoC servers transmit and receive data traffic from the user equipment and also transmit and receive data traffic from the controlling PoC server.
  • the controlling PoC server transmits and receives data traffic from the participating PoC servers and controls access to the PoC shared floor dependent on the information received from the participating servers.
  • one participating PoC server also acts as a controlling PoC server.
  • FIG. 2 shows a further view of the communications system of Figure 1 with regards to the push-to-talk over cellular (PoC) system.
  • Figure 2 shows a network of user equipment units UEl 30, UE2 44, UE3 102, UE4 104 communicating over a push-to-talk over cellular telecommunication system.
  • UEl 30 is connected to the first participating PoC server 101, which is connected to the controlling PoC server 50.
  • UE2 44 is connected to the second participating PoC server 103 which is connected to the controlling PoC server 50.
  • UE3 102 is connected to the third participating PoC server 105 which is connected to the controlling PoC server 50.
  • UE4 104 is connected to the fourth participating PoC server 107 which is connected to the controlling PoC server 50.
  • the mobile user equipment UEl, UE2 , UE3 , and UE4 can be from four different IMS networks.
  • the PoC participating servers 101, 103, 105, 107 and controlling PoC server 50 provide push-to-talk over cellular (PoC) services over the IMS network 45.
  • the push-to-talk service is an example of the so called direct voice communication service. Users who wish to use the PoC service may need to subscribe to an appropriate PoC server.
  • the direct voice communication services are intended to use the capabilities of the GPRS back bone and the control functions of the multimedia subsystem for enabling IP connections with the user equipment UEl 30, UE2 44, UE3 102, UE4 104.
  • the PoC server may be operated by the operator of the
  • IMS system or a third party service provider.
  • a user may open the communication link, for example, by pressing a specific activation button on the user equipment UEl 30. While the user of the UEl 30 speaks, the users of UE2 44, UE3 102, and UE4 104 listen. The user of the user equipment UE2 44 may then reply in a similar manner.
  • the signalling between the user equipment and the appropriate call session control functions is routed via the GPRS network.
  • the user plane session sets up signalling for the user equipment and is routed via the participating PoC servers 101, 103, 105, 107 and controlled by the controlling PoC server 50. In other words, the PoC server controls both the control plane (for signalling) and the User plane (for user data) of the PoC user.
  • the control plane traffic between the participating PoC server and the user equipment may be routed via the IMS whilst the user plane traffic between the user equipment and the PoC server may be routed from the GPRS system to the PoC server on interfaces 54 and 56 (as shown in Figure 1) .
  • the push-to-talk service is based on multi-unicasting.
  • Each transmitting user equipment UEl 30, UE2 44, UE3 102, UE4 104 sends packet data traffic to a dedicated push-to-talk server and in case of a group call, the server then duplicates the traffic to all recipients.
  • user plane' messages can be passed from one user to the rest of the system and vice versa.
  • One type of data communications packet in the user plane is that of informing which user is transmitting or has received permission to use the floor. This information could be a "floor taken' message. This "floor taken' information is received by the user equipment which will receive RTP traffic from the user who has taken control of the floor.
  • These control packets are based on a real time control protocol (RTCP) packet, a subset of the real time protocols (RTP) described earlier.
  • RTCP real time control protocol
  • PoC Client A refers in this example to the user equipment UE4 104
  • the participating PoC server A refers to the participating PoC server 107
  • the controlling PoC server X refers to the controlling PoC server 50
  • the PoC server B refers to the first participating PoC servers 101
  • the PoC Client B refers to the respective user equipment UEl 30.
  • a one-to-one communication is described within this example it is appreciated that the same method can be applied to a one-to-many communication where the controlling PoC server copies the message to each of the receiving parties .
  • the PoC Client A 104 transmits a "talk request' message to the participating PoC server A 107.
  • This "talk request' message includes the talking party or user identity of the client A and an anonymity request.
  • the second step 203 occurs after the participating PoC server A 107 has received the talk request.
  • the participating PoC server A 107 forwards the "talk request' including the talking party identity and the anonymity request to the controlling PoC server X 50.
  • the controlling PoC server X 50 may carry out authorisation of the client to determine that the client is authorised to participate in the PoC communications group. If the PoC Client A 104 is permitted to talk i.e. there is no other user occupying the floor then the controlling PoC server X 50 initiates a first step 205 and a second step 207.
  • the controlling PoC servers initiated first step 205 is where the controlling PoC server X 50 forwards a "floor taken' message to the participating PoC server B 101.
  • the controlling PoC servers initiated second step 207 is where the controlling PoC server X 50 transmits a "talk granted' message to the participating PoC server A 107.
  • the controlling PoC server X 50 transmits a "floor granted' message which is processed by the system in a manner similar to a "talk granted' message.
  • the participating PoC server A transmits the "talk granted' message received from the previous step towards the PoC Client A 104. This
  • talk granted' message allows the client A to send a talk burst within the group, i.e. to broadcast to the group any message it wishes to send.
  • the participating PoC server B 101 receives the "floor taken' message from the controlling PoC server X 50 including the talking party identity and anonymity request information.
  • the participating PoC server B 101 recognises the anonymity request and removes the identity of the talking party from the "floor taken' message.
  • the participating PoC server B 101 generates a new "floor taken' message within this step 251.
  • the participating PoC server B 101 then transmits this new "floor taken' message containing no identifying features of the user to the PoC Client B 30 in step 211.
  • RTCP real time control protocol
  • the "talk request' RTCP packet is transmitted from the PoC Client A 104 to the participating PoC server 107, and forwarded by the participating PoC server A 107 to the controlling PoC server X 50 in order to request from the controlling server permission to transmit speech to the other users .
  • the "talk request' RTCP packet comprises a datagram 32 bits in width.
  • the first line of the datagram comprises a series of information values, a version indicator (V) 303 (2 bits), a padding bit (P) (1 bit) 305, a source count 307A (5 bits) , a payload type (PT) (8 bits) 309, and a length indicator (LENGTH) 311.
  • the version indicator 303 indicates the version of the RTP being used, in this example version 2.
  • the padding bit 305 indicates if the packet contained one or more padding octets.
  • the source count is used to identify a subtype that defines which of the various RTCP packets the present one is. In the example shown in Figure 4 the value of 10000 indicates this is a modified "talk request' RTCP packet, the modification being that the user requesting the talk request wishes to maintain anonymity to the other users of the group.
  • the payload type (PT) 107 defines the format of the RTCP payload, in the example shown the payload type is equal to APP or 204.
  • the length indicator (LENGTH) 311 describes the length of the packet in 32 bit words, not counting the first word. In this example the length is equal to two further 32 bit words.
  • the second line of the datagram comprises a synchronisation source identifier (SSRC) 313, which identifies the synchronisation source for the originator of the packet .
  • SSRC synchronisation source identifier
  • the third and final line of the RTCP packet comprises the displayed address "name' 315 for the user equipment.
  • the "name' field can also be used to indicate the application release version.
  • This packet once received by the participating server A at the end of step 201 is then forwarded in step 203 to the controlling PoC server X 50.
  • RTCP real time control protocol
  • the second type is transmitted from the participating PoC server to the user equipment, e.g. UEl 30, and prepares the user equipment to receive RTP packets from the user equipment which has been granted the floor. Both the first and second types can be described with respect to Figure 5.
  • the "floor taken' RTCP packet comprises a datagram 32 bits in width.
  • the first line of the datagram comprises a series of information values, a version indicator (V) 303 (2 bits) , a padding bit (P) (1 bit) 305, a source count (5 bits) 307b, a payload type (PT) (8 bits) 309, and a length indicator (length) 311b.
  • the version indicator 303 indicates the version of the RTP being used, in this example version 2.
  • the padding bit 305 indicates if the packet contains one or more padding octets.
  • the source count 307b is used to identify a subtype that defines which of the various RTCP packets the present one is. In the example shown in figure 5 the value of 10010 indicates that this is a modified "floor taken' RTCP packet where the user requested anonymity (as compared to the subtype 00010 indicating a regular "floor taken' RTCP packet) .
  • the payload type (PT) 309 defines the format of the RTCP payload, in the example shown the payload type is equal to APP or 204.
  • the length indicator (length) 109 describes the length of the packet in 32 bit words, not counting the first word.
  • the second line of the datagram comprises a synchronisation source identifier (SSRC) 313b, which identifies the synchronisation source for the originator of the packet .
  • SSRC synchronisation source identifier
  • the third line of the RTCP packet comprises the displayed address (name) 315b for the push-to-talk over cellular (PoC) server.
  • the "name' field can also be used to indicate the application release version.
  • the fourth and further lines of the packet comprises an information block 317.
  • the information block comprises two source description (SDES) items .
  • the first source description item 321 comprises the canonical name (CNAME) .
  • the canonical name comprises the canonical name of the user 323.
  • the canonical name of the user 323 is defined as the unique identifier assigned to the user/user equipment combination.
  • An example of such a unique identifier would be the SIP uniform resource indicator (URI) such as that shown in Fig 5, "dave.bowman@poc.operator.com'.
  • URI uniform resource indicator
  • the second source description item 325 comprises the display name (name) .
  • the display name comprises the display name of the user 327.
  • the display name of the user 327 is an identifier displayed by the user equipment indicating the user/user equipment combination. An example of such an identifier would be the alphanumeric string such as that shown in Fig 5 "DaveB' .
  • the participating PoC server B 103 processes the "floor taken' message to remove the canonical name (CNAME) and display name (NAME) of the user.
  • the CNAME and NAME values may be in some embodiments of the present invention given unique anonymous names. In such a situation it would be possible for the user to maintain their anonymity, but authorities still be able to link the message to a particular user given the particular relationship between the unique anonymous name and the user name .
  • the subtype of the "floor taken' message reverts to the normal subtype for a "floor taken' message. In such an embodiment it is therefore possible to prevent the receiving user equipment detecting that the transmitting user equipment has requested anonymity.
  • the user is capable of maintaining anonymity when requested in front of other clients or user equipment, but still be capable of being monitored by authorised parties at the controller.
  • the indicator can be located within other parts of the floor control message.
  • the request for anonymity is indicated by the use of a modified payload type.
  • the controlling PoC server and participating PoC servers are able to recognise this modified payload type to provide the required anonymity.
  • the request for anonymity may be indicated by the provision of additional SEDS fields incorporating an anonymous or alternative identity from the user.
  • the request for anonymity within the floor control message can be indicated by adding additional customised fields to the packet .
  • the first type "floor taken' message sent from the controlling PoC server 50 to the participating PoC server B 103 carries the anonymous information together with the SDES field containing the anonymous ID of the user.
  • the second type "floor taken' message from the participating PoC server 103 to the receiving PoC client 30 includes only the anonymous information, i.e. the ID of the user is removed prior to forwarding to the PoC Client B 30.
  • the anonymous or alternative identity is provided not as an additional SDES field but is concatenated to the original SDES field information in order to form a compound SDES field.
  • the display name in the first type of "floor taken' message can contain the data, ""name+++anonymousID" , where the "name' is the display name of the user, the string "+++' a separator and " anonymousID' the name passed to the other users in the second type of "floor taken' message.
  • the anonymity information or packet or element is piggybacked with the known "floor taken' packet.
  • a first packet or packet or element is piggybacked with the known "floor taken' packet.
  • a "floor taken' RTCP packet as known in the art is followed directly by a second RTCP packet containing anonymity information.
  • This second packet is a predefined real time control protocol (RTCP) application (APP) packet.
  • RTCP real time control protocol
  • the anonymity identifier source description item PRIV produces a PoC specific private extension transporting the anonymity information.
  • the PRIV packet 501 comprises a value string 503 which contains the anonymity information, i.e. the indicator and/or any anonymity ID.
  • the canonical name of the user can be the Tel URL/URI of the user.
  • the Tel URL/URI is the SIP equivalent to the telephone number of the user equipment as used in the public switched telephone network (PSTN) .
  • the controlling PoC server remembers an instance during a user's initialisation where the user requested anonymity. This request can be carried out using the SIP protocols described within IETF RFC 3325 and/or IETF RFC 3323.
  • the controlling PoC server examines any talk or floor request messages and applies the privacy as requested by the user, i.e. the controlling PoC server transmits a "floor taken' message as if it had received a "talk request' message containing an anonymity request .
  • Embodiments of the present invention may use other types of floor control ⁇ messages or indeed other types of messages to provide the described information.
  • Examples of other types of messages include media messages.
  • Embodiments of the present invention may further use protocols other then RTCP for transmitting user and control plane messages.
  • the controlling PoC server carries out the tasks of stripping any identifying feature from the forwarded messages before forwarding the message onto the untrusted network participating server.
  • the user equipment can transmit an anonymous value as the users display name.
  • the system is arranged not to strip the anonymous value but to simply forward the value. Thus the user still maintains their privacy within such a system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention porte sur un système de communication comportant un premier et un deuxième équipement d'utilisateur communiquant par l'intermédiaire d'un étage commun et de serveurs gérant l'étage commun. Selon le système, le serveur détecte une demande d'anonymat provenant du premier équipement d'utilisateur, et en réponse à ladite demande, empêche le deuxième équipement d'utilisateur d'identifier le premier équipement d'utilisateur à partir de messages plans transmis entre le premier équipement d'utilisateur et le deuxième. L'étage commun peut avoir trait à un service 'presser/parler sur réseau cellulaire (PoC).
EP05739800A 2004-06-11 2005-05-17 Systeme de communication Withdrawn EP1759489A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB0413106A GB0413106D0 (en) 2004-06-11 2004-06-11 A communication system
US11/028,605 US7889726B2 (en) 2004-06-11 2005-01-05 Communication system
PCT/IB2005/001491 WO2005122470A1 (fr) 2004-06-11 2005-05-17 Systeme de communication

Publications (1)

Publication Number Publication Date
EP1759489A1 true EP1759489A1 (fr) 2007-03-07

Family

ID=34968345

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05739800A Withdrawn EP1759489A1 (fr) 2004-06-11 2005-05-17 Systeme de communication

Country Status (5)

Country Link
EP (1) EP1759489A1 (fr)
JP (1) JP2008502252A (fr)
KR (1) KR100907986B1 (fr)
AU (1) AU2005253276B2 (fr)
WO (1) WO2005122470A1 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080013684A (ko) * 2006-08-09 2008-02-13 엘지전자 주식회사 Pt 서비스의 자동 응답 모드에서의 프라이버시 확보 방법
PL2060018T3 (pl) * 2006-08-17 2019-02-28 Redcom Laboratories, Inc. Sygnalizacja ptt/pts w sieci o protokole internetowym
CN101150848B (zh) * 2006-09-18 2011-06-15 摩托罗拉移动公司 用于鉴权无线通信装置的方法
KR101348002B1 (ko) * 2006-11-24 2014-02-13 삼성전자주식회사 플리트 멤버 간 라우팅 규칙 생성 시스템 및 방법
CN101325487B (zh) * 2007-06-15 2011-11-30 中兴通讯股份有限公司 一种在会议业务通知消息中限制用户号码显示的方法
US8474007B2 (en) * 2009-12-23 2013-06-25 Motorola Solutions, Inc. System and method of controlling identity privacy in a communication session
US9450991B2 (en) * 2010-11-30 2016-09-20 Motorola Solutions, Inc. Method of controlling sharing of participant identity in a group communication session

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6477150B1 (en) * 2000-03-03 2002-11-05 Qualcomm, Inc. System and method for providing group communication services in an existing communication system
JP2002058005A (ja) * 2000-06-02 2002-02-22 Canon Inc テレビ会議・テレビ電話システム、送信装置、受信装置、画像通信システム、通信装置、通信方法、記録媒体、プログラム
JP2003009231A (ja) * 2001-06-19 2003-01-10 Takatori Ikueikai:Kk 無線通信システムおよび無線通信サービス
JP3725070B2 (ja) * 2001-12-21 2005-12-07 株式会社東芝 ネットワークシステム、ルータ、ホスト、プレフィクス管理方法及びipアドレス管理方法
US6986036B2 (en) * 2002-03-20 2006-01-10 Microsoft Corporation System and method for protecting privacy and anonymity of parties of network communications
US7688764B2 (en) * 2002-06-20 2010-03-30 Motorola, Inc. Method and apparatus for speaker arbitration in a multi-participant communication session

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005122470A1 *

Also Published As

Publication number Publication date
KR100907986B1 (ko) 2009-07-16
AU2005253276B2 (en) 2009-11-19
JP2008502252A (ja) 2008-01-24
WO2005122470A1 (fr) 2005-12-22
KR20070034045A (ko) 2007-03-27
AU2005253276A1 (en) 2005-12-22

Similar Documents

Publication Publication Date Title
US7889726B2 (en) Communication system
AU2005232140B2 (en) A method of communication
EP1510090B9 (fr) Procede de commande de parties dans des communications de groupes de donnees en temps reel au moyen de paquets accuse de reception
KR101061373B1 (ko) 푸쉬투토크 오버 셀룰러 망의 미디어 저장 서비스 수행 방법과 PoC 서버 및 PoC 클라이언트
KR101155224B1 (ko) Sip/ip 코어 네트워크에서 세션 분리 방법 및 서버 및 단말
US7650159B2 (en) Communication system
WO2005107361A2 (fr) Systeme de communication
KR101058643B1 (ko) 푸쉬 투 토크 오버 셀룰러 시스템의 그룹 세션 개시 방법및 그 시스템
US20060153102A1 (en) Multi-party sessions in a communication system
US20060056440A1 (en) Managing conference communication in a communication system
US20060294243A1 (en) Management of group communication
AU2005253276B2 (en) A communication system
US20100115089A1 (en) Identifying Participants in a Conference
JP5248675B2 (ja) セルラー網を用いたプッシュ・ツー・トークにおけるプライベート通信
AU2004309946B2 (en) Method and device for push-to-talk service
EP1766858B1 (fr) Protection de la confidentialite par jeton dans un systeme de communication instantanee par bouton-poussoir par telecommunication cellulaire
CN1989734A (zh) 通信系统

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20061222

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU MC NL PL PT RO SE SI SK TR

17Q First examination report despatched

Effective date: 20070320

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20111201