Hi Michel,
It has been a long time since we worked together.
With respect to your question, there are really two issues here:
1)
Q: Should IEs be used for purposes above the MAC subayer of the
Data-link layer?
A: There's been a lot of discussion of conveying TSCH and
higher-sublayer functionality in IEs. From a layering perspective, there
is no problem with that provided that the information is from or for the
same layer, which I interpret as the entire Data-link layer.
It's a different issue if one considers carrying Network-layer or
Transport-layer or Application-layer information; doing that introduces
inter-layer coupling that reduces the compartmentalization and utility
of the mix-and-match layering concept.
In summary, using IEs to convey intra-layer information is acceptable;
using IEs to convey inter-layer information is not, as it means that the
higher layer implementation is dependent on being mated to a specific
lower layer and can't be readily supported by other lower layers (e.g.,
Ethernet or WiFi).
2)
Q: Can an IE in an ACK frame be used to convey a response to the
immediately-preceding same-slot Data frame, and if so what are the
limits on the information that can be included in the ACK frame's IE?
A: It is possible for an IE in an ACK frame to convey a response to the
immediately-preceding same-slot Data frame, provided that
i) the ACK frame that contains the IE does not exceed the airtime
reserved for that ACK within the slot, and
ii) the IE can be generated from information available to the MAC before
or during MAC-level processing of the same-slot Data frame that triggers
the ACK.
What this means in the hypothetical three-component implementation,
where the RF and MAC are combined but the higher layers are in a
separate microcontroller that uses some form of inter-CPU communication,
is that it is not permissible to receive information in the Data frame,
hand it off to the second microcontroller, then demand that the second
microcontroller respond in time for the MAC to generate the required
same-slot ACK.
Don't make the mistake of analyzing this in terms of microseconds at a
given data rate; the architectural solution needs to work if the
date-rates are scaled up to 60 GHZ optical communications and
multi-Mbit/s bandwidth.
I've been through these issue repeatedly, starting with the initial
technical meeting of IEEE 802 in early 1980, even as what is now the OSI
Basic Reference Model was being created by Charlie Bachman, a colleague
of mine in Honeywell (for which he was later rapporteur). In the decades
since, I've gone through this analysis repeatedly. It always comes out
the same: an intimate timing-dependent coupling of layers forecloses too
many future options and evolutionary paths.
Just my opinion, of course,
-Tom
=====
On 2015.07.02 10:15, Michel Veillette wrote:
Hi Tom, long time no see
I'm assume that your answer to my question "Is there something already
available if the drafts to accommodate this use case?" is no.
You seem to imply that IEs within Enhanced acknowledgment can be used
only by the MAC layer, is it the case? The only relevant text I can
find in IEEE 802.15.4e on this subject is:
4.5.4.3 Frame acknowledgment
The receiving device may insert additional content in an enhanced
acknowledgment encapsulated as IEs. If
the originator does not understand the IE content of the
acknowledgment, it is ignored, but the transmission is considered
successful.
Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-375-0556 ext. 237
[email protected]
www.trilliantinc.com
-----Original Message-----
From: 6tisch [mailto:[email protected]] On Behalf Of Tom Phinney
Sent: 2 juillet 2015 12:46
To: [email protected]
Subject: Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05
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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
