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

[Joydeep Tripathi <[e-mail]>]

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.
>
> - om_p
>