## 7 Conclusions and Open Issues
This implies obtaining and dealing with different kind of information for every purpose (safety warnings, traffic load, hotspots' pictures, _etc._), though it is possible to deduce some of this information (such as traffic load) from the interchange of previous messages, thus reducing communications overhead. In addition, this may require the establishment of priorities for the different types of network information flows. Several works consider the use of the WSN-oriented 802.15.4 standard for the Vehicle to Infrastructure communication (and vice versa). As it was mentioned, this standard is not suited for mobility. Only a preliminary evaluation of the effect of the vehicle speed on the link quality has been conducted [14], stating that up to 70 Km/h there are packet losses but these are not important. However, the association process of mobile devices to static coordinators at the roadside is not considered, which is required by the standard. The main goal of the association is searching for the radio channel in which the network is operating prior to joining it. This process may take up to several minutes, being therefore unacceptable in most ITS scenarios [87]. A straightforward solution is to force all sensor nodes to operate in a predefined channel and modify the protocol operation to automatically select that channel without performing any search. However, this prevents from selecting between different channels in order to avoid interferences from, for instance, nearby Wi-Fi networks. Consequently, there is a need to investigate effective methods for the channel selection. This has been done in other scenarios considering mobility [95], but efforts are still required to find proper solutions in the vehicular scenario. A reasonable alternative though is the use of appropriate VANET standards for Vehicle to Infrastructure communications, in spite of being less power efficient. Nevertheless, the development of vehicular applications has been affected until now by the unavailability in the market of devices capable of doing this. With the recent publication of the IEEE 802.11p standard, this is no longer a major concern, leading to a massive appearance of compliant devices which may act as OBUs and RSUs [96]. In addition, this equipment fosters the integration with other wireless technologies by means of pluggable interfaces, which may support WSN standards such as IEEE 802.15.4. Similarly, there are other existing pieces of hardware which may solve some of the problems that have been presented throughout the paper and whose use has not been reported yet. One of these problems is the relatively limited transmission range of 802.15.4 in comparison with standards such as 802.11p. In this case, there are 802.15.4 compliant devices such as Xbee Pro [97] which could be used in order to extend the transmission range to distances greater than 3 Km, thus enabling either a higher separation between nodes or more time to alert vehicles. In case of using these devices, it should be noted that the design constraints change since, instead of minimizing the duty cycle, the main goal would be minimizing the number of packets transmitted as they consume 3 to 4 times more energy than their reception mode. Something similar happens when trying to solve the ground effect found when sensors are placed on the road surface or in small holes in it. For the latter case however, instead of more powerful devices, arrays of antennas could be considered in order to modify the radiation pattern to provide its maximum in the plane parallel to the road. Finally, another open issue regards the sensors and methods employed for the detection of vehicles. In this respect, in currently WSN-based employed systems, the CPU has an important implication in detection, managing the operation of the other components. This increases power consumption, since the CPU must be turned on for every data sampling.