Like any application used for receiving multicast, the multicast client can listen to multicast transmission in real time. However, the number of packets that are lost from a multicast stream can be too large to be corrected by for-ward error correction if a terminal cannot listen to the multicast transmission all the time. One typical situation is when a mobile terminal temporarily moves into an area without wireless network coverage which is good enough to be used for receiving the stream. The client-cache protocol is used for re-questing the lost packets after the terminal returns within network coverage.
The lost packets are retransmitted from a multicast cache. Essentially, the protocol can be used to compensate an unreliable link by using retransmis-sions.
Cache selection
A multicast cache periodically sends Cache Announcement messages over the network interfaces which are used to send multicast data to terminals.
The goal of the Cache Announcement messages is to inform the terminals of the presence of a multicast cache which is willing to send retransmissions.
One multicast cache can sent announcements over several interfaces, with possibly different network technologies, simultaneously.
The announcement messages are sent to a multicast address which is lis-tened to by all multicast clients. Each Cache Announcement message con-tains at least the following information.
1. The contact address. The contact address is used by the multicast client as the destination address in the requests sent to this multicast cache.
2. A cookie value, which is a random number. The cookie value changes in every announcement message which is sent. When the client sends a request to the cache, it includes the most recent cookie value into the request. The value is used to ensure that only clients that are able to listen to the announcement messages can send acceptable requests to the multicast cache.
The cache announcement message can also include other information, such as the identity of the owner of the cache, a timestamp and pricing infor-mation. The announcement messages can also be signed using the multicast caches signature key, if such a key has been assigned to the cache. However, these extensions are outside the scope of this dissertation.
Based on the above specified information, the multicast client selects one or more of the simultaneously available multicast caches as the caches which will be used to request retransmissions. The client software can use variables such as available network capacity and pricing to select the multicast cache if several caches are simultaneously available.
Retransmission requests
Retransmission requests are sent by a multicast client when it detects that it has not received one or more packets that it needs to reconstruct the original content from the received packets.
The client software maintains a database of packets it has already received from each multicast stream. Every time the client software receives a packet from a multicast stream, it verifies whether or not it has received enough packets from every FEC block that has already been sent by the server. If the multicast client detects that it has not received a sufficient number of packets from each sent FEC block, it can send a retransmission request to one of its currently available multicast caches. Typically, the client software requests the packets that are needed most urgently. That is, the client attempts to reconstruct the incomplete FEC block with the smallest sequence number first.
The sequence numbers of the packets missing from the client software are carried in the request message to the multicast cache. The message body consists of pair of numbers. The first number of the pair gives the sequence number of the first packet. The second number of the pair gives the number of packets missing after the sequence number given in the first number of the pair. The request message also carries the source and destination addresses of the stream from which packets are begin requested. The most recently received cookie value is also included in the packet.
Dest addr, Source addr, cookie value,nseq. start, num. packetso
| {z }
Possibly repeated part
An example of a request message is given below:
FF1E::1234, 3FFE::1, 0x1A6F8BB2, 102, 5, 115, 4
In the example above, the client software requests packets in the sequence number range of 102-106 and 115-118 to be retransmitted.
Retransmissions
The retransmission requests are sent to one of the available multicast caches.
After receiving a request, a multicast cache first verifies that the cookie value received in the packet matches one of the cookies that have been transmitted by this cache within the last few seconds.
Next, the packet is compared with request messages received from other hosts. If multiple requests for the same packets are received from separate nodes, the requests for duplicate packets are removed from the request. Since terminals that are sending requests do not know what requests have been sent by other nodes, this comparison is needed to prevent multiple retransmis-sions of the same packet within a short period of time. Then the request is entered into the retransmission queue to wait for an opportunity to be sent.
When the radio interface is available for sending retransmission packets, a retransmission request is taken from the queue. Next, the multicast cache needs to decide which packet to retransmit in response to the request. Natu-rally, the retransmitted packet needs to be from the multicast stream identi-fied by the request. However, due to the use of FEC, the sequence number of the retransmitted packet does not need to match exactly to the requested sequence number. Any packet with the following properties are suitable to be retransmitted.
1. The transmitted packet is from the same FEC block as the requested packet.
2. The client has not already received the packet from this stream with this sequence number.
That is, any packet, from the correct FEC block, unreceived by the client is suitable for replacing a lost packet. However, it is usually impossible for the multicast caches to know which exact packets have already been received by the clients. This makes the second property of the above list difficult to
utilize. The most simple strategy is to send exactly the packet which was requested in the message. This method is suitable for the situation where only one terminal is requesting packets from this FEC block to be sent.
Another strategy may be more appropriate when sending retransmissions from one multicast stream simultaneously to multiple terminals. If the above strategy is used in this case, each client needs to be retransmitted repair pack-ets individually, since the set of lost packpack-ets will most likely be different in every host. In this case, the goal is to send packets which are most likely un-received at all of the terminals. That is, the multicast cache ignores the exact sequence numbers in the requests and retransmits, for example, only FEC packets from the specified FEC block.