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 protected] > 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. " > > 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 > > -- _______________________________________ 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 _______________________________________
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
