Rule Optimization for Real-Time Query Service in Software-Defined Internet of Vehicles

Rule Optimization for Real-Time Query Service in Software-Defined Internet of Vehicles

\authorblockNXin Wang\authorrefmark1, Cheng Wang\authorrefmark1, Changjun Jiang\authorrefmark1, Lei Yang\authorrefmark2, Zhong Li\authorrefmark1, Xiaobo Zhou\authorrefmark3 \authorblockA\authorrefmark1 Department of Computer Science, Tongji University, China \authorblockA\authorrefmark2 Institute of Trustworthy Networks and Systems, Tsinghua University, China \authorblockA\authorrefmark3 Department of Computer Science, University of Colorado, USA

Internet of Vehicles (IoV) has recently gained considerable attentions from both industry and research communities since the development of communication technology and smart city. However, a proprietary and closed way of operating hardwares in network equipments slows down the progress of new services deployment and extension in IoV. Moreover, the tightly coupled control and data planes in traditional networks significantly increase the complexity and cost of network management. By proposing a novel architecture, called Software-Defined Internet of Vehicles (SDIV), we adopt the software-defined network (SDN) architecture to address these problems by leveraging its separation of the control plane from the data plane and a uniform way to configure heterogeneous switches. However, the characteristics of IoV introduce the very challenges in rule installation due to the limited size of Flow Tables at OpenFlow-enabled switches which are the main component of SDN. It is necessary to build compact Flow Tables for the scalability of IoV. Accordingly, we develop a rule optimization approach for real-time query service in SDIV. Specifically, we separate wired data plane from wireless data plane and use multicast address in wireless data plane. Furthermore, we introduce a destination-driven model in wired data plane for reducing the number of rules at switches. Experiments show that our rule optimization strategy reduces the number of rules while keeping the performance of data transmission.

I Introduction

Internet of Vehicles (IoV) is attracting considerable attention from both academia and industry. The vigorous development of communication technology and smart city makes various services possible in IoV, which significantly improves the quality and safety of driving. The research and industry communities are carrying out several projects[1][2] for the development of IoV. For example, EU’s CVIS [1] is committed to design, develop and test the technologies needed to allow cars to communicate with each other and with the nearby roadside infrastructure. Smartway [2] focuses on integrating all ITS functions to a Smartway platform and provides services by two-way communication.

Though there is a promising future in IoV, the proprietary and closed way of operating hardwares in network equipments slows down the progress of new services deployment and extension in IoV. Network equipments such as switches and routers are developed by different manufacturers. Every change of network equipments requires substantial manual configuration by trained operators, which makes network management expensive and error-prone. The lack of an open and unified interface for flexible and dynamically customizable network makes new services deployment and extension difficult in large-scale IoV. A new network architecture is expected for the development of IoV.

(a) (b)
Fig. 1: In Subfigure (a), when the vehicle moves to another place (form to ), it needs to establish a new connection. The dash line represents the connection which is not established yet; In Subfigure (b), when a vehicle connecting to multiple cameras simultaneously, it needs to build a path for each connection which is not efficient since all paths have the same destination (all data flow’s destination is ).

There are several projects for the new network architecture and Next Generation Internet (NGI). Named Data Networking (NDN) [3] aims to develop a new Internet architecture that concentrates on getting ‘what’ service rather than ‘where’ to get service. MobilityFirst [4] supports seamless and smooth mobility and it takes the mobility of nodes as a common case rather than a special case in traditional networks. NEBULA [5] develops a new network architecture based on cloud computing and data centers. The eXpressive Internet Architecture (XIA) [6] supports the trustworthy communication, the growing diversity of network using models, the sustained technological innovation and clarity of the interface between different networks. Software-Defined Network (SDN) provides a unified interface to configure network equipments and separates the control plane from the data plane. A unified interface of configuring network equipments makes large scale customizable network possible, and accelerates new services deployment in IoV. Therefore, we adopt SDN to support IoV for its open and unified interface, and propose Software-Defined Internet of Vehicles (SDIV), a new architecture for the development of IoV. SDN has several advantages in supporting IoV besides the open and unified interface: (1) SDN naturally has a high scalability by separating the data plane from control plane, (2) SDN has good network management capabilities as it centralizes the control part to the controller, (3) the controller is able to choose the best path for data transmission and plays as a coordinator between roadside electronic devices according to current network state. But, the characteristics of IoV introduce challenges in rule installation due to the limited size of Flow Tables at OpenFlow switches. It is necessary to build compact Flow Tables for scalability of IoV.

In this paper, we consider the real-time query service, one of typical services in IoV, to show the design details for rule optimization in SDIV. Real-time query service provides drivers the real-time conditions of roads and then drivers decide which way to go according to the information. Road information coming from the surveillance cameras (or other kind of roadside electronic devices) will be transmitted to every vehicles with the information demanded. In this scenario, the specific issues are: (1) the mobility of vehicles increases the number of rules since it needs to establish new connections between vehicles and surveillance cameras, (2) when a vehicle connecting to multiple cameras, it is not efficient to install rules for every path since each path has the same destination. Figure 1 illustrates the problems of rule installation in IoV. If the controller simply installs rules upon the requests of drivers, the table size at switches will be the bottleneck of scalability, which impacts the performance of real-time query service.

To address the rule optimization problems for real-time query service, we introduce several techniques by leveraging the centralized and fine granularity of data flow control in SDN for rule optimization: (1) To reduce the number of requests sent by vehicles, we use multicast address instead of general destination address as the last address when vehicles receive data from cameras; (2) To keep uninterrupted connection between vehicles and roadside electronic devices, we make the controller install rules in advance based on the conditions of vehicles; (3) To decrease the number of rules and maintain the correctness of data transmission, we modify the headers when packets come to branching nodes.

In this work, we first describe the architecture of SDIV. We then analyze the problem of flow table size in OpenFlow supported switches and design and develop an approach to reduce the number of rules in switches. We validate the feasibility of rule optimization by considering four situations in the real-time query service and analyzing the details of data transmission in each case. Finally we use Floodlight [7] as controller and Mininet [8] as the testbed to evaluate the performance of our rule optimization method. Simulation results show using rule optimization, the flow table at switches have been more compact compared to simply installing rules and does not lose the performance.

The rest of the paper is organized as follows. In Section II, we introduce the architecture of SDIV. In Section III, we discuss the rule optimization issues and show how it works. We conduct extensive experiments and report our results in Section IV. In Section V, we review related works. We conclude the paper in Section VI.

Ii Network Architecture: Software-Defined IOV

In this section, we propose Software Defined Internet of Vehicles (SDIV) architecture and discuss its utility through real-time query service in IoV. Before introducing the architecture of SDIV, we describe the basic SDN model and its main features.

Ii-a Software Defined Networks (SDN)

The principal endeavors of SDN are proposed to separate the control plane from the data plane and centralize network’s intelligence and state to a single device. A SDN network consists of two parts: (1) switches process flows’ packets based on actions of flow entries in the Flow Table, (2) the controller generally runs on a remote commodity server and communicates over a secure connection with the switches using a southbound interface to add and remove flow entries from the flow table. A flow table consists of flow entries associated with actions that tell the switch how to process the flow. Each flow entry has an action associated with it: (1) Forward this flow’s packets to a given port so as to route packets through the network; (2) Encapsulate and forward this flow’s packets to the controller for installing rules; (3) Drop this flow’s packets. When a new switch joins the network, it will send a hello message to the controller. Then, the controller recognizes the switch and changes the network status appropriately. The controller interacts with the forwarding elements through the southbound interface. OpenFlow, a protocol maintained by ONF[9], can be viewed as a promising implementation of such an interaction. OpenFlow enables users to control data flows in the network by installing rules with matching fields and actions of processing packets at switches. In this work, we use OpenFlow as the intermediate protocol between the controller and switches.

Ii-B Software-Defined IoV (SDIV)

Our proposed SDIV network has a three-tier architecture. From bottom to top, they are physical layer, control layer and application layer, as illustrated in Figure 2.

Ii-B1 Physical Layer

In physical layer, it is the same as IoV with vehicles, APs, roadside electronic devices, switches and servers. Vehicles act as mobile nodes and communicate with the server through road-side APs. When sensors in a vehicle collect information about conditions of the vehicle (e.g. speed, direction and location), the data should be transmitted to the server as soon as possible. And vehicles should receive responses from the server through nearby APs (we assume that the number of road-side APs is much enough to cover every road). Road-side APs are static WiFi access points reachable from the road that offer the ability of data transmission to vehicles. Roadside electronic devices like surveillance cameras gather road conditions and also send data to servers or vehicles. Switches connect APs, surveillance cameras and servers. The server analyzes the data gathered from APs and vehicles for information services, such as traffic conditions, local map, car accidents and provides services for user requests. Location information of units in IoV should be in the form of coordinates given in longitude and latitude, which can be easily found with GPS. Multiple servers are available for vehicles retrieving data from appropriate server considering the work load and location of both vehicles and the server.

Ii-B2 Control Layer

In control layer, the controller connecting to every switches (including APs) acts as a coordinator for various services and data flows by installing rules at switches via OpenFlow Protocol. Switches forward any packet with no rule matched to the controller and then controller installs rules at the switches based on strategies pre-configured, and this enables the controller to control all data flows in IoV. When network status changed, the switches will notify the controller through OpenFlow Protocol. In this architecture, switches (including APs) act as connector between vehicles, servers and other roadside electronic devices by forwarding data flows based on rules. The controller has an up-to-date, global view of the network topology and traffic states, and provide the capability of customizing networks easily. Another important duty of the controller is abstracting the underlying network topology for the upper services, and providing network states to the applications in the upper layer. The abstract underlying topology should be suited to the application that each application has different purposes, in another word, different applications may have different views of the topology, and it does not need to provide whole network topology with all details to applications since they only care about a small part of the network topology. Also privacy and security are benefit from the abstract topology that enclosure the details of devices in the underlying network. The controller provides network states (i.e., link utility, the number of rules at switches and the number of flows at switches) to the applications in order to make the applications write their own strategies for their services implementation.

Ii-B3 Application Layer

The strategy of each application is defined in the application layer. Applications provide services for drivers in IoV, such as real-time query service, location service and road conditions service. Each application get the network states from control layer and make decision according to their strategies. The strategy here means how to provide service defined in the application to the clients (e.g., the vehicles). Such as real-time query service is to provide drivers the real-time conditions of roads and then drivers decide which way to go according to the information, then the topology of the network is necessary to compute the path for improving performance which we will give details in Section III. Applications also have abilities to install rules into the chosen switches by the interfaces provided from the control layer. The input of applications in this layer is the network states and the forwarded packets to invoke the application service, and the output of applications is the rules at selected switches.

Fig. 2: Three-tier architecture of SDIV with physical layer, control layer and application layer bottom up.

Ii-C SDIV operations and advantages

After introducing the components of SDIV, we describe how SDIV works through two scenarios in SDIV as depicted in Figure 3.

Fig. 3: Subfigure (a) shows a scenario that a vehicle want to get the information about road conditions maybe two or three blocks away from current location; Subfigure (b) depicts a scenario of data uploading through nearby AP to the server.

Figure 3 (a) describes a typical scenario where a vehicle wants to get the information about road conditions (maybe three blocks away from current location) via surveillance cameras.

In Step 1, the vehicle sends a request to a nearby road-side AP as shown in Figure 3 (a); in Step 2, since there is no rule matching the header of the flow’s first packet, the switch (AP ) encapsulates and forwards the packet to the controller; in Step 3, the controller recognizes the header and installs rules based on the vehicle’s requests and information (e.g., location, speed and direction) and also current network’s status; in Step 4, switches along the path towards the destination forward the matched packet to given ports based on the rules installed; in Step 5, the other side data flow, from the surveillance camera () to the vehicle, go through the same procedure as described in Step 2-4. When the number of vehicles increasing ( at appears), there needs a scalable approach in installing rules for data transmission. The conditions (e.g., directions) of vehicles also should be considered for installing rules (install rules at in advance).

Figure 3 (b) describes a scenario where the vehicles need to build connections between the server through nearby AP for data uploading such as their vehicles conditions.

We can classify road-side APs by centrality degree (if an AP is connected by more vehicles, then it has a higher degree) in the controller which has a global view of the network. Traffic engineering can be implemented based on the level of services and the centrality degree of APs using LP [10] which is not concerned in this work. As illustrated in Figure 3 (b), initially vehicles send data to the server. Then, in Step 1, the controller gathers the information from AP and (when the switches or APs receive the packets with no rule matching, they will send the packets to the controller) for computing their centricity degrees. In Step 2, the controller installs rules at switches according to the centricity degree. In Figure 3 (b), AP has higher degree than AP since there are more vehicles connecting to than , then we allocate more bandwidth for data flows coming from .

In addition, SDIV is more attractive when considering large-scale multicast and the mobility of vehicles. As the number of vehicles connecting to one camera increasing, it is easy to think of multicast for the efficiency of data transmission. Although dense-mode multicast (reasonable for cameras) goes well in small networks, as the range of data transmission increasing, the growing number of entries kept in APs (or switches) and broadcasting messages periodically for establishing SPT limit the scalability of data transmission. The mixed model of control and data plane makes it necessary to keep entries even not used currently at every routers for a fast graft. In Figure 3 (a), it is necessary to reserve entries at AP for a new coming vehicle . The mobility of vehicles also brings difficulty to traditional network technologies. Vehicle moving from to as described in Figure 3 (a) need to send another request for retrieving data, which results in interruption of data stream and moreover increases the work load of the surveillance camera (). In our design, we address the mobility problem by predicting the most possible path that the vehicles would choose and set the rules in flow tables advance to multicast the packets from nearby APs along the path. Multicast along the data transferred path in SPT can not satisfy the mobility issue since the shortest path for data transmission seldom matches the driving path.

Table 1 summarizes the benefits of SDIV against traditional network technologies (multicast) besides its open interfaces of network equipments. Compared to traditional multicast method that needs to broadcast messages periodically for establishing SPT, SDIV leverages the benefits of OpenFlow protocol that makes switches forward packets with no matching rule in flow table to the controller and then the controller installs rules for the packets, which is reactive mode and it doesn’t need to broadcast messages periodically. This reactive mode also makes is possible that the switches only need to keep the least number of rules in flow table against keeping entries at routers in traditional multicast method. With the support of the controller with an up-to-date, global view of the network topology and traffic states, it can compute the most possible path that the vehicles would choose and installs rules in advance for providing persistent connection between vehicles and the devices.

Traditional Technologies SDIV
Broadcasting messages periodically Reactive mode
Keeping entries at routers Installing rules when needed
SPT can not match the driving path
Finding the path according to
the direction of vehicles
TABLE I: Summary of benefits against traditional network technologies (multicast) in SDIV for location-based services

Iii Rule Optimization: Problem and Approach

Having described the overview architecture of SDIV and how SDIV works, we show more details about rule installation and explain that it could bring complexities if naively installing rules just for packets forwarding. In this section, we consider real-time query service as the context to explain the necessity of rule optimization.

In the real-time query service, if controller simply installs rules for the requests from drivers, the table size at switches will be the performance bottleneck since the limited size of flow table. When vehicles moving from one place to another, it needs to send another request packets which will be forwarded to the controller since there is no rule matching the packets. In this work, we assume that OpenFlow supported switches would select reactive mode that there is no rule at the beginning. The packets forwarded to the controller will lead to a serious computational bottleneck at the controller. Even if the controller’s computational capacity can scale, the bandwidth demand that every packets go through the controller may be impractical. As for the drivers, the delay caused by every packets forwarded to the controller is much larger than the directly forwarding to the destination devices. Hence, it is very important to decrease the number of packets forwarded to the controller both for the controller’s capacity and the drivers’ using experience. Besides the number of packets forwarded to the controller, the number of rules at the switches is another factor that influences the performance of network since the limited size of TCAM at the switches, hence it is important to produce a compact table to fit more cached policy decision at the switch. For each flow established, it needs two rules at the selected switches for sending the request packets and receiving the data packets from the destination, and even if we only consider the second data flow, since the request flow is only useful at the beginning and can be deleted by timeout entry in OpenFlow switches, it still need one rule for each flow. It seems that one rule for each flow is compact enough for flow table, but in reality drivers always connect to multiple surveillance cameras at the same time and compare all roads’ conditions then choose the best path. As a result, there needs to install rules for every data flow at every selected switches even though these flows all have the same destination. To summarize, we need to decrease the number of packets forwarded to the controller and establish a compact flow table since the limited size of TCAM at switches.

Figure 4 depicts the basic scenario that how real-time query service works. Suppose that vehicle wants to see the conditions of road (or crossroads) . Here, the conditions can be represented as video or any other kinds of data stored in the roadside devices. At the first step, sends a request to AP and then the data flow is forwarded to . After confirming the request from , starts to send data to AP . Finally, AP transmits the data to and completes the data transmission. The entire process is simple, but this simplicity may introduce performance lost if simply implemented. Consider the situation that when there is another vehicle also wants to get the information of , as shown in Figure 4. will follow the same procedure as does, and there is another path from to , which makes switch installed two rules following the same path. As a result, with the number of vehicles connecting to getting large, the size of flow table at switches along the path reaches the maximum, which reduces the performance of the service. Moreover, when moves to other place, it needs to send a request again.

Next, we consider another example to show the importance of rule optimization. wants to get the data from at the same time, then switch and need to install more rules to make data flow transmitted to , even though both flows ( and ) have a same destination. Situations will become more complex if vehicle joins. To make at receive data, there needs to build a new path which increases table size. The mobility of vehicles increases the complexity and reduces performance as well.

To address the problem, we propose an idea to separate the wireless data plane (for communication between vehicles and APs) from wired data plane (for communication among switches) and develop a destination-driven model (the details of destination-driven model are shown in the Section III-C) for the wired data plane. When vehicles receive data from nearby APs, they do not care how data transmitted in wired data plane, they just want a persistent connection though their locations change over time. To make the separation efficiently, we introduce three techniques: (1) using multicast address as the last hop address from cameras to vehicles, (2) installing rules in the most possible path in advance according to the conditions of vehicles, (3) modifying the headers when packets come to branching nodes.

Iii-a Multicast Address for the Last Hop

We utilize multicast address from traditional networks for the mobility and scalability in SDIV. Every surveillance camera has a unique multicast address which can be generated from MAC address as the same method in traditional networks. Multicast address can be used in the last hop from cameras to vehicles for data transmission in wireless data plane. Vehicle receives packets with the destination address of ’s multicast address in Figure 4. The advantage of using multicast address is apparent that every vehicles, within the range of an AP which has been equipped the rule, can get the real-time data without sending new requests. Furthermore, in real-time query service, the first packet of users’ requests have to be forwarded to the controller for installing rules. If every request needs to contact the controller for rule installation, it will lead to a serious bottleneck at the controller since the computational capacity and bandwidth are limited. A multicast address can address the problem efficiently. After the first vehicle connecting the camera with the intervention of the controller, the data flow will multicast around its location (along the path to the destination), and every new vehicle asking for the same camera can directly receive the data without sending the request, which reduces the frequency of contacting the controller. As the example in Figure 4, if there is another vehicle that wants to see the conditions of , it can receive the data without sending a request after vehicle sending the request.

Due to the limited size of TCAM in OpenFlow supported switches, we need to remove the useless rules from flow tables. In our design, we use timeout in OpenFlow protocol to delete rules for saving flow table resources. A switch maintains a per-flow-entry variable that indicates if there has ever been a period of seconds in which no packet arrived for the flow. In practice in OpenFlow, this is maintained by adding an ”idle timeout” value to a flow entry. Comparing to equal values of timeout, we choose selecting different values of timeout in switches depending on the distance away from the destination location. We make an assumption that the number of vehicles interested in the destination gets larger as they are closer to the destination, then we set larger values in timeout for the closer switches to the destination. As an example in Figure 4, the timeout value in switch has the constraint: , and in our design, we set the value in the equation: where means the distance between the destination and other location . For simplicity, the distance can be the hop count.

Fig. 4: is connecting to and simultaneously, and at the path of to asks the data from . also requires the data from but at the different path.

Iii-B Predict the Path and Install Rules in Advance

1:  Algorithm PathFind()
2:    put into set , ;
3:    for each child node of
4:      if the angle between and is less than 90 degree then
5:        put into set ;
6:    Find();
7:    return ;
9:  Procedure Find()
10:    put into set ;
11:    for each in
12:      if is then
13:        put into set ;
14:        finish;
15:      put into set ;
16:      remove from set ;
17:      calculate , ;
18:      if then
19:        ;
20:        ;
21:    put into set ;
22:    for each child node of
23:      if not in set then
24:        put into set ;
25:    Find();
26:    return;
Algorithm 1 PathFind()

To deal with the mobility of vehicles in SDIV, it is necessary to predict the most possible path that a driver will choose, and then install rules in advance along the path in order to keep data transmission uninterrupted when the vehicle moves. A simple method to predict the path is computing the shortest path, but it is not always a correct path in reality. Now, we describe , a simple algorithm shown in Algorithm 1 that finds the most likely path in topology. Here is the current location, is the destination and is the direction of the vehicle. denotes the vector of and , means euclidean distance between and .

As the preparatory work (Lines 3-5), filters the possible first node of result path according to the condition (e.g., direction) of the vehicle, since the driver seldom turn back in street. Then, we apply recursively to calculate the result path by choosing the node which has the minimum value of (e.g., the distance between the chosen location to destination) as shown in Lines 17-20. In current design, denotes euclidean distance between and , but we can change to a more intelligent calculation for a better result as the future work. Finally, the identifies the destination as the next node and return the result (Lines 12-14).

We apply in Figure 5. The vehicle in location plans to find a path to . First it puts into set according to the direction of the vehicle in the current location, then it finds has a shorter path to compared with . It chooses to start again, and finds that directly connects to and finishes. The result is more reasonable than the shortest path since reversing a vehicle is rarely seen in reality. Though the delay of path is prolonged comparing to path , the vehicle should send more requests when it find there is no data from nearby AP. In this case, the vehicle more likely choose as its next location, then the result path is better than the shortest path since the vehicle can receive data without sending another request. In Figure 4, after installing rules at the switches along the predicted path (), the multicast address also makes receive data without sending a new request.

Iii-C Modify Address in Branching Nodes

1:  Algorithm ModifyAddress()
2:    for each node in do
3:       = the next node of ;
4:       = false;
5:      for each rule in do
6:         = the node connecting the output port of ;
7:        if matching and != then
8:           = forward to and modify the destination address to ;
9:          ;
10:           = true;
11:        else if matching and = then
12:           = true;
13:      if == false then
14:         = forward to ;
15:        ;
16:    return;
Algorithm 2 ModifyAddress()

To achieve a scalable and efficient scheme for routing packets in a wired network, we propose an address modification method compared with traditional technologies unicast or multicast by leveraging the properties of OpenFlow as shown in Algorithm 2. The input implies the source of data, implies the current location of the vehicle and is computed by . We clarify that the rule matching means that the controller records the source address of every request, not the rule in switch matches . By using our modifying address algorithm, we let packets with different source address but the same destination address match the same rule and hence decreases the number of rules and save the size of flow table (e.g., destination-driven model). Modifying the destination address of packets in branching nodes by leveraging the properties of OpenFlow is for the correctness of the algorithm. As an example shown in Figure 6, data flow and are both generated from surveillance camera , and data flow comes from surveillance camera . is requested from vehicle . , are destined to . Suppose that ’s current location is and is at , data flow and need at least two rules at switches and (and if any switches between them) in unicast, and flow and need two rules at least at switches and (and if any switches between them) in multicast, which is not efficient since and come from the same node, and and have the same destination. We modify the destination address in the header of packets in switch (as a branching node) for and . By setting the destination address of packets in and (, ), the number of rules in switches will be reduced and it save the size of Flow Table for more services. As an example, we assume that sends a request for data from first. sends data flow with destination address in packets header. At this moment, it only needs one rule at each switch. When asks data from , the rules at switches still suit. Finally, when requires data from , it just increases one rule at switch with matching with an action of modification. The header of packets can be represented by using two parameters, namely , so are the match conditions in Flow Table. This destination-driven mode emphasizes destination address as matching conditions in Flow Table, and generalizes the data flow demands of the same destination for reducing the size of Flow Table at switches. In Figure 4, when joins, it needs address modification at the branching switch for rule optimization.

Fig. 5: The blue dash line is the shortest path between the current location and destination, while the red dash line is a more likely path that the vehicle may choose according to the direction.
Fig. 6: Data flow (red line) comes from and its destination is ; Data flow (blue line) comes from and its destination is ; Data flow (green line) comes from and its destination is . The matching conditions only depend on the destination address.
Fig. 7: Subfigure (a) shows a 1 to 1 pattern that wants to receive data from ; (b)shows a N to 1 pattern that and want to receive data from ; (c)shows a 1 to N pattern that wants to receive data from and at the same time; (d) shows a N to N pattern that wants to receive data from and while wants to receive data from .

Iii-D Examples

In this section, we will give four examples to show how our scheme works and then describe the details about rules installed at switches. By analyzing the process of data transmission in real-time query service, we summarize four patterns as shown in Figure 7.

Iii-D1 1 to 1 case

In the simplest situation, there is only one vehicle asking for real-time query service from one surveillance camera. As shown in Figure 7 (a), vehicle sends a request to camera and then receives data flow coming from . Therefore, the packets generated from is , and match conditions at , are both . The packets multicast at is where is multicast address of . In this scenario, the path found by is , which is the most likely path that the driver would choose. Then we install rules for multicast with at previously. When the vehicle arrives to , it can receive data without interruption.

Iii-D2 N to 1 case

When a camera connecting to multiple vehicles, there needs to modify the destination address at the branching nodes (like in Figure 7 (b)). The cost of modification would not be large since it is a necessary work to copy the packet, and the address for modifying can be preserved at switches. The buffer inconsistency problem can not happen since modification is carried out at switches, and the rules must be installed before data flows arriving. At the beginning, sends packets since vehicle at requests faster than at . When sends a request, the controller (not shown in this figure) installs a new rule with a modification action (can be implemented in OpenFlow). As a result, switch forwards two packets and to different ports. The data flows forwarded (by AP) at , and are all .

Iii-D3 1 to N case

A vehicle may connect to multiple cameras simultaneously. As descried in Figure 7 (c), vehicle wants to receive data from and at the same time. The packets generated from and are and . At switches and , the matching conditions are both . There only needs rule to meet the requirements for different packets. When the packets come to , the rule matches the packets and then forwards to . The switch will follow the same procedure as . and also need to change the destination address of the packets for multicast. The packets for multicast at and are and , where and are the multicast address.

Iii-D4 N to N case

We combine the 1 to N and N to 1 for a more common scenario N to N in Figure 7 (d). Vehicle requests real-time data from and , and requests data from only. There needs a modification at just for packets matching , since is a branching node when data source transfers packets to and at the same time. The packets coming from are just forwarded to the given port without any modification.

The N to N scenario is a general case that give details about how to implement rule optimization. Furthermore, we can observe that the theoretical upper bound of the table size of the proposed rule optimization approach is related with the number of devices which the driver is connecting to at the same time. denotes the number of devices, denotes the number of rules for the traditional approach and denotes the number of rules for the proposed rule optimization approach, then we have is the upper bound of the table size we save. In this case, there are all devices connecting to the same switches.

Iv Performance Evaluation

Iv-a Testbed

We use Floodlight[7] as the controller and Mininet[8] to build a SDN environment to testify rule optimization strategy in SDIV. We run Floodlight on a server, with 16 AMD Opteron(tm) processor 6172 and 16G memory. Our server software includes Linux kernel version 2.6.32. We run Mininet on a separate server and servers are connected by a 10Gbps Ethernet network.

Iv-B Effects of Rules Optimization

We use the real data of traveling trace in Shanghai [11] as a common scenario to show the benefit of rule optimization. Figure 8 (a) shows a snapshot around People’s Square in Shanghai. Traveling traces of vehicles are composed of GPS data at different times. At the first time (), there are only five vehicles in this area. At , there are another two vehicles join. At , vehicle appears in the area. The appearance time and disappear time of vehicles are illustrated in Figure 8 (b). Interval time between any two moments is 120 seconds. We make any mark belong to the same moment if the difference between their timestamps and the moments is shorter than 30 seconds. Although these GPS marks at the same moment may not have exactly the same timestamp, it can roughly say that these vehicles move to these locations very closely at that moment by limiting the difference between the timestamp of GPS marks and the time of moments to a certain range. In this case, we set it to 30 seconds to ensure that every GPS mark can reflect the real location at that moment.

Figure 8 (c) is a sketch map of Figure 8 (a). Arrow lines with different colors illustrate the directions of vehicles according to the order of these timestamps in GPS marks as shown in Figure 8 (a). We assume that there is always one road-side AP (switches in Figure 8 (c)) around the GPS marks for data transmission available at any time. We make every vehicle in sketch map have a data transfer demand at the first moment they appear. Therefore, and near the intersection of line 8 and line 2 want to receive data from both and , and also have the same path along line 8. locating on the convergence of Beijing E Rd and Fujian Middle Rd also has demands of receiving data from and . , and have the same target but choose different paths. asks the data from . has the target only. All these vehicles require a persistent data flow service until they move to their destinations. Then we need to install rules at every necessary switches for their requirements. Simple installation which we compared with is a general method forwarding packets to given ports based on the source address. By rule optimization, it will merge the rules which have the same destination (destination-driven mode) in 1 to N pattern like connecting to and , and modify headers of packets at branching nodes in N to 1 pattern. The result is shown in Figure 8 (d). The decreasing at is because of the timeout in rules we set. Figure 8 (e) shows the number of vehicles at different moments. Figure 8 (f) shows the delay time of different vehicles in two strategies. The delay time we evaluate here is the longest one if a vehicle connects two cameras at the same time (we choose instead of for evaluating ’s delay time). And we can see from Figure 8 (f) that our rule optimization strategy hardly influences the performance of data transmission though it needs address modification in the header of packets. By rule optimization, it reduces the number of rules and saves the space at Flow Table for scalability.

(b)    (c)
(d) (e)
Fig. 8: Subfigure (a) shows a snapshot around People’s Square in Shanghai; (b) shows the appear and disappear time of vehicles; (c) is a sketch map of (a) with the direction of vehicles; (d) shows different number of rules for two strategies; (e) shows the number of vehicles at different moments; (f) shows the delay time of vehicles in two strategies.

Iv-C Analysis

We study the two patterns (1 to N and N to 1) in details and show how they influence results differently. We compare the number of rules and the delay time with simple installation to show that it does not affect the performance of data transmission. Figure 9 (a) shows N to 1 mode that there are multiple vehicles connecting to one surveillance camera (). We pick which has the longest path to evaluate delay time. It means every packet transferred from to will modify the headers (destination IP address) at each switch and then forward to the next switch. And we compare our method with the simple installing that every packet just forwards to given ports without modifying the header. Figure 9 (b) shows that, as the switch number increasing, delay time of both methods get large but have little difference between each other. The packet modification process in rule optimization strategy barely influences the performance. Figure 9 (c) shows the number of rules at switches. The black line represents simple installing mode that node transfers data flow across networks to every node at the same time. Therefore, there only needs one rule at each switch with and means the multicast address. The red line depicts rule optimization strategy that we modify the destination address at every branching node and then forward the packets to given ports. There also needs only one rule at each switch comparing to simple installing mode.

Figure 9 (d) shows 1 to N patten that the vehicle connects to multiple cameras () at the same time. Figure 9 (e) shows the delay time according to the different number of switches. Without rule optimization, there need three rules for each source node at each switch, , which is a source-driven mode (forwards packets based on data source). In our rule optimization strategy, there only needs one rule, , at each switch and it still support N to 1 pattern as discussed above. Figure 9 (f) shows the number of rules and our method has a more compact rule table than simple installing mode.

We draw two conclusions from the result. First, the modification of packets at branching nodes has little impact on the performance of data transmission. Second, for the best case of rule optimization (1 to N), the number of reduced rules is proportional to the number of data sources, and even for the worst case of rule optimization (N to 1), the number of rules at switches is equal to that of simple installing mode which just forwards packets to different ports without any strategy.

(a) (b) (c)
(d) (e) (f)
Fig. 9: Subfigure (a) shows a topology of N to 1 mode; (b) shows delay time on different number of switches in (a); (c) shows number rules on different number of switches in (a); (d) shows a topology of 1 to N mode; (e) shows delay time on different number of switches in (d); (f) shows number rules on different number of switches in (d)

V Related Work

To the best of our knowledge, SDIV is the first architecture that combines IoV with SDN by using a centralized controller to manage the network devices. Hence, there is rarely related research work and most we list are either related to vehicular networks or SDN. Most applications and services (road security, fleet management, navigation, billing, multimedia, etc) in IoV rely on data exchanged between the vehicle and the roadside infrastructure (V2I) and between vehicles (V2V) [12]. Several research works [13][14] have demonstrated the feasibility of providing connectivity via road-side APs and the ubiquity of WiFi.The studies [15][16][17] deal with the efficient communication between APs and vehicles. In [18], the authors propose a novel system design and implementation for realtime reliable roadway communications, for providing safety messages to users in a realtime and reliable manner. For routing and data forwarding, there are [19][20][21][22] that study the routing protocol and fast forwarding. To manage vehicular networks, a centralized policy framework is introduced in [23], Virtuoso, that manages spectrum resources while ensuring users have suitable access for their communication needs. In [24], the authors focus on content downloading in vehicular networks. Paper [25] presents the Road Information Sharing Architecture (RISA), the first distributed approach to road condition detection and dissemination for vehicular networks.

To establish a new architecture in vehicular networks, Named Data Networking is applied to networking vehicles and enables networking among all computing devices independent from whether they are connected through wired infrastructure, ad hoc, or intermittent Delay Tolerant Network in [26]. In [27], the authors present an OpenFlow [28] Wireless networks to achieve a free travel between any wireless infrastructures by separating the network service from the underlying physical infrastructure.

In the area of software-defined network, SDN is applied to improve network management in [29]. For rule optimization, a distribution framework is proposed for decomposing large switch tables into small ones to address limited size of switch tables [30]. In [31], the authors introduce Maple to discover reusable forwarding decisions and reduce the number of rules by a trace tree structure that records access on a specific packet. A centralized traffic engineering with SDN has been proposed in [32] and [33] with the idea of classifying the services based on their performance requirements.

Vi Conclusion and Future Work

This paper proposes a new architecture SDIV to address the issues of the proprietary and closed way of operating hardwares in network equipments, which slows down the progress of new services deployment and extension in IoV. But, simple installation of rules is not efficient since the characteristics of IoV. Rule optimization is necessary in SDIV. Our rule optimization method can reduce the size of Flow Table but not degrade the performance of data transmission. The separation of wired data plane from wireless data plane and the destination-drive mode are suited well for the characteristic of SDIV. Evaluation shows that our rule optimization strategy reduces the number of rules without losing the performance of data transmission.

In our future works, we plan to address flowing issues:

(1) We assume that there is no limitation in the capacity of switches, which means that the performance of data transmission does not degrade as the number of vehicles connecting to one camera increasing. Actually, it is necessary to design an allocation mechanisms for controlling data flows based on the whole network status.

(2) The controller should gather geographic information around the switches (APs) for making further decisions. This is an important work in reality. We will consider an efficient interface such as letting switches uploading their conditions at regular intervals.

(3) We only considered real-time query service in this work. As a future work, it is necessary to investigate data uploading service and achieve a coordinator between the different services based on the performance demands. This includes identifying the conditions of switches and the service types of data flows.


  • [1] “CVIS.”
  • [2] H. Makino, “Smartway project,” Development, vol. 2005, 2005.
  • [3] “NDN.”
  • [4] “MobilityFirst.”
  • [5] “NEBULA.”
  • [6] “XIA.”
  • [7] “Floodlight.”
  • [8] “Mininet.”
  • [9] “Open Networking Foundation.”
  • [10] E. Danna, S. Mandal, and A. Singh, “A practical algorithm for balancing the max-min fairness and throughput objectives in traffic engineering,” in Proc. IEEE INFOCOM 2012.
  • [11]
  • [12] T. Ernst, “The information technology era of the vehicular industry,” ACM SIGCOMM Computer Communication Review, vol. 36, no. 2, pp. 49–52, 2006.
  • [13] J. Ott and D. Kutscher, “A disconnection-tolerant transport for drive-thru internet environments,” in Proc. IEEE INFOCOM 2005.
  • [14] A. Balasubramanian, R. Mahajan, A. Venkataramani, B. N. Levine, and J. Zahorjan, “Interactive wifi connectivity for moving vehicles,” ACM SIGCOMM Computer Communication Review, vol. 38, no. 4, pp. 427–438, 2008.
  • [15] A. U. Joshi and P. Kulkarni, “Vehicular wifi access and rate adaptation,” ACM SIGCOMM Computer Communication Review, vol. 41, no. 4, pp. 423–424, 2011.
  • [16] B. B. Chen and M. C. Chan, “MobTorrent: A framework for mobile Internet access from vehicles,” in Proc. IEEE INFOCOM 2009.
  • [17] F. Xu, S. Guo, J. Jeong, Y. Gu, Q. Cao, M. Liu, and T. He, “Utilizing shared vehicle trajectories for data forwarding in vehicular networks,” in Proc. IEEE INFOCOM 2011.
  • [18] K. Xing, T. Gu, Z. Zhao, L. Shi, Y. Liu, P. Hu, Y. Wang, Y. Liang, S. Zhang, Y. Wang et al., “Approaching reliable realtime communications? A novel system design and implementation for roadway safety oriented vehicular communications,” in Proc. IEEE INFOCOM 2013.
  • [19] Y. Li and W. Wang, “Horizon on the move: Geocast in intermittently connected vehicular ad hoc networks,” in Proc. IEEE INFOCOM 2013.
  • [20] L. Zhang, B. Yu, and J. Pan, “GeoMob: A Mobility-aware Geocast Scheme in Metropolitans via Taxicabs and Buses,” in Proc. IEEE INFOCOM 2014.
  • [21] I. Leontiadis, P. Costa, and C. Mascolo, “Extending access point connectivity through opportunistic routing in vehicular networks,” in Proc. IEEE INFOCOM 2010.
  • [22] H. Zhu, M. Dong, S. Chang, Y. Zhu, M. Li, and X. Sherman Shen, “Zoom: scaling the mobility for fast opportunistic forwarding in vehicular networks,” in Proc. IEEE INFOCOM 2013.
  • [23] J. Hare, L. Hartung, and S. Banerjee, “Policy-based network management for generalized vehicle-to-internet connectivity,” in Proc. ACM SIGCOMM 2012 workshop on Cellular networks: operations, challenges, and future design.
  • [24] F. Malandrino, C. Casetti, C. Chiasserini, and M. Fiore, “Content downloading in vehicular networks: What really matters,” in Proc. IEEE INFOCOM 2011.
  • [25] J. Ahn, Y. Wang, B. Yu, F. Bai, and B. Krishnamachari, “Risa: Distributed road information sharing architecture,” in Proc. IEEE INFOCOM 2012.
  • [26] G. Grassi, D. Pesavento, G. Pau, R. Vuyyuru, R. Wakikawa, and L. Zhang, “VANET via Named Data Networking,” in Proc. NOMEN Workshop of IEEE INFOCOMM 2013.
  • [27] K.-K. Yap, R. Sherwood, M. Kobayashi, T.-Y. Huang, M. Chan, N. Handigol, N. McKeown, and G. Parulkar, “Blueprint for introducing innovation into wireless mobile networks,” in Proc. ACM SIGCOMM 2010 Workshop on Virtualized Infrastructure Systems and Architectures.
  • [28] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner, “OpenFlow: enabling innovation in campus networks,” ACM SIGCOMM Computer Communication Review, vol. 38, no. 2, pp. 69–74, 2008.
  • [29] H. Kim and N. Feamster, “Improving network management with software defined networking,” IEEE Communications Magazine, vol. 51, no. 2, pp. 114–119, 2013.
  • [30] Y. Kanizo, D. Hay, and I. Keslassy, “Palette: Distributing tables in software-defined networks,” in Proc. IEEE INFOCOM 2013.
  • [31] A. Voellmy, J. Wang, Y. R. Yang, B. Ford, and P. Hudak, “Maple: Simplifying SDN programming using algorithmic policies,” in Proc. ACM SIGCOMM 2013.
  • [32] C.-Y. Hong, S. Kandula, R. Mahajan, M. Zhang, V. Gill, M. Nanduri, and R. Wattenhofer, “Achieving high utilization with software-driven WAN,” in Proc. ACM SIGCOMM 2013.
  • [33] S. Jain, A. Kumar, S. Mandal, J. Ong, L. Poutievski, A. Singh, S. Venkata, J. Wanderer, J. Zhou, M. Zhu et al., “B4: Experience with a globally-deployed software defined WAN,” in Proc. ACM SIGCOMM 2013.
Comments 0
Request Comment
You are adding the first comment!
How to quickly get a good reply:
  • Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
  • Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
  • Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
The feedback must be of minimum 40 characters and the title a minimum of 5 characters
Add comment
Loading ...
This is a comment super asjknd jkasnjk adsnkj
The feedback must be of minumum 40 characters
The feedback must be of minumum 40 characters

You are asking your first question!
How to quickly get a good answer:
  • Keep your question short and to the point
  • Check for grammar or spelling errors.
  • Phrase it like a question
Test description