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. > > >> 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? > > 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). > > >> * +/- 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? > > 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 >> 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? > 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 >> 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? > I don't think that anyone has started. Does that concept of a profile violate anything that ietf holds dear?
ksjp > Pieter > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
