Proceedings of International Conference on Developments in Engineering Research
www.iaetsd.in
Zigbee For Vehicular Communication Systems J.Ram Harish Yadav1, K.Dhanunjaya2 1
2
PG Student, Department of Electronics & Communication Engineering, ASCET, Gudur, A.P, India. Head of the Deepartment, Department of Electronics & Communication Engineering, ASCET, Gudur, A.P, India 1
ramharish.j@gmail.com
ď€ Abstract:Vehicular communication is a popular
topic in theacademia and the car industry. The aim of this growing interestis to develop an effective communication system for theIntelligent Transportation System (ITS). In this paper wepresented the model of wireless base station goodput evaluation.We used wireless access point model as a queuing system withvariable requests and the auto traffic model. The performance ofthe wireless networks can be impacted from a variety ofparameters, such as radio communication range, availablebandwidth and bit rate, the number of clients in wireless networkrange and vehicle speed. The basic parameters were analyzedand presented in this paper. Index Terms:Short Range Vehicle Network; 802.11n; wirelessnetwork; goodput; network performance; transport; mobilestations; auto traffic; vehicle speed; Markov chain. I. INTRODUCTION The needs to enhance road safety, traffic efficiency and to reduce environmental impact of road transport are seriouschange for both academics and industry. Researchers aregreatly interested to develop vehicular communication andnetworking technology in two realistic ways vehicle tovehicle (V2V) in ad hoc mode and vehicle to infrastructure(V2I) with fixed nodes along the road. The potency toexchange information wireless via V2X is a foundationstone for building powerful Intelligent Transport Systems(ITS). In Europe, USA and Japan are great efforts madefrom automakers and governments to reach single standardsthrough the several and common projects such as CAR 2CAR Communication Consortium, Vehicle Safety Communication Consortium, and EUCAR SGA etc. Result fromcommon effort is an international standard, IEEE802.11p[2], also known as Wireless Access for VehicularEnvironments (WAVE). This standard will be used as thegroundwork for Dedicated Short Range Communications(DSRC).
ISBN NO : 378 - 26 - 13840 - 9
This type of communication has potential toimprove safety on the road, traffic flow and provide comfortfor passengers and drivers with expedited applications suchas INTERNET, network games, automatic electronic tollcollection, drive-through payments, digital map update,wireless diagnostic and flashing etc. DSRC is the one stepin the future, because it lets inter-vehicle and vehicle toinfrastructure wireless communication. Wireless networking based on IEEE802.11 technology[3] has recently become popular and broadly available atlow-cost for home networking and free Wi-Fi orcommercial hotspots. The DSRC starting idea was to equipvehicular network nodes with off-the-shelf wirelesstechnology such as IEEE802.11a. This technology is costeffective and has potential to grow and new versions havebeen recently produced. The latest standard of wirelesslocal area network (WLAN) is IEEE802.11n [4]. The IEEE802.11n standard promises to improve and extend mostpopular WLAN standards by significantly increasingthroughput, reliability and reach. Nowadays dispositions of WLAN-based accesstechnology are predominantly to stationer indoor andoutdoor users who are most slowly moving and in rangelimited. Despite the fact that the standard has not beendeveloped for fast dynamic usage, nothing limits it to beevaluated for vehicular communication systems. Themotivation is to understand the interaction between thevehicle speed and goodput of WLAN-based network.Realizing field trials for goodput evaluation ofvehicular wireless communication systems is very difficultand costly because many vehicles and communicationequipments need to be purchased or rented, and also manyexperimenters need to be employed. Given such problems,it is highly desirable to obtain a mathematical descriptionof process with real data from small scale scenarios ofpractical measurement results and performance evaluationsprior to conducting field trials as it is made in this work.
INTERNATIONAL ASSOCIATION OF ENGINEERING & TECHNOLOGY FOR SKILL DEVELOPMENT 122
Proceedings of International Conference on Developments in Engineering Research
This paper constructs as follows: After introducing theproblem in Section 1, Section 2 provides some Vehicular Communication Systems. Then, in Section 3 SeVeCom Implementation and demonstrating the analysis results inSection 4. Section 5 summarize and concludes this paperwith a brief description on future works. II. VEHICULAR COMMUNICATION SYSTEMS There are significant differences between devices such asmobile phones or desktop computers connected to the Internetand devices in a VC system. Differences in development,production, and operation, determine VC-specific constraintsand conditions: 1) Vehicles have a long life span, lasting several yearsin most cases. This makes it hard to change onboardsystems as reaction to new upcoming risks to the vehiclesafety. 2) Owners have constant physical access to and full controlover vehicles. In spite of the involved safety risks,many users might try to modify or “enhance” theirvehicles. From a manufacturer’s point of view, the riskof hardware tampering cannot be neglected. 3) No technical expertise on vehicle electronics or VCsecurity aspects is expected from a user that runs avehicle. Hence, the vehicular security measures have tooperate autonomously with no need for intervention orfeedback from the user.
www.iaetsd.in
adding, replace, and reconfigurecomponents (for example, substitute cryptographic algorithms)throughout the life cycle of the vehicle. The large number and the variety of vehicles have tobe taken into account. Even for a single car type, differentproduction and equipment lines lead to many distinct versionsand variants. Nonetheless, it should be possible to integratea security system into all those platforms. In addition, thecommunication stack and security measures might be designedby different teams or vendors; a situation that clearly requireswell-defined but still flexible interfaces. These reasons ledto the development of the so called “hooking architecture”,which introduces special hooks at the interface between everylayer of the vehicular communication system. The hookingarchitecture introduces an event-callback mechanism into thecommunication stack which allows adding security measureswithout the need to change the entire communication system.The security system in a vehicle has to fulfill real-time ornear realtime requirements. For the underlying cryptographicprimitives, this implies optimized cryptographic hardware,in order to guarantee the near real-time performance. Thepotential trade-off between security and performance has tobe well balanced.To enable VC systems to withstand future, yet unknownattacks, besides the traditional prevention-oriented approach,functionalities to detect attacks, such as intrusion detectioncapabilities, and to recover after an attack, are needed. In thelong run, the goal is to enhance the resilience of the system. III. SEVECOM IMPLEMENTATION
4) Robustness requirements and time constraints are demanding.Functions necessary, for example, for drivingor alerts received via the VC system must be processedin real-time: delays or errors could lead to vehicle malfunctions,driving errors, and consequently to physicaldamages and injuries. 5) Liability and conformance require precise formulationof legal issues. Differing regulations and requirements invarious countries make it even more difficult to addressthese challenges. These observations have consequences on the implementationof a VC security system. Due to the long vehicle lifecycle, it cannot be ensured that all threats are thwarted at thetime of development. Therefore, the VC security mechanismsshould be flexible, adaptable, and extensible, to allow lateradjustments to changing security requirements. To address this need, we propose a component-based security architecture forVC systems, which allows
ISBN NO : 378 - 26 - 13840 - 9
The SeVeCom project defines baseline securityarchitecture for VC systems. Based on a set of designprinciples, SeVeCom defines an architecture that comprisesdifferent modules, each addressing certain security and privacyaspects. Modules contain components implementing one partof system functionality. The baseline specification providesone instantiation of the baseline architecture, building on wellestablishedmechanisms and cryptographic primitives, thusbeing easy to implement and to deploy in upcoming VCsystems. A. Baseline Architecture: Deployment View The SeVeCom baseline architecture addresses different aspects,such as secure communication protocols, privacy protection,and in-vehicle security. As the design and development ofVC protocols, system architectures, and security mechanismsis an ongoing process, only few parts of the overall system
INTERNATIONAL ASSOCIATION OF ENGINEERING & TECHNOLOGY FOR SKILL DEVELOPMENT 123
Proceedings of International Conference on Developments in Engineering Research
areyet finished or standardized. As a result, a VC security systemcannot be based on a fixed platform but instead has to beflexible, with the possibility to adapt to future VC applicationsor new VC technologies. To achieve the required flexibility, the SeVeCom baselinearchitecture consists of modules, which are responsible fora certain system aspect, such as identity management. Themodules, in turn, are composed of multiple components eachhandling a specific task. For instance, the Secure CommunicationModule is responsible for implementing protocols forsecure communication and consists of several components,each of them implementing a single protocol. Components areinstantiated only when their use is required by certain applications,and they use well-defined interfaces to communicatewith other components. Thus, they can be exchanged by morerecent versions, without other modules being affected.
Fig.1. Baseline Architecture: Deployment View. As shown in Fig. 1, the Security Manager is the centralpart of the SeVeCom system architecture. It instantiates andconfigures the components of all other security modules andestablishes the connection to the Cryptographic Support Module.To cope with different situations, the Security Managermaintains different policy sets. Policies can enable or disablesome of the components or adjust their configuration, forexample, to enhance or relax the parameters for a pseudonymchange under certain circumstances.
www.iaetsd.in
inspired by similararchitectures such as the Linux Netfilter kernel subsystem.Inter Layer Proxies (ILPs) are inserted at several points in thecommunication stack. Every ILP maintains a list of callbackhandlers that are to be notified of certain events.During initialization, the SeVeCom components can registerat an ILP, subscribing for certain message types and direction(up or down the stack). Therefore, they have to implement anevent listener interface and use the registerHandler() methodto connect to an ILP. Some components may have to register atmultiple ILPs, subscribing for different kinds of packets. Whena message arrives at an ILP, an event callback is triggered forall components that have registered for this message type andtheir eventHander() method is called. The callback includes areference to the received message, and the component is thenable to inspect or modify it. By the return value the componentindicates if the message was modified, if it should be reinsertedinto the stack, or if it should be simply dropped by the ILP. The Secure Beaconing Component, for example, connects tothe ILP above the MAC layer and checks the signatures of allincoming beacon messages. Beacons with invalid signaturesare either discarded or tagged. Using this hooking architecture,it is possible to transparently integrate security functionalityinto an existing network stack with minimal modifications. Whereas events are triggered by the communication stack,the security system can also access the stack by means ofcommand calls using a well-defined API offered by stacklayers. Command calls could, e.g. instruct the MAC layer toset its MAC address to that of a new pseudonym.The hooking concept makes certain assumptions aboutthe network stack. It assumes a layered architecture, wherethe ILPs can be inserted in between, and the stack has toimplement a certain command API, e.g. for change of MACaddresses. To be able to port the SeVeCom architecture tomany different communication platforms, we also providean additional convergence layer: This defines an abstractioninterface that proxies call between the communication systemand the security components. Whenever the SeVeCom systemis ported to a new platform, besides adapting to differentpacket formats, only the ILPs and the convergence layer haveto be modified, while all other components remain unaffectedboth in terms of security and communication. C. Hardware Security Module
B. Communication Stack Integration To be independent of the actual communication stack, theintegration of the SeVeCom security system into the protocolstack is based on a hooking concept,
ISBN NO : 378 - 26 - 13840 - 9
As explained, the purpose of the Hardware SecurityModule (HSM) is to provide a physically protected environmentfor the storage of private keys
INTERNATIONAL ASSOCIATION OF ENGINEERING & TECHNOLOGY FOR SKILL DEVELOPMENT 124
Proceedings of International Conference on Developments in Engineering Research
and for the execution ofcryptographic operations using them. Clearly, the full implementationof a HSM is beyond the scope of the SeVeComProject, but we can summarize the main requirements thatsuch an implementation should meet in order to be applicablefor securing vehicle communication systems.First of all, the HSM must be tamper resistant, to someextent. High-end tamper resistant modules (such as the IBM4758 Cryptographic Coprocessor) are too expensive to beadded to every vehicle. At the same time, we observe thatLow-end tamper resistant devices (such as smart cards) donot provide all the functionality that we need. In particular,commercially available low-end devices do not have built-inbatteries, and consequently, cannot provide a trusted internalclock. As pointed out, without a trusted source of time,such devices are not able to produce time-stamps that canbe trusted by other participants of the system. Therefore, weneed an HSM implementation somewhere between highendand low-end devices. A potential approach is to implementthe HSM as an Application-Specific Integrated Circuit(ASIC)with some special coating that provides a certain level oftamper resistance. Such a customized device can provide allthe necessary functionality by design and it can be producedin large quantity at sufficiently low costs. Second, the HSM must have an API, through which itcan provide services to the other modules of the securityarchitecture that run on the OBU. This API should supportthe digital signature and timestamping service, the decryptionservice, as well as the key and device management servicesdescribed. We specified such an API in the SeVeComProject, however, lacking the appropriate HSM hardware; weonly implemented it in the form of a software library runningon a general purpose computer. Nevertheless, besides beinguseful for demonstration purposes, our implementation canalso serve as a reference for future implementations on realHSM devices. In our implementation, we used ECDSA fordigital signature generation, ECIES with HMAC-SHA1 andAES-CBC for encryption, and we fully implemented the keymanagement services of the HSM described. Finally, we note that some examples published showthat physically secure modules can successfully be attackedthrough their weakly designed API. For this reason, we usedformal verification techniques to verify the SeVeCom HSMAPI. Our method is based on the applied pi-calculus and anautomated verification tool called Prove it. We proved that akey generated by an adversary cannot be implanted as a newroot key in the HSM through the API. Additionally, short-termand long-term private keys
ISBN NO : 378 - 26 - 13840 - 9
www.iaetsd.in
are proved not to be revealed asthe result of possible series of function calls. D. In-Vehicle Security In order to achieve their full potential, VC systems need access to the in-car network and sensors that observe thecurrent status of the vehicle and the environment. This enablesthe VC system to process signals such as emergency braking,airbag activation, and slippery road detection, thus greatlycontributing to the avoidance of accidents and improvementof road safety.On-board system signals are transferred inside the carthrough different networks and domains. Usually, the networkarchitecture and the incar gateways restrict the signals tothe defined network segments and prevent information fromleaving its dedicated domains. This clear architecture andstrict separation is one measure that ensures the entire vehicle,especially its vital functions (brakes, engine or airbag control),always operate reliably and cannot be attacked from the outside. If this were to be changed into a more open architecture,for example, allowing reading out sensor information fromin-vehicle networks or displaying and reacting to warningmessages from external sources, it would be absolutely necessaryto ensure that in-vehicle systems are protected from anyexternal malicious influence.The In-vehicle Security Module protects the interface betweenthe incar networks and the wireless communicationsystem. It controls external access to the in-car networks,onboard control units and vehicle sensor data, but it alsoensures that data and services required by other V2V andV2I applications are provided correctly. Within the in-vehiclesecurity module, two main components are provided: (i) Afirewall that controls the data flow from external applicationsto the vehicle and backwards, and (ii) an Intrusion DetectionSystem (IDS) that constantly monitors the status of the incarsystems and provides real-time detection of attacks. The firewall realizes a packet or application based firewallapproach. Its rule-based table states which application isallowed to access each kind of data or service the IDS candynamically add rules to the firewall table, in order to denyaccess for a specific application or disable a service.The IDS is based on an anomaly detection approach,which implies that normal on-board system behavior is clearlydefined and specified. If an event results in an on-board systemstate that is not part of the standard specification, a potentiallydangerous situation is detected. Depending on the source andtype of the
INTERNATIONAL ASSOCIATION OF ENGINEERING & TECHNOLOGY FOR SKILL DEVELOPMENT 125
Proceedings of International Conference on Developments in Engineering Research
event, appropriate reactions are taken to get thesystem back to a secure and safe state. IV. ANALYTICAL MODEL Realizing field trials for good put evaluation of vehicular wireless communication systems is very difficult and costly. Numerous vehicles and communication equipments need to be involved, and also many experimenters need to be employed. In this case, it is highly desirable to obtain theoretical analysis with real data from small scale scenarios of practical measurement results and perform an evolution prior to conducting field trials. In terms of analysis methods, were mapped previous approximations of vehicle mobility and good put into Markov M/M/1/N chain model. Use of Markov model is novel for evaluation of IEEE802.11n standard in a mobwith legacy standard (i.e. IEEE802.11g)
www.iaetsd.in
B. Results In the computation of the analytical model in the previous subsection was constructed a topology with an access point sending file data to all vehicles within coverage range of an access point. In the computation, each vehicle maintains its speed as it derives through the access point coverage range. The computation compares the results derived from trial field tests with analytical model for the single-lane in vehicle traffic. The range of good put that a vehicle can receive from the access point per pass shown in Fig.2. The results here are for the case where there are two types of vehicles, i.e, wireless-equipped and non-wirelessequipped vehicles. The type of vehicles can be interpreted as the penetration rate of wirelessequipped vehicles for use.
A. System model descript
From the Fig.2 can make the following observations:
For this model computation, was considering the case where the access point’s transmission data rate is variable through the access point coverage range.Primitive packets flow from finite wireless mobile users N and arrive to an infinite buffer of the system and are served by the server or wireless access point.
At low traffic density corresponding to high vehicle speed, there are few vehicles and as such there is a few connections using the access point resource and the value of good put is close to maximum. It is about two times less than plausible maximum good put.
In this case our system is expressed by the Kendall notation like M/M/1//N where first M-defines exponential inter arrival times between packet distribution (Poisson process), second M- defines exponential data packets transmission time distribution , next number defines the transmission channel and N- represents the number of packet sources.Queuing models for M/M/1/N systems are very elegant in analysis of wireless data networks in transmission channel with no packet loss and vehicles simultaneously under the coverage of the access point speed-N (v) (i.e, ρ (v). Based on this M/M/1/N queuing model the average good put by a vehicle can be computed as follows:
where π0 represent the probability of the idle system
where j = 1,2,3,….,N(v), π – the data packet transmission rate of the channel between vehicular and base station, λ is the packet arrival rate in the coverage range of the access point
ISBN NO : 378 - 26 - 13840 - 9
Fig.2. Average good put of a vehicle at different speed and WLAN penetration rate On low velocity increase value of vehicles and bandwidth connections increases leading to lower values of good put for the individual user. Despite reduction of maximum good put due to mobility at a velocity from 50 km/h to 100 km/h improves the good put value of a vehicle.
INTERNATIONAL ASSOCIATION OF ENGINEERING & TECHNOLOGY FOR SKILL DEVELOPMENT 126
Proceedings of International Conference on Developments in Engineering Research
www.iaetsd.in
Penetration rates specify the possible optimal values of WLAN performance.
[3] IEEE 802.11, The Working Group for WLAN Standards,http://grouper.ieee.org/groups/802/11/ , April, 2006.
V. CONCLUSION AND FUTURE WORK
[4] ”Part 11: Wireless LAN Medium Access Control (MAC) and PhysicalLayer (PHY) Specifications Amendment 5: Enhancements for HigherThroughput”, http://ieeexplore.ieee.org/servlet/opac?punumber=53 0729, IEEE, 29.October, 2009.
In this article was presented field trial evaluationstogether with theoretical analyses of the IEEE802.11nstandard comparing with legacy standard in the vehicleenvironment. The trial field test was performed in thecontext of simple scenario of one vehicle and access point.At various velocities has been testing the performance ofWLAN. Wireless network link under fluent number ofvehicles respectively active users simultaneously realizingsuch field trials for goodput evaluation is very difficult andcostly. Therefore a simple mathematical model for goodputevaluation of vehicular communication systems in V2Iscenario was presented and analyzed for understanding thebasic processes in wireless data networks prior toconducting larger field trials. We mark that while numbers of necessary real time application of vehicular networks are the dissemination ofsafety and traffic condition messages, we can assume Wi-Fi for vehicle communication systems in the near future willalso be requested to provide different applications, for e.g.web browsing, video streaming, VoIP, downloading files,WiFi radio, etc. These types of applications have arequirement for high throughput during connections to theaccess point and existing mobile communication systemsexcept WLAN aren’t able to provide growing needs.And it is also important to note that the results wereshowing her serve as information for future analysis anddesign of vehicle networking systems.
[5] J. P.Singh, N. Bambos, B. Srinivassan and D. Clawin, Wireless LANperformance under varied stress conditions in vehicular trafficscenarios, proceedings of Vehicular Technology Conference, 2002,Vol. 2, pp. 24-28. [6] J. Ott, D. Kutscher, “Drive–thru Internet: IEEE 802.11b forAutomobile Users”, IEEE Infocom, Hong Kong, 2004. [7] R. Gass, J. Scott, C. Diot, “Measurements of In– Motion 802.11Networking”, WMCSA '06. Proceedings, 2006, pp. 69-74. [8] M. Wellens, B. Westphal, P. Mähönen “Performance Evaluation ofIEEE 802.11–based WLANs in Vehicular Scenarios”, Proc. VTCSpring, 2007. pp. 1167–1171. [9] M. Rubinstein, F. Ben Abdesslem, S. RodriguesCavalcanti, M. EliasMitreCampista, R. Alves dos Santos, L. Costa, M. Dias de Amorim,O. Duarte, “Measuring the capacity of in–car to in–car vehicularnetworks” IEEE Communications Magazine, Vol. 47., Iss. 11, 2009.,pp. 128–136. [10] P. Richards Shock waves on the highway. Operations Research 4,1956, 42–51.
VI. REFERENCES [1] Janis Jansons, Ernests Petersons, NikolajsBogdanovs, “WiFi for Vehicular Communication Systems”, 2013 27th International Conference on Advanced Information Networking and Applications Workshops.
[11] M. Lighthill and G. Whitham “On kinematic waves: II. A theory oftraffic on long crowded roads.” Proc. Roy. Soc. of London A 229,1955, pp 317–345. [12] B. Kerner and P. Konhauser, “Structure and parameters of clusters intraffic flow”, Physical Review E 50, 1994, pp 54–83.
[2] "Part 11: Wireless LAN Medium Access Control (MAC) and PhysicalLayer (PHY) Specifications Amendment 6: Wireless Access inVehicular Environments", http://ieeexplore.ieee.org/servlet/opac?punumber=55 14473, IEEE,15.July, 2010.
ISBN NO : 378 - 26 - 13840 - 9
INTERNATIONAL ASSOCIATION OF ENGINEERING & TECHNOLOGY FOR SKILL DEVELOPMENT 127
Proceedings of International Conference on Developments in Engineering Research
ISBN NO : 378 - 26 - 13840 - 9
www.iaetsd.in 7
INTERNATIONAL ASSOCIATION OF ENGINEERING & TECHNOLOGY FOR SKILL DEVELOPMENT 128