IEEE TRANSACTIONS ON MOBILE COMPUTING,
VOL. 13,
NO. 11,
NOVEMBER 2014
2431
A Feasibility Study and Development Framework Design for Realizing Smartphone-Based Vehicular Networking Systems Yongtae Park, Jihun Ha, Seungho Kuk, Hyogon Kim, Chieh-Jan Mike Liang, and JeongGil Ko Abstract—Designing and distributing effective vehicular safety applications can help significantly reduce the number of car accidents and assure the safety of many precious lives. However, despite the efforts from standardization bodies and industrial manufacturers, many studies suggest that it will take more than a decade for full deployment. We start this work with the hypothesis that smartphones may be suitable platforms for catalyzing the distribution of vehicular safety systems. Specifically, smartphones connected to their respective cellular networks can report sensing data to back-end application servers and exchange safety-related messages. This paper first evaluates the performance of the vehicular ad-hoc networking standards and the hardware platforms that implement them. Next, we perform empirical evaluations on the performance of cellular networks to confirm their applicability in vehicular networking. Based on our observations, we present the VoCell application development framework. VoCell, comprehends a set of components that eases the development of smartphone applications for vehicular networking applications. Using VoCell, developers can easily access internal and external sensing components and share this data to servers. We present a number of example applications developed using VoCell and evaluate their effectiveness in local and highway environments using a pilot deployment. We envision that VoCell can act as a building block for enabling new smartphone-based systems for vehicular networking applications. Index Terms—Vehicular networking systems, cellular applications, smartphone-based VANET, application development framework
Ç 1
INTRODUCTION
S
the introduction of the first steam-engined automobile in the late 18th century, the number of automobiles in the world has surpassed 1 billion in 2011. Naturally, the number of car accidents that threaten the safety of precious lives has increased as well; thus, preserving vehicular safety becomes an increasingly important issue. As a solution, combining local vehicle status data, such as the traveling speed and location, along with traffic conditions (e.g., accidents or unexpected speed changes), can help drivers avoid many tragic incidents. However, this solution addresses only one part of the safety issues, or simply local faults caused by the driver. The problem is that cars today still do not have a reliable way to communicate with surrounding vehicles, despite the advancement in mobile communication technologies. To address this controversy, the IEEE has been working on a standard suite including a physical (PHY) and medium access control (MAC) layer specification as well as higher layer protocols [10], [11], [12] that are suitable for vehicular communication systems. This technology, when combined with vehicular movement detecting sensors and effective industrial standards, can be used to implement
INCE
Y. Park, J. Ha, S. Kuk, and H. Kim are with the Korea University, Seoul, South Korea. E-mail: {ytpark, jhha85, tmdgh9, Hyogon}@korea.ac.kr. C.-J.M. Liang is with the Microsoft Research, Beijing, China. E-mail:
[email protected]. J. Ko is with the ETRI, Daejeon, South Korea. E-mail:
[email protected].
Manuscript received 5 Sept. 2013; revised 21 Jan. 2014; accepted 18 Feb. 2014. Date of publication 4 Mar. 2014; date of current version 26 Sept. 2014. For information on obtaining reprints of this article, please send e-mail to:
[email protected], and reference the Digital Object Identifier below. Digital Object Identifier no. 10.1109/TMC.2014.2309959
intra-vehicle embedded systems that allow inter-vehicle data exchange. The realization of these standards are currently under development in the form of On-Board Units (OBUs) for vehicular applications [6], [27]. Unfortunately, waiting for such technologies to mature and spread in large scale is not something that can happen quickly in the near future [17]. Nevertheless, given the importance and attractiveness of safety-related vehicular networking applications (e.g., real-time vehicle status sharing and alert, road condition reporting, etc.), it is meaningful to explore the capabilities of existing technologies to provide and distribute these services to drivers at scale now as we wait for standards and OBUs to integrate into our vehicles. To this end, we envision that smartphones can act as the platform to quickly realize such applications, especially with their already large user base and several commercialized applications (e.g., WAZE and Google Maps services). This work introduces the VoCell application development framework which catalyzes the development of various vehicular networking applications in smartphone platforms. We see this as an important step forward, even for the fast deployment of vehicular networking applications using standard-based OBUs. In fact, a recent meeting report by the U.S. Department of Transportation (DOT) shows that the standardsbased OBUs face the issue of lacking “day 1 benefits” [26]. In other words, to experience effective vehicular networking applications, a wide distribution of OBUs is essential. However, as OBUs slowly integrate to driving environments, their initial effectiveness can be minimal; thus, restrain their distribution even more. By using already widely distributed smartphones and the VoCell development framework as a tool to showcase and experience the
1536-1233 ß 2014 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
2432
IEEE TRANSACTIONS ON MOBILE COMPUTING,
effectiveness of vehicular (safety) applications, later, when OBUs are available in the market, we envision that the urge to actively employ these systems will increase. Key goals of VoCell are to allow developers to easily access a wide variety of sensors and extract vehicular movement information while exposing APIs to simplify cloud/ web-based services development. As we motivate, present and exemplify the design of VoCell, we make the following contributions:
We summarize the proposed standards for vehicular communications and their target applications. Furthermore, we empirically evaluate state-of-the-art standards-compliant OBUs that will enable vehicular networks on future vehicles. We empirically evaluate the feasibility and performance of cellular network-connected smartphones in catalyzing the realization and distribution of vehicular networking applications. We introduce the VoCell application development framework which provides developers with (1) easy access to sensory information relating to the vehicular states, and (2) a comprehensive set of APIs to support vehicular applications on cellular networks. Using VoCell, we implement a set of vehicular networking applications and identify some lessons and directions for future research in designing smartphone-based vehicular networking systems. Next, Section 2 introduces standards and applications in the vehicular networking domain, and evaluate the OBUs that implement these standards. Section 3 shows empirical evaluations on cellular networks to verify their feasibility as a building block for vehicular networking applications. Section 4 presents the VoCell application development framework, and Section 5 presents several applications developed with VoCell and the lessons learned from our deployments. Finally, we present related work in Section 6 and conclude in Section 7.
2 2.1
OVERVIEW AND EMPIRICAL EVALUATION OF VEHICULAR NETWORKING STANDARDS
Vehicular Networking Standards and Applications Over the past decade we have witnessed the emergence of numerous embedded computing platforms that integrate processing, storage, wireless networking, and sensing modules to improve existing applications and create new applications in various domains. Such technologies, when applied to vehicles, can enable a new set of applications that assist in providing information for realizing safe and efficient driving conditions. A wireless environment that exploits such standards is typically called wireless access in vehicular environments (WAVE). For the wide spreading of such technologies, standardization at multiple layers is essential. To fulfill this need, standardization for vehicular communications started with the allocation of the 5.855.925 GHz frequency range (i.e., seven channels) by the FCC for dedicated short-range communications (DSRC) in 1999. This frequency range includes dedicated channels for vehicular networking control traffic, some channels dedicated
VOL. 13,
NO. 11,
NOVEMBER 2014
towards public safety messages and some channels that can be used for vehicular entertainment. Following the frequency allocation, a multitude of standardization bodies have proposed protocols and message formats for vehicular applications. The IEEE took an early step forward and proposed 802.11p as amendments to standardize PHY and MAC layer parameters for adopting the IEEE 802.11 standards to vehicles [12]. Above 802.11p, IEEE 1609 defines the necessary modifications and additions for supporting vehicular applications, which include, multichannel access for 802.11 (e.g., IEEE 1609.4 [9]), message formats in the form of the WAVE short message protocol (WSMP) or UDP over IP (e.g., IEEE 1609.3 [10]), and security issues (e.g., IEEE 1609.2 [11]). These protocols assure that safety-related messages are transmitted with highest priority on the WAVE channels. In addition to IEEE, the Society of Automotive Engineers (SAE) International, an industrial standards organization for auto parts, has proposed the SAE J2735 [20] standards to define the over-the-air (OTA) message set specifications for vehicle to vehicle (V2V) and vehicle to infrastructure (V2I) communications. The primary application-level goals of these systems are to reduce the chances of accidents and provide real-time traffic reports to ease road congestion. To do so, these applications aim to improve the visibility of the road and surrounding conditions, especially for the unskilled drivers. Furthermore, the same communication infrastructure can enable “info-tainment” services. The following paragraphs discuss the characteristics of some applications that WAVE can be applied to. First, the Emergency Braking Detection and Reporting Application, or the electronic emergency brake light (EEBL) application, detects and distributes information on a vehicle’s braking activities and transmits warnings to approaching vehicles. The key challenge of this application is to distribute emergency braking information with minimal latency to all vehicles within affected range, especially to those with poor or blocked visibility. When vehicles receive such information, drivers can be alerted, and vehicles can be manually or automatically slowed down to avoid collisions. Second, applications for Overtaking/Lane Change Assistance and Warning target to quickly distribute the intent of a driver to switch lanes or overtake a slower vehicle to its surrounding vehicles. The drivers that initiate a “movement intent” can also be provided with information on the right timing. For example, in the case of overtaking a slower vehicle, the Overtaking Assistance application can notify all vehicles involved of the intravehicle distances [21]. The key challenge is in the accurate estimate the intra-vehicle distances by fusing all sensory information on the smartphones. Third, using high precision location information and low latency wireless communications, drivers can be alerted of fast approaching vehicles for Intersection Collision Prediction and Warning. In urban environments where line-of-sight (LOS) is not guaranteed for intersecting vehicles (e.g., due to environmental factors such as high-rise buildings), such applications gain high importance. By utilizing infrastructures such as road side units (RSUs), or by using direct communication (e.g., V2V), vehicles can be alerted if another
PARK ET AL.: A FEASIBILITY STUDY AND DEVELOPMENT FRAMEWORK DESIGN FOR REALIZING SMARTPHONE-BASED VEHICULAR...
Fig. 1. Picture of an on-board unit manufactured by Cohda Wireless [27]. The OBU includes components such as a WAVE communication module, ARM11 processor, and GPS sensor.
vehicle is dangerously approaching the intersection so that potential accidents can be prevented.
Realizing Vehicular Networking Applications with On-Board Units As an effort to realize the aforementioned vehicular networking applications, commercial vendors have started manufacturing on-board units which are platforms that integrate WAVE standards-compliant communication modules with data processing components. These OBUs are projected to be located inside a vehicle to enable V2V and V2I communications. In this section, we present an overview on the capability of OBUs along with some preliminary experimental results on their communication performance.
2433
Fig. 2. NS-3 simulation results on the expected packet reception ratio of the OBU’s communication module with increasing vehicle density for different communication distances.
1609 implementations and the file system) can be easily accessed using these APIs and applications are developed using C-based code.
2.2
2.2.1 Unveiling the OBUs An OBU, typically equipped with a radio module for IEEE 802.11p-based communications with additional interfaces that allow connections to a vehicle’s internally integrated sensing units, is projected to be implanted into the vehicles of the future. As they gain increasing interest and significance, it is important to take a closer look at these platforms to forecast their usability in real vehicular networking applications. Fig. 1 presents a picture of an industrial grade OBU that we use for evaluations in this work. Specifically, developed by Cohda Wireless, the MK2 WAVE-DSRC Radio is an FPGA-based board that includes a dual channel IEEE 802.11p radio module [12] to support the IEEE 1609 networking stack [9], [10], [11] including its security features. This platform was one of the three platforms used in the U.S. Department of Transportation’s Safety Pilot Program (http://www.its.dot.gov/safety_pilot/) in Ann Arbor, MI, from 2011 to 2012; thus, is proven to be standards-compliant and effective for realizing the vehicular networking applications. The processing core of the platform is an ARM11 processor that can operate at up to 533 MHz while utilizing the platform’s 64 MB of DDR memory. For internal sensing, the OBU includes a GPS module and gyroscope to detect changes in the vehicular motion. Additional sensors provided by the vehicles are connected using the CAN bus interfaces. For further external interaction, the OBU also includes interfaces such as Ethernet, USB and serial ports as well. On top of these hardware components, the MK2 WAVEDSRC Radio runs a Linux-based operating system. To simplify the process of application development, a set of APIs is exposed to the application layer. Hardware components (e.g., radio and GPS), exte0rnally accessible interfaces (e.g., CAN and USB), and software components (e.g., the IEEE
2.2.2 Communication Performance While such OBUs are the basis of various vehicular ad-hoc networking (VANET) applications, only little about the empirical performance of these platforms is known to the research community. For this, we now turn our focus to evaluating the communication performance of the WAVErelated standards and an OBU that implements these standards. Specifically, we focus on investigating the performance in terms of packet reception ratio (PRR) with varying vehicle densities/distances and transmission latency with different internal processing loads. We use the NS-3 simulator [1] to simulate the performance of a wireless system with a large number of vehicles. We vary the distance between vehicles on a 5-KM road strip to achieve a density of 20, 30, 40, 80, and 120 vehicles per KM. For simulating a realistic wireless channel, we use the Log Distance Propagation Loss model with the reference value set to 47.2 and the loss exponent set as 2.35. The Nakagami Propagation Loss Model was used as the fading model with m ¼ 2:285 (e.g., identical to a Ricean Fading Model with K ¼ 3) to simulate a highway environment. A 5.8 GHz radio and a data rate of 6 Mbps was used and these aforementioned parameters were borrowed from many previous literature that simulate the performance of vehicular environments [19], [24]. We note that no special routing mechanism is needed since nodes perform single-hop broadcast. We set the transmission power to 20 dBm with an antenna height of 1.5 meters and configure each vehicle to broadcast 250 byte messages at 10 Hz.1 Fig. 2 presents the PRR of WAVE-compliant devices with varying vehicle densities and communication distances. At the density of 120 vehicles per kilometer, the congestion level increases to saturate the wireless channel and quickly brings down the PRR. Furthermore, due to the use of the 5.8 GHz frequency band, we can notice that, even without channel saturation, the packet delivery quality drops rapidly as the distance increases due to path loss. While we agree that simulations only capture part of the real environment characteristics, we utilize simulations in this work to present results that require large-scale testing, which is practically difficult 1. Many VANETs require packet transmissions rates of 10 Hz and a secured Basic Safety Message (BSM) with a certificate requires a packet size 250 bytes [16].
2434
IEEE TRANSACTIONS ON MOBILE COMPUTING,
VOL. 13,
NO. 11,
NOVEMBER 2014
Fig. 3. Empirical results collected from road tests on the PRR with respect to the communications range and varying transmission power.
Fig. 4. Empirically measured communication latencies for inter-OBU communications with different workloads.
to test with real devices at a prototype level. Nevertheless, in Fig. 3 we present the empirically measured per-distance PRR using our OBUs on a road test. Packets in were sent at 10 Hz with varying transmission powers from one vehicle moving at 90 km/h and the following vehicle, also moving at 90 km/h, received the packets while maintaining different relative distances. By comparing these empirical results against Fig. 2, we can notice that the PRR drops even more quickly in reality. Deeper investigations revealed that the lower PRR is a result of poor engineering of the antennas that were positioned inside the vehicles. We note that such findings were recently made in large scale VANET studies as well [25]. This experimental result suggests that OBU deployments still face stages of (engineering) improvement before they can be applied in real life. Next, in Fig. 4 we use two OBUs to perform empirical experiments in a mobile environment and compute the application-level communication latency with different processor workloads. In the first configuration, presented as solid dots in Fig. 4, the processor is left idle except for when transmitting or receiving packets. On the other hand, in the second configuration, we force the processor to continuously perform floating point multiplications to emulate a case where the processor is busy processing data for a background application, while a different application intends to transmit or receive a packet (see “x” plots in Fig. 4). We observe that while both measurements show low communication latency, the processor’s workload gives a visible impact on the OBU’s communication module. In real operations, the processor can easily fall in the busy state since the SAE J2735 standards require VANET applications to encode their messages using methods such as basic encoding rules (BER), canonical encoding rules (CER), or distinguished encoding rules (DER) [20]. As a result, when a single OBU services multiple vehicular networking applications, the en/decoding process for one application’s packets can delay the packet transmissions for other applications. Furthermore, as the work by Min et al. indicates, when the security features, such as IEEE 1609.2 [11], are applied to the packets, packet delivery latencies can increase even higher (e.g., 50 ms) [13]. Finally, we point out that these results are not specific to the OBU that we tested with. Specifically, we were able to observe the same trend due to similar hardware limitations when testing with an OBU manufactured by a different vendor as well (e.g., the Denso Wireless Safety Unit [6] is equipped with a 400 MHz MPC5200B PowerPC processor). Together, these results suggest that with careful engineering OBUs implementing the WAVE-related standards are promising in supporting a reasonable amount of network
capacity and low packet exchange latencies that are less than 25 ms without security implementations. However, our results also suggest that WAVE-based VANETs would face reliability issues as the deployment density grows, and the use of 5.8 GHz radios can limit the communication range due to the affect of signal propagation. Furthermore, our evaluations indicate that the limited processing power of current-day OBUs can impact the communication latency when multiple applications operate simultaneously.
3
FEASIBILITY STUDY OF SMARTPHONE-BASED VEHICULAR NETWORKING SYSTEMS
Section 2.2 discusses that the current generation of OBUs still faces some performance limitations, which can hinder the effectiveness of vehicular applications under certain circumstances. In addition, results from previous studies [17] and the adoption rate of OBUs so far, suggest that it may take more than 10 years before OBUs become a viable platform for vehicular applications. Given the importance and the need for many vehicular networking applications, this section argues that the current smartphone and cellular network technologies can already adequately support the requirements of many critical applications. Using empirical studies, we identify application spaces in vehicular networking where smartphones act as the communication (and sensing) medium.
3.1 Cellular Network-Based Vehicular Networks Forming a network of vehicles using drivers’ smartphones can be done in two distinctive ways. First, like the WAVE standards, smartphones inside the vehicles can directly exchange information with each other by forming a mobile ad-hoc network of smartphones. The benefits of this approach come from the minimal infrastructural dependency. Specifically, direct links among devices reduce the number of forwarding hops, hence the transfer latency. In addition, such a system is arguably independent from external networking factors (e.g., unexpected connectivity issues related to cellular networks). Nevertheless, in order to achieve ad-hoc communication, some smartphone platforms (e.g., Apple iOS and Windows Phone) would need significant changes to allow low-level radio access such as soft Wi-Fi AP, or an additional external (dedicated) communication module. Furthermore, many radios, such as 802.11 IBSS [12] and Bluetooth, are not designed to handle shorter encounter times, which leads to high membership churn rates. On the other hand, the second approach of forming a smartphone-based vehicular network is to utilize the already present wireless infrastructure, such as the 3 G
PARK ET AL.: A FEASIBILITY STUDY AND DEVELOPMENT FRAMEWORK DESIGN FOR REALIZING SMARTPHONE-BASED VEHICULAR...
2435
Fig. 6. Communication latency distribution for a smartphone’s cellular communication module while communicating with a server located in Seoul, Korea.
Fig. 5. A system architecture of a vehicular network implemented using a set of participating smartphones and a server connected to the web.
or 4G/LTE cellular networks. By communicating with the Internet using these communication channels, smartphones that are registered to an application server can easily exchange data with each other. While this approach is dependent on the latency and reliability of existing wireless communication infrastructure, the following sections show that the current cellular networks can serve as a stable communication channel. Fig. 5 depicts the architecture of such a system, and it highlights three major components: smartphone(s), cellular network, and back-end application server(s). From the operational perspective, smartphones can sample their internal sensors (e.g., GPS, accelerometer, gyroscope, etc.) or gather sensory data externally from the vehicle and periodically report this information to an application server. The application server collects the sensing data from various vehicles and can compute contextual data regarding the vehicle’s movement (e.g., speed, heading, and acceleration). To ease the computational overhead at the server, applications can also choose to compute the contextual data in a distributed way, at individual smartphones. The application servers will also serve the role of disseminating data to vehicles in the same region. We now justify the use of a cellular network with measurements of three metrics: packet delivery latency, reliability, and scalability. Below we show that such systems can satisfy tight application latency requirements while providing high system reliability and scalability: Latency. We measured the communication latency for various cellular networks in different countries to verify their feasibility in supporting timing-constrained application classes such as vehicular safety. We periodically sent 250-byte time-stamped UDP packets (e.g., typical message length for Basic Safety Messages in WAVE applications) every 100 ms to an application server in Seoul, Korea. Upon receiving the packet, the server records the packet information and returns a response of the same size. This setup effectively emulates the latency required for a vehicle-initiated emergency message to travel to a server, and distributed as alert messages to surrounding vehicles. At the time of writing, LTE is readily available in 62 countries such as U.S. and Korea, but the deployment is not as pervasive in 21 other countries such as China [14]. To address the concern of system practicality, we also
benchmark the latency of 3G (HSPA+) networks with the same experimental settings in different countries as well (e.g., Beijing, China and Baltimore, MD.). For our experiments, we picked the most popular cellular carriers in these countries: SK Telecom, China Unicom, and Verizon. Given the location of the server and the resulting the geographical distance, the experiment results heavily depend on both the latency of the over-sea Internet backbone and the 3G cellular network. Fig. 6 presents the CDF of the packet delivery and reception (e.g., round trip) latencies computed over 60,000 samples collected for each cellular carrier (e.g., 100 minutes of continuous operation). Specifically, through Fig. 6 we can notice that, when using LTE, more than 80 percent of the packets had a RTT less than 58 ms, and 99.99 percent of the packets experienced RTTs < 80 ms. For 3G, 90 percent of the measurements are below 110, 218, and 350 ms for Korea, China and U.S., respectively. Given that the latency observed from an Ethernet-connected PC in Baltimore is around 231.61 ms, we can estimate the (separated) 3G latency to be 120 ms. In other words, distributing servers in different areas will improve the response time of our system, and we can expect the 3G latency to fall under 150 ms in most cases. We note that similar latencies have been reported in several previous work as well [28]. While these measurements are not close to the 25 ms RTT observed for WAVE, we next discuss them in the context of vehicular applications. First, although the WAVE standards do not mandate vehicle status report frequency for Basic Safety Messages, typical reporting frequencies used in the literature are between 1 [23] and 10 Hz [4]. Our experiment results for LTE networks can meet the 10 Hz target. Second, we point out that the U.S. Department of Transportation recommends a minimum of 3-second traveling distance between two vehicles. Since it typically takes about 2.5 seconds for cars on the highway to completely stop (thinking plus braking distance) [7], the measured RTT of both LTE and 3G can fit the 500-ms gap. Reliability. We now characterize the packet loss of the cellular network based on our LTE benchmarks. Results indicate that 99.72 percent of the 60,000 packets were received on the first attempt, and 99.99 percent of the packets were received within five retries. In addition, Fig. 7 plots a histogram with respect to the number of consecutively missed packets, and it suggests a non-bursty loss. This combination of high PRR with non-bursty loss patterns suggests that crucial data can be delivered over a cellular network with high
2436
IEEE TRANSACTIONS ON MOBILE COMPUTING,
Fig. 7. Number of consecutively missed packets missed when transmitting packets to the application server while the smartphone is mobile with LTE connection.
probability. Based on an additional experiment carried over 24 hours on an operating vehicle (see Fig. 9), we observe that this high reliability has a low correlation with the time of day. Scalability. As we did with the WAVE standards-based system in Section 2.2.2, we performed NS-3 simulations to estimate the maximum capacity of the smartphone-based vehicular networking system (i.e., number of concurrently connected smartphones). In our simulations, we emulated a horizontal 5 KM road with two LTE basestations (e.g., eNodeBs) each located vertically 1 KM away from the end points of the road. Based on a literature survey of LTE performance simulations [2], we configure the eNodeB to have a height of 80 meters and a transmission power of 40 dBm (e.g., suitable for rural and highway environments). Smartphones in the vehicles on the road were configured to transmit 250-byte packets at 10 Hz with a power of 20 dBm. As for the LTE parameters, the up-link channel frequency was configured to use the 829-MHz frequency band with a system bandwidth of 10 MHz and 50 resource blocks. Lastly, we varied the density of the vehicles among 20, 30, 40, 80 and 120 vehicles per kilometer. By observing Fig. 8 we can notice that as the number of vehicles increases, the PRR shows a sharp degradation. This is a major concern with cellular networks and is mostly caused by the inter-cell interference. While LTE assigns transmission time slots for each node, the highly utilized network bandwidth result in adjacent cell interference. Note that with 120 vehicles per kilometer, vehicles are only 8 meters apart. Given the size of a mid-sized vehicle, the distance between the tail of a vehicle and the head of the following vehicle is < 4 meters. Such a case would not represent a fast moving scenario; thus, the transmission rate can be adaptively controlled on a practical perspective. In Fig. 8, as we decrease the transmission rate to 5 and 1 Hz, we notice that the
Fig. 8. Packet reception ratio of the smartphone’s LTE communication for different vehicle densities.
VOL. 13,
NO. 11,
NOVEMBER 2014
Fig. 9. Per hour PRR for LTE packets transmitted at 10 Hz under driving conditions.
cellular network can still scale to a large number of vehicles. Furthermore, previous literature on inter-cell interference cancellation (ICIC) for LTE networks shows that this performance degradation from inter-cell interference can be minimized as well [3]. Lastly, we also note that compared to the short range nature of 802.11p-based networks, LTE networks are not affected by the distance between communicating vehicles. We acknowledge concerns regarding the signaling overhead of initiating LTE connections as the LTE network scales. Nevertheless, given that the continuous data transmissions in many vehicular networking applications will allow LTE connections to be long-live, we conjecture that this overhead will only be introduced during cellular handover from one eNodeB to another.
3.2 Supportable Applications Continuing from the discussion on the architectural perspective, we now turn our focus on identifying types of vehicular applications that can be supported using smartphones. We gather this insight from analyzing the overall system capabilities and limitations: Network stack. Given the fact that WAVE protocols are designed for DSRC systems, OBU-based wireless communications provide short coverage ranges on the 5.8 GHz frequency band. On the other hand, the LTE communication modules operate lower on frequency bands (e.g., 700/ 800/1,700/1,900 MHz in North America, 800/900/1,800/ 2,600 MHz in Europe and Asia). This naturally helps LTEbased systems to achieve wider coverage. In other words, vehicles located farther away can access realted information earlier, despite having low vehicle density, while the direct communication nature of the WAVE standards can limit propagation when the road lacks vehicle density. On the other hand, while WAVE standards-based systems are independent from external communication infrastructure conditions, smartphone-based vehicular networks cannot provide effective service when cellular infrastructures are not present or when the infrastructure fails for any external reasons. Furthermore, due to the direct communication nature of WAVE, the communication latency is lower in most cases compared to the delay introduced by cellular networks. This allows WAVE-based systems to be more suitable for applications that require very low data transmission latency. Nevertheless, the latencies of cellular networks can still meet the requirements for applications that target a 10 Hz reporting frequency (see Fig. 6); thus, their uses are practical in applications that require latencies of less than 100 ms.
PARK ET AL.: A FEASIBILITY STUDY AND DEVELOPMENT FRAMEWORK DESIGN FOR REALIZING SMARTPHONE-BASED VEHICULAR...
Hardware platform. The processing power is one major differentiator for smartphone-based solutions over OBUs. For example, the popular Samsung Galaxy S III smartphone has a quad-core CPU running at 1.4 GHz, as compared to the 533 MHz single-core CPU on current OBUs. Fig. 4 illustrates the impact due to OBUs’ limited processing power, where performing common operations can lower the network performance by a factor of five. On the other hand, multi-tasking support on modern smartphones allows faster response time for safety applications and concurrent applications. While more advanced components are available on the market (separately), based on our discussions with industrial experts, the OBU’s components are selected so that their costs are minimized while achieving the target functions. Security. When observing the security capabilities of the two systems, smartphone-based systems ease the overhead of additional security considerations by leveraging the security features of cellular network. On the other hand, the OBU-based system requires an implementation of a separate application level security mechanism [11]. Not only does this induce processing overheads, but it also increase the packet size. Even in the case of implementing the same IEEE 1609.2 security features, smartphones’ relatively higher processing power can still help lowering the processing latency. Application architecture. Compared to OBU-based VANETs, the smartphone-based vehicular applications require the use of web-based application servers. This additional component in the system architecture grants applications access to global information from vehicles that may be located distantly. This additional information can allow a new set of applications to be designed. Commercially available systems such as WAZE (http://www.waze.com/) and Google Maps services (http://www.google.com/mobile/ maps/) utilize or are capable of utilizing this capability to offer attractive services. In summary, with modern smartphones and cellular networks, smartphone-based vehicular networks can enable applications with sub-second-level response latency constraints (i.e., few hundred msec). However, it might not be suitable for applications that require tighter latency requirements.
4
THE VOCELL APPLICATION DEVELOPMENT FRAMEWORK
Based on the requirements of various vehicular networking applications surveyed and the results from our feasibility studies of realizing vehicular networking applications using smartphones, we list a set of design goals for a software development framework that simplifies smartphone-based vehicular application development. Specifically, a such framework should 1.
2.
provide easy access to internal sensing modules and provide software components that facilitate extraction of vehicular contextual information (e.g., speed, movement direction, etc.). Provide interfaces that inter-connect applications with sensing components by integrating them using light-weight software drivers.
2437
3.
Exchange data between smartphone applications and backend servers over the network interface with the highest traffic-energy ratio. 4. Offer access to real-time information provided by public services (e.g., weather, traffic information). 5. Offer easy integration with various geo-location services (e.g., Google Maps). 6. Provide generic back-end components that serve as building blocks of back-end services for different vehicular networking applications. Apart from analyzing the networking aspects of smartphone-based vehicular networking systems, a major goal of this work is to design and introduce an application development framework that satisfies the requirements presented above. By providing developers with a customized set of software resources targeting vehicular networking, we hope to vitalize future research in this application domain and excite users by showcasing various vehicular networking applications that can improve daily driving routines. In the rest of this section, we dive into components of the VoCell software development framework, and discuss how they address the requirements listed above.
4.1 Smartphone-Side Development Components A development framework for smartphones is expected to be well integrated with the smartphone OS’ SDK. VoCell is implemented as a library for the Android SDK. Our current implementations for VoCell is in Java Android SDK 4.1, but it can support down to version 2.3.4. An application developer simply includes the VoCell class as part of the target project to use its APIs. There are three major components in the main VoCell class: SensorManager, VisualizationManager, and NetworkManager. Specifically, the SensorManager component provides functions to discover and configure internal and external sensing components along with sensing data collected from external databases (e.g., governmentprovided road emergency alerts, weather information, etc.). Furthermore, it performs the operations needed to compute various context data for inferring vehicular movement, such as speed, heading, turn, and braking information. We will discuss the algorithms for computing these vehicular context information in detail using sensing samples collected from road tests in Section 5. Next, using the NetworkManager component, an application can easily establish connections with the server, periodically report its data (e.g., GPS), and retrieve various neighborhood-related data (or other information that require global topology information or server-side processing). While VoCell, by default, transmits packets by prioritizing cellular connections, NetworkManager also allows for WiFi connections (if present) for actions such as efficient bulk data transfers. Finally, given that configuring the GUI layout is one of the most troublesome processes in smartphone application development, we provide a set of simple layouts that can be widely used for vehicular networking scenarios using the VisualizationManager component. Our current implementation provides support for Google and Naver Maps (the latter is only supported in Korea) and provides a simple
2438
IEEE TRANSACTIONS ON MOBILE COMPUTING,
VOL. 13,
NO. 11,
NOVEMBER 2014
Fig. 11. Sample code sequence for a simple road monitoring application using VoCell. Fig. 10. Architecture of the VoCell application development framework for the Android SDK.
layout for the location of the host vehicle and the surrounding vehicles (if any). The map also has a simple summary of the road characteristics. Nevertheless, extending to different types of layouts is possible by modifying the VisualizationManager component. In the development phase, these three main components in VoCell are globally initialized with the init(). While each sub-component in VoCell provides its own set of functionalities, the VoCell class (see Fig. 10) provides an abstraction for these components and an easily accessible API set to the developers. As our simple example in Fig. 11 shows, once components are initialized, the application enables its target sensor module by using the sampleSensor() function. In this example, the GPS sensor is called to report periodic samples with an interval of SAMPLE_INTERVAL. The trackValue() function enables periodic data collection from either the operations of the SensorManager or the NetworkManager. The first parameter of trackValue() is updated by internally computable elements (e.g., SPEED, HEADING, LOCATION, ACCELERATION, etc.). The SensorManager uses its sensor data to compute the context and periodically updates the target variable (e.g., VoCell. SPEED, VoCell.HEADING, and VoCell.LOCATION in the example). For elements that require interactions with the server (e.g., SURROUNDING_VEHICLES, ALERT_STATUS, etc.), the NetworkManager periodically fetches the information from the server for the application’s target purposes. Nevertheless, before any server-smartphone interaction takes place, the application issues a connection request to the server using the connect() function, and periodically reports its values with reportValue(). Once all the internal data collection procedures are configured, VoCell allows the selection of maps by their layout and view type. Fig. 13a illustrates the SIMPLE_MAP layout. This layout uses SPEED, HEADING, LOCATION, and SURROUNDING_VEHICLES as parameters. Since these elements are already configured to be updated every INTERVAL, calling plotMap(REFRESH_INTERVAL) triggers the ViualizationManager to update the layout on the screen with an interval of REFRESH_INTERVAL. Likewise, VoCell allows developers to easily implement vehicular networking applications on the smartphone by effectively exposing the resources and components that are well-used in this application domain. This abstraction naturally reduces the code size and increases the code re-usability for application development.
4.2 Server-Side Development Components While we envision that most application servers will be configured by individual service development entities, for the purpose of building initial prototype systems, setting up a server can be a burdensome process. Furthermore, since many of the functionalities can be passed to backend servers for computation, severs are crucial in enabling smartphone-based vehicular networking systems. To this end, the VoCell development framework also provides a separate development framework for server-side application development. Our development code for the application server assumes a cloud service environment, such as the Amazon Cloud Service, Microsoft Azure, or the Google App Engine. Our application development environment for the server also assumes that a SQL database service is installed in the cloud-based server (e.g., Amazon Relational Database Service). Mostly developed in C, the server code receives inputs from different smartphone applications and performs two major operations below. First, a simple, yet important role of the server is to store the smartphone-initiated data on its database. When a VoCell application establishes a connection and data flows in using the reportValue() function, the server-side code generates a query message to add the collected sensing information to the target database after attaching a local timestamp of the current time (i.e., time of data collection). For application developers, VoCell provides a listening interface so that applications can intercept the data reporting messages in case applications require more operations than the simple default procedure of “listen-and-store-todatabase”. Second, when a smartphone requests for data (e.g., list of surrounding vehicles), the server code fetches information from its database, performs the required processes, and informs the smartphone of the data that was requested. For all contextual elements requested by trackValue to the server, the server-side code keeps a separate listener interface so that the context-computation process happens autonomously with the request. Within this operation, the server-side application developers can pre-specify various parameters related to the contextual output information. We will discuss these parameters and the process of identifying surrounding vehicles in Section 5.1.2.
5
SAMPLE APPLICATION IMPLEMENTATIONS
We have implemented a suite of vehicular safety applications with the VoCell framework (Fig. 12). This section
PARK ET AL.: A FEASIBILITY STUDY AND DEVELOPMENT FRAMEWORK DESIGN FOR REALIZING SMARTPHONE-BASED VEHICULAR...
2439
Fig. 12. Screenshot of our traffic status monitoring application (left) and a picture of the smartphone mounted on a vehicle (right).
discusses these applications and highlights the details of VoCell’s major components.
5.1 Real-Time Traffic Status Monitoring The first VoCell application that we designed is a real-time traffic status monitoring application, which can be the foundation of various vehicular networking applications. As such, the application provides two main services. First, it provides a communication channel for smartphones and back-end servers to exchange data and push real-time alerts. Second, it offers a tool for evaluating the underlying network qualities to the back-end servers. This section describes our current prototype of the application (c.f. Fig. 13), and then presents some of VoCell’s software components that compute vehicle movement states with the sensing measurements. In the bootstrapping phase, the application turns on the GPS by accessing the pass-through component in VoCell. By simply configuring a sampling interval and server reporting interval, and passing parameters that represent the current vehicle states (e.g., quick turn, emergency brake, accidents, etc.) periodic packets can be reported to a preconfigured server. In our implementation, upon receiving these reports, the server returns two types of responses. First is a periodic (but low-priority) summary of the current road traffic conditions, and second is a triggered (but highpriority) alert. Fig. 13a shows our application screenshot as an example of how VoCell helps visualize the server responses with a map overlay. In addition, we note that VoCell exposes APIs to issue audio beeps and visual alerts to notify important messages. Next, we highlight the primitives and algorithms offered by VoCell to vehicular applications: calculating vehicle speed, identifying surrounding vehicles, and detecting abnormal vehicles. 5.1.1 Vehicle Speed Estimation Component VoCell collects GPS samples in the format of < Timestamp, Coordinates > . Given their timestamps, the traveling distance between two points a and b can be computed with a naive equation of dividing the traveled distance with the elapsed time. Unfortunately, this approach does not take the earth curvature into consideration. To address this, VoCell uses the following equation to compute vehicle speed: Vab ¼
dab ; jTimestampa Timestampb j
(1)
Fig. 13. Screenshots of our real-time traffic monitoring application on the Android platform.
where dab is the distance between points a and b, computed using the respective GPS coordinates with the Haversine equation as detailed below: sffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi ! d : (2) haversin ab dab ¼ 2r arcsin r Here, r is the Earth’s radius and the Haversine equation d haversinðuÞ, where u ¼ rab , is solved as below [22]. Note that here, pa ; pb are the latitude and a ; b are the longitude GPS readings for locations a and b, respectively: haversinðuÞ ¼ haversinðpb pa Þ þ cosðpa Þcosðpb Þhaversinðb a Þ 1 cosðuÞ : ¼ sin2 ðu=2Þ ¼ 2
(3)
To evaluate VoCell’s vehicle speed estimation component, we present results from trace-driven simulations with an hour-long empiricall collected trace from driving in the city and on the highway. The ground truth is based on the speed limit of road segments and human reports made every three seconds. The result shows an average error margin of 4 percent on this highway and 7 percent in the city.
5.1.2 Neighborhood Awareness Component An important primitive for many cooperative vehicular applications is keeping track of nearby vehicles. Specifically, given a host vehicle (hv), the surrounding vehicle set (svlhv ) is a subset of the population vl, and it contains the list of vehicles in a predefined region R. This information is crucial in minimizing unnecessary alerts since svlhv vehicles in should be notified of significant vehicle state changes of hv. Algorithm 1 highlights the pseudo-code of VoCell’s search component. Note that, Algorithm 1 takes h as an input, which represents the target heading of the vehicles in svl. A software that uses SurroundingVehicles(), can set h to be SAME HEADING, OPPOSITE HEADING, or ALL HEADING. As these names imply, based on h, Algorithm 1 filters devices by their heading primitive (e.g., vl[i]. heading) to determine vehicles that are traveling in the same direction, opposite direction and all vehicles in range
2440
IEEE TRANSACTIONS ON MOBILE COMPUTING,
VOL. 13,
NO. 11,
NOVEMBER 2014
Fig. 14. Pictures of the highway environment (left) and the GPS trajectory of our drive.
R. While the accuracy of the GPS modules are not sufficient to detect the exact lanes of the vehicles, our experience shows that it is sufficient for detecting differences in heading. Specifically, our empirical evaluations on the GPS accuracy shows that the mean location error is 3.09 meters in an open environment and approximately two times higher in a urban setting. We point out that with the help of the Assisted-GPS feature on recent smartphones, and by using historical location-based current location tracking schemes [8], this accuracy can increase further.
Fig. 15. Accelerometer traces with GPS-based speed readings for the highway environment. Emergency and slow stops are vertically marked in solid brown and dotted pink, respectively.
host vehicle hv to each member in svlhv , and sends an alert to hv if a condition (e.g., based on a pre-configured threshold) is found. On a practical perspective, in our real-time traffic monitoring application, we envision 250 bytes of data being transmitted at 10 Hz. This translates to 18 MB of data (upload) for a two-hour drive. Furthermore, if we assume such usage for 20 days (average working days per month), the upload would be 360 MB per month. In terms of cost, based on the data plans of major cellular service carriers in Korea and the U.S., the data cost is expected to be between 4 to 18 USD per month.
5.2 Emergency Braking Warning Application When vehicles brake at high speeds, it is difficult for the drivers behind to judge whether the rear red braking light signals a sudden emergency braking activity or a typical braking motion to control the vehicle’s speed. An automated system that distinguishes sudden/sharp braking activities with typical braking can significantly reduce the number of accidents caused by bad judgment of less-skilled drivers. We next highlight how VoCell helps this implementation process.
5.1.3 Abnormal Vehicle Detection Component As many accidents are caused by reckless driving of nearby vehicles, VoCell provides a software component to identify vehicles with abnormal behavior. Our algorithm currently treats the vehicle speed difference as the criteria of abnormal vehicular behavior detection. Specifically, the component identifies the set of vehicles (in svlhv ) with a speed difference above a specified threshold, as compared to the host vehicle hv. Our current implementation also allows road segment speed limits to be treated as a virtual vehicular element in svlhv . This enables use cases such as detecting speeding vehicles approaching from the back or unexpectedly slower vehicles in the front. Both usages in an application are illustrated in Figs. 13b and 13c, respectively. On an application designing perspective, the main challenge is to achieve an energy-efficient implementation. Using VoCell, our application offloads the algorithm execution to the back-end servers, and offers an event-based hook to the smartphones. The basic flow is as follows. Upon receiving a periodic report, the server first determines the vehicle speed and svlhv . Then, it compares the speed of the
5.2.1 Preliminaries on Detecting Braking Activities For braking activity detection in a wider set of vehicles, we perform a preliminary test on detecting emergency braking activities with smartphones, using a series of data traces collected while performing emergency brakes on a (empty) highway (c.f., Fig. 14). During the experiment, we sampled the GPS at 1 Hz and sampled the accelerometer at 200 Hz (both on-board the smartphone). We maintained an average speed of 90 km/h during the test and made a total of seven intentional stops (see Fig. 15). Of the seven, two were slow stops where we slowly decreased the speed from 90 to 0 km/h (pink dotted lines in Fig. 15), and five were emergency braking events where the vehicle’s brake was stepped on as fast as possible to make a full stop (brown solid lines in Fig. 15). Fig. 16 shows a closer view of the Vab (blue line) of our vehicle with the accelerometer’s gravitational and advancing axes traces for one of the emergency stops. Given that the solid brown line indicates the time instant when an emergency braking took place, it is difficult to detect sudden stopping activities quickly with Vab alone (e.g., 2.5 sec delay). On the other hand, accelerometer traces react much quicker. This observation suggests that the accelerometer can better detect instantaneous changes in the vehicle’s movement.
PARK ET AL.: A FEASIBILITY STUDY AND DEVELOPMENT FRAMEWORK DESIGN FOR REALIZING SMARTPHONE-BASED VEHICULAR...
Fig. 16. A close up view of an emergency braking pattern in a highway environment.
Furthermore, Fig. 17 presents accelerometer traces for six different vehicular motions collected in a different set of test drive experiments. The observations here confirm that, except for cases with different speeds (e.g., slow and high speed cases), accelerometer data is sufficient to detect and distinguish between various vehicular movement patterns.
Accelerometer-Based Emergency Braking Monitoring Component Implementation While the high-level idea of leveraging accelerometers for braking detection is not new, we empirically evaluate the feasibility of applying this method to a smartphone-based vehicular networking application. The recent work by Mohan et al. presented an algorithm for detecting braking activity with accelerometer readings [15]. Nevertheless, their algorithm focuses on a case of detecting soft braking activities in a slowly moving vehicular setting while we target more sudden and instantaneous vehicular motion. We find the scheme by Mohan et al. difficult to adopt directly to an emergency braking detection application since classifying a slow braking activity as an emergency stop will cause false positive alerts. Therefore, we take another approach and train a model to distinguish between slow and emergency stops. Based on the collected traces, we summarize the differences between the two types of stops in two-fold: during emergency stops, there is a sharp increase in the readings of the advancing axis, and a sudden decrease in gravitational axis. While using a threshold-based scheme for the two axes can be simple, given the potentially different accelerometer patterns with various road conditions, drivers, and vehicles, we present a more robust scheme to effectively detect these stops.
2441
We first put our attention on the advancing axis. Due to the noise in the data, mostly caused by road conditions, we first pass the accelerometer data (originally collected at 200 Hz in our experiments) through a low pass filter that computes the average of n sample batches. The lowpass filter was used to reduce false detections due to typical variations in the accelerometer samples. We point out that using the low-pass filter resulted in a reduction of the advancing axis measurement’s variance by four-fold (e.g., without the filter the samples showed a mean of 1.34 with a variance of 0.52 but with the low-pass filter the mean was 1.34 with 0.12 variance). In our current implementation we target on collecting one averaged sample per 100 ms; thus, n ¼ 20. The result of this filter, axisLPF adv ðtÞ, where t is the current time, is used to compute the 95 percent confidence range CRadv ðtÞ: 2 CRadv ðtÞ ¼ axisLPF adv ðtÞ þ 1:96 s adv ðtÞ:
(4)
5.2.2
With CRadv ðtÞ, we can detect outliers because a sharp braking motion would cause axisLPF adv ðtÞ to increase more quickly than usual. Therefore, if axisLPF adv ðtÞ > CRadv ðt 1Þ, we set CRadv ðtÞ ¼ CRadv ðt 1Þ and monitor axisLPF adv ðt þ 1Þ. ðt þ 1Þ is also larger than CR ðtÞ, our scheme If axisLPF adv adv determines that a sharp breaking took place. When applying this scheme to highway measurements, our scheme successfully detected all five emergency brakes (e.g., solid brown marks in Fig. 15), but also classified the two slow, gradual stops as emergency braking events as emergency brakes as well (e.g., dotted pink in Fig. 15). To minimize such false positives, we utilize the data from the gravitational axis and start by applying the same low pass filter as above to compute axisLPF gravity ðtÞ. We compute the confidence range, CRgravity ðtÞ for the gravitational axis as below: 2 CRgravity ðtÞ ¼ axisLPF gravity ðtÞ 1:96 s gravity ðtÞ:
(5)
If two consecutive axisLPF gravity ðtÞ measurements are < CRgravity ðt 1Þ, and CRadv ðtÞ also detects an emergency brake, the component concludes that an emergency braking occurred. By evaluating this scheme using the traces collected in Fig. 15, we were able to notice that this scheme
Fig. 17. Accelerometer traces for idle, low/high speed, speed bump, slow/sudden stop vehicular movements.
2442
IEEE TRANSACTIONS ON MOBILE COMPUTING,
effectively removes the false positive detection of the two slow stops. Specifically, using an empirical experiment of making 40 sudden stops and 40 slow stops on highway and urban environments, we were able to properly classify 100 percent of the sudden stops properly and 95 percent of the slow stops properly (two slow stops were classified as sudden stops). Since our algorithm requires two post LPF samples with n ¼ 20, the overall detection process takes 200 ms, which is significantly shorter than the detection with GPS readings (e.g., 2.5 sec). In reality, this reduced latency translates to quicker notifications; thus, potentially lowering the number of accidents. We acknowledge that there are various systems for detecting braking activities such as the Brake Assist PLUS system from Mercedes-Benz and the Collision Warning with Auto Brake by Volvo. These pre-installed systems are based on accurate distance estimation to neighboring vehicles with radar. However, compared to smartphonebased solutions, these system are relatively more expensive and are available to selected vehicles only. Once applications are notified of a braking action (using any braking detection scheme), applications send emergency alerts to the server, which then computes the vehicles that are affected by this emergency braking event using SurroundingVehiclesðvl; hv; R; SAME HEADINGÞ. Subsequently, the server sends alerts to the identified vehicles. Given that the round trip latency of 60 ms on 4G/LTE, and the braking detection latency of 200 ms, the entire process should finish within 300 ms after the braking event. In our experiment with 40 sudden stops and 40 slow stops, all 42 events which were classified as sudden stops (as discussed above) were properly reported to a following vehicle located 150 meters apart within 300 ms.
5.3 Deployment Experience We now share lessons learned from a small-scale deployment of our emergency braking application developed using VoCell. Specifically, as the list below details, based on our experiences, we were able to identify a points of consideration for future large-scale developments: Smartphone accelerometer calibration. Modern smartphones typically have three-axial accelerometers that measures the force on fixed axes, and the device orientation changes the readings of these axes. Without orientation calibration, applications can mis-interpret these readings. For example, if our emergency brake detection component does not adjust its advancing axis and the gravitational axis accordingly, it can miss braking activities of a vehicle. To address this problem, we implemented an additional component (e.g., CalibrateAccelerometerðtÞ) that takes in the first t seconds of stable accelerometer readings to set the vehicle’s heading. Furthermore, we use the gyro to continuously compensate for the orientation change. Adaptive reporting intervals. One problem we noticed is the overhead of periodic reporting. There are many cases where the car state does not exhibit any changes, such as a stopped state at the red light. Empirical data shows that adjusting the reporting frequency between 1 and 10 Hz according to both the surrounding area type (highway, city, suburban) and the car state, can significantly reduce the network
VOL. 13,
NO. 11,
NOVEMBER 2014
traffic, without sacrificing the application performance. For this purpose, we design the APIs in VoCell to allow the dynamic adjusting of reporting intervals. We also note that this technique introduces a new system policy-related tradeoff between the movement tracking accuracy and network bandwidth conservation. While our current sample applications assume highest data accuracy for safety applications, finding the lower bound is useful to conserve the network bandwidth. The architecture of VoCell will open further research on this tradeoff. Effective interaction with drivers. Vehicular safety applications are highly user interactive, and it is important to define how they will interact with the users. Specifically, even if the system can deliver an alert within a few hundred milliseconds, if drivers need several seconds to determine their next action, the alert would not be as useful. Our current user interface options in VoCell have gone through several revisions to address this concern. We have found that audible warnings (e.g., beeping) work well to get user attentions. VoCell also allows color and font size differences to cover three levels of severity: informative, warning, and caution.
6
RELATED WORK
We now position our work among existing literature in the domains of smartphone-based sensing systems for vehicular networking and systems that utilize the cellular network for vehicular applications. Closely related to VoCell, some previous work proposed using cellular networks for vehicular communications. As an example, in [18] the authors improve LTE communications to provide a customized communication infrastructure for vehicular networks. In addition to these efforts, in terms of analyzing the performance of LTEbased vehicular networks, Abid et al. presented simulation results for throughput, packet loss ratio and delay when vehicular applications utilize the cellular networks [2]. While we share the same concept of integrating cellular networks to vehicular applications, existing literature mostly draw their conclusions based on simulation, which only partially reflects the performance of wireless networks in reality. On a more practical perspective, Corti et al., evaluate the performance of a UMTS network in a real vehicular environment [5]. This work also proposes the centralized Advanced Driver Assistance System and measures the latency introduced by a cellular network. While this work is meaningful in the sense that it provided one of the first empirical performance evaluations for cellular networkbased vehicular networks, the authors focus only on packet delivery latency and do not discuss other important metrics such as reliability and system scalability. Our work not only performs an in-depth evaluation of the LTE/3 G latency performance in real environments, but we also present evaluations on the reliability and scalability of the cellular systems. Furthermore, our work takes a step further and shows comparisons against the state-of-the-art standardized hardware designed for VANETs. Finally, our work extends the findings to design a development environment and present sample application implementations.
PARK ET AL.: A FEASIBILITY STUDY AND DEVELOPMENT FRAMEWORK DESIGN FOR REALIZING SMARTPHONE-BASED VEHICULAR...
7
CONCLUSION
This work presents a feasibility study along with guidelines and the VoCell application development framework for enabling vehicular networking applications with smartphones. The observations made in this work suggest that all the ingredients for realizing such systems are ready. Nevertheless, we fully acknowledge the fact that over the next decade, vehicular networks based on the WAVE standards will start to appear in the cars that we drive every day. The VoCell framework and applications presented in this work can act as catalysts that bring crucial vehicular applications to reality sooner. With studies and commercial efforts suggesting that such cellular-based vehicular networking systems can be well-accepted by a large population, the active participation of drivers can revolutionize road safety effort by actively providing relevant suggestions to drivers.
ACKNOWLEDGMENTS This work was jointly supported by project number #10041725 from KEIT and the MSIP, and also by the Midcareer Researcher Program through NRF grant funded by the MEST (2011-0028892). JeongGil Ko is the corresponding author.
REFERENCES [1] [2]
[3]
[4] [5]
[6] [7] [8]
[9] [10] [11] [12] [13] [14] [15]
“NS-3 Network Simulator, ” http://www.nsnam.org/, 2009. H. Abid, T.-C. Chung, S. Lee, and S. Qaisar, “Performance Analysis of LTE Smartphones-Based Vehicle-to-Infrastructure Communication,” Proc. IEEE Ninth Int’l Conf. Ubiquitous Intelligence & Computing and Ninth Int’l Conf. Automatic & Trusted Computing (UIC/ATC), 2012. G. Boudreau, J. Panicker, N. Guo, R. Chang, N. Wang, and S. Vrzic, “Interference Coordination and Cancellation for 4G Networks,” IEEE Comm. Magazine, vol. 47, no. 4, pp. 74-81, Apr. 2009. Q. Chen, D. Jiang, V. Taliwal, and L. Delgrossi, “IEEE-802.11Based Vehicular Communication Simulation Design for NS-2,” Proc. ACM VANET Workshop, 2006. A. Corti, S.M. Savaresi, V. Manzoni, P. di Milano, M.D. Santucci, O. Di Tanna, and P. Spa, “A Centralized Real-Time Driver Assistance System Road Safety Based on Smartphone,” Proc. The First Workshop Pervasive Urban Applications, 2011. Denso, Denso Wireless Safety Unit (WSU), http://www.globaldenso.com/en/investors/annual/2007/future01.html, 2014.. UK Government, Typically Stopping Distance, http://www. nidirect.gov.uk/imperial/dg-070304-95511.pdf, 2014. C.-L. Huang, Y.P. Fallah, R. Sengupta, and H. Krishnan, “Adaptive Intervehicle Communication Control for Cooperative Safety Systems,” IEEE Network, vol. 24, no. 1, pp. 6-13, Jan./Feb. 2010. IEEE Standard for Wireless Access in Vehicular Environments (WAVE) Multi—Channel Operation, IEEE 1609 WG, 2010. IEEE Standard for Wireless Access in Vehicular Environments (WAVE) Networking Services, IEEE 1609 WG, 2010. IEEE Standard for Wireless Access in Vehicular Environments (WAVE)—Security Services for Applications and Management Messages, IEEE 1609 WG, 2013. Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE 802.11 WG, 2012. J. Min, J. Ha, S. Yun, I. Kang, and H. Kim, “Secure Vehicular Communication for Safety Applications - A Measurement Study,” Proc. IEEE Vehicular Technology Conf. (VTC Spring ’08), 2008. OpenSignal, “The State of LTE”, 2013, http://opensignal.com/ reports/state-of-lte/OpenSignal-State-of-LTE-Report_(Feb-2013). pdf, 2014. P. Mohan, V. N Padmanabhan, and R. Ramjee, “Nericell: Rich Monitoring of Road and Traffic Conditions Using Mobile Smartphones,” Proc. Sixth ACM Conf. Embedded Network Sensor Systems (ACM SenSys), 2008.
2443
[16] Y. Park and H. Kim, “Collision Control of Periodic Safety Messages with Strict Messaging Frequency Requirements,” IEEE Trans. Vehicular Technology, vol. 62, no. 2, pp. 843-852, Feb. 2013. [17] E. Pindilli, ”Applications for the Environment: RealTime Information Synthesis (AERIS) Benefit-Cost Analysis”, AERIS Program, http://www.its.dot.gov/presentations/pdf/AERIS_BCA_webinar _10-17-12.pdf, 2014. [18] G. Remy, S. Senouci, F. Jan, and Y. Gourhant, “Lte4v2x - Collection, Dissemination and Multi-Hop Forwarding,” Proc. IEEE Int’l Conf. Comm. (ICC), 2012. [19] S.O. Rice, “Statistical Properties of a Sine Wave Plus Random Noise,” The Bell System Technical J., vol. 27, pp. 109-157, Jan. 1948. [20] SAE J2735-200911, Dedicated Short Range Communications (DSRC) Message Set Dictionary, 2009. [21] M. Sepulcre and J. Gozalvez, “Experimental Evaluation of Cooperative Active Safety Applications Based on V2V Communications,” Proc. ACM VANET Workshop, pp. 13-20, 2012. [22] R.W. Sinnott, “Virtues of the Haversine,” Sky AND Telescope, vol. 68, p. 158, Dec. 1984. [23] O. Tonguz, N. Wisitpongphan, F. Bai, P. Mudalige, and V. Sadeka, “Broadcasting in VANET,” Proc. IEEE Mobile Network for Vehicular Environments (MOVE) Workshop, 2007. [24] M. Torrent-Moreno, D. Jiang, and H. Hartenstein, “Broadcast Reception Rates and Effects of Priority Access in 802.11-Based Vehicular Ad-Hoc Networks,” Proc. ACM VANET Workshop, 2004. [25] USDOT UMTRI, “Safety Pilot Model Deployment,” http://www. safetypilot.us/, 2014. [26] US DoT, ITS Program Advisory Committee, Minutes of March 2728, 2013 Meeting, http://www.its.dot.gov/itspac/march2013/ pdf/Minutes_ITSPAC_2013-03-27_2013-03-28_R01C00vFinal.pdf, 2013. [27] Cohda Wireless, “CohdaMobility MK2 WAVE-DSRC Radio,” http://www.cohdawireless.com/product/mk2.html, 2014. [28] E.M. Nahum, R.J. Gibbens, Y.-C. Chen, Y.-s. Lim, and D. Towsley, “Characterizing 4G and 3G Networks: Supporting Mobility with Multi-Path TCP,” UMass Technical Report UM-CS-2013-027, 2013. Yongtae Park received the B.Eng, and M.Eng degrees from Korea University in 2010, and 2012, respectively. He is currently a Ph.D. candidate at Korea University and a recipient of the Global Ph.D. Fellowship from 2012 to 2014. His research interests include software defined radio, vehicular communication and mobile computing.
Jihun Ha received the B.Eng, M.Eng, and Ph.D. degrees from Korea University in 2008, 2010, and 2014, respectively. He is currently a postdoctoral researcher at Korea University and his research interests include mobile computing, vehicular networking, IoT, and network virtualization.
Seungho Kuk received the B.Eng degree from Korea University in 2014 and is currently a M.Eng student at Korea University. His research interests include mobile computing, vehicular communication and software defined radios.
2444
IEEE TRANSACTIONS ON MOBILE COMPUTING,
Hyogon Kim received the B.Eng and M.Eng degrees from Seoul National University in 1985 and 1987, respectively, and his Ph.D. degree from the Department of Computer and Information Science, University of Pennsylvania, in 1995. Prior to joining the Department of Computer Science at Korea University, he was a research scientist at Bell Communications Research (BellCore) from 1996 to 1999. His research interests include vehicular communication, mobile computing and Internet of Things. Chieh-Jan Mike Liang received the Ph.D. degree from the Johns Hopkins University in 2011. He is currently a researcher at Microsoft Research. His current research interests surround system and networking aspects of sensory and mobile computing.
VOL. 13,
NO. 11,
NOVEMBER 2014
JeongGil Ko received the B.Eng. degree in computer science and engineering from Korea University in 2007 and received his Ph.D. degree in computer science from the Johns Hopkins University in 2012, respectively. He is a receipient of the Abel Wolman Fellowship awarded by the Johns Hopkins University in 2007. His research interests are in the general area of developing wireless embedded systems with ambient intelligence for the Internet of Things (IoT) and Cyber Physical Systems (CPS). As of June 2012, JeongGil Ko is with the Electronics and Telecommunications Research Institute (ETRI) in Daejeon, Korea. " For more information on this or any other computing topic, please visit our Digital Library at www.computer.org/publications/dlib.
