Re: [6lowapp] Next version of charter proposal up on 6lowapp.net

"Van Der Stok, Peter" <peter.van.der.stok@philips.com> Mon, 09 November 2009 06:21 UTC

Return-Path: <peter.van.der.stok@philips.com>
X-Original-To: 6lowapp@core3.amsl.com
Delivered-To: 6lowapp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AEAE3A6906 for <6lowapp@core3.amsl.com>; Sun, 8 Nov 2009 22:21:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRmbrTFtHSeT for <6lowapp@core3.amsl.com>; Sun, 8 Nov 2009 22:21:26 -0800 (PST)
Received: from smtpx.philips.com (smtpx.philips.com [168.87.56.20]) by core3.amsl.com (Postfix) with ESMTP id F12503A6867 for <6lowapp@ietf.org>; Sun, 8 Nov 2009 22:21:24 -0800 (PST)
Received: from NLAMSEXH05.connect1.local (172.16.153.68) by connect1.philips.com (172.16.156.49) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 9 Nov 2009 07:21:55 +0100
Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLAMSEXH05.connect1.local ([172.16.153.68]) with mapi; Mon, 9 Nov 2009 07:21:46 +0100
From: "Van Der Stok, Peter" <peter.van.der.stok@philips.com>
To: "Stuber, Michael" <Michael.Stuber@itron.com>, Henning Schulzrinne <hgs@cs.columbia.edu>
Date: Mon, 9 Nov 2009 07:21:42 +0100
Thread-Topic: [6lowapp] Next version of charter proposal up on 6lowapp.net
Thread-Index: Acpg7EHSqCwYTL9MRde0iQ+w34l5bQAAjpmQAAV5s1A=
Message-ID: <B5584ABB89131542BEA01BFAF71A73877FD30AFC4C@NLCLUEXM03.connect1.local>
References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org><4AF77C65.3050309@ cisco.com><517197C5-5B51-4A0F-9E18-6DC876EB971C@cs.columbia.edu><05C6A38D73 2F1144A8C4016BA4416BFE0242D03C@SPO-EXVS-02.itron.com><7F90BA96-1AC8-4DBF-9F76-5B200CA118D4@cs.columbia.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D03E@SPO-EXVS-02.itron.com>
In-Reply-To: <05C6A38D732F1144A8C4016BA4416BFE0242D03E@SPO-EXVS-02.itron.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "6lowapp@ietf.org" <6lowapp@ietf.org>
Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net
X-BeenThere: 6lowapp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>, <mailto:6lowapp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowapp>
List-Post: <mailto:6lowapp@ietf.org>
List-Help: <mailto:6lowapp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowapp>, <mailto:6lowapp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2009 06:21:28 -0000

Although I agree with the not challenged statement, a few updates:
I expect a presence detector to send out a message once per second or per 10 seconds
There may be 1 till 100 in one wireless mesh, dependent on office lay-out.
The crux comes when an alarm hits. Then we will have an avalanche of messages and some can be just thrown away and a few need to be sent on through the routers to some central post(s)regardless. There is the challenge of overload handling.

Peter


-----Original Message-----
From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Stuber, Michael
Sent: Monday 9 November 2009 4:49
To: Henning Schulzrinne
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net

The amount of bandwidth required per applications varies a great deal.
Some devices, like light switches, or battery powered sensors may only
send a message or two per day.  Other devices such as energy usage
monitors or electric vehicles may send a large number of updates.
Electric meters may send current usage information to in-home displays
every 10 seconds.  Electric cars may start with an extended exchange to
negotiate a charging regime, followed by periodic updates to in-home
displays regarding the device's state of charge.

Most of the networks that I worry about are indeed likely to be small
(>30 nodes); however, there are places where folks have been running
larger smart energy networks for meter data collection that are upwards
of thousands of nodes.  The 802.15.4 T4G SUN work is likely to expand
this trend.  Starting with efficient protocols provides headroom for
growth in the application later.

-----Original Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
Sent: Sunday, November 08, 2009 7:25 PM
To: Stuber, Michael
Cc: Benoit Claise; 6lowapp@ietf.org
Subject: Re: [6lowapp] Next version of charter proposal up on
6lowapp.net

Right, but the bandwidth per device is really, really low. How many bits
do you send each day to a thermostat or light switch? Are there any
measurements of the realistic signaling load in such networks?

I'm worried about artificially constraining the solution space to solve
a practical non-problem.

Henning

On Nov 8, 2009, at 10:18 PM, Stuber, Michael wrote:

> Keep in mind though, that much of that bandwidth is shared on these
> networks  In an 802.15.4 environment, devices will share a single
> channel.  If this work is successful there will be many constrained
> nodes within the network, rather than a single pair of nodes.
>
> -----Original Message-----
> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On
> Behalf Of Henning Schulzrinne
> Sent: Sunday, November 08, 2009 6:33 PM
> To: Benoit Claise
> Cc: 6lowapp@ietf.org
> Subject: Re: [6lowapp] Next version of charter proposal up on
> 6lowapp.net
>
> I find this conflation of Smart Energy/HAN and LowApp confusing.
> Most of
> the in-home networks are not exactly "challenged". Even ZigBee has 250

> kb/s (or 20 kb/s in the lowest-bandwidth mode), i.e., equivalent to
> early DSL or 1990's modems.
>
> Henning
>
> On Nov 8, 2009, at 9:20 PM, Benoit Claise wrote:
>
>> Carsten,
>>
>> Thanks for the new charter proposal.
>>
>> - "This WG is concentrating on requirements from energy (e.g. Smart
>> Energy 2.0) and building management applications."
>> Is the goal to describe these requirements in the "objectives and
>> architecture" document?
>> If not, where can we understand those requirements from?
>> The following were mentioned on the list:
>>
>> There are a lot of use cases to start with.  Here is a starter set:
>> 1)  OpenHAN:
>>
>> http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20-
>> %20v1.04%20-%
>> 200808
>>
>> 19-1.pdf
>> 2)  SmartGridipedia:
>>
>> http://www.smartgridipedia.org/index.php/Category:Use_Cases
>> , both the
>> Intelligrid and Southern California Edison use cases are good
>> 3)  ZigBee/HomePlug Market Requirements and Use Cases (which we are
>> using for our Smart Energy V2 work):
>>
>> http://www.homeplug.org/products/ZBHP_SE_MRD_090624.pdf
>> Any other ones?
>>
>> "The framework will also specify specify a way to support interface
>> profiles, ..."
>> Can you expand on "interface profile".
>>
>>
>> "A document with operation and management advice about running a
>> network using these applications."
>> Is advice the right word? It seems like one or two advices are
>> sufficient to manage the network ;-)
>>
>>
>> Regards, Benoit.
>>> I have put a new version of the WG charter proposal on the wiki page

>>> at http://6lowapp.net =
>>> http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp
>>> (charter text is at the end of the page).
>>>
>>> Obviously, I could not pick up every comment that was on the list
>>> (they were partially going in conflicting directions), but please do

>>> comment on the new version.
>>>
>>> Gruesse, Carsten
>>>
>>> _______________________________________________
>>> 6lowapp mailing list
>>> 6lowapp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6lowapp
>>
>> _______________________________________________
>> 6lowapp mailing list
>> 6lowapp@ietf.org
>> https://www.ietf.org/mailman/listinfo/6lowapp
>
> _______________________________________________
> 6lowapp mailing list
> 6lowapp@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowapp
>

_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.