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

["Don Sturek" <[e-mail]>]

Have a look at the 6LowAPP presentation at the BOF.   There is a slide
outlining a typical CPU used on such a system.

 

There is not a single set of network constraints or topologies.   There are
many networks deployed today using IEEE 802.15.4.  Many of these networks
run proprietary or vendor consortium standards (non-IP).  The 6LowAPP
problem statement (and 6LowPAN) capture what is needed to displace these
solutions with IP.

 

Don

 

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Arjun
Roychowdhury
Sent: Monday, November 09, 2009 6:35 AM
To: [e-mail]
Cc: Benoit Claise; Van Der Stok, Peter; Stuber, Michael; [e-mail]
Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net

 

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]] 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]]
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]] 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