Subject: [6tisch] Link Options bitmap in 6P Cell format

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 5 Oct 2016 15:40:46 +0200

Hi,

following an action item from the previous call I want to propose the use
of the Link Options bitmap in the 6P Cell format. This extra byte per
requested cell will be useful to support the allocation of both TX and RX
cells from the origin of the transaction perspective as well as to enable
6top to schedule shared cells.

Note that this format is not mandatory but recommended in the current
draft.

what is your opinion?

regards,
Xavi

---

From: Qin Wang <[email-masked]>
Date: Wed, 5 Oct 2016 14:45:42 +0000 (UTC)

Hi Xavi,
In IEEE802.15.4e, LinkOptions is defined as follows.

Is it what you are going to use? Then, another way is to use two bits to express TX/RX/Share. I'm not sure which way is better than another.
ThanksQin

    On Wednesday, October 5, 2016 9:40 AM, Xavier Vilajosana <[email-masked]> wrote:

 Hi,
following an action item from the previous call I want to propose the use of the Link Options bitmap in the 6P Cell format. This extra byte per requested cell will be useful to support the allocation of both TX and RX cells from the origin of the transaction perspective as well as to enable 6top to schedule shared cells. 
Note that this format is not mandatory but recommended in the current draft. 
what is your opinion?
regards,
Xavi
_______________________________________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 5 Oct 2016 18:02:56 +0300

> In IEEE802.15.4e, LinkOptions is defined as follows.

This was changed in the 802.15.4-2015, i.e., the MLME and he PIB no
longer specify bit numbers for those infrmation, they provide the same
information in separate parameters (TxLink, RxLink, SharedLink,
TimekeepngLink, PriorityLink), or spearate PIB entries (macTxType,
macRxType, macLinkTimekeeping and macPriorityType).

The TSCH Slotframe and Link IE do define field called Link Options and
splits it to bits as follows:

+---------+---------+-------------+-------------+----------+----------+
| Bits: 0 |     1   |      2      |      3      |     4    |   5-7    |
+---------+---------+-------------+-------------+----------+----------+
| TX Link | RX Link | Shared Link | Timekeeping | Priority | Reserved |
+---------+---------+-------------+-------------+----------+----------+
		Figure 7-54 --Link Options field format

Note, that there is new bit for Priority in there too. And as normally
this is LSB first so care should be taken when written to the IETF
draft... 

> Is it what you are going to use? Then, another way is to use two bits to
> express TX/RX/Share. I'm not sure which way is better than another.

Two bits is not enough to define all different link types. The text in
802.15.4-2015 defining the bits is:

	The TX Link field shall be set to one if it is a TX link and
	shall be set to zero otherwise.

	TX Shared links, indicated by the TX link field and Shared
	Link field both set to one, may be used by a joining device to
	send an Association Request command or higher layer message to
	the advertising device.

	The RX Link field shall be set to one if the link is an RX
	link and shall be set to zero otherwise. RX links are used by
	a joining device to receive an Association Response command or
	higher layer message from an advertising device.

	The Shared Link field shall be set to one if the link is a
	shared link and shall be set to zero otherwise. A shared link
	is one that uses contention to access the medium.

	A link may be used as both a TX shared link and RX link.

	The Timekeeping field shall be set to one if the link is to be
	used for clock synchronization and shall be set to zero
	otherwise. RX links shall have the Timekeeping field set to
	one.

	The Priority field shall be set to one if the link is a
	priority channel access, as defined in 6.2.5.2, and shall be
	set to zero otherwise.
-- 
[email-masked]

---

From: Qin Wang <[email-masked]>
Date: Wed, 5 Oct 2016 15:27:54 +0000 (UTC)

Hi Tero,
Thank you for the update. 
According to my understanding, the flag used in 6P is trying to define the communication direction of scheduled cell(s). So, I wonder if 2 bits flag is enough.
ThanksQin  

    On Wednesday, October 5, 2016 11:03 AM, Tero Kivinen <[email-masked]> wrote:

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 6 Oct 2016 04:54:44 +0200

Hi Qin,

the LinkOptions makes it more flexible for future uses (as it opens more
options). I see the priority field for example also interesting.

I agree however that we use 5-extra bits per requested cell and that the
timekeeping and priority fields are not in the scope as of today. Maybe
even 8 if we leave some reserved bits as 15.4.

thoughts?
X

2016-10-05 17:27 GMT+02:00 Qin Wang <[email-masked]>:

> According to my understanding, the flag used in 6P is trying to define the
> communication direction of scheduled cell(s). So, I wonder if 2 bits flag
> is enough.
>
> Thanks
> Qin
>
>

---

From: Qin Wang <[email-masked]>
Date: Thu, 6 Oct 2016 15:06:36 +0000 (UTC)

Xavi,
I agree LinkOptions-like field will bring more flexibility. (I say LinkOptiions-like field because IEEE802.15.4e does not has the LinkOptions anymore as Tero mentioned.)
I have a further question. Does it mean the LinkOption-like flag will associated with a cell, instead of a transaction? In another word, the LinkOptions-like flag will be part of 6P Cell Format with slotOffset and channelOffset. 
ThanksQin

    On Wednesday, October 5, 2016 10:54 PM, Xavier Vilajosana <[email-masked]> wrote:

 Hi Qin,
the LinkOptions makes it more flexible for future uses (as it opens more options). I see the priority field for example also interesting.
I agree however that we use 5-extra bits per requested cell and that the timekeeping and priority fields are not in the scope as of today. Maybe even 8 if we leave some reserved bits as 15.4.
thoughts?X

Hi Tero,

+---------+---------+--------- ----+-------------+----------+ ----------+
| Bits: 0 |    1  |      2      |      3      |    4    |  5-7    |
+---------+---------+--------- ----+-------------+----------+ ----------+
| TX Link | RX Link | Shared Link | Timekeeping | Priority | Reserved |
+---------+---------+--------- ----+-------------+----------+ ----------+
        Figure 7-54 --Link Options field format

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Thu, 6 Oct 2016 21:36:33 +0200

Dear Qin,
answering to this:

"Does it mean the LinkOption-like flag will associated with a cell, instead
of a transaction? In another word, the LinkOptions-like flag will be part
of 6P Cell Format with slotOffset and channelOffset. "

XV> this is something we can decide. We either bind it to thel 6P Cell
Format with slotOffset and channelOffset., hence using 1 extra byte for
each cell or we associate the linkOption to the whole list of cells
(assuming that all the requested cells will have the same "options"). This
will safe bytes at the cost of less flexibility.

what is your opinion here?
X

2016-10-06 17:06 GMT+02:00 Qin Wang <[email-masked]>:

> Xavi,
>
> I agree LinkOptions-like field will bring more flexibility. (I say
> LinkOptiions-like field because IEEE802.15.4e does not has the LinkOptions
> anymore as Tero mentioned.)
>
> I have a further question. Does it mean the LinkOption-like flag will
> associated with a cell, instead of a transaction? In another word, the
> LinkOptions-like flag will be part of 6P Cell Format with slotOffset and
> channelOffset.
>
> Thanks
> Qin
>
>
>

-- 
Dr. Xavier Vilajosana Guillén
Research Professor
Wireless Networks Research Group
Internet Interdisciplinary Institute (IN3)
Universitat Oberta de Catalunya

+34 646 633 681| [email-masked] | Skype: xvilajosana
http://xvilajosana.org
http://wine.rdi.uoc.edu/

Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 5. Edifici B3
08860 Castelldefels (Barcelona)

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 7 Oct 2016 15:12:43 +0200

All,

I have captured this discussion at
https://trac.tools.ietf.org/wg/6tisch/trac/ticket/46, and am preparing a
summary slide for the interim meeting. Let's discuss there an conclude.

Thomas

On Thu, Oct 6, 2016 at 9:36 PM, Xavi Vilajosana Guillen <[email-masked]
> wrote:

> Dear Qin,
> answering to this:
>
> "Does it mean the LinkOption-like flag will associated with a cell,
> instead of a transaction? In another word, the LinkOptions-like flag will
> be part of 6P Cell Format with slotOffset and channelOffset. "
>
>> According to my understanding, the flag used in 6P is trying to define
>> the communication direction of scheduled cell(s). So, I wonder if 2 bits
>> flag is enough.
>>
>> Thanks
>> Qin
>>
>>

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________