L Patural
email: patural@emse.fr

P Grosseau

A Govin

J Pourchez

B Ruot

Water transport in freshly-mixed mortars containing cellulose ethers

Introduction

Polysaccharides are polymers frequently introduced into mortar formulations in order to improve the workability and water retention capacity of the fresh materials [START_REF] Ruot | Some aspects of cellulose ethers and latexes influence on the properties of cement-based materials -Examples of results obtained within the CEReM[END_REF]. Among all the polysaccharides, cellulose ethers seem to be the most suitable molecules to obtain a mortar with pretty good water retention ability (i.e. higher than 94%). On the other hand, polysaccharides such as starch ethers or starches generally induce a low increase in water retention (i.e. up to 85%).

Mortar consistency may contribute to its water retention capacity but this hypothesis should be checked by further investigations. Indeed, cellulose ethers could induce excellent water retention thanks to the possible superposition of two phenomena [START_REF] Pourchez | Aspects physico-chimiques de l'interaction des éthers de cellulose avec la matrice cimentaire[END_REF]:

a rheological effect similar to the one caused by other polysaccharides; an effect that could be specific to cellulose ethers, which remains to be defined. It could be caused by a modification of the porous network in the fresh state, osmotic pressure or the presence of a cellulose ether film playing the role of diffusion barrier.

The molar mass distribution of polysaccharides has been determined by size exclusion chromatography. Using such well-known molecules, it should be possible to understand the functioning of three types of cellulose ethers (HEC, HPMC and HEMC) on mortar water retention. Then, the influence of mortar consistency on water retention has been studied in order to verify if there is a relationship between these two parameters. To complete the panel, the impact of starch ethers on water retention and mortar consistency has also been investigated.

Materials and experimental methods

Mineral products

Mortars were prepared with the CEReM formulation which is given in Table 1. Mixing procedure was in accordance with EN 196-1 [START_REF]Methods of testing cement -Part 1: Determination of strength[END_REF]. Grey Portland cement was CEM I 52.5 N according to EN 197-1 [START_REF]Cement. Part 1: Composition[END_REF], supplied by LAFARGE. Chemical analysis was carried out by X-ray fluorescence (XRF) spectroscopy. This technique enables to determine oxides cement-composition. Then, phase compositions were calculated using Bogue formula [START_REF] Taylor | Cement Chemistry, The chemistry of Portland cement manufacture[END_REF]. The analysis was performed both by X-Ray Diffraction (XRD) analysis, and using Rietveld quantification (Siroquant V2.5 software). The composition of the cement is given in Table 2. Every experiment was carried out three times to make smaller uncertainties in measurement.

For both methods (XRF and XRD), cement phase composition results are similar.

Organic admixtures

Admixtures are especially formulated products which are added in small amounts to mortar during the mixing process in order to modify its properties.

Cellulose ethers

Cellulose, the most abundant polymer in nature, forms a part of polysaccharides family derived from -D-glucopyranose. Cellulose ethers are obtained by alkalization or alkylation of cellulose. In keeping with the substitution, different cellulose ethers can be obtained. In this study, three kinds of cellulose ethers will be studied (Figure 1 Starch ethers are obtained by the reaction of alkyl groups with etherifying agents. In this study, seven starch ethers were used. M1 and M4 are two carboxymethylhydroxypropyl starches, and M2, M3 and L2 are three hydroxypropyl starches. These five compounds have an amylopectin / amylose ratio equal to 80 / 20, and their polymerization degree are respectively 2 000 000 and 4 000. L1 and L3 are two modified starches.

Starch ethers

Starch ethers lead to better workability and improve application properties of the fresh mortar.

Characterization of admixtures

All polysaccharides were analysed by Size Exclusion Chromatography (SEC) in order to obtain their average molecular weights. The benefits of SEC are the low sample quantities, a wide separating range (10 3 -10 7 g/mol) and short analysis time (1h) [START_REF] Clasen | Determination of viscoelastic and rheo-optical material functions of water-soluble cellulose derivatives[END_REF]. With this chromatographic method, the particles are separated based on their size. The SEC principle is that the particles of different sizes will elute through a stationary phase at different rates. The larger the particles, the faster the elution. SEC analysis was performed on a Waters apparatus equipped with a pump (Waters 916) and a refractometer-type detector (Waters 410). The specific column used for SEC of polysaccharides is a TOSOHAAS TSK Gel GMPWXL column. In our situation, the eluent was a 0.5 mol/L sodium chloride solution in order to avoid agglomeration. The eluent was filtered and in line-degassed; the flow was set to 0.5 mL/min. The column was kept at 35 °C in a furnace. A calibration was performed using standards with known molecular weight and a theoretical polydispersity index close to 1. Height polymaltotrioses SHODEX standard P-82 were used, which are linear polysaccharides with a chemical structure close to the cellulose ethers one. Their molecular weight ranging from 5 800 Daltons (P5) to 788 000 Daltons (P800) and their retention time are, respectively 16.10 minutes and 11.98 minutes. The obtained peaks allow to establish the calibration curve by drawing ln(Mw) versus the retention time. Subsequently, every chromatogram was divided into many slices of 0.15 secondes in width and h i in height. Thanks to the calibration curve, every retention time corresponds to a mass M i of N i molecules eluted of the studied polymer. The height of every slice is directly proportional to the concentration c i of the eluted polymer. Therefore, the weight-average molecular mass (noted w M ) and the number-average molecular mass (noted n M ) were calculated thanks to the following equations 1a and 1b.

i i i w c M   M c  . i i i n M c c M   

Water retention measurements

Water retention is a mortar property that prevents the rapid loss of water to substrate by suction. This property prevents bleeding or "water gain" when the mortar is in contact with relatively impermeable units. Water retention is a fundamental property and affects workability and bond between mortar and masonry units. Water retention depends on mortar formulation. According to the DTU 26.1 [START_REF]Document technique Unifié" -Travaux d'enduits de mortiers[END_REF], mortars are divided into three classes:

the first one is for mortars which have a water retention lower than 86 %. They belong to the low water retention category; the second class (intermediate water retention): when the value is between 86 % and 94 %; and when water retention is higher than 94 %, it is a strong water retention mortar These limits have to be used with care because they refer only to the ASTM C91 measurements.

In this study, water retention measurements were performed using two different standards: the DIN 18555 and the ASTM C91 methods. Experiments were carried out three times for each material.

Water retention using DIN 18555

The standard DIN [START_REF]Testing of mortars containing mineral binders; part7: Determination of water retentivity of freshly mixed mortar by the filter plate method[END_REF] was carried out 5 minutes after mixing. It consists in measuring the lost water of a mortar in contact with a filter plate within a period of 5 minutes. The mortar was poured into a conical ring previously placed on a filter paper, as shown in Figure 3. The assembly was weighed, covered with a plastic plate and left to stand for 5 minutes. By weight differences, the water retention WR (in %) was thus deduced using equation 2.

Water retention using ASTM C91

Concerning the standard ASTM C 91 [START_REF]cement: determination of water retention and air content[END_REF], measurements have to be performed 15 minutes after mixing. The aim of the test is to measure the water loss of a mortar under a depression of 50 mmHg for 15 minutes (Figure 4). Where:

-W 0 represents the initial mass of mixing water -W 1 is the loss of mass of mixing water after 15 minutes under depression.

Consistency

Workability is an essential property of any mortar used in construction. This property improves the contact between mortar and substrates. This parameter could be measured using CSTB method (Consistor Baronnie) [START_REF] Cstb | Certificat CSTBat -Mortiers-colle de montage pour maçonnerie[END_REF]. This method was chosen because it is very easy and quick to set up; however, results need to be confirmed with a more rigorous method (rheological measurements). The material consists of ten stainless steel tubes with diameter ranging from 10 to 55 mm; they are marked from 1 to 10 (Figure 5a). The tube is tight inside the dish (Figure 5b), filled with mortar and levelled off. The shutter of the dish is quickly opened and the mortar falling time is measured. The aim of the experiment is to find the largest tube for which the paste does not slide before 5 seconds. The consistency of the paste is given by the number which corresponds to the largest tube. If the consistency is not measurable, the result will be noted f (for "fluid"). Measurements were performed with the same batch as water retention one. For a constant chemical structure, experimental results of water retention highlight the impact of admixture molecular weight (Figure 7). In spite of C1 having a slightly different methoxyl percentage, this result is in line with the three other HEMCs. Hence, for HEMC having a molecular mass lower than 400 000 Daltons, the higher the molecular mass, the better the mortar water retention capacity. Moreover, two of these four admixtures do not procure strong water retention (C1 and C2). For low HEMC molecular masses, the mortar water retention belongs to the intermediate class defined by the DTU. On the contrary, C3 and C4 give a strong water retention capacity to the mortar.

Consistency measurements for HEMC C group can also be related to the cellulose ether molecular mass (Figure 8). For this HEMC sample group, both the mortar consistency and water retention increase with admixture molecular mass. A hypothesis can be emitted: when the HEMC molecular mass increases, the mortar consistency increases too, which has itself an impact on the water retention. This can be explained by the HEMC capacity to form, with mixing water, a more or less viscous gel. As a consequence, a high molecular mass admixture would decrease the water mobility (due to this gel) with the result that the water retention would be improved.

For the HEMC C, the higher the molecular mass, the better the consistency and the water retention capacity of the admixed mortar.

Results

for HPMC Among HPMC, only two cellulose ethers (HPMC A) have a constant chemical structure (Table 3). The HPMC molecular mass influence can be studied using these two molecules. The experimental results of water retention and consistency are given in the Table 5. The observed trend is the same as for HEMC. The higher the HPMC molecular mass, the better the water retention capacity and the mortar consistency. However, it is difficult to conclude with only two molecules. This study needs to be widened using compounds with intermediate and higher molecular masses.

Results for HEC

Admixtures from group N present a wide range of molecular mass ranging from 40 000 to 2 900 000 Daltons. According to the manufacturers' data, the hydroxyethyl percentage is equivalent for all these cellulose ethers (56 %). In this sample group, only one parameter varies: the HEC molecular mass. Even though absolute water retention results differ between DIN and ASTM methods, the trends are similar (Figure 9). For HEC with molecular masses ranging from 40 000 to 630 000 Daltons, mortar water retention varies from 87 % to 92 % for standard DIN and from 93 % to 97 % for standard ASTM. For HEC with molecular masses ranging from 630 000 to 2 900 000 Daltons, water retention rise is less important (ranging from 92 % to 96 % for standard DIN and from 97 % to 98 % for standard ASTM).

The water retention increases with the HEC molecular mass up to a threshold value. This value can be estimated at roughly 600 000 Daltons. However, it is difficult to conclude because there are many intermediate molecular masses between 40 000 and 630 000 Daltons. From this value, the molecular mass seems to influence only slightly the mortar capacity to retain water. This trend is confirmed with the results obtained for another HEC family: H (Figure 10). However, among this panel, the substitution degree is also varying from 45 % to 52.5 % (respectively for H1 and H2). With this admixtures H, a plateau is observed from 275 000 (H3) to 790 000 Daltons (H7). In this range, mortar water retention is slightly constant whatever the HEC molecular mass. In consequence for HEC with a hydroxyethyl percentage ranging from 49.8 to 52.5 %, the molecular mass does not have any influence on water retention from 275 000 Daltons.

Regarding H1 and H2, in comparison with the complete panel, these admixtures have two parameters varying (molecular mass and substitution degree). The conclusion therefore is difficult to establish. However, the trend is in line with the HEC N. There is a threshold value from which the molecular mass does not influence the mortar water retention.

The relationship between mortar consistency and HEC molecular mass is similar to the water retention evolution (Figure 11). For these two admixtures panels, the consistency was not measurable for all mortars because they looked like the non-admixed mortar. Nevertheless, in each sample group, mortar consistency is better for high HEC molecular weights.

Impact of mortar consistency on water retention capacity

In part 3.2.1 a hypothesis was formulated concerning the influence of mortar consistency on water retention capacity. Indeed, for HEMC C, water retention increases when mortar consistency increases. However, the correlation between water retention and consistency does not seem to be so obvious. Some starch ethers were studied and these compounds procure very poor water retention to the mortar while paste consistency is pretty good (Figure 12). These results show that HPMC and HEMC usually procure strong water retention and pretty good consistency for the mortar. However, some HEC (notably two molecules from group N) bring strong water retention (i.e. higher than 95 %) to the fresh mortar, whereas the paste consistency is close to the non-admixed one. Furthermore, admixed mortar can have different consistencies ranging from unmeasurable to 2, whereas the same water retention can be observed. As a consequence, a major conclusion of this study is that the water retention capacity of a fresh mortar is not only due to its consistency.

Conclusions and new insights

Gradual effects on mortar water retention are clearly observed as a function of cellulose ethers chemistry. Therefore, one of the main conclusions of this study is that the polymer chemistry (HEMC, HPMC, or HEC) and the structural parameters (particularly molecular mass) are important factors controlling water retention and mortar consistency. For HEMC and HPMC, consistency and water retention increase with cellulose ether size. On the other hand, for HEC, a threshold value for molecular mass was observed. Different thresholds were noticed between two families with different substitution degrees. However, the studied panel does not allow us to conclude about the impact of substitution degree on water retention. This study also demonstrates that mortar water retention is not only a function of its consistency. Nevertheless, consistency results have to be confirmed with a rigorous method. Measurements of yield stress with a controlled shear stress rheometer supplied with a helical geometry may be an interesting way to characterize mortar consistency.

For a better understanding of the functioning of cellulose ethers on water retention mechanism, two parameters will be studied. First, the polymer particle size will be explored by performing water retention measurements with different particle size grades. It will be taken to think that the thinner the admixture particle, the better the polymer rate dissolution. Secondly, mortar water retention capacity will be studied as a function of cellulose ether concentration in mortar formulation. Indeed, Afridi [START_REF] Afridi | Water retention and adhesion of powdered and aqueous polymer-modified mortars[END_REF] using different kind of admixtures (latex) showed that water retention of polymer-modified mortars increases with a rise in polymer-cement ratio.

Water retention may be explained by an effect of barrier diffusion of cellulose ethers film. Polymer films in a freshly mixed mortar were observed by Jenni [START_REF] Holzer | Influence of polymers on microstructure and adhesive strength of cementitious tile adhesive mortars[END_REF]. This behaviour was particularly studied for a HPMC; in consequence, this property should be carried out whatever the cellulose ether molecule. Moreover, cellulose ether capacity to form film could be studied using a polarized-light microscope.

Figure 1 :

 1 Figure 1: Structure of cellulose ethers (a: HPMC, b: HEMC, c: HEC).

Figure 2 Figure 2 :

 22 Figure 2: Structure of starch (a: amylose, b: amylopectin).

Equation 1 :

 1 Formula to calculate the weight-average (a) and the number-average (b) molecular mass (a) (b)

Figure 3 :Equation 2 :

 32 Figure 3: Test device for standard DIN 18555. 1: plastic plate; 2: plastic ring; 3: fresh mortar; 4: filter paper; 5: non woven tissue. Dimensions are in mm.

Figure 4 :

 4 Figure 4: Experimental device to measure water retention with standard ASTM C91.Then, the water retention capacity is calculated using equation 3.

Equation 3 :

 3 Formula to calculate the water retention capacity using ASTM C91 standard.

Figure 5 :

 5 Figure 5: Test devices to measure mortar consistency.

Figure 7 :

 7 Figure 7: Influence of molecular mass of HEMC on water retention.

Figure 8 :

 8 Figure 8: Influence of molecular mass of HEMC on mortar consistency.

Figure 9 :

 9 Figure 9: Influence of molecular mass of HEC N on water retention.

Figure 10 :

 10 Figure 10: Influence of molecular mass of HEC H on water retention.

Figure 11 :

 11 Figure 11: Influence of molecular mass of HEC N and H on mortar consistency.

Figure 12 :

 12 Figure 12: Evolution of water retention as a function of mortar consistency.

Table 1 :

 1 Formulation of CEReM mortar.

	Component	Cement	Sand	CaCO 3	Admixture	Water mQ (Millipore ® )
	% wt of dry mixture	30 %	65 %	5 %	0.27 %	30 %
	Amounts for 2 kg of mortar	460.6 g	997.9 g	76.8 g	4.15 g	460.6 g
	Sand was supplied by SIFRACO ® , its reference is DU 0.1 / 0.35. The filler reference (CaCO 3 ) is BL200 from OMYA ® .

Table 2 :

 2 Chemical and phase composition of the investigated cement.

	Chemical composition (% wt)		Phase composition (% wt)
	Oxides	XRF	Phases	X-ray fluorescence (Bogue)	X-ray diffraction (Rietvield)
	CaO	66.3 ± 0.2	C 3 S	64.3 ± 0.8	67.9 ± 1.2
	SiO 2	22.3 ± 0.1	C 2 S	15.5 ± 0.3	15.8 ± 0.8
	Al 2 O 3	3.40 ± 0.01	C 3 A	4.2 ± 0.1	3.8 ± 0.4
	SO 3	3.04 ± 0.03	C 4 AF	8.7 ±0.1	9.4 ± 0.3
	Fe 2 O 3	2.87 ± 0.03	Sulfates	3.04 ± 0.03	3.1 ± 0.3
	MgO	0.99 ± 0.01
	P 2 O 5	0.24 ± 0.01
	TiO 2	0.18 ± 0.18
	K 2 O	0.04 ± 0.04
	MnO	0.016 ± 0.001

Table 3

 3

	):

HEMC Mp (x1000 Daltons) Méthoxyl group (% OCH3) DS Hydroxyethyl group (% OC 2 H 4 OH) MS

	C1	90	28.4	1.8	4.7	0.15
	C2	180	27.4	1.7	4.8	0.15
	C3	310	27.4	1.7	4.8	0.15
	C4	380	27.4	1.7	4.8	0.15

HPMC Mp (x1000 Daltons) Méthoxyl group (% OCH3) DS Hydroxypropyl group (% OC 3 H 6 OH) MS

	A1	50	28.0	1.9	9.5	0.35
	A2	80	21.5	1.4	9.5	0.33
	A3	220	28.0	1.9	9.5	0.35

HEC Mp (x1000 Daltons) Hydroxyethyl group (% OC 2 H 4 OH) MS

	H1	45	45.3	1.9
	H2	120	46.9	2.0
	H3	275	49.8	2.2
	H4	430	51.2	2.3
	H5	720	52.5	2.4
	H6	770	52.5	2.4
	H7	790	52.5	2.4
	N1	40	56.0	2.5
	N2	630	56.0	2.5
	N4	1 100	56.0	2.5
	N7	1 500	56.0	2.5
	N3	2 200	56.0	2.5
	N5	2 300	56.0	2.5
	N6	2 900	56.0	2.5

Table 3 :

 3 Cellulose ethers used in this study.

Table 4 :

 4 Range of HEMC to investigate the impact of w M .

	Admixtures	Méthoxyl	Hydroxyethyl group	M	w
	HEMC	(% OCH 3 )	(% OC 2 H 4 OH)	(x1000 Daltons)
	C1	28.8	4.7	90
	C2	27.4	4.8	180
	C3	27.4	4.8	310
	C4	27.4	4.8	380

Table 5 :

 5 Range of HPMC to investigate the impact of Mw.

	Admixtures HPMC	Mw (x1000 Daltons)	Water retention (%) DIN ASTM	Consistency
	A1	50	(86.6 ± 0.3)	(89.5 ± 0.3)	1
	A3	220	(92.9 ± 0.4)	(93.6 ± 0.4)	2

Results and discussion

Correlation between ASTM C91 and DIN 18 555 test methods

For the whole study, water retention measurements are performed with both methods. The comparison between both methods of measurement is shown on figure 6. Usually, both methods give rather close results, except for a few molecules. Among these are three HEC (N1, N2 and N3). These additives conferred to the mortar a more liquid aspect. The water retention value obtained with the DIN method is close to 90 % while the result of ASTM is considerably higher (roughly 97 %). This could be explained by a bleeding phenomenon observed for these admixtures during the experiment. Indeed, water seems to stay above whereas sand is at the bottom.

Furthermore, the values obtained with the ASTM method are usually higher than those obtained with the DIN method (the linear regression is over the first bisecting line). This phenomenon could be explained by a depression effect. Indeed, the ASTM measurement is carried out with a depression of 50 mmHg while the DIN method is a measurement of absorption of water in contact with a paper filter, based on gravitation and performed at atmospheric pressure. All things considered, the DIN 18555 and the ASTM C91 methods are two ways of determining water retention which are roughly comparable.

Influence of molecular mass on the water retention capacity

Results for HEMC

To study the weight-average molecular mass influence, the sample group C was chosen. Indeed, these compounds have a constant chemical structure except for C1 which has a slightly different methoxyl percentage (Table 4).


-Point and Broadcast Traffic Performance in RPL

Keywords: Réseaux de capteurs, RPL, Routage, Diffusion, Multicast

Study of Multipoint-to

Introduction

The general context for routing in Wireless Sensor Networks (WSNs) is small, cheap devices whose primary function is data acquisition, and for which communications capabilities are a "commodity to their primary function" -a necessary, but in preference unobtrusive, functionality, specifically targeted to the precise goal which the WSN is deployed to satisfy. As an example, a WSN deployed for environmental monitoring might contain a set of temperature sensors, sending "notifications" to a central controller when the temperature exceeds certain thresholds -and occasional "keepalive" messages otherwise, to let the controller know that the sensors are still operational. Traffic from the controller to the individual sensors may be limited to "setting the thresholds" -possibly rarely, such as at system deployment, or even never such as would be the case with factory set thresholds.

WSN Traffic Flows

The communications requirements for WSNs are in contrast to "traditional networks", wherein communications devices (network interfaces, switches, routers) have carrying data traffic as their sole raison d'être, and in which devices do not make any a-priori assumptions such as the characteristics of the traffic they will be carrying. WSNs assume an a-priori knowledge of the traffic patterns to optimize for -with sensor-to-controller traffic (multipoint-to-point) being predominant, controller-to-sensor traffic (point-to-multipoint) being rare and sensor-to-sensor traffic being somewhat esoteric1 .

WSN Trade-off 's

Low-power consumption, minute physical sizes, low price-points and ruggedness against the environment are among the industrial or commercial keywords, often associated with wireless sensors -and which entail challenging constraints (in terms of the computational power, permanent and temporary storage and in the characteristics (capacity) of the wireless interfaces) for designing routing algorithms. WSN routing protocols are therefore inherently compromises: trade-offs are made in adapting to the specific constraints under which they are to operate -the first of these is usually "generality". WSN routing protocols generally and narrowly consider only the traffic characteristics of their target environment as "valid", and discard all other traffic characteristics in the name of satisfying operational constraints; two of the most common such constraints brought forward are strict bounds on in-router state and on control traffic. A second trade-off is often in route optimality: stretched (non-optimal) routing paths are an acceptable trade-off for lower control traffic from a routing protocol, with the hypothesis that traffic flows will be such that the impact of such stretched paths will be negligible.

The perceived optimal routing protocol might thus be described as a routing protocol which requires zero in-router state and zero control traffic overhead, while providing non-stretched routing paths. Such a protocol is possible, although may not be desirable. Consider the example in figure 1a. The network connectivity is as indicated by the dotted lines, with the source and destination indicated by Source (router C) and Destination (router I), respectively. A "perceived optimal routing protocol" would be, as illustrated in figure 1b, simply flooding data traffic. Such entails no control traffic overhead and no in-router state, and a packet from C will arrive at I via a path of length 2 (i.e. a routing path stretch of 1). Data transmission between C and I via a path such as the one indicated in figure 1c appears intuitively better. While the routing path stretch is 3 (6 hops), at least routers D and E do not retransmit. An even worse situation is possible, as illustrated in figure 1e: all routers still retransmitting and receiving as many copies of a packet as in flooding -but with a routing path stretch of 4.

A flooding operation, as in figure 1b, would in this case entail 8 transmissions (i.e. (n -1) transmissions, with n being the number of routers in the network) -just as "bad"2 for battery consumption and media occupation as if the path length had been of 8, as in figure 1e. On the other hand, the routing path in figure 1e did not appear "by magic": a (more or less optimal) routing protocol has provided this path, and in order to do so generated a certain amount of control traffic.

As a measure of success, "routing path stretch" is an inappropriate metric, when used alone. In deployments with heavy unicast traffic, it might be reasonable to trade off more state and more control traffic in order to obtain shorter paths, whereas in scenarios where such unicast traffic is light, a longer path may be a reasonable trade-off in order to reduce state and control traffic. If in a network unicast traffic is both light and rare, simple flooding, and so trading off "route stretching" (or, more appropriately, "total number of transmissions on the wireless medium in order to successfully deliver the data packet at the destination") and state for simpler logic in the router and no control traffic, might be reasonable, as might flooding be reasonable if the majority of traffic is (very light) broadcast.

Paper Outline

The remainder of this memorandum is organized as follows: section 2 provides an overview of the activities of the IETF ROLL working group, chartered to develop routing protocols for IPv6-based sensor networks, as well as provides a description and critical discussion of the RPL routing protocol, developed within that working group. RPL provides relatively well defined and well understood support for multipoint-to-point traffic -and is currently developing mechanisms for supporting point-to-multipoint traffic as well. Section 3 suggests a couple of different mechanisms for providing also support for broadcast traffic in a WSN, by way of using the data structures and topologies already maintained by RPL. Section 4 provides a performance study of the multipoint-to-point performance of RPL, as well as a comparative study of the suggested broadcast mechanisms. Section 5 concludes this paper.

State of the art: ROLL and RPL

ROLL is the abbreviation of an IETF Working Group named "Routing Over Low power and Lossy networks". This working group has as objective to develop a routing protocol for WSN-like networks, based on IP.

The unofficial goal, which this Working Group tries to attain, is to prevent fragmentation in the WSN market by providing an IP-based routing standard and solicit broad industrial support behind that standard. To this end, the Working Group is operating with a very tight schedule and an objective of completing the standardization effort in fall 2010, satisfying only whatever requirements have been expressed within that time-frame.

The current proposal by the ROLL Working Group is denoted "Routing Protocol for Low Power and Lossy Networks" (RPL), a draft version hereof exists [2]. The objective of this protocol is to target networks which "comprise up to thousands of routers", where the majority of the routers have very constrained resources, where the network to a large degree is "managed" by a (single or few) central "superrouters", and where handling mobility is not an explicit design criteria. Supported traffic patterns include multipoint-to-point, point-tomultipoint and point-to-point traffic. The emphasis among these traffic patterns is to optimize for multipoint-to-point traffic, to reasonably support point-tomultipoint traffic and to provide basic features for point-to-point traffic, in that order.

The basic construct in RPL is the DODAG -a destination oriented DAG, rooted in a "controller", in figure 2. In the converged state, each WSN router has identified a stable set of parents, on a path towards the "root" of the DODAG, as well as a preferred parent. Each router, which is part of a DODAG (i.e. has selected parents) will emit DODAG Information Object (DIO) messages, using link-local multicasting, indicating its respective Rank in the DODAG (i.e. their position -distance according to some metric(s), in the simplest form hop-count -with respect to the root). Upon having received a (number of such) DIO messages, a router will calculate its own rank such that it is greater than the rank of each of its parents, and will itself start emitting DIO messages. Thus, the DODAG formation starts at the root, and spreads gradually to cover the whole network.

As a Distance Vector protocol, RPL [2] contains rules restricting the ability for a router to change its rank. Specifically, a router is allowed to assume a smaller rank than previously advertised (i.e. to logically move closer to the root) if it discovers a parent advertising a lower rank (and it must then disregard all previous parents with higher ranks), while the ability for a router to assume a greater rank (i.e. to logically move farther from the root) in case all its former parents disappear, is restricted to avoid count-to-infinity problems. The root can trigger "global recalculation" of the DODAG by way of increasing a sequence number in the DIO messages.

RPL Data Traffic Flows

The DODAG so constructed is used for installing routes in the WSN routers: the "preferred parent" can serve as a default route towards the root, or the root can embed in its DIO messages the destination prefixes, also included by DIOs generated by WSN routers through the WSN, to which it can provide connectivity. Thus, RPL provides "upward routes" or "multipoint-to-point routes" from the sensors towards the controller.

"Downward routes" are installed by having the sensors issue Destination Advertisement Object (DAO) messages, which propagate via parents towards the routes, and which describe which prefixes belong to, and can be reached via, which WSN router. Each intermediate WSN router, forwarding a DAO message towards the root, adds its address to a reverse routing stack in the DAO message, thereby providing the source with the ability to do source routing for reaching addresses in the WSN.

Sensor-to-sensor routes are as default supported by having the source sensor transmit via its default route to the root, which will add a source-route to the received data for reaching the destination sensor.

RPL Operational Requirements

The minimal set of in-router state, required in a WSN router running RPL is, (i) the identifier of the DODAG root, (ii) the address and rank of the preferred parent, (iii) the configuration parameters shared by the DODAG root (notably, destination prefixes and message emission timers) and (iv) the maximum rank that the WSN router has itself advertised. For redundancy, a WSN router running RPL can maintain information describing additional parents (up to and including all its parents), which may allow rapidly changing its preferred parent (and thus its "next hop") in case the former preferred parent becomes unreachable.

INRIA

RPL message generation is timer-based, with the root able to configure suitable back-off of message emission intervals using trickle timers [3].

RPL Discussion

In its basic form, RPL is a fairly simple-to-understand and simple-to-implement distance-vector protocol. The DODAG formation mechanism, using DIO messages, is currently well understood, and despite the specification hereof in [2] remaining somewhat ambiguous, the authors of this paper managed to develop and test an implementation "from scratch" within about a week.

The DODAG formation mechanism is not without potential issues, however. First, parents (and the preferred parent) are selected based on receipt of DIO messages, without verification of the ability for a WSN router to successfully communicate with the parent -i.e. without any bidirectionality check of links. In a wireless environment, unidirectional links are no rare occurrence, and can simply happen as illustrated in figure 3: the gray device, X, illustrates a source of environmental interference, preventing route b from successfully receive transmissions from a. This may, however, not prevent b from transmitting DIOs, received by a and which may contain information causing a to select b as both parent and preferred parent. As b is a "useless" next-hop for a, due to the interference from X, this is a bad choice. RPL suggests using Neighbor Unreachability Detection (NUD) [4] to detect and recover from this situation, when it occurs that a tries (and fails) to actually use b for forwarding traffic. NUD is based upon observing if a data packet is making forward progress towards the destination, either by way of indicators from upper-layer protocols (such as TCP), from lower-layer protocols (such as Link Layer ACKs) or -failing these two -by unicast probing. A couple of problems can be noted regarding this approach.

First, absent all WSN routers consistently advertising their reachability through DAO messages, a protocol requiring bi-directional flows between the communicating devices, such as TCP, will be unable to operate. Even if such bi-directional flows are enabled, the source detecting, by way of an upper layer protocol, that no forward progress is possible, is of restricted use: the source can not know if it is its "preferred parent" (next hop) which is unreachable, or if it is a problem further along the path (even outside the WSN). Thus, any corrective action that the source might take (changing preferred parent, moving to a higher rank within the limits allowed, etc.) may be unable to alleviate the problem, and corrective actions may even be counter-productive (poison the sub-dag, for example).

Second, there is a change that the radio range of a unicast (as would be used for data delivery via the next hop towards the root) would differ from the radio range of DIOs, which are sent using link-local multicast 3 .

Third, upon having been notified by NUD that the "next hop" is unreachable, a WSN router must discard the preferred parent and select another preferred parent -hoping that this time, the preferred parent is actually reachable. Also, if NUD indicates "no forward progress" based on an upper-layer protocol, there is no guarantee that the problem stems from the preferred parent being unreachable. Indeed, it may be a problem father ahead, possibly outside the WSN, thus changing preferred parent will do nothing to alleviate the situation.

Fourth, the selection of parents and preferred parent is based on receipt of DIO messages only, and is based on the rank of the candidate parents. Absent other complementary mechanisms (which are currently not specified as part of [2]), a WSN router may receive, transiently (e.g. due to a fortunate environmental reflection), a DIO from another router, much closer to the root -and as a consequence change its parent set and rank to this new more attractive parent. If no stable link exist, this may cause delivery failures.

The Destination Advertisement mechanism, for providing downward routes "from the root to the sensors", remains in a state of flux. While the basic properties of the Destination Advertisement mechanism, given a stable underlying DODAG, appear easy to understand, it does have several inconveniences: all sensor-to-sensor routes transit the root, possibly causing congestion in the wireless spectrum near the root, as well as draining energy from the intermediate routers on an unnecessarily long path. Several solutions are proposed to alleviate this, including allowing intermediate WSN routers, otherwise only forwarding DAO messages towards the root, to record routing state, and allowing these intermediate WSN routers to act as "shortcuts". Another proposed solution is to use proper sensor-to-sensor routing protocols, derived off e.g. AODV [5].

Finally, the current specification of RPL does not provide support for "broadcasting" of any form. Unicast traffic to and from the root can be enabled, as previously described, however is inefficient in case the root has data to deliver to all (or a sufficiently large subset) of the WSN routers in the network.

Data Broadcasting in RPL

This section suggests mechanisms for exploiting the DODAG as constructed by RPL in order to undertake better-than-classic-flooding WSN-wide broadcasting. The fundamental hypothesis for these mechanisms is that all broadcast operations are launched from the root of the DODAG. If a sensor needs to undertake a network-wide broadcast, the assumption is that this broadcast is sent to the root using unicast, from where the DODAG root will launch the broadcast operation -this is similar to the basic mechanism for sensor-to-sensor unicast in [2], wherein traffic from the source sensor transits to the DODAG root, for relaying to the destination sensor.

Classic Flooding (CF)

A common baseline for broadcast operations is that of classic flooding: each router relays a broadcast packet upon its first receipt by that router; subsequent receipts of the same packet are suppressed and do not cause retransmissions. This has to its merit that no control traffic is required -however also entails (i) that each data packet must be uniquely identifiable (commonly ensured by embedding a unique sequence number in each broadcast packet, emitted by a given source), (ii) that each router must maintain information (state) for each already received and relayed data packet so as to enable suppression of duplicates, and (iii) each data packet is retransmitted by each router in the network -often with a large degree of redundant transmissions as consequence.

Redundant retransmissions cause increased battery drain, both when transmitting and receiving (and discarding) the redundant packets, and increase contention on the wireless media, increasing the probability of data loss due to collisions. CF is, for these reasons, not suggested as a mechanism for data broadcast in WSNs, but is described here as a baseline for data broadcasting in RPL.

MultiPoint Relay Flooding (MPRF)

A common improvement over Classic Flooding is for each router to select and designate a subset of its neighbors (MultiPoint Relays -MPRs [START_REF] Qayyum | Multipoint relaying: An efficient technique for flooding in mobile wireless networks[END_REF]) for relaying broadcast transmissions, thereby reducing the number of redundant retransmissions of each packet. This has been shown to offer dramatic reductions in the network load (fewer transmissions), as well as a dramatic reduction in data loss due to collisions [START_REF] Clausen | Investigating Broadcast Performance in Mobile Ad-hoc Networks[END_REF].

In order for MPRF to work, a router must select its MPRs such that a message relayed by these MPRs will be received by all routers two hops away, as illustrated in figure 4. To this end, each router must maintain, at a minimum, state describing both its neighbor routers, as well as its 2-hop neighbors ("neighbor routers of neighbors"). MPRF -as CF -requires identification of each broadcast packet, and maintenance of state allowing elimination of duplicate packets. MPRF is a common approach in wireless ad hoc networks, where it is used e.g. for network-wide broadcast of routing protocol control traffic by [START_REF] Clausen | Optimized Link State Routing Protocol (OLSR)[END_REF], [START_REF] Clausen | SPF Multipoint Relay (MPR) Extension for Ad Hoc Networks[END_REF] and [START_REF] Clausen | The Optimized Link State Routing Protocol version 2 (OLSRv2)[END_REF] -as well as for network-wide data broadcast [START_REF] Macker | Simplified Multicast Forwarding[END_REF]. Comparing RPLspecific broadcast mechanisms with MPRF is therefore, to a certain extend, a comparison with "state of the art" of broadcasting in wireless multi-hop networks.

Parent Flooding (PF)

Admitting the RPL "philosophy" of data transmission to sensors originating at (or relaying via) "the DODAG root", RPL lends itself to a first and simple broadcast optimization: restricting a RPL router to retransmit only broadcast packets received from a "parent". Logically, the basic performance hereof should be similar to that of classic flooding: with the broadcast operation initiated from the DODAG root, each router will retransmit the packet upon receipt from a parent. PF does not require any additional control traffic over that which is caused by RPL. PF may apply identification of each broadcast packet, and maintenance of state allowing elimination of duplicate packets in order to avoid multiple retransmissions of the same packet received from different parentssimilar to MPRF and CF.

Preferred Parent Flooding (PPF)

In order to not incur any additional in-router state requirements for detecting and suppressing retransmission of duplicate packets, preferred parent flooding utilizes the existing relationship between RPL routers, in order to ensure that no router will forward a broadcast packet more than once. Each RPL router is required to select exactly one Preferred Parent. Restricting retransmissions of broadcast packets to only those received from the router's preferred parent ensures that duplicates received from other routers (parents or otherwise) are ignored for retransmission.

Preferred Parent MPR Flooding (PPMPRF)

PPF is fundamentally a derivative of the MPRF optimization, attempting further to decrease the number of retransmissions necessary for a network wide broadcast. The idea is as follows: each router, selected as "Preferred Parent", must designate a subset of its "selectees" (children which have selected it as preferred parent) as "Preferred Children". These "Preferred Children" must be selected such that a message, relayed by these "Preferred Children", will reach all its "grand children" -i.e. the children of its "selectees".

Whenever a router receives a data packet that is to be broadcast throughout the network, that router will only then forward the packet if (i) at least one parent of that router has selected it as preferred child and (ii) the packet has not been previously received (as determined by a duplicated detection mechanism). It is to be noted that it is not sufficient to restrict forwarding to packets received from the preferred parent of a router, but that packets from any parent of that router have to be forwarded if the router has been selected as preferred child by at least one of its parents. The rationale is illustrated in figure 5. Assuming that the root of the network (router 0) has selected B as preferred child as indicated by the downward arrow, and B forwards a packet originating from the root. If forwarding was restricted to packets received from the preferred parent of a router, D would not forward the packet from B (since it is no preferred parent of D), and thus X would never receive the packet. This restriction entails less liberties with respect to selecting relays for "best 2-hop coverage". It is quite possible that the child providing the "best" coverage of a router has not selected that router as Preferred Parent, and that therefore PPMPRF will result in more relays than MPRF. In RPL, the Preferred Parent selection is intended to optimize for "best upwards paths towards the DODAG root" (possibly according to some deployment specific optimization criteria), which may not coincide with what would be optimal for "best downwards coverage".

The PPMPRF mechanism also requires that each router knows (i) which children have selected it as Preferred Parent (i.e. its selectees), and (ii) which routers are Preferred Children of these selectees. This information can be made available through adding an option to DIO messages, emitted by all routers running RPL.

Optimized Preferred Parent MPR Flooding (PPMPRFopt)

This mechanism represents a small optimization over PPMPRF, in that it provides all neighboring routers with the same rank with information, encouraging coordinated Preferred Parent selection so as to try to reduce the number of routers selected as Preferred Parent. Thus, a router will select as its Preferred Parent among its parents, the one which most of its adjacent routers also have in their parent set. Given a tie, the parent which a majority of the adjacent routers have already selected as Preferred Parent will be chosen. Thus, in addition to the information indicated for PPMPRF, PPMPRF-opt requires all parents to be advertised. Figure 6(a) depicts an example of Preferred Parent selection, as may happen in basic RPL: a router selects its Preferred Parent amongst all its parents with the lowest rank in an uncoordinated way. Worst case (in terms of redundant transmissions and therefore possible collisions when broadcasting), routers D, E and F all select different Preferred Parents (C, B, and A respectively). Similarly, I, H, and G may select three different Preferred Parents. For PPMPRF, this means that all routers, other than 0, will be selected as MPRs and thus retransmit a broadcast.

Figure 6(b) depicts a coordinated Preferred Parent selection. Router D will advertise all its parents (C and B) in its control messages, as will E (parents C, B and A) and F (parents B and A). D has an equal choice between parents C and B, and F has the same choice between B and A. E will select B as Preferred Parent because this is the only parent that both of its adjacent routers can also select as Preferred Parent. Once D and F receive a control message from E, advertising that B is selected as Preferred Parent, they will also select B. Thus, only routers B, E and H will be selected as Preferred Parents and therefore retransmit a broadcast.

Such coordinated Preferred Parent selection may be a double-edged sword for RPL. While it is a potential benefit for broadcast traffic from the DODAG root, unicast traffic flows towards the DODAG root via Preferred Parents. Thus, coordinated selection of Preferred Parents implies that unicast traffic is concentrated through a subset of the routers in the network, possibly increasing congestion in these routers, increasing the battery drain in these routers etc.

RPL Performance Study

This section presents results of a simulation study of RPL with the Ns2 simulator. Several properties of the DIO mechanism, as well as unicast and broadcast data traffic have been analyzed. The implementation reflects a basic version of the RPL protocol: only upward routes, and a single RPL instance with a single DODAG are considered. Since routers are not mobile in the simulation, the sequence number (and thus the DODAG iteration) will not change during the simulation. At the beginning of the simulation, only the root (which is the router with the ID of 0) starts transmitting DIOs. routers other than the root receiving a DIO start sending DIOs exactly two seconds after no more change in their Candidate Neighbor Set has been detected. Each DIO contains the DODAG Configuration suboption. The simulations have been performed in two variations:

• with periodic DIO transmission: DIOs are sent periodically with an interval of two seconds minus a jitter of maximum 0.5 s (as defined in [START_REF] Clausen | Jitter Considerations in Mobile Ad Hoc Networks (MANETs)[END_REF])

• with a trickle timer: I_min is 2 s and I_doublings is 20. During the simulation, the trickle timer is never reset.

Results

This section describes the results of the Ns2 simulation. Figure 7 shows a RPL instance of a simulated network with 1000 routers. Figure 8 shows the maximum and average rank of routers in the DODAG, where the number represents the distance of a router to the root in terms of hops (i.e. the maximum rank represents the diameter of the network, the average rank represents the average over all routers). The maximum and average ranks grow logarithmically with the number of routers in the network.

Figure 9 depicts the average number of parents of each router in the DODAG. Keeping the density of the network constant with increasing number of routers, the average number of parents grows logarithmically. Figure 12 depicts the collision ratio of the DIO messages. Since the RPL implementation using the trickle timer sends significantly fewer DIO messages, the probability of collision is lower. In the following, unicast CBR data streams of 1280 bytes/s have been sent from an arbitrary router to the root, in average five concurrent streams of 10s duration each.

Figure 13 depicts the delivery ratio of packets that have arrived at the root. It can be seen that it is constantly very high, only few packets are lost due to collisions on lower layers.

Figure 13: Unicast: delivery ratio Figure 14 illustrates the average path length in number of hops that a data traffic traverses before reaching the root. As expected, it grows logarithmically with the number of routers, and is very similar to the average rank as depicted in figure 8. Figure 15 shows the delay of the data transmission, i.e. the time interval from sending the packet at the source until it reaches the destination. Due to the longer path length, the delay increases with the number of routers in the network.

Figure 15: Unicast: delay

Broadcast Data traffic

In the following, the broadcast mechanisms presented in section 3 are analyzed in terms of MAC layer collisions, delivery ratio, overhead, delay, and path length. CF and PF (without duplicate detection) are not considered since their performance is expectedly much worse than any of the other mechanisms.

Figure 16 depicts the number of collisions of frames on the MAC layer, for the different broadcast mechanisms. MPRF and PPMPRF-opt yield the lowest number of collisions among the analyzed protocols, with PPMPRF causing about the same number of collisions as PF+DD (PF with duplicate packet detection). This is expected, as in MPRF, relays are explicitly selected so as to avoid redundant retransmission by topologically close routers, and the coordinated preferred parent selection in PPMPRF-opt also reduces the number of relays. PPMPRF without coordination entails more relays, as more routers in the network will be selected as preferred parents, which in turn select the relays (i.e. preferred children). In PPF, topologically close routers are likely to have chosen the same Preferred Parent and so will explicitly produce redundant retransmissions. Consider the example in figure 17, wherein a broadcast transmission is made by router 0 and relayed as indicated by the solid arrows. In PPF, as indicated in figure 17(a), each router will select its Preferred Parent and retransmit the packet once upon receipt from that preferred parent. Routers A, B and C all receive the transmission directly from router 0. Routers D, E and F have all chosen one of A, B and C as Preferred Parent and will thus all retransmit when receiving the transmission from their chosen preferred parentsimilar for I, H, G, even though these three do not have any routers further down the network. In contrast, in figure 17(b), MPRs have been selected. Router 0 has selected B as MPR (as B "covers" D, E, F) and router B has chosen router INRIA E as MPR (as it covers all of G, H, I). As there are no further routers "below" in the network, router E has chosen no MPRs downwards. Thus, only B and E retransmit the broadcast packet from 0 -i.e. for each "level" in this simple network, only a single transmission occurs, with no collisions at each level. 18 depicts the delivery ratio of broadcast packets. The delivery ratio of the MPRF and PPMPRF mechanisms are the highest of the compared broadcast mechanisms, with PPMPRF-opt being not much below MPR. This can be interpreted as a tradeoff between redundancy and efficiency: in relatively scarce networks (such as the simulated scenario) a higher redundancy of relays, such as in PPMPRF, can lead to a higher delivery ratio, despite of the increased number of collisions. as observed in figure 16. In dense networks, however, the large number of collisions with more redundant delays can reverse that effect and reduce the delivery ratio. A detailed analysis of the MPR relaying mechanism can be found in [START_REF] Qayyum | Multipoint relaying: An efficient technique for flooding in mobile wireless networks[END_REF].

PF+DD has a higher delivery ratio than PPF, due to the redundancy of transmissions -when a router receives the same broadcast packet from several of its parents, chances are higher that at least one of the packets will reach the router, while if the one transmission from the preferred parent in PPF is lost due to a collision, the router will not forward the other incoming packets from its (non-preferred) parents. The higher delivery ratio of PF+DD is at the expense of vastly higher media load, as depicted in figure 19: the cumulative number of bytes transmitted during the simulations are significantly higher for PF+DD and for PPMPRF without the optimization. PPF incurs a lower overhead than PF+DD with MPRF still outperforming PPF by a large, and constant, margin. PPMPRF-opt has a similar overhead as MPRF. Figure 20 depicts the average end-to-end delay for data traffic from the root to every WSN router in the network, and figure 21 depicts the average path length of successfully delivered data packets. The optimized MPR-based broadcast mechanisms incur the lowest delay of the protocols, while PPF causes a slightly lower delay than does PF+DD. The, on average, longer path lengths of MPRF are due to the data delivery ratio being higher -MPRF successfully INRIA "reaches" routers farther away from the root (as depicted in figure 22). It has been shown ( [START_REF] Qayyum | Multipoint relaying: An efficient technique for flooding in mobile wireless networks[END_REF]) that MPR leads to optimal path length. That means that every mechanism indicating a shorter path in the figure entails a lower reachability of routers further away from the broadcast source. Longer paths indicate suboptimal paths. It is worth observing that MPRF achieves the optimal path length with a lower delay still. This can in part be explained by the fact that MPRF ensures that data is flooded via shortest paths, and in part by the fact that with fewer retransmissions, less media and queue contention occurs.

PPF with Jitter

In the results presented in section 4.2.2, data traffic has been promptly forwarded by each WSN router, without explicit delay. As has been shown in [START_REF] Clausen | The Optimized Link State Routing Protocol, Evaluation through Experiments and Simulation[END_REF][START_REF] Clausen | Jitter Considerations in Mobile Ad Hoc Networks (MANETs)[END_REF], adding a random jitter before retransmitting a broadcast packet can significantly reduce the number of collisions and, therefore, increase the delivery ratio for broadcast packets. In the following, the effect of adding jitter to PPF is investigated. Figure 23 depicts the collision ratio of frames when using no jitter, and a random jitter uniformly distributed between 0 and 500 ms respectively. With jitter, the collision ratio is much lower than it is without. This is due to the fewer concurrent retransmissions by adjacent WSN routers. Comparing to figure 16, PPF with jitter yields a collision ratio comparable to, or lower than, MPRF without jitter. As a consequence of the lower collision ratio, the delivery ratio of PPF with jitter is higher than it is without, as depicted in figure 24. Comparing to figure 18, the delivery ratio of PPF still remains consistently below that of MPRF, even when PFF is used with jitter.

The drawback of using jitter is a higher end-to-end delay of packets, as depicted in figure 25. With jitter, the delay is considerably higher than it is without.

Conclusion

This memorandum has presented a critical review of RPL -the currently proposed routing protocol for IPv6-based Wireless Sensor Networks (WSNs), as developed within the Internet Engineering Task Force. A distance vector protocol constructing routing paths from sensors to a central "controller", RPLs basic mechanism is one of DAG formation, with that DAG being the central topology upon which routing is performed. The review reveals areas where, in the authors opinion, further work is required -in particular with respect to tracking of uni-directional links, to point-to-multipoint routes (controller-to-sensor routes) and data broadcasting in a WSN. The memorandum then suggests a simple zero-in-router-state broadcast protocol, utilizing the DAGs already constructed by RPL.

The memorandum concludes by a performance study of the "multipoint-topoint" (sensor-to-controller) routing performance RPL, as well as of the suggested data broadcasting mechanisms.

INRIA

Figure 1 :

 1 Figure 1: "Route Stretching" vs "number of transmissions"

Figure 2 :

 2 Figure 2: RPL Basic Construct: DODAGs

Figure 3 :

 3 Figure 3: Unidirectional link due to radio interference

Figure 4 :

 4 Figure 4: (a) Classic flooding and (b) MPR Flooding

INRIA

Figure 5 :

 5 Figure 5: PPMPRF: Example showing the need to forward packets not only received by the preferred parent, but by any parent if the router is selected as preferred child by at least one of its parents. Upward arrows depict preferred parent selection, downward arrows preferred child selection.

Figure 6 :

 6 Figure 6: Uncoordinated PP selection (a) and coordinated PP selection (b) in the same network. Solid arrows indicate the selection of a Parent as Preferred Parent; dotted lines the connectivity of the network.

INRIA

4

 4

Figure 7 :

 7 Figure 7: Example RPL instance with 1000 routers

Figure 8 :

 8 Figure 8: Maximum and average rank of routers in the DODAG

Figure 9 :

 9 Figure 9: Average number of parents per router in a DODAG

Figure 10 :

 10 Figure 10: Network convergence time

Figure 11 :

 11 Figure 11: Control traffic: overhead in bytes

Figure 12 :

 12 Figure 12: Control traffic: collision ratio

Figure 14 :

 14 Figure 14: Unicast: path length

  Figure 16: Broadcast: total number of MAC layer collisions

Figure 17 :

 17 Figure 17: PPF (a) and MPRF (b) in the same network. Solid arrows indicate transmission of a packet; dotted lines the connectivity of the network.

Figure 19 :

 19 Figure 18: Broadcast: delivery ratio

Figure 21 :

 21 Figure 20: Broadcast: average delay

Figure 22 :

 22 Figure 22: Broadcast: traffic delivery ratio with respect to distance from the root in hops (with 100 routers in the network)

Figure 23 :

 23 Figure 23: Collision ratio of PPF with jitter

Figure 25 :

 25 Figure 24: Delivery ratio of PPF with jitter

  .1 Simulation Settings RPL has been implemented in Java. The specific settings of the scenarios studied are detailed in table 1. For each datapoint, the values have been averaged over 10 runs.

	Parameter	Value
	Ns2 version	2.34
	Mobility scenarios	No mobility, random distribution of
		routers
	Grid size	variable
	router density	50 / km 2
	Communication range	250m
	Radio propagation model Two-ray ground
	Simulation time	100 secs
	Interface type	802.11b
	Frequency	2.4 GHz
	Table 1: Ns2 parameters
	4.1.1 DIO settings

Note that while this may be commonly assumed, this is not a universal distribution of traffic patterns in WSNs -there are scenarios in which sensor-router to sensor-router traffic is assumed a more common occurrence, such as[1].RR n°7384

Actually, even worse: in order to prevent "looping" packets, state would have to be maintained in each sensor router, ensuring that each such packet would be retransmitted no more than once.INRIA

RR n°7384

Such is the case for some implementations of IEEE 802.11b. IEEE 802.11b is, of course, not suggested as a viable radio interface for WSNs, but serves to illustrate that such asymmetric designs exist.INRIA


IPv6 Operation for WAVE -Wireless Access in Vehicular Environments

Keywords: IEEE 1609, WAVE, DSRC, Rseaux Vhiculaire, IPv6

La suite de protocoles IEEE WAVE fournit des services de communications pour les réseaux véhiculaires, en promettant le support de deux piles de protocoles: le Wave Short Message Protocol (WSMP) d'une part, et IPv6 d'autre part. Si WSMP est spécifié dans la famille de standards IEEE 1609, les auteurs du présent papier affirment que les considérations concernant IPv6 dans WAVE ne sont pas assez dévelloppées, et que par conséquent, plusieurs problèmes ne sont pas résolus. Ce papier passe en revue ces problèmes, et analyse les principaux vérrous concernant le dévelloppement de solutions appropriées à ces problèmes.

Introduction

The IEEE is currently undertaking standardization of a protocol suite for Wireless Access in Vehicular Environments (WAVE), with the objective of providing vehicles and pedestrians with the ability to communicate with each other and with road-side infrastructure. Possible applications hereof include emergency warning systems, cooperative cruise control and collision warning, as well as toll and parking fee collection. This protocol suite is developed in the IEEE 1609 working group, documented in [START_REF]The Wireless Access in Vehicular Environments (WAVE) Working Group of the Intelligent Transport Systems (ITS) Committee[END_REF]2,3,4,[START_REF]IEEE P1609.4: Draft Standard for Wireless Access in Vehicular Environments (WAVE) -Multi-Channel Operation[END_REF][START_REF][END_REF] and intended for operation over Dedicated Short-Range Communications (DSRC) -a set of wireless communications channels, dedicated for vehicular networking at 5.9GHz.

WAVE is providing communications services to applications, by way of promising support for two protocol stacks, the Wave Short Message Protocol (WSMP) and IPv6, as shown in figure 1. While WSMP is developed within the IEEE 1609 family of standards [4], considerations for operation of IPv6 for WAVE are less developed. The WAVE architecture specification [START_REF]The Wireless Access in Vehicular Environments (WAVE) Working Group of the Intelligent Transport Systems (ITS) Committee[END_REF] makes reference to the IETF1 specification of IPv6 [START_REF] Hinden | RFC2460: Internet Protocol, Version 6 (IPv6) Specification[END_REF] and makes minimal observations regarding the use of IPv6 addresses, but no further specific recommendations as to IPv6 operation for WAVE are provided.

The authors of this memorandum assert that, while the IEEE 1609 family of specifications provides a set of necessary considerations for IPv6 operation over WAVE, these considerations are not sufficient for proper and correct IPv6 operation in this environment. This memorandum thus provides an analysis of IPv6 operation, as described in the IEEE 1609 family of specifications for WAVE networks, identifies where IPv6 operation for WAVE networks is underspecified, and presents a set of additional recommendations enabling proper IPv6 operation for WAVE networks.

Memorandum Overview

While IPv6, as defined in [START_REF] Hinden | RFC2460: Internet Protocol, Version 6 (IPv6) Specification[END_REF], principally concerns the data frame layout (header format, header extensibility, rules governing header construction and processing etc.), IPv6 operation implies operation of a set of basic protocols at the network layer, including NDP [START_REF] Narten | RFC2461: Neigh-bor Discovery for IP Version 6 (IPv6)[END_REF], stateless address autoconfiguration [START_REF] Thomson | RFC2462: IPv6 state-less address autoconfiguration[END_REF]. The IPv6 protocol stack provides additional protocols at other layers, such as the transport layer and the application layer. Most of these protocols make certain assumptions about properties of an underlying link model for their proper operation, and assume certain relationships between assigned IP addresses and communications ability across the underlying data link layer. This is discussed in details in section 2, elaborating on the link-model presented by a WAVE system, and presenting IPv6 network layer considerations for WAVE, resulting from the properties of that link-model. This memorandum , then, in section 3 presents additional issues for WAVE operation in an IP networking context, including "pseudonymity", transport and application layer challenges. This memorandum is concluded in section 4.

WAVE Network Layer Challenges with the IPv6 Protocol Stack

IPv6 operation is, beyond the use of the IPv6 frame format [START_REF] Hinden | RFC2460: Internet Protocol, Version 6 (IPv6) Specification[END_REF] on the network layer, generally understood to also imply assumptions of a specific and well-defined link-model reflected in a well-defined addressing model [START_REF] Hinden | RFC3513: Internet Protocol Version 6 (IPv6) Addressing Architecture[END_REF], and operation of a set of supporting protocols [START_REF] Narten | RFC2461: Neigh-bor Discovery for IP Version 6 (IPv6)[END_REF], [START_REF] Thomson | RFC2462: IPv6 state-less address autoconfiguration[END_REF]. The IPv6 addressing model defines different address families (e.g., Link Local or Global addresses), with associated properties. This enables applications or protocol to have certain expectations of communication abilities, corresponding to the addresses they use. For example, an application using a Global address as destination address expects the network to be able to ensure multi-hop communication to that destination address. The network, then, expects such addresses to be assigned in a way such that by inspection of the address, it can be determined if the destination is reachable directly, or reachable only via a (and, in that case, also via which) router.

In an IPv6 network, the supporting Neighbor Discovery Protocol for stateless autoconfiguration (of addresses, default routers etc) and duplicate address detection [START_REF] Narten | RFC2461: Neigh-bor Discovery for IP Version 6 (IPv6)[END_REF], [START_REF] Thomson | RFC2462: IPv6 state-less address autoconfiguration[END_REF], is assumed to be running -and that protocol expects specific link model and addressing model.

Thus, IPv6 operation entails (i) using the IPv6 frame format, (ii) certain assumptions of a well-defined link-model, reflected in an (iii) address model, and (iv) proper operation of NDP. This is detailed further in the following sections. [START_REF] Thaler | RFC4903: Multilink Subnet Issues[END_REF] points out that network protocols and applications are designed with specific assumptions on the nature of an IP link, illustrated in figure 2 and summarized as follows:

IPv6 Link Model

INRIA

• all hosts (H) with network interfaces configured with addresses from within the same prefix p::, and with the same prefix p:: assigned to the interfaces, can communicate directly with one another; i.e.:

-IPv6 datagrams are not forwarded at the network layer when communicating between interfaces which are configured with addresses from within the same prefix; hence hop-limit in IPv6 datagrams are not decremented when communicating between interfaces which are configured with addresses from within the same prefix, and;

multicast/broadcast IPv6 datagrams with a hop-limit of 1 are (modulo data loss) delivered to all interfaces within the same subnet.

• link-local multicasts and broadcasts are received by all interfaces configured with addresses from within the same prefix without forwarding.

The IPv6 Link Model, in figure 2, axiomatically assumes that neighbor relationships are symmetric: if communication from air interface A to air interface B is possible in one hop, then communication in the reverse direction is also possible -in other words, connectivity between neighbor interfaces is assumed symmetric.

An even shorter summary of the IPv6 link model is to say that an IPv6 link looks like an Ethernet.

IPv6 Addressing Model, Address Scopes and Uniqueness

As described in section 2.1, the notion of an "IPv6 link" is tied with that of an IPv6 subnet prefix: all interfaces which are configured with the same subnet prefix are considered to be on the same IP link and, thus, for communication between nodes on the same subnet, no forwarding is required and no decrement of TTL/hop-limit is performed. In addition to this relationship between link and prefix, IPv6 introduces address scopes -Link-Local and Global -and mechanisms by which addresses are constructed using Interface IDs.

A Link-Local address is valid for communication with a device on the same link: an IPv6 datagram with a Link-Local source or destination address is not to be forwarded on the network layer, but is to be received by a destination on the same link -or not received at all. The only requirement for an unicast Link-Local address to be useful is, thus, that it is unique on the local link; the same Link-Local address may well be in use on another, disjoint, link, however as IPv6 datagrams with Link-Local addresses are never to be forwarded, no ambiguities exist.

A Global address is valid for communication beyond the local link: an IPv6 datagram with a Global source and destination address can be forwarded on the network layer and, thus, be received by a destination on the same or on a different link -or not received at all. For an unicast Global address to be useful, it must, thus, be unique across the entire network.

It is important that these address uniqueness requirements are universally satisfied. This is ensured in IPv6 by having an interface detect when it connects to a link (typically, by way of a discrete link-layer trigger), upon which it constructs a Link-Local IPv6 address by concatenating the Link-Local Prefix (FE80::/10) with an Interface ID, typically derived from the MAC address of that interface. Duplicate Address Detection (DAD) [START_REF] Thomson | RFC2462: IPv6 state-less address autoconfiguration[END_REF] is then performed, to verify that this address is not already in use on the link. DAD employs Link-Local Multicast, interrogating all other interfaces on the link as to if they are already using that address, by way of Neighbor Solicitation (NS) messages. Absent a reply to this interrogation -by way of Neighbor Advertisement (NA) messages -the address is assumed unique on the link and henceforth used. As all Link-Local addresses share the same Prefix (FE80::/10), this DAD procedure in reality verifies that the chosen Interface ID is unique across the link.

Global addresses are constructed by concatenating the Global prefix of a link with the Interface ID of an interface, verified to be unique during the configuration procedure for Link-Local addresses. The Global Prefix is obtained from a router on the link2 , by way of Router Solicitation / Router Advertisement messages [START_REF] Narten | RFC2461: Neigh-bor Discovery for IP Version 6 (IPv6)[END_REF]. It follows that uniqueness of a Global address for an interface relies on (i) the Interface ID being unique on the link to which the interface is connected, and (ii) unique prefixes being delegated to routers. It follows, then, that a Global address is valid only as long as that interface is connected to the link on which the router providing the Global prefix is present.

An interface must also detect when it disconnects from a link (typically also by way of a discrete link-layer trigger), upon which it must cease to use the previously configured addresses. Thus, in IPv6, a link describes a welldetermined set of network interfaces, all able to communicate directly with each other without forwarding, and with all interfaces in a single (link-local multicast) transmission be able to reach all other interfaces on the same link. This set of network interfaces is maintained by way of explicit and discrete signals, allowing an interface to detect its connection to a given link.

A summary description of the IP addressing model is therefore, that (i) addresses are of a specific validity scopes, global or local, where (ii) within validity scope of an address, it must be used by no more than one interface, and (iii) an address of global validity scope assigned to an interface must be topologically correct, i.e., it must match the Global prefix provided by the router on the IP link to which the interface connects.

IPv6 Network Layer Considerations Regarding WAVE

As indicated in section 1, the IEEE 1609 family of specifications present a minimal set of considerations for IPv6 operation for vehicular networks. Devices in vehicular networks are separated into On-Board Units (OBUs) and Road-Side Units (RSUs), with the latter providing, as needed, infrastructure and configuration support for the former. With respect to IPv6 operation in such networks, the IEEE 1609 family of specifications simply state that:

• IPv6 is provided as a data plane protocol, and that the "standard IPv6 protocol" is used;

• IP configuration parameters (global prefixes, ...) are provided in the WAVE Routing Advertisement (WRA) messages;

• OBUs advertising services to other OBUs do so using Link-Local addresses: OBUs provide services to (1-hop) neighbors only, and therefore acquiring and maintaining topologically correct Global addresses is wasteful;

• RSUs are identified by either Link-Local or Global addresses;

• Link-Local addresses are derived by the device, are not globally unique and are not usable for routing;

• NDP [START_REF] Narten | RFC2461: Neigh-bor Discovery for IP Version 6 (IPv6)[END_REF], otherwise used for populating the neighbor cache, is asserted to generate a substantial and unacceptable amount of traffic, and thus other means for populating the neighbor cache (ICMPv6, IPv6 PDUs) are employed;

• NDP is, however, not excluded for "cases where it might be needed".

WAVE air Interface "Link Model"

The air interfaces of a WAVE system, and the "links" to which they attach, have different characteristics from those described in section 2.1, and are therefore detailed in this section. The resulting "WAVE link model" does not provide for a direct mapping to the IPv6 link model, thus considerations for operating IPv6 over this "WAVE link model" are detailed in section 2.5. Symmetric to the IPv6 Link Model in figure 2, figure 3 illustrates the relationship between WAVE air interfaces, and serve for elaborating the "WAVE link model" in the discussions in this section.

Each air interface is a (radio) broadcast interface, able to establish a direct link layer communication with air interfaces which are within its coverage area. In figure 3, this coverage area is approximated by a simple disc of fixed radius (light gray discs) -in the real world, both the shape and size of the coverage area is variable as a function of the interface, interference from the environment etc. Referring to figure 3 if, e.g., if N3 transmits, then this transmission may be received by N2 and N4, but not by N1 and N5. This implies that, e.g., N3 and N4 -despite being neighbors and on the same "link" -do not share the same view of which other nodes are neighbors and on the same "link": N3 considers that it is on the same "link" as N2 and N4, whereas N4 considers itself to be on the same "link" as N3 and N5. Thus, a set of air interfaces within a region -even if using the same channels and modulation -may not all be able to communicate to all other air interfaces, without intermediate relaying. A link-local multicast transmission from one air interface may not (even disregarding losses) be able to be received by all other air interfaces; indeed, a multicast transmission from one air interface may not be able to reach the same set of air interfaces as would a multicast transmission from its closest neighbor air interface. This is the case in figure 3, where no two air interfaces can directly transmit to the same set of other air interfaces.

An air interface has an "interference area" which may be greater than its coverage area, i.e. a transmission by N3 in figure 3 will, as indicated above, be correctly received by the interfaces N2 and N4. At the same time, however, this transmission may be propagating to interfaces of N1 and N5 where, while the transmission can not be correctly decoded, it can be detected, and cause interference with other transmissions which could otherwise be correctly received over the air interfaces of N1 and N5 (such as transmissions from N0 and N6). Figure 4 illustrates a situation where, for some reason (powerful transmitter, environmental interference, large antenna, ...), the air interface of N1 has a large enough coverage area for its transmissions to be received and correctly decoded by the air interface N2. The air interface of N2, on the other hand, has a much smaller coverage radius, such that transmissions from the air interface of N2 can not be received and correctly decoded at the air interface of N1. Thus INRIA asymmetric -or more precisely, unidirectional -connectivity between the air interface of N1 and the air interface of N2 exists: N2 sees N1 as a neighbor (since the air interface N2 can receive transmissions from the air interface of N1), whereas N1 does not see N2 as a neighbor (since the air interface of N1 can not receive transmissions from the air interface of N2).

A vehicular network, naturally, represents a dynamic topology: OBUs move relatively to each other and to RSUs. The resulting network is a highly dynamic graph, where the neighborhood of an air interface is also dynamic and varies over time -due to mobility, and due to changing environmental factors: two air interfaces which were not in communications range a moment ago may become neighbors, and vice-versa.

Thus, neighboring air interfaces may experience distinctly different neighborhoods, may not even agree on if they are or are not neighbors, and may at any time become, or cease to be, neighbors.

Finally, as the set of air interfaces "on a link" are communicating via radio waves rather than electrical wires, there are no implicit physical signals, allowing an air interface to detect its association or disassociation with a given set of other air interfaces "on the same link". And the set of air interfaces "on a link" may be subject to constant and rapid change. In a certain way, it is tempting to add "this is just as well", as the other "on a link" properties expected in the IPv6 Link Model do not hold, as described above.

Considerations for IPv6-over-WAVE

Considering the differences between the IPv6 link model, described in section 2.1, and the WAVE link model, described in section 2.4, verbatim use of the standard IPv6 protocol stack, as the IEEE 1609 family of specifications stipulate, is not sufficient.

Air Interface Addresses

addresses for OBUs are specified to be link-local in [START_REF]The Wireless Access in Vehicular Environments (WAVE) Working Group of the Intelligent Transport Systems (ITS) Committee[END_REF]; it is further stated that configuring air interfaces of OBUs with Global Addresses is undesired due to the need to maintain topological correctness of such Global Addresses. This is necessary, but not sufficient, for these interfaces to be configured with "valid" addresses. Link Local addresses assigned to interfaces should in addition be globally unique, i.e., must be derived from some globally unique token. The reason for this is, as vehicles -and so their OBUs -may move, any two OBU air interfaces may at some point in the future become direct neighbors. On the other hand, since there is no guarantee that an arbitrary pair of air interfaces of OBUs will always remain neighbors, no IPv6 subnet prefix can be configured on an interface: vehicle movement may render such two air interfaces unable to communicate, requiring reconfiguration of the on-link IPv6 subnet prefix to respect the IPv6 Link Model assumption that "two interfaces with the same subnet prefix can communicate directly", as described in section 2.1. The recently published RFC5889 [START_REF] Baccelli | RFC5889: IP Addressing Model in Ad Hoc Networks[END_REF] describes an IP addressing model for ad-hoc networks; the considerations described herein apply equally to air interfaces in WAVE networks, notably:

• An IP address configured on an air interface should be unique, at least within the routing domain (in this case, the vehicular network at large), and

• No on-link subnet prefix is configured on this air interface.

.

Supporting Protocols Employing Link-Local-Multicast

protocols such as DHCP, NDP and Stateless Address Autoconfiguration, assume the multicast characteristics of the IPv6 Link Model; as stated, these do not hold for the WAVE Link Model. NDP basic mechanisms such as Neighbor Solicitation (NS) do not operate as expected: the set of air interfaces which will receive such a NS is the set of air interfaces which, at the time of emission of the NS, happen to be within radio range. Thus, e.g., Duplicate Address Detection (DAD) will not ensure the desired uniqueness properties of IPv6 Link Local Addresses.

Discrete Link Layer Association Triggers

such triggers, otherwise used for initiating IPv6 interface configuration, are absent on the WAVE Link Model. Thus, protocols, including [START_REF] Narten | RFC2461: Neigh-bor Discovery for IP Version 6 (IPv6)[END_REF], [START_REF] Thomson | RFC2462: IPv6 state-less address autoconfiguration[END_REF], and the address configuration assumption that an interface can detect when it "disconnects" and thus should cease using previously used addresses, can not rely on such. Information can thus not be "solicited when events happen" but must be beaconed, and protocols adopted accordingly.

Communications Bidirectionality

link bidirectionality cannot be assumed. Experience with air interfaces show that if a device A hears service advertisements from another device B (OBU or RSU), this does not guarantee that device B can hear any service request sent by device A -i.e., it is not uncommon that links are unidirectional. Thus any alternative mechanism to be developed should at least verify link bidirectionality before relying on it.

3 Other Challenges with WAVE using the IPv6 Protocol Stack

The IPv6 protocol stack includes various additional protocols, above the network layer protocols described in section 2. Regardless of how the described network layer issues are resolved, attention must be paid to operation of the transport and the application layers. This section briefly overviews some of these additional considerations.

Transport

At the transport layer, the IPv6 protocol stack proposes two types of protocols: TCP, a reliable, rate-adapting mechanism enabling end-to-end transport of application data across several IP hops and requiring bi-directional communication

INRIA

between the peers for acknowledgements etc. The second IPv6 transport protocol is UDP, a much simpler protocol providing no rate-adapting or reliability mechanism and so no signaling from the destination to the sender in a traffic flow.

It is worth noting that TCP is often very inefficient in wireless ad hoc environments [START_REF] Holland | Analysis of TCP performance over mobile ad hoc networks[END_REF], especially when faced with mobility: TCP was designed to interpret packet loss as traffic congestion and to diminish sending rates in this case, whereas in wireless networks, packet loss may have causes that are other than traffic congestion, such as interfaces moving out of reach, collisions or interference. Also, if a TCP connection is established between two air-interfaces, subsequently moving out of range before the connection is terminated, connectionstate remains for timing out (and possibly causing extraneous transmissions), not cleared up by the usual end-of-connection signaling. Therefore, TCP is usually not employed in VANETs, which leaves UDP as the only viable alternative within the standard IPv6 stack. [START_REF]The Wireless Access in Vehicular Environments (WAVE) Working Group of the Intelligent Transport Systems (ITS) Committee[END_REF] recommends the use of UDP, however the reasons given (in section 6.4.3 of [START_REF]The Wireless Access in Vehicular Environments (WAVE) Working Group of the Intelligent Transport Systems (ITS) Committee[END_REF]) relate to the matching of "the connectionless nature of WAVE transmissions" only. The authors submit that there are also technical reasons for why TCP might be a lesser appropriate choice for this environment.

Applications requiring rate-adapting or end to end transport reliability services may not be satisfied with what the standard IPv6 protocol stack has to offer.

Pseudonimity

The IEEE 1609 family of specifications also promise to support MAC address changes to provide pseudonymity, i.e., to ensure that a device's non-temporary identity, and its long-term patterns of behavior, cannot be deduced from its network traffic and are only available to authorized parties.

However, IEEE 1609 specifications do not provide a way to generate or assign pools of globally unique network addresses, aside of basic "random" local generation which is likely to provide duplicate network addresses if devices change their network addresses too frequently. Note that the specifications do not define how frequently MAC address changes should take place in order to provide pseudonymity. Nevertheless, it is doubtful that pseudonymity can be achieved without a significant probability of duplicate network addresses using the current IEEE 1609 specifications.

In the same vein, in order to provide pseudonymity at layers above the network layer (which may be necessary to provide user pseudonymity in the end), similar issues are bound to arise if devices must change their IP addresses frequently. More generally, providing pools of globally unique IDs, dynamically and in a distributed manner, becomes a hard problem if the number of possible IDs is not extremely large.

Therefore, applications' requirements concerning pseudonymity may not be entirely satisfied with what the standard WAVE and IPv6 specifications have to offer so far, and thus, it is presently left to these applications to provide such services (if at all possible). Moreover, one should note that, as quickly mentioned in the IEEE 1609 specifications, frequent MAC or IP address changes will disrupt most applications.

Conclusion

This memorandum has provided an overview of the issues concerning IPv6 use over WAVE, the protocol suite for wireless access in vehicular environments currently developed by the IEEE. While WAVE promises communications services to applications via IPv6 stack support -defined in the IEEE 1609 family of standards -this memorandum has shown that this support underspecified, and described the issues that are so far left unaddressed concerning IPv6 operation for WAVE. This memorandum has also analyzed the challenges in designing solutions to overcome these issues, and provided guidelines regarding the design of appropriate solutions.

Figure 1 :

 1 Figure 1: Dual stack, IPv6 and WAVE.

Figure 2 :

 2 Figure 2: IP Link Model: hosts (H) connected to the same link have assigned IP addresses from a common prefix, possibly assigned by a router (R).

Figure 3 :

 3 Figure 3: Nodes (N) with air interfaces. The light grey area indicates the coverage area of each air interface. The dark grey circle indicates the interference area of the air interface of N3.

Figure 4 :

 4 Figure 4: Neighbor asymmetry.

http://www.ietf.org RR n°7383

RR n°7383

Global addresses are only relevant in case the network can provide multi-hop communication, i.e. a router is present on the link.