JP2009502092A - Method and apparatus for broadcasting push-to-talk group sessions simultaneously - Google Patents

Abstract

  The present invention relates to a method for communicating push-to-data packets in a communication system in which push-to-packets are generated from push-to-clients joining a push-to-user group including at least two push-to-clients. To do. The method comprises the steps of receiving a push-to-data packet from a push-to server and broadcasting a push-to-data packet to a broadcast client that is not a member of a push-to-user group via a broadcast distribution network. including. Join a push-to-user group that includes at least two push-to-clients to a broadcast node that broadcasts push-to-data packets from a push-to server to a broadcast client that is not part of a push-to-user group A communication interface for communicating push-to-data packets originating from a push-to-client is also disclosed.

Description

  The present invention relates to the field of mobile radio communications, in particular to the field of push-to-service.

  Recently, the functionality of mobile radiocommunication networks has been expanded to include a push-to-talk (PTT) service, which allows users of a mobile radiocommunication network to interact with other users of the mobile radiocommunication network. This service facilitates one-way communication. PTT users can perform one-way voice communication with other PTT users that form a PTT user group. A PTT user group can structurally include more than one PTT user, and members of the PTT user group can change over time. Within a PTT user group, only one PTT user can talk at a time.

  In order to participate in the PTT discussion, it is necessary to subscribe to a mobile telephone adapted to the PTT service and a mobile radio network providing the PTT service. Typically, a subscription to a PTT service is also required. If a PTT user knows that he is in an area that does not provide wireless services for the normal mobile radio network, the user will not be able to hear the PTT debate. The user of PTT can choose to be a user who does not speak and thus only listens. On the other hand, in order to listen to discussions within the PTT user group, a mobile phone providing a PTT service is required.

  The problem to which the present invention pertains is related to a method that makes it possible to listen to PTT discussions without connecting to a mobile telephone adapted to the PTT service.

  This problem is addressed by a method of communicating in a communication system push-to-data packets originating from push-to-clients that join a push-to-user group that includes at least two push-to-clients. The method receives a push-to-data packet from a push-to server and broadcasts a push-to-data packet to a broadcast client that is not a member of a push-to-user group via the broadcast distribution network (210). The process of carrying out is included.

  This method allows push clients that are not part of a push-to-user group and cannot be active in a push-to-user group, such as push-to-talk data packets or push-to-watch data packets. It becomes possible to broadcast all push-to-data packets simultaneously. Thus, like a wireless or television program, activities performed within a push-to-user group can be broadcast to a large or small number of broadcast clients.

  In one embodiment of the present invention, the method includes a push-to-priority indication that indicates a priority level to be given to a push-to-data packet when broadcasting a push-to-data packet. The method further includes providing a data packet. A push-to-data packet can be given priority over other data packets, and the push-to-server is connected to a broadcast-report node and / or a broadcast-node that connects the push-to-server to the broadcast distribution network. Push-to-data packets can be broadcast in real time if the transmission delay at the interface connecting the two can be minimized. Even if there are other IP packets waiting to be transmitted in the IP router, it is possible to transmit a push-to-data packet or a burst of push-to-data packets without forming a queue according to the priority instruction. Can be guaranteed. The priority indication helps to allow the IP router to plan the transmission of push-to-data packets even when there are other data packets waiting in the router's buffer.

  Push-to-data packets are advantageously received via a communication interface having a user plane part and a control plane part. In one embodiment of the present invention, the method includes transmitting an implementation status message including information about push-to-session of a push-to-user group from the control plane unit to the user plane unit, and session status to the user plane unit. And a step of associating the push-to-data packet with the session state.

  Thereby, session dependent information can be used in push-to-data packet communication by the user plane unit. In this embodiment, providing a push-to-data packet with a priority indication includes associating the push-to-data packet with a session state. This allows different conditions to be used for the manner in which the various push-to sessions provide push-to-data packets with priority indications.

  The method is preferably formatted according to a first protocol used for sending control messages by a push-to-server and receiving a control message related to a broadcast containing information about the recipient; and Converting the control message into a second control message formatted according to the second communication protocol used by the broadcast node that broadcasts the push-to-data packet via the broadcast node, and the second control message to the broadcast node Transmitting.

  This enables control messages related to broadcast to be transmitted between the push-to server and the broadcast node even when the broadcast node uses a different protocol stack than the push-to-server. Become. The first protocol may preferably be a Session Initiation Protocol (SIP).

  In one embodiment of the invention, the method further comprises the step of checking if the push-to-data packet should be broadcast. This allows the push-to-data packet to be muted for broadcasts, so information that the push-to-user does not want to broadcast is only sent to members of the push-to-user group. As a result, push-to-users can rest assured.

  In one embodiment, the method further includes storing the push-to-data packet in a storage device for push-to-data packets upon receipt of the push-to-data packet, wherein the broadcast step is from the storage device. Retrieving a push-to-data packet. This allows a push-to-session to be replayed at a different point in time, thereby enabling editing of the current push-to-session and subsequent broadcast of the session.

The problem is further addressed by the control data communication device, which receives from the first node a first control message that is formatted by the first node according to a first protocol used to transmit the control message. A second port, a protocol conversion mechanism for converting the first control message into a second control message formatted according to a second protocol used for transmission of the control message by the second node, and a second control A second port for sending a message to the second node;
The first node is a push-to-server,
The control message relates to a broadcast of push-to-data packets originating from push-to-clients joining a push-to-user group that includes at least two push-to-clients,
The second node is a broadcast node that broadcasts push-to-data packets to broadcast clients that are not part of the push-to-user group.

  The problem is also addressed by a user data communication device, the user data communication device receiving a user data packet from the first node and a first port transmitting the user data packet to the second node. The user data packet is a push-to-data packet originating from a push-to-client joining a push-to-user group including at least two push-to-clients; The second node is a push-to-server, and the second node is a broadcast node that broadcasts push-to-data packets to broadcast clients that are not part of the push-to-user group.

  A communication interface for communicating push-to-data packets from a push-to server to a broadcast node could advantageously include the control data communication device and the user data communication device. The control data communication device could be implemented as part of a push-to-server, part of a broadcast node, or one or more of several individual entities. The same applies to the user data communication device.

  The problem is further addressed by the mobile station, which sends the push-to-data packet to a push-to server for further distribution within the push-to-user group. The mobile station includes a mute mechanism and receives a first instruction that a push-to-data packet should not be broadcast to any broadcast client that is not a member of a push-to-user group; Send a second command to the push-to-server that the packet should not be broadcast. This allows push-to-data packets to be mu for broadcasts, so information that the push-to-user does not want to broadcast is sent only to members of the push-to-user group. And push-to-users can feel secure.

  For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following description taken in conjunction with the accompanying drawings, in which:

  A general configuration of a mobile radio network 100 that provides a PTT service is schematically illustrated in FIG. The mobile radio network 100 of FIG. 1 includes a PTT server 105, a core network 110, a connection network 115, and a radio base station 120. The PTT server 105 is connected to the core network 110, and the core network 110 is further connected to the connection network 115. The connection network 115 is connected to the radio base station 120, and the radio base station 120 can communicate with the mobile station 125 via the radio interface 130. Although the mobile radio network 100 may include several PTT servers 105, for simplicity, it will be assumed below that there is only one PTT server 105. Although most PTT clients 125 support many other communication services other than PTT services, for purposes of explanation only, the mobile station 125 will be referred to as a PTT client 125 in the following.

  The PTT service provided by the mobile radio network 100 is preferably controlled by the PTT server 105, which conveniently includes an interface 135 for communicating with the PTT client 125. A PTT client 125 that communicates within the mobile radio network 100 and is suitable for providing PTT services to PTT service users can implement one-way voice communication within the group of PTT clients 125 that form a PTT user group. . A PTT user group can include two or more PTT clients 125 by configuration, and members of the PTT user group may change over time. Within a PTT user group, only one PTT user 140 can speak at a time. If PTT user 140 wants to talk to one or more other PTT users 140, PTT user 140 uses PTT client 125 to request call authorization. The PTT client 125 includes software for transmitting a call permission request. Requesting call permission is often referred to as requesting a “floor” and the PTT client 125 that currently has call permission is said to occupy the floor. When a floor is given to the PTT client 125 by the PTT server 105, the corresponding PTT user 140 can talk with other PTT users 140 in the PTT user group. The PTT data packet 145 containing data corresponding to the sound recorded by the PTT client 125 occupying the current floor is routed via the PTT server 105 to other PTT clients 125 that are part of the same PTT user group.

  The PTT user 140 never requests a floor and can therefore choose to be the listening user only. Nevertheless, in order to hear discussions taking place within the PTT user group, a PTT client 125 that provides PTT services to users is still needed. Typically, subscription to a PTT service in the mobile radio network 100 is also necessary.

  According to the present invention, PTT discussions can be heard without prior requirements for joining the PTT client 125 or the mobile radio network 100.

  FIG. 2 illustrates a mobile radio communication system 201 that includes the mobile radio network 100 of FIG. 1 and provides a new interface 200 between the PTT server 105 and the broadcast node 205. Thereafter, the PTT server 105 can transmit the PTT data packet 145 received from the PTT client 125 to the broadcast node 205 via the interface 200, which is hereinafter referred to as the PTT broadcast interface 200. The broadcast node 205 is further connected to the broadcast message distribution network 210 via the connection 207, and the broadcast node 205 can transfer the PTT data packet 145 received from the PTT server 105 to the broadcast message distribution network. The broadcast node 205 could be part of the broadcast distribution network 210 or a logically separate entity. The broadcast delivery network 210 can then send a PTT data packet 145 over connection 215 to one or more clients 220, hereinafter referred to as broadcast client 220. The broadcast message distribution network 210 is a logical entity that broadcasts information, that is, can distribute the same information to a large number of broadcast clients 220. It is often the case that information distribution by the broadcast message distribution network 210 is simultaneously performed on several broadcast message clients 220. A session that broadcasts PTT data packets related to the PTT user group to one or more of the several broadcast clients 220 will be referred to as a PTT broadcast session hereinafter. The broadcast client 220 is a client that receives the PTT data packet 145 in the PTT broadcast session but cannot be active in the PTT broadcast session, that is, cannot send the PTT data packet 145. Depending on the transmission protocol used by the broadcast client 220 and broadcast delivery network 210, the connection 215 that connects the broadcast delivery network 210 to the broadcast client 220 can be wired or wireless. The broadcast distribution network 210 could support both wired and wireless transmission, or just one of the two.

  The payload of the PTT data packet 145 represents a binary sound recorded by the PTT terminal 125 while the PTT terminal 125 occupies the floor. The PTT server 105 conventionally uses a real-time transport protocol (RTP) to transmit the PTT data packet 145. The RTP packet is normally encapsulated in a UDP / IP (User Data Protocol / Internet Protocol) packet. A protocol called Session Initiation Protocol (SIP) is used by the PTT server 105 for control plane communications such as setting up a push-to-talk session.

  The PTT user 140 should preferably be given the possibility to control whether or not to broadcast its contribution to the PTT group discussion. This is based on contribution-by-contribution, or never broadcasts the contribution of a particular PTT user 140 to a PTT group discussion, but specifies that it should be transmitted only to other PTT users 140 in the PTT group This could be done in any way that the user 140 can determine. The contribution-by-contribution implementation could be implemented, for example, by the mute button 150 on the PTT client 125, but pressing the mute button on the PTT client 125 will cause any PTT user 140 to send the next time it occupies the floor. The addition of the mute label to the PTT message 145 is started. In this implementation, the broadcast node 205 could include software to interpret the mute label and ensure that any PTT message 145 having the mute label is not broadcast by the broadcast node 205. Alternatively, the PTT server 105 can interpret the mute label and if the mute label indicates that the PTT message 145 should not be broadcast, the PTT server 105 ensures that the PTT message 145 is not forwarded to the broadcast node 205 To do. The addition of the mute label can be replaced by setting the mute flag value “mute” in the PTT message 145. Alternatively, when the mute button 150 is pressed, transmission of a control message indicating that the next PTT message 145 from the PTT user 140 should not be broadcasted from the PTT client 125 to the PTT server 125 or the broadcast node 205 is started. I can do it.

  In an implementation where the PTT user 140 can generally refuse any broadcast of its contribution, each PTT that the PTT client 125 attempts to change by changing the settings of the PTT client 125 by pressing a predefined button on the PTT client 125 A mute label can be added to the message 145, or a mute flag can be set. Alternatively, a PTT message 145 from the PTT user 140 should not be broadcast to the PTT server 125 or to the broadcast node 205 by pressing a predefined button on the PTT client 125 or by a predefined sequence of button presses. The transmission of the control message indicating the message can be started. Such a mute control message may preferably be a SIP message. An example of the mute control message 300 is shown in FIG. The mute control message 300 includes an address field 305 for specifying a node to which the mute control message 300 designates a destination, a message specification field 310 for specifying the mute control message 300 related to muting of the PTT message 145, and a PTT message 145. The PTT user specifying field 315 for specifying the PTT user 140 and the PTT client 125 that should not be notified simultaneously. Other fields could also be included in the mute control message 300. The corresponding end of the mute control message should preferably also be defined to facilitate the PTT client 125 instructing the mobile radio communication system to stop muting the PTT message 145 generated from the PTT client 125. . In this implementation, either the PTT server 105 or the broadcast node 205 can have a storage device and stores specific information of the PTT user 140 that should not broadcast the PTT message 145. When the mute control message 300 is received, the specific information stored in the PTT user specific field 315 will be added to the storage device for storing the specific information of the PTT user 140 that should not broadcast the PTT message 145. Upon receipt of the PTT message 145, this storage device for storing the specific information can be examined and will not broadcast any PTT messages 145 received from the PTT user 140 specified in the storage device.

  By allowing the PTT user 140 to refuse to broadcast its contribution to the PTT group discussion, the confidentiality of the PTT user 140 is guaranteed.

  Information regarding the broadcast client 220 that is currently receiving the PTT broadcast session could preferably be stored in the broadcast node 205 or elsewhere. For example, this information could be provided to the PTT client 125 in response to a request by a short message service (SMS) of the mobile radio communication system 201. This gives PTT user 140 the possibility to check for users who will be listening to the current PTT user group discussion.

  Various types of broadcast distribution networks 210 could be used to implement the present invention. The broadcast distribution network 210 is, for example, a mobile wireless network (for example, the mobile wireless network 100 that provides the PTT service), a digital audio broadcast (Digital Audio Broadcast, DAB) network, a wireless LAN, a digital video broadcast (Digital Video Broadcast, DVB). It could be a network, a digital video broadcast-handheld (DVB-H) network, or a conventional radio broadcast network such as an FM radio network used for public transmission of radio programs, for example. If the broadcast distribution network 210 is a conventional radio broadcast network, the broadcast node 205 includes software that converts the stream of digital representation PTT data packets 145 into a format suitable for transmission over the conventional radio broadcast network.

  In order for the user 223 of the broadcast terminal 220 to be able to listen to a specific PTT user group, the broadcast terminal 220 can be tuned to the channel used by the broadcast distribution network 210 for the broadcast of a specific PTT user group Sex should preferably be present. A channel can be viewed as a set of physical and higher layer variables that uniquely identify a stream of PTT data packets 145 that originate from a PTT user group and carry data to be transmitted to the broadcast client 220 via connection 215. To do. The tuning procedure includes corresponding physical layer parameters (eg, frequency in a frequency division multiplexing system, CDMA code in a code division multiplexing system, in a time slot system, such that a desired PTT data packet 145 can be delivered to the broadcast client 220. Time slot information, etc.) and higher layer parameter selection. If the broadcast distribution network is a conventional FM radio network, the channel can correspond to frequency and the broadcast client 220 could include conventional frequency tuning means.

  The broadcast node 205 connects the PTT user group to information linked to the broadcast resource (channel) used for the PTT user group broadcast, and routes the PTT data packet 145 generated from the PTT user group to the correct broadcast resource. Should be able to do. Moreover, as will be discussed further below, this information could also be used for notification of PTT user group broadcasts.

  3GPPTS 23.246 “Service and System Aspects Technical Specification Group; Multimedia Broadcast / Multicast Service (MBMS); Configuration and Functional Description” (“Technicalb Specification Group Services and System Aspects; Multimedia Broadcast / MS; and functional description ”) and 3GPPTS 26.346“ Service and System Aspects Technical Specification Group; Multimedia Broadcast / Multicast Services; Protocols and Codes ”(“ Technicalb Specification Group Service ”). es and System Aspects; Multimedia Broadcast / Multicast service; Protocol and Codes "), the broadcast node 205 may be a broadcast multicast service center (Broadcast-Multicast-CentreB), It is. Similar nodes are defined in the corresponding 3GPP2 service broadcast and multicast services, and the term BM-SC will be used below to mean nodes of both standards. As the name implies, the BM-SC can both broadcast information and multicast. Hereinafter, both simultaneous notification and multicast will be referred to as simultaneous notification, and the present invention is equally applicable to both.

  Multimedia broadcast / multiservice is a point-to-multipoint service, which can be implemented in a mobile radio network such as a GSM or UMTS network. In the MBMS service, data is transmitted from a single source entity to a plurality of recipients, and the BM-SC is a functional entity, which provides the functions necessary for the implementation of the MBMS user service. For example, the BM-SC can provide a service as a transmission input point of a content provider, that is, the BM-SC can serve a content provider that provides content to an MBMS end user to a mobile radio network that the BM-SC provides. Connection can be provided. The BM-SC provides transmission related parameters such as start and end of MBMS bearer resources before and after content transmission to an MBMS end user, quality of service to a mobile radio network served by the BM-SC, and transmission content data. Billing records can be generated. The BM-SC includes an MBMS session and a transmission function, and the transmission function includes an MBMS distribution method that transmits actual MBMS session data to an MBMS user equipment / client group and uses an MBMS bearer service for content distribution. The BM-SC uses a standardized BM-SC control protocol for control plane communication with other nodes.

  In this implementation of the invention, the PTT server 105 is connected to the BM-SC so that the BM-SC can broadcast the PTT data packet 145 to users who do not necessarily have a connection to the PTT client 125. Next, the BM-SC operates as the broadcast node 205, and this BM-SC is hereinafter referred to as BM-SC 205i. The PTT server 105 can then be viewed as providing a service to the BM-SC 205i as a content provider. However, the PTT server 105 is different from other content providers in transmitting the provided content in real time. In addition, the content provided by the PTT server 105 is bursty, and the PTT server 105 can provide content (one or more several PTT data packets 145) at one moment, while at the next moment. The PTT server 105 cannot provide anything to the BM-SC, and can immediately provide one or more PTT data packets 145.

  In order to allow the PTT server 105 to provide content to the BM-SC 205i, the PTT broadcast interface 200 can be defined to be suitable for the interaction between the PTT server 105 and the BM-SC 205i. FIG. 4 shows a control plane unit 400 and a user plane unit 405 of an example of such a simultaneous notification interface 200. User plane and control plane communications with the PTT server 105 may preferably be handled by the session and transmission function 407 of the BM-SC 205i. The control plane 400 of the broadcast interface 200 of FIG. 4 is for the SIP connection 410 for that end of the broadcast interface 200 closer to the PTT server 105, and for that end of the broadcast interface 200 closer to the BM-SC 205i. A BM-SC control connection 415 is included. The control plane unit 400 further includes a PTT broadcast protocol conversion unit 420 that connects the SIP connection 410 with the BM-SC control connection 415. The PTT broadcast protocol conversion unit 420 can convert the SIP control message to be transmitted on the SIP connection 410 into a corresponding BM-SC control message, and can transmit the BM-SC control message on the BM-SC control connection 415. -SC control messages can be acknowledged by BM-SC 205i and vice versa, allowing control message communication between PTT server 105 and BM-SC 205i. The control message to be communicated may be related to, for example, setting up and terminating the PTT broadcast session, the format to be used for the payload of the PTT data packet 145, muting the PTT message 145 as discussed above, and the like.

  The PTT broadcast protocol conversion unit 420 could be implemented as a separate physical device, as part of the PTT server 105 or BM-SC 205i, or as part of any other suitable node. The PTT broadcast notification protocol conversion unit 420 of FIG. 4 operates only on the control plane part of the broadcast notification interface 200. In other implementations of the present invention, the PTT broadcast protocol conversion unit 420 can operate on the user plane portion of the broadcast interface 200 and is used by the broadcast 205 from the speech encoding format used by the PTT server 105, for example. It would be possible to perform a coding conversion of the PTT data packet 145 to a voice coding format.

  The user plane 405 of FIG. 4 can be advantageously implemented through the use of an IP network 425, which can transmit PTT data packets 145 from the PTT server 105 to the BM-SC 205i in real time. As used herein, this means that there is virtually no delay due to real time, or that a delay of about 15-20 ms may be acceptable. Transmission in the user plane portion 405 of the broadcast interface 200 may preferably include IP / UDP protocol and RTP protocol.

  In order to ensure that the BM-SC 205i forwards any PTT data packet 145 to the broadcast delivery network 210 in real time, the PTT data packet 145 may advantageously be marked with a priority label. The priority label may preferably be used to indicate to the BM-SC 205i that the received PTT data packet 145 should be given priority over data packets received from other sessions. Moreover, the priority label could also be used to instruct the IP network 425 that the PTT data packet 145 should be given priority over other IP packets in the IP network 425. By giving high priority to the PTT data packet 145, real-time transmission of the PTT data packet 145 can be guaranteed. An example of the PTT data packet 145 to which the priority label 500 is added is shown in FIG. In the PTT data packet 145 of FIG. 5, the priority label 500 is included in the header 505 of the PTT data packet 145. If the PTT data packet 145 is an IP packet, the priority label 500 could be indicated in, for example, a “type of service” (ToS) field or a “traffic class” field. A standard differentiated services IP router can then be used in the IP network 425 and does not require modification of the payload 510 of the PTT data packet 145, so more user data can be transmitted in each PTT data packet 145. I can do it. In this implementation, the priority label 500 can be included in the header 505 so that the IP router of the IP network 425 will recognize the priority label 500 as a priority label. The priority may be given to the PTT data packet 145 in the SC 205i. In alternative implementations, the priority label 500 could be added to the PTT data packet 145 as tail or head. On the other hand, in this implementation, the PTT data packet 145 will not be recognized as an IP packet, and the broadcast interface 200 will have to be a single link between the PTT server 105 and the BM-SC 205i. In yet another alternative, the priority label 500 can be added into the payload 510 of the PTT data packet 145 so that the BM-SC 205i must open the PTT data packet 145 and detect the priority label 500. I will. On the other hand, in this implementation, any IP router in IP network 425 will not recognize that priority should be given to PTT data packet 145. Alternatively, the IP network 425 could use the sender's IP address to specify the priority of the PTT data packet 145. All PTT data packets 145 originating from the same PTT server 105 will then be given the same priority.

  The priority labeling unit 500 can add the priority label 500 to the PTT data packet 145. For example, the priority unit may be a part of the PTT server 105 or a part of the PTT broadcast protocol conversion unit 420. Or it could be implemented as a separate unit. In a simple embodiment of the priority label 500, the priority label 500 is a binary digit, a binary digit with a value of 1 can represent a high priority, ie a real time PTT data packet 145, and another value is low. It could represent a priority, ie a data packet from another content provider. Alternatively, the presence of priority label 500 could indicate real-time PTT data packet 145, but without priority label 500, it indicates a best effort data packet that does not require real-time transmission. I can do it.

  In another embodiment, the priority label 500 can take multiple values. This may be caused by, for example, a specific PTT data packet 145 originating from a PTT user 140 in a specific state (eg, a leader of a PTT user group) instructing the BM-SC 205i of a PTT broadcast session to which the specific PTT data packet 145 relates May be advantageous for indicating, indicating that the PTT data packet 145 includes an emergency message, and so on. The different values that the priority label 500 can take could also include values representing the mute labels discussed above. In this embodiment, an interface 440 between the control plane unit 400 and the prioritization node 430 can advantageously be established, and this interface is connected to the priority conversion unit 430 with the protocol conversion unit 420. As shown in FIG. Alternatively, the provision of this information to the prioritization unit 430 could be handled by another entity.

  The interface 440 could be used to implement status information related to the PTT broadcast session in the prioritization unit 430. The state information implemented in the priority granting unit 430 may be part or all of session description protocol (SDP) information carried in the SIP signal notification related to the PTT broadcast session. The information is stored together with specific information for specifying a PTT broadcast session related to the information. The session description protocol is specified in the document RFC2327 of the Internet Engineering Task Force (IETF). For example, the SDP information carried in the SIP signal notification is information relating to the priority to be given to the PTT data packet 145 of the session (may be dedicated to the user), IP address, port number and voice sample related to the session. It could include the code to use (eg, pulse code modulation), a URL (Uniform resource locators) that identifies websites from which more information about the topic of the session can be retrieved, etc. For further distribution to the BM-SC 205i, the PTT data packet 145 received by the priority granting unit 430 includes specific information for specifying the PTT broadcast session in which the PTT data packet 145 is generated. Accordingly, status information stored in the priority grant unit 430 related to this PTT broadcast session, such as priority information, could be applied to the PTT data packet 145 by the priority grant unit 430.

  In order for the BM-SC 205i to be able to interpret the priority label 500, the BM-SC 205i should preferably have a priority label interpretation unit 435 that interprets the priority label 500. The priority label interpretation unit 435 is preferably part of the BM-SC 205i or could be implemented as a separate physical device. In embodiments where the representation of the various values of the priority label 500 varies, the priority label interpretation unit 435 can have a connection similar to the connection 440, which causes the priority label interpretation unit 435 to have a priority label 500. Could provide information related to the interpretation of

  The priority label 500, which can take multiple values, allows different values to indicate different levels of priority. On the other hand, in many cases, the same level of priority must be given to PTT broadcast sessions related to different values by BM-SC 205i. Accordingly, the priority level can be indicated by a simple binary priority label 500, but the session information can be indicated by an individual session information label.

  FIG. 4 shows a control plane unit 400 and a user plane unit 405 that use different connections. Needless to say, in the implementation of the present invention, the control plane unit 400 and the user plane unit 405 could use the same physical connection (eg, a core network based on the IP of a mobile network operator). .

  FIG. 6 shows an example of signal notification related to the PTT broadcast session and executed by the PTT broadcast protocol conversion unit 420 between the PTT server 105 and the BM-SC 205i of FIG. The control plane entities related to signal notification shown in FIG. 6 are the PTT server 105, the PTT broadcast protocol conversion unit 420, the BM-SC 205i, and the broadcast distribution network 210. Signal notification of the control plane of FIG. 6 is shown by using broken lines. The illustrated signaling includes a first set of control messages 600 related to setting up a PTT broadcast session, delivery 603 of a PTT data packet 145, and a second set of control messages 604 related to closing a PTT broadcast session. Including. The first set of control messages 600 illustrates an example of PTT broadcast session setup between the PTT server 105 and the BM-SC 205i. A “SIP invite BM-SC URL” message 605 is transmitted from the PTT server 105 to the PTT broadcast protocol conversion unit 420 via the SIP connection 410. The “SIP Invite BM-SC URL” message 605 is converted into a corresponding “BM-SC Session Start Request” message 610 by the PTT broadcast protocol conversion unit 420 and transmitted to the BM-SC 205i via the BM-SC control connection 415. . The PTT broadcast message protocol conversion unit 420 also sends a “SIP 100 trial” message 615 and a “SIP 180 call” message 620 to the PTT server 105, indicating that the “SIP Invite BM-SC URL” message 605 has been activated. To instruct.

  Upon receipt of the “BM-SC session start request” message 610, the BM-SC 205i assigns specific information (single or multiple) / resources for the broadcast message network to the related PTT user group and broadcasts the message using a suitable protocol. A “session start request” message 625 is transmitted to the network 210 via the connection 207. A “session start request” message 625 received by the broadcast delivery network 210 activates the broadcast delivery network 210 and allocates resources for transmission of the PTT data packet 145. Next, a “session start OK” message 630 is transmitted from the broadcast message distribution network 210 to the BM-SC 205i, and the “session start OK” message is transmitted to the PTT broadcast message protocol conversion unit 420 by the BM-SC 205i via the BM-SC control connection 415. This is transferred as a “BM-SC session start OK” message 635. The “BM-SC session start OK” message 635 is converted by the PTT broadcast protocol conversion unit 420 into a corresponding “SIP200 OK” message 645 to be transmitted via the SIP connection 410. In the implementation of the present invention shown in FIG. 6, the reception of the “BM-SC session start OK” message 635 by the PTT broadcast protocol conversion unit 420 activates the PTT broadcast protocol conversion unit 420 and sends it to the priority grant unit 430 “status”. An “implementation” message 640 is sent and the state is implemented in the prioritization unit 430 as discussed above.

  Distribution 603 of the PTT data packet 145 from the PTT server 105 to the broadcast client 220 via the IP network 425 for streaming, for example by using the RTP protocol, or for downloading, for example, FLUTE (File Delivery over Unidirectional Transport, File delivery via one-way transmission) or by any other suitable protocol. In FIG. 6, a dotted line indicating a user plane entity indicates that this user plane entity is related to the delivery 603 of the PTT data packet 145. This applies to the PTT server 105, the priority assignment unit 430, the BM-SC 205i, the broadcast notification distribution network 210, and the broadcast notification terminal 220. In the embodiment illustrated by FIG. 6, the priority grant unit 430 adds a priority label 500 to the PTT data packet 145.

  The second set 604 of control messages for closing the PTT broadcast session is sent to the “SIP by BMSC URL” message 650 and “SIP by BMSC URL” message 650 transmitted from the PTT server 105 to the PTT broadcast protocol conversion unit 420. In response to the “BM-SC session stop request” message 655 and the “BM-SC session stop request” message 655 transmitted from the PTT broadcast message protocol conversion unit 420 to the BM-SC 205i, the “session” transmitted from the BM-SC 205i. A “stop request” message 660. Upon receipt of the “Session Stop Request” message 660, the broadcast delivery network 210 releases resources allocated to close the PTT broadcast session. Next, a “session stop OK” message 665 is transmitted from the broadcast message delivery network 210 to the BM-SC 205 i, and the BM-SC 205 i transmits a “BM-SC session stop OK” message 670 to the PTT broadcast message protocol conversion unit 420. In response to receiving this message, the PTT broadcast protocol conversion unit 420 transmits a “SIP200 OK” message 680 to the PTT server 105 and a “state deletion” message 675 to the priority granting unit 430.

  In the example of signal notification shown in FIG. 6, the PTT server 105 starts a PTT broadcast session by transmitting an “Invite BM-SC URL” message. In another example, a PTT broadcast session could be initiated by BM-SC 205i. This could be advantageous if, for example, the number of broadcast clients 220 is much smaller than the number of PTT clients 125, as there is a great risk that there will be no active broadcast clients 220 that will listen to the PTT broadcast session. Once a sufficient number of broadcast clients 220 are operational, the BM-SC 205i will then be able to initiate a PTT broadcast session. When activation is implemented in the BM-SC 205i and the number of active broadcast clients 220 exceeds a predefined number, for example, 1, for example, transmission of a message regarding the start of a PTT broadcast session to the PTT server 105 can be started. Like. This activation could be, for example, a counter that counts active broadcast clients 220. Similarly, the closure of the PTT broadcast session could be initiated by BM-SC 205i.

  In order to find the PTT user group session being broadcast and the channel to be used for broadcast, the broadcast information should preferably be notified of the broadcast information network 210. This could be done in an output or input scenario. The broadcast message delivery network 210 may output channel information to the broadcast client 220, for example, or the broadcast client 220 may be able to input channel information from, for example, an IP core network of a mobile network operating company. FIG. 7 shows an example of an output notification session for notification of the PTT broadcast service via the broadcast message distribution network 210 in the embodiment where the broadcast node 205 is the BM-SC 205i. A control session of the first set 700 is used to set up a notification session. The first set 700 of FIG. 7 includes the same signaling as the first set 600 of FIG. 6 except that it does not send a “implement state” message 640. When the PTT server 105 receives the “SIP200 OK” message 645 notifying that the session has started, the PTT server 105 transmits a “PTT information” message 702 to the BM-SC 205i. The “PTT information” message 702 includes information related to the PTT user group (s) to be notified. Such information includes, for example, specific information of the PTT user group (s), specific information of the PTT user 140 currently operating in the PTT user group (s), messages already exchanged in the PTT user group (s) Or the time that the PTT user group was operating. The “PTT information” message 702 may be, for example, a SIP message, or a new protocol that includes the “PTT information” message 702 could be defined. Alternatively, message 702 could be transmitted using the FLUTE protocol.

  Upon receiving the PTT information message 702, the BM-SC 205i connects the PTT user group (s) to be notified to the assigned / assigned resource to the PTT user group (s) and notifies the related broadcast client 220. A message 703 is transmitted. Notification message 703 identifies information about PTT user group (s) to be broadcasted (to be broadcast) and channel (s) to / from broadcast to PTT user group (s). Information to be included. Other information could also be included in the notification message 703, such as specific information for PTT users 140 participating in the PTT user group (s). Specific information of the PTT user group that can be used to join the PTT user group, such as a telephone number, for example, can be broadcast by the broadcast node 205 preferably. If desired, this information could be used by broadcast user 223 who wishes to join the PTT user group as PTT user 140 via PTT capable client 220/125. Any suitable protocol can be used, but advantageously the notification message 703 could be sent using the FLUTE protocol.

  A second set of control messages 704 is used in FIG. 7 to close the notification session established by the set of control messages 700. The second set 704 of FIG. 7 includes the same signaling as the second set 604 of FIG. 6 except that the “delete state” message 675 is not sent. Upon receiving the “session stop request” message 660, the broadcast distribution network 210 releases resources allocated to the notification session. For example, a second set of control messages 704 could be triggered by PTT user group inactivity or timer expiration.

  The notification session of FIG. 7 is started by the PTT server 105. Since the PTT server 105 has information on whether the PTT user 140 is currently operating or whether there is a PTT user 140 operating with the mute function discussed above, it is easy to make notifications dynamic. To. Alternatively, a notification session for notification of the broadcast service can be started by the BM-SC 205i. The BM-SC 205i accumulates information on available PTT user groups and corresponding channels used for simultaneous notification of the PTT user group, and makes it unnecessary to exchange information between the PTT server 105 and the BM-SC 205i of FIG. I can do it. Alternatively, the notification session could be terminated by the BM-SC 205i regardless of whether the PTT server 105 or the BM-SC 205i has started the notification session.

  In the embodiment of the signal notification diagram of FIGS. 6 and 7, the broadcast node 205 is a BM-SC 205i. On the other hand, in an implementation in which the broadcast node 205 is another type of node such as a service application node of a DVB-H network, a similar signal notification diagram could be applied.

  If necessary, protocol conversion may be performed on a message to be transmitted in the connection between the broadcast node 205 and the broadcast distribution network 210. An apparatus capable of converting messages formatted according to the protocol used by the broadcast node 205 and the broadcast distribution network 210 may preferably be included in the mobile radio communication system 201.

  The present invention could be implemented such that the broadcast distribution network 210 is a mobile radio network. For example, if the broadcast node 205 is a BM-SC, the broadcast delivery network 210 could be a mobile radio network that implements a multimedia broadcast / multicast service (MBMS). Accordingly, the mobile radio network 100 that provides the PTT service to the PTT client 125 and the broadcast message distribution network 210 that broadcasts the PTT broadcast session to the broadcast client 220 may be the same. The broadcast client 220 does not have to be a client capable of PTT, but may simply be a client capable of MBMS. Advantageously in this implementation, the connection 207 between the broadcast node 205 (BM-SC) and the broadcast distribution network 210 could be a standardized Gmb interface as defined in 3GPPTS 23.256.

  The broadcast node 205 could simultaneously transfer the PTT data packet 145 to one or more broadcast distribution networks 210, such as the mobile wireless network 100 and the wireless LAN. In that case, the broadcast client 220 operating in accordance with various standards can simultaneously follow the PTT discussion sent by the broadcast node 205. Alternatively, the PTT server 105 could be connected to two or more broadcast nodes 205 that connect to various broadcast networks 210 via the broadcast interface 200.

  In the application of the present invention in which the PTT data packet 145 corresponding to the discussion conducted in the PTT user group does not need to be broadcast in real time, and the delay of the PTT broadcast session is permitted, the mobile radio communication System 201 could include a storage device that stores PTT data packets 145. In that case, the PTT server 105 would transmit to the storage device for storing the PTT data packet 145, and the stored PTT data packet 145 could be retrieved by the broadcast node 205 at a later time. The storage device that stores the PTT message 145 could be located at the PTT server 105, the broadcast node 205, or elsewhere. At that silent moment when the PTT user 140 is not talking or can refuse the PTT user 140 who refuses to broadcast its contribution, the PTT data packet 145 is for playback at a later time. It is advantageous to accumulate. In this implementation, the PTT data packet 145 could be broadcast to all broadcast clients 220 that tune to the broadcast channel during the broadcast. Alternatively, transmission of the accumulated PTT data packet 145 to the client could be performed upon request.

  The present invention has been described above with a push-to-talk service. On the other hand, the present invention can be applied to any push-to service that transmits push-to-data packets 145 in a one-way communication manner from a push-to-user 140 to a group of other push-to-users 140. The push-to-talk service is an example of a push-to-service, in which the push-to-data packet 145 is a push-to-data packet containing data representing sound. Another example of a push-to service is a push-to-watch service, in which the transmitted push-to-data packet 145 includes data representing visual data.

  The present invention is not limited to the embodiments disclosed in the accompanying drawings and the foregoing detailed description, which are presented for purposes of illustration only, and can be implemented in a number of different ways, and the invention is limited by the appended claims. Those skilled in the art will recognize that this is done.

It is an outline explanatory view of a mobile radio network which provides a PTT service. FIG. 2 is a schematic explanatory diagram of a mobile radio communication system that provides a broadcast notification interface of the present invention between a PTT server and a broadcast notification node in order to enable broadcast of discussions performed by a PTT user group. It is a schematic explanatory drawing of the mute control message used for the command of a mobile radio communication system in order to mute the PTT message generated from a specific PTT user / PTT client. It is an outline explanatory view of one embodiment of a simultaneous report interface of the present invention. It is a figure explaining the PTT data packet which added the priority label. It is a figure explaining the example of the signal notification performed in a mobile radio | wireless communications system for the setting and closing of a PTT simultaneous report session. It is a figure explaining the example of the signal notification performed in a mobile radio | wireless communications system for notification of PTT broadcast information.

Claims (22)

A method of communicating within a communication system (201) a push-to-data packet (145) generated from a push-to-client (125) participating in a push-to-user group comprising at least two push-to-clients. And
Receiving the push-to-data packet from a push-to server (105);
And simultaneously broadcasting the push-to-data packet to a broadcast client (220) that is not a member of the push-to-user group via a broadcast distribution network (210).   Providing the push-to-data packet having a priority indication (500) indicating a priority level to be given to the push-to-data packet when the push-to-data packet is broadcast simultaneously The method of claim 1, further comprising: Receiving the push-to-data packet via a communication interface having a user plane part and a control plane part, the method comprising:
Transmitting an implementation status message (640) including information about push-to-session of the push-to-user group from the control plane unit to the user plane unit;
Implementing the session state in the user plane part;
The method of claim 1 or 2, further comprising associating the push-to-data packet with the session state.   The claim when claim 3 is dependent on claim 2, wherein the step of providing the push-to-data packet with an indication of priority comprises associating the push-to-data packet with the session state. Item 4. The method according to Item 3. The method comprises
Receiving the control message related to the broadcast message, formatted according to a first protocol used to transmit the control message by the push-to server;
Converting the control message into a second control message that is formatted according to a second communication protocol used by a broadcast node that broadcasts the push-to-data packet via the broadcast delivery network;
The method according to claim 1, further comprising: transmitting the second control message to the broadcast node.   6. The method of claim 5, wherein the first communication protocol is a session initiation protocol.   The method according to any one of claims 1 to 6, further comprising the step of checking whether the push-to-data packet should be broadcast. Storing the push-to-data packet in a storage device for the push-to-data packet upon receipt of the push-to-data packet;
The method according to any one of claims 1 to 7, wherein the step of performing the broadcast includes the step of retrieving the push-to-data packet from the storage device. A control data communication device (420), wherein the first port receives from the first node a first control message that is formatted by the first node according to a first protocol used for the transmission of the control message. A protocol conversion mechanism (420) for converting the first control message into a second control message that is formatted according to a second protocol used for the transmission of the control message by a second node; A second port for transmitting the second control message to a node;
The first node is a push-to-server (105);
The control message relates to the broadcast of a push-to-data packet (145) originating from a push-to-client (125) joining a push-to-user group including at least two push-to-clients;
The control data communication device, wherein the second node is a broadcast node (105) that broadcasts the push-to-data packet to a broadcast client (220) that is not a member of the push-to-user group.   The control data communication device according to claim 9, wherein the control message relates to the setting of the push-to-talk broadcast session of the push-to-user group.   The control data communication apparatus according to claim 9, wherein the control message is related to the setting of the notification session, and information related to a push-to-talk broadcast message session is broadcasted simultaneously by the broadcast node.   It further includes a mechanism for sending an implementation status message (640) to a user plane node (405) of the communication interface, wherein the implementation status message includes information regarding the status of the push-to-session of the push-to-user group. The control data communication apparatus according to any one of claims 9 to 11.   A user data communication device (430, 435), a first port for receiving a user data packet (145) from a first node (105) and the user data packet to a second node (205) And the user data packet originates from a push-to-client (125) joining a push-to-user group comprising at least two push-to-clients. A data packet (145), wherein the first node is a push-to-server (105) and the second node is to a broadcast client (220) that is not a member of the push-to-user group; Before being a broadcast node (205) that broadcasts push-to-data packets User data communication device.   A priority indication mechanism (500) for adding a priority label (500) to the push-to-data packet indicating the level of the priority over other communication data packets to be given to the push-to-data packet. 430). The user data communication apparatus of claim 13, further comprising:   14. The user data communication device of claim 13, further comprising a priority interpretation mechanism (435) that determines the priority of the push-to-data packet.   The user data according to any one of claims 13 to 15, further comprising a mechanism for receiving a mounting state message (640) from a control plane part of the communication interface and mounting a state according to information included in the mounting state message. Communication device.   The user data communication apparatus according to any one of claims 13 to 17, further comprising means for examining a mechanism for examining whether or not a push-to-data packet should be broadcast simultaneously. The mobile radio communication system is
A storage device for storing push-to-data packets;
The user data communication device according to claim 13, further comprising a mechanism for broadcasting the push-to-data packet to the broadcast client in response to a request.   Push-to-data packets originating from push-to-clients (125) joining a push-to-user group including at least two push-to-clients from the push-to server (105) to the push-to-users 14. A communication interface for communicating with a broadcast node that broadcasts the push-to-data packet to a broadcast client (220) that is not a member of a group, the communication interface according to any one of claims 9 to 13. 20. A communication interface comprising the protocol conversion unit of claim 14 and a user data communication device according to any one of claims 14 to 19. A mobile station (125) that transmits a push-to-data packet (145) to a push-to server (105) for further distribution within a push-to-user group;
Receiving a first instruction not to broadcast a push-to-data packet to any broadcast client (220) that is not a member of the push-to-user group and broadcasting the push-to-data packet simultaneously A mobile station characterized by a mute mechanism for transmitting to the push-to-server a second command not to be reported.   The push-to-client of claim 20, wherein the second instruction is sent to the push-to server in a control message (300).   21. The push-to-client of claim 20, wherein the second instruction is sent to the push-to server as an indication in the push-to-data packet to be muted.

Images