Preliminary results about MPL performance evaluation
CEA
http://www.cea.fr
France
Pierre.Roux@cea.fr
CEA
http://www.cea.fr
France
Alexandru.Petrescu@cea.fr
CEA
http://www.cea.fr
France
Mounir.Kellil@cea.fr
Internet
Network Working Group
MPL, Tricle Multicast, evaluation
This draft presents simulation work and first results related to MPL performance evaluation.
The simulation makes it possible to evaluate MPL performances in the context of a large network.
The simulated network introduces 500 nodes. The general principles of the simulator are described.
Then reference settings are introduced, and evaluation indicators are proposed.
Finally preliminary results are presented under the form of a few tables, that show the proposed indicator
values depending on some specific parameter which is used as a variable argument.
Among various results, the advantage of using reactive mode for MPL is shown
in terms of the capability to maintain loss free diffusion in harsh radio conditions.
The RPL protocol is an IPv6 protocol for low-power and lossy
networks, defined in .
The draft introduces the so called MPL algorithm,
with a lot of freedom in terms of possible configuration. The current draft is a preliminary attempt
to provide guidance for finding good algorithm settings for MPL.
Simulation makes it possible to address algorithmic capabilities in terms of scalability.
A network made of 500 nodes is considered in this document.
The proposed objective is to assess performance of the MPL protocol in such large networks, and to compare various MPL settings,
in order to understand their influence on performances, so that setting guidelines may be derived.
However, the presented results are still not mature enough to propose solid and motivated guidelines.
This draft should be considered as a preliminary attempt in this direction.
Depending on the feedback, a more complete set of results may be presented in the coming months.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
RFC 2119.
A reference network layout has been assumed for all
simulations. It is composed of 500 nodes randomly distributed
within a rectangular area, excluding a void sub-area in its center, as shown in Figure 1.
The main area width is 20 km and the height is 10 km.
The void sub-area is 2 km and its height is 5 km.
The layout is built by dropping nodes randomly in the main area.
Once a potential node has been dropped at a random location in the main area,
it is retained only if it is not located in the void sub-area,
and if its closest neighbour among previously defined nodes, is not closer than 20 meters.
This process continues until 500 nodes has been retained in the area.
Then the closest node to the point of coordinates (x=2km,y=5km) is selected as the seed node.
The simulator elementary time step has been set in such a way
that it takes 4 elementary steps for a sender to send the
longest messages, which are supposed not to exceed 128
bytes. The simulator doesn't address anything below this time
step. As an example the simulator doesn't actually fill
messages with bits.
At each elementary step, the simulator spans each node in the
network several times in order to:
Check data trickle timers and control trickle timer (if
one exists).
Treat incoming messages.
Take care of (data or control) message transmission (start, continue or complete a message transmission).
As said above, only a fragment of a message can be transmitted
during an elementary time step of the simulator. The term of
fragment, as used in this document, refers to the part of a
message which can be transmitted during an elementary
simulator step time.
The radio coverage radius if set to 100m, which means that beyond this
distance, no fragment can be transmitted between 2
nodes. Below this distance, there is a probability for a
transmitted fragment to be received which depends on the
simulated power received at the receiver.
The static attenuation in dB is assumed to be equal to 50 +
30.log10(d/50), with d in meters, which means that we
assume 3 as the path loss exponent. A log normal shadowing with
3 dB as standard deviation is added as a dynamical
attenuation. Dynamical attenuation spectrum is limited with a 3
Hz cut off frequency.
A fragment being sent may not be received (or corrupted) at
the receiver depending on a probability which is bound to the
received level at the receiver at the receiving time. A
predefined table defines the probability for a fragment to be
received depending on the received power.
For a message to be transmitted between a sender and a
receiver it is necessary that all segments involved in the
message are received uncorrupted. Otherwise, the message is
assumed to be lost (because of the UDP checksum mechanism, it
is assumed that a message received corrupted is also a non
delivered UDP message). If any segment has been lost then the
message is lost as well.
Collisions are simulated as well: if a receiver receives
fragments from multiples neighbour nodes under its coverage,
then a collision may occur for the received fragment. For a
message to be delivered, it is necessary that no collision
occurs on any fragment of this message. A collision condition
occurs if the received power from a first neighbour is
interfered with the received power from one or a set of other
neighbours which a total interfering power which is equal at
least to half the useful received power from the first
neighbour.
When not explicitly stated, preliminary results
are obtained with the following parameter values:
Parameter
Value
Maximum number of messages in buffer message set
10
Seed message rate
1 per each 4 seconds period
Number of messages sent during one simulation
200
DATA_MESSAGE_IMIN
1.28 second (128 simul. steps)
DATA_MESSAGE_IMAX
10 (max interval = 21 minutes)
DATA_MESSAGE_K
1
DATA_MESSAGE_TIMER_EXPIRATIONS
No expiration
CONTROL_MESSAGE_IMIN
128
CONTROL_MESSAGE_IMAX
10
CONTROL_MESSAGE_K
1
Transmission power
5 mW
Default values assumed for simulation
This set of default values should not be seen as a proposed
configuration which would be optimum in some sense. It is just
meant as a reference point to explore configuration space. A
future contribution may propose a more optimized reference
configuration, once systematic simulations will have been run.
The following performance indicators are exploited:
Indicator
Explanation
Proactive, or reactive date loss ratio
Data message loss ratio observed in each node after simulation,
and averaged across all nodes in the network.
Proactive, or reactive data expansion
Total number of data messages transmitted from any node
during simulation, divided by the number of nodes in the
network, and divided again by the number of data messages sent
from the seed.
Reactive control expansion
Total number of control messages transmitted from any node
during simulation, divided by the number of nodes in the
network, and divided again by the number of data messages sent
from the seed.
Reactive expansion
Sum of the reactive data expansion plus the reactive control
expansion
Performance indicators
With respect to expansion figures, there is no claim about any
generic properties for the results which are presented in this
document. Given the present definitions, it is expected that the
denser is the network (in terms of average number of neighbours
per node) the lower expansions rates will be.
Therefore expansion rates are not only depending on the
routing algorithmic aspects, they also depend on the network
layout. Their interest in the context of this document is
to compare different configuration settings, rather than to obtain generic performance indicators.
Data message generation period at the seed
0.5s
1s
2s
4s
Proactive data loss ratio
0.38
0.15
0.03
0
Proactive data expansion
0.37
0.85
1.37
1.79
Reactive data loss ratio
0.38
0.2
0.02
0
Reactive data expansion
0.36
0.91
1.58
1.93
Reactive control expansion
0.1
0.22
0.44
0.72
Reactive total expansion
0.46
1.13
2.02
2.65
Preliminary results with respect to achievable data rates
Table 3 provides results for several message rates at the
seed. It can be seen that a saturation phenomenon is observed
(introducing significant message loss ratios) when the message
rate is too high. Of course, this result is strongly related to
the DATA_MESSAGE_IMIN and CONTROL_MESSAGE_IMIN parameters,
which have both been set in this case to 1.28 s.
The other observation seems to be that the reactive mode
introduces more transmissions in the network (higher
total expansion), with no real benefit in terms of achievable
message rate given the constraints of negligible message loss
ratios.
DATA_MESSAGE_K
1
2
4
Proactive data expansion
1.79
2.95
4.4
Data expansion in proactive mode, versus redundancy constant
DATA_MESSAGE_K
1
2
4
Reactive data expansion
1.93
2.88
4.18
Reactive control expansion
0.72
0.7
0.72
Reactive total expansion
2.65
3.58
4.9
Data and control expansion in reactive mode, versus redundancy constants
Table 4 shows the effect of redundancy constant of trickle
timers on data expansion, in case of proactive mode. The other
configuration parameters are set as described in the
simulation conditions section. In particular, the message rate
is 1 message for 4s, so that there are not message losses in
any simulation. With no surprise, it can be observed that the
redundancy constant has a strong influence on expansion ratio.
Table 5 shows the same result with respect to proactive
mode.
It shows that expansion figures are higher when reactive mode is used, as compared to proactive mode.
The influence of introducing vlues that are different of 1 for CONTROL_MESSAGE_K will be studied later.
Tx power (mW)
1
2
3
4
5
Proactive data loss ratio
0.56
0.14
0.03
0.01
0
Proactive data expansion
0.8
1.85
1.95
1.88
1.8
Reactive data loss ratio
0.4
0.07
0.01
0
0
Reactive data expansion
1.61
2.55
2.29
2.07
1.92
Reactive control expansion
0.68
0.88
0.81
0.76
0.72
Reactive total expansion
2.29
3.43
3.1
2.83
2.64
Results versus transmit power
Table 6 shows the effect of varying the transmit power.
It shows the interest of using reactive mode has it is
able to achieve lower message loss ratios in harsh radio
environments. Of course this result is obtained at the cost of
higher expansion rates.
This work has been supported by the A2NETS project (Autonomic Services in M2M Networks) which is funded by the ITEA 2 program.
The changes are listed in reverse chronological order, most
recent changes appearing at the top of the list.
From draft-roux-roll-mpl-eval-00.txt to
draft-authors-ipv6-over-80211p-00.txt:
first version.