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

"Stuber, Michael" <Michael.Stuber@itron.com> Mon, 09 November 2009 03:48 UTC

Return-Path: <Michael.Stuber@itron.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 49E9D3A6924 for <6lowapp@core3.amsl.com>; Sun, 8 Nov 2009 19:48:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 uVJ1s7avr-FF for <6lowapp@core3.amsl.com>; Sun, 8 Nov 2009 19:48:19 -0800 (PST)
Received: from mailer-1.itron.com (mailer-1.itron.com [198.182.8.121]) by core3.amsl.com (Postfix) with ESMTP id 140733A691E for <6lowapp@ietf.org>; Sun, 8 Nov 2009 19:48:19 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 8 Nov 2009 19:48:44 -0800
Message-ID: <05C6A38D732F1144A8C4016BA4416BFE0242D03E@SPO-EXVS-02.itron.com>
In-Reply-To: <7F90BA96-1AC8-4DBF-9F76-5B200CA118D4@cs.columbia.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [6lowapp] Next version of charter proposal up on 6lowapp.net
Thread-Index: Acpg7EHSqCwYTL9MRde0iQ+w34l5bQAAjpmQ
References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org><4AF77C65.3050309@cisco.com> <517197C5-5B51-4A0F-9E18-6DC876EB971C@cs.columbia.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D03C@SPO-EXVS-02.itron.com> <7F90BA96-1AC8-4DBF-9F76-5B200CA118D4@cs.columbia.edu>
From: "Stuber, Michael" <Michael.Stuber@itron.com>
To: "Henning Schulzrinne" <hgs@cs.columbia.edu>
Cc: 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 03:48:20 -0000

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
>