ThinGs In a Fog: System Illustration with Connected Vehicles

Transcription

1 ThinGs In a Fog: System Illustration with Connected Vehicles Anjan Rayamajhi 4, Mizanur Rahman 2, Manveen Kaur 1, Jianwei Liu 1, Mashrur Chowdhury, Ph.D. 2, Hongxin Hu, Ph.D. 1, Jerome McClendon, Ph.D. 1, Kuang-Ching Wang, Ph.D. 3, Abhimanyu Gosain 4, and Jim Martin, Ph.D. 1,5 1 School of Computing, Clemson University, Clemson, SC Glenn Department of Civil Engineering, Clemson University, Clemson, SC Electrical and Computer Engineering, Clemson University, Clemson, SC Raytheon BBN Technologies, Cambridge, MA Corresponding Author, jmarty@clemson.edu Abstract ThinGs In a Fog is a distributed computing framework designed to support interdisciplinary research under the broad context of the Internet of Things. The framework is based on an Edge Computing system design that distributes application processing to system compute nodes leveraging locality and compute resources to support machine-to-machine interactions that potentially have real-time constraints. To provide further insight, we focus on Connected Vehicle as an exemplar application domain. This paper provides a summary of work-todate including preliminary results from a prototype of the system deployed at Clemson University. We illustrate the system by presenting the design, implementation, and evaluation of a connected vehicle application known as Queue Warning. This application has been thoroughly developed by the transportation community, however there is renewed interest in understanding how such an application applies in a connected vehicle environment. Queue Warning is nicely suited for illustrating the benefits and complexities of distributed applications in emerging Internet of Things frameworks such as TGIF. Keywords Internet of Things, Edge Computing, Fog Computing, Connected Vehicles, Wireless Sensing Networks, Data Semantics and Common Ontologies I. INTRODUCTION The Internet of Things (IoT) conceptually has existed since 1999, viewed as the path for wide adoption of ubiquitous computing and sensor networks [1]. The term remained broadly (un)defined until recent activities and trends including supportive federal government policy, availability of low cost underlying technical enablers, and industry trends centered around big data, which collectively have led to the current surge of interest in IoT. Relevant academic research in IoT represents an integration of a diverse set of research communities including mobile and pervasive computing, wireless sensing networks, wireless systems, cloud computing, data science, and cyber physical systems (CPS) [2]. The literature reflects distinct phases in the evolution of IoT [3,4]. Initially, IoT focused on enhancing the visibility of things through RFID. The concept extended the things to CPS objects accessed through wireless sensing and actuator networks (WSANs). Scalability became an issue when the Internet in IoT was assumed to be IPv6. Scaling to a global Internet led to semantic and big data perspectives of IoT. The most recent phase of IoT described by terms similar to Smarter Spaces, such as Smarter Homes, Cities, Farms, Roads, and Power Grid, are resulting in large scale development and deployment of IoT systems. A Smart City applies the IoT concept to applicable objects and domains such as power grid, climatology, connected vehicles and public safety to name a few. Fundamental to IoT is the use of Edge Computing (also referred to as Fog Computing) [5,6]. Edge Computing involves a set of lightweight services, referred to as microservices, operating at compute nodes that are located geographically close to devices (i.e., things ) in the field. A cloud close to the ground is the metaphoric fog in TGIF. Edge Computing also assumes intelligent infrastructure that can support a diverse, heterogeneous environment that potentially includes multiple, possibly competing applications from different organizations in a shared usage model. The data driven nature of IoT motivates the sharing of data across different domains, in some cases in a peer-to-peer manner. Current research in named data networking provides a possible path for future coupling between the commodity Internet and IoT. US government investment in Smart City, Smart Grid, and Connected Vehicle Technology (CVT) programs is motivating academic research in basic science to support these complex systems. The research presented in this paper is funding most directly by CVT programs. The US Department of Transportation (DOT) recently announced a proposed law to require all new vehicles to support vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications based on a distributed compute environment generally referred to as Wireless Access for Vehicular Environments (WAVE). This set of IEEE standards is a variant of Wi-Fi referred to as Dedicated Short Range Communication (DSRC) [7]. The literature refers to all technology required to implement and support a CV system deployment, including the applications operating in the DOT s cloud that consumes and analyzes CV sensing data, as Connected Vehicle Technology (CVT). As we will explore later in this paper, CVT can be viewed as an application domain that operates in the IoT that involves mobile things such as vehicles, pedestrians, bicycles, and stationary things such as in-road vehicle sensing devices, video traffic cameras, and traffic lights. We have developed an IoT system framework, Things in a Fog (TGIF), that is meant to foster innovation and collaboration across a diverse set of research communities at Clemson University. Initial research has focused on systems design and validation through prototyping and evaluation. For brevity, we limit the scope of this paper to a brief introduction of TGIF, to This work was sponsored in part by the National Science Foundation under grants CNS and CNS

2 the prototype implementation that we have deployed at Clemson University, and to a summary of work-to-date on the design, implementation, and evaluation of a specific CVT application. We illustrate the system by presenting the design, implementation, and evaluation of a connected vehicle application known as Queue Warning. This application has been thoroughly developed by the transportation community, however there is renewed interest in understanding how such an application applies in a connected vehicle environment. Queue Warning is nicely suited for illustrating the benefits and complexities of distributed applications in emerging Internet of Things frameworks such as TGIF. The goal of this paper is to provide a preview of TGIF to spark conversation and feedback. This paper is organized as follows. The next section presents a brief overview of the relevant literature. Section III presents details of the TGIF system design and implementation of the Queue Warning application with TGIF. Preliminary results obtained using the TGIF and Queue Warning experimental deployments are presented in Section IV. II. BACKGROUND A. Clouds to the Edge and IoT The literature on IoT identifies a number of perspectives on the subject of IoT [4,8]: 1) Tracking things: IoT was originally defined in the context of using RFID to track things. 2) Wireless Sensing and Actuator Networks (WSANs): A WSAN gathers information about the environment and utilizes actuators such as servomechanisms in cyberphysical systems (CPS) such as automobiles or manufacturing. CPS provides theoretic methods and tools that can be applied to IoT sytems. 3) Service Oriented Architecture IoT: An SOA approach simplifies the discussion on IoT s scope of operation by assuming that each thing in the IoT offers its own set of services. SOA implies a middleware that provides the glue to connect the system services to applications. 4) Data Oriented IoT: Data oriented IoT acknowledges the massive amount of raw data that is possible in large scale IoT deployments. The perspective focuses on a semantically aware system that reflect the added value of aggregated data and of data produced through reasoning [9] particularly for sharing and exchanges between machines and domains. Further, the semantics need to support the sharing and exchange of data across machines and over multiple application domains. 5) Edge Computing: The high-speed data processing and latency requirements unmet by centralized cloud computing required by IoT applications is made possible through Edge Computing. IoT s history brings quite a bit of prior work that has made it difficult for unifying standards and architectures to materialize. IoT transport protocols is more clearly defined through the adoption of Constrained Application Protocol (CoAP), Message Queue Telemetry Transport (MQTT), Extensible Messaging and Presence Protocol (XMPP), Advanced message Queueing Protocol (AMQP), and the Data Distribution Service (DDS) [4]. The only feature in common across these protocols is that they each provide a publish subscribe messaging model that offers an asynchronous application interface (i.e., requires applications to setup callback functions to handle asynchronous events). The protocols differ in many details such as 1) TCP versus UDP; 2) Available service quality levels; 3) Application programming environment and interfaces. B. Connected Vehicle The US DOT has developed a roadmap CVT referred to as the Connected Vehicle Reference Implementation Architecture (CVRIA) [10]. The CVRIA provides a guide for the research and development of CVT by providing a detailed system architecture that involves vehicles and road side equipment equipped with communications and information processing capability, allowing vehicles to be aware of their status and to communicate with each other, with surrounding infrastructure, and consequently with state DOT transportation management systems located in a hierarchical manner throughout an area, city, and state. Crash avoidance applications that are expected to be required by future vehicles exchange safety critical information such as speed, acceleration, location and direction of movement with peer vehicles. While the primary goal of CVT is to save lives, additional benefits are possible in terms of improved traffic operational performance, reduced energy consumption, and reduced pollutant emissions. These applications have diverse goals, properties, and network requirements. The vehicle on-board unit (OBU) provides the platform for vehicle-based processing, storage and communications. The OBU interacts with other OBUs (i.e. V2V) or with road-side units (RSUs) (i.e. V2I) deployed along roadways. A set of IEEE standards, collectively referred to as Wireless Access for Vehicular Environments (WAVE), specifies security mechanisms, network services, and a variant of Wi-Fi specified by the IEEE p standard also referred to as Dedicated Short Range Communication (DSRC). It has been pointed out that DSRC will not be sufficient to support the breadth of applications outlined by CVRIA [11]. The issue of how non-dsrc wireless networks can embellish vehicular networks is under intense investigation. III. SYSTEM DESCRIPTION The TGIF framework, illustrated in Figure 1, supports applications running on a hierarchy of node types that abstract to the system a range of system level capabilities. Currently, TGIF nodes are limited to hardware platforms that support Ubuntu LTS. TGIF is middleware that provides a C++ object interface to applications. Objects provide abstract service interfaces to basic functions and services such as geolocation, messaging, connectivity, or WAVE. TGIF is a data oriented IoT system, consequently the messaging service is based on asynchronous messaging using a publish/subscribe interface. IoT platforms or devices are supported natively by TGIF if the TGIF middleware has been ported to the platform. A platform such as a Raspberry Pi without the TGIF software can communicate with a TGIF node using an agreed upon network and transport protocol. TGIF provides a gateway service that

3 converts the sensing data from the external device into an appropriate TGIF message. Messages are disseminated across TGIF nodes through publish-subscribe methods, using application or system provided message attributes to provide hints to the TGIF system related to temporal, location, or priority. The attributes along with subscribe requests from either TGIF system services or applications are collectively used to assist with routing of messages throughout the system. The TGIF framework provides support for either localized, centralized, or distributed control of heterogeneous wireless resources. Mobile nodes are likely to have multiple wireless interfaces. The framework is meant to support research in the area of resource allocation in heterogeneous wireless systems. The system provides three methods to applications. First, applications can choose to have the system handle the choice of network (if multiple networks are available). Second, applications can provide hints to the system when it publishes a message by adding attributes to the message. Third, applications can use the connectivity service for communicating with other applications. For example, the connectivity service supports a socket object that provide communications function appropriate for mobile or sensing scenarios. Examples include separating the network address and link addresses from the socket and support for reliable and unreliable stream transport using multiple interfaces. The TGIF architecture (illustrated in Figure 1) involves a backbone network that includes two components. Fixed Edge nodes that can connect to the campus network interconnect using VPNs and one or more VPN gateways. Second, edge nodes (mobile or fixed) that operate outside the campus backbone (i.e., a (MEN) in a vehicle that can connect to the Internet through a commercial 3GPP network) interconnects with the backbone through one of the VPN gateways that has one interface exposed to the commercial Internet. Aside from this one window to the backbone, all other campus edge nodes use internal campus private IP addressing. The system defines several classes of nodes, a hierarchical set of nodes (some mobile, some fixed) that run the TGIF middleware and then a set of external nodes, referred to as machine nodes, that represent external IoT devices or platforms that do not run TGIF code. System Edge Fixed Edge Node Fig. 1. TGIF system architecture. Cellular Network TGIF Gateway Backbone Network IoT Platforms GENI Cloud Other Universities Fixed Edge Node For example, a mobile node could be a smartphone, a raspberry pi, or a DSRC OBU running in a car. With our particular focus of Connected Vehicles, we are building a mobile TGIF node that includes a general-purpose embedded Linux board, any number of wireless connectivity options through USB dongles, and an OBU. We refer to this as a Mobile Edge Node (MEN). Further information on the TGIF nodes types are described as follows: 1) Machine Node (MN): An IoT device that does not support the TGIF middleware. TGIF includes gateway services to support a set of Machine Nodes. 2) System Node Node (SEN): An end point for data generated and computed locally within the realm of TGIF, also supports third party application interfaces such as DOT, user applications etc. Provide services for global networking, data collection etc. 3) (MEN): Edge computing capability added to mobile units such as vehicle or low flying drones. These are capable of supporting Heterogeneous Networks and can leverage Wi-Fi, LTE or DSRC through other nodes. 4) Fixed Edge Node (FEN): that is logically similar to a MEN but offers greater processing capabilities, support for a wired backhaul (if available at the location), and includes an RSU rather than an OBU and capable of interfacing with different sensors not limited to vehicle data, weather, road harzards etc. Figure 1 also illustrates the use of the Global Environment For Network Innovation (GENI) for interconnecting TGIF deployments across University campuses. As an example, let s assume we want to extend the TGIF network based in Clemson to the GENI network available at a different University. There are two interconnect models possible. First, we add a GENI Edge Resource to the TGIF backbone. Addressing between the GENI network and the TGIF network can be handled using IP routing. Second, the TGIF backbone is replaced by a GENI

4 network fabric. The TGIF middleware could be integrated into GENI Resource Nodes. Any level of integration would be possible between the current TGIF command and control and the GENI control subsystems. TGIF s SOA abstracts services that are appropriate for the specific node type. Example services include the following: Messaging Service: The messaging service takes care of all data transfer between the system nodes, MENs, and FENs. This service handles crucial aspects of data transfer such as message identification based on factors such as priority and utility, broadcast dissemination within a sub-network, and error recovery and retransmission to ensure efficient handling of information. Connectivity Service: The connectivity service allows applications to utilize the best available method of data transmission from source to destination. The best available method is decided based on signal strength of all the access networks, measured and predicted end-to-end metrics of connections, and the demands of applications. WAVE Service: The WAVE Service provides applications and other system services with ways to acquire information and use services related to transmission and reception of message and control information using DSRC/WAVE standards. WAVE Services also include a set of internal services called Lower Edge Services that are responsible for creating an independent middle ware that understands the mechanism required to transfer messages between specific DSRC protocol and various messaging protocols used by TGIF system. Security Service: Secure message dissemination is crucial for any CVT system. The design of the security architecture for TGIF is under design. However, examples of security services include encryption and authentication of messages and the detection and mitigation of denial of service attaches. TGIF is designed to support applications that involve different types of data and processing performed at different nodes based on the node s location and hierarchical node type. External applications are also supported through an exposed interface to the TGIF pub/sub messaging system. For example, this allows external data analytics to subscribe to published topics. A. Illustrative application: Queue Warning Queue warning application provides advance information to the downstream traffic to prepare for slow moving or stop traffic in the upstream, which will reduce traffic congestion and secondary crashes due to unexpected traffic condition. The implementation of queue warning application using CV technology will enable DOT to minimize secondary collisions and the resulting traffic flow shockwaves by: 1) rapidly detect the location, duration, and the length of a queue propagation, 2) formulating an appropriate response plan for approaching vehicles, and 3) disseminating such information to the approaching vehicles readily and in an actionable manner. According to CVRIA, queue-warning application is not intended to operate as a crash avoidance system (e.g., like the forward collision warning safety application) [10], however it will engage well in advance of any potential crash situation, providing messages and information to the driver in order to minimize the likelihood of crash or mitigation actions later. The queue-warning application performs two essential tasks: queue determination (detection and/or prediction) and queue status dissemination. This application will eventually reduce fuel consumption and greenhouse gas emission, save travel time and most importantly, lives. Figure 2 shows an architecture of a queue warning application adopted from CVRIA [10]. According to CVRIA, there are two different perspectives for implementing Queue Warning application that includes- 1) application can run at vehicle and 2) application can run at roadside unit. Vehicle Queue Warning application aggregates data within a vehicle s DSRC coverage to detect queues. Roadside unit Queue Warning application can aggregate CV data within the DSRC communication range of a RSU and use it to detect queue. Roadside unit then can relay queue-warning status to the TMC, which uses the information to monitor the roadway segment. Queue warning application status Traffic Management Center TMC Roadway Monitoring TMC Traffic Surveillance Traffic situation data Vehicle environmental data Queue warning application information Roadside Unit RSU Queue Warning Raw Data Processing Unit Roadside Sensors Monitoring Traffic flow and traffic images Roadway warning system status Environmental sensor data Roadway surveillance, traffic flow and environmental sensor control Queue warning information Vehicle location and motion Vehicle environmental data Fig. 2. USDOT reference for Queue Warning application. ITS Roadway Equipment Roadway Warning Roadway Environmental Monitoring Roadway Basic Surveillance Vehicle signage local data Traffic situation data Connected Vehicle OBU Vehicle Queue Warning Vehicle Basic Safety and environmental monitoring Figure 3 illustrated a high-level design of our queue warning services based on edge centric computing. As we described previously, this physical system consists of System Edge Node, Fixed Edge Node, and. In our system, we have three different perspectives for queue warning service: 1) Q-Warn service at vehicle level (CV OBU), 2) Q-Warn Service at Fixed Edge node (i.e., roadside unit), and 3) Q-Warn service at System Edge node (i.e., TMC). These three nodes can publish or subscribe required information through messaging services. Data collected for Queue Warning application can be used for other CV applications through Queue Warn services. For example, vehicle location and motion (as shown in Figure 2) information can be used in the following applications: 1) Border Management Systems; 2) Connected Eco-Driving; 3) Eco- Approach and Departure at Signalized Intersections; 4) Eco- Cooperative Adaptive Cruise Control; 5) Eco-Lanes

5 Management; 6) Eco-Ramp Metering; 7) Eco-Speed Harmonization; 8) Eco-Traffic Signal Timing; 9) Intelligent Traffic Signal System; 10) Low Emissions Zone Management; 11) Map Management; 12) Queue Warning; 13) Roadside Lighting; 14)Smart Park and Ride System; 15) Speed Harmonization; 16) Traveler Information- Smart Parking; 17) Variable Speed Limits for Weather-Responsive Traffic Management; and 18) Vehicle Data for Traffic Operations [10]. DSRC range of a Fixed Edge Node, the vehicle OBU can connect to the RSU via the DSRC communication. We hosted databases using MongoDB to store data at the Fixed Edge Node device and at the System Edge Node. Training Data for System Edge Node Parameter Estimation Algorithm Parameter Values MongoDB Fixed Edge Node System Edge Node CV App - 1 CV App - 2 Q-Warn Service - 1 Messaging Service CV App - 2 Q-Warn Service - 2 Messaging Service Fig. 3. High-level design of Queue Warning services. CV App - 2 Q-Warn Service - 3 Messaging Service In addition, queue warning application algorithm (e.g., machine learning based algorithm or simple logic based algorithm) can be run at three different edge nodes depending on computational load of application algorithm. If a queue warning application runs in a vehicle (Q-Warn Service - 1), it should not be computationally intensive and generate queue flag based on surrounding vehicles location, motion (e.g., headway, speed) and weather information in real-time. On the other hand, queue warning application algorithm (i.e., machine-learning) in fixed edge node (i.e., Q-Warn Service 2) and system edge node (i.e., Q-Warn Service 3) can be computationally intensive and it may not be time sensitive as vehicle based service. This queue warning application provides services to other CV applications by providing early queue detection information. Other CV applications can be categorized into two groups that includes: 1) CV App 1 (i.e., safety applications and some mobility applications), which need real time information, and 2) CV App 2 (i.e., CV mobility and environmental applications), which are not time critical applications. For example, queue warning service can assist collision avoidance and cooperative adaptive cruise control application (i.e., CV App 1) by providing realtime queue alerts to other vehicles within the DSRC range to reduce rear-end collisions. The main contribution here is the redefinition of queue warning application in a TGIF system by leveraging services to other applications. IV. PRELIMINARY RESULTS In this section, we provide our recent results, which is mainly focused on implementation of queue warning service at Fixed Edge Node (i.e., Q-Warn Service 2, which is shown in Figure 3) at the CV Testbed located on campus. Figure 4 illustrates our current CV deployment on perimeter road at Clemson University campus, Clemson, SC. We implemented a machinelearning based queue warning service at Fixed Edge Node. Queue warning algorithm is distributed between Fixed Edge and System Edge Node. This queue-warning algorithm minimizes the computing workload of processing, aggregating and predicting queue using data from each connected vehicle within a DSRC communication range of a Fixed Edge Node. Connected vehicles (i.e., s) are able to set up their own network autonomously with Fixed Edge node using DSRC. Whenever one of the s is within the BSM Messages MQTT Broker DSRC RSU BSM Messages Time Stamp Car ID Latitude Longitude Speed Fixed Edge Node Q-Warn Service - 2 Processed Data Time Stamp Average Speed Average Headway BSM Messages Traffic Flow Direction Raw Data Processing Training Data for Time Stamp Average Speed Average Headway Queue Flag MongoDB Queue Information Queue Ahead or No Queue Ahead Average Speed Queue Prediction Algorithm Parameter Values Mobile Mobile Mobile Edge Node Edge Node Edge Node Perimeter Road, Clemson, SC Fig. 4. Details of Q-Warn Service-2 (as shown in Figure 3) implementation at Jervey Gym Athletic Center CV deployment. We simulated similar connected vehicle environment on the perimeter road in VISSIM, which is a microscopic traffic simulator tool [12], to get CV data for training the machinelearning algorithm for queue detection. We also used VISSIM simulation data for estimating the Support Vector Machine () parameter at the System Edge Node. Support Vector Machine () method was used for predicting queues (queue and no queue) from the Scikit learn library tool in python [13]. A radial basis kernel function is used for the binary classification problem. It is required to estimate parameters using train data set. A grid-search method was used to find the optimal value of the parameters. As we estimated the parameters in System Edge Node, the duration of estimating parameter set does not affect the real-time application. Vehicle trajectory data collected from the DSRC OBU at DSRC RSU is published to MQTT broker, and raw data processing unit consumes data from the MQTT broker. After processing the

6 vehicle trajectory data, queue prediction algorithm will run and predicted data will be stored at MongoDB database in the Fixed Edge Node device. Other CV applications can use the predicted data from the Fixed Edge Node. Data will be stored at the Fixed Edge Node device for a short period of time. Data can also be stored for a longer period of time in the historical data storage at the System Edge Node. In future, we will implement other connected vehicle applications by sharing the stored data of queue warning application TABLE I A SAMPLE QUEUE PREDICTION RESULTS (STORED IN MONGODB) Average Speed (mph) Average Space Headway (ft) based Machine Learning Algorithm Field Data (using video Camera) No queue =0; Queue =1 Illustrative Results: In our Testbed, three vehicles were stopped at the traffic signal forming a queue. We collected vehicle trajectory data (i.e., time stamp, car ID, latitude, longitude and speed) similar to Basic Safety Messages (BSMs) every 100 milliseconds to predict the queue state (as shown in Table I). We analyzed vehicle trajectory data to obtain space headway between two consecutive vehicles and compute average speed of vehicles over each second (as shown in Table I). In our test, we used speed and space headway as features for classifying queue. Related literature of found that these machine learning algorithms are very sensitive to the scale and variance of the input data [13,14,15]. Thus, both train and test data are normalized using same scale between 0 and 1. Table I shows a sample queue prediction results on the perimeter road using the machine learning algorithm. This table also provides field collected video camera data representing the ground truth data. We calculated machine learning algorithm accuracy for predicting queue for three test runs of 167 instances. The accuracy of machine learning algorithm was 94%. V. CONCLUSIONS In this paper, we introduced the TGIF system framework, and illustrated the concept in more detail by summarizing workto-date on the design and implementation of the Queue Warning application. There are quite a few IoT frameworks and systems presented in the literature. However, to the best of our knowledge, there currently is not a single, unifying architecture and framework. We did not develop TGIF to serve as a unifying framework, instead it was developed by necessity to support our research. The novelty of our work is more likely our illustrative example of how an emerging CV systems might coexist and integrate with an IoT system based on an Edge Computing model. In a future publication, we will provide a thorough description and evaluation of TGIF with several illustrate applications from multiple application domains. We also plan to make TGIF available to the community as an open source project. REFERENCES [1] K. Ashton, That Internet of Things Thing, RFiD Journal, Vol. 22, no. 7, pp , [2] F. Bonomi, R. Milito, J. Zhu, S. Addepalli, Fog Computing and its Role in the Internet of Things, Proceedings of MCC, August [3] J. Stankovic, Research Directions for the Internet of Things, IEEE Internet of Things Journal, vol 1. No. 1, Feb [4] L. Atzori, A. Iera, G. Morabito, The Internet of Things: A Survey, Elsevier Computer Networks. (2010), doi: /j.comnet [5] R. Khatoun, S. Zeadally, Smart Cities: Concepts, Architectures, Research Opportunities, Communications of the ACM, vol. 59, No 8, Aug [6] W. Shi, J. Cao, Q. Zhang, Y. Li, and L. Xu, Edge Computing: Vision and Challenges, IEEE Internet of Things Journal, vol 3, no 5, oct [7] Department of Transportation, Federal Motor Vehicle Safety Standards; V2V Communications, Notice of Proposed Rulemaking, Jan, [8] L. Atzori, A. Iera, G. Morabito, The Internet of Things: A Survey, Elsevier Computer Networks. (2010), doi: /j.comnet [9] A. Gyrard, P. Patel, A., Sheth, M. Serrano, Building the Web of Knowledge with Smart IoT Applications, IEEE Intelligent Systems, vol 31, no 5, Sept [10] Connected Vehicle Reference Implementation Architecture (CVRIA). Available online: [11] K. Dey, A. Rayamajhi, M. Chowdhury, P. Bhavsar, J. Martin, Vehicleto-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication in a heterogeneous wireless network Performance evaluation, TRC: Emerging Technologies, Vol 68, July [12] VISSIM User Manual. PTV Vision, July 18, [13] Support Vector Machines. Available online at [14] A. Attig and P. Perner, The Problem of Normalization and a Normalized Similarity Measure by Online Data, Tran. CBR, 4(1), 3-17, [15] A. B. Graf, A. J. Smola, and S. Borer, Classification in a normalized feature space using support vector machines, IEEE Transactions on Neural Networks, 14(3), , 2003.