1. Improving Opportunistic Data Dissemination via Known Vector
Jyh-How Huang1, Ying-Yu Chen2, Yi-Chao Chen2, Shivakant Mishra3, and Ling-Jyh Chen2
1 Department of Electronic Engineering, National Taiwan University
2 Institute of Information Science, Academia Sinica
3 Department of Computer Science, University of Colorado Boulder

2. Motivation
Replication is the most popular design choice for opportunistic network routing protocols.
For example, the Epidemic Routing protocol sends identical copies of a message over multiple paths to mitigate the effects of a single path failure.
Two encountered nodes may have some messages in common.
It is necessary to avoid sending the messages that the other node already has.

3. Motivation (Cont.)
Intuitively, exchanging meta-messages with indices of messages in the buffer can solve the problem.
However, meta-message exchange may become a big overhead.
We propose a new scheme, called Known Ventor (KV), to reduce the overhead.

4. Meta-Message
Meta-message is used to avoid sending duplicate messages that the other node already has.
Most protocols apply a scheme called Summary Vector as the meta-message.
A summary vector comprises all identifiers of the messages buffered on the node.
An identifier of a message is unique for each message in the network.
Let’s take the Epidemic Routing protocol as an example 

5. Epidemic Routing
When two nodes encounter, they exchange the summary vector with each other.
Each node compares the received summary vector to its buffer, and then requests the messages that are not in its buffer.
We call the request of messages as Request Vector.
After receiving a request vector, the node transmits the requested messages.

6. Example of Epidemic Routing
Define:
BUFx: the set of messages in the buffer of node x
SVx,y: the summary vector generated by node x for node y
RVx,y: the request vector generated by node x for node y
Node i
Node j
1. Before encounter
BUFi = {M1, M2, M3}
BUFj = {M3, M4, M5}
2. Exchange summary vectors
SVi,j = {M1, M2, M3}
SVj,i = {M3, M4, M5}
3. Send a request vector and transmit messages
RVi,j = {M4, M5}
RVj,i = {M1, M2}
4. After transmission
BUFi = {M1, M2, M3, M4, M5}
BUFj = {M1, M2, M3, M4, M5}
SV results in tremendous overhead when 1) nodes move in a group; and 2) network connectivity is good.

7. Our Approach: Known Vector
The idea: if a node knows which messages are not interesting to the other node, he removes those message IDs in advance, and thus reduces the SV size.
A simple solution:
Keep a record about who has the message
Send the record along with the message

8. The Known Vector Scheme
In the Known Vector scheme, each message has two parts:
the original data
a known vector
A known vector is a list of nodes who have already “known” this message.
Known Vectors of the same message may be different on different nodes (i.e., each node has its own view of the KVs for each stored message)

9. Why using Known Vector?
The Known Vector scheme can be considered as a pre-processor that removes non-interested meta-messages from a Summary Vector.
Every protocol that implements the Summary Vector scheme can apply the Known Vector scheme to improve its performance.

10. Procedures of Known Vector (0/4)
Define:
BUFx: the set of messages in the buffer of node x
SVx,y: the summary vector generated by node x for node y
RVx,y: the request vector generated by node x for node y
Mk,x: the copy of a message Mk resided in node x
KVMk,x: the known vector of Mk,x

11. Procedures of Known Vector (1/4)
Generate and exchange summary vectors: Node x generates SVx,y that contains IDs of the messages whose known vectors do not contain node y.
For example, when node i and j encounter:
- Status of node i: BUFi={M1, M2}, KVM1,i={m, j, n}, KVM2,i={a, b}
- Status of node j: BUFj={M3, M1}, KVM3,j={a}, KVM1,j={m}
- Node i generate SVi,j={M2} (Note: M1 is not included because KVM1,i contains j.)
- Node j generate SVj,i={M3, M1}

12. Procedures of Known Vector (2/4)
2. Generate and send request vectors: After receiving SVy,x, node x requests all messages in SVy,x but not in BUFx, that is, RVx,y = SVy,x – BUFx
For the previous example:
- Node i generates: RVi,j={M3} (Note: Node i does not request M1.)
- Node j generates: RVj,i={M2}

13. Procedures of Known Vector (3/4)
3. Transmit messages requested: 3.1) For every message Mk transmitted from node x to node y, node x duplicates Mk,x as Mk,x’ including KVMk,x, and sends it to node y. 3.2) After transmission: KVMk,x <- KVMk,x U {y} Mk,y <- Mk,x’, KVMk,y <- KVMk,x’ U {x}
For the previous example:
- After node i sends M2,i’ to node j: KVM2,i={a,b,j}, KVM2,j={a,b,i}
- After node j sends M3,j’ to node i: KVM3,j={a,i}, KVM3,i={a,j}

14. Procedures of Known Vector (4/4)
4. Update known vectors: Node x add y into the known vector of every message in the set SVx,y – RVy,x because node y is supposed to request every message in SVx,y unless it already has that message.
For the previous example:
- SVi,j – RVj,i = {}
- SVj,i – RVi,j = {M1} => KVM1,j={m,i}

15. Evaluation Evaluate the performance on top of Epidemic Routing
Simulator: The ONE
The Opportunistic Network Environment simulator
A Java-based simulator

16. Evaluation Scenarios Use two realistic wireless network traces:
ZebraNet
iMote
Trace Name
ZebraNet
iMote
Device
N/A
Network Type
Bluetooth
Duration(days) 16 3
Devices participating 34
274
Number of contacts
31,693
28,217
Avg # Contacts/pair/day

17. Evaluation Settings Messages: Transmission rate: 240Kbps
Generated in the first 10% of the simulation time
Are either 1K bytes or 100 bytes
With a Poisson rate of 40 seconds/message in iMote and 200 seconds/message in ZebraNet
Transmission rate: 240Kbps

18. Evaluation I: Infinite Buffer
CDF(cumulative distribution function) of delivery ratio:
- In both scenario, the two schemes are comparable.

19. Evaluation I: Infinite Buffer
CDF of overhead / total data transmitted:
- In iMote, KV reduces about 16% of overhead
- In ZebraNet, KV reduces about 31% of overhead

20. Evaluation II: Finite Buffer
CDF of delivery ratio:
Message size is fixed at 100 bytes.
The KV scheme outperforms the SV scheme in all test cases, and the performance gain increases as the buffer size decreases.
For example, the performance gain is about 16%, 7%, and 3% in the ZebraNet when the buffer is 20k, 40k, and 60k bytes.

21. Evaluation II: Finite Buffer
CDF of overhead / total data transmitted:
Message size is fixed at 100 bytes.
The KV scheme is able to reduce traffic overhead when comparing with the SV scheme.
For example, the KV scheme reduces about 77%, 77%, and 71% in ZebraNet when the buffer size is 20k, 40k, and 60k bytes.

22. Conclusion
The SV overhead may increase substantially as the number of messages buffered on each node increases.
We propose a novel approach, Known Vector, to mitigate the overhead.
The evaluation results show that the two schemes are comparable when the buffer is infinite.
However, when the buffer is constrained, the Known Vector scheme is much superior to the Summary Vector scheme.

23. Thanks! http://www.iis.sinica.edu.tw/~cclljj/