All, It's tempting to consider coupling the MAC ACK/NAK immediate-response with higher-layer functions. Unfortunately, end-product architectural considerations mandate that this NEVER even be considered.
Many industrial wireless products will have a two-module or three-module structure, where 1) the RF and MAC are integrated into a single chip with some analog support components, such as an RF transmit power amplifier and receiver front-end; 2) the other communication protocol layers are in a separate microcontroller, such as an MSP430-class micro; and 3) the process-related sensor(s) and actuator(s), which are the inputs and outputs that connect to the physical world, such as a valve positioner. Such a product structure permits evolution of the RF subsection as newer communications standards become widely accepted, of the other comm protocol layers as changes occur in the underlying microcontrollers (due largely to smartphone and IIoT), and of reuse of those common designs throughout the product line, mating them with different sensors and actuators, everything from the reasonable-size positioner for a 3 m diameter valve to a very small lick-and-stick corrosion sensor to go on pipes that might be 10 m above the ground. -Tom On 2015.07.02 08:25, Michel Veillette wrote: > > Hi Pascal > > I’m trying to address a different use case I thinks, when the number of > timeslots is limited. This use case is probably more relevant to large scale > NAN networks (e.g. Zigbee NAN). > > > > This use case is as follow. > > > > Let say I have a RPL parent with 100 RPL children with a timeslot of 10 msec. > If I want to assign a dedicated timeslot to each child, 100 timeslots need to > be assigned. This means that a timeslot for uplink traffic will available to > a child only each couple of seconds. The propose approach allows the RPL > parent to reserve soft cells to allocate bandwidth dynamically to some of > these 100 children when needed. > > > > Is this make some sense? > > Is there something already available if the drafts to accommodate this use > case? > > > > cid:[email protected] > > > Michel Veillette > System Architecture Director > > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > [email protected] > > www.trilliantinc.com > > > > > > From: Pascal Thubert (pthubert) [mailto:[email protected]] > Sent: 2 juillet 2015 10:40 > To: Michel Veillette; Qin Wang; Nicola Accettura > Cc: [email protected]; [email protected] > Subject: RE: [6tisch] draft-dujovne-6tisch-on-the-fly-05 > > > > Hello Michel: > > > > We discussed an angle of this on the call of 22 Nov 2013 recording here : > > > > https://bitbucket.org/6tisch/meetings/wiki/131122_webex at 8:13 > > https://bitbucket.org/6tisch/meetings/src/master/131122_webex/slides_131122_webex.ppt > > > > > > In short, if the schedule is rather not busy, we can have more timeSlots per > child than they really need. > > > > In that case, the peer would only listen to the first timeSlot of a sequence > of say 4. If there is no traffic there, the peer would not listen for the > other 3. But if there is traffic, then the sender can indicate whether > there’s more till done, in which case all the timeSlots could be used on that > round. > > > > This avoids negotiation to allocate / deallocate time slots. > > > > Cheers, > > > > Pascal > > > > From: 6tisch [mailto:[email protected]] On Behalf Of Michel Veillette > Sent: mercredi 1 juillet 2015 19:10 > To: Qin Wang; Nicola Accettura > Cc: [email protected]; [email protected] > Subject: Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05 > > > > Hi Qin > > > > Yes, the Frame Pending flag is defined as follow: > > > > IEEE 802.15.4-2006 section 7.2.1.1.3 > > “Frame Pending subfield is 1 bit in length and shall be set to one if the > device sending the frame has more data for the recipient. This subfield shall > be set to zero otherwise” > > > > This feature can be especially useful for the upstream traffic in a RPL > DODAG. In a scenario where a DAG parent have dozens of children, dedicated > timeslot will be infrequent and share timeslots suffer from contention. If a > subset of these children have ongoing traffic, the parent can use the Frame > Pending flag information to schedule temporary soft cells and avoid > contention or speedup transfer. > > > > > > cid:[email protected] > > > Michel Veillette > System Architecture Director > > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > [email protected] > > www.trilliantinc.com > > > > > > From: Qin Wang [mailto:[email protected]] > Sent: 1 juillet 2015 11:28 > To: Nicola Accettura; Michel Veillette > Cc: [email protected]; [email protected] > Subject: Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05 > > > > Hi Michel and Nicola, > > > > I think Michel's idea is interesting. But, according to my understanding, the > Frame Pending setting just means there is frame following, does not mean that > the current bandwidth provided by TSCH schedule, including hard cells and > soft cells, is not enough to convey those frames, and then needs more > bandwidth (e.g. additional soft cells) . Right? Do I miss something? > > > > Thanks > > Qin > > > > > > On Wednesday, July 1, 2015 4:03 AM, Nicola Accettura > <[email protected]> wrote: > > > > Hi Michel, > > your proposal is very interesting. > > However, OTF does not allocate cells directly: it just computes the estimated > number of cells to add or delete into the schedule, and then sends this > information to 6top. 6top is then in charge of negotiating cells among > neighbors, and meybe perform the scheme you are proposing. > > So, your proposal seems fitting more the 6top-to-6top communication. > > Am I missing something? What others think about? > > Sincerely > > Nicola > > > > 2015-06-30 8:13 GMT-07:00 Michel Veillette > <[email protected]>: > > Hi Diego > > > > It’s my first reading of the “6TiSCH On-the-Fly Scheduling” (and I’m not > completely done yet) and I wandering if the concept of on the fly, in a > single exchange, temporary allocation of a soft cell have already been > discussed. For example, a node can use the Frame Pending subfield (IEEE > 802.15.4-2006 section 7.2.1.1.3) to indicate the presence of packets ready to > be transmitted. Based on that knowledge, the target may add an IE in an > enhanced acknowledgment to allocate a temporary soft cell (e.g. single cell). > Each subsequent transmission may further re-allocate a temporary soft cell. > It’s important to note that the default delay for a TSCH Acknowledgment is > 1ms (macTsTxAckDelay) which seem sufficient for the processing of this new IE. > > > > > > > > This scheme is very reactive and may help dealing with non-predictable > communication patterns. > > What do you things? > > > > Michel Veillette > System Architecture Director > > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > [email protected] > > www.trilliantinc.com _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
