Subject: [6tsch] Schemes for resource allocation in the LLN for 6tus

From: JeongGil Ko <[email-masked]>
Date: Wed, 13 Mar 2013 13:02:06 -0400

Hi all,

I would like to start the discussion on what potential schemes can be used to reserve slot/bandwidth resources in an LLN on TSCH. 

One scheme popping of the top of anyone's mind would be a simple form of RSVP but I think its meaningful to open up the discussions to many standardized schemes and perform a short survey on the pros and cons of each scheme.

Please start your discussions on this topic so we can start organizing the schemes.

Thanks!

-John

---

From: Pascal Thubert <[email-masked]>
Date: Thu, 14 Mar 2013 16:04:06 -0400

'lo John,

I think that the contender is NSIS. We have to figure which is best
suited. We have to be able to express in a dense fashion the bandwidth
and teh jitter/latency budget that we have. At each hop, the
reservation message must trigger an operation at the 6TUS layer to
negotiate the cell(s) allocation with the next hop.

At the calls we discussed and agreed that this allocation should be
done in such a way that 6TUS should not know or care whether the
reservation is done between A and B along a RPL route, or controller
by the PCE. Also, we agreed that the PCE should only need to talk to A
in order to establish a cell between A and B, so as to limit the
expenses in control. We have to see how that maps into the pcep
model...

Cheers,

Pascal

2013/3/13 JeongGil Ko <[email-masked]>:
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch

-- 
Pascal

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 Mar 2013 17:01:56 -0400

On Mar 14, 2013, at 16:04, Pascal Thubert <[email-masked]> wrote:

> NSIS

http://nsis-ka.org says:

GIST: 32,858 LOC
NSIS: 67,193 LOC

Grüße, Carsten

---

From: "Qin Wang" <[email-masked]>
Date: Thu, 14 Mar 2013 14:57:27 -0700

Hi all,

This may be a silly question: why we investigate various resource
reservation protocols? Do we want to bind 6tus with some resource
reservation protocol, or try to figure out the mandatory functionality
6tus must provides by investigating those protocols?

Thanks
Qin

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 14 Mar 2013 15:02:02 -0700

Qin, I think that we need a protocol that is in charge of managing 
tracks, allocating bandwidth along the track,  monitor that the end to 
end bandwidth requirement is really accomplished, etc..

this is my point.. maybe others can add more reasons..

X

---

From: JeongGil Ko <[email-masked]>
Date: Thu, 14 Mar 2013 23:33:19 -0400

Exactly my take on this issue. Its really not a matter of using the scheme directly (unless we really can, which can be nice) but taking the concepts and applying it to match our needs for bandwidth/slot allocation.

Thanks.

-John
 
------
JeongGil Ko, Ph.D.
Researcher
Electronics and Telecommunications Research Institute (ETRI)
http://sites.google.com/site/jeonggilko/

On Mar 14, 2013, at 6:02 PM, Xavier Vilajosana <[email-masked]> wrote:

> Qin, I think that we need a protocol that is in charge of managing tracks, allocating bandwidth along the track,  monitor that the end to end bandwidth requirement is really accomplished, etc..
>

---

From: "Qin Wang" <[email-masked]>
Date: Fri, 15 Mar 2013 15:04:12 -0700

John and Xavi,

I agree that understanding more about upper layer protocols like RSVP and
NSIS is very helpful for designing 6tus. But, I want to make clearer about
my understanding on the relationship between 6tus and existing reservation
protocols like RSVP or NSIS.

(1) When we talk about reservation in the context of 6tus, we mainly focus
on  link resource (i.e. cell) reservation, which is required/ triggered by
upper layer. Even in the pure centralized approach, it may happen to
cross-layer reserve both L3 and L2 resource, but you still can separate
them logically.

(2) The upper layer requirement to 6tus may come from PCE carried by
protocol like CoAP, may come from the RSVP/NSIS entity inside nodes.

Thus, for 6tus, the question is what kind of function and interface should
be provided to support the upper layer, instead of which upper layer
protocol should be used.

How do you think?

Qin

> Exactly my take on this issue. Its really not a matter of using the scheme
> directly (unless we really can, which can be nice) but taking the concepts
> and applying it to match our needs for bandwidth/slot allocation.
>
> Thanks.
>
> -John
>
> ------
> JeongGil Ko, Ph.D.
> Researcher

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 16 Mar 2013 11:05:52 +0000

Hi Qin:

I think we are on the same line. The services that 6TUS proposes do not depend on which protocol the request came in through.
Since we are defining the protocol extensions, we'll make sure that the new information is directly digestible by the 6TUS layer.
The protocol extensions will be separate specs, and there should be little to no dereference between those specs and yours.

What's important to me to discuss is how we establish a bundle of cells between A and B.
IMHO, it would be best if that can be achieved by triggering a service in A - no need to trigger B as well.
That way, the volume of exchanges between PCE and nodes can be devided by 2.

This would mean that there must be an exchange between 6TUS in A and 6TUS in B. 
Which  also would mean that there is a protocol part related to 6TUS...

Cheers,

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: vendredi 15 mars 2013 18:04
To: JeongGil Ko
Cc: [email-masked]; Xavier Vilajosana
Subject: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus

John and Xavi,

I agree that understanding more about upper layer protocols like RSVP and NSIS is very helpful for designing 6tus. But, I want to make clearer about my understanding on the relationship between 6tus and existing reservation protocols like RSVP or NSIS.

(1) When we talk about reservation in the context of 6tus, we mainly focus on  link resource (i.e. cell) reservation, which is required/ triggered by upper layer. Even in the pure centralized approach, it may happen to cross-layer reserve both L3 and L2 resource, but you still can separate them logically.

(2) The upper layer requirement to 6tus may come from PCE carried by protocol like CoAP, may come from the RSVP/NSIS entity inside nodes.

Thus, for 6tus, the question is what kind of function and interface should be provided to support the upper layer, instead of which upper layer protocol should be used.

How do you think?

Qin

> Exactly my take on this issue. Its really not a matter of using the 
> scheme directly (unless we really can, which can be nice) but taking 
> the concepts and applying it to match our needs for bandwidth/slot allocation.
>
> Thanks.
>
> -John
>
> ------
> JeongGil Ko, Ph.D.
> Researcher
>> tracks, allocating bandwidth along the track,  monitor that the end 
>> to end bandwidth requirement is really accomplished, etc..
>>
>>> reservation protocol, or try to figure out the mandatory 
>>> functionality 6tus must provides by investigating those protocols?
>>>
>>> Thanks
>>> Qin
>>>
>>>
>>>> On Mar 14, 2013, at 16:04, Pascal Thubert 
>>>> <[email-masked]>
>>>> wrote:
>>>>
>>>>> NSIS
>>>> http://nsis-ka.org says:
>>>>
>>>> GIST: 32,858 LOC
>>>> NSIS: 67,193 LOC
>>>>
>>>> Grüße, Carsten
>>>>

---

From: "Qin Wang" <[email-masked]>
Date: Sat, 16 Mar 2013 16:19:39 -0700

Hi Pascal,

It is a very good idea to establish a bundle of cells between A and B by
just triggering 6tus in one side. We can design for different scenarios.

(1) PCE defines the track, i.e. the multihop path, the bandwidth of each
hop, and scheduling hard-cells to implement the multihop path. Assume
nodeA and nodeB are one-hop neighbors along the path. In this case, PCE
can send Create.hardcell command to 6tus layer in nodeA,and nodeA's 6tus
sends Create.hardcell command to nodeB' 6tus, then the hard cell is
reserved. This function is not in the current version of 6tus draft, but
we can add it in the next version easily.

(2)PCE defines the multihop path and the bandwidth of each hop, but not
schedules the cells to meet the path bandwidth. In this case, soft cell
reservation will be applied, which is always triggered in Transmitting
side, and negotiated by the 6tus layer of both sides.

(3)The cell reservation is triggered by upper layer, e.g. the RSVP/NSIS
entity in nodeA. Then soft cell reservation process in 6tus layer of nodeA
will by triggered, and the negotiation process is same as case (2).

In summary, by adding reserve hard cell procedure into version-00 of 6tus,
we can let the bundle reservation in every scenarios be triggered just in
one side.

How do you think?

Qin

> Hi Qin:
>
> I think we are on the same line. The services that 6TUS proposes do not
> depend on which protocol the request came in through.
> Since we are defining the protocol extensions, we'll make sure that the
> new information is directly digestible by the 6TUS layer.
> The protocol extensions will be separate specs, and there should be little
> to no dereference between those specs and yours.
>

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 17 Mar 2013 01:45:29 +0100

On Mar 17, 2013, at 00:19, "Qin Wang" <[email-masked]> wrote:

> scenarios

I think it is good to look at all these scenarios.
But please let's then select a small subset that we actually do.

I don't know how it is better to have half of your state set up by the god box ("PCE") and half of it by neighbors.  I can think of so many interesting race conditions here...

Simplify, simplify, simplify.

Grüße, Carsten

---

From: JeongGil Ko <[email-masked]>
Date: Sun, 17 Mar 2013 13:48:40 +0900

Sorry for the delayed response. I was stuck on the plane for too long :)

I like the discussion that Qin is going for where we define the scenarios.  At the same time, as Carsten says we need to make sure overlapping scenarios of any sort are simplified and aggregated as much as possible.

Let me just try to put my 2 cents in-line...

> we can let the bundle reservation in every scenarios be triggered just in

Great first start in defining the scenarios.

>> Which  also would mean that there is a protocol part related to 6TUS…
>> 

Fully agreed that this is needed. Being an independent layer, I don't see why not.

>> be provided to support the upper layer, instead of which upper layer

I agree with your arguments that the important thing is defining the functionalities. It seems like some of these efforts are on the way in the later emails. Me bringing in the term "RSVP" was not that I wanted to go an use RSVP in the way it is, but bring the (modified/customized) concept in for use in 6tus. As to what I read there may have been a misunderstanding between us but we are on the same line. 

Thanks!

-John

---

From: "Qin Wang" <[email-masked]>
Date: Sun, 17 Mar 2013 09:47:31 -0700

I fully agree with Carsten that Simple is very important. Let's
overlapping the following three scenarios, then we will find only two
groups of functions 6tus should provide.

(1) Hard cell reserve/remove, which supports the 1st scenario.
(2) Soft cell reserve/remove, which supports the 2nd and 3rd scenario.

Any more?

Qin

> I like the discussion that Qin is going for where we define the scenarios.
>  At the same time, as Carsten says we need to make sure overlapping
> scenarios of any sort are simplified and aggregated as much as possible.
>
>>> IMHO, it would be best if that can be achieved by triggering a service
>>> in
>>> A - no need to trigger B as well.
>>> That way, the volume of exchanges between PCE and nodes can be devided
>>> by
>>> 2.
>>>
>>> This would mean that there must be an exchange between 6TUS in A and
>>> 6TUS
>>> in B.
>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>> Of
>>> Qin Wang
> I agree with your arguments that the important thing is defining the
> functionalities. It seems like some of these efforts are on the way in the
> later emails. Me bringing in the term "RSVP" was not that I wanted to go
> an use RSVP in the way it is, but bring the (modified/customized) concept
> in for use in 6tus. As to what I read there may have been a
> misunderstanding between us but we are on the same line.
>
> Thanks!
>
> -John
>
>>> Qin
>>>
>>>
>>
>
>

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Mon, 18 Mar 2013 09:21:52 +0000

+1 about keeping simple solutions!

It should be great if 6tus could include the following functionalities!
Maria Rita

>> (1) PCE defines the track, i.e. the multihop path, the bandwidth of 
>> each hop, and scheduling hard-cells to implement the multihop path. 
>> Assume nodeA and nodeB are one-hop neighbors along the path. In this 
>> case, PCE can send Create.hardcell command to 6tus layer in nodeA,and 
>> nodeA's 6tus sends Create.hardcell command to nodeB' 6tus, then the 
>> hard cell is reserved. This function is not in the current version of 
>> 6tus draft, but we can add it in the next version easily.
>>

---------------------------------------------------------------------------------------------------------------------------------------------
>> (2)PCE defines the multihop path and the bandwidth of each hop, but 
>> not schedules the cells to meet the path bandwidth. In this case, 
>> soft cell reservation will be applied, which is always triggered in 
>> Transmitting side, and negotiated by the 6tus layer of both sides.
>>
>> (3)The cell reservation is triggered by upper layer, e.g. the 
>> RSVP/NSIS entity in nodeA. Then soft cell reservation process in 6tus 
>> layer of nodeA will by triggered, and the negotiation process is same 
>> as case (2).
>>
>> In summary, by adding reserve hard cell procedure into version-00 of 
>> 6tus, we can let the bundle reservation in every scenarios be 
>> triggered just in one side.
>>
>> How do you think?
>>
>
>>> I think we are on the same line. The services that 6TUS proposes do 
>>> not depend on which protocol the request came in through.
>>> Since we are defining the protocol extensions, we'll make sure that 
>>> the new information is directly digestible by the 6TUS layer.
>>> The protocol extensions will be separate specs, and there should be 
>>> little to no dereference between those specs and yours.
>>>
>>> IMHO, it would be best if that can be achieved by triggering a 
>>> service in A - no need to trigger B as well.
>>> 6TUS in B.
>>> I agree that understanding more about upper layer protocols like 
>>> RSVP and NSIS is very helpful for designing 6tus. But, I want to 
>>> make clearer about my understanding on the relationship between 6tus 
>>> and existing reservation protocols like RSVP or NSIS.
>>>
>>> (1) When we talk about reservation in the context of 6tus, we mainly 
>>> focus on  link resource (i.e. cell) reservation, which is required/ 
>>> triggered by upper layer. Even in the pure centralized approach, it 
>>> may happen to cross-layer reserve both L3 and L2 resource, but you 
>>> still can separate them logically.
>>>
>>> Thus, for 6tus, the question is what kind of function and interface 
>>> should be provided to support the upper layer, instead of which 
>>> upper layer protocol should be used.
>>>
>>> How do you think?
>>>
>
> functionalities. It seems like some of these efforts are on the way in 
> the later emails. Me bringing in the term "RSVP" was not that I wanted 
> to go an use RSVP in the way it is, but bring the 
> (modified/customized) concept in for use in 6tus. As to what I read 
> there may have been a misunderstanding between us but we are on the same line.
>
> Thanks!
>
> -John
>
>>> Qin
>>>
>>>
>>
>
>

---

From: Xavier Vilajosana <[email-masked]>
Date: Mon, 18 Mar 2013 06:29:44 -0700

This is on the roadmap of the draft.

regards,
Xavi

---

From: "Qin Wang" <[email-masked]>
Date: Mon, 18 Mar 2013 10:48:19 -0700

Alfredo,

Firstly, my understanding is Hard cell reservation can only be used by
PCE, i.e.  centralized schedule. Thus, mobile node will join in network
based on the cells broadcast in EB. And, after its registration, PCE will
assign some Hard cells to it.

secondly, regarding to high priority of the data flow from the mobile
node, DSCP may help, i.e. the packets from the mobile node can include
Priority.

How do you think?

Qin

> Hi Qin and all,
>
> Just to challenge the two groups of functions Qin is talking about, what
> if a certain number of mobile nodes need hard reservation ? In this case,
> mobile nodes transmit Real time data to be delivered within a given
> deadline but 6tus does not know in advance the rank (or the position
> within the topology) of such nodes.
>
> I mean that this kind of traffic has the top priority but nobody knows in
> advance the exact position of the nodes that is going to generate that
> data.
>
> Do we need a further case ? Or we can leverage on 1 or 2 ? If yes, how ?
>
> Thanks a lot in advance for your attention
>
> Cheers
>
> Alfredo
>
> --
> Luigi Alfredo Grieco, PhD
> Assistant Professor
> Department of Electrical and Information Engineering
> Politecnico di Bari
> Via Orabona 4 - 70125 - Bari - Italy
> +39 080 5963 911
> telematics.poliba.it/grieco
> Skype id: l.alfredo.grieco
> Mobile: +39 3346715672
>
>
> On 17 Mar 2013, at 17:47, "Qin Wang" <[email-masked]> wrote:
>
>>
>>
>>>> each
>>>> not
>>>> RSVP/NSIS
>>>> 6tus,
>>>>> not
>>>>> the
>>>>> little
>>>>> What's important to me to discuss is how we establish a bundle of
>>>>> cells
>>>>> between A and B.
>>>>> service
>>> Fully agreed that this is needed. Being an independent layer, I don't
>>> see
>>> why not.
>>>
>>>
>>>>> Cheers,
>>>>>
>>>>> Pascal
>>>>>
>>>>>
>>>>> focus
>>>>> on  link resource (i.e. cell) reservation, which is required/
>>>>> triggered
>>>>> by
>>>>> should
>>> the

---

From: "Alfredo Grieco" <[email-masked]>
Date: Mon, 18 Mar 2013 19:01:51 +0100

Hi Qin,

Your proposal is sound. 

Just a final remark: if my understanding is correct, the PCE should build a schedule that spans across multiple links from mobile node M towards the sink S. 

If a M moves after the schedule has been built, some pre-assigned resources along that path could get lost (which could be tolerated) because of the change of the topology.

Is it ok ?

Cheers and thanks for your answer

Alfredo

-----Messaggio originale-----
Da: Qin Wang [mailto:[email-masked]] 
Inviato: Monday, March 18, 2013 6:48 PM
A: Grieco
Cc: Qin Wang; JeongGil Ko; Pascal Thubert (pthubert); [email-masked]; Xavier Vilajosana
Oggetto: Re: [6tsch] Schemes for resource allocation in the LLN for 6tus

Alfredo,

Firstly, my understanding is Hard cell reservation can only be used by PCE, i.e.  centralized schedule. Thus, mobile node will join in network based on the cells broadcast in EB. And, after its registration, PCE will assign some Hard cells to it.

secondly, regarding to high priority of the data flow from the mobile node, DSCP may help, i.e. the packets from the mobile node can include Priority.

How do you think?

Qin

> Hi Qin and all,
>
> Just to challenge the two groups of functions Qin is talking about, 
> what if a certain number of mobile nodes need hard reservation ? In 
> this case, mobile nodes transmit Real time data to be delivered within 
> a given deadline but 6tus does not know in advance the rank (or the 
> position within the topology) of such nodes.
>
> I mean that this kind of traffic has the top priority but nobody knows 
> in advance the exact position of the nodes that is going to generate 
> that data.
>
> Department of Electrical and Information Engineering Politecnico di 
> Bari Via Orabona 4 - 70125 - Bari - Italy
> +39 080 5963 911
>>> Sorry for the delayed response. I was stuck on the plane for too 
>>> long
>>> :)
>>>
>>>> It is a very good idea to establish a bundle of cells between A and 
>>>> B by just triggering 6tus in one side. We can design for different 
>>>> scenarios.
>>>>
>>>> Assume nodeA and nodeB are one-hop neighbors along the path. In 
>>>> this case, PCE can send Create.hardcell command to 6tus layer in 
>>>> nodeA,and nodeA's 6tus sends Create.hardcell command to nodeB' 
>>>> 6tus, then the hard cell is reserved. This function is not in the 
>>>> current version of 6tus draft, but we can add it in the next 
>>>> version easily.
>>>>
>>>> RSVP/NSIS entity in nodeA. Then soft cell reservation process in 
>>>> 6tus layer of nodeA will by triggered, and the negotiation process 
>>>> is same as case (2).
>>>>
>>>> In summary, by adding reserve hard cell procedure into version-00 
>>>> of 6tus, we can let the bundle reservation in every scenarios be 
>>>>> I think we are on the same line. The services that 6TUS proposes 
>>>>> do not depend on which protocol the request came in through.
>>>>> Since we are defining the protocol extensions, we'll make sure 
>>>>> that the new information is directly digestible by the 6TUS layer.
>>>>> The protocol extensions will be separate specs, and there should 
>>>>> be little to no dereference between those specs and yours.
>>>>>
>>>>> cells between A and B.
>>>>> make clearer about my understanding on the relationship between 
>>>>> 6tus and existing reservation protocols like RSVP or NSIS.
>>>>>
>>>>> (1) When we talk about reservation in the context of 6tus, we 
>>>>> mainly focus on  link resource (i.e. cell) reservation, which is 
>>>>> required/ triggered by upper layer. Even in the pure centralized 
>>>>> approach, it may happen to cross-layer reserve both L3 and L2 
>>>>> resource, but you still can separate them logically.
>>>>>
>>>>> (2) The upper layer requirement to 6tus may come from PCE carried 
>>>>> by protocol like CoAP, may come from the RSVP/NSIS entity inside nodes.
>>>>>
>>>>> Thus, for 6tus, the question is what kind of function and 
>>>>> interface should be provided to support the upper layer, instead 
>>>>> of which upper layer protocol should be used.
>>>>>
>>>>> How do you think?
>>>>>
>>>
>>> functionalities. It seems like some of these efforts are on the way 
>>> in the later emails. Me bringing in the term "RSVP" was not that I 
>>> wanted to go an use RSVP in the way it is, but bring the

---

From: "Qin Wang" <[email-masked]>
Date: Mon, 18 Mar 2013 12:20:08 -0700

Alfredo,

I think your remark is correct. So, if there is lots of mobility, I would
be prefer distributed approach, i.e. Soft Cell reservation locally + RPL +
DSCP for QoS.

Qin

> Hi Qin,
>
> Your proposal is sound.
>
> Just a final remark: if my understanding is correct, the PCE should build
> a schedule that spans across multiple links from mobile node M towards the
> sink S.
>
> If a M moves after the schedule has been built, some pre-assigned
> resources along that path could get lost (which could be tolerated)
> because of the change of the topology.
>
> Is it ok ?
>

---

From: Xavier Vilajosana <[email-masked]>
Date: Mon, 18 Mar 2013 12:40:49 -0700

Hi Alfredo,

just one point on mobility.
TSCH networks may require certain time for a node to join, this depends 
on how the EBs are sent and what are the policies for the joining node 
on how to scan the different channels. Having said that, I think that 
the time required for a node to reserve some cells with its neighbour is 
extremely less than the joining time and hence if a mobile node can join 
the network for sure has time to schedule some links. So maybe this is 
not a big problem :-)

cheers!
Xavi

On 18/03/13 12:36, Grieco wrote:
> Hi Qin, Thomas, and all
>
> Perhaps the only way to cope with (a reasonable degree of) mobility is 
> to hardly assign a certain number of cells at each link to be used in 
> case a mobile node arrives with urgent data to transmit.
>
> Obviously this would slightly decrease the overall efficiency of the 
> system because such "guaranteed cells" could get unused in most of cases.
>
> If, on the other side, the mobile node is generating data which is not 
> that urgent, soft reservation could be used as well, which should 
> waste a smaller amount of resources.
>
> In this perspective, mobile nodes could be handled using either 
> functions 1 or 2, depending on the degree of mobility, the priority of 
> the data packets generated by mobile nodes, the desired duty cycle, 
> and so on.
>
> Cheers
>
> Alfredo
>
>
>
>
> -- 
> telematics.poliba.it/grieco <http://telematics.poliba.it/grieco>
> On 18 Mar 2013, at 20:20, "Qin Wang" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Alfredo,
>>
>>> Cc: Qin Wang; JeongGil Ko; Pascal Thubert (pthubert); [email-masked] 
>>> <mailto:[email-masked]>;
>>> Xavier Vilajosana
>>>> telematics.poliba.it/grieco <http://telematics.poliba.it/grieco>
>>>> On 17 Mar 2013, at 17:47, "Qin Wang" <[email-masked] 
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>>>
>>>>>
>>>>>> On Mar 17, 2013, at 8:19 AM, Qin Wang <[email-masked] 
>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>
>>>>>>> Hi Pascal,
>>>>>>>
>>>>>>>> From: [email-masked] <mailto:[email-masked]> 
>>>>>>>> [mailto:[email-masked]] On
>>>>>>>> Behalf Of Qin Wang
>>>>>>>> Cc: [email-masked] <mailto:[email-masked]>; Xavier Vilajosana
>>>>> [email-masked] <mailto:[email-masked]>

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 18 Mar 2013 12:41:25 -0700

Alfredo,

Cool idea! Where do you think this could be described? Architecture draft?
Or do you think this is worth another draft, possibly later on?

In any case, let's keep that idea is the backs of our minds.

Thomas

On Mon, Mar 18, 2013 at 12:36 PM, Grieco <[email-masked]> wrote:

> Hi Qin, Thomas, and all
>
> Perhaps the only way to cope with (a reasonable degree of) mobility is to
> hardly assign a certain number of cells at each link to be used in case a
> mobile node arrives with urgent data to transmit.
>
> that urgent, soft reservation could be used as well, which should waste a
> smaller amount of resources.
>
> In this perspective, mobile nodes could be handled using either functions
> 1 or 2, depending on the degree of mobility, the priority of the data
> packets generated by mobile nodes, the desired duty cycle, and so on.
>
> Cheers
>
> Alfredo
>
>
>
>
> --
> On 18 Mar 2013, at 20:20, "Qin Wang" <[email-masked]> wrote:
>
> Alfredo,
>
> Da: Qin Wang [mailto:[email-masked] <[email-masked]>]
>
> Cc: Qin Wang; JeongGil Ko; Pascal Thubert (pthubert); [email-masked];
>
> Xavier Vilajosana
>
> I like the discussion that Qin is going for where we define the
>
> scenarios.
>
> scenarios of any sort are simplified and aggregated as much as
>
> possible.
>
>
> That way, the volume of exchanges between PCE and nodes can be
>
> devided by 2.
>
>
> This would mean that there must be an exchange between 6TUS in A
>
> and 6TUS in B.
>
> Which  also would mean that there is a protocol part related to
>
> 6TUS…
>
>
>
> Fully agreed that this is needed. Being an independent layer, I
>
> don't see why not.
>
>
>
> Cheers,
>
>
> Pascal
>
>
>
> From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On
>
> Behalf Of Qin Wang
>
> Subject: Re: [6tsch] Schemes for resource allocation in the LLN
>
> for 6tus
>
>
> John and Xavi,
>
>
> by protocol like CoAP, may come from the RSVP/NSIS entity inside
>
> nodes.
>
>
> there may have been a misunderstanding between us but we are on the
>
> same line.
>
>
> Thanks!
>
>
> -John
>
>
> Qin
>
>
>
>
>
>
>

---

From: Grieco <[email-masked]>
Date: Mon, 18 Mar 2013 23:42:50 +0100

Hi Xavi, Thomas, all

The problem I am pointing out is not related only to the neighbourhood. As a matter of fact, a node would like its data be received to the sink and not only at the next hop. If for each hop to travel, a data packet should gain a cell through some request/answer handshake this would lead to high e2e delays when the depth of the tree is high and would incur useless signalling.

If we think at TASA, to do an example, the schedule exactly rules the story of each packet from its generating node to the sink. I was trying to figure out how to do the same in presence of some uncertainty on the network topology.

While solving this problem is something to be afforded in some scientific paper, I believe that the functionalities of 6tus and the entire architecture we are envisaging should be ready to welcome this new wave of algorithms.

In other terms, I am proposing to add a limited number of "reserved pipes" to the sink that could be used to transport "only" urgent data from mobile nodes. 

Thomas, this could be added as general remark to the architecture or to the draft you are editing. Of course, with more details, some primitive to the 6tus draft could be added or lead to a new draft on handling mobile 6tsch nodes.

Cheers :-)

On 18 Mar 2013, at 20:40, Xavier Vilajosana <[email-masked]> wrote:

> TSCH networks may require certain time for a node to join, this depends on how the EBs are sent and what are the policies for the joining node on how to scan the different channels. Having said that, I think that the time required for a node to reserve some cells with its neighbour is extremely less than the joining time and hence if a mobile node can join the network for sure has time to schedule some links. So maybe this is not a big problem :-)
> 
> cheers!
> Xavi
> 
> 
> 
> 
>> Perhaps the only way to cope with (a reasonable degree of) mobility is to hardly assign a certain number of cells at each link to be used in case a mobile node arrives with urgent data to transmit.
>> 
>> Obviously this would slightly decrease the overall efficiency of the system because such "guaranteed cells" could get unused in most of cases.
>> 
>> If, on the other side, the mobile node is generating data which is not that urgent, soft reservation could be used as well, which should waste a smaller amount of resources.
>> 
>> In this perspective, mobile nodes could be handled using either functions 1 or 2, depending on the degree of mobility, the priority of the data packets generated by mobile nodes, the desired duty cycle, and so on.
>> 
>> Cheers
>> 
>> Alfredo
>> 
>> 
>> 
>> 
>> --

---

From: "Qin Wang" <[email-masked]>
Date: Mon, 18 Mar 2013 17:09:47 -0700

Alfredo,

I think there are two key features in your description: (1)data with high
priority, and (2)mobility. I would like to think the two feature
separately.

Regarding to the high priority, I think the QoS mechanism like DSCP can
handle it, no matter the data flow come from static node or moving node.

Regarding to the mobility, the 6tus can support to establish tracks for
specific purpose. Actually, the cell reservation request comes from upper
layer, 6tus do not know the reserved cells will be used by static nodes or
mobile nodes. In another word, upper layer can ask 6tus to reserve some
cells or tracks or pipes which specifically used for mobile node to send
data as you said.

Does it make sense?

Qin

>
> Hi Xavi, Thomas, all
>
> The problem I am pointing out is not related only to the neighbourhood. As
> a matter of fact, a node would like its data be received to the sink and
> not only at the next hop. If for each hop to travel, a data packet should
> gain a cell through some request/answer handshake this would lead to high
> e2e delays when the depth of the tree is high and would incur useless
> signalling.
>
> If we think at TASA, to do an example, the schedule exactly rules the
> story of each packet from its generating node to the sink. I was trying to
> figure out how to do the same in presence of some uncertainty on the
> network topology.
>
> While solving this problem is something to be afforded in some scientific
> paper, I believe that the functionalities of 6tus and the entire
> architecture we are envisaging should be ready to welcome this new wave of
> algorithms.
>
> In other terms, I am proposing to add a limited number of "reserved pipes"
> to the sink that could be used to transport "only" urgent data from mobile
> nodes.
>
> Thomas, this could be added as general remark to the architecture or to
> the draft you are editing. Of course, with more details, some primitive to
> the 6tus draft could be added or lead to a new draft on handling mobile
> 6tsch nodes.
>
> Cheers :-)
>
>
> --
>>> that urgent, soft reservation could be used as well, which should waste
>>> a smaller amount of resources.
>>>
>>> the data packets generated by mobile nodes, the desired duty cycle, and
>>> so on.
>>>
>>> Cheers
>>>
>>> Alfredo
>>>
>>>
>>>
>>>
>>> --

---

From: Grieco <[email-masked]>
Date: Tue, 19 Mar 2013 09:58:01 +0100

Hi Qin,

It does work for me: thanks for the clarification

Cheers

Alfredo

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 19 Mar 2013 09:57:27 -0700

Alfredo,

This is an interesting use case you bring up. Do you have a specific use
case/problem you are trying to solve?

I agree with Qin that it would be great if this were a schedule-only
decision, i.e. we change as little as possible in the mechanism (e.g.
6tus), but rather have the scheduling entity build an (otherwise normal)
schedule which allows for some motes to roam around.

Thomas

On Tue, Mar 19, 2013 at 1:58 AM, Grieco <[email-masked]> wrote:

> On 18 Mar 2013, at 20:40, Xavier Vilajosana
>
> <[email-masked]> wrote:
>
>
> Hi Alfredo,
>
>
> system because such "guaranteed cells" could get unused in most of
>
> cases.
>
>
> I think your remark is correct. So, if there is lots of mobility, I
>
> would
>
> be prefer distributed approach, i.e. Soft Cell reservation locally +
>
> RPL +
>
> DSCP for QoS.
>
>
> Qin
>
>
>
> Hi Qin,
>
> Your proposal is sound.
>
> Just a final remark: if my understanding is correct, the PCE should
>
> build
>
> a schedule that spans across multiple links from mobile node M
>
> towards the
>
> sink S.
>
> Oggetto: Re: [6tsch] Schemes for resource allocation in the LLN for
>
> 6tus
>
> Alfredo,
>
> Firstly, my understanding is Hard cell reservation can only be used
>
> by
>
> PCE, i.e.  centralized schedule. Thus, mobile node will join in
>
> network
>
> based on the cells broadcast in EB. And, after its registration, PCE
>
> will
>
> node, DSCP may help, i.e. the packets from the mobile node can
>
> include
>
> Priority.
>
> How do you think?
>
> Qin
>
> Hi Qin and all,
>
> this case, mobile nodes transmit Real time data to be delivered
>
> within
>
> I mean that this kind of traffic has the top priority but nobody
>
> knows
>
> Do we need a further case ? Or we can leverage on 1 or 2 ? If yes,
>
> how ?
>
> overlapping the following three scenarios, then we will find only
>
> two
>
> (2) Soft cell reserve/remove, which supports the 2nd and 3rd
>
> scenario.
>
> Any more?
>
> Qin
>
> On Mar 17, 2013, at 8:19 AM, Qin Wang <[email-masked]>
>
> wrote:
>
> Hi Pascal,
>
> It is a very good idea to establish a bundle of cells between A
>
> and
>
> B by just triggering 6tus in one side. We can design for
>
> different
>
> scenarios.
>
> (1) PCE defines the track, i.e. the multihop path, the bandwidth
>
> of
>
> each hop, and scheduling hard-cells to implement the multihop
>
> path.
>
> (2)PCE defines the multihop path and the bandwidth of each hop,
>
> but
>
> soft cell reservation will be applied, which is always triggered
>
> in
>
> Transmitting side, and negotiated by the 6tus layer of both
>
> sides.
>
> 6tus layer of nodeA will by triggered, and the negotiation
>
> process
>
> is same as case (2).
>
> that the new information is directly digestible by the 6TUS
>
> layer.
>
> What's important to me to discuss is how we establish a bundle
>
> of
>
> cells between A and B.
>
> (2) The upper layer requirement to 6tus may come from PCE
>
> carried
>
> I agree with your arguments that the important thing is defining
>
> the
>
> functionalities. It seems like some of these efforts are on the
>
> way
>
> (modified/customized) concept in for use in 6tus. As to what I
>
> read
>
> there may have been a misunderstanding between us but we are on
>
> the
>
> same line.
>
> Thanks!
>
> -John
>
> Qin
>

---

From: Grieco <[email-masked]>
Date: Tue, 19 Mar 2013 20:29:54 +0100

Thomas, Pascal,

If this can serve to point out some relevant target scenarios, use cases with some degree of mobility include:
- robotics applications
- assembly lines
- avionic systems
- radio localization and tracking 
- advanced mechatronic systems

These are the main domains Telematics lab  is involved within several research projects at Politecnico di Bari.

Cheers

Alfredo

On 19 Mar 2013, at 17:57, Thomas Watteyne <[email-masked]> wrote:

> Alfredo,
> 
> This is an interesting use case you bring up. Do you have a specific use case/problem you are trying to solve?
> 
> I agree with Qin that it would be great if this were a schedule-only decision, i.e. we change as little as possible in the mechanism (e.g. 6tus), but rather have the scheduling entity build an (otherwise normal) schedule which allows for some motes to roam around.
> 
> Thomas
>

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 19 Mar 2013 12:37:30 -0700

Hi,

more uses cases that might benefit from 6tus:

-Smart cities/infrastructures/industries
     *(road,street) traffic control (requires increase of bw as more 
traffic in the road)
     *smart urban parking (requires redundancy of routes an 
over-provision as RF degrades with cars on top of the sensors)
     *building monitoring (requires redundancy as RF degrades when there 
are changes on the environment, doors, movement,etc..)
     *industrial automation (latency, robustnes->overprovision,etc...)
     *metering (can be bursty)

and for sure we can find several more use cases where 6tus might be 
*VERY* relevant.

regards,
Xavi

On 19/03/13 12:29, Grieco wrote:
> Thomas, Pascal,
>
> If this can serve to point out some relevant target scenarios, use 
> cases with some degree of mobility include:
> - robotics applications
> - assembly lines
> - avionic systems
> These are the main domains Telematics lab  is involved within several 
> research projects at Politecnico di Bari.
>
> Cheers
>
> Alfredo
>
>
> On 19 Mar 2013, at 17:57, Thomas Watteyne <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Alfredo,
>>
>> This is an interesting use case you bring up. Do you have a specific 
>> use case/problem you are trying to solve?
>>
>> 6tus), but rather have the scheduling entity build an (otherwise 
>> normal) schedule which allows for some motes to roam around.
>>
>> Thomas
>>
>> On Tue, Mar 19, 2013 at 1:58 AM, Grieco <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     Hi Qin,
>>
>>     +39 080 5963 911 <tel:%2B39%20080%205963%20911>
>>     Mobile: +39 3346715672 <tel:%2B39%203346715672>
>>
>>
>>     On 19 Mar 2013, at 01:09, "Qin Wang" <[email-masked]
>>>>     +39 080 5963 911 <tel:%2B39%20080%205963%20911>
>>>>     Mobile: +39 3346715672 <tel:%2B39%203346715672>
>>>>
>>>>
>>>>     <[email-masked]
>>>>     <mailto:[email-masked]>> wrote:
>>>>
>>>>>     Hi Alfredo,
>>>>>
>>>>>>     +39 080 5963 911 <tel:%2B39%20080%205963%20911>
>>>>>>     Mobile: +39 3346715672 <tel:%2B39%203346715672>
>>>>>>
>>>>>>
>>>>>>>>     Cc: Qin Wang; JeongGil Ko; Pascal Thubert (pthubert);
>>>>>>>>     [email-masked] <mailto:[email-masked]>;
>>>>>>>>     Xavier Vilajosana
>>>>>>>>>     Politecnico di
>>>>>>>>>     +39 080 5963 911 <tel:%2B39%20080%205963%20911>
>>>>>>>>>     <http://telematics.poliba.it/grieco>
>>>>>>>>>     Mobile: +39 3346715672 <tel:%2B39%203346715672>
>>>>>>>>>>>     On Mar 17, 2013, at 8:19 AM, Qin Wang
>>>>>>>>>>>     <[email-masked] <mailto:[email-masked]>>
>>>>>>>>>>>     wrote:
>>>>>>>>>>>>     Hi Pascal,
>>>>>>>>>>>>>     6TUS...