Subject: [6lowpan] Syncronized Wake

From: Colin O'Flynn <[email-masked]>
Date: Sun, 02 Mar 2008 10:21:10 -0400

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

---

From: Kris Pister <[email-masked]>
Date: Mon, 03 Mar 2008 20:17:51 -0800

Colin - there are basically 3 camps:
 * 15.4 beacons
 * some flavor of preamble sampling
 * time synchronized, e.g. SCP, Dozer, and TSMP

If you wanted to do something really useful, you'd find an abstraction 
of their layer-two features and limitations that makes it easy for 
layer-3 and up to do useful things with them.

ksjp

---

From: "Robert Assimiti" <[email-masked]>
Date: Thu, 6 Mar 2008 16:17:00 -0500

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,

Warm Regards,

 -Colin O'Flynn

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

---

From: "Pieter De Mil" <[email-masked]>
Date: Thu, 6 Mar 2008 22:53:00 +0100

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.

"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,

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

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

---

From: Colin O'Flynn <[email-masked]>
Date: Thu, 06 Mar 2008 18:56:44 -0400

Hello,

> Let me know if you are interested in more details.

Definitely! Let me know more details...

Thanks,

 -Colin

---

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

---

From: "Pieter De Mil" <[email-masked]>
Date: Mon, 10 Mar 2008 01:24:51 +0100 (CET)

Hi Kris, All;

Thanks for the info, the ISA100.11a MAC seems to be a very flexible MAC
layer.
Some questions inline.

> 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.

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?

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.

Can you disable this extra time information for some ack packets?

> For many/most motes in many/all
and beyond normal data traffic.  For low traffic networks, beaconing may
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?

> For
> 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.

Great!

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 :)

:-) 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?

Pieter

seconds?
>> How are your sync. messages scheduled? Via a distributed assignment? Do
you use CSMA/CA in a time slot?
>> The currently undergoing ISA100.11a standardization effort would be the
perfect paradigm for what you are trying to accomplish. It is a
standard
>> being considered), the Field Devices (FFD/RFDs in 802.15.4 semantics)
communicate during strictly enforced "time slots" without using
beacons.
still
>> I don't want to do GTS though, as nodes can talk at any time. But I
need
>> a
>> So the question: would their be a standards-compliant way to do this?
Or
>> is
>> distributing or taking any action in reliance on the contents of this
information is strictly prohibited. No employee is authorized to
conclude

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Mar 2008 10:32:35 +0100

Hi Pieter:

Actually the novelty happens in the Data Link Layer (DLL), and it is,
indeed, extremely flexible by design. To the point that some additional
documentation can be very welcome to use the DLL implement specific
requirements...

Pascal

>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pieter De Mil
>Sent: lundi 10 mars 2008 01:25
>To: Kris Pister
>Cc: [email-masked]
in
>channel hop, dramatically reducing the chance of a link between two
motes
>is where things get interesting with 6LoWPAN and RoLL.  TSMP provides
the
>>> How are your sync. messages scheduled? Via a distributed assignment?
Do
>>> Currently employing the 802.15.4 PHY/MAC (although alternate
PHY/MACs
>are
>>> First a quick question - I found this list on the IETF site. I
assume
>it's a
>>> know, and will be listening at that time. But any node can TX at
almost
>any
>>> PS: If you are interested: hardware is 8-bit AVR devices, using uIP
for
>IPv6
>>> in error, please reply to advise us immediately, delete it and
destroy
>any
>>> we have taken reasonable precautions to ensure no viruses are
present
>in

---

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

responses inline

> Thanks for the info, the ISA100.11a MAC seems to be a very flexible MAC
There is some concern about it being too flexible :)
> 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).
> 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?
> beacons in low traffic networks? Or is this out of scope of the standard
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.
> 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: Colin O'Flynn <[email-masked]>
Date: Mon, 10 Mar 2008 19:25:43 -0300

Hi,

> There is some concern about it being too flexible :)

I could see where that comes from. One presentation I found included lines 
such as:

"Address needs of users ranging from unsophisticated to networking experts"

"interoperability of ISA100 devices"..."Standardize the necessary interfaces 
while leaving other aspects for vendor customization"

Which - well it sounds good, but really too good for me to trust ;-)

However the ISA100 looks like it could be quite useful, from what I can read 
of it. However is the ISA100.11a around somewhere? I couldn't seem to find 
the actual spec, and the link to 'Join Now' says that "As a token of your 
support, you are requested to make a one time financial donation of $10,000 
to ISA.". A bit rich perhaps for me...

Thanks!

 -Colin

> > :-) The need for an abstraction layer is clear, because some MAC layers
> > : do
> >

---

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: "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]