Subject: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt

From: "Jetcheva, Jorjeta" <[email-masked]>
Date: Wed, 14 Sep 2011 11:32:03 -0700

Hello everyone,

Just wanted to draw your attention to the new iteration of the RPL AMI Applicability Internet-Draft (version 02).  We've made a few improvements to the draft based on feedback from the group received so far.  Thank you all who sent us questions, comments and suggestions!

Below is a brief summary of the changes:

- Expanded discussion of Trickle parameter setting considerations

- Updates related to battery operated meters and routing infrastructure

- Expanded discussion related to network topology characteristics

- Updates related to traffic characteristics

- Removed text discussing the benefits of multi-hop deployments vs. single-hop deployments

- Clarification and readability improvements

We look forward to your feedback as we work on improving the draft further!

Thanks, Jorjeta

<https://www.itron.com/>

Jorjeta Jetcheva, Ph.D.

Strategic Industry Standards and Architecture
Office of the CTO
Mobile: +1.408.688.1428
Knowledge to Shape Your Future

<http://twitter.com/#!/itron>    <http://www.facebook.com/ItronInc>     <http://www.linkedin.com/company/7550?trk=null>     <http://www.youtube.com/itronsmartmedia>

---

From: C Chauvenet <[email-masked]>
Date: Thu, 15 Sep 2011 02:00:04 -0700

Hi Jorjeta,

Thank you for the update, I think the doc brings additional valuable content in this new revision.

I have 2 comments about this new version of the draft :

In 2.2.1 : It is mentioned that the traffic in AMI networks will be highly asymmetric, and mostly narrowed to MP2P traffic.
I agree that most of the traffic in AMI will be sent by meters to the LBR. Though, as stated a little bit above in the doc, most of meters will be polled, resulting in P2MP traffic (unicast or multicast packets). So, my understanding is that if every meters is polled before sending its data, the traffic becomes symmetrical, because you have a 1:1 ratio between downward (LBR polling) and upward (Meter reporting) traffic.
Could you please help me to understand your statement ?
I think the traffic pattern may impact significantly the Storing Vs Non-Storing design choice.

In 4.1.4 : It is mentioned that Hop Count (HC) or Link Quality Level (LQL) may be suitable for energy constrained node much as water or gas meters.
I am not sure about the efficiency of Hop Count regarding energy consumption. As we are working in lossy networks, there is a great chance that the shortest path may not be the more reliable. So the shortest path may induce many MAC level retries (thus inducing a faster energy drop of the node, and a higher congestion of the channel), and decrease significantly the reliability. This could result in a path that cannot meet the requirements of AMI (regarding reliability especially). I guess you mentioned Hop count, because you get an minimum number of forwarder, thus reducing the number of devices involved in the path, and minimizing the impact of a packet in the global energy depletion of the global networks. I think this is very true in not-so-lossy networks, but I was wondering about lossy networks.
In my opinion, LQL may be more adapted. Maybe your were thinking about mixing Hop Count and LQL?
About energy, note that a specific metric has been designed in the rpl-metric-draft. It may be worth to mention it.

Best,

Cédric.

Le 14 sept. 2011 à 20:32, Jetcheva, Jorjeta a écrit :

Hello everyone,

Just wanted to draw your attention to the new iteration of the RPL AMI Applicability Internet-Draft (version 02).  We’ve made a few improvements to the draft based on feedback from the group received so far.  Thank you all who sent us questions, comments and suggestions!

Thanks, Jorjeta

<https://www.itron.com/>

Jorjeta Jetcheva, Ph.D.

<ATT00001..txt>

---

From: Nicolas DEJEAN <[email-masked]>
Date: Fri, 16 Sep 2011 10:08:19 +0200

Hello Cédric,

I will answer to your second comment.

I completely agree with you and this is excatly what is meant by "Hop Count
and Link Quality Level".
Moreover, the comment about an objective able to deal with more than one
metric in section 4.1.5 follows the same idea.
However, I agree that this is not clear enough in the draft and it will be
updated in the next release.
Something like a "combination of Hop Count and Link Quality Level" should
appear.

I also agree about the energy metric.
The next release will also be updated accordingly.

Cheers,

Nicolas.
2011/9/15 C Chauvenet <[email-masked]>

> In 2.2.1 : It is mentioned that the traffic in AMI networks will be highly
> asymmetric, and mostly narrowed to MP2P traffic.
> I agree that most of the traffic in AMI will be sent by meters to the LBR.
> Though, as stated a little bit above in the doc, most of meters will be
> polled, resulting in P2MP traffic (unicast or multicast packets). So, my
> understanding is that if every meters is polled before sending its data, the
> traffic becomes symmetrical, because you have a 1:1 ratio between downward
> (LBR polling) and upward (Meter reporting) traffic.
> In 4.1.4 : It is mentioned that Hop Count (HC) or Link Quality Level (LQL)
> may be suitable for energy constrained node much as water or gas meters.
> I am not sure about the efficiency of Hop Count regarding energy
> consumption. As we are working in lossy networks, there is a great chance
> that the shortest path may not be the more reliable. So the shortest path
> may induce many MAC level retries (thus inducing a faster energy drop of the
> node, and a higher congestion of the channel), and decrease significantly
> the reliability. This could result in a path that cannot meet the
> requirements of AMI (regarding reliability especially). I guess you
> mentioned Hop count, because you get an minimum number of forwarder, thus
> reducing the number of devices involved in the path, and minimizing the
> impact of a packet in the global energy depletion of the global networks. I
> think this is very true in not-so-lossy networks, but I was wondering about
> lossy networks.
> About energy, note that a specific metric has been designed in the
> rpl-metric-draft. It may be worth to mention it.
>
> Best,
>
> Cédric.
>
>
>   Hello everyone,****
> ** **
> Just wanted to draw your attention to the new iteration of the RPL AMI
> Applicability Internet-Draft (version 02).  We’ve made a few improvements to
> the draft based on feedback from the group received so far.  Thank you all
> who sent us questions, comments and suggestions!****
> ** **
> Below is a brief summary of the changes:****
> ** **
> - Expanded discussion of Trickle parameter setting considerations****
> - Updates related to battery operated meters and routing infrastructure***
> *
> - Expanded discussion related to network topology characteristics****
> - Updates related to traffic characteristics****
> - Removed text discussing the benefits of multi-hop deployments vs.
> single-hop deployments****
> - Clarification and readability improvements****
> ** **
> ****
> ** **
> Thanks, Jorjeta****
> ** **
> ** **
>    <https://www.itron.com/>****
>  *Jorjeta Jetcheva, Ph.D.***
>  Strategic Industry Standards and Architecture****
> Office of the CTO
> Mobile: +1.408.688.1428
> Knowledge to Shape Your Future****
>   <http://twitter.com/#!/itron>   <http://www.facebook.com/ItronInc>
>     <http://www.linkedin.com/company/7550?trk=null>
>  <http://www.youtube.com/itronsmartmedia>****
> ** **
> ** **
> <ATT00001..txt>
>
>
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: "Jetcheva, Jorjeta" <[email-masked]>
Date: Fri, 16 Sep 2011 09:10:37 -0700

Hello Cédric,

Thank you for your comments.  Since Nicolas already addressed your second question, let me try to address the first one.  Most of the traffic tends to be towards the LBR in terms of bytes (reports are typically much bigger than queries), but also in terms of number of packets, e.g., some reports have to be split into multiple packets due to packet size limitations, periodic reports can be sent without requiring each of them to be triggered by a query, and there are unsolicited events like alarms and outage notifications generated by the meters as well.   Does this answer your question?

Clearly there is room for clarification in the text, so we will update it accordingly.  Thanks again!

Jorjeta

<https://www.itron.com/>

Jorjeta Jetcheva, Ph.D.

From: C Chauvenet [mailto:[email-masked]]
Sent: Thursday, September 15, 2011 2:00 AM
To: Jetcheva, Jorjeta
Cc: [email-masked]
Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt

Hi Jorjeta,

Best,

Cédric.

Hello everyone,

Thanks, Jorjeta

<https://www.itron.com/>

Jorjeta Jetcheva, Ph.D.

<ATT00001..txt>

---

From: C Chauvenet <[email-masked]>
Date: Fri, 16 Sep 2011 09:39:01 -0700

Hi,

Thank your for the clarification.
It fully adress my question.

Cédric.

De : Jetcheva, Jorjeta [mailto:[email-masked]]
Envoyé : vendredi 16 septembre 2011 18:11
À : C Chauvenet
Cc : [email-masked]
Objet : RE: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt

Hello Cédric,

Jorjeta

<https://www.itron.com/>

Jorjeta Jetcheva, Ph.D.

Hi Jorjeta,

Best,

Cédric.

Hello everyone,

Thanks, Jorjeta

<https://www.itron.com/>

Jorjeta Jetcheva, Ph.D.

<ATT00001..txt>

---

From: "Salazar, Ruben" <[email-masked]>
Date: Fri, 16 Sep 2011 23:14:43 +0200

I would like to add to Jorjetta's note: The section that Cedric identifies 2.2.1 refers only to the Smart Meter Data application of the AMI network: for that application somewhere around 90% of the traffic generated comes from scheduled activities in each meter, reporting of metering data and status data, that can be originated in the meter without need for polling, thus creating the asymmetric aspect of this application. There will be symmetric activities, polling, but they represent a reduced percentage of the traffic.
There may be, though, implementations where the reporting of metering data and status data is also handled using polling schemes.
Regards

Ruben Salazar
Director Research and Technology
Landis+Gyr
Energy Management Solutions
Office: +1 678 258 3165
[email-masked]<mailto:[email-masked]>
www.landisgyr.com<http://www.landisgyr.com/>
manage energy better

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jetcheva, Jorjeta
Sent: Friday, September 16, 2011 12:11 PM
To: C Chauvenet
Cc: [email-masked]
Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-ami-02.txt

Hello Cédric,

Jorjeta

<https://www.itron.com/>

Jorjeta Jetcheva, Ph.D.

Hi Jorjeta,

Best,

Cédric.

Hello everyone,

Thanks, Jorjeta

<https://www.itron.com/>

Jorjeta Jetcheva, Ph.D.

<ATT00001..txt>