Hi Maxence,On Oct 13, 2009, at 12:09 AM, Maxence Dalmais wrote: Hi JP,
The fact is that sending a high energy cost packet won't be a problem for a mains powered node, but it will induce noise and impact the links of the entire network.
That is a second order effect though and not true for PLC link. It is bit of a stretch to choose a low energy path, because of a high energy path may cause increase noise along that path thus leading to more errors ... don't you think ?
Personnaly I don't think.
Using high energy path will include more errors to others transmissions, ie increase retransmissions, ie increase the ETX metric. This may involve modifications in the chosen path.
I am saying that when using wireless links, a node should be aware that his communication could interfere with other communication.
Less powered is the transmission signal, less noise is seen by neighbours.
A low powered node will also need less energy to communicate in a less noisy environnement.
Bear in mind, that you do not know this environment so this may lead you to an incorrect conclusion. The real metric is the link reliability, which reflect the properties of the environment.
Furthermore, this does not apply to PLC links. So, it appears to me logical that when others metrics are egals to choose the less power needed links.
As said somewhere else, the final metric should be a computation of different metrics.
This is the objective function.
JP. I think that including the energy cost in the computation could be a little great idea. Yes but how would you expect "host" to use that information to select the router ?
It may very well be that the router offering the lower energy cost end up following a high energy path.
[In [Roll] RPL Metric I-D from JP Vasseur to Alexandru Petrescu about link energy information in RA ]
That means that we need end-to-end energy-cost metric to balance the route. Maybe we need 2. The first being a sum of product of the power consumption to send the packet with the needs to save energy (ie the mains powered nodes won't be include having a nul needs to save energy). End-2-End Energy Cost Metric = sum for i in 0 to path_length : powerConsumption (i,i+1) * savingEnergyNeeds(i) The second one is more subject to discussion. Experimentation results of such an idea could help to make a choice. The idea is to get a representation for the inconvenience to other nodes to transmit a packet on the specific link. This is very different from the classical best effort, but maybe one of the first think to do to improve quality in Lossy wireless Network is to reduce the perceived noise. Here is my point of view, Maxence. HI Maxence, On Oct 12, 2009, at 5:00 PM, Maxence Dalmais wrote: Hi JP,
The fact is that sending a high energy cost packet won't be a problem for a mains powered node, but it will induce noise and impact the links of the entire network.
That is a second order effect though and not true for PLC link. It is bit of a stretch to choose a low energy path, because of a high energy path may cause increase noise along that path thus leading to more errors ... don't you think ?
Personnaly I don't think.
Using high energy path will include more errors to others transmissions, ie increase retransmissions, ie increase the ETX metric. This may involve modifications in the chosen path.
you are basically saying that we should not use high energy links .... Maybe we could think that we don't need to take energy path into account the because ETX will automatically adapt to this.
that is the aim of using ETX But having a highly dynamic ETX may cause others trouble, don't you think ?
of course, this is true for ALL dynamic metrics. Maybe, energy path has to be taken in count in RPL to avoid the need of a very dynamic ETX and retransmissions.
I think that when designing a new specialized protocol, we shouldn't be affraid of developing new idea.
we're not afraid ;-) but we learned from experience (look at the dynamic metric of ARPANET 2). - Hide quoted text -
Does anyone have experience with such an altruistic routing protocol ?
Cheers,
Maxence.
_______________________________________________
Roll mailing list
Roll at ietf.org
https://www.ietf.org/mailman/listinfo/roll
|
