Re: [Roll] Interest in opportunistic routing?

["Gillmore, Matthew" <[e-mail]>]

Simon,

Not sure how that's possible because in 802.15.4-2011 it states

5.1.6.4 Use of acknowledgments and retransmissions
A data or MAC command frame shall be sent with the AR field set appropriately for the frame. A beacon or
acknowledgment frame shall always be sent with the AR field set to indicate no acknowledgment requested.
Similarly, any frame that is broadcast shall be sent with its AR field set to indicate no acknowledgment
requested.

Even if this restriction wasn't in place,  broadcasting with the AR bit set is not a good idea because any devices that hears the broadcast will respond within macSIFSPeriod will cause a flood.


[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

[Description: http://marketing.itron.com/campaign/social_media_icon_twitter29.jpg]<http://twitter.com/#!/itron>  [Description: http://marketing.itron.com/campaign/social_media_icon_facebook29.jpg] <http://www.facebook.com/ItronInc>   [Description: http://marketing.itron.com/campaign/social_media_icon_linkedin29.jpg] <http://www.linkedin.com/company/7550?trk=null>   [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: Monday, March 10, 2014 10:46 AM
To: Routing Over Low power and Lossy networks
Subject: Re: [Roll] Interest in opportunistic routing?

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]<mailto:[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

[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]<tel:%2B1.517.745.7350>
Knowledge to Shape Your Future

[Description: http://marketing.itron.com/campaign/social_media_icon_twitter29.jpg]<http://twitter.com/#!/itron>  [Description: http://marketing.itron.com/campaign/social_media_icon_facebook29.jpg] <http://www.facebook.com/ItronInc>   [Description: http://marketing.itron.com/campaign/social_media_icon_linkedin29.jpg] <http://www.linkedin.com/company/7550?trk=null>   [Description: http://marketing.itron.com/campaign/social_media_icon_youtube29.jpg] <http://www.youtube.com/itronsmartmedia>



From: Roll [mailto:[e-mail]<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]<mailto:[e-mail]>> wrote:

Simon Duquennoy <[e-mail]<mailto:[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]<mailto:[e-mail]>>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/


_______________________________________________
Roll mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll


_______________________________________________
Roll mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll