Re: [Roll] Moving forward with the protocol work

[[e-mail]]

Hi Julien,

Section 3 of the Building Requirements ID describes the typical devices 
and device densities in a commercial building; Section 6 describes the 
traffic flow.  Let me try to reiterate here ...

The building control application domain includes Heating Ventilation and 
Air Conditioning (aka HVAC), Physical Security, Lighting, Elevator and 
Fire control.  While each has its nuances, they all fall roughly onto the 
same topology.  The leaf layer for these systems are the sensors.  There's 
a plethora of them including temperature sensors, humidity sensors, 
pressure sensors, tamper switches, C02, C0, smoke detectors, occupancy 
sensors, light switches, and the list goes on.  In a room, you might 
expect a temp sensor, a humidity sensor, an occupancy sensor, solar 
sensor, smoke detector and light switches. 

Now along with the room sensors, there are room actuators and room 
controllers.  The controllers receive the environmental data from the 
sensors, and determine the necessary control based on conditions, system 
overrides, time-of-day, etc and then control the environment by tweaking 
the actuators accordingly.  The HVAC system will modulate the airflow and 
augment heating/cooling.  The shade controller will sense solar load and 
adjust the shades.  The lighting will be adjusted as requested by the 
presentation mode.  When I talk about a room, I am not meaning necessarily 
only a closed door meeting room.  This would also apply to public spaces 
such as an attria, hallways, ballrooms.etc.  The key ingredient in this is 
that each of these areas has a self contained sensor/controller/actuator 
subsystem.

Now, the next layer of controllers are the zone and area controllers. 
These are higher level devices that supply the facility with more global 
control systems.  HVAC will have air handlers that supply fresh air to the 
rooms.  Chillers that support cold air to the rooms, boilers that supply 
heat.  Lighting panels will control whole floors rather than simply rooms. 
 The point being that these higher order devices are also LLN devices 
incorporating another whole set of sensors such as outdoor air temp, 
relative humidity, etc.

With regards to your question about layer 2, at present these devices are 
not IP devices.  They typically reside on an EIA-485 network.

Hope this helps,

Jerry





"Julien Abeille (jabeille)" <[e-mail]> 
07/30/2009 11:07 AM

To
<[e-mail]>, "Mischa Dohler" <[e-mail]>
cc
"ROLL WG" <[e-mail]>, <[e-mail]>
Subject
RE: [Roll] Moving forward with the protocol work






Hi Jerald,
 
just to understand better the setup in commercial buildings: in a typical 
scenario,  which devices / how many are present in a room, what is the 
layer 2 topology and the p2p application flows?
 
Thank you,
Julien

From: [e-mail] [mailto:[e-mail]] On Behalf Of 
[e-mail]
Sent: jeudi 30 juillet 2009 17:58
To: Mischa Dohler
Cc: ROLL WG; [e-mail]
Subject: Re: [Roll] Moving forward with the protocol work



Hi Mischa, 

Nearly all communication in a commercial building facility management 
system is point to point.  I'm surprised the other three requirements 
don't also have a strong p2p requirement.  Back in the early 80's prior to 
processor based sensors, we deployed 'dumb sensors' that would simply 
upload their current environmental information to a centralized 
minicomputer.  This centralized model was not scalable nor fault tolerant. 
 That is if the minicomputer 'blew a gasket', the entire building went out 
of control. 

As soon as it was economically viable, we decentralized control by moving 
it down into the rooms.  Now each room was controlled independently with 
an array of room sensors and room controllers.  Now if a controller 
failed, only the room might lose control, not the entire complex.  The 
room controllers were then further controlled by higher level controllers. 
 This distributed architecture has been in place for 25 years and is the 
mainstay of building control.   

My point is that is the Commercial Market the LLN is not just a path for 
moving data nortbound.  Most of the packets sent on the LLN are destined 
to other nodes on the LLN.  They all require application ACKs.  About 20% 
of the packets are destined to the LBR and onwards.  These are event 
packets being sent to the higher layers for further analysis. 

If we don't support a robust p2p protocol option in ROLL, we will knock 
out the Building Market in its entirety which means at best you will only 
solve 75% of the need. 


Jerry 




Mischa Dohler <[e-mail]> 
Sent by: [e-mail] 
07/29/2009 04:18 PM 


To
JP Vasseur <[e-mail]> 
cc
ROLL WG <[e-mail]> 
Subject
Re: [Roll] Moving forward with the protocol work








JP, all,

We should use this early design stage to come up with one solution - one 
solution which is not necessarily optimum for all cases but for the 
(e.g.) 95% quantile. The PHY guys learned to live with such an approach. 
The MAC folks are getting there and we should take our chance now. 95% 
means clearly to concentrate on the core issues, of which loop 
detection/avoidance, p2p and security are somehow still open.

I do understand the concept of loops arising. I have doubts that with 
the dynamics of typical ROLL networks, these will give us headaches 
within this 95% application quantile. I have read tons of papers 
produced in the last decade on routing in ROLL-type networks. Loop 
detection and avoidance was clearly not something people (including 
those doing practical rollouts and running their companies today) were 
worried about too much. Unless somebody provides me with a convincing 
study, I propose to merely adopt some simple and possibly sub-optimum 
heuristics and then forget about it.

P2P seems to worry some of us (sorry, Jerry, for having forgotten about 
the p2p paragraph). However, again, are we talking about the 95% 
quantile here? Furthermore, how much p2p exactly are you talking about? 
Any node truly to any node? Are we back to pure ad hoc then? I guess if 
IETF couldn't provide us with a magic ultra low power solution for ad 
hoc networks in past years, then chances are slim that this will work 
out now. Unless somebody provides me with a convincing study that 
adopting a general p2p ROLL protocol will not jeopardize the efficiency 
of the 95% quantile applications, I propose to adopt some simple and 
possibly sub-optimum heuristics and then forget about it.

Security is an important issue.

Now that we are at it, I sampled quite a large number of companies at an 
 M2M event in Paris a few months ago organized by Orange where we met 
with JP and others. The large majority of companies present there 
explicitly told me that - for a very varying set of reasons - they would 
never let IP run over their ROLL-type networks. The sheer majority did 
suprise me. We still have a lot of work ahead.

I am in favour of adopting draft-dt-roll-rpl-01 as a WG document.

Mischa.






JP Vasseur wrote:
> Dear WG,
> 
> First of all, thanks for all the time and energy you all have devoted 
> during the past few weeks on the protocol work. There was excellent 
> followup discussion at the physical WG meeting.
> 
> To the question "Do you think that RPL provides an adequate foundation 
> for the ROLL routing protocol work", there was clearly a good consensus 
> in the WG meeting. It was also recognized there are still several open 
> issues for which we WILL need help from many WG contributors, including 
> the authors of other documents.
> 
> Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 
> as a WG document ?
> 
> Then we will of course move to the next step.
> 
> Thanks,
> 
> JP and David
> 
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/roll