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 >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pieter De Mil >Sent: lundi 10 mars 2008 01:25 >To: Kris Pister >Cc: [email protected] >Subject: Re: [6lowpan] Syncronized Wake > > Hi Kris, All; > >Thanks for the info, the ISA100.11a MAC seems to be a very flexible MAC >layer. >Some questions inline. > >> 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. > > >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? > > > >> * +/- 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. > > >Can you disable this extra time information for some ack packets? > > > >> 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. > > >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 >> 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. > > >Great! > > > >> * 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 :) > > >:-) 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 > >> >> 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 PROTECTED]> >>> To: "Colin O'Flynn" <[EMAIL PROTECTED]>; <[email protected]> >>> 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 PROTECTED] >>> -----Original Message----- >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >Behalf >>> Of Colin O'Flynn >>> Sent: Sunday, March 02, 2008 9:21 AM >>> To: [email protected] >>> 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 protected] >>> 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 protected] >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> _______________________________________________ >>> 6lowpan mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/6lowpan >> > > > > >_______________________________________________ >6lowpan mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
