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 protected]>: > 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 > > > > On Wednesday, October 5, 2016 10:54 PM, Xavier Vilajosana < > [email protected]> 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 > > > 2016-10-05 17:27 GMT+02:00 Qin Wang <[email protected]>: > > 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. > > Thanks > Qin > > > On Wednesday, October 5, 2016 11:03 AM, Tero Kivinen <[email protected]> > wrote: > > > Qin Wang writes: > > 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 protected] > > > > > > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > -- Dr. Xavier Vilajosana Guillén Research Professor Wireless Networks Research Group Internet Interdisciplinary Institute (IN3) Universitat Oberta de Catalunya +34 646 633 681| [email protected] | 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)
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
