Hello All,
I would like to present my thoughts purely from the perspective of protocol
conformance and interoperability tests carried out among various IEEE
802.15.4e
implementations. The APIs offered by such an implementation are essentially
going to dictate what service interface it is going to provide to its higher
layers, 6TiSCH happens to be one.
If CCA is not a mandatory functionality that an IEEE 802.15.4e
implementation
MUST have for passing interoperability tests, then it is possible that in a
given implementation either it is disabled or not implemented at all. In the
former case, there may not be an API to enable it! 6TiSCH therefore may
have to
"probe" the configuration attributes using an appropriate IEEE 802.15.4e
API to
know the availability of CCA service attribute configuration.
In summary, 6TiSCH has to work within the the protocol conformance
rules set by IEEE
802.15.4e standard, irrespective of merits and demerits of CCA. Is this
argument
reasonable ?
Anand
On Saturday 19 December 2015 03:25 PM, Pascal Thubert (pthubert) wrote:
> Hello Kris: > > > > I certainly buy your arguments, which fit the
intuition of the network operation. > > > > There are two additional
angles that may influence this proposition, though, both relating to
uses cases that minimal enables and that are a lot less engineered than
the art TSCH: > > > > - One is a case where more than one minimal
6TiSCH network are deployed in one interference domain. The networks may
not be coordinated and they may not be synchronized. Say they are
dimensioned for their own traffic but not for necessarily twice that
traffic. If they both operate around the default of 100 slots per
slotframe, the chances of contact are very low. Yet theres this roughly
1/1000 chance that the end up on a same channel at a shifted time, and
if the slot duration is the same, the collision becomes systematic. In
that case both networks may experience degradation. CCA may still help
that case just like it may help coexistence with other types of
networks. If we do CCA, only the network which is slightly lagging will
experience bad performances, which is half of the way. It may make sense
to provide recommendations for that sort of case, like, if there is a
minimum of coordinated configuration available, then at least do not use
slotframes of equal length and if possible make them prime to one
another to avoid systematic collisions. > > > > - The other is
longer sleep and higher drifts. Would it be possible that because the
minimal devices experience more asynchronous / statistical traffic,
there may be a wider distribution of interval between frames and thus of
time drifts? If so, wouldnt it be possible that 2 devices are
desynchronized enough that one starts emitting while the other is still
sensing the channel, in which case CCA would protect the first come? > >
> > > > Also, CCA simplifies the compliance with regulation in Europe
and countries that follow the same regulations. > > > > Im hearing
though that 200328 2.0 will be more open to channel hoppers. Ill try to
get the exact wording but I understand that you can be a channel hopper
if you hop between 5 channels as opposed to 15 as before. So CCA may be
less critical there as it was before. > > > > All in all, I do not see a
strong case for CCA, but incremental benefits. I also sense some push
back against it but I have less understanding of where that comes from.
Is that an battery drain problem? Is that a matter of complexity? > > >
> Thanks for all this, > > Pascal > > > > From: Kris Pister
[mailto:[email protected]] > Sent: vendredi 18 décembre 2015 19:36 > To:
Pascal Thubert (pthubert) <[email protected]> > Cc: 6tisch
<[email protected]>; [email protected] > Subject: Re:
[6tisch] #40 (minimal): Ralph's INT AREA review on minimal > > > >
Pascal - > CCA can be a useful feature in a TSCH network. It is
certainly useful if the EU standards > prevent you from selling your
devices without it. It doesn't provide much benefit for > the purpose
that you describe below however. > > Most motes in a TSCH network will
the synchronized to a small fraction of the guard > time (+/- 1 ms
default for minimal). That's just simple statistics - if six sigma of
the > synchronization error distribution is approach the guard time,
then you're already > in deep trouble with motes falling out of the
network. > > Published academic networks routinely run with a few tens
of microseconds of > synchronization error. Commercial networks can be
below one microsecond RMS. > In general, synchronization improves with
increasing network traffic, as the motes > get updates more frequently.
> > Compare these numbers to the RX-to-TX turnaround time specified in
the 15.4 standard, > which is 192 microseconds. If I'm supposed to
start transmitting at time T0, I need > to *end* my CCA RX of the
channel something like 192 microseconds before T0. But > everyone who
might collide with my transmission is also planning to transmit at >
time TO. As described above, they will probably succeed with an error
of a few > microseconds, to possibly tens of microseconds. Result: I
won't hear them. > > 192 microseconds is the upper bound given in the
standard, and most radios are > faster. But even so CCA is just not
going to help you very often. It may be useful > to detect WiFi or
other interferers, but it won't detect other motes in your > network
contending for the same slot. > > ksjp > > On 12/18/2015 8:55 AM, Pascal
Thubert (pthubert) wrote: > > Hello Xavi: > > Point is, we are
doing statistical multiplexing in the minimal time slots. If a node
starts talking, the others should yield. > > The draft says that CCA
is optional; this is not a very strong language. Shouldnt we encourage
it a bit more loudly? > > > > Cheers, > > > > Pascal > > > >
From: [email protected] [mailto:[email protected]] On Behalf Of
Xavier Vilajosana > Sent: vendredi 18 décembre 2015 17:47 > To:
[email protected] > Cc: Pascal Thubert (pthubert)
<[email protected]>; Tero Kivinen <[email protected]>; Ralph Droms
(rdroms) <[email protected]>; Kris Pister <[email protected]>; 6tisch
<[email protected]>; Simon Jonathan <[email protected]>;
[email protected] > Subject: Re: [6tisch] #40
(minimal): Ralph's INT AREA review on minimal > > > > As Jonathan
said in a previous thread. CCA is optional and does not bring a big
advantage as nodes are synchronized and communication occurs at the same
time and hence CCA does not bring a lot. Maybe to get some benefit in
duty cycle regulation due to LBT and maybe to avoid some external
interference. But at the end the behaviour in shared slots is slotted
aloha if this CCA option is not used. > > > > regards, > > Xavi
> > > > > > 2015-12-18 17:00 GMT+01:00
[email protected] <[email protected]>:
> > Youre correct, they are very similar so no need to change.
> > > > Pat > > > > On 18, Dec2015, at 8:57, Pascal
Thubert (pthubert) <[email protected]> wrote: > > > > Hello
Pat: > > > > Actually, I provisionally wrote the following in
last call text for the abstract: > > > > > This document
describes a minimal mode of operation for a 6TiSCH > > >
Network, to provide IPv6 connectivity over a Non-Broadcast > > >
Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4 Time slotted
Channel Hopping (TSCH) links. > > > This minimal mode uses a
collection of protocols including the 6LoWPAN > > > framework
and RPL to enable shared access operations over a static > > >
TSCH schedule. > > > > > > Note that Ralph had an issue with the
beginning of the sentence which now mentions a collection of
protocols . > > > > Otherwise, the last call text seems to be
very similar to your proposal. Would you suggest to change the above
abstract or is it OK as is? > > > > Pascal > > > > From:
[email protected]
[mailto:[email protected]] > Sent: vendredi 18
décembre 2015 15:41 > To: Pascal Thubert (pthubert)
<[email protected]> > Cc: Simon Jonathan <[email protected]>;
Qin Wang <[email protected]>; Xavier Vilajosana
<[email protected]>; Tero Kivinen <[email protected]>; Ralph
Droms (rdroms) <[email protected]>; Kris Pister <[email protected]>;
[email protected]; 6tisch <[email protected]>
> Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review
on minimal > > > > We could change the sentence to : This
minimal mode leverages 6LoWPAN and RPL to enable communication links
over a static TSCH schedule via shared time-slots. > > > > Pat >
> > > > > On 18, Dec2015, at 8:25, Pascal Thubert (pthubert)
<[email protected]> wrote: > > > > We need to reach consensus
on this; > > > > With minimal, we are using a time slotted
medium with shared access. And we want to do cca to avoid collisions,
dont we? If thats so, then even if the MAC has that optional, minimal
needs it. > > Should we call this TDMA? For some people
(including Wikipedia and yours truly), TDMA is about exclusive access to
time slots. Which will be the case of the slots that are assigned by the
6P protocol between parent and child, but is not the case of the minimal
draft. I agree that because we do cca, we are not aloha stricto sensu
either. > > > > What we are doing extends slotted-aloha to
make it polite . In a way that makes minimal compliant with ETSI, since
politeness is what the regulation is all about. > > > > Will we
agree if we replace slotted-aloha by polite slotted-aloha or a
polite form of slotted-aloha ? > > > > Cheers, > > > >
Pascal > > > > From: Jonathan Simon [mailto:[email protected]]
> Sent: mardi 15 décembre 2015 01:28 > To:
[email protected] > Cc: Qin Wang
<[email protected]>; Pascal Thubert (pthubert) <[email protected]>;
Xavier Vilajosana <[email protected]>; Tero Kivinen
<[email protected]>; Ralph Droms (rdroms) <[email protected]>; Kris Pister
<[email protected]>; [email protected]; 6tisch
<[email protected]> > Subject: Re: [6tisch] #40 (minimal): Ralph's
INT AREA review on minimal > > > > Pat - Carrier sense (via CCA)
is an option in TSCH, so it can be used where appropriate (e.g. for
coexistence), but isn't required in general as part of the media access
scheme, again because it may not be useable in a tightly synchronized
network. > > > > Jonathan > > > > On Mon, Dec 14, 2015
at 4:18 PM, [email protected]
<[email protected]> wrote: > > I made an
error in my earlier email, although shared slots do not require carrier
sense, it is really recommended. In most 15.4 modes (but not TSCH) when
a device wishes to use a shared medium, the devices use CSMA to avoid
collisions. Also, devices compliant to ETSI 300-328 must use carrier
sense for LBT (802.15.4s CSMA is cited in that regulation) > > >
> Pat > > > > On 12, Dec2015, at 16:29,
Jonathan Simon <[email protected]> wrote: > > > > Pat -
unless something was changed in 802.15.4-2015, that was not how the
original TSCH shared slots worked. Devices don't do carrier sense,
since transmissions are synchronized and talk at the same time (within
sync tolerances) - they do however back off using a similar backoff
mechanism, but counted in shared slots as opposed to time, to avoid
persistent collision. I think that's what "slotted Aloha" is supposed
to mean here - a slotted shared medium without carrier sense. > > >
> Jonathan > > > > On Sat, Dec 12, 2015 at 4:57
AM, Pat Kinney <[email protected]> wrote: >
> Hi Qin; > > A shared slot is open
for all devices. To transmit on this timeslot a device shall sense the
medium for activity, if active it shall wait for the next available time
slot. Hence a shared slot is a contention access period for CSMA-CA.
This isn't slotted aloha, since it senses the medium first. >
> Pat > > > Patrick Kinney >
> Kinney Consulting > > +1.847.960.3715
> > [email protected] > >
> On Dec 11, 2015, at 5:06 PM, Qin Wang
<[email protected]> wrote: > > Hi Pat, > > >
> According to my understanding, in the TSCH mode
of 802.15.4, if the attribute of a slot is Shared, slotted- aloha access
should be allowed in the slot. Right? > > > > Thanks
> > Qin > > > > > > On Friday,
December 11, 2015 2:29 PM, "[email protected]"
<[email protected]> wrote: > > > >
Xavi; > > > > As I understand slotted-aloha, TSCH is
really Time Division Multiple Access (TDMA), not slotted-aloha.
Slotted-aloha access to the medium is used in the 802.15.4 CSMA
algorithms for some modes but not TSCH. > > > > Pat
> > > > On 11, Dec2015, at 11:24, Xavier Vilajosana
<[email protected]> wrote: > > > > Dear
all, > > > > I wrapped up the proposed changes and
integrated them to the version in bitbucket. > >
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal/commits/28cb63fde078a0aec8307d416e82cdf482c0608a
> > > > For simplicity, see here a summary of the
changes. > > > > > > Abstract: > > >
> [OLD] > > > > This document
describes the minimal set of rules to operate an IEEE >
> 802.15.4 Timeslotted Channel Hopping (TSCH)
network. This minimal > > mode of operation can
be used during network bootstrap, as a fall- > >
back mode of operation when no dynamic scheduling solution is >
> available or functioning, or during early
interoperability testing > > and development. > >
> > [NEW] > > > > This document
describes a minimal mode of operation for a 6TiSCH >
> Network, to provide IPv6 connectivity over a
Non-Broadcast Multi- > > Access (NBMA) mesh that
is formed of IEEE 802.15.4 Timeslotted > >
Channel Hopping (TSCH) links. This minimal mode leverages 6LoWPAN >
> and RPL to enable slotted-aloha operations
over a static TSCH > > schedule. > > > > >
> Introduction: > > > > [OLD] >
> > > The nodes in a IEEE 802.15.4 TSCH network
follow a communication > > schedule. The entity
(centralized or decentralized) responsible for >
> building and maintaining that schedule has
precise control over the > > trade-off between
the network's latency, bandwidth, reliability and >
> power consumption. During early
interoperability testing and > > development,
however, simplicity is more important than efficiency. >
> One goal of this document is to define the
simplest set of rules for > > building a
TSCH-compliant network, at the necessary price of lesser >
> efficiency. Yet, this minimal mode of
operation MAY also be used > > during network
bootstrap before any schedule is installed into the >
> network so nodes can self-organize and the
management and > > configuration information be
distributed. In addition, the minimal > >
configuration MAY be used as a fall-back mode of operation, ensuring >
> connectivity of nodes in case that dynamic
scheduling mechanisms fail > > or are not
available. The IEEE 802.15.4 specification provides a >
> mechanism whereby the details of slotframe
length, timeslot timing, > > and channel hopping
pattern are communicated when a node time > >
synchronizes to the network [IEEE802154]. This document describes >
> specific settings for these parameters. > > >
> [NEW] > > > > A 6TiSCH
Network provides IPv6 connectivity over a Non-Broadcast >
> Multi-Access (NBMA) mesh that is formed of
IEEE 802.15.4 Timeslotted > > Channel Hopping
(TSCH) links. > > > > The 6TiSCH
[I-D.ietf-6tisch-architecture] architecture requires the >
> use of both RPL and the 6LoWPAN adaptation
layer framework > > ([RFC4944], [RFC6282]) as
defined over IEEE 802.14.5. 6LoWPAN > > Neighbor
Discovery [RFC6775] (ND) is also required to exchange >
> Compression Contexts, form IPv6 addresses and
register them for the > > purpose of Duplicate
Address Detection, Address Resolution and > >
Neighbor Unreachability detection over one TSCH link. In order to >
> reduce the header overhead of the RPL
artifacts in data packets, the > > Routing header
[RFC6554], the RPL Option [RFC6553] and the related IP >
> in IP encapsulation MUST be encoded as
prescribed in > > [I-D.ietf-6lo-routing-dispatch]
> > > > Nodes in a IEEE 802.15.4 TSCH network
follow a communication > > schedule. A network
using the simple mode of operation uses a static >
> schedule. > > > > This
specification defines a Minimal Configuration to build a 6TiSCH >
> Network, using the Routing Protocol for LLNs
(RPL) and a static TSCH > > Schedule. The
802.15.4 TSCH mode, RPL [RFC6550], and its Objective >
> Function 0 (OF0) [RFC6552], are used
unmodified, but parameters and > > particular
operations are specified to guarantee interoperability >
> between nodes in a 6TiSCH Network. > > >
> More advanced work is expected in the future
to complement the > > Minimal Configuration with
dynamic operations that can adapt the > >
Schedule to the needs of the traffic in run time. > > > > >
> Section 11.2 > > > > [OLD] >
> > > In addition to the Objective Function (OF),
nodes in a multihop > > network using RPL MUST
indicate the preferred mode of operation using >
> the MOP field in DIO. Nodes not being able to
operate in the > > specified mode of operation
MUST only join as leaf nodes. RPL > >
information and hop-by-hop extension headers MUST follow [RFC6553] >
> and [RFC6554] specification. In the case that
the packets formed at > > the LLN need to cross
through intermediate routers, these MUST follow >
> the IP in IP encapsulation requirement
specified by the [RFC6282] and > > [RFC2460].
RPI and RH3 extension headers and inner IP headers MUST >
> be compressed according to [RFC6282]. > > >
> [NEW] > > > > In addition to
the Objective Function (OF), nodes in a multihop >
> network using RPL MUST indicate the preferred
mode of operation using > > the MOP field in
DIO. Nodes not being able to operate in the > >
specified mode of operation MUST only join as leaf nodes. RPL >
> information and hop-by-hop extension headers
MUST follow [RFC6553] > > and [RFC6554]
specification. In the case that the packets formed at >
> the LLN need to cross through intermediate
routers, these MUST follow > > the IP in IP
encapsulation requirement specified by the [RFC6282] and >
> [RFC2460]. RPI and RH3 extension headers and
inner IP headers MUST > > be compressed according
to [RFC6282] and [I-D.ietf-6lo-routing-dispatch]. > > > > >
> have a nice weekend, > > Xavi
> > > > 2015-12-11 17:49 GMT+01:00 Kris Pister
<[email protected]>: > > Ralph - to my knowledge
no one has deployed the specific time-parent >
selection scheme described in 802.15.4-*. The basic scheme will likely
work, > but the devil will be in the real-world
details. > > We've had about 8 years of
successful deployments of industrial tsch mesh >
networks using a time-parent selection scheme similar to what is
proposed > in minimal. >
> 6TiSCH present a rich design space at many
levels. The goal of minimal was > to do
something simple, based as closely as possible on things that are
> known to work in deployed networks. The hope
and belief is that new and > better ideas will
emerge, but it is certain that many of the proposed "good
> ideas" will fail. By defining minimal we
provide a reliable interoperable > platform on
which papers like "Comparing time-parent selection in 15.4-*
> and foo" can be written. >
> ksjp > > On
12/10/2015 5:43 AM, Ralph Droms (rdroms) wrote: >
> Is there an analysis published somewhere
that demonstrates how time synchronization in 802.15.4-* is inadequate
for 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 > >
> > > >
_______________________________________________ >
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 > > > > > > > > > > >
> -- > > Jonathan Simon > Linear Technology,
Dust Networks product group > 32990 Alvarado-Niles Road, Suite
910 > Union City, CA 94587 > (510) 400-2936 >
(510) 489-3799 FAX > [email protected] > > > >
******************LINEAR TECHNOLOGY CORPORATION
CONFIDENTIAL****************** > > This e-mail transmission, and
any documents, files or previous e-mail messages attached to it may
contain confidential information that is legally privileged. If you are
not the intended recipient, or person responsible for delivering it to
the intended recipient, you are hereby notified that any disclosure,
copying, distribution or use of any of the information contained in or
attached to this transmission is STRICTLY PROHIBITED. If you have
received this transmission in error, please immediately notify me by
reply email or by telephone at 510-400-2936 and delete the original
transmission and its attachments without reading or saving in any
manner. Thank you. > > > >
_______________________________________________ > 6tisch mailing
list > [email protected] >
https://www.ietf.org/mailman/listinfo/6tisch > > > > > > > > >
_______________________________________________ > 6tisch mailing list >
[email protected] > https://www.ietf.org/mailman/listinfo/6tisch
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
