The present invention is directed generally to an apparatus, system, method and computer program product for reliable multicast transport of data packets.
For one-to-many services over systems such as IP multicast, file delivery is an important service. Many of the features for delivering files over point-to-point protocols such as file transfer protocol (FTP) and hypertext transfer protocol (HTTP) are problematic for one-to-many scenarios. In particular, the reliable delivery of files using similar one-to-one acknowledgement (ACK) protocols such as transmission control protocol (TCP) is not feasible.
The Working Group of the Internet Engineering Task Force (IETF) (c/o Corporation for National Research Initiatives, Reston, Va., www.ieft.org) is in the process of standardizing two categories of error-resilient multicast transport protocols. In the first category, reliability is implemented through the use of a proactive forward error correction (FEC). In the second category, the protocol uses receiver feedback for reliable multicast transport. Asynchronous Layered Coding (ALC) is a protocol instantiation belonging to the first category, while the NACK-Oriented Reliable Multicast (NORM) protocol is used in the second category. The details of ALC and NORM protocols are discussed in more detail in papers entitled “NACK-oriented Reliable Multicast Protocol” and “Asynchronous Layered Coding (ALC) protocol Instantiation” prepared by the Working Group of the IETF and available at www.ietf.org. The contents of these papers are fully incorporated herein by reference.
Briefly, ALC protocol is a proactive FEC based scheme that allows receivers to reconstruct mangled packets or packets that have not been received. ALC protocol uses FEC encoding on multiple channels, allowing the sender to send data at multiple rates (channels) to possibly heterogeneous receivers. Additionally, ALC protocol uses a congestion control mechanism to maintain different rates on different channels.
ALC protocol is massively scalable in terms of the number of users because no uplink signalling is required. Therefore, any amount of additional receivers does not put increased demand on the system. However, ALC protocol is not 100% reliable because reception is not guaranteed. Accordingly, the repetition of the transmission is necessary. In the best case, the number of retransmissions and any time gap between transmissions is a balance between available bandwidth and the number of users likely to receive 100% of the data. ALC protocol is clearly targeted to multicast delivery over simplex (one-way) links to massive groups with no uplink signalling.
NORM also incorporates the use of FEC on a per-packet basis for repair of damaged packets or packets that have not been received. However, these packets are sent by the sender in response to NACKs received from receivers. The sender employs FEC encoding for the retransmission of packets requested by a receiver. Receivers employ negative acknowledgement (NACK) messages to indicate loss or damage of transmitted packets to the sender. Accordingly, a receiver that “missed” some data blocks from a data transmission can signal the sender using a NACK. NORM protocol also optionally allows for the use of packet-level FEC encoding for proactive robust transmissions.
On a wireless link, however, errors in transmission tend to occur in bursts and thus affect a larger number of blocks and a larger number of receivers at the same time. This could result in a “NACK-implosion,” e.g. a sudden massive number of receivers signalling the sender at the same time by using, for example, either the NACK or the following block retransmission or both. NORM protocol is clearly targeted at multicast delivery over duplex (two-way) links to small and medium sized groups requiring uplink signalling.
The access networks on which these protocols can be used include wireless multiple-access networks such as a universal mobile telecommunications system (UMTS), a wireless local area network (WLAN), a digital video broadcasting-terrestrial (DVB-T) and a digital video broadcasting-satellite (DVB-S).
Both ALC and NORM protocols offer benefits for the multicast transport of data. However, they are targeted at distinct applications: 1) unidirectional (e.g. broadcast DVB-T); and 2) bi-directional (e.g. multicast WLAN) systems. Additionally, a survey of available literature on the topic does not reveal any attempt to combine the above-mentioned features of ALC and NORM protocols.
Accordingly, it would be very useful to enable multicast delivery of data with the massively scalable user groups features of ALC protocol and the 100% rapid reliability of NORM protocol, where an uplink is available to some or all users.
To overcome limitations in the prior art described above, and to overcome other limitations that will be apparent upon reading and understanding the present application, an apparatus, system, method and computer program product for reliable multicast transport of data packets are proposed.
The present invention is directed to combining the desirable features of ALC and NORM protocols by allowing a sending device to use multiple data rates on different channels to send data packets and receiving devices to use NACKs to request retransmission of missing or mangling data from the sending device or other receiving devices.
The apparatus and system of the present invention include at least one sending device for transmitting data to at least one receiving device. After receiving the data, the receiving device determines if there is missing or mangled data transmitted from the sending device and sends an acknowledgement or transmission regarding the missing or mangled data to the sending device or to another receiving device.
The apparatus includes at least one processor for determining missing or mangled data in a data transmission, and a NACK and retransmission mechanism. The NACK and retransmission mechanism allows from the transmission of NACKs as well as the transmission of data to the sending device or other receiving devices in the network. The receiving device can be a personal communication device, GPRS, WLAN, DVB of other similar wireless device. The sending device can be a server, IP-based device, GPRS, DVB, or other similar device.
Data is transmitted from said sending device to one or more receiving devices using an active ALC mechanism. By way of example, it is contemplated that the sending device defines unidirectional transmission block identifiers and corresponding objects before transmitting data to the receiving device. The sending device transmits data using a unidirectional protocol. The receiving device then transmits an acknowledgement using a bi-directional or uplink simplex protocol using the same transmission block identifier as the unidirectional protocol.
It is also contemplated by the invention that the system of the present invention includes at least one network for establishing communication between the receiving device and the sending device. The sending device and the receiving device can be located in the same network or in different networks. The networks may include wireless multiple-access networks such as UMTS, WLAN, DVB-T and DVB-S, or a cellular network.
The method of the present invention includes transmitting data packets from at least one sending device via a network to at least one receiving device. The receiving device determines if there is any missing or mangled data. The receiving device then sends an acknowledgement or transmission of missing or mangled data to the sending device or to another receiving device. The sending device or another receiving device retransmits the missing or mangled data to the requesting device to complete the data transmission session.
The acknowledgment or retransmission of missing or mangled data can be multicast or unicast messages. Moreover, a single acknowledgement can contain a plurality of negative acknowledgements messages regarding missing or mangled data, or a positive acknowledgement indicating that the missing or mangled data has been received correctly. Acknowledgements can be transmitted by a sending device or receiving device to the network.
The missing or mangled data can be retransmitted from the sending device or from another receiving device that possesses the missing or mangled data from the original data transmission. It is also contemplated that the retransmission of missing or mangled data can be prioritized based on the acknowledgement received, the number of data transmissions missed, the location of missed or mangled data or the like. For example, retransmitting of the missing or mangled data can be done by retransmitting the original data transmission, retransmitting only the missing data of the original data transmission, or repositioning the missing or mangled data in the data transmission. The retransmission can be sent on different channels and at different data rates.
The computer program product of the present invention includes a computer readable medium for storing computer program code. The program code includes code for transmitting a data packet from at least one sending device to at least one receiving device and determining if there is missing or mangled data transmitted from the sending device. The program code also includes code for sending an acknowledgement or transmission of missing or mangled data to the sending device or to another receiving device as well as program code for retransmission of the missing or mangled data to a receiving device to complete the data transmission session.
The accompanying figures show one context for illustrating the details of an apparatus, system, method and computer program product for reliable multicast transport of data packets in accordance with the present invention. However, it is contemplated that other contexts could be used for illustration without departing from the spirit and scope of the invention presented herein. Like reference numbers and designations in these figures refer to like elements.
In the following description of the various embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration various embodiments in which the invention may be practiced.
The ALC mechanism requires LCT, FEC, layered congestion control and security building blocks (not shown). Information in ALC is carried in a session that is characterized by a set of groups/port numbers. Data is transferred as objects. For instance, a file, a JPEG image, a file slice are all objects. A single session may include the transmission of a single object or multiple objects. By way of example, each session is uniquely identified by the IP address of the sender and the transmission session identifier (TSI). Further, the transmission object identifier (TOI) is used to indicate the object to which the packet being transmitted in a particular session pertains. For instance, a sender 1 might send a number of files in the same session using a TOI of 0 for the first file, 1 for the second and so on. On the other hand, the TOI may be a unique global identifier that is being transmitted from several senders 1 concurrently.
The FEC building block provides reliable object delivery within an ALC session. Each object sent in the session is independently encoded using FEC codes. Each source block is represented by a set of encoding symbols. Each packet in an ALC session contains the FEC payload ID that uniquely identifies the encoding symbols that constitute the payload of each packet, and the receiver 5 uses it to determine how the encoding symbols carried in the payload of the packet were generated from the object. When no FEC encoding is used, the block identifier is the triplet of the TOI, the source block number and the encoding symbol ID. The TOI includes the FEC encoding ID 0, the length in bytes of the encoding symbol carried in the packet payload for each source block and the length of the source block in bytes. It is transmitted “out-of-band.” The source block number and the encoding symbol ID together form the FEC payload ID.
In
As seen in
When sending a NACK, the receivers 5 can use either a unicast or a multicast message. For example, if the receiver 5 has a unicast link to the sender 1, it sends a unicast NACK. If the receiver 5 does not have a unicast link to the sender 1, it sends a multicast NACK to receivers 5 in the multicast group. On the other hand, if the receiver 5 is part of an ad hoc network, it sends a link-local broadcast to other receivers 5 within the ad hoc network. In this case, the sender 1 can also receive the multicast NACK. Additionally, it is possible that the sender 1 is part of the multicast group to which the receiver 5 sends the NACK.
Similarly, in
The sender operation when using ALC includes all the requirements laid down by the LCT, FEC and multiple rate congestion control feature. A sender using ALC is required to make available the session description as well as the FEC object transmission information “out-of-band” to the receivers. The following is an example:
FEC object transmission information (OTI) includes one or more of the following: 1) FEC instance identification; 2) source block length; 3) encoding symbol length; 4) maximum number of data symbols per block; and 5) maximum number of encoding symbols.
Within a session a sender transmits a sequence of packets to the channels associated with the session at the appropriate rates as defined by the multiple rate congestion control and building block features. The same TSI is used for all the objects in a session and if more than one object is to be transmitted during the session, then the sender with a unique TOI indicates each object.
A transmission is considered complete if one of several conditions are satisfied: 1) a certain time has expired; 2) a certain number of packets has been sent; or 3) some out-of-band signal, such as a higher level protocol, has indicated completion by a sufficient number of receivers 5. Typically, a receiver 5 joins a certain channel based on information received “out-of-band”. This means that the receiver 5 knows that it should join a particular channel according to its capability based on, for example, SAP messages.
By way of example, missing or mangled blocks can be determined by identifying blocks with some kind of “label,” such as explicit or implicit. Explicit requires defining a new identifier, where as implicit means that the label can be derived from other information (e.g. the TOI, source block identifier and FEC block identifier—as in file delivery over unidirectional transport (FLUTE) protocol.).
Detecting a missing block is easy for linear transmissions as blocks can be labelled and are expected in order. When a block arrives out of order, it may have been lost. It may also be desirable to set an additional timer so that networks known to reorder packets (as with many IP-routed networks) may still deliver packets (and perhaps blocks) very slightly out of order, but lost packets are still detected.
Detecting missed blocks is also readily feasible for other structured transmissions. Examples include “last block first and all blocks in reverse order”, or “every 10th block shifted by one each of ten times.” This is due to the fact that the transmission order is predictable and can be communicated to the receiver 5 in advance, or the receiver 5 can “learn” the order intelligently as the transmission progresses.
The following methods can be used for random or near-random missing block detection (and also the structured cases). A time out based on the expected duration of the whole transmission can be used, or possibly a link-list kind of system (each block identifies the next one or more). It is also possible to signal the end of a transmission explicitly (a null or message block or message explicitly, or finding an already received block implicitly or a combination of these).
Also for the random transmission, it is possible to make it near random by taking the whole transmission and segmenting it so at the end of the segment (instead of the whole transmission) you could do one of the previous “detections.” This is “naturally occurring” for file transfers if a series of files are transmitted one after the other in a single transmission and the FEC blocks are randomised only per file.
The following are other examples of determining missing data blocks also contemplated by the invention:
In
With this in mind, in step S10 a mobile terminal 5 responds to the NACK by transmitting data to the server 1 in a unicast message. In step S11, the server 1 then retransmits the missing data back to the other mobile terminals 5 in the network 20. In this case, the server 1 received the missing blocks as a member of the multicast group to which the missing blocks were sent. The NACK from the mobile terminal 5 that did not receive the original transmission was a unicast NACK to the server 1. After receiving the NACK, the server 1 polled the other terminals 5 because it did not have the data itself or for other reasons, such as proximity or aggregation.
Limiting the scope of retransmission can be useful and is also contemplated by the invention. The limitation of retransmission can be based on certain factors, such as proximity. On the other hand, within a multicast group, only one device (i.e., server or terminal) may be designated to retransmit data. Moreover, the retransmissions from the mobile terminals 5 may be limited by the server 1 multicasting an “OK” message after it has received the missing blocks or by the mobile terminal 5 itself by multicasting the missing blocks to all the other mobile terminals 5 in the network 20 or group.
Contrary to the above approaches, in
An expanding ring search works on a proximity basis. First, to the terminals that are within link-local broadcast range (TTL=1). Then if there is no reply, the TTL=2 and the message is forwarded to terminals 5 further away. The TTL value may also be incremented in steps other than value 1. Hence, the number is limited by the number of other terminals 5 present within the given number of hops by the number of hops to the terminal 5. E.g. within 1 hop is within 1 hop proximity, within 2 hops is within 2 hop proximity etc. This is a well-known parameter in ad hoc networks, with several algorithms available to determine this for various radio technologies (e.g. for WLAN).
In
Although illustrative embodiments have been described herein in detail, it should be noted and understood that the descriptions and drawings have been provided for purposes of illustration only and that other variations both in form and detail can be added thereupon without departing from the spirit and scope of the invention. The terms and expressions have been used as terms of description and not terms of limitation. There is no limitation to use the terms or expressions to exclude any equivalents of features shown and described or portions thereof.