We also investigate the pros and cons of different cellular technologies (GSM, 3G, ... wireless technologies for vehicle-to-infrastructure communi- cation (DVB-H ...
1
Electric Vehicles Communicating with WebSockets - Measurements and Estimations Javier P´erez and Jukka K.Nurminen, Member, IEEE
Abstract—In this work we study alternative ways to handle the communication between electric vehicles (EVs) and different services. Our main interest is on use cases where the servers need to know the status of the EVs for e.g. intelligent management of the EV fleet. We assume that communication would take place with the regular cellular technologies and would use WebSocket technology, often related to HTML5. We implement an Android application, which emulates EV status, and a node.js server to collect EV status data. We use these to measure how accurate and frequent data the services needing EV status information would be able to receive, how different sampling and encoding techniques influence the amount of data, and how much load different vehicle densities would create to the communication infrastructure. We compare secure communication with WebSockets with regular TCP and with HTTP. We also investigate the pros and cons of different cellular technologies (GSM, 3G, LTE) from communication volume, latency, and energy spending point of view, and propose a set of suggestions to consider when deciding how to implement EV to infrastructure communication. Index Terms—electric vehicle, communication, cellular, mobile, HTML5, WebSocket
I. I NTRODUCTION S the number of electric vehicles (EVs) is increasing new services are likely to emerge. Such services include guidance to charging points, scheduling of charging activities, renewable energy integration, and management of EV fleets. Many of the services will rely on some central component that is able to handle the decision making or suggestion generation by using data collected from EVs [1]. To consider the feasibility of such services from the required communication point of view, we need to understand how the data is transferred and how much load typical use cases would generate. This work is based on the assumption that regular cellular protocols (GSM, 3G, LTE) for the vehicle to infrastructure communication will be used. The present cellular protocols have primarily been designed for interactive use such as browsing. Therefore they are not optimal for machineto-machine communication but they are widely available, well understood, and, therefore, easy to adopt. The upcoming HTML5 standard is often expected to have an important role in future mobile applications. A main benefit is its platform independence. Instead of requiring different applications for different versions, and mechanisms to install and update the applications, a single web application could, at least in theory, be enough. Moreover, the widely available skills of web development could be leveraged. Therefore we wanted to explore in this study how applicable HTML5 would
A
J. P´erez and J.K. Nurminen are with the Department of Computer Science and Engineering, School of Science, Aalto University, Finland
be for the EV communication needs. In particular we study the WebSocket technology, which enables two way communication between web browser (client when using HTML5) and server. We also aim to understand how much new communication load the new EV services would create. Naturally it is difficult to estimate how the services will be like when a significant number of EVs start to be on the roads. However, from the service development perspective it is good to understand what kind of limitations the communication capacity will create for the amount and accuracy of the EV status data that the services can receive. In this work we assume that the EVs are following ISO/IEC 15118 standard [2], which defines vehicle to grid communication interface. We develop an Android application that emulates the vehicle to infrastructure communication and use it to study the influence of different technology alternatives to the communication volume, speed, and energy-efficiency. The key contributions of this work are: 1) We investigate the feasibility of using WebSockets for EV communication over cellular networks with our Android implementation that emulates the vehicle behavior. 2) We measure with our prototype implementation how much communication different protocols create. We also compare how different ways to compress and reduce the data influence the amount of data when sending EV status data as specified in standard ISO/IEC 15118 [2]. We also study the overhead of web technologies in comparison to regular TCP communication. 3) We analyze the feasibility of different cellular technologies for EV communication by measuring their traffic, delay, and energy consumption behavior and propose a set of suggestion for the developer to consider when choosing how to implement vehicle to infrastructure communication. 4) We estimate the load to the cellular infrastructure that arises in different geographical areas with different traffic densities. We do this by combining our single vehicle measurements with typical traffic densities as provided by Finnish Transport Agency. II. R ELATED W ORKS Belanovi´c et al. [3] are looking at the feasibility of different wireless technologies for vehicle-to-infrastructure communication (DVB-H, 3G, WAVE) from the coverage and capacity point of view. Their focus is on safety-critical services where data, such as traffic alerts, is mainly flowing downlink while our main interest is uplink traffic. Interestingly they observe
2
that the capacity of 3G network without additional optimizations is not adequate to support such intelligent traffic services. G¨ung¨or et al. [4] are more optimistic observing that cellular networks have enough bandwidth for smart grid applications. They compare cellular technologies (GSM, GPRS, 3G) as well as other wireless technologies (WiMAX, PLC, ZigBee). Their analysis is qualitative observing the strengths of cellular communications to be their availability, coverage, low cost, and good security while the network operation in abnormal situations can be a bottleneck. Our quantitative measurements complement their findings. Deshpande et al. [5] have compared via measurements 3G and WiFi for vehicular applications especially from the throughput perspective. Obviously, WiFi coverage has a lot more gaps than cellular coverage but when available is superior in speed. Abid et al. [6] have investigated the use of LTE for vehicle-to-infrastructure communication but their work is only based on simulations. K¨abisch et al. [7] look at the mobile communication with web technologies between smart grid and vehicles. They have developed an Android phone prototype application but they are not reporting any performance metrics in their paper. Chen et al. [8] are looking at architectural solutions for network management systems on Android phones. Their focus is on applications size and startup times rather than on the communication measurements. III. M ODEL We assume that a set of EV services S are available with different data transfer needs. We assume that service Si needs to receive the amount di of data with frequency fi . We assume that we have a set of alternative ways Fj (d, f ) to reduce and compress the data. Furthermore,Pwe assume that the share of service i users is σi . Note that σi can be less than one as some vehicles may not be using any services. If a vehicle is using multiple services with different d, and f values we treat the combined service as a separate one. Finally, we assume that in a geographical area A we have traffic density δA . Then total communication need T (A) in area A is given by X T (A) = Fj (di , fi ) ∗ σi ∗ δA ∗ A (1) i∈S
IV. E XPERIMENT A number of alternatives technology selections are available that influence the data traffic volumes and other performance attributes. In this work we study the following: • Different cellular technologies (GSM, 3G, LTE) • Different ways to communicate with the server (WebSockets, regular TCP sockets, and normal HTTP). In all our experiments we used the secure versions of the protocols (TLS v1.0). • Software compression methods (EXI and delta compression) We can also use different sampling techniques [9] and vary the sampling frequency or criteria. The techniques we employ are:
Update sampling, that transmits data every time the GPS updates its status. This seems to results into roughly one update every second. • Periodic sampling, which send data periodically with a period T in seconds. • Space sampling, which transmits only when the vehicle has moved a distance D in meters. • Bundle sampling, technique that gathers B samples and send them together in a bundle. We have created a mobile application, which generates and sends emulated data of EV status to the data center. The application is a native Android app but it can use web technologies (WebSockets or HTTP) for communication. Therefore the results of our WebSockets measurements should remain the same if, in the future, the application would be running in an HTML5 enabled web browser. Currently, the mobile browser support of the new HTML5 web technologies is not yet fully available. The data sent is based on the format specified in the standard ISO/IEC 15118. This standard defines an XML interface that can be used for vehicle-to-grid communication. The messages transfer a timestamp, the location of the vehicle (longitude, latitude and altitude), the accuracy of the location and the speed and battery state of charge (SoC) of the vehicle. In our experiment the size of the XML messages is around 898 bytes and when sending with the compressed EXI format the size is reduced to approximately 690 bytes. The test application is implemented with Android 4.0. and we have used Samsung Galaxy S III for our experiments. The server side is implemented with node.js, which has built-in support for Socket.IO (a library that implements the WebSocket API). This allows us to measure how the system works on live networks. We used the Wireshark packet analyzer tool to extract statistical data from the collected communication logs. For power measurements we used the Monsoon power monitor which provided power to the smartphone and recorded the amount of power spent at each time point. The trials consisted in 5 minutes tests of each configuration. We performed the measurements on bus trips in the Helsinki region. Using typical vehicle movement patterns in the measurements is especially relevant for the space sampling techniques. •
V. R ESULTS The overall observation of experimenting with our test application is that HTML5 along with WebSockets can be used for the kind of status data updates that EVs may want to do. (In fact, many of the results would apply to other mobile status gathering applications beyond the EV case). In our test traces we never noticed any major gaps in the readings that the server received. Also changes in the underlying communication technology did not influence the user experience. However, the different communication alternatives clearly showed different performance tradeoffs. A. Effect of sampling strategy and cellular technology Table I shows the results obtained for the network load measurements of the three cellular technologies: GSM, 3G and
3
LTE; all the measurements employed WebSockets and EXI compression. In the table we use the color coding where the light blue lines correspond to changes in sampling interval, violet lines correspond to changes in bundling the samples, and red lines correspond to changes in sampling distance. The numbers in the first column show what parameters we used for data reduction (T = 0 or D = 0 indicate that no periodic or space sampling were used, B = 1 means that no bundle sampling was used, since the bundle only contains one sample). For the last column we also calculated how much data a vehicle would generate in 24h (3G with EXI). In this calculation we were estimating that each EV would continuously be sending with the same policy while in reality the parked vehicles are likely to have a different behavior. The numbers in the table are therefore clearly upper limits to the amount of data. TABLE I B ITRATES AND LOAD PER CAR AND DAY DEPENDING ON THE STANDARD USED AND THE COMPRESSION METHOD .
The results clearly show how important the sampling strategy is for the amount of sent data. Therefore an application should carefully consider how up-to-date status is needed. Reducing the sampling interval from instantaneous to 5 s reduces the traffic by 75% and the move from 5 s sampling to 10 s sampling by 40%. Collecting multiple sample and sending them in one bundle has also a big effect although the benefit per sample gets smaller when the bundle size increases (35% saving when two samples are bundled but only 60% saving when eight samples are collected in a bundle). The reason for the savings is that with bundling we can reduce the amount of header data and other overhead related to a communication event. However, bundling introduces additional delay so this approach is only feasible where accurate history is necessary and the server tolerates a delay in receiving the data. If the location is the most important attribute for the operation of the service space sampling can be an optimal alternative. This would radically reduce the traffic from parked and other non-moving vehicles. Reducing the accuracy of needed location has an important influence of the traffic volume. Sending samples only after 200 m movement reduces the traffic 85% in comparison to the case when data is sent whenever the vehicle has moved 10 m. The difference between GSM and 3G data volume is small. Interestingly, the traffic volume generated for LTE was 10%20% less than in 3G. We were able to find two reasons for the difference. First, with the LTE connection hardly any TCP level retransmissions were needed while some retransmissions
were common in GSM and 3G. Second, for the LTE measurements we used a different phone instance (same Samsung Galaxy S III model and operating system version but with LTE support). For some reason that phone sent fewer GPS readings than the phone we used in all other measurements. Future research could investigate if these are just random variations. The daily load per vehicle data in last column allows us to estimate the monthly data use. Comparing that with the available cellular subscriptions it turns out that, even if these data volumes may seem high, a basic subscription, which today is below 10 e per month, would be enough to satisfy the communication needs. Different cellular technologies also vary in their latency. While many applications can tolerate long delays, a short delay can be crucial for those applications that need fast real time response. The round trip delays we measured for the different communication alternatives are: 708 ms for GSM, 175 ms for 3G, and 22 ms for LTE. For comparison the roundtrip time for WiFi is 4 ms. Although WiFi provides a better performance, its splintered coverage may not be optimal for EV communication. The round trip delays of newer cellular technologies, 3G and LTE, are getting shorter by each generation. 3G round trip delay is only 25% of GMS, and LTE is only 13% of 3G. Therefore the new cellular technologies are particularly suitable for cases where a short delay is important although in other dimensions, e.g. in energy spending (see section V-E), the old GSM technology is working better. There is thus no single winner in the comparison but the application needs dictate what is the best approach to take. B. Benefits of data compression
Fig. 1.
Software compression performance
In addition to changing the sampling and sending strategy we can also apply different compression techniques to reduce the amount of data sent. Figure 1 compares the regular case of sending the data as XML to the use of EXI and to the use of delta compression, where successive updates only send the data that has been changed. All the cases used 3G and WebSockets. EXI compression reduces the amount of data by around 25% and delta compression reduces it further by around 5%. As a conclusion the use of EXI is definitely useful while the delta compression gives only minimal additional savings.
4
C. Aggreagate load to cellular network While the above numbers measure the needed bitrate for a single vehicle we also wanted to understand how big cumulative load the vehicles would create to the network infrastructure. For that reason we used the data provided by the Finnish Transport Agency, which tells the traffic load on different roads in the country. Table II, shows the bitrates that are needed to satisfy the communication needs of the busiest roads in different parts of Finland. For the calculation we assume that the speed of the vehicles is 40 km/h. The number of vehicles per kilometer of a road thus varies between 46 (Kouvola) and 334 (Helsinki). The calculation assumes the use of 3G, WebSockets and EXI compression. The second column is calculated with the most active sampling strategy (0, 0, 1) while the last column estimates the case when two reading are combined in one bundle and samples are taken only when the vehicle has moved 10 m (0, 10, 2). Since the data only covers the roads, the cars on smaller streets on the same area are ignored. However it is also very difficult to know how this translates to base station coverage area. Also note that the table has been calculated with the assumption that all vehicles would communicate using the same approach. This may not be true because it takes a long time before all vehicles will adopt technologies requiring such communication and, possibly, different drivers will be using different services with different need for status communication. TABLE II T RAFFIC AND BITRATES NEEDED DEPENDING ON THE REGION AND ROAD
Fig. 2.
Network load of different transport protocols
However, WebSocket is still surprisingly inefficient in comparison to regular TCP. TCP requires 40%-50% less bitrate than WebSocket. The big difference is unfortunate for web technology because implementing data gathering applications with the HTML5 technologies would in many ways be attractive. Unless a more efficient way to handle WebSocket communication can be found the major difference in the amount of data will be a big handicap. For applications needing frequent status update communication the old TCP technology seems superior. The web technologies could be attractive for those applications where the communication need is rather infrequent. However, if the communication interval between status updates is long (several minutes) then the WebSocket needs keep-alive traffic to keep it open. The keep-alive traffic would then easily spend much more communication resources than the actual data.
SEGMENT
E. Energy consumption of communication
For insight of the magnitude of the needed bitrates, we compared the values with the well-known YouTube video service. The bitrate needed by the busiest road kilometer in the whole country would correspond to only 4 people simultaneously watching low resolution videos (H.264 480x360) with their mobile devices. So the amount of data is not excessive but the bigger problem could be maintaining data connections to hundreds of users on the road.
Mobile phone applications are very sensitive to energy consumption. However, in a vehicle application the energy spending is less of a problem as the car has plenty of energy available. The driver could connect the phone to the power outlet of the vehicle, or, in the future, position it on a wireless charging pad but these actions still require extra effort from the driver. Therefore, for those cases where communication is happening via a phone in drivers pocket or purse the energy spending of the communication is important.
D. Comparison of alternative transport protocols While our prime interest has been the new WebSocket combined with HTML5, we wanted to understand how it compares with other alternatives. As shown in Figure 2 we compared WebSockets with regular HTTP communication and with regular TCP communication. We tested all the transport protocols over 3G and using EXI. In the web protocol comparison WebSocket is clearly superior giving 60%-70% savings in needed bitrates. This is easy to understand because WebSocket protocol has very little overhead while HTTP transfers big amount of header information with each status update.
Fig. 3.
Average power consumption (mW )
Figure 3 shows the average power spent in different sampling intervals with different technologies. We can see that the old GSM technology is clearly more power efficient than 3G, which again is more power-efficient than the just emerging
5
LTE. For LTE we measured two operator networks. According to our observation the power efficient cDRX technology is in use in the Sonera network while it is not yet available in the Elisa network. Anyhow both of the LTE networks were still clearly lagging in energy efficiency in comparison to 3G. The comparison between WebSocket and TCP readings shows that TCP spends less energy. This is an obvious result from the smaller amount of data that the TCP solution needs to send. However, while the difference is around 20%-30% in GSM, in 3G the difference is only around 5%. The difference arises from the well know property that 3G spends a lot of energy in the idle state after sending the last bit of information [10]. The GSM battery consumption thus better matches the changing load. The likely reason for the worse behavior of newer cellular generations is that cellular standardization has focused on providing faster connections to the users, which naturally is very desirable in interactive applications like web browsing. Ongoing cellular standardization efforts on machine type communication are likely to change the situation [11]. VI. C ONCLUSIONS This study shows that cellular communication and new WebSocket technologies over HTML5 are feasible technologies for sending status updates from vehicles to infrastructure. The accuracy and timeliness of the status information will vary between different EV services but even in the most active case that almost continuously send the updates each EV will need less than 1 KB/s communication capacity. This can be further reduced by different sampling and compression techniques. Assuming all vehicles on the busiest road kilometer in Finland would be communicating in this fashion corresponds to only 4 people watching YouTube videos on their mobiles simultaneously. This is a significant but not overwhelming load to the cellular infrastructure but reaching this kind of future state will take a long time. The measurements we did in this study showed different tradeoffs between the available technology options. Based on our experiment we suggest the following observations for an application developer whose is considering which of the technologies to target: • To reduce the amount of sent data, smart sampling strategy and EXI compression are effective ways while sending only changes from previous reading creates only small savings • If the application requires a short latency then the newer cellular technologies 3G and LTE are vast improvements over GSM • If energy-efficiency of the data collector application is important then GSM technology is a better choice than the newer cellular generations • Traditional TCP sockets require much less data sending than WebSockets. However, their use requires native application development. The potential benefits of web technologies would then be missed. Beyond these technical dimensions there is naturally a set of other influencing factors such as the cost and penetration
of different technologies, the coverage and pricing of different ways of communicating, the availability of skilled developers, and the estimated effort to offer the solutions on different platforms. ACKNOWLEDGMENT This research was partly funded by Aalto University ESCI energy initiative. We would like to thank Finnish Transport Agency for their collaboration and data provided. R EFERENCES [1] H. V. Poor, E. Hossain, and Z. Han, Eds., Smart Grid Communications. Cambridge University Press, 2012. [2] R. Schmidt, A. Caldevilla, A. Kov´acs, Z. Jak´o, V. Kaffes, J. Lord, A. Ankou, D. Maples, D. K´udela, S. Spizzi, and M. Reina-Ortega, Eds., V2G Interface specifications between the electric vehicle, the local smart meter and ITS service providers. PowerUp, 2012. [3] P. Belanovi´c, D. Valerio, A. Paier, T. Zemen, F. Ricciato, and C. Mecklenbrauker, “On wireless links for vehicle-to-infrastructure communications,” Vehicular Technology, IEEE Transactions on, vol. 59, no. 1, pp. 269 –282, jan. 2010. [4] V. Gungor, D. Sahin, T. Kocak, S. Ergut, C. Buccella, C. Cecati, and G. Hancke, “Smart grid technologies: Communication technologies and standards,” Industrial Informatics, IEEE Transactions on, vol. 7, no. 4, pp. 529–539, 2011. [5] P. Deshpande, X. Hou, and S. R. Das, “Performance comparison of 3g and metro-scale wifi for vehicular network access,” in Proceedings of the 10th ACM SIGCOMM conference on Internet measurement, ser. IMC ’10. New York, NY, USA: ACM, 2010, pp. 301–307. [Online]. Available: http://doi.acm.org/10.1145/1879141.1879180 [6] H. Abid, T.-C. Chung, S. Lee, and S. Qaisar, “Performance analysis of lte smartphones-based vehicle-to-infrastrcuture communication,” in Ubiquitous Intelligence Computing and 9th International Conference on Autonomic Trusted Computing (UIC/ATC), 2012 9th International Conference on, 2012, pp. 72–78. [7] S. K¨abisch, A. Schmitt, M. Winter, and J. Heuer, “Interconnections and communications of electric vehicles and smart grids,” in Smart Grid Communications (SmartGridComm), 2010 First IEEE International Conference on, 2010, pp. 161–166. [8] M.-C. Chen, J.-L. Chen, and T.-W. Chang, “Android/osgi-based vehicular network management system,” Computer Communications, vol. 34, no. 2, pp. 169 – 183, 2011, ¡ce:title¿Special Issue: Open network service technologies and applications¡/ce:title¿. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S0140366410001647 [9] L. Carafoli, F. Mandreoli, R. Martoglia, and W. Penzo, “Evaluation of data reduction techniques for vehicle to infrastructure communication saving purposes,” in Proceedings of the 16th International Database Engineering & Applications Sysmposium, ser. IDEAS ’12. New York, NY, USA: ACM, 2012, pp. 61–70. [Online]. Available: http://doi.acm.org/10.1145/2351476.2351484 [10] N. Balasubramanian, A. Balasubramanian, and A. Venkataramani, “Energy consumption in mobile phones: a measurement study and implications for network applications,” in Proceedings of the 9th ACM SIGCOMM conference on Internet measurement conference. ACM, 2009, pp. 280–293. [11] P. Jain, P. Hedman, and H. Zisimopoulos, “Machine type communications in 3gpp systems,” Communications Magazine, IEEE, vol. 50, no. 11, pp. 28–35, 2012.