Information Pool Management

As we mentioned before, one of the keys to make the network coding practical is information pool. Due to the limited size of inf oP ool, how to manage inf oP ool is an important issue.

If we can manage inf oP ool effectively, then we can effectively utilize the benefit of OASIS protocol.

In [5], this issue is not be discussed much. The original approach that COPE adopts is buffering the received packet for a period time (the default value is set to T = 0.5s). In this way, the size of inf oP ool may be small; however, it does not well utilize the received packets. That is, the received packets may be dropped before they can be used to decode plain packets.

We further observe a situation that once a packet in the inf oP ool has been used to decode a plain packet from a coded packet, then the probability of the packet being used again is really low. We call that this packet is referred. If the packets in the inf oP ools of the neighbors of a certain sender have been referred in a certain transmission, then which implicitly means that this sender has mixed all of these packets into a coded packet. In addition, there must have some potential receivers intending for these packets. If all these potential receivers successfully decode their intended packets, then the sender will drop all of these packets and never send them again. In other words, there is small probability for these packets in the neighbors’ inf oP ools being referred again since these packets have already removed from the sender’s queue. The only situation that the packets are sent again is the occurrence of the retransmission events. However, there are rarely such events in our

experiments. The conditional probability of packets referred twice under that are referred once is no more than 2% as shown in Fig. 4.4. As the above observation, we propose a new approach to manage inf oP ool. The detail of the management algorithm is depicted in PROCEDURE 3.

In our proposed algorithm depicted in PROCEDURE 3, we use not only the factor adopted by COPE, the time that a packet stays in the inf oP ool, but also a new factor, that is the number of times that a packet is referred. In addition, we consider that a packet which has been referred has lower probability to be referred again than which has long staying time. Thus, in our algorithm, we give the higher priority for a packet being replaced to the packets which have been referred. A node v inserts a plain packet p into its inf oP ool_v when it generates, relays and overhears a plain packet or decodes a plain packet from coded packet. It first checks whether inf oP oo_v is full or not. If the inf oP ool_v is not full, v simply put p into inf oP oolv. If inf oP oolv is full, then one packet must be remove from the inf oP ool to free a slot for p. We first check that if there exists a packet q belonging to inf oP ool_v such that the inequality, q.ref T imes > REF ER T IMES LIMIT , can be held, where q.ref T imes represents the reference times of q and REF ER T IMES LIMIT is defined to be the threshold of reference times that a packet can be referred. Here, we set the value of REF ER T IMES LIMIT to be 1, that is, we can replace a packet once it has been referred. If there is such packet q, then we replace q with the new packet p and finish the management procedure. If there is no such packet in inf oP ool_v, then we further check that if there exists a packet q belonging to inf oP ool_v such that the inequality,

q.stayT ime > ST AY T IME LIMIT , can be held, where q.staytime represents the time that q stays in inf oP ool_v and ST AY T IME LIMIT is defined to be the threshold of the time that a packet can stay in inf oP ool_v. Here, we set the value of ST AY T IME LIMIT to be 0.5s, which is the same setup with the default value of COPE. If there is such packet q, we replace q with the new packet p and finish the management procedure. Finally, if both check described above are failed, we randomly choose a packet q belonging to inf oP ool_v, and replace q with the new packet p. The reason for doing so is that we think that a new coming packet has more potential to be used in the future. That is because, in a network with high traffic load, the packets in the inf oP ool are soon out of date. Thus, frequently updating inf oP ool is needed.

PROCEDURE 3 OASIS₋inf oP ool₋management (v, inf oP ool)

Require: node v receives a packet p, and want to insert it into inf oP ool_v if inf oP ool_v is full then

if ∃q ∈ inf oP ool_v, and q.ref T imes > REF ER₋T IM ES₋LIMIT then replace q with p

else if ∃q ∈ inf oP ool_v, and q.stayT ime > ST AY₋T IME₋LIMIT then replace q with p

else

randomly pick q ∈ inf oP ool_v replace q with p

end if else

put p into inf oP ool_v end if

Chapter 4