Subject: Re: [Roll] [6lowpan] Syncronized Wake

From: Kris Pister <[email-masked]>
Date: Sat, 08 Mar 2008 12:07:54 -0800

Pieter, Collin:
the ISA100.11a MAC is based on TSMP (http://en.wikipedia.org/wiki/TSMP), 
although it's been made very general because of political requirements 
in getting the .11 group off the ground.  So it's actually possible to 
configure it to be pure scheduled unicast channel-hopping TDMA, pure 
single-channel CSMA, or anything in between.
One likely operating mode would look something like this (this is 
basically what Wireless HART does):
* 10ms slot length.  Single packet sent and acknowledged in a single 
slot.  Most scheduled slots would be unicast for "upstream" data 
collection.  Some scheduled slots would be broadcast for downstream 
communication.  Some might be shared bandwidth (slotted aloha).  
Scheduled slots repeat in one or more superframes, similar to but far 
more flexible than the 15.4 GTS mechanism.
* +/- 1ms guard time at the beginning of the slot to allow for 
synchronization errors.  Depending on the temperature range and the 
quality of the time-keeping at each mote, this leads to a 
synchronization requirement of between 10 seconds and a minute.  Motes 
keep track of their last synchronization (optionally on a path-by-path 
basis) and send a keepalive packet if their synch timer expires.  Every 
acknowledged packet carries time information in both directions, so they 
reset the synchronization timer.  For many/most motes in many/all 
networks there is no need for additional synchronization traffic above 
and beyond normal data traffic.  For low traffic networks, beaconing may 
be used if it makes more sense energetically than keepalives.  For 
802.15.4 radios, the overhead for maintaining +/-1ms synchronization 
across the entire network is less than 0.01% radio duty cycle.
Since all motes share a common sense of time, they can pseudo-randomly 
channel hop, dramatically reducing the chance of a link between two 
motes "going down" due to external or multi-path interference.
* Communication cells (={slot, channel_offset} pair) may be assigned by 
some central manager, or via purely distributed algorithms, or some 
combination of both.  Enforcing unicast with no collisions, 1,600 cells 
per second are available (100 slots/second * 16 channels).

Cells are collected into graphs.  Graphs provide QoS to applications, 
and can be turned on and off to dynamically vary power and performance 
over many orders of magnitude in response to application requests.  This 
is where things get interesting with 6LoWPAN and RoLL.  TSMP provides 
the mechanisms to bind layer 4 quality of service to layer 3 routes and 
layer 2 performance/power provisioning.  This is critical in industrial 
automation, and seems likely to be very useful in other applications as 
well.  I don't think that it violates anything that the IETF holds dear, 
but I've  been wrong about that before :)

ksjp

Pieter De Mil wrote:
> Hi Robert,
>
> I don't know if Colin is interested in more details, but I certainly am.
>
> How frequently do you have to exchange sync. messages? Every 10/60/.. 
> seconds?
> How are your sync. messages scheduled? Via a distributed assignment?
>
> Do you use CSMA/CA in a time slot?
>
> Pieter
>
> ----- Original Message ----- 
> From: "Robert Assimiti" <[email-masked]>
> To: "Colin O'Flynn" <[email-masked]>; <[email-masked]>
> Sent: Thursday, March 06, 2008 10:17 PM
> Subject: Re: [6lowpan] Syncronized Wake
>
>
> Hello Colin,
>
> The currently undergoing ISA100.11a standardization effort would be the 
> perfect paradigm for what you are trying to accomplish. It is a standard 
> geared towards industrial process and automation, but it definitely has 
> applicability in commercial applications as well.
>
> Currently employing the 802.15.4 PHY/MAC (although alternate PHY/MACs are 
> being considered), the Field Devices (FFD/RFDs in 802.15.4 semantics) 
> communicate during strictly enforced "time slots" without using beacons. 
> This allows for prolonged battery life although frequent time 
> synchronization messages must be exchanged.
>
> Let me know if you are interested in more details.
>
>
>
>
>
> "The nice thing about standards is that there are so many to choose from." - 
> Andrew S. Tanenbaum
> Robert Assimiti
> Executive Staff Engineer
> Office: [678]-202-6859
> Mobile: [404]-578-0205
> [email-masked]
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Colin O'Flynn
> Sent: Sunday, March 02, 2008 9:21 AM
> To: [email-masked]
> Subject: [6lowpan] Syncronized Wake
>
> Hello All,
>
> First a quick question - I found this list on the IETF site. I assume it's a
> public list, you don't have to be a member of the working group to submit?
>
> Anyway, a few of us are working on doing a 6lowpan implementation. I was
> looking at doing a 'syncronized wake' to help save power yet get reasonable
> response times. By my calculations you could wake every few seconds and 
> still
> have an exceptional battery life (year+).
>
> Since some nodes might need to wake up more often than others they might 
> have
> different schedules, and obviously you'd need some sort of beacon to
> syncronize. The idea is each node has a "wake schedule" that nearby nodes
> know, and will be listening at that time. But any node can TX at almost any
> time.
>
> I don't want to do GTS though, as nodes can talk at any time. But I need a 
> way
> to (a) sync nodes and (b) transmit wake schedule.
>
> So the question: would their be a standards-compliant way to do this? Or is 
> it
> worth it trying to be standards compliant at this stage? It would be easy
> enough to make some simple protocol up to do this for testing.
>
> Warm Regards,
>
>  -Colin O'Flynn
>
> PS: If you are interested: hardware is 8-bit AVR devices, using uIP for IPv6
> implementation. The gateway router is AVR32 device, which can route over
> ethernet.
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>
>
> This e-mail (including any attachments to it) is confidential, proprietary, 
> legally privileged, subject to copyright and is sent for the personal 
> attention of the intended recipient only. If you have received this e-mail 
> in error, please reply to advise us immediately, delete it and destroy any 
> printed copies of it. You are notified that reading, disclosing, copying, 
> distributing or taking any action in reliance on the contents of this 
> information is strictly prohibited. No employee is authorized to conclude 
> any binding agreement on behalf of NIVIS LLC with another party by e-mail 
> without express written confirmation by an officer of the company. Although 
> we have taken reasonable precautions to ensure no viruses are present in 
> this e-mail, we cannot accept responsibility for any loss or damage arising 
> from the viruses in this e-mail or attachments.
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>
>
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>   
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Kris Pister <[email-masked]>
Date: Mon, 10 Mar 2008 10:20:22 -0700

responses inline

Pieter De Mil wrote:
>  Hi Kris, All;
>
> Thanks for the info, the ISA100.11a MAC seems to be a very flexible MAC
> layer.
>   
There is some concern about it being too flexible :)
> Some questions inline.
> although it's been made very general because of political requirements in
> getting the .11 group off the ground.  So it's actually possible to
> Do you mean that the same scheduled slot "No 1" (assuming 1000 slots in 1
> superframe) can be configured as "upstream" at time0 and as "broasdcast
> for downstream" at time0+10s?
>
>   
There are 16 cells in slot 0 that can be assigned independently without 
RF collision and without consideration of spatial frequency re-use.  So 
you could have several unicast cells (A --> B) and several broadcast 
cells (Q --> *), and several aloha cells (* --> *), and still have some 
cells left to assign.  All of these cells would fire every 10 seconds in 
a 1000 slot superframe, as you indicated.  But a given cell would not 
change from superframe cycle to superframe cycle.  (note that the actual 
channel used for each cell will hop pseudo-randomly - the cell gives the 
channel offset, not the absolute channel).
> reset the synchronization timer.
>
>
> Can you disable this extra time information for some ack packets?
>
>   
hmm.  Good question.  You can disable the timer for certain paths (if 
you want to enforce regular updates between one pair of motes and not 
another).  But I don't think that you can ignore the time update in the 
ack.  What's the use case?
>
>   
>> For many/most motes in many/all
> be used if it makes more sense energetically than keepalives.
>
>
> Can you have a beacon-enabled ISA100.11a MAC?
> I've read you can assign the communication cells
> centrally/distributed/hybrid. Is this scheduling algorithm defined for
> beacons in low traffic networks? Or is this out of scope of the standard
> spec?
>   
You can certainly distribute time via beacons if you want.  If I don't 
hear your beacon a few times in a row, and my keepalive timer goes off, 
I would still send you a keepalive packet.
The cell scheduling mechanism is out of scope, but assumed to be 
centralized in the first release of both wireless HART and forthcoming 
isa100.
>> For
> channel hop, dramatically reducing the chance of a link between two motes
> "going down" due to external or multi-path interference.
>
>
> Great!
>
>
>
>   
> is where things get interesting with 6LoWPAN and RoLL.  TSMP provides the
> mechanisms to bind layer 4 quality of service to layer 3 routes and layer
> 2 performance/power provisioning.  This is critical in industrial
> :-) The need for an abstraction layer is clear, because some MAC layers do
> not offer slots or synchronization. The routing layer has to know this.
>
> One option is defining a profile or information base that every MAC layer
> (implementer) has to fill in. This profile must describe the MAC
> capabilities (available channels, transmit power, synchronized, slotted,
> slotlength,...).
>
> Someone has already started?
>   
I don't think that anyone has started.  Does that concept of a profile 
violate anything that ietf holds dear?

ksjp

---

From: "Pieter De Mil" <[email-masked]>
Date: Tue, 11 Mar 2008 04:24:07 +0100 (CET)

> ack.  What's the use case?

In a network with a lot of traffic, I can imagine that this time
information in the ack's is not always necessary for the motes to stay
synchronized. It is necessary sometimes, but not for all successive acks.
Disabling this time information  in the ack = saving battery juice.
To keep things simple, it may be OK to keep the time info always in the
ack. I was just wondering if the DLL was *that* flexible :-)

Pieter

---

From: "Miguel Sanchez" <[email-masked]>
Date: Tue, 11 Mar 2008 10:34:11 +0100

> ack. I was just wondering if the DLL was *that* flexible :-)

Please bear in mind that for some radio hardware (802.15.4) the transmission
and reception power consumption is nearly the same, so not transmitting some
bits (the time) only helps if you then can shut off the radio receiver
sooner.

Cheers,

Miguel Sánchez

---

From: "Robert Assimiti" <[email-masked]>
Date: Thu, 13 Mar 2008 11:40:52 -0400

Hello Pieter,

Yes, the DLL is that flexible....and more.

Minimizing battery consumption was one of the primary design constraints
for the DLL.

Time corrections can be accomplished in two ways:

1.  Through ACK 

a.  Time corrections can be enabled/disabled in the ACK

b.  Other fun data can be enabled/disabled in the ACK such as LQI/RSSI
data or the EUI-64 of the receiving device

2.  Through advertisement headers

"The nice thing about standards is that there are so many to choose
from." - Andrew S. Tanenbaum 

Robert Assimiti

Executive Staff Engineer

Office: [678]-202-6859

Mobile: [404]-578-0205

 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pieter De Mil
Sent: Monday, March 10, 2008 11:24 PM
To: Kris Pister
Cc: [email-masked]; [email-masked]
Subject: Re: [6lowpan] Syncronized Wake

 

synchronized. It is necessary sometimes, but not for all successive
acks.

Pieter

6lowpan mailing list

[email-masked]

This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments.
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll