Improving Opportunistic Data Dissemination via Known Vector by r5uhfBp

VIEWS: 0 PAGES: 23

									 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
                  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.
          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.
              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 
          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.
       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        SVi,j = {M1, M2, M3}          SVj,i = {M3, M4, M5}
vectors
3. Send a request vector   RVi,j = {M4, M5}              RVj,i = {M1, M2}
and transmit messages
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.
   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
      The Known Vector Scheme
• In the Known Vector scheme, each message has two
  parts:
   1. the original data
   2. 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)
     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.
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
Procedures of Known Vector (1/4)
1. 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}
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}
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}
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}
               Evaluation
• Evaluate the performance on top of
  Epidemic Routing

• Simulator: The ONE
  – The Opportunistic Network Environment
    simulator
  – A Java-based simulator
             Evaluation Scenarios
• Use two realistic wireless network traces:
  – ZebraNet
  – iMote
   Trace Name                ZebraNet   iMote
   Device                    N/A        iMote
   Network Type              N/A        Bluetooth
   Duration(days)            16         3
   Devices participating     34         274
   Number of contacts        31,693     28,217
   Avg # Contacts/pair/day   3.53086    0.12574
          Evaluation Settings
• Messages:
  – 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
       Evaluation I: Infinite Buffer
CDF(cumulative distribution function) of delivery ratio:
 - In both scenario, the two schemes are comparable.
      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
         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.
        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.
                   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.
           Thanks!
http://www.iis.sinica.edu.tw/~cclljj/
    http://nrl.iis.sinica.edu.tw/




                                        23

								
To top