This application claims the benefit of Korean Patent Application No. 10-2007-0023673, filed on Mar. 9, 2007, in the Korean Intellectual Property Office, the disclosure of which is incorporated herein in its entirety by reference.
1. Field of the Invention
The present invention relates to internet protocol (IP) multicast, and more particularly, to an apparatus and method for compensating for a loss of data packets transmitted using IP multicast.
2. Description of the Related Art
Data packets can be sent through the Internet from a server computer (hereinafter referred to as “server”) to a client computer (hereinafter referred to as “client”) by various routing methods, including anycast, broadcast, multicast, and unicast.
As internet protocol (IP) televisions (TVs) or internet TVs have recently been developed, multicast has been used more extensively.
Multicast is a technique which allows the same data packet to be simultaneously transmitted from one source (or one server) to a plurality of clients which subscribe to a multicast group.
An example of the various multicast techniques is IP multicast, based on an IP infrastructure. According to IP multicast, clients that desire to receive multimedia content from a server form one multicast group, and share the same multicast address (or the same IP destination address). The server transmits a data packet that contains the destination address only once, via the Internet. Thereafter, routers in a network duplicate the data packet and transmit it to the clients which subscribe to the multicast group.
IP multicast allows a large amount of multimedia content to be simultaneously transmitted to a plurality of clients, and thus can prevent an information traffic jam that occurs frequently if unicast is used.
However, a client cannot reproduce a received image or audio data for a while if some data packets transmitted from an IP multicast server are lost or damaged owing to the bad conditions of a network or the temporary overload of a terminal, and particularly, if the lost or damaged packets are important or contain header information necessary to reproduce audio/video (AIV) data.
In order to solve this problem, Pragmatic General Multicast (PGM) has been conventionally used. According to PGM, a client accesses a server by unicast in order to request retransmission of the lost or damaged data packets. However, if the transmission rate of a transmission channel is high, retransmission of the lost or damaged data packet may be difficult, and retransmission of the lost or damaged data packet may interrupt the transmission of other packets by the server.
The present invention provides a method and apparatus for compensating for a lost or damaged data packet of a client without interrupting a data transmission of a server.
According to an aspect of the present invention, a client is provided comprising a packet monitoring block which monitors whether data packets transmitted from a server which provides multimedia content are lost; and a compensation request processing block which transmits a request for lost data packets to other clients if the packet monitoring block detects lost data packets, and processes a compensation request for compensation of lost packets if the compensation request is received from at least one of the other clients.
According to another aspect of the present invention, there a system is provided to compensate for data packet loss, the system comprising a server which provides multimedia content; two or more clients forming a multicast group; and a network which electronically connects the server and the clients, wherein if one of the clients loses data packets transmitted from the server, the lost data packets are compensated for from the other clients.
According to another aspect of the present invention, a method is provided to compensate for lost data packets, the method comprising receiving, in a client, data packets; determining in the client whether compensation for data packets is needed; if compensation for data packets is needed, sending, from the client to the other clients, a request to compensate for data packet; and receiving in the client one or more data packets that are to be compensated for from the other clients, and performing packet rearrangement.
According to another aspect of the present invention, a method is provided to a request for compensation for a data packet, the method comprising determining in a first client whether a request for data packet compensation is received from a second client; and if the request is received, transmitting a lost data packet from the first client to the second client in a manner such that transmission by the first client does not collide with transmission by a third client which has also received the request from the second client.
According to another aspect of the present invention, d a multicast data packet is provided comprising a header section, and a data section, wherein the header section comprises continuity information and packet importance information.
The above and other features and advantages of the present invention will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings in which:
The present invention will now be described more fully with reference to the accompanying drawings, in which exemplary embodiments of the invention are shown.
In order to receive data packets from the server 11, the clients 13 through 15 subscribe to two multicast groups: one multicast group that allows them to receive data packets from the server 11, and the other multicast group that allows compensation for lost or damaged (hereinafter referred to as “lost”) data packets. In general, members of the latter multicast group are the same as those of the former multicast group, and internet protocol (IP) addresses, are allocated to both multicast groups. These IP addresses may be similar, e.g. 224.0.0.1 and 224.0.0.2, but are not necessarily limited to being similar or to having any particular relationship or particular values.
An example of a network through which the server 11 and the clients 13 through 15 are connected is an IP-based internet.
The header section 21 contains continuity information 211 and packet importance information 212. If the header section 21 is a routing table protocol (RTP) header, the RTP header is 12 bytes long, and the continuity information 211 and the packet importance information 212 are inserted into blank bytes of the 12 bytes.
The continuity information 211 indicates a sequence of numbers, e.g., 1-2-3 . . . -N-1-2 . . . , which are respectively given to a sequence of data packets, the sequence of numbers being repeated in a predetermined cycle N. The packet importance information 212 indicates whether a packet must be compensated for if it is lost or damaged. For example, the packet type may be used as the packet importance information 212. Thus, if a lost packet contains a header for reproducing A/V data and other important data, the system must compensate for that packet if lost. In this case, the packet importance information 212 may indicate the types of the current packet and a subsequent packet (or a previous packet).
The data section 22 includes header data and/or A/V data. The header data is needed to reproduce the A/V data.
(c) of
The first client 13 includes a first main block 131, a first packet monitoring block 132, a first compensation request processing block 133, and a first transmitting/receiving block 134. The second client 14 includes a second main block 141, a second packet monitoring block 142, a second compensation request processing block 143, and a second transmitting/receiving block 144. The third client 15 includes a third main block 151, a third packet monitoring block 152, a third compensation request processing block 153, and a third transmitting/receiving block 143.
Each of the main blocks 131, 141, and 151 finds out the attributes of a packet received from a server (not shown) or from the other clients. That is, the main block determines whether the packet received via the transmitting/receiving block is a data packet, a packet requesting flag clearance, or a packet requesting packet compensation.
Each of the packet monitoring blocks 132, 142, and 152 monitors a sequence of data packets received from the server. The packet monitoring block determines whether packet loss occurs, based on continuity information contained in the header section of each of the data packets. If it is determined that one of the data packets has been lost, the packet monitoring block checks the packet importance information contained in a packet preceding or following the lost packet, to determine whether compensation for the lost packet is needed, depending on whether the lost packet contains important data, such as header data.
The functions performed by each of the compensation request processing blocks 133, 143, and 153 varies depending on whether the client that includes the compensation request processing block loses a packet.
The compensation request processing block of a client that has lost a packet transmits a request for compensation for the lost data packet to the other clients belonging to the same multicast group via the transmitting/receiving block.
The compensation request processing blocks of the other clients transmit the data packet to the client that lost the data packet, via the transmitting/receiving block, in a manner that does not cause transmission collision, in response to the request for the packet compensation.
Although not shown, each of the first through third clients 13 through 15 includes a buffer (or a packet pool) that stores received data packets, a storage unit (ROM, RAM, etc.), and a compensation flag.
In operation 41, two or more clients subscribe to a multicast group. Two or more clients that desire to receive data packets (or multimedia content) from a server form a multicast group. The same multicast address is given to the clients.
In operation 42, the clients receive data packets from the server. The server transmits data packets each containing a specific multicast address, continuity information, and packet importance information via a network. Then, the clients subscribing to the multicast group in operation 41 receive the data packets. At the same time, each of the clients buffers a predetermined quantity of the data packets so that they can later reproduce the received data. The quantity of data packets that are to be buffered is determined by the transmission speed of a transmission channel, the capacity of the buffer, and so on.
In operation 43, each of the clients determines whether data packet compensation is needed. First, it is determined whether the data packets are continuous packets by checking the continuity information contained in the header of each of the data packets that the clients receive.
For convenience of explanation, it is assumed some data packets sent to the first client 13 illustrated in
When one or more of the data packets transmitted to the first client 13, e.g., the third packet illustrated in
In operation 44, a compensation request packet (hereinafter referred to as a “compensation request”) is transmitted in order to compensate for the lost data packet. The first client 13 transmits the compensation request to the other clients 14 and 15 belonging to the same multicast group. The compensation request contains the continuity number, which is given to the lost data packet of the first client 13.
In operation 45, the compensation request is processed. The second and third clients 14 and 15 that receive the compensation request from the first client 13 transmit the lost data packet to the first client 13 in a manner that does not cause transmission collision. Operation 45 will be described later in greater detail with reference to
In operation 46, the sequence of the packets is rearranged. The first client 13 receives the data packet from the client 14 or 15, and inserts it between the other buffered data packets (packet pool), based on the continuity number given to the data packet.
Then, the compensation for the lost data packet is completed.
As in
In operation 51, the other clients 14 and 15 observe a transmission channel in order to determine whether a compensation request is received from the first client 13. Each of the clients 13 through 15 stores data packets of a cycle N in a storage unit (not shown). The storage unit may be RAM or ROM, and stores data packets in preparation for compensation of a lost data packet.
In operation 52, if it is determined that a compensation request is received from the first client 13, each of the second and third clients 14 and 15 sets its compensation flag. However, if a compensation request is not received, each of the clients 14 and 15 processes received packets and continuously observes the transmission channel (operation 51).
In operation 53, the clients 14 and 15 stand by for an arbitrary period of time. Each of the clients 14 and 15 receiving the compensation request waits for an arbitrary period of time before transmitting a packet requested by the first client 13, in order to prevent collision of the packet transmissions by the clients 14 and 15. To avoid the collision, each of the clients 14 and 15 generates a random number, and waits for a period of time corresponding to the generated number. In this example, it is assumed that the waiting period of the second client 14 is shorter than that of the third client 15.
In operation 54, each of the clients 14 and 15 determines whether a request to clear the compensation flag is received from the other client.
Since the waiting time of the second client 14 is shorter than that of the third client 15, the second client 14 does not receive a request to clear the compensation flag from the third client 15.
In operation 55, the second client 14 sends a request to the third client 15 to clear its flag. In operation 56, the second client 14 then reads from its storage unit a packet that is identical to the lost packet of the first client 13, and transmits that packet to the first client 13.
On the other hand, since the waiting time of the third client 15 is longer than that of the second client 14, the third client 15 receives a request to clear its flag from the second client 14. In operation 57, the third client 15 clears the flag set in operation 52.
The present invention can be embodied as computer readable code in a computer readable medium. Here, the computer readable medium may be any recording apparatus capable of storing data that is read by a computer system, e.g. a read-only memory (ROM), a random access memory (RAM), a compact disc (CD)-ROM, a magnetic tape, a floppy disk, an optical data storage device, and so on. The computer readable medium can be distributed among computer systems that are interconnected through a network, and the present invention may be stored and implemented as computer readable code in the distributed system.
According to the present invention, even if a client loses a data packet, the data packet can be compensated for, thus preventing reproduction of A/V data from being interrupted due to the loss of the data packet.
Also, since the other clients, instead of the server, compensate for the lost packet, it is possible to solve the problem of conventional methods, in which data transmission of a server is interrupted.
While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it will be understood by those of ordinary skill in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the present invention as defined by the following claims.
Number | Date | Country | Kind |
---|---|---|---|
10-2007-0023673 | Mar 2007 | KR | national |