Re: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-01

[Philip Levis <[e-mail]>]

On Dec 29, 2009, at 5:11 PM, Joydeep Tripathi wrote:

> On Tue, Dec 29, 2009 at 7:17 PM, Omprakash Gnawali
> <[e-mail]> wrote:
>> On Tue, Dec 29, 2009 at 6:58 PM, Joydeep Tripathi
>> <[e-mail]> wrote:
>>> Hi,
>>> 
>>> On Thu, Dec 24, 2009 at 2:25 AM, Philip Levis <[e-mail]> wrote:
>>>> 
>>>> On Dec 23, 2009, at 10:24 PM, Joydeep Tripathi wrote:
>>>> 
>>>>> On Wed, Dec 23, 2009 at 2:52 AM, Omprakash Gnawali
>>>>> <[e-mail]>
>>>>>  wrote:
>>>>>> 
>>>>>> I managed to find the pdf with the graphs. Here are some comments.
>>>>>> 
>>>>>> It will help greatly if more information about the link model were
>>>>>> included. -01 mentions:
>>>>>> 
>>>>>> "* Link failure model: Time varying real network traces containing
>>>>>> packet delivery probability for each
>>>>>> link and over all channels for both indoor network deployment and
>>>>>> outdoor network deployment were used.
>>>>>> Thus, di erent types of link characteristics are used in the study.
>>>>>> * Topology: The topologies are gathered from real-life deployment
>>>>>> (traces mentioned above) as opposed
>>>>>> to random topology simulations. are repeated here:"
>>>>>> 
>>>>> Actually,we collected real-life traces with hundreds of links varying
>>>>> with time for the network,  and simulated the same variation in PDR
>>>>> for each link as in the real deployment.
>>>> 
>>>> I don't understand -- how do you do this? There has to be some interval over
>>>> which you average, unless you are replaying success/failure traces. Link can
>>>> very much faster than every ten seconds.
>>> 
>>> Actually you are right, the PDR value of a link is averaged over 100
>>> packets over an interval. When the trace was gathered, during each 15
>>> minutes interval, 100 packets are transmitted over a link in the
>>> network. Out of 100 packets, number of successfully received packets
>>> was count for each link between two communicating nodes that are
>>> physically one hop away. The number of successfully received packets
>>> out of 100 packets originally transmitted was recorded as the PDR of
>>> the link after each 15 minutes interval. In our simulation, we
>>> consider the PDR between those two nodes to be constant during a 10
>>> minutes interval. When an interval gets over, we consider the next PDR
>>> value between same two nodes in the database of traces, that was
>>> collected during the next interval and use that value for next
>>> interval.
>>> 
>>> I hope this clarifies how the link quality traces are gathered and
>>> used. Please let me know if you have further questions.
>> 
>> Each node sends a packet every 9 seconds to estimate the link quality
>> and the estimate is updated every 100 packets?
>> 
>> Do you consider datarate in your simulation?
> 
> When the link  trace was gathered, I believe the intention was to
> check how the connectivity between the nodes vary over time. The trace
> reflects the quality of the links between the nodes, and the packets
> used for trace gathering in real implementation did not use RPL
> headers. However, in our simulation, we considered RPL headers, MAC
> headers etc. For simulation, we also used specifications of TelosB
> CC2420 radio, which has a datarate of 250 Kbps.
> 
>> I did not understand why data collection uses a window of 15 mins and
>> data use uses a window of 10 mins.
> 
> The simulation used a 10 minute window to update PDR for every link.
> However, in simulation also, the links have same temporal
> characteristics as seen in the real link quality trace gathering. The
> 10 minutes interval is just to make the simulation generic to other
> gathered traces from other deployment as well. There may be traces
> which update the link quality after an interval other than 15 minutes
> (we do have such traces). We will include samples of link quality (in
> terms of PDR) in our next revision as well.

Jodeep,

It's worth noting that links can vary as quickly as 500ms or less[1]. So 10 minute variations ignore some of the short-term dynamics you might see. This is especially important for problems like establishing an efficient yet reasonably stable tree.

Phil

[1] Kannan Srinivasan, Maria A. Kazandjieva, Saatvik Agarwal, Philip Levis: The beta-factor: measuring wireless link burstiness. SenSys 2008: 29-42