[go: up one dir, main page]

WO2011081536A1 - Procédé et dispositif de réception de données de diffusion groupée - Google Patents

Procédé et dispositif de réception de données de diffusion groupée Download PDF

Info

Publication number
WO2011081536A1
WO2011081536A1 PCT/PL2009/000112 PL2009000112W WO2011081536A1 WO 2011081536 A1 WO2011081536 A1 WO 2011081536A1 PL 2009000112 W PL2009000112 W PL 2009000112W WO 2011081536 A1 WO2011081536 A1 WO 2011081536A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
network node
server
data
transfer group
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.)
Ceased
Application number
PCT/PL2009/000112
Other languages
English (en)
Inventor
Grzegorz Knapik
Albert Dabrowski
Bartosz Drzewinski (Bartek)
Krzysztof A. Kloc
Konrad Liedtke
Sylwester Pena (Sylwek)
Michał PYTEL
Michał ŚLUSARCZYK
Ireneusz Wlizlo
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.)
Motorola Solutions Inc
Original Assignee
Motorola Solutions Inc
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
Application filed by Motorola Solutions Inc filed Critical Motorola Solutions Inc
Priority to GB1211369.2A priority Critical patent/GB2488733B/en
Priority to PCT/PL2009/000112 priority patent/WO2011081536A1/fr
Publication of WO2011081536A1 publication Critical patent/WO2011081536A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1868—Measures taken after transmission, e.g. acknowledgments
    • H04L12/1872—Measures taken after transmission, e.g. acknowledgments avoiding ACK or NACK implosion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1868—Measures taken after transmission, e.g. acknowledgments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/15—Flow control; Congestion control in relation to multipoint traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership

Definitions

  • the present invention relates generally to communication networks and in particular to multicasting data between network nodes within a communication network.
  • Multimedia and group communications are important aspects of telecommunication networks, and the demand for such services continues to increase. For instance, there are presently many different systems and networks that allow group communication. Public safety organizations are particularly interested in group communications and dedicated resources are often provided for these organizations. Others, such as businesses and even personal users also have a desire to use multimedia and group communications due to the enhanced communication features.
  • a group communication has the efficiency of delivering one informational stream to many users, instead of providing individual
  • a broadcast can be used to communicate one data stream to multiple users.
  • each user terminal may not have the same communication capabilities, resulting in some users having a different communication experience from other users in the group.
  • multiple multicast groups can be used to deliver additional communication streams with different capabilities suited for different users.
  • an information stream can be delivered to the groups using less bandwidth than would be required if individual
  • acknowledgement messages can cause severe network congestion. Such congestion is known in the art as an acknowledgement implosion problem. Therefore, there is a need for an improved method and device for receiving multicast data.
  • FIG. 1 is a message sequence chart illustrating multicast messaging in a communication network, in accordance with some embodiments.
  • FIG. 2 is a message sequence chart illustrating a continuation of the multicast messaging of FIG. 1 , in accordance with some embodiments.
  • FIG. 3 is a message sequence chart illustrating a continuation of the multicast messaging of FIG. 2, in accordance with some embodiments.
  • FIG. 4 is a message sequence chart illustrating a continuation of the multicast messaging of FIG. 3, in accordance with some embodiments.
  • FIG. 5 is a general flow diagram illustrating a method for receiving multicast data at a first network node, in accordance with some embodiments.
  • FIG. 6 is a block diagram illustrating components of a network node, in accordance with some embodiments.
  • a method enables receiving multicast data efficiently and effectively at a first network node.
  • the method includes joining a multicast transfer group.
  • a data stream is then received from a server of the multicast transfer group, where the data stream includes the multicast data. Subsequently, it is detected that a missed data packet included in the multicast data was not received in the data stream.
  • An error status timer is therefore activated. It is then determined whether to transmit an error message to the server after the error status timer is activated.
  • Embodiments provided herein thus enable more efficient and reliable network communications involving multicast transmissions of various types of data, such as software, files, and software patches. As fewer acknowledgement messages are required, there is less network congestion. Multiple
  • acknowledgments can be multicast to transfer groups as a bitmap in a single status message, and other nodes can cancel their own status messages if such messages are made redundant by another node's previous status message. Further, some embodiments enable multiple multicast transfer groups to be created to more efficiently transfer a data stream to multiple clients, and also enable data streams to be unicast to clients when required.
  • a message sequence chart illustrates multicast messaging in a communication network 100, in accordance with some
  • both a first network node (clientl 105) and a second network node (client2 1 10) seek to obtain data (e.g., software, files, or various other types of data) in the form of a data stream from a server 115.
  • the network 100 thus configures a multicast common group 120 to manage multicast transmissions of the data stream to the clientl 105 and the client2 1 10.
  • the clientl 105 transmits a join message 125 and the client2 110 transmits a join message 130 to the multicast common group 120.
  • a multicast transfer is then initiated by the server 115
  • the message 145 can include, for example, one or more of the following fields: transfer identification, file name, scheduled time, state (e.g., whether
  • IP transfer group internet protocol
  • common multicast group 120 data packet size, and file size.
  • the clientl 105 then transmits a join message 150 to the first multicast transfer group 140 and enters a receiving data mode. Next, the clientl 105
  • the client status message 155 can include, for example, one or more of the following fields: transfer
  • a packet status report (e.g., a first packet number, last packet number, and a packet bitmap).
  • the packet bitmap can include a "0" to indicate that a packet was not received, and a "1" to indicate that a packet was received.
  • a partial bitmap can be included in a status report to reduce message size.
  • the client2 1 10 transmits a join message 160 to the first
  • the multicast transfer group 140 and enters a receiving data mode.
  • the client2 110 then transmits a client status message 165 to the server 115.
  • the server 115 then enters a sending data mode and transmits a first data packet 170 followed by a
  • transfer group 140 are multicast transmissions to each member of the first
  • FIG. 2 is a message sequence chart illustrating a continuation of the multicast messaging of FIG. 1 in the communication network 100.
  • the server 1 15 continues to transfer data packets 205, 210, 215 to the first multicast transfer group 140.
  • no acknowledgement messages are transmitted from the client 1 105 to the server 115. This can significantly reduce congestion in the network 100, particularly when the first multicast transfer group 140 includes a large number of clients.
  • the clientl 105 determines that it has missed data packet 210. Rather than immediately transmitting an error message to the server 115, the clientl 105 activates an error status timer.
  • Additional data packets 225, 230, 235 then continue to be transmitted from the server 1 15 to the first multicast transfer group 140.
  • the error status timer can be, for example, a random timer.
  • a random timer can operate between a time Tmin and a time Tmax, where
  • Tmax (N packets) x (Mean_Time_of_packet_ Eq. 2 transmission in the network).
  • the clientl 105 can calculate Tmax based on received information about N, where N is a number of packets in a particular transmission. For example, N can be included in the transfer info message 145 received from the server 1 15.
  • the clientl 105 determines that it has missed data packet 230. Because the error status timer of the clientl 105 is already activated, no further timers are set. Further, at block 245 the client2 1 10 also determines that it has missed data packet 230. Because the client2 110 has not already missed a packet, the client2 110 activates an error status timer. [0026] After transmitting a further data packet 250, the server 1 15 transmits another transfer info message 255 to the multicast common group 120. Transfer info messages can be sent periodically to provide updated information to clients regarding data transfers.
  • the server 115 then transmits a further data packet 260 to the first multicast transfer group 140.
  • the error status timer at clientl 105 which was set at block 220, expires.
  • the clientl 105 therefore transmits a client status message 265 to the first multicast transfer group 140, which message 265 includes a bitmap to indicate that data packets 210, 230 were not received.
  • the clientl 105 then continues operating in a receiving data mode.
  • the client2 110 processes the client status message 265 and promptly cancels the error status timer that was set at block 245. This occurs because the client2 110 knows that, in response to the client status message 265, the data packet 230 will be
  • FIG. 3 is a message sequence chart illustrating a continuation of the multicast messaging of FIG. 2 in the communication network 100.
  • a third network node (client3 305) joins the multicast common group 120 by transmitting a join message 310 to the multicast common group 120.
  • the server 1 15 then continues in its sending data mode by transmitting a data packet 315 to the first multicast transfer group 140, followed by a transfer info message 320 transmitted to the multicast common group 120.
  • the client3 305 then transmits a join message 325 to the first multicast transfer group 140.
  • a subsequent data packet 330 transmitted to the first multicast transfer group 140 is therefore also transmitted to the client3 305.
  • the client3 305 determines that it did not receive all of data packets 170, 175, through data packet 315. Therefore, the client3 305 activates an error status timer. The server 115 then continues to transmit data packets 340, 345 to the first multicast transfer group 140. At block 347, the error status timer activated at block 335 expires, causing the client3 305 to transmit a client status message 350 to the first multicast transfer group 140, where the message 350 identifies the data packets that the client3 305 did not receive. The client3 305 then continues in a receiving data mode.
  • the server 115 After receiving the client status message 350, the server 115 determines that it would be inefficient to retransmit to the other members of the first multicast transfer group 140 all of the data packets that the client3 305 missed. Therefore, the server 1 15 creates a second multicast transfer group 355 by transmitting a create transfer group message 360. The server 115 then transmits a transfer info message 365 to the multicast common group 120 to inform the group 120 of the existence and purpose of the second multicast transfer group 355. After receiving the message 365, the client3 305 transmits a join message 370 to the second multicast transfer group 355.
  • additional transfer groups such as the second multicast transfer group 355
  • the server 115 then transmits additional data packets 375, 376, 377 to the first multicast transfer group 140 and, alternately, transmits data packet 380, 381, 382, 383 to the second multicast transfer group 355. Because a purpose of the second multicast transfer group 355 is to provide data from the data stream that was sent earlier to the first multicast transfer group 140 but was missed by the client3 305, the data packets 380, 381, and the like sent to the second multicast transfer group 355 are identical to the data packets 170, 175, and the like previously sent to the first multicast transfer group 140. Because the client3 305 is the sole member of the second multicast transfer group 355, it can receive data packets at a unicast IP address. The client3 305 then reports any missing data packets to the server 115 using the unicast address of the server 115.
  • FIG. 4 is a message sequence chart illustrating a continuation of the multicast messaging of FIG. 3 in the communication network 100.
  • the server 1 15 continues to transmit data packets 405, 415 to the first multicast transfer group 140 and, alternately, data packet 410 to the second multicast transfer group 355.
  • the clientl 105 and client 2 110 After receiving the final data packet 415 in the data stream as members of the first multicast transfer group 140, the clientl 105 and client 2 110 enter a receiving finished mode and transmit status complete messages 420, 425, respectively, to the server 115.
  • the server 115 then transmits an
  • the acknowledgement message 430 can include, for example, one or more of a transfer identification, a transfer group IP address, and a list of all clients that have indicated that they have received all data packets in the data stream.
  • the clientl 105 and client2 1 10 After receiving the acknowledgement message 430, the clientl 105 and client2 1 10 transmit detach messages 435, 440, respectively, to the first multicast transfer group 140. The clientl 105 and client2 1 10 then enter an idle mode.
  • the server 1 15 completes transmission of data packets 445, 450, 455, 460 to the second multicast transfer group 355.
  • the client3 305 After receiving the final data packet 460 in the data stream as the sole member of the second multicast transfer group 355, the client3 305 enters a receiving finished mode and transmits a status complete message 465 to the server 1 15.
  • the server 1 15 then unicasts, because there is only one member of the second multicast transfer group 355, an acknowledgement message 470 to the client3 305. After receiving the
  • the client3 305 transmits detach messages 475, 480 to, respectively, the first multicast transfer group 140 and the second multicast transfer group 355. Both the server 115 and the client3 305 then enter an idle mode.
  • Embodiments may be implemented within various types of wired or wireless networks, including wireless local area networks (WLANs).
  • WLAN may adhere to an Institute of Electrical and Electronics Engineers (IEEE) 802 protocol, e.g. IEEE 802.1 1.
  • IEEE 802.1 1 a Medium Access Control (MAC) Layer is defined and addressing of packets, including multicast packets, is described.
  • MAC Medium Access Control
  • any of the IEEE standards or specifications referred to herein may be obtained at http://standards.ieee.org/getieee802/index.html or by contacting the IEEE at IEEE, 445 Hoes Lane, PO Box 1331, Piscataway, NJ 08855-1331 , USA.
  • WLAN encompasses both peer-to-peer communications (also referred to as “ad-hoc”) and client-server communications (also referred to as “master-slave” or “access point-station”).
  • Embodiments are also envisioned to work in other communication systems.
  • the communication system may be any one of the following: a Worldwide Interoperability for Microwave Access (WiMax) system, an Ethernet communications system, or an Internet Protocol (IP) communications system.
  • WiMax Worldwide Interoperability for Microwave Access
  • Ethernet communications system also referred to as "master-slave” or “access point-station”
  • IP Internet Protocol
  • the multicast packets may adhere to IP multicast protocols, such as Internet Group Management Protocol (IGMP), Protocol Independent Multicast (PIM), Distance Vector Multicast Routing Protocol (DVMRP), Multicast OSPF (MOSPF), Multicast BGP (MBGP), Multicast Source Discovery Protocol (MSDP), and Multicast Listener Discovery (MLD).
  • IGMP Internet Group Management Protocol
  • PIM Protocol Independent Multicast
  • DVMRP Distance Vector Multicast Routing Protocol
  • MOSPF Multicast OSPF
  • MBGP Multicast BGP
  • MSDP Multicast Source Discovery Protocol
  • MDP Multicast Listener Discovery
  • a general flow diagram illustrates a method 500 for receiving multicast data at a first network node, according to some embodiments.
  • the first network node joins a multicast common group.
  • the clientl 105 joins the multicast common group 120 by transmitting the join message 125 to the multicast common group 120.
  • the first network node joins a multicast transfer group.
  • the clientl 105 joins the first multicast transfer group 140 by
  • the first network node receives a data stream from a server of the multicast transfer group, wherein the data stream includes the multicast data.
  • the clientl 105 begins receiving a data stream from the server 115 by receiving the data packet 170 that was transmitted using a multicast
  • the first network node detects that a missed data packet included in the multicast data was not received in the data stream. For example, at block 220 the clientl 105 detects that the data packet 210 was not successfully received in the data stream received from the server 1 15.
  • the first network node activates an error status timer.
  • the clientl 105 activates a random error status timer.
  • the first network node determines whether to transmit an error message to the server after the error status timer is activated. For example, the clientl 105 determines whether to transmit to the server 115 an error message in the form of the client status message 265 after expiration of the error status timer. Alternatively, the clientl 105 determines not to send an error message to the server 1 15 if the client2 1 10 first transmitted an error message to the server 1 15 that indicated that the same data packet was not received.
  • FIG. 6 a block diagram illustrates components of a network node, such as clientl 105, according to some embodiments.
  • the clientl 105 can comprise a device such as a laptop computer or mobile telephone containing at least all the elements depicted in FIG. 6, as well as any other elements necessary for the client 1 105 to perform its particular functions.
  • the client 1 105 can comprise a collection of appropriately interconnected units or devices, wherein such units or devices perform functions that are equivalent to the functions performed by the elements depicted in FIG. 6.
  • the clientl 105 comprises a random access memory (RAM) 605 and a programmable memory 610 that are coupled to a processor 615.
  • the processor 615 also has ports for coupling to network interfaces 620, 625.
  • the network interfaces 620, 625 can be used to enable the clientl 105 to communicate with other devices in various types of wired or wireless communication networks.
  • the network interface 620 may enable the clientl 105 to transmit messages, such as the client status message 265, to the server 115.
  • the programmable memory 610 can store operating code (OC) for the processor 615 and code for performing functions associated with a network node.
  • OC operating code
  • the programmable memory 610 can store computer readable program code components 640 configured to cause execution of a method, such as the method 500, for receiving multicast data, as described herein.
  • Wireless portable electronic devices such as a network node, that utilize and benefit from the method as described herein can utilize various types of wireless network architectures including a mesh enabled architecture (MEA) network, or an Institute of Electrical and Electronics Engineers (IEEE) 802.11 network (e.g., 802.1 la, 802.1 lb, 802.1 lg, 802.1 In). It will be appreciated by those of ordinary skill in the art that such wireless communication networks can alternatively comprise any packetized communication network where packets are forwarded across multiple wireless hops.
  • MAA mesh enabled architecture
  • IEEE Institute of Electrical and Electronics Engineers
  • such a wireless communication network can be a network utilizing multiple access schemes such as OFDMA (orthogonal frequency division multiple access), TDMA (time division multiple access), FDMA (Frequency Division Multiple Access), or CSMA (Carrier Sense Multiple Access).
  • OFDMA orthogonal frequency division multiple access
  • TDMA time division multiple access
  • FDMA Frequency Division Multiple Access
  • CSMA Carrier Sense Multiple Access
  • Advantages of some embodiments provided herein therefore include enabling more efficient and reliable network communications involving multicast transmissions. As fewer acknowledgement messages are required, there is less network congestion. Multiple acknowledgments can be multicast to transfer groups as a bitmap in a single status message, and other nodes can cancel their own status messages if such messages are made redundant by another node's previous status message. Further, some embodiments provided herein enable multiple multicast transfer groups to be created to more efficiently transfer a data stream to multiple clients, and also enable data streams to be unicast to clients when required.
  • processors such as microprocessors, digital signal processors, customized processors and field programmable gate arrays (FPGAs) and unique stored program instructions (including both software and firmware) that control the one or more processors to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the method and system described herein.
  • processors or “processing devices”
  • FPGAs field programmable gate arrays
  • unique stored program instructions including both software and firmware
  • an embodiment can be implemented as a computer-readable storage medium having computer readable code stored thereon for programming a computer (e.g., comprising a processor) to perform a method as described and claimed herein.
  • Examples of such computer-readable storage mediums include, but are not limited to, a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory) and a Flash memory.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention porte sur un procédé et sur un dispositif qui permettent de recevoir efficacement des données de diffusion groupée au niveau d'un nœud de réseau. Le procédé consiste à se joindre à un groupe de transfert de diffusion groupée (étape 510). Un flux de données est ensuite reçu d'un serveur du groupe de transfert de diffusion groupée, le flux de données comprenant les données de diffusion groupée (étape 515). Ensuite, il est détecté qu'un paquet de données manquant inclus dans les données de diffusion groupée n'a pas été reçu dans le flux de données (étape 520). Un mode d'état d'erreur est par conséquent activé (étape 525). Il est ensuite déterminé s'il faut envoyer ou non un message d'erreur au groupe de transfert de diffusion groupée après que le mode d'état d'erreur a été activé (étape 530).
PCT/PL2009/000112 2009-12-29 2009-12-29 Procédé et dispositif de réception de données de diffusion groupée Ceased WO2011081536A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
GB1211369.2A GB2488733B (en) 2009-12-29 2009-12-29 Method and device for receiving multicast data
PCT/PL2009/000112 WO2011081536A1 (fr) 2009-12-29 2009-12-29 Procédé et dispositif de réception de données de diffusion groupée

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/PL2009/000112 WO2011081536A1 (fr) 2009-12-29 2009-12-29 Procédé et dispositif de réception de données de diffusion groupée

Publications (1)

Publication Number Publication Date
WO2011081536A1 true WO2011081536A1 (fr) 2011-07-07

Family

ID=42663632

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/PL2009/000112 Ceased WO2011081536A1 (fr) 2009-12-29 2009-12-29 Procédé et dispositif de réception de données de diffusion groupée

Country Status (2)

Country Link
GB (1) GB2488733B (fr)
WO (1) WO2011081536A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8594023B2 (en) 2011-12-16 2013-11-26 International Business Machines Corporation Quasi-dynamic spectrum access for internet of things (IOT) applications

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020075824A1 (en) * 2000-12-14 2002-06-20 Willekes Tom J. System and method for distributing files in a wireless network infrastructure
WO2002073882A2 (fr) * 2001-03-14 2002-09-19 International Business Machines Corporation Suppression d'accuse de reception negatif pour protocoles de multidiffusion dans des reseaux essentiellement unidirectionnels
WO2006024948A2 (fr) * 2004-08-30 2006-03-09 Nokia Corporation Mecanisme de rapport de verification de distribution point a point pour systemes de transmission point a multipoint

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020075824A1 (en) * 2000-12-14 2002-06-20 Willekes Tom J. System and method for distributing files in a wireless network infrastructure
WO2002073882A2 (fr) * 2001-03-14 2002-09-19 International Business Machines Corporation Suppression d'accuse de reception negatif pour protocoles de multidiffusion dans des reseaux essentiellement unidirectionnels
WO2006024948A2 (fr) * 2004-08-30 2006-03-09 Nokia Corporation Mecanisme de rapport de verification de distribution point a point pour systemes de transmission point a multipoint

Also Published As

Publication number Publication date
GB201211369D0 (en) 2012-08-08
GB2488733B (en) 2014-11-26
GB2488733A (en) 2012-09-05

Similar Documents

Publication Publication Date Title
CN101867877B (zh) 发送推送消息的方法、设备及系统
CN100440781C (zh) 信息传送方法和信息传送系统
AU2020416492B2 (en) Multicast Service Implementation Method and Apparatus, and Communications Device
US11337040B2 (en) Broadcast bearer management method and device thereof
US12363796B2 (en) Method and apparatus for transmission mode switching in wireless communication system
CN101027871A (zh) 在点对多点传输系统中确认数据的方法和设备
CN101175252A (zh) 多媒体广播组播服务中建立会话的方法和网络系统
JP5921506B2 (ja) 通信装置および通信方法
CN104782078A (zh) 用于执行文件修复过程的用户设备节点、服务器节点以及在此类节点中执行的方法
CN102006564B (zh) 消息互通方法及融合业务系统
WO2011081536A1 (fr) Procédé et dispositif de réception de données de diffusion groupée
CN109842876B (zh) 一种集群用户和用户组的状态订阅方法
JP2006279937A (ja) 無線基地局、無線端末および無線アクセスネットワーク
CN101938700B (zh) 一种广播多播服务系统中数据流传输的方法和系统
CN101588537A (zh) WiMAX网络中实现广播/组播的方法、装置和系统
WO2012079471A1 (fr) Procédé de détermination de durée et entité de coordination de multidiffusion/multi-cellules
JP5341821B2 (ja) マルチキャスト配信システム及び方法
HK40078060A (en) Multicast service implementing method, device, and communication device
JP6262436B2 (ja) マルチキャスト通信方法
JP6100016B2 (ja) マルチキャスト通信方法
JP2014158172A (ja) マルチキャスト通信方法
HK40078060B (en) Multicast service implementing method, device, and communication device
Nagaraj Comparison of Multicasting Protocols in Wireless Networks
WO2013029478A1 (fr) Procédé, dispositif et système de transmission d'informations de nœud feuille

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09809007

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 1211369

Country of ref document: GB

Kind code of ref document: A

Free format text: PCT FILING DATE = 20091229

WWE Wipo information: entry into national phase

Ref document number: 1211369.2

Country of ref document: GB

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09809007

Country of ref document: EP

Kind code of ref document: A1