Re: [Roll] Interest in opportunistic routing?

[Simon Duquennoy <[e-mail]>]

Hi Matt,

The context where anycast is some sort of acked broadcast is with radio
duty cycling, in particular low-power listening. In this context,
broadcasting consists in repeated transmissions for an entire sleep period
so that all neighbors wake up once and get the frame. What we do is we set
the ACK bit and we stop the broadcast transmission upon receiving an ACK
from any neighbor (c.f. fig 2 in the paper). The concept can be applied
(with some adaptations) to different duty cycling solutions including
802.11 PSM, 802.15.4 CSL, RIT or TSCH.

Thanks,
Simon



On Mon, Mar 10, 2014 at 3:16 PM, Gillmore, Matthew <
[e-mail]> wrote:

>  Simon,
>
>
>
> In 802.15.4,  setting the AR bit for acknowledgements on a broadcast is
> not a good idea because the network would be flooded with ACKS.
>
>
>
> Matt
>
>
>
> [image: Description:
> http://marketing.itron.com/campaign/ribbon_logo_rgb_81h.jpg]<https://www.itron.com/>
>
> *Matthew Gillmore*
>
> Strategic Standards Architect, Office of the CTO
> Mobile: [phone]
> Knowledge to Shape Your Future
>
> [image: Description:
> http://marketing.itron.com/campaign/social_media_icon_twitter29.jpg]<http://twitter.com/#!/itron>
> [image: Description:
> http://marketing.itron.com/campaign/social_media_icon_facebook29.jpg]<http://www.facebook.com/ItronInc>
> [image: Description:
> http://marketing.itron.com/campaign/social_media_icon_linkedin29.jpg]<http://www.linkedin.com/company/7550?trk=null>
> [image: Description:
> http://marketing.itron.com/campaign/social_media_icon_youtube29.jpg]<http://www.youtube.com/itronsmartmedia>
>
>
>
>
>
> *From:* Roll [mailto:[e-mail]] *On Behalf Of *Simon Duquennoy
> *Sent:* Friday, March 07, 2014 8:47 AM
> *To:* Routing Over Low power and Lossy networks
> *Subject:* Re: [Roll] Interest in opportunistic routing?
>
>
>
> On Fri, Mar 7, 2014 at 1:37 PM, Michael Richardson <[e-mail]>
> wrote:
>
>
> Simon Duquennoy <[e-mail]> wrote:
>     > We have designed an opportunistic extension of RPL, where the basic
> idea is to
>     > exploit all links of the DODAG rather than the tree defined by links
> to
>     > preferred parents. We do this using anycast: transmissions are
> intended either
>     > (upwards) to any parent or (downwards) to any child having the
> destination
>     > below in the DODAG.
>
> This is very interesting.
>
>     > We have a working prototype [1] in Contiki that we evaluated
> thoroughly in a
>     > 135-node testbed [2]. In a 4-min packet interval data collection, we
> increase
>     > the reliability of RPL from 97.4 to 99.5%, while halving the latency
> (below
>     > 0.5s) and radio duty cycle (below 0.5%).
>
>     > If there is interest, we can come up with a simplified version of
> the design
>     > presented in the paper, and propose a way to integrate it in RPL
> through only a
>     > few minor additions. To be more specific, the simplified version
> would use the
>     > existing RPL routing tables rather than Bloom filters, and would be
> MAC-layer
>     > agnostic (the only assumption being that the MAC layer supports
>     > anycast).
>
> I'm not familliar with the concept of anycast at layer-2.
> I think that ethernet supports this, but that actually one would have the
> multicast bit set.  I think that you'd have to do the same thing on 802.11.
> I guess that 15.4 has a specific support for this, or is just a choice of a
> particular unicast mac?
>
>
>
> Dear Michael, all,
>
>
>
> There is no specific support for anycast in 802.15.4, but the standard MAC
> layers can easily be used for anycast (often by setting multicast/broadcast
> + ACK bits).
>
> I've see prototypes for 802.15.4 beacon-enabled [1], for a 15.4e RIT-like
> MAC [2], and for a CSL-like MAC (our own implementation uses ContikiMAC,
> which is similar CSL).
>
> Should also be possible with 15.4 TSCH or even 802.11 PSM.
>
> Doing this on an always-on link like ethernet or traditional 802.11 is
> more tricky because you need an agreement procedure so that only one
> neighbor that received the packet forwards it. There exist solutions for
> WiFi, such as ExOR [3], which introduced opportunistic for 802.11 back in
> 2005. I don't think we want to go into this though; I'd rather simply
> stipulate that anycast is required at the MAC layer and possibly give some
> hints on how to support it on the most common MAC protocols.
>
>
>
> Best,
>
> Simon
>
>
>
> [1]
> http://clarinet.u-strasbg.fr/~theoleyre/uploads/Publis/pavkovic11rpl.pdf
>
> [2] http://www.ti5.tuhh.de/publications/2012/EWSN12_Orinoco.pdf
>
> [3] http://en.wikipedia.org/wiki/ExOR_(wireless_network_protocol)
>
>
>
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>
>