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 > > 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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
