Subject: [6tsch] set DAGRank to Join Priority

From: Qin Wang <[email-masked]>
Date: Sat, 28 Sep 2013 01:30:59 +0800

Hi Thomas,

I think with OF0 the DAGRank is uint8. But, in the Table 52b of
IEEE802.15.4e, the range of Join Priority is 0x00~0x3f. If the range is a
"MUST", we have to have a function mapping a DAGRank in 0x00~0xff to a
JoinPriority in 0x00~0x3f. Correct?

Would you please confirm with some expertise in IEEE802.15.4e if the range
0x00~0x3f is a MUST or not?

Thanks
Qin

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Fri, 27 Sep 2013 11:30:23 -0700

Hi Qin,

after thinking a little bit on that maybe we can use the higher byte of the
rank for that. that is  rank>>8, the higher byte is a monotonically
increasing counter. As each hop is <<8 (due to minhopRankIncrease) we can
have the sense of higher join priority as higher the rank.

In addition having if we have the limitation of 0x3F, this means that we
will support Join priorities up to 0x3F that translated to ranks are
0x3F<<8 (big number) ..

just thoughts...
X

On Fri, Sep 27, 2013 at 10:30 AM, Qin Wang <[email-masked]> wrote:

> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

---

From: Qin Wang <[email-masked]>
Date: Sat, 28 Sep 2013 04:44:23 +0800

Xavi,

Let's take the example in your draft to see what the problem is. Please
point out if I'm wrong.
+-------+
     |   0   | R(0)=0
     |       | DAGRank(R(0)) = 0
     +-------+
         |
         |
     +-------+
     |   1   | R(1)=R(0)+683=683
     |       | DAGRank(R(1)) = 2
     +-------+
         |
         |
     +-------+
     |   2   | R(2)=R(1)+683=1366
     |       | DAGRank(R(2)) = 5
     +-------+
         |
         |
     +-------+
     |   3   | R(3)=R(2)+683=2049
     |       | DAGRank(R(3)) = 8
     +-------+
         |
         |
     +-------+
     |   4   | R(4)=R(3)+683=2732
     |       | DAGRank(R(4)) = 10
     +-------+
         |
         |
     +-------+
     |   5   | R(5)=R(4)+683=3415
     |       | DAGRank(R(5)) = 13
     +-------+

>From the example, you can see R(n) is a 2-byte integer, and DAGRank is
always the higher byte of the 2byte integer, because minHopRankIncrease =
256.

If set JoinPriority = DAGRank, then it is possible JoinPriority> 0x3f
(although it unlikely happens often), out of its range.
If set JoinPriority[5:0] = DAGRank[7:2], (Is it your suggestion?), a new
node may found many existing nodes with same JoinPriority in received EB.
In another word, the JoinPriority can not provide information about
preferring joining. Right?

I haven't had good solution for it. So, I hope the range 0x00~0x3f is not a
"MUST" in IEEE802.15.4e.

What  do you think?
Qin

On Sat, Sep 28, 2013 at 2:30 AM, Xavier Vilajosana Guillen <
[email-masked]> wrote:

> Hi Qin,
>
> after thinking a little bit on that maybe we can use the higher byte of
> the rank for that. that is  rank>>8, the higher byte is a monotonically
>> Would you please confirm with some expertise in IEEE802.15.4e if the
>> range 0x00~0x3f is a MUST or not?
>>
>> Thanks
>> Qin
>>

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Fri, 27 Sep 2013 14:07:04 -0700

Hi Qin,

my suggestion is to use JoinPriority[5:0] = (rank[15:8]&0x3F) or 0x3F if
bigger -- having a 0x3F would be like having INFINITE Join Priority as in
the case of RPL with ranks>65535.

would that not work?
X

On Fri, Sep 27, 2013 at 1:44 PM, Qin Wang <[email-masked]> wrote:

> I haven't had good solution for it. So, I hope the range 0x00~0x3f is not
> a "MUST" in IEEE802.15.4e.
>
> What  do you think?
> Qin
>
>
>
>

---

From: Qin Wang <[email-masked]>
Date: Sat, 28 Sep 2013 05:20:18 +0800

Xavi,

You mean:
if rank <= 0x3f then JoinPriority=rank else JoinPriority=0x3f

Correct? I think it could be a solution.

Thanks
Qin

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Fri, 27 Sep 2013 14:31:43 -0700

Hi Qin,

well the rank is 2Byte, what i suggest is to divide it by 256 and take this
number as Join Priority (1Byte). If this number is bigger than 0x3F then
the Join Priority becomes 0x3F. Of course this if 0x3F is a strict
requirement.

regards,
Xavi

On Fri, Sep 27, 2013 at 2:20 PM, Qin Wang <[email-masked]> wrote:

>>> I haven't had good solution for it. So, I hope the range 0x00~0x3f is
>>> not a "MUST" in IEEE802.15.4e.
>>>
>>> What  do you think?
>>> Qin
>>>
>>>
>>>
>>>
>>>> In addition having if we have the limitation of 0x3F, this means that
>>>> we will support Join priorities up to 0x3F that translated to ranks are
>>>> 0x3F<<8 (big number) ..
>>>>
>>>> just thoughts...
>>>> X
>>>>
>>>>
>>>> On Fri, Sep 27, 2013 at 10:30 AM, Qin Wang <[email-masked]>wrote:
>>>>
>>>>> Hi Thomas,
>>>>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 28 Sep 2013 07:08:27 +0000

Agreed

Say the rule is as discussed earlier:
Rank = sigma (etx*2*mh) where mh is 256.
Thus dagrank <= 2*sigma(etx)

Let us be honest, even with an etx of 3 this gives us 8 hops, which leaves very little chances to deliver in time.

For a classical mesh we are shooting at 4 or 5 hops so 3f should be enough.

For long and static lines, we may resort to hop count though.

What do others think?

Pascal

Le 27 sept. 2013 à 23:34, "Xavier Vilajosana Guillen" <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Qin,

well the rank is 2Byte, what i suggest is to divide it by 256 and take this number as Join Priority (1Byte). If this number is bigger than 0x3F then the Join Priority becomes 0x3F. Of course this if 0x3F is a strict requirement.

regards,
Xavi

On Fri, Sep 27, 2013 at 2:20 PM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Xavi,

You mean:

Thanks
Qin

On Sat, Sep 28, 2013 at 5:07 AM, Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Qin,

my suggestion is to use JoinPriority[5:0] = (rank[15:8]&0x3F) or 0x3F if bigger -- having a 0x3F would be like having INFINITE Join Priority as in the case of RPL with ranks>65535.

would that not work?
X

On Fri, Sep 27, 2013 at 1:44 PM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Xavi,

Let's take the example in your draft to see what the problem is. Please point out if I'm wrong.
+-------+
     |   0   | R(0)=0
     |       | DAGRank(R(0)) = 0
     +-------+
         |
         |
     +-------+
     |   1   | R(1)=R(0)+683=683
     |       | DAGRank(R(1)) = 2
     +-------+
         |
         |
     +-------+
     |   2   | R(2)=R(1)+683=1366
     |       | DAGRank(R(2)) = 5
     +-------+
         |
         |
     +-------+
     |   3   | R(3)=R(2)+683=2049
     |       | DAGRank(R(3)) = 8
     +-------+
         |
         |
     +-------+
     |   4   | R(4)=R(3)+683=2732
     |       | DAGRank(R(4)) = 10
     +-------+
         |
         |
     +-------+
     |   5   | R(5)=R(4)+683=3415
     |       | DAGRank(R(5)) = 13
     +-------+

>From the example, you can see R(n) is a 2-byte integer, and DAGRank is always the higher byte of the 2byte integer, because minHopRankIncrease = 256.

If set JoinPriority = DAGRank, then it is possible JoinPriority> 0x3f (although it unlikely happens often), out of its range.
If set JoinPriority[5:0] = DAGRank[7:2], (Is it your suggestion?), a new node may found many existing nodes with same JoinPriority in received EB. In another word, the JoinPriority can not provide information about preferring joining. Right?

I haven't had good solution for it. So, I hope the range 0x00~0x3f is not a "MUST" in IEEE802.15.4e.

What  do you think?
Qin

On Sat, Sep 28, 2013 at 2:30 AM, Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Qin,

after thinking a little bit on that maybe we can use the higher byte of the rank for that. that is  rank>>8, the higher byte is a monotonically increasing counter. As each hop is <<8 (due to minhopRankIncrease) we can have the sense of higher join priority as higher the rank.

In addition having if we have the limitation of 0x3F, this means that we will support Join priorities up to 0x3F that translated to ranks are 0x3F<<8 (big number) ..

just thoughts...
X

On Fri, Sep 27, 2013 at 10:30 AM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Thomas,

I think with OF0 the DAGRank is uint8. But, in the Table 52b of IEEE802.15.4e, the range of Join Priority is 0x00~0x3f. If the range is a "MUST", we have to have a function mapping a DAGRank in 0x00~0xff to a JoinPriority in 0x00~0x3f. Correct?

Would you please confirm with some expertise in IEEE802.15.4e if the range 0x00~0x3f is a MUST or not?

Thanks
Qin

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

---

From: Thomas Watteyne <[email-masked]>
Date: Sat, 28 Sep 2013 12:42:18 -0700

Qin,

In IEEE802.15.4e, Table 52b indeed shows a range of 0x00-0x3f. Yet, Figure
48ee shows a 1-byte field. I'll go on a little hunt to understand where
those 2 bits went, will let you know.

Thomas

On Sat, Sep 28, 2013 at 12:08 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Let us be honest, even with an etx of 3 this gives us 8 hops, which
> leaves very little chances to deliver in time.
>
> Le 27 sept. 2013 à 23:34, "Xavier Vilajosana Guillen" <
> [email-masked]> a écrit :
>
>   Hi Qin,
>
>  well the rank is 2Byte, what i suggest is to divide it by 256 and take
> this number as Join Priority (1Byte). If this number is bigger than 0x3F
> then the Join Priority becomes 0x3F. Of course this if 0x3F is a strict
> requirement.
>
>  regards,
> Xavi
>
>
>>>  my suggestion is to use JoinPriority[5:0] = (rank[15:8]&0x3F) or 0x3F
>>> if bigger -- having a 0x3F would be like having INFINITE Join Priority as
>>> in the case of RPL with ranks>65535.
>>>
>>>  would that not work?
>>> X
>>>
>>>
>>>>  From the example, you can see R(n) is a 2-byte integer, and DAGRank
>>>> is always the higher byte of the 2byte integer, because minHopRankIncrease
>>>> = 256.
>>>>
>>>> If set JoinPriority[5:0] = DAGRank[7:2], (Is it your suggestion?), a
>>>> new node may found many existing nodes with same JoinPriority in received
>>>> EB. In another word, the JoinPriority can not provide information about
>>>>> after thinking a little bit on that maybe we can use the higher byte
>>>>> of the rank for that. that is  rank>>8, the higher byte is a monotonically