HCOR: a high-throughput coding-aware opportunistic routing for inter-flow network coding in wireless mesh networks

4.1 Opportunistic transmission and anypath cost

With the above settings, some conclusions can be achieved in the anypath cost.

4.2 Inter-flow network coding

Before discussing the issues of IRNC in opportunistic routing, we would like to give a definition of IRNC formally. For a network coding structure, w.l.o.g., we assume that there is only one coding node and multiple decoding nodes. All potential encoded flows should be encoded at the coding node and decoded at the decoding nodes. Considering a multihop wireless network, a flow runs possibly on a multihop path which starts at a source and ends at a destination. We denote a flow from source i to destination j by f _ij . If a native flow f _ij is encoded into an encoded flow, we mark it as a virtual native flow by $f_{\mathit{\text{ij}}}^{\prime }$. A path ${\mathcal{P}}_{\mathit{\text{ij}}}$ means a set of links connecting node i to node j. We say a flow on a path ${\mathcal{P}}_{\mathit{\text{ij}}}$ if and only if this flow passes the nodes i and j. According to the denotation of a flow, we distinguish a flow on a path by the start and end of this path. For example, given two flows f _ab and f _cd , if f _ab is on the path ${\mathcal{P}}_{\mathit{\text{ij}}}$, we say f _cd is distinguishable from f _ab on ${\mathcal{P}}_{\mathit{\text{ij}}}$ if and only if f _cd is not on ${\mathcal{P}}_{\mathit{\text{ij}}}$. Based on this setting of path distinction, we give the definition of IRNC by

4.3 General coding condition

Considering an intermediate node k on the path ${\mathcal{P}}_{\mathit{\text{ij}}}$ of flow f _ij , we denote the upstream part of ${\mathcal{P}}_{\mathit{\text{ij}}}$ at k by U _k (f _ij ) and the corresponding downstream part by D _k (f _ij ). Before doing network coding, the coding node must guarantee that the encoded flow is decodable. That means there is at least one node in the downstream which can decode this encoded flow. For doing this, the coding node must know the decoding knowledge before making any coding decision. In inter-flow network coding, decoding knowledge is the flow’s overheard information which is defined by a set of possible nodes which had or overheard this flow. This information can be achieved by learning neighbor state method. We denote the overheard information of flow f before node i by $O_i\left(f\right)={\cup }_{j\in U_i\left(f\right)}\left(N_j\cup \left\{j\right\}\right)$, where N _j is the neighbor of node j with a high PDR. The nodes in O _i (f) can be considered as the potential decoding nodes for the flows which are encoded with f. Hence, the general coding condition is given as follows.

5.1 Forwarding set of a coding node

In anypath routing, when an intermediate node receives a packet from a flow, only the destination of this packet and the nexthop which implies the neighbors of the coding node can be known as the downstream of this flow. According to the coding condition, the potential decoding nodes of this packet are only from its nexthops and destination. Hence, we have

5.2 Network coding price in anypath transmission

In this paper, we focus the issues of network coding only on the routing layer. So we study the cost of network coding on the transmission level and ignore the cost on the coding level, such as additional coding header or additional computation for network coding.

From our research, the main network coding price in anypath routing is from the shrinkage of the forwarding set. As illustrated in Figure 2, we consider a case with two-flow network coding. According to the coding condition, because some of the nodes in the forwarding sets J and K may be not the decoding nodes of this encoded flow, the forwarding sets J^′ and K^′ for encoded flow are not equal to J and K possibly. Hence, the forwarding set of each native flow will be changed after doing the network coding. According to Theorem 5.1, the new forwarding sets J^′ and K^′ are the subsets of J and K, respectively. That means, according to the Lemma 4.2, the costs of $C_{J^{\prime }}$ and $C_{K^{\prime }}$ will be greater than or equal to those of C _J and C _K , respectively. So additional price should be paid by doing network coding in this anypath transmission.

Based on the calculation of anypath cost and the above discussion, we know $c_{i\left\{J^{\prime },K^{\prime }\right\}}<c_{\mathit{\text{iJ}}}+c_{\mathit{\text{iK}}}$ and $C_{J^{\prime }}+C_{K^{\prime }}\ge C_J+C_K$. Hence, which one of $C_i^{f_j,f_k}$ and $C_i^{f_j^{\prime },f_k^{\prime }}$ is more expensive is unknown in the second case. In summary, due to the existence of network coding price in opportunistic routing, we should check whether it is worth to do the network coding even if a network coding opportunity is there.

6.1 Multihop overheard information

In the previous sections, we have mentioned that HCOR has a multihop coding structure. The key of realizing multihop network coding is to do multihop detection of overheard information (OI). Traditional network coding schemes use local OI detection [18], in which every node gets the OI only from its neighborhood, such as opportunistic listening or learning neighbor states in COPE. We call this local detection for simplicity. As illustrated in Figure 3, local detection misses many coding opportunities in the multihop networks. In [3], authors proposed a multihop OI detection method, say multihop detection for simplicity. Their multihop detection is based on local detection and works in the routing procedure. The OI of a flow is collected by local detection and transmitted with routing control packets to all the nodes on this route. The OI keeps being updated by adding some new OI from each hop. This process can be considered as a combination of two procedures, detecting OI locally and forwarding it to the route. However, this method has two defects. First, it is dependent on the routing procedure. For opportunistic routing methods which have no routing procedure, this method cannot work without routing control packets. Second, this method is not accurate. If the route is not broken but the neighbor nodes of this route have changed, then the OI detected by this method will be not right since the routing update does not begin.

Considering the above problems, HCOR uses each packet itself to piggyback its own OI. Before source node sending a packet, an OI list will be added into the control header of this packet. When a forwarder receives this packet, the OI list will be updated by adding its own OI before forwarding. The cost of inserting an OI list into the control header may be sensitive if we consider a large-scale intensive network. However, compared with broadcasting the receiving reports periodically, our method is still beneficial for reducing the packet collisions and control packet scheduling. In HCOR, every node maintains a neighbor table. Before sending a packet, the node will guess which nodes will overhear this packet from its neighbors. Only the neighbor with high PDR will be chosen (we set 0.7 as the default). If a node makes an incorrect guess occasionally, the relevant native packet should be retransmitted to help decode this encoded packet.

6.2 Virtual flow list

In HCOR, each node maintains a virtual flow list. The virtual flow list records the flows which are passing this node. The format of a virtual flow list is shown in Figure 4. Source and Destination identify a flow uniquely. Coding Flag marks that the virtual flow is a potential encoded flow, or say being an encoded status. Coding Expire is the expired time of this flow being the encoded status. Forwarding List is the temporary forwarding list of this encoded flow. It contains the anypath cost of every potential nexthop and is set to null if no network coding happens. Expire is the expired time of this virtual flow.

When a node received the first packet from a new flow, it will create a virtual flow in its virtual flow list. Every following packet from this flow will trigger an update of this virtual flow. There are two different updates for a virtual flow in HCOR. One is normal update which is triggered by every packet from the native flow. In normal update, only the flag of Expire will be reset. The other is coding update which begins only after receiving an ACK packet from a coding node (we will discuss this ACK process in the following section). In the coding update, the Coding Flag will be set to 1, Coding Expire will be reset, and the Forwarding List will be modified. In every node, there is a timer to purge the virtual flow list. The virtual flow will be removed if it is expired. The Coding Flag will be set to 0 if this virtual flow is not being an encoded flow.

6.3 Coding procedure and coding feedback

Whenever a node i receives a new packet p _k from flow f _k , it executes the coding procedure illustrated in Algorithm 1.

Line 24 implies the coding condition and Lemma 4.4. The costs $C_i^{k,j}$ and $C_i^{k^{\prime },j^{\prime }}$ obey Equations 7 and 8. In line 27, we use anypath cost as the judging criteria of network coding. Meanwhile, as we analyzed in Section 5.2, we always do network coding if the decoding node is the destination for each virtual native flow. As mentioned in Section 4.3, this coding procedure only realizes two-flow XORing. For m>2 flow XORing, if the calculation of anypath cost can be expanded to the multiple flow case, it can be realized with greedy strategy by only removing the word ‘native’ in line 5

where $d_{k^{\prime }}$ is the PDR of encoded packet p from i to nexthop _k . After the neighbor of i receives this coding feedback, its virtual flow list will be updated. The virtual flow (src, dst) updates its forwarding list by modifying the anypath cost of nexthop i to cost. After doing this, the anypath cost of node i for flow f _k is updated to $C_i^k=\alpha C_i^{k^{\prime }}+\left(1-\alpha \right)C_i^k$, where α=1 if $0<C_i^{k^{\prime }}<C_i^k$, and α=0 otherwise. Based on the update of virtual flow list, the nexthops recorded in the virtual flow will be more competitive to achieve a high priority to forward this packet. If network coding disappears, no coding feedback causes no virtual flow update. After reaching the expiration time, virtual flow will be purged, and then the new packet from this flow will be forwarded following its original anypath cost.

6.4 Decoding

In HCOR, every node works in the promiscuous mode and stores all packets sent and overheard by itself in the past T seconds in its Packet Pool. The decoding process happens when an encoded packet arrives at a node and the address of this node is in the decoding. Because we use the XOR coding method, the encoded packet can be decoded only by XORing any of the virtual native packets, such as p₁=(p₁⊕p₂)⊕p₂.

7.1 Results from illustrative scenarios

We present the performance of HCOR compared with the non-NC scheme in some basic topologies. Firstly, we study the chain topology with bidirectional flows shown in Figure 5a.

We set all links with a fixed PDR. Two symmetrical loads have the same rate from A to B and B to A, respectively. The measurements of average end-to-end throughput are plotted in Figure 6. The throughput gain is about 23% after symmetrical load running in the saturation levels shown in Figure 6a. The reason why HCOR and non-NC have different variation trends in Figure 6b is because the relay node in non-NC suffers from bottleneck, and hence, the bandwidth of its output links will be saturated when the loads keep increasing. In HCOR, the relay node mixes the two flows together and sends this mixture as one flow. So the rate of output is always lower than that of input. If input and output links have the same bandwidth, there is no bottleneck problem in HCOR because output links are always starved.

Next, we study X topology shown in Figure 5b. The measurement results are plotted in Figure 7. We can see that the throughput gain is still significant and about 21% in X topology. Different from the chain scenario, there are overhearing links in the X scenario. In our simulation, we set the threshold of guessing a successful overhearing to 0.7 as default. That means a node guesses one of its neighbors can overhear the packets it sends if the PDR from it to this neighbor is more than 0.7. Hence, we can see that the performance of HCOR and non-NC is similar when PDR is no more than 0.7 in Figure 7b. After that, a gain can be achieved by HCOR.

At last, a simple multihop scenario is studied to present the multihop structure of HCOR. This multihop topology is shown in Figure 5c. We plot the simulation results in Figure 8. The gain of HCOR is not as much as the above two scenarios. The reason may be the gain from bottleneck is diluted by bandwidth consumption from multihop transmission. But we can still have more than 10% gain for total end-to-end throughput over non-NC. In Figure 8b, HCOR almost always has a gain over non-NC because multihop topology has multiple coding structure, such as (A, B, C), (G, F, C), and ({B,E}, C, {F,D}), where (A, B, C) and (G, F, C) are not affected by the overhearing links.

7.2 Results from specific scenarios

In this section, we want to present how flexible HCOR is. We aim to point out the benefit of HCOR compared with COOR. To do this, we design two specific scenarios. One is cellular scenario with a hexagon topology. The other is diamond scenario with a double-diamond topology.

As shown in Figure 9a, there are seven nodes and two flows f₂₃ and f₆₅ with the same rate in the cellular scenario. The PDR of links (2,1), (2,4), (1,3), (6,7), (6,4), and (7,5) is set to 0.8. The PDR of links (4,1) and (4,7) is set to 0.4. The PDR of links (4,5) and (4,3) is set to 0.5. The PDR of links (2,5) and (6,3) is set to 1. The potential forwarding nodes for f₂₃ are nodes 1 and 4. The potential forwarding nodes for f₆₅ are nodes 7 and 4. Apparently, there is a coding opportunity at node 4 because the overhearing links (2,5) and (6,3) have very good quality. But the output links of node 4 are very poor. So intuitively, it seems that there is no gain for doing network coding at node 4. The simulation results plotted in Figure 9b demonstrate that our intuition is correct. COOR shows a poor performance in this scenario and has about 30% lower throughput gain than HCOR.

In the Figure 10a, we present a diamond scenario with two symmetrical loads f₆₇ and f₂₁. The PDR of links (5,7), (2,5), (6,3), and (3,1) is set to 0.9. The PDR of links (6,4), (2,4), (4,7), and (4,1) is set to 0.7. The PDR of links (4,5) and (4,3) is set to 0.63. According to anypath routing, node 5(3) is the forwarder of node 4 for flow f₆₇(f₂₁) since node 5(3) has better PDR to the destination than node 4. The structure composed of 6, 3, 4, 2, and 5 is a basic coding structure of X topology. So there is still a coding opportunity at node 4. The simulation results show that there is no coding gain in this scenario. The performance of COOR is 28% lower than that of HCOR.

7.3 Results from random scenario

At last, we consider the performance of HCOR in a larger random mesh network. We construct ten 50-node random topologies with size 1,000 × 1,000 and 20 random loads for each topology. All these loads have random sources and destinations with the same rate and random time of duration. The PDR of all links in these topologies is set to the ‘lowest bound PDR’, which means the PDR of every link is set randomly but higher than the lowest bound PDR value. We compare HCOR with COOR and plot the average throughput performance of these ten topologies in Figure 11. We first set the lowest bound PDR to 0.6 and show the throughput performance with increasing loads in Figure 11a. The results show that HCOR has more than 25% gain over COOR in this case. In another case, we vary the lowest bound PDR from 0.3 to 1 and use a fixed load rate of 400 kb/s. The throughput performance of the second case is shown in Figure 11b. We can see that the gain of HCOR is 13% higher than that of COOR, and the promotion is obvious between 0.5 to 0.8 of PDR.