WO2009097767A1 - 提高组播可靠性的方法、系统和组播网络 - Google Patents

提高组播可靠性的方法、系统和组播网络 Download PDF

Info

Publication number
WO2009097767A1
WO2009097767A1 PCT/CN2009/070128 CN2009070128W WO2009097767A1 WO 2009097767 A1 WO2009097767 A1 WO 2009097767A1 CN 2009070128 W CN2009070128 W CN 2009070128W WO 2009097767 A1 WO2009097767 A1 WO 2009097767A1
Authority
WO
WIPO (PCT)
Prior art keywords
retransmission window
node
notification message
size
upstream node
Prior art date
Application number
PCT/CN2009/070128
Other languages
English (en)
French (fr)
Inventor
Ning Zong
Original Assignee
Huawei Technologies Co., Ltd.
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 Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2009097767A1 publication Critical patent/WO2009097767A1/zh

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

Definitions

  • the present invention relates to the field of multicast technologies, and in particular, to a method, system, and multicast network for improving multicast reliability.
  • Multicast technology refers to a point-to-multipoint network connection technology solution between a multicast source and a receiver.
  • the multicast source simultaneously transmits the same data to multiple receiving ends, and only needs to copy one copy of the same data packet. It improves data transfer efficiency and reduces the possibility of congestion in the backbone network.
  • Multicast can be divided into application layer multicast and IP multicast.
  • Application layer multicast is a technical solution for implementing a multicast mechanism at the application layer.
  • the technical solution organizes multicast group members in an application layer overlay (overlay) network, and implements a multicast session in the application layer overlay network. Topology construction, maintenance, replication and forwarding of multicast data.
  • the multicast source is usually a server, and the receiving end is usually served by a common node.
  • the receiving end can be divided into two categories according to their positions in the topology: intermediate nodes and leaf nodes.
  • the intermediate node is responsible for receiving data from the upstream node and copying and forwarding the received data to the downstream node.
  • the leaf node is only responsible for receiving data from the upstream node.
  • IP multicast is a technical solution for implementing a multicast mechanism at the network layer. The technical solution is to send data to a specific reserved group address by a multicast source, and all the receivers joining the group can receive the data.
  • QoE Quality of Experience
  • One of the methods for realizing reliable multicast data transmission is to use multicast data retransmission, and the multicast data retransmission is usually implemented by using a communication mechanism between the multicast source and the receiving end, that is, the receiving end requests the multicast source to be re-transmitted. The data lost in the multicast data transmission is sent, and the multicast source resends the data according to the received request.
  • NCM NACK-Oriented Reliable Multicast
  • the multicast source sends a retransmission window notification message to the receiving end, where the message includes the size of the retransmission window, that is, the range of data that the receiving end can resend itself.
  • the multicast source may directly send a retransmission window notification message to the leaf node in the receiving end, or may send the retransmission window notification message to the leaf node.
  • the receiving end receives the retransmission window notification message sent by the multicast source. If the receiving end does not receive a certain piece of data, the receiving end may send a NACK (Negative Acknowledgement) to the multicast source, requesting the multicast source to be re-requested. Send lost data.
  • NACK Negative Acknowledgement
  • the multicast source After receiving the NACK, the multicast source resends the lost data to the receiving end.
  • the receiving end can know the retransmission window size of the node by retransmitting the window notification message, that is, the buffered data. At this time, the receiving end according to the received retransmission window The notification message requests the multicast source to resend the lost data, which can reduce invalid data retransmission requests.
  • the NORM protocol, message retransmission window notification message carried by SQUELCH (inhibition), the range of the data source multicast retransmission window size, i.e., can be re-transmitted, the data may be cached by the multicast source point BP (Buff er P 0 Int, cache point) to represent.
  • the retransmission window notification mechanism of the existing NORM protocol can only make the receiving end perceive the retransmission window size of the multicast source, and cannot sense the retransmission window size of the upstream node at the receiving end. Therefore, one disadvantage of applying the NORM protocol directly to application layer multicast is:
  • the intermediate node can also provide data buffering and resend data while receiving, copying, and forwarding multicast data. Therefore, if the intermediate node has data caching capability, if the downstream node of the intermediate node cannot perceive the retransmission window size of the intermediate node, the data buffered by the intermediate node cannot be fully utilized for data retransmission, thereby improving multicast. The bottleneck of reliability. Summary of the invention
  • an embodiment of the present invention provides a method, system, and multicast network for improving multicast reliability.
  • the technical solution is as follows:
  • the embodiment of the present invention provides a method for improving multicast reliability, where the method includes: receiving, by an intermediate node, a retransmission window notification message sent by a first upstream node, updating the retransmission window notification message, and The updated retransmission window notification message is sent to a downstream node of the intermediate node, and the first upstream node is an upstream node of the intermediate node.
  • an embodiment of the present invention provides a system for improving multicast reliability, where the system includes: a receiving module, configured to receive a retransmission window notification message sent by a first upstream node;
  • an update module configured to update the retransmission window notification message, and send the updated retransmission window notification message to a downstream node, where the first upstream node is an upstream node of the intermediate node.
  • an embodiment of the present invention provides a multicast network, where the multicast network includes:
  • a first upstream node configured to send a retransmission window notification message to the intermediate node
  • the intermediate node is configured to receive the retransmission window notification message, update the retransmission window notification message, and send the updated retransmission window notification message to a downstream node, where the first upstream node Is the upstream node of the intermediate node.
  • the retransmission window notification message is updated by the intermediate node, and the updated retransmission window notification message is sent to the downstream node of the intermediate node, so that the downstream node can perceive more retransmissions.
  • the data is conducive to improving the reliability of multicast.
  • FIG. 1 is a flowchart of a method for improving multicast reliability according to an embodiment of the present invention
  • FIG. 2 is a schematic diagram of networking for improving multicast reliability according to an embodiment of the present invention.
  • FIG. 3 is a schematic diagram of an update of a retransmission window notification message according to an embodiment of the present invention.
  • FIG. 4 is a schematic diagram of another retransmission window notification message update according to an embodiment of the present invention.
  • FIG. 5 is a schematic diagram of a third retransmission window notification message update according to an embodiment of the present invention.
  • FIG. 6 is a schematic diagram of updating a fourth retransmission window notification message according to an embodiment of the present invention.
  • FIG. 7 is a schematic diagram of a system for improving multicast reliability according to an embodiment of the present invention.
  • FIG. 8 is a schematic diagram of a multicast network according to an embodiment of the present invention. detailed description
  • An embodiment of the present invention provides a method for improving multicast reliability, where the intermediate node updates the retransmission window notification message, and sends the updated retransmission window notification message to the downstream node of the intermediate node (starting from the intermediate node) All nodes on the multicast path); after receiving the updated retransmission window notification message, the downstream node can sense its own upstream node (from the multicast source to all nodes on its own multicast path, including the multicast source and The retransmission window size of the intermediate node) helps the multicast reliability to be improved even if the downstream node perceives more data that can be retransmitted.
  • specific steps of the embodiment of the present invention are as follows:
  • Step 101 The multicast source node N_l sends a retransmission window notification message M to the intermediate node N_2, and the retransmission window notification message M carries BP_1 indicating the retransmission window size of the ⁇ _1.
  • the specific bearer mode of the retransmission window notification message can be the following two types: First, the new application layer multicast signaling bearer may be triggered by a timer, such as sending a retransmission window notification message from a multicast source or an intermediate node at intervals; or when certain conditions are met Trigger, such as the multicast source or an intermediate node finds that its retransmission window size has changed, sending a retransmission window notification message.
  • the typical maintenance signaling includes periodic heartbeat detection signaling between the application layer multicast nodes, and the multicast signaling source can be carried in the detection signaling. Or the retransmission window size of the intermediate node.
  • Step 102 The intermediate node ⁇ _2 receives the retransmission window notification message, performs retransmission window notification message update, and forwards the updated retransmission window notification message M1 to its own downstream node ⁇ _4 and ⁇ _5, new
  • the retransmission window notification message M1 carries the retransmission window size BP_PN_2 retransmission window size BP_2 indicating ⁇ _1.
  • the update of the retransmission window notification message by the intermediate node refers to updating the received retransmission window size BP_1 with BP_2 indicating the size of the retransmission window.
  • the update methods mainly include the following two types:
  • each node has the same Buffer End Point (BEP) and different Buffer Start Point (BSP).
  • BEP Buffer End Point
  • BSP Buffer Start Point
  • the playback progress of each node is the same, and the cache data length is different, that is, the retransmission window size is different.
  • the retransmission window size BP_1 of ⁇ _1 is 5- 10 minutes content
  • N_2 retransmission window size BP_2 is 2- 10 minutes content.
  • Retransmission window notifications Examples of message updates are as follows:
  • N_2 After N_2 receives the retransmission window notification message M of N_1, as shown in FIG. 3, if the retransmission window size BP_2 of N_2 can cover the retransmission window size BP_1 of N_1, the update is represented by ⁇ BSP_2, BEP ⁇ . Retransmit the window size, and mark ⁇ BSP_1, BEP ⁇ as the intersection of the retransmission window sizes of N_1 and N_2, and mark ⁇ BSP_1, 88?_2 ⁇ as the unique retransmission window size of ⁇ _2.
  • N_2 After N_2 receives the retransmission window notification message of N_l, as shown in Figure 4, if the retransmission window size of N_2
  • BP_2 cannot cover the retransmission window size BP_1 of ⁇ _1, and still uses ⁇ BSP_1, BEP ⁇ to indicate the updated retransmission window size, and mark ⁇ B SP_2, BEP ⁇ as the retransmission window size of ⁇ _1 and ⁇ _2.
  • the intersection, the mark ⁇ B SP_2, BSP_1 ⁇ is the unique retransmission window size of ⁇ _1.
  • each node has a different BEP and BSP.
  • This scenario is applicable to some multicast applications, such as VoD, (Video on Demand, video on demand), the playback progress and cache length of each node are different, such as ⁇ _1 retransmission window size BP_1 is 5-10 minutes content, N_2 The retransmission window size BP_2 is 6-14 minutes of content. Specific examples are as follows:
  • N_2 receives the retransmission window notification message M of N_1, as shown in FIG. 5, ⁇ BSP_1, BEP_2 ⁇ replaces ⁇ BSP_1, BEP_1 ⁇ with the updated retransmission window size, and marks ⁇ BEP_2, 8£? _1 ⁇ is the unique retransmission window size of ⁇ _2, the mark ⁇ BEP_1, 88?_2 ⁇ is the intersection of the retransmission window sizes of ⁇ _1 and ⁇ _2, and the mark ⁇ BSP_2, BSP_1 ⁇ is the unique weight of N_l Pass the window size.
  • N_2 After receiving the retransmission window notification message M of N_1, N_2 uses ⁇ BSP_1, BEP_1 ⁇ and ⁇ BSP_2, BEP_2 ⁇ indicates the size of the updated retransmission window.
  • the updated retransmission window size must reflect the retransmission window size of the node and the upstream node of the node.
  • Step 103 ⁇ _4 and ⁇ _5 receive the retransmission window notification message M1. If one of the nodes (e.g., N_4) needs to retransmit a piece of lost data, an optimal upstream node is selected and a data retransmission request (e.g., NACK) is sent to the upstream node.
  • NACK data retransmission request
  • the N_4 can perceive the data that the upstream node (the multicast source node and the intermediate node) can retransmit. If the N_4 needs to retransmit a certain piece of lost data,
  • the preferred upstream node is selected according to the following criteria:
  • the multicast source may send a retransmission window notification message to many intermediate nodes (for example, ⁇ _2 and ⁇ _3), and correspondingly, in step 102, the intermediate node receives the group.
  • the retransmission window notification message sent by the broadcast source will update the retransmission window notification message and send the updated retransmission window notification message to its downstream node. This process will continue until all the receiving ends (including the middle) The node and leaf nodes receive an updated retransmission window notification message.
  • the retransmission window notification message is updated by the intermediate node, and the updated retransmission window notification message is sent to the downstream node of the intermediate node, so that the downstream node can perceive more retransmissions.
  • the data is conducive to improving the reliability of multicast.
  • An embodiment of the present invention provides a system for improving multicast reliability. As shown in FIG. 7, the system includes: a receiving module, configured to receive a retransmission window notification message sent by a first upstream node;
  • the update module is configured to update the retransmission window notification message, and send the updated retransmission window notification message to the downstream node.
  • the first upstream node includes all nodes on the multicast path from the multicast source node to the intermediate node; the downstream node includes all nodes on the multicast path starting from the intermediate node.
  • system further includes:
  • a recording module configured to receive an updated retransmission window notification message, and record a retransmission window size
  • a selecting module configured to: when the downstream node detects data loss, select an upstream node according to the received updated retransmission window notification message, a distance of the downstream node to the second upstream node, and/or a service capability of the second upstream node, and request Choose The upstream node resends the lost data.
  • the second upstream node includes all nodes on the multicast path from the multicast source node to the downstream node.
  • the update module includes:
  • the first update module is configured to: when the retransmission window size of the intermediate node can cover the retransmission window size of the first upstream node, take the retransmission window size of the intermediate node as the updated retransmission window size, and take the intermediate node retransmission window.
  • the size of the retransmission window size of the first upstream node, the size of the retransmission window identified as the intermediate node and the first upstream node in the retransmission window notification message, and the size of the retransmission window unique to the intermediate node, in the retransmission window The size of the retransmission window unique to the intermediate node identified in the notification message; or
  • a second update module configured to: when the retransmission window size of the first upstream node can cover the retransmission window size of the intermediate node, take the retransmission window size of the first upstream node as the updated retransmission window size, and take the intermediate node weight
  • the intersection of the size of the transmission window and the size of the retransmission window of the first upstream node is identified in the retransmission window notification message as the retransmission window size of the intermediate node and the first upstream node, and the size of the retransmission window unique to the first upstream node is taken.
  • the size of the retransmission window unique to the first upstream node is identified in the retransmission window notification message; or
  • a third update module configured to: when the retransmission window size of the first upstream node and the retransmission window size of the intermediate node cannot overlap each other, take the union of the size of the retransmission window of the first upstream node and the intermediate node as the update weight Transmitting the window size, taking the intersection of the intermediate node retransmission window size and the size of the first upstream node retransmission window, and identifying the retransmission window size of the intermediate node and the first upstream node in the retransmission window notification message, which is unique to the intermediate node
  • the size of the retransmission window is identified in the retransmission window notification message as the size of the retransmission window unique to the intermediate node, and the size of the retransmission window unique to the first upstream node is identified as the first upstream in the retransmission window notification message.
  • the size of the retransmission window unique to the node is identified in the retransmission window notification message.
  • the receiving module and the updating module are integrated on the intermediate node; the recording module and the selecting module are integrated on the downstream node of the intermediate node.
  • the retransmission window notification message is updated by the intermediate node, and the updated retransmission window notification message is sent to the downstream node of the intermediate node, so that the downstream node can perceive more retransmissions.
  • the data is conducive to improving the reliability of multicast.
  • the embodiment of the invention provides a multicast network.
  • the multicast network includes:
  • a first upstream node configured to send a retransmission window notification message to the intermediate node
  • the intermediate node is configured to receive a retransmission window notification message, update the retransmission window notification message, and send the updated retransmission window notification message to the downstream node.
  • the network further includes a downstream node, where the downstream node is configured to receive an updated retransmission window notification message, and record a retransmission window size; when detecting data loss, select an upstream node according to the received updated retransmission window notification message. And request the selected upstream node to resend the lost data.
  • the intermediate node updating the retransmission window notification message refer to step 102 of the method embodiment.
  • the selected upstream node For a detailed process of selecting an upstream node by a downstream node, refer to step 103 of the method embodiment.
  • the retransmission window notification message is updated by the intermediate node, and the updated retransmission window notification message is sent to the downstream node of the intermediate node, so that the downstream node can perceive more retransmissions.
  • the data is conducive to improving the reliability of multicast.
  • the technical solution of the embodiment of the present invention can be extended to IP multicast.
  • the specific application scenario is that the IP multicast node has cached data for retransmission.

Landscapes

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

Description

提高组播可靠性的方法、 系统和组播网络 本申请要求于 2008年 02月 04日提交中国专利局、 申请号为 200810009198. 4、发明名 称为 "提高组播可靠性的方法、 系统和组播网络" 的中国专利申请的优先权， 其全部内容 通过引用结合在本申请中。
说
技术领域
本发明涉及组播技术领域， 特别涉及一种提高组播可靠性的方法、 系统和组播网络。 背景技术 书
组播 （Multicast) 技术是指在组播源和接收端之间实现点对多点网络连接技术方案。 该 技术方案中， 组播源同时给多个接收端传输相同的数据， 只需复制一份的相同数据包。 它 提高了数据传送效率， 减少了骨干网络出现拥塞的可能性。
组播可以分为应用层组播和 IP组播。 应用层组播是一种在应用层实现组播机制的技术方 案，该技术方案将组播组成员组织在一个应用层 overlay (叠加）网络中，并在该应用层 overlay 网络实现组播会话的拓扑构建、 维护、 组播数据的复制和转发等功能。 在应用层组播中， 组播源通常为服务器， 接收端通常由普通节点担当。 接收端按照在拓扑中的位置不同可分 为两类： 中间节点和叶子节点。 中间节点负责从上游节点接收数据， 并将接收的数据复制 和转发给下游节点。叶子节点只负责从上游节点接收数据。 IP组播是一种在网络层实现组播 机制的技术方案， 该技术方案是由组播源将数据发送到特定的预约的组地址， 所有加入该 组的接收端均可以接收到这份数据。
在组播应用 （如多方音 /视频业务） 中， 用户通常要求较高的 QoE (Qualification of Experience, 用户体验质量） 。 其中， QoE中包含了如何实现可靠的组播数据传输。 实现可 靠的组播数据传输的方法之一是利用组播数据重传， 而实现组播数据重传通常利用组播源 和接收端之间的通信机制来实现， 即接收端请求组播源重新发送组播数据传输中丢失的数 据， 组播源根据接收的请求重新发送数据。
现有技术提供了一种面向反应答可靠组播（NACK-Oriented Reliable Multicast, NORM) 协议， 该协议为 IP组播的组播源和接收端分别定义了一系列实现可靠组播数据传输的功能， 具体如下： ( 1 ) 组播源向接收端发送重传窗口通知消息， 该消息中包含重传窗口大小， 即通知接 收端自己可以重新发送的数据的范围。 组播源可以直接向接收端中的叶子节点发送重传窗 口通知消息， 也可以经由中间节点发送给叶子节点。
( 2 ) 接收端接收组播源发送的重传窗口通知消息， 如果接收端在探明没有接收到某段 数据， 可以向组播源发送 NACK (Negative Acknowledgement, 反应答） ， 要求组播源重新 发送丢失的数据。
( 3 ) 组播源在接收到 NACK后， 向接收端重新发送丢失的数据。
在网络状况较差， 组播源缓存较小等情况下， 接收端通过重传窗口通知消息， 可以知 道节点的重传窗口大小， 即缓存的数据， 此时， 接收端根据接收的重传窗口通知消息向组 播源请求重发丢失的数据， 这样能够减少无效的数据重传请求。 根据 NORM协议， 重传窗 口通知消息由 SQUELCH (抑制） 消息承载， 组播源的重传窗口大小， 即可以重新发送的数 据的范围， 可以由组播源的数据缓存点 BP(Buffer P0int， 缓存点)来表示。
在实现本发明过程中， 发明人发现现有技术中至少存在如下问题：
现有 NORM协议的重传窗口通知机制只能让接收端感知组播源的重传窗口大小， 无法 感知接收端的上游节点的重传窗口大小。 所以， 将 NORM协议直接运用到应用层组播的一 个缺点是： 在应用层组播中， 中间节点在接收、 复制和转发组播数据的同时， 还可以提供 数据缓存以及重新发送数据的功能。 因此， 在中间节点有数据缓存能力的情况下， 如果中 间节点的下游节点无法感知中间节点的重传窗口大小， 也就无法充分利用中间节点缓存的 数据来进行数据重传， 从而成为提高组播可靠性的瓶颈。 发明内容
为了提高组播可靠性， 本发明实施例提供了一种提高组播可靠性的方法、 系统和组播 网络。 所述技术方案如下：
一方面， 本发明实施例提供了一种提高组播可靠性的方法， 所述方法包括： 中间节点接收第一上游节点发送的重传窗口通知消息， 更新所述重传窗口通知消息， 并将所述更新后的重传窗口通知消息发送给所述中间节点的下游节点， 所述第一上游节点 为所述中间节点的上游节点。
另一方面， 本发明实施例提供了一种提高组播可靠性的系统， 所述系统包括： 接收模块， 用于接收第一上游节点发送的重传窗口通知消息；
更新模块， 用于更新所述重传窗口通知消息， 并将所述更新后的重传窗口通知消息发 送给下游节点， 所述第一上游节点为所述中间节点的上游节点。 另一方面， 本发明实施例提供了一种组播网络， 所述组播网络包括：
第一上游节点， 用于向中间节点发送重传窗口通知消息；
所述中间节点， 用于接收所述重传窗口通知消息， 更新所述重传窗口通知消息， 并将 所述更新后的重传窗口通知消息发送给下游节点， 其中， 所述第一上游节点为所述中间节 点的上游节点。
在本发明实施例中， 由中间节点进行重传窗口通知消息的更新， 并将更新的重传窗口 通知消息下发给该中间节点的下游节点， 可以使下游节点感知到更多可供重传的数据， 有 利于提高组播的可靠性。 附图说明
图 1是本发明实施例提供的一种提高组播可靠性的方法的流程图；
图 2是本发明实施例提供的一种提高组播可靠性的组网示意图；
图 3是本发明实施例提供的一种重传窗口通知消息更新的示意图；
图 4是本发明实施例提供的另一种重传窗口通知消息更新的示意图；
图 5是本发明实施例提供的第三种重传窗口通知消息更新的示意图；
图 6是本发明实施例提供的第四种重传窗口通知消息更新的示意图；
图 7是本发明实施例提供的一种提高组播可靠性的系统示意图；
图 8是本发明实施例提供的一种组播网络示意图。 具体实施方式
为使本发明的目的、 技术方案和优点更加清楚， 下面将结合附图对本发明实施方式作 进一步地详细描述。
本发明实施例提供了一种提高组播可靠性的方法， 该方法由中间节点更新重传窗口通 知消息， 并将更新的重传窗口通知消息下发给中间节点的下游节点 （从中间节点开始的组 播路径上的所有节点） ； 下游节点接收到更新的重传窗口通知消息后， 可以感知自身的上 游节点 （从组播源到自身的组播路径上的所有节点， 包括组播源和中间节点） 的重传窗口 大小， 即使下游节点感知到更多的可供重传的数据， 从而有助于提高组播可靠性。 参见图 1 和图 2， 本发明实施例的具体歩骤如下：
步骤 101 : 组播源节点 N_l向中间节点 N_2发送重传窗口通知消息 M， 重传窗口通知消 息 M携带表示^^_1重传窗口大小的 BP_1。
在本步骤中， 重传窗口通知消息的具体承载方式可以有以下两种： 第一， 由新的应用层组播信令承载， 可以由定时器触发， 如每隔一段时间， 从组播源 或某个中间节点开始发送重传窗口通知消息； 也可以在满足一定条件时触发， 如组播源或 某个中间节点发现自己的重传窗口大小发生了变化， 发送重传窗口通知消息。
第二， 由现有的应用层组播会话维护信令承载， 典型的维护信令包括应用层组播节点 之间的周期性心跳检测信令， 在该检测信令中可以带上组播源或中间节点的重传窗口大小。
步骤 102： 中间节点^^_2接收到重传窗口通知消息 ， 进行重传窗口通知消息的更新， 并将更新的重传窗口通知消息 Ml转发给自己的下游节点^^_4和^^_5，新的重传窗口通知消息 Ml携带表示^^_1的重传窗口大小 BP_ PN_2重传窗口大小 BP_2。
在本步骤中， 中间节点进行重传窗口通知消息的更新是指用表示自己重传窗口大小的 BP_2更新接收到的重传窗口大小 BP_1， 更新方式主要有以下两种：
第一、 各个节点具有相同的缓存结束点 （Buffer End Point, BEP) ， 不同的缓存起始点 (Buffer Start Point, BSP) 。 该场景适用于某些组播应用， 例如 BTV (Broadcast TV, 直播 电视） ， 各个节点的播放进度相同， 缓存数据长度不同， 即重传窗口大小不同， 如^^_1的重 传窗口大小 BP_1为 5- 10分钟内容， N_2的重传窗口大小 BP_2为 2- 10分钟内容。重传窗口通知 消息更新的实例如下：
( 1 ) N_2接收到 N_l的重传窗口通知消息 M后， 如图 3所示， 如果 N_2的重传窗口大小 BP_2能够覆盖N_1的重传窗口大小 BP_1， 则用 {BSP_2， BEP}表示更新的重传窗口大小， 并 标记 { BSP_1， BEP }为N_1和N_2的重传窗口大小的交集， 标记 {BSP_1， 88?_2}为^^_2的独 有的重传窗口大小。
(2) N_2接收到 N_l的重传窗口通知消息 M后， 如图 4所示， 如果 N_2的重传窗口大小
BP_2不能覆盖^^_1的重传窗口大小 BP_1， 则仍用 {BSP_1， BEP}表示更新的重传窗口大小， 并标记 { B SP_2， BEP }为^^_1和^^_2的重传窗口大小交集， 标记 {B SP_2， BSP_1 }为^^_1独有 的重传窗口大小。
第二、各个节点具有不同的 BEP和 BSP。该场景适用于某些组播应用，例如 VoD， (Video on Demand,视频点播）各个节点的播放进度和缓存长度都不同，如^^_1的重传窗口大小 BP_1 为 5-10分钟内容， N_2的重传窗口大小 BP_2为 6-14分钟内容。 具体的实例如下：
( 1 ) N_2接收到 N_l的重传窗口通知消息 M后， 如图 5所示， 用 {BSP_1， BEP_2 弋替 {BSP_1 , BEP_1 }表示更新的重传窗口大小， 并标记 {BEP_2， 8£?_1 }为^^_2独有的重传窗口 大小， 标记 {BEP_1， 88?_2}为^^_1和^^_2的重传窗口大小的交集， 标记 {BSP_2， BSP_1 }为 N_l独有的重传窗口大小。
( 2 ) N_2接收到 N_l的重传窗口通知消息 M后， 如图 6所示， 用 {BSP_1， BEP_1}和 {BSP_2, BEP_2}表示更新的重传窗口大小。
需要说明的是， 无论采用何种重传窗口大小更新方式， 更新后的重传窗口大小必须能 够反映本节点和本节点上游节点的重传窗口大小。
步骤 103 : ^^_4和^^_5接收重传窗口通知消息 Ml。 如果其中一个节点 （例如 N_4) 需要 重传某段丢失的数据， 则选择一个最优的上游节点， 并发送数据重传请求（例如 NACK)给 该上游节点。
在本步骤中， N_4接收到重传窗口通知消息 Ml后， 则可以感知到上游节点 （组播源节 点和中间节点）可以重传的数据， 如果 N_4需要重传某段丢失的数据， 则可以依据下列标准 选择优选的上游节点：
第一、 根据本节点到上游节点的网络距离。 网络距离越小， 意味重传数据的时延越短， 网络带宽的占用越少， 从而该上游节点越优。
第二、 根据上游节点的服务能力。 上游节点的服务能力越大， 意味处理能力越强， 网 络带宽越高， 从而该上游节点越优。
需要说明的是， 在步骤 101中， 组播源可能会同时向很多中间节点 （例如 ^^_2和^^_3 ) 发送重传窗口通知消息， 相应地， 在步骤 102中， 中间节点接收到组播源发送的重传窗口通 知消息， 会进行重传窗口通知消息的更新， 并将更新后的重传窗口通知消息发送给其下游 节点， 这个过程会持续进行， 直到所有的接收端 （包括中间节点和叶子节点） 接收到更新 的重传窗口通知消息。
在本发明实施例中， 由中间节点进行重传窗口通知消息的更新， 并将更新的重传窗口 通知消息下发给该中间节点的下游节点， 可以使下游节点感知到更多可供重传的数据， 有 利于提高组播的可靠性。 本发明实施例提供了一种提高组播可靠性的系统， 如图 7所示， 该系统包括： 接收模块， 用于接收第一上游节点发送的重传窗口通知消息；
更新模块， 用于更新重传窗口通知消息， 并将更新后的重传窗口通知消息发送给下游 节点。 该第一上游节点包括从组播源节点到中间节点的组播路径上的所有节点； 该下游节 点包括从中间节点开始的组播路径上的所有节点。
进一步， 该系统还包括：
记录模块， 用于接收更新的重传窗口通知消息， 记录重传窗口大小；
选择模块， 用于当下游节点检测到数据丢失时， 根据接收的更新的重传窗口通知消息、 下游节点到第二上游节点的距离和 /或第二上游节点的服务能力选择上游节点， 并要求选择 的上游节点重发丢失的数据。 所述第二上游节点包括从组播源节点到下游节点的组播路径 上的所有节点。
其中， 更新模块包括：
第一更新模块， 用于当中间节点的重传窗口大小能覆盖第一上游节点的重传窗口大小 时， 取中间节点的重传窗口大小作为更新的重传窗口大小， 取中间节点重传窗口大小和第 一上游节点重传窗口大小的交集， 在重传窗口通知消息中标识为中间节点和第一上游节点 的重传窗口大小， 取中间节点独有的重传窗口大小， 在重传窗口通知消息中标识为中间节 点独有的重传窗口大小； 或
第二更新模块， 用于当第一上游节点的重传窗口大小能覆盖中间节点的重传窗口大小 时， 取第一上游节点的重传窗口大小作为更新的重传窗口大小， 取中间节点重传窗口大小 和第一上游节点重传窗口大小的交集， 在重传窗口通知消息中标识为中间节点和第一上游 节点的重传窗口大小， 取第一上游节点独有的重传窗口大小， 在重传窗口通知消息中标识 为第一上游节点独有的重传窗口大小； 或
第三更新模块， 用于当第一上游节点的重传窗口大小和中间节点的重传窗口大小不能 相互覆盖时， 取第一上游节点和中间节点的重传窗口大小的并集作为更新的重传窗口大小， 取中间节点重传窗口大小和第一上游节点重传窗口大小的交集， 在重传窗口通知消息中标 识为中间节点和第一上游节点的重传窗口大小， 取中间节点独有的重传窗口大小， 在重传 窗口通知消息中标识为中间节点独有的重传窗口大小， 取第一上游节点独有的重传窗口大 小， 在重传窗口通知消息中标识为第一上游节点独有的重传窗口大小。
需要说明的是， 接收模块和更新模块集成在中间节点上； 记录模块和选择模块集成在 中间节点的下游节点上。
在本发明实施例中， 由中间节点进行重传窗口通知消息的更新， 并将更新的重传窗口 通知消息下发给该中间节点的下游节点， 可以使下游节点感知到更多可供重传的数据， 有 利于提高组播的可靠性。
本发明实施例提供了一种组播网络， 如图 8所示， 该组播网络包括：
第一上游节点， 用于向中间节点发送重传窗口通知消息；
中间节点， 用于接收重传窗口通知消息， 更新重传窗口通知消息， 并将更新后的重传 窗口通知消息发送给下游节点。
进一步地， 该网络还包括下游节点， 该下游节点用于接收更新的重传窗口通知消息， 记录重传窗口大小； 当检测到数据丢失时， 根据接收的更新的重传窗口通知消息选择上游 节点， 并请求选择的上游节点重发丢失的数据。 其中， 中间节点更新重传窗口通知消息的详细过程可以参见方法实施例的步骤 102。 其中， 下游节点选择上游节点的详细过程可以参见方法实施例的步骤 103。
在本发明实施例中， 由中间节点进行重传窗口通知消息的更新， 并将更新的重传窗口 通知消息下发给该中间节点的下游节点， 可以使下游节点感知到更多可供重传的数据， 有 利于提高组播的可靠性。
本发明实施例所述技术方案可以推广到 IP组播， 具体的应用场景是 IP组播节点带有用 于重传的缓存数据。
以上所述仅为本发明的较佳实施例， 并不用以限制本发明， 凡在本发明的精神和原则 之内， 所作的任何修改、 等同替换、 改进等， 均应包含在本发明的保护范围之内。

Claims

权 利 要 求 书
1、 一种提高组播可靠性的方法， 其特征在于， 所述方法包括：
中间节点接收第一上游节点发送的重传窗口通知消息， 更新所述重传窗口通知消息， 并将所述更新后的重传窗口通知消息发送给所述中间节点的下游节点， 所述第一上游节点 为所述中间节点的上游节点。
2、 如权利要求 1所述的提高组播可靠性的方法， 其特征在于， 所述方法还包括： 所述下游节点接收所述更新后的重传窗口通知消息， 记录重传窗口大小， 当所述下游 节点检测到数据丢失时， 根据所述更新后的重传窗口通知消息、 所述下游节点到第二上游 节点的距离和 /或第二上游节点的服务能力选择上游节点， 请求所述选择的上游节点重发丢 失的数据， 所述第二上游节点为所述下游节点的上游节点。
3、 如权利要求 1所述的提高组播可靠性的方法， 其特征在于， 所述更新所述重传窗口 通知消息， 包括：
当所述中间节点的重传窗口大小能覆盖所述第一上游节点的重传窗口大小时， 取所述 中间节点的重传窗口大小作为更新的重传窗口大小， 取所述中间节点重传窗口大小和所述 第一上游节点重传窗口大小的交集， 在所述重传窗口通知消息中标识为所述中间节点和所 述第一上游节点的重传窗口大小， 取所述中间节点独有的重传窗口大小， 在所述重传窗口 通知消息中标识为所述中间节点独有的重传窗口大小； 或
当所述第一上游节点的重传窗口大小能覆盖所述中间节点的重传窗口大小时， 取所述 第一上游节点的重传窗口大小作为更新的重传窗口大小， 取所述中间节点重传窗口大小和 所述第一上游节点重传窗口大小的交集， 在所述重传窗口通知消息中标识为所述中间节点 和所述第一上游节点的重传窗口大小， 取所述第一上游节点独有的重传窗口大小， 在所述 重传窗口通知消息中标识为所述第一上游节点独有的重传窗口大小； 或
当所述第一上游节点的重传窗口大小和所述中间节点的重传窗口大小不能相互覆盖 时， 取所述第一上游节点和所述中间节点的重传窗口大小的并集作为更新的重传窗口大小， 取所述中间节点重传窗口大小和所述第一上游节点重传窗口大小的交集， 在所述重传窗口 通知消息中标识为所述中间节点和所述第一上游节点的重传窗口大小， 取所述中间节点独 有的重传窗口大小， 在所述重传窗口通知消息中标识为所述中间节点独有的重传窗口大小， 取所述第一上游节点独有的重传窗口大小， 在所述重传窗口通知消息中标识为所述第一上 游节点独有的重传窗口大小。
4、 一种提高组播可靠性的系统， 其特征在于， 所述系统包括：
接收模块， 用于接收第一上游节点发送的重传窗口通知消息；
更新模块， 用于更新所述重传窗口通知消息， 并将所述更新后的重传窗口通知消息发 送给下游节点， 所述第一上游节点为所述中间节点的上游节点。
5、 如权利要求 4所述的提高组播可靠性的系统， 其特征在于， 所述系统还包括： 记录模块， 用于接收所述更新的重传窗口通知消息， 记录重传窗口大小；
选择模块， 用于当所述下游节点检测到数据丢失时， 根据接收的所述更新的重传窗口 通知消息、 所述下游节点到第二上游节点的距离和 /或第二上游节点的服务能力选择上游节 点， 并要求所述选择的上游节点重发丢失的数据， 所述第二上游节点为所述下游节点的上 游节点。
6、 如权利要求 4所述的提高组播可靠性的系统， 其特征在于， 所述更新模块包括： 第一更新单元， 用于当所述中间节点的重传窗口大小能覆盖所述第一上游节点的重传 窗口大小时， 取所述中间节点的重传窗口大小作为更新的重传窗口大小， 取所述中间节点 重传窗口大小和所述第一上游节点重传窗口大小的交集， 在所述重传窗口通知消息中标识 为所述中间节点和所述第一上游节点的重传窗口大小， 取所述中间节点独有的重传窗口大 小， 在所述重传窗口通知消息中标识为所述中间节点独有的重传窗口大小； 或
第二更新单元， 用于当所述第一上游节点的重传窗口大小能覆盖所述中间节点的重传 窗口大小时， 取所述第一上游节点的重传窗口大小作为更新的重传窗口大小， 取所述中间 节点重传窗口大小和所述第一上游节点重传窗口大小的交集， 在所述重传窗口通知消息中 标识为所述中间节点和所述第一上游节点的重传窗口大小， 取所述第一上游节点独有的重 传窗口大小， 在所述重传窗口通知消息中标识为所述第一上游节点独有的重传窗口大小； 或
第三更新单元， 用于当所述第一上游节点的重传窗口大小和所述中间节点的重传窗口 大小不能相互覆盖时， 取所述第一上游节点和所述中间节点重传窗口大小的并集作为更新 的重传窗口大小， 取所述中间节点重传窗口大小和所述第一上游节点重传窗口大小的交集， 在所述重传窗口通知消息中标识为所述中间节点和所述第一上游节点的重传窗口大小， 取 所述中间节点独有的重传窗口大小， 在所述重传窗口通知消息中标识为所述中间节点独有 的重传窗口大小， 取所述第一上游节点独有的重传窗口大小， 在所述重传窗口通知消息中 标识为所述第一上游节点独有的重传窗口大小。
7、 如权利要求 5 所述的提高组播可靠性的系统， 其特征在于， 所述接收模块和所述 更新模块集成在中间节点上；
所述记录模块和所述选择模块集成在所述中间节点的下游节点上。
8、 一种组播网络， 其特征在于， 所述组播网络包括：
第一上游节点， 用于向中间节点发送重传窗口通知消息；
所述中间节点， 用于接收所述重传窗口通知消息， 更新所述重传窗口通知消息， 并将 所述更新后的重传窗口通知消息发送给下游节点；
其中， 所述第一上游节点为所述中间节点的上游节点。
9、 如权利要求 8所述的组播网络， 其特征在于， 还包括所述下游节点， 所述下游节点 用于接收所述更新后的重传窗口通知消息， 记录重传窗口大小， 当所述下游节点检测到数 据丢失时， 根据所述更新后的重传窗口通知消息、 所述下游节点到第二上游节点的距离和 / 或第二上游节点的服务能力选择上游节点， 请求所述选择的上游节点重发丢失的数据， 所 述第二上游节点为所述下游节点的上游节点。
PCT/CN2009/070128 2008-02-04 2009-01-13 提高组播可靠性的方法、系统和组播网络 WO2009097767A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200810009198.4 2008-02-04
CNA2008100091984A CN101505211A (zh) 2008-02-04 2008-02-04 一种提高组播可靠性的方法、系统和组播网络

Publications (1)

Publication Number Publication Date
WO2009097767A1 true WO2009097767A1 (zh) 2009-08-13

Family

ID=40951775

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2009/070128 WO2009097767A1 (zh) 2008-02-04 2009-01-13 提高组播可靠性的方法、系统和组播网络

Country Status (2)

Country Link
CN (1) CN101505211A (zh)
WO (1) WO2009097767A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112152820B (zh) * 2019-12-09 2021-07-20 北京天德科技有限公司 一种多播tcp的架构方法及多播tcp系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1541466A (zh) * 2001-06-30 2004-10-27 ��˹��ŵ�� 用于在多跳无线网络中传递分组的设备和方法
CN1695355A (zh) * 2002-10-28 2005-11-09 思科技术公司 Rpf多方可靠传输
JP2007208635A (ja) * 2006-02-01 2007-08-16 Matsushita Electric Ind Co Ltd ノード、パケット通信方法、及びパケット通信システム
CN101102174A (zh) * 2006-07-04 2008-01-09 株式会社Ntt都科摩 混合自动请求重传方法、及采用其的中继设备和通信系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1541466A (zh) * 2001-06-30 2004-10-27 ��˹��ŵ�� 用于在多跳无线网络中传递分组的设备和方法
CN1695355A (zh) * 2002-10-28 2005-11-09 思科技术公司 Rpf多方可靠传输
JP2007208635A (ja) * 2006-02-01 2007-08-16 Matsushita Electric Ind Co Ltd ノード、パケット通信方法、及びパケット通信システム
CN101102174A (zh) * 2006-07-04 2008-01-09 株式会社Ntt都科摩 混合自动请求重传方法、及采用其的中继设备和通信系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Network Working Group, Request for Comments", vol. 3940, November 2004, article ADAMSON, B ET AL.: "Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol" *

Also Published As

Publication number Publication date
CN101505211A (zh) 2009-08-12

Similar Documents

Publication Publication Date Title
US7542438B2 (en) Reliable multicast data retransmission method by grouping wireless terminals in wireless communication medium and apparatus for the same
US6807578B2 (en) Nack suppression for multicast protocols in mostly one-way networks
KR101571145B1 (ko) 무선 근거리 네트워크들에서의 신뢰 가능한 멀티캐스트를 위해 병합된 자동 반복 요청으로 적응 순방향 에러 정정을 하기 위한 방법 및 장치
KR101644215B1 (ko) 신뢰성 있는 데이터 통신을 위한 네트워크 추상화 계층을 파싱하는 방법 및 장치
KR100904072B1 (ko) 데이터 패킷들의 신뢰성 있는 멀티캐스트 전송을 위한 장치, 시스템, 방법 및 컴퓨터로 읽을 수 있는 매체
KR100831654B1 (ko) 멀티캐스트 및 브로드캐스트 전송을 관리할 수 있는시스템에서 데이터 복구 방법
US8423855B2 (en) Adaptive and scalable packer error correction apparatus and method
WO2011079822A1 (zh) 保障网络电视直播业务的业务服务质量的方法和设备
WO2009088913A1 (en) Improved multimedia wireless distribution systems and methods
WO2010048825A1 (zh) 丢包抑制重传的方法、网络节点和系统
US20060224745A1 (en) Error recovery mechanism and network element comprising same
WO2015027429A1 (zh) 聚合传输的方法、装置和系统以及网络服务器和用户设备
CN100531152C (zh) 无线局域网传输组播帧的设备、系统及实现方法
KR100240645B1 (ko) 멀티캐스트 통신의 패킷 오류 제어기 및 이를 이용한패킷 오류제어 방법
EP2445162B1 (en) Method For Adaptive Streaming
CN110602568B (zh) 一种基于rtp的视频流传输丢包重传方法、设备及存储设备
US8526432B2 (en) Packet processing system for a network packet forwarding device and method thereof
US20050094632A1 (en) DOCSIS MAC layer-based ARQ for fixed wireless
WO2009097767A1 (zh) 提高组播可靠性的方法、系统和组播网络
JP3378429B2 (ja) 同報通信制御装置
CN1937519A (zh) 一种无线局域网ip组播传输异常的快速检测方法
JP2017092581A (ja) ゲートウェイ装置、放送受信装置、放送中継方法、放送受信方法、放送中継プログラムおよび放送受信プログラム
Li et al. Network‐coding‐based cache policy for loss recovery enhancement in reliable multicast
JP3516395B2 (ja) 応答モード可変データ配信方法及びその実施装置並びにその処理プログラムと記録媒体
Somchit et al. A proposal for a multicast protocol for live media

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: 09709172

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09709172

Country of ref document: EP

Kind code of ref document: A1