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
