Subject: [6lo] 6lo usecases?

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 13 Feb 2014 02:32:00 +0000

Hello 6lo-colleagues:

Some time ago, 6lowpan (IPv6-over-IEEE 802.15.4) have worked on a usecase draft http://tools.ietf.org/html/rfc6568.

Can someone volunteer  and discuss in the mailing list if it covers the  6lo usecases as well?

Thank you.
-Samita

---

From: "Cao,Zhen" <[email-masked]>
Date: Fri, 14 Feb 2014 15:35:15 +0800

Hi ALL,

RFC6568 covers 6 major use cases, industrial monitoring, structural
monitoring, Connected Home, Vehicle Telematics, Healthcare,
Agricultural Monitoring.

And the use cases were basically around the application of 802.15.4,
while the 6lo working group is covering diverse types of L2.

I can at least envision the use cases such as: Environmental
Monitoring, Smart Logistics and Tracking, Energy Management, and etc.

Regards,
Zhen

On Thu, Feb 13, 2014 at 10:32 AM, Samita Chakrabarti
<[email-masked]> wrote:
> Hello 6lo-colleagues:
>
>
>
> Some time ago, 6lowpan (IPv6-over-IEEE 802.15.4) have worked on a usecase
> draft http://tools.ietf.org/html/rfc6568.
>
>
>
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: <[email-masked]>
Date: Fri, 14 Feb 2014 07:41:26 +0000

Hi all,

I'd count in Wearables as well.

Best regards,

Teemu
________________________________________
From: 6lo [[email-masked]] on behalf of ext Cao,Zhen [[email-masked]]
Sent: Friday, February 14, 2014 9:35 AM
To: Samita Chakrabarti
Cc: [email-masked]
Subject: Re: [6lo] 6lo usecases?

Hi ALL,

Regards,
Zhen

---

From: "Cao,Zhen" <[email-masked]>
Date: Fri, 14 Feb 2014 15:49:32 +0800

Wearables were discussed in Healthcare. But I agree that it will be an
outstanding use case :)

-Zhen

---

From: <[email-masked]>
Date: Fri, 14 Feb 2014 07:53:01 +0000

Oh, ok, well, anyhow I don't see Wearables as a subset of Healhcare - rather those two use-cases intersect for a class of devices.

Best regards,

Teemu
________________________________________
From: ext Cao,Zhen [[email-masked]]
Sent: Friday, February 14, 2014 9:49 AM
To: Savolainen Teemu (Nokia-CTO/Tampere)
Cc: Samita Chakrabarti; [email-masked]
Subject: Re: [6lo] 6lo usecases?

-Zhen

---

From: Niclas Granqvist <[email-masked]>
Date: Fri, 14 Feb 2014 09:08:09 +0100

I agree with Teemu in the sense that Sports and Fitness wearables
and sometime near-body/off body devices(example: cycling sensors),
for example, is not  part of health care.

Health care is more complex with FDA certifications
and most times has additional requirements compared to other fields.

Kind Regards,
________________________________
Mr. Niclas Granqvist
Director, Interoperable ecosystems
Tel:          +41 (0)32 862 9050
Direct:     +41 (0)32 862 9068
Fax:         +41 (0)32 862 9055
Mob:        +41 (0)79 814 9161
Skype:    niclas_granqvist_work
Email:      [email-masked]
Address:                 Polar Electro Europe BV, Fleurier Branch
Av. D.-Jeanrichard 2a, CH-2114 Fleurier, Switzerland
Web: www.polar.com

From:
"Cao,Zhen" <[email-masked]>
To:
[email-masked], 
Cc:
Samita Chakrabarti <[email-masked]>, "[email-masked]" 
<[email-masked]>
Date:
14.02.2014 08:49
Subject:
Re: [6lo] 6lo usecases?
Sent by:
"6lo" <[email-masked]>

-Zhen

On Fri, Feb 14, 2014 at 3:41 PM,  <[email-masked]> wrote:
>> Can someone volunteer  and discuss in the mailing list if it covers the 
 6lo
>> usecases as well?

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Feb 2014 09:10:08 +0100

> Can someone volunteer  and discuss in the mailing list if it covers the  6lo usecases as well?

What would that be?  Use cases for a working group?

Seriously, 6lo is about getting IP running on link layer technologies appropriate for constrained node networks.
So our use cases are everything that involves constrained node networks.

After just having spent an inordinate amount of time getting a terminology document for constrained node networks through the IESG (last DISCUSS cleared, now in final COMMENT disposition), I’m not looking forward to an endeavor creating such a wide-ranging document.

(Looking back to RFC6568, the selection of use cases that made it in there always seemed a bit arbitrary.  It still was a useful document for introducing to the applications of wireless constrained node networks.  But that work is done.  Creating a “more use cases” supplement certainly is possible, but what specific work would it guide us in?  I’d rather define that work first, and then get a specific use cases document if that is needed for that work.)

Grüße, Carsten

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Feb 2014 19:43:19 +0100

Le 14/02/2014 09:10, Carsten Bormann a écrit :
> Seriously, 6lo is about getting IP running on link layer technologies
> appropriate for constrained node networks. So our use cases are
> everything that involves constrained node networks.

To me that is too generic.

A constrained node may be constrained in one dimension but very relaxed
in others; or fully constrained node may  need to communicate to totally 
unconstrained node.  I'd say that most nodes are that way.

Let aside the totally constrained nodes (little RAM, small size, little
battery, little movement range), there are many other nodes which are
constrained in RAM but have high bandwidth, or high energy, or high
speed of movement.

I think this brings in a difference which is hard to align with the 6lo
protocols, whose design decisions apply in all parts of the protocol 
(header compression applied to all packets, addresses always short, etc).

I would like to understand, for example, what is constrained in RFC6568
vehicle telematics:
> LoWPANs play an important role in intelligent transportation systems.
> Incorporated into roads, vehicles, and traffic signals, they
> contribute to the improvement of safety in transportation systems.
> Through traffic or air-quality monitoring, they increase the
> possibility of traffic flow optimization, and they help reduce road
> congestion.

Air-quality monitoring happens on poles which have power by cable or by
large solar panels.  The hardware platform is typically something for
which gcc could output binaries, although maybe by cross-compilation.
The clock frequency is in the hundred to thousand MHz range. What else
is constrained?

The sending of data of these monitors is with long-range (hence high
power) radios.

> LoWPAN nodes for motion monitoring are incorporated into roads during road
> construction.

There are a number of kinds of nodes incorporated into roads during road 
construction.  Some of them have no communication ability and have a 
very primitive mechanical counting hundred years old.  Others more 
sophisticated have electronic computers to count, but no transmission 
facility.

I wonder which LoWPAN nodes have been shown as useful for this work and 
how do they work?

BEcause I know of other more sophisticated means (not low energy) which 
are deployed along roadways, like the 'portiques ecotax'.  They have 
enough computing power and energy at their disposal to compute and 
transmit data far away.  They use 802.11p in some cases.

>    The lifetime of LoWPAN nodes incorporated into roads is expected to
>    be as long as the lifetime of the roads (about 10 years).

I humbly suggest for some roads to correct the number of years - lower 
it to somewhere around 2-3 years, depending on weather and kind of soil.

> LoWPAN nodes in the roads run on
>    batteries.

Sorry, I am curious - which are these nodes?

>    Other applications may involve car-to-car communication for increased
>    road safety.

I wonder which car-to-car scenarios are considered?

I know some of them and how they are used but they are not constrained 
in terms other than being maybe linux platforms at 200-300MHz running on 
car's battery.  This is relatively high.

On another hand, I think that _inside_ the vehicle there may be a need 
of nodes which are constrained in terms of computing power (clock MHz) 
but have enough energy, and a reliable transmission link like copper or 
fiber.

I wonder whether 6lo would be appropriate in this case.

I have even seen plain blueetooth transmissions between vehicles but 
that obviously is limited in terms of distance range to a few tens of 
meters.  One would prefer 802.11p for these vehicle-to-vehicle 
transmissions for some applications like video transmissions.

For the shorter range V2V (bumper-to-bumper in traffic jams, obstacle 
avoidance during self-parking) there exist very simple means like radars 
at 60GHz that don't need IP, because the MAC typically sitting below it 
is too slow for these dimensions.

For the warnings from the automated-and-electric-vehicle to 
walker-wearing-noise-cancellation-headphones, I guess plain bluetooth 
would be necessary. (the vehicle is not constrained but the 
noise-cancellation headphones are).

YOurs,

Alex

> After just having spent an inordinate amount of time getting a
> terminology document for constrained node networks through the IESG
> (last DISCUSS cleared, now in final COMMENT disposition), I’m not
> looking forward to an endeavor creating such a wide-ranging
> document.
>
> (Looking back to RFC6568, the selection of use cases that made it in
>  there always seemed a bit arbitrary.  It still was a useful document
>  for introducing to the applications of wireless constrained node
> networks.  But that work is done.  Creating a “more use cases”
> supplement certainly is possible, but what specific work would it
> guide us in?  I’d rather define that work first, and then get a
> specific use cases document if that is needed for that work.)
>
> Grüße, Carsten
>
> _______________________________________________ 6lo mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/6lo
>

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 26 Feb 2014 02:30:31 +0000

Thanks Zhen for the comments and  perspective.

-Samita

-----Original Message-----
From: Cao,Zhen [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 11:35 PM
To: Samita Chakrabarti
Cc: [email-masked]
Subject: Re: [6lo] 6lo usecases?

Hi ALL,

RFC6568 covers 6 major use cases, industrial monitoring, structural monitoring, Connected Home, Vehicle Telematics, Healthcare, Agricultural Monitoring.

And the use cases were basically around the application of 802.15.4, while the 6lo working group is covering diverse types of L2.

I can at least envision the use cases such as: Environmental Monitoring, Smart Logistics and Tracking, Energy Management, and etc.

Regards,
Zhen

On Thu, Feb 13, 2014 at 10:32 AM, Samita Chakrabarti <[email-masked]> wrote:
> Hello 6lo-colleagues:
>
>
>
> Some time ago, 6lowpan (IPv6-over-IEEE 802.15.4) have worked on a 
> usecase draft http://tools.ietf.org/html/rfc6568.
>
>
>

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 26 Feb 2014 02:31:48 +0000

Sure.  Now that BT-LE can run 6lo stack.

Thanks,
-Samita
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 13, 2014 11:41 PM
To: [email-masked]; Samita Chakrabarti
Cc: [email-masked]
Subject: RE: [6lo] 6lo usecases?

Hi all,

Best regards,

Teemu

Hi ALL,

Regards,
Zhen

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 26 Feb 2014 03:06:38 +0000

Hi Carsten,

Please see in-line.

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Friday, February 14, 2014 12:10 AM
To: Samita Chakrabarti
Cc: [email-masked]
Subject: Re: [6lo] 6lo usecases?

What would that be?  Use cases for a working group?
[SC>]  It says if RFC 6568 covers  only 6lowpan usecases or  other L2-technology specific usecases as well ( for example wearbales].

Though defining usecases for a INT-area WG sounds less technical, it actually gives us real-life direction on the path we are taking.
Ie, What does it take to deploy the 6lo/6lowpan  technology?  What are the gaps today that might be applicable for 6lo WG to ponder over?
Where is this technology might be applicable for deployment? 

Seriously, 6lo is about getting IP running on link layer technologies appropriate for constrained node networks.
So our use cases are everything that involves constrained node networks.
[SC>] That's a quite generic statement.  Having a deployment picture is always helpful to make a technology successful.

==> We have enough interests in the WG to discuss different usecases/applicability.

After just having spent an inordinate amount of time getting a terminology document for constrained node networks through the IESG (last DISCUSS cleared, now in final COMMENT disposition), I'm not looking forward to an endeavor creating such a wide-ranging document.
[SC>]  We are not asking to generate a new document right away, but requesting the WG to evaluate the RFC6568 use-cases on 6lo applicability.

(Looking back to RFC6568, the selection of use cases that made it in there always seemed a bit arbitrary.  It still was a useful document for introducing to the applications of wireless constrained node networks.  But that work is done.  Creating a "more use cases" supplement certainly is possible, but what specific work would it guide us in?  I'd rather define that work first, and then get a specific use cases document if that is needed for that work.)
[SC>] 
[SC>]  If we think of '6lo' as a piece of code or header-compression technology over some constrained node L2-technolgy , it seems limiting.  Thinking of different use-cases might provide us thoughts about finding gaps, improvements, interworking with other IOT/m2m areas that we will not know if we don't ever think about applicability of our work that we are generating.

Discussion on use-cases does not necessarily mean writing up another big document  :-)

Cheers,
[SC>]

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 26 Feb 2014 03:23:05 +0000

The examples that Alex gave are quite intriguing.
Personally I am interested in finding out the requirements in different constrained or lossy-network scenarios, the new scenarios (with some details) that have never been used before, but it could be possible now with the IETF generated constrained node networks technologies.

-Samita

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Friday, February 14, 2014 10:43 AM
To: [email-masked]
Subject: Re: [6lo] 6lo usecases? vehicular and 6lo

A constrained node may be constrained in one dimension but very relaxed in others; or fully constrained node may  need to communicate to totally unconstrained node.  I'd say that most nodes are that way.

Let aside the totally constrained nodes (little RAM, small size, little battery, little movement range), there are many other nodes which are constrained in RAM but have high bandwidth, or high energy, or high speed of movement.

I think this brings in a difference which is hard to align with the 6lo protocols, whose design decisions apply in all parts of the protocol (header compression applied to all packets, addresses always short, etc).

> possibility of traffic flow optimization, and they help reduce road 

Air-quality monitoring happens on poles which have power by cable or by large solar panels.  The hardware platform is typically something for which gcc could output binaries, although maybe by cross-compilation.
The clock frequency is in the hundred to thousand MHz range. What else is constrained?

> LoWPAN nodes for motion monitoring are incorporated into roads during 
> road construction.

There are a number of kinds of nodes incorporated into roads during road construction.  Some of them have no communication ability and have a very primitive mechanical counting hundred years old.  Others more sophisticated have electronic computers to count, but no transmission facility.

I wonder which LoWPAN nodes have been shown as useful for this work and how do they work?

BEcause I know of other more sophisticated means (not low energy) which are deployed along roadways, like the 'portiques ecotax'.  They have enough computing power and energy at their disposal to compute and transmit data far away.  They use 802.11p in some cases.

>    be as long as the lifetime of the roads (about 10 years).

I humbly suggest for some roads to correct the number of years - lower it to somewhere around 2-3 years, depending on weather and kind of soil.

I know some of them and how they are used but they are not constrained in terms other than being maybe linux platforms at 200-300MHz running on car's battery.  This is relatively high.

On another hand, I think that _inside_ the vehicle there may be a need of nodes which are constrained in terms of computing power (clock MHz) but have enough energy, and a reliable transmission link like copper or fiber.

I have even seen plain blueetooth transmissions between vehicles but that obviously is limited in terms of distance range to a few tens of meters.  One would prefer 802.11p for these vehicle-to-vehicle transmissions for some applications like video transmissions.

For the shorter range V2V (bumper-to-bumper in traffic jams, obstacle avoidance during self-parking) there exist very simple means like radars at 60GHz that don't need IP, because the MAC typically sitting below it is too slow for these dimensions.

For the warnings from the automated-and-electric-vehicle to walker-wearing-noise-cancellation-headphones, I guess plain bluetooth would be necessary. (the vehicle is not constrained but the noise-cancellation headphones are).

YOurs,

Alex

> (last DISCUSS cleared, now in final COMMENT disposition), I'm not 
> looking forward to an endeavor creating such a wide-ranging document.
>
> networks.  But that work is done.  Creating a "more use cases"
> guide us in?  I'd rather define that work first, and then get a