CHAPTER 2 Related Work
2.5 Network Coding on DTNs
國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
11 Figure 3: The encoding process of RLNC
A node decodes as soon as it has received coded blocks X = , , … , with linearly independent encoding vectors. It first forms a coefficient matrix C using the encoding vectors. Each row in C corresponds to the encoding vectors of one coded block.
The original blocks B , , … , could be recovered by:
B = C X
The inversion of C is only possible when its rows are linearly independent, in other words C is full rank (rank of C == k).
2.5 Network Coding on DTNs
Network coding has been widely used in different network filed. Several research efforts [14, 15] have applied network coding to P2P system. Katti et al proposed a scheme to combine network coding and wireless mesh network [16]. CodeTorrent[17] and VANETCODE[18] exploit network coding to rapidly distribute data among nodes in vehicular network.
There are some routing protocols [19, 20] studied the benefit of network coding on DTNs. Those protocols applied network coding to avoid redundant replication transmission.
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
12
However, those protocols select relay node based on epidemic routing, so they send coded blocks to every contact node results in high transmission overhead.
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
13
CHAPTER 3 The LANC Protocol
This section we will introduce our schemes in detail. First we give an overview of the protocol and describe detail in the subsections below. We proposed location-assisted routing with network coding: LANC. The main idea of LANC is, as each contact opportunity occurs; calculate the probability of the contact node to check if it is suitable to relay messages to destination. The criterions we used to estimate probability are trajectory of node, node’s moving direction and its velocity. If the result of estimated probability is larger than the threshold, the RLNC operation will be performed on messages in the buffer. After the coding process, this protocol schedules messages to transmit according to the estimated results. When the transmission is completed, the rank map and purge table will be put into beacons to inform other nodes. Once a node receives the beacon from contact node, it could purge its buffer by looking up the purge table.
‧
We model a DTN as a set of mobile nodes in a vehicular environment. And there is only allowed inter-vehicle communication. A "contact" is defined as two nodes are within the radio range of each other, thus they have an opportunity to transfer data. Each node in the network equips global positioning system (GPS) device. And the navigation system is installed on every node. The nodes use the navigation system to find a shortest path to its destination. The navigation system provides three kind of primitive information: trajectory, moving direction and velocity. Based on the information provided by navigation system, every node can collect navigation information contained in beacon which is broadcasted from the contact neighbors during contact time and make routing decision accordingly. The destination of message has a fixed location such as a portal to internet. A node can deliver messages to the final recipient directly or via intermediate nodes.
3.2 Delivery Probability Estimation
When transmission opportunity occurs during contact time, how to define a delivery quality of node is the first question to address. Same as the concept of forwarding-based routing protocol, we use the location information to estimate the delivery probability.
First of all, if there is a node that will bring the message closer to destination, we might be able to rely on it to deliver the message. So we adopt the future trajectory of node provided by navigation system as one of the estimation factors.
However, the trajectory information is not enough to define good relay candidates. For example, a bus may have a fixed trajectory closer to destination but its moving direction is
‧
away from it. Therefore, the node’s moving direction should also take into account.
Finally, it is very intuitive to select a faster node to take the responsibility for delivering message.
Combined the three factors, the formula we used to estimate delivery probability listed below:
1 c: Contact node
, , : System parameters (range from 0 to 1), 1 Path(c): Ratio to reach destination (range from 0 to 1)
Dir(c): Ratio moving toward destination (range from 0 to 1) V(c): Relative velocity ratio (range from 0 to 1)
If the result of P(c) is greater than the predefined threshold, then the contact node c are viewed as an appropriate relay candidate. The detail of algorithms will list below.
3.2.1 Algorithm Path(c)
In algorithm Path(c), the minimal distance between message’s destination and a node’s path is defined as the result that calculating the minimum distance from the location of destination to each coordinates of the path. For example, in Figure 5 the message is now at node A.
Input: Node A’s path, Node C’s path, Message M Output: ratio to reach destination
1. dist_A := minDistance(A.getPath(), M.getDestination()) 2. dist_C := minDistance(C.getPath(), M.getDestination()) 3. ratio := Math.abs(dist_A-dist_C)/dist_A
4. Path(c) := ratio > 1 ? 1 : ratio 5. return Path(c)
Figure 4: Algorithm Path(c)
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
16
There is a contact node C. For Node A, the minimal distance between Node A’s future path and destination is dist_A. For Node C, the minimal distance from destination to each coordinates of Node C’s path is dist_C. It is obvious that node C will be closer to the destination, so node C is more proper than node A for delivering message M. Using algorithm Path(c), we obtain the ratio to reach destination of each contact node.
Figure 5: Calculate Path(c)
‧
As mentioned before, the algorithm Path(c) may not be enough to select a “good” relay node;
the moving direction should be also considered. Therefore, we add the second function, Dir(c), in the delivery probability estimation formula. For instance, in Figure 7, node A is in
contact with node C, and node A holds the message M. We can get a vector formed by message M’s moving intention, and another vector of node C’s moving direction. There will be an angle formed by these two vectors. If the angle is close to zero means that the node C is moving toward the destination of message M. So we could also take node C as a relay candidate. We would get the ratio moving toward destination of the contact node by using algorithm Dir(c).
Input: Node A’s location, Node C’s moving direction, Message M Output: ratio moving toward destination
1. mv_M := M.getDestination() – A.getLocation() 2. len_M := countDistance(mv_M)
3. mv_C := C.getMovingDirection() 4. len_C := countDistance(mv_C)
5. angle := Math.acos(Math.dotsum(mv_M, mv_C) / (len_M*len_C)) 6. Dir(c) := 1 – angle/π
7. return Dir(c)
Figure 6: Algorithm Dir(c)
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
18 Figure 7: Calculate Dir(c)
3.2.3 Algorithm V(c)
Input: Node A’s speed, Node C’s speed Output: relative velocity ratio
1. spd_A := A.getSpeed() 2. spd_C := C.getSpeed() 3. if(spd_C == 0) 4. V(c) := 0 5. else if (spd_A == 0) 6. V(c) := 1 7. else
8. ratio := Math.abs(spd_A-spd_C)/spd_A 9. V(c) := ratio > 1 ? 1 : ratio
10. return V(c)
Figure 8: Algorithm V(c)
‧
When designing a DTN routing protocol, delay latency is an important issue needed to be concerned; hence we wish message delivered to destination as soon as possible. If a node has faster velocity, then it might reach destination quickly. The relative velocity ratio is calculated using algorithm V(c).
3.3 Location-assisted routing with network coding
Now we will give a full description of our proposed protocol in this section. The LANC protocol executes when two nodes are within radio range and have discovered one another.
It has five stages: Initialization, Probability estimation, Coding, Scheduling and Termination.
When two nodes contact with each other, they will collect metadata during initialization stage. After obtain the metadata, the nodes will estimate the delivery probability using the formula we mentioned in previous section 3.2. If the result of estimation is larger than threshold, it will perform coding operation on the messages in outgoing buffer. Due to not all the coded blocks are needed to be delivered, the coded blocks will be scheduled by the previous estimated results and contact node’s rank map. After the transfer is finished, if the receiver is the destination of the message, it will try to decode the message, update purge table or rank map depending on the decoding result. The detail of each stage is listed below.
3.3.1 Initialization
When moving in the networks, nodes will send out periodic beacons which allow detecting contact nodes in the transmission range. A node will not send out any message if it has no neighbors. The beacons not only inform neighbor the presence of node, but also contain the metadata of node.
‧
The metadata contained in beacon includes: trajectory information of node, node’s moving direction, velocity, rank map and purge table. The first three factors are used to estimate delivery probability as we mentioned before. The rank map is a record of independent encoding vectors of each message. The purge table indicates which message has already decoded.
The format of rank map is: (M_ID: R, M_ID: R, M_ID: R …) M_ID: unique id of message
R: rank of message
In order to distinguish a coded block belongs to which message, a unique identifier will be assigned to message before encoding process at source. Here we use a hash function called SHA-1 to generate unique identifier for each message.
The rank of message is the number of independent encoding vectors. At each transmission finished, a node will check the rank of message, and records the value with corresponding message identifier.
The format of purge table is: (M_ID: T, M_ID: T, M_ID: T…) M_ID: unique id of message
T: the time original message is decoded
If the original message is decoded successfully, its identifier and the time decoding process finished will be pushed into the purge table and propagated by beacons. Nodes receive this beacon could drop coded blocks according to the same identifier to release memory space.
3.3.2 Probability Estimation
After discovering a contact node by its beacon, a node could estimate the delivery probability
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
21
using the formula we mentioned in section 3.1. The procedure works as follow: for each message in buffer, if the result of P(c) is larger than threshold, then puts the message in outgoing buffer for next coding stage.
3.3.3 Coding Operation
Before the transmission starting, the coding operation will code the blocks in the outgoing buffer. The RLNC is performed on the blocks with the same message identifier. The encoding operation is a slight difference between source node and relay node.
In source node, a message is divided into k blocks and one or several coded blocks will be transferred with corresponding encoding vectors. As mentioned in section 2.4, the source first chooses a set of random elements from GF 2 , then multiplies each block with the element , and adds up all the results of the multiplications together to produce a coded block. If the source node wants to generate another coded block, the operations are the same except the source node has to choose another encoding vector. Figure 9 illustrates the coding operation in source node.
Figure 9: Encoding a single block in source
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
22
If a relay node wants to send coded blocks to another node, it operates similar operations as source does. It also chooses a set of random elements from GF 2 , but the size of this set is the number of coded blocks with the same message identifier in its buffer. Relay node multiplies each element with encoding vector and finally adds up to produce a new encoding vector. This operation is repeated again using the same set of elements to generate a new coded block. Since all the numerical operations are defined on GF 2 and all the coefficients are also randomly chosen from GF 2 , the new generated code block and encoding vector are still the linear combination of original message. The message is decodable as long as the destination could receive enough linear independent encoding vectors such that the coefficient matrix formed by encoding vectors is full rank. Figure 10 shows the encoding procedure in relay node.
Figure 10: Re-encoding in relay
3.3.4 Scheduling
Before starting a transmission, we will schedule which coded blocks in outgoing buffer should be transferred first to get better performance. As we mentioned in previous section, a message is decodable only if its encoding matrix is full rank. Therefore, the rank of message is the first factor we used to make scheduling decision. During initialization stage, a node
‧
could obtain the contact node’s rank map from beacon. Then the node could look up the rank map of contact node by message identifier to get the corresponding rank.
The second factor is the delivery probability to destination. In section 3.2, we proposed our method to estimate the probability if the contact node would reach the destination in the future. So the probability can be regarded as the power that delivering messages to the final recipient. With great power comes great responsibility. If a node finds out that the power of its contact node is less than its power, this node would not have to transfer all the coded blocks to its contact node. It will merely transfer part of coded blocks in its outgoing buffer to contact node. The pseudo code of our scheduling approach is listed below.
Scheduling(Node A, Node C, Buffer outgoing){
for(Message M: outgoing){
if(C == M.getDestination()){
rank_C := rank_map_C.get(M.getID()) if(M.isFullRank(rank_C))
continue
if(startTransfer(C, M) == Receive_OK) rank_map_C.update(M.getID()) }else{
rank_C := rank_map_C.get(M.getID()) if(M.isFullRank(rank_C))
continue
prob_A := Estimate(A, M.getDestination()) prob_C := Estimate(C, M.getDestination()) rank_A := rank_map_A.get(M.getID())
limit := Math.ceil(rank_A * (prob_C/prob_A)) if(transfer_count > limit)
continue
if(startTransfer(C, M) == Receive_OK){
rank_map_C.updata(M.getID()) transfer_count := transfer_count + 1 }
} } }
Figure 11: The scheduling scheme of LANC
‧
A transfer ends when two nodes are out of radio range or all outgoing blocks transmitted.
After the transfer, the node which received coded blocks would update the rank map, or try to recover the original message by decoding.
3.3.5.1 Update Rank Map
After receiving a coded block, a node will execute Gaussian elimination procedure to verify if the incoming coded blocks is innovate to the coded blocks in buffer. If the result of checking is true, the incoming coded block will be put into buffer and increase the rank counter by one in rank map according to the message identifier.
3.3.5.2 Decoding
After the rank map updating, if the encoding matrix of message is full rank, in other words, the number of independent encoding vector equals the size of each single encoding vector, the Gaussian elimination will be operated on it to get the inverse of encoding matrix. The original message will be recovered by encoding the inverse of encoding matrix and coded block.
3.3.5.3 Update Purge Table
In DTNs, some nodes would continuously send the messages that have already delivered to destination because these nodes don’t know the messages reached their final recipient.
To ease the kinds of redundant transmissions and buffer occupancy, once the destination recovers the original message successfully by decoding operation, the purge table will be updated by adding the message identifier and the time it decoded. The purge table will be propagated by beacons over the network. After received the beacons, a node will compare
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
25
the message identifiers contained in purge table with messages identifier of coded blocks currently stored in its buffer. If it finds out the same identifier, it will purge the buffer by discarding the coded blocks with the same message identifier immediately because it is not necessary to send the coded blocks of this message anymore.
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
26
CHAPTER 4 Simulation and Results
This section we will discuss the simulation. We evaluate the performance of LANC through simulation by using the Opportunistic Network Environment simulator [21].
4.1 Performance Evaluation
The main object of a DTN routing protocol is to maximize the message delivery ratio and to minimize the delay latency. We evaluated our protocol in vehicles environment. We evaluate the performance of LANC using three metrics:
Message delivery ratio
Average delay latency
Transmission overhead: The transmission overhead is defined as
We compare LANC with another two routing protocols: Epidemic Routing and PROPHET Routing. The Epidemic Routing is a greedy approach that duplicates copies of message to every contact node. The PROPHET Routing uses history of encounter and transitivity to select a better relay node. We modified these two protocols such that they have the ability to perform random linear network coding.
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
27
4.2 Simulation Setup
Our evaluations are based on The ONE (Opportunistic Network Environment simulator), a simulator written in java. We developed a set of extensions to the simulator to enable nodes could overhear neighbors’ transmissions and to implement a random linear network coding module.
We use a map-based model of a small part of the city of Helsinki for the simulation.
The size of this map is 4500m * 3400m. The nodes in the map can only drive on roads.
The speed of nodes is from 20 to 80 km/h. Once a node reaches its destination, it will randomly choose a new random map location as its new destination and finds the way to destination using the shortest available path. Figure 12 is a snap shot of simulation.
Figure 12: a snap shot of simulation
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
28
The simulation times are 43200 seconds. For the fairness, the warm up time is 1000 seconds. The nodes only could move but not allow transmitting any message until the warm up time counts down to zero. Each destination of flow has a stationary location selected randomly before starting the simulation. Every node has only one single network interface.
The data rate is 1 Mbps and the transmission range is 100m. For each flow, there are 100 messages to transmit. Each message is divided into 16 blocks. The size of a message is 256KB, so the size of each block is 16KB. The buffer size of every node is set to half of total flow, but the source and destination have additional buffer space to store message that are transmitting to destination or receiving from source respectively. The TTL is 3 hours, and pure duration is 6 hours. Below are the parameters we described above.
Figure 13: The parameters of simulation
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
29
4.3 Simulation Results
We evaluated our approaches in three different scenarios: single flow, two flows and multiple flows. Although our protocol has a little higher data transmission delay than other protocols, but the delivery ratio is almost the same as Epidemic routing with NC in multiple flows scenario. It shows that with overhead ratio, LANC outperforms with other approaches.
4.3.1 Single Flow
In single flow case, we want to know the impact of three factors in our estimation algorithm.
The number of nodes is set 40 to 80. In LANC, the default value of α, β, γ is 0.33 and default threshold is 0.4. The value of α, β, γ will be set to 1 in different simulation round.
The result shows in figure 14 to figure 16. It’s very obvious that if the estimation uses only one factor to make relay node selection; the performance will all be lower than Epidemic routing with NC and PROPHET routing with NC. But if we use these three factors to estimate the probability at the same time, it will get a better performance.
Figure 14: Delivery ratio of single flow
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
30
From figure 14, the future trajectory information of a node is the most significant factor for increasing delivery ratio. The reason is that even if the relay node couldn't reach the destination eventually, the other nodes around destination could take over the responsibility of delivering message to final recipient. Therefore, a message should be transferred to the node has the minimal distance between its future trajectory and the destination of message.
Figure 15: Average delay of single flow
We could get the same conclusion as figure 14 from figure 15. If a message is closer to destination, the less time it needs to reach destination. On the contrary, if the message is taken away from its destination, it has to do more effort to get back to destination, and it’s
We could get the same conclusion as figure 14 from figure 15. If a message is closer to destination, the less time it needs to reach destination. On the contrary, if the message is taken away from its destination, it has to do more effort to get back to destination, and it’s