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

[Arjun Roychowdhury <[e-mail]>]

Okay, I am sorry, I am very confused now. Can someone please point me to a
resource where I can read up what are the constraints for HAN devices this
group is talking about, specifically:

a) CPU constraints (and what sort of devices this applies/does not apply to)
b) Network constraints
c) What is the network topology for which modelling needs to be done to
figure out whether a protocol is appropriate or not?

I see numbers being talked about in this list and while discussing the
charter, but I am unable to see a clear modeling that arrives at those
numbers.

regds
arjun

On Mon, Nov 9, 2009 at 6:30 AM, Don Sturek <[e-mail]> wrote:

>  250 Kbps is the theoretical maximum on the data link.   Considering back
> offs and other required channel operations (CSMA) the maximum you will see
> in practice is about 140 Kbps.
>
>
>
> Next, the 140 Kbps is from point to point (a device to its neighbor).
> Depending on the network topology and the data transfer characteristics (for
> example, if you had an application where predominant traffic is MP2P where
> all devices in a multihop network were to send data to a single access
> point) you might see less than 10K bps at the concentrator (again, depends
> on the data traffic model, the frequency of data transfer, the number of
> hops from leaf nodes in the network to the concentrator, etc.).
>
>
>
> Don
>
>
>
>
>
> *From:* [e-mail] [mailto:[e-mail]] *On
> Behalf Of *Benoit Claise
> *Sent:* Sunday, November 08, 2009 11:15 PM
> *To:* Van Der Stok, Peter
> *Cc:* Stuber, Michael; [e-mail]
>
> *Subject:* Re: [6lowapp] Next version of charter proposal up on
> 6lowapp.net
>
>
>
> From the requirement/use case remark in my initial email, I wanted to
> understand: how many constrained nodes in a single constrained network must
> share the 250kbit/s? For example, in case of discovery, concurrent events,
> concurrent queries, etc.
> IMHO, this is an important input for the protocol design, which I didn't
> get from the BOF.
>
> Regards, Benoit.
>
>  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: [e-mail] [mailto:[e-mail] <[e-mail]>] On Behalf Of Stuber, Michael
>
> Sent: Monday 9 November 2009 4:49
>
> To: Henning Schulzrinne
>
> Cc: [e-mail]
>
> 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:[e-mail] <[e-mail]>]
>
> Sent: Sunday, November 08, 2009 7:25 PM
>
> To: Stuber, Michael
>
> Cc: Benoit Claise; [e-mail]
>
> 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: [e-mail] [mailto:[e-mail] <[e-mail]>] On
>
> Behalf Of Henning Schulzrinne
>
> Sent: Sunday, November 08, 2009 6:33 PM
>
> To: Benoit Claise
>
> Cc: [e-mail]
>
> 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
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/6lowapp
>
>
>
>  _______________________________________________
>
> 6lowapp mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/6lowapp
>
>
>
> _______________________________________________
>
> 6lowapp mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/6lowapp
>
>
>
>
>
>
>
> _______________________________________________
>
> 6lowapp mailing list
>
> [e-mail]
>
> 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.
>
> _______________________________________________
>
> 6lowapp mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/6lowapp
>
>
>
>
>
> _______________________________________________
> 6lowapp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowapp
>
>
>
>
>
>
>
> *********************************************DISCLAIMER*********************************************
> The email is subject to Disclaimer as per -
> http://www.hsc.com/tabid/91/Default.aspx#emaildisclaimer
>
>
>


-- 
Arjun Roychowdhury