Sage Journals: Discover world-class research

Abstract

Internet of Vehicles has become a promising way to realize the evolution from vehicular ad hoc networks and next-generation intelligent transportation system into future autonomous driving scenarios, clean-energy intelligent vehicles, and Smart Cities. However, multicasting service messages on available service channels and periodic exchanges of beacon messages on control channel cause the problem of efficiently scheduling those messages via multichannel transmission for intelligent vehicle terminal, to support real-world applications in Internet of Vehicles scenario. In this article, we investigate the intelligent vehicle terminal architecture and, particularly, design the wireless communication board by incorporating multicasting and congestion control modules. Especially, we present a multicast data delivery scheme with random-delay lowest-cost constraint to transfer service messages on service channels. Furthermore, a priority-aware congestion control scheme is also proposed by considering differentiated priorities of beacon messages on control channel, to cope with the congestion problem at bottleneck vehicle node. Based on the proposed schemes, we build up the RanLow (Random-delay Lowest-cost) module and the priority-aware congestion control (PARCEL) module by enabling multicasting and congestion control together in wireless communication board of the intelligent vehicle terminal architecture. Finally, the experimental results and comparison show that our devised RanLow module and PARCEL module are feasible and more efficient than existing schemes.

Keywords

Internet of Vehicles intelligent vehicle terminal multicasting congestion control multichannel transmission

Introduction

Problem and motivation

As an emerging vehicle-oriented mobile Internet of Things (IoT), Internet of Vehicles (IoV) provides a dynamic mobile communication system that communicates with its internal and external environment by creating the interactions of vehicle-to-sensor, vehicle-to-vehicle, vehicle-to-road infrastructure, vehicle-to-Internet, and so on.^1–3 With the help of on-board units (OBUs) or on-board sensors installed on vehicles and road-side units (RSUs) deployed along the sides of roads or highways, IoV is highly characterized by gathering, sharing, processing, computing, and secure release of data services onto information platforms.² Compared with traditional intelligent transportation system (ITS), IoV puts more emphasis on expanding interactions and connections among vehicles, drivers, passengers, and RSUs, aiming to accommodate for fifth generation (5G)-enabled vehicular networks.⁴ To this end, the primary goal of IoV is to make drivers obtain the real-time road traffic information easily, to improve the road safety for drivers, to provide passengers with the travel convenience and comfort, to enjoy the existing Internet-based services (e.g. video conference, gaming, content sharing, and Web surfing), and to further benefit from big data applications through fog computing.^5–7 In addition, IoV can be also deemed to a superset of vehicular ad hoc networks (VANETs). The network scale, structure, and applications of VANETs are also been extended by IoV. It goes without saying that IoV has become a promising way to realize the evolution from VANETs and next-generation ITS into future autonomous driving scenarios,⁷ clean-energy intelligent vehicles,⁸ and Smart Cities.⁹

From the perspective of vehicular communications, dedicated short-range communication (DSRC) service has been developed as a set of protocols and standards used for VANETs operating at a frequency range from 5.850 to 5.925 GHz dedicated for road safety and traffic efficiency. To provide DSRC service, both American and European standards have adopted wireless access in vehicular environments (WAVE) or IEEE 802.11p as PHY and MAC layers via carrier sense multiple access with collision avoidance (CSMA/CA).^10–12 In WAVE, each vehicle periodically switches on control channel (CCH) to disseminate control and safety-related messages with high priority toward all surrounding vehicles through single-hop broadcasting and then tune into one of available service channels (SCHs) to exchange all the other low priority service messages. In this way, the joint use of CCH for safety-related messages and SCHs for service messages will necessitate the multichannel transmission in vehicular communications. As a significant IoV entity, intelligent vehicle terminal (IVT) is an intelligent embedded vehicle-carried OBU system installed on vehicles in IoV scenario. The vehicles equipped with IVT system collect vehicular status information, sense road situation and environment, and also acquire real-time location information of vehicles by adopting the emerging wireless technologies such as IoT, DSRC, long-term evolution/fourth generation (LTE/4G) mobile communications, and GPS/BDS navigation and positioning system. Moreover, IVT system can be further developed for meeting the drivers’ real-life needs of eating, living, traveling, shopping, and entertainment by means of interaction and display functions.

Recall that the purpose of real-world applications toward IVT system or even IoV is to provide drivers and passengers with Internet-based services along with some new types of services on SCHs dedicated to highly mobile environment via DSRC technology. A large number of applications as described above require multicast communications in IoV scenario where multicasting data packets of service messages will be delivered or addressed to a group of destination vehicle nodes simultaneously (i.e. one-to-many or many-to-many distributions).^13–15 Apart from traditional multicast applications, IVT system together with IoV can also allow emerging new applications in multicast data delivery (MDD) involving fleet management and point of interest distribution.¹³ It is discovered that the use of MDD on SCHs in IVT system can effectively organize network resources, save bandwidth consumption, reduce network congestion, and ensure load balance of data traffic. Most importantly, IoV and VANETs should also offer a large number of safety applications with high priority, including autonomous lane change maneuver, forward collision warning, traffic signal violation, emergency brake lights, and so on.^16–18 By the aid of IVT system and RSUs in IoV scenario, safety applications use beacon messages that are based on periodic message exchanges of single-hop broadcast packets (also known as cooperative awareness messages) on CCH.¹¹ The periodical exchange of beacon messages on CCH among IVT system and RSUs will make vehicles aware of their surroundings and will also be exploited by higher layer protocols and applications. Accordingly, this operation will help to significantly improve road safety, traffic efficiency, and even driving comfort. Unfortunately, high transmission power and rapid mobility of each vehicle node in IoV scenario cause regions of node density to form quickly.¹⁹ In such situations, similar to terrestrial wireline Internet or most other traditional wireless networks, network congestion in IoV scenario will also occur when aggregated data load exceeds available capacity of vehicle node due to buffer overflow caused by accumulated periodic beacon messages on CCH. It, therefore, results in performance degradation for safety applications in IoV scenario including beacon message losses, aggressive retransmissions, queuing delay, and blocking of new sessions, which will further decrease quality of service (QoS) and reliability of safety applications. Indubitably, congestion control technique should be conducted on CCH to reduce beacon message drops, to enhance network fairness, to balance resource load, and to avoid excessive congestion. From above discussions, we can find that the multichannel transmission of multicasting service messages on SCHs and periodic exchanges of beacon messages on CCH for IoV scenario becomes highly valuable. This motivates us to reinvestigate how to realize the multicasting and congestion control (MAC²) for IoV scenario from the IVT system perspective.

Related works

Design and development of IVT system have attracted much attention around research community, although the mainstream research efforts are aimed at the protocols and algorithms within the layered architecture of IoV.^1,7,20 In the literature, IVT system in IoV environment was mainly devised according to different application scenarios, such as intelligent transportation,²¹ logistics and cargo transportation,^22,23 forestry monorail car,²⁴ and engineering equipment.²⁵ Xu and Li²¹ presented the hardware design and software flowchart of an embedded vehicle terminal, with the capability to achieve high reliability, low power consumption, stable performance, and easy extensibility. Li et al.^22,23 proposed two vehicle terminal systems which can realize collaborative awareness, continuous monitoring and precise localization of vehicles for logistics and cargo transportation by employing context-aware computing. Yang et al.²⁴ designed an embedded wireless forestry monorail car control system with the object to achieve long-distance’s real-time monitoring and control the monorail car. Tu et al.²⁵ proposed a vehicle intelligent terminal system for engineering equipment by taking into account condition monitoring, fault diagnosis, time-based maintenance intelligent management, and long-distance operation management synthetically. A main drawback of those developed IVT system^21–25 is that they did not consider how to deal with multicasting service messages on SCHs coupled with periodic exchanges of beacon messages on CCH for IoV scenario. In other words, from a practical application perspective, both MAC² functions and modules were not incorporated into the IVT architecture.

From a theoretical study perspective, several studies on MDD or multicast routing for IoV scenario and VANETs were undertaken recently, including Internet-based multicasting,^13,14 trajectory-based multicast,²⁶ spatiotemporal multicast,²⁷ QoS-constrained multicast routing,²⁸ and cognitive multicast routing.²⁹ Jemaa et al.^13,14 proposed an extended membership management and mobility-aware tree-based multicast message dissemination protocol, to enable Internet-based multicast services on top of VANETs. Jeong et al.²⁶ devised a trajectory-based multi-anycast forwarding scheme for achieving efficient MDD in vehicular networks. Moreover, a multicast tree per packet was well constructed to minimize overall multicast delivery cost or delivery delay. Chen et al.²⁷ presented a spatiotemporal multicast protocol to support the spatiotemporal coordination in VANETs. In the context of QoS-constrained multicast routing, Zhang et al.²⁸ modeled multicast routing as the continuous optimization problem to maximize network lifetime and minimize communication cost. A micro–artificial bee colony algorithm was further proposed to deal with this continuous optimization problem. Kim and Gerla²⁹ presented a cognitive multicast protocol by applying the cognitive ability of vehicle nodes for VANETs. In addition, the effect of adjacent channel interference and narrowband interference was mitigated by exploiting orthogonal frequency-division multiplexing (OFDM) technique. To the best of our knowledge, there also has been some theoretical research efforts in congestion control strategies for VANETs or vehicular communications, namely, QoS and driving context awareness,¹⁹ cross-layer model,¹² beaconing rate control with different transmit power,³⁰ statistical approach to transmit power control,³¹ environment- and context-aware approach,³² and so on. Zhang and Valaee¹⁹ formulated the transmission probability of vehicle node under a slotted p-persistent vehicular broadcast MAC protocol as a classical network utility maximization (NUM) problem to reach a fair distribution of available wireless resources. Jabbarpour et al.¹² presented a cross-layer congestion control model by jointly considering prioritized event-driven messages and channel load threshold assignment in VANETs. Egea-Lopez and Pavon-Marino³⁰ transformed the beaconing congestion control problem for vehicular networks as a NUM rate allocation problem, to maximize the number of beacons delivered at each transmit power. A statistical approach was also introduced by Egea-Lopez et al.³¹ aiming to conduct transmit power control for beaconing congestion control, complying with the given maximum beacon load. Aygun et al.³² proposed an environment- and context-aware decentralized congestion control algorithm that combines power and rate control to improve cooperative awareness by adapting to propagation environments for vehicular communications. Although that the theoretical studies has made impressive progress in multicasting^{13,14,26–29} and congestion control^{12,19,30–32} for IoV scenario and VANETs, our work differs from them based on two points. First, their performance evaluations were to optimize one or several objectives through extensive computer simulations under the given parameter settings. However, our work is to conduct system design and hardware implementation of MAC² modules with multichannel transmission, and use these modules to attain experimental data via extensive static tests. Second, those authors mainly focused on investigating the strategies and protocols under the limitation of IoV scenario and VANETs. We study this problem from the IVT architecture perspective and focus on the interactions between the IVT architecture and MAC² modules.

Contributions and organization

In this article, our goal is to figure out how to deal with multicasting service messages on SCHs coupled with periodic exchanges of beacon messages on CCH for IoV scenario. To achieve this goal, we revisit the IVT architecture and particularly design the wireless communication board (WCB) by incorporating MAC² modules. Under the framework of the IVT architecture, our work mainly concentrates on the system design and hardware implementation of MAC² for IoV scenario owing to its significant impact on network performance. It once again goes without saying that the multichannel transmission of beacon messages on CCH along with service messages on SCHs are fully achieved by enabling MAC² together in IVT system. To summarize, the contributions of our work are as follows:

We propose an MDD scheme with random-delay lowest-cost (RDLC) constraint to transfer service messages on SCHs. In this scheme, a multicast tree with the minimum tree cost is constructed using the delay-based Dijkstra algorithm to compute the multicast tree with shortest paths. Further, a random-delay control strategy is formulated to dynamically regulate the transmit time of Reply packet for destination vehicle node, aiming to reduce the collision probability of multicast data packet transfers.

A priority-aware congestion control (PARCEL) scheme is proposed by giving more insights into differentiated priorities of beacon messages for safety applications on CCH when the congestion occurs at the possible bottleneck vehicle node. We define a time and distance coupling function to describe the priority of beacon message with a certain type. This scheme relies on this coupling function as well as perfect interaction between congestion control policy and two control messages. In addition, we use a receiver-level value to characterize the selection metric of optimal neighbor vehicle node as the receiver of beacon messages.

We employ the proposed MDD scheme into the design of the MDD module and build up the RanLow (Random-delay Lowest-cost) module and its prototype system in WCB board of the IVT architecture. In addition, the PARCEL module and its prototype system are also constructed in WCB board. We evaluate the performance of the devised RanLow module and PARCEL module through extensive static tests.

The remainder of this article is organized as follows. The IVT architecture is introduced in section “IVT architecture.” Section “System model” describes the system model. In section “Enabling MAC² in IoV scenario,” we propose the enabling schemes for MAC². Section “System design and experimental results” introduces the system design of RanLow module and the PARCEL module for IVT system and further demonstrates the experimental results. Finally, section “Conclusion and future work” concludes this article and discusses the future work.

IVT architecture

As an intelligent vehicle-carried OBU system, IVT system is installed on vehicles which can be used for different transport services and personal real-life needs of drivers and passengers. Beyond this, it can be also devised to provide the realistic applications through multichannel transmission including: (1) MDD applications on SCHs with the purpose of achieving better network performance and obtaining particular demands with service messages; (2) safety applications via periodic beacon message exchanges on CCH, aiming to improve road safety, traffic efficiency, and even driving comfort. In addition to traditional function modules as depicted in the literature,^21–25 IVT system could also have an MDD module and a congestion control module from an architecture perspective. Based on this motivation, we intend to build the IVT architecture by taking into account more realistic multicasting services and congestion control mechanism for specific applications via multichannel transmission. Specifically, the IVT architecture as shown in Figure 1 is devised on the basis of the ARM Cortex-A9 MPCore as a microcontroller unit (MCU) that is one multicore processor providing up to four cache-coherent cores, supporting the following core function boards:

WCB. To realize the wireless communication functions encompassing navigation/positioning services, mobile communications/wireless access, MDD services, congestion control with safety applications, and so on, the WCB consists of a GPS/BDS module, an LTE/4G module, an MDD module, and a congestion control module, which can connect to the MCU by adopting the universal asynchronous receiver/transmitter (UART) port.

Sensing Board (SB). The SB is responsible for detecting, collecting, and processing information by means of several in-vehicle sensors that connects IVT system. The information will be transferred through the general-purpose input/output (GPIO) pins at run time. In the SB, the in-vehicle sensors include speed sensor, microwave detection, radio-frequency identification (RFID), vehicle monitoring, infrared sensing, and camera, in order to acquire various kinds of sensing information about intelligent vehicle environment awareness.

Multimedia Board (MB). The interaction/display services offered by peripheral devices (i.e. human interface devices) through the MB should be connected to the MCU via the UART port. Particularly, a large number of peripheral devices communicate with the MCU via serial point-to-point connections. Connecting these peripheral devices to the MCU requires the use of interfaces that transfer serial signals to bus protocols and vice versa. The interaction and display module in the MB allows for the use of either an RS232 or an RS485 serial interface, which helps to simplify IVT system configuration.

Memory and File Board (MFB). The MFB is devised to provide memory/file services through controllers comprising dynamic random-access memory (DRAM), internal random-access memory (RAM), NAND flash, Serial Read-Only Memory (SROM), and so on, which will be connected to the MCU directly or with the help of the flexible static memory controller (FSMC). Technically, the FSMC supports external memory via NAND Flash Controller and SROM controller.

Power Board (PB). The PB is in charge of power supply for each function boards and the MCU of IVT system.

Figure 1.

Intelligent vehicle terminal architecture.

System model

We consider a bidirectional network topology of IoV scenario as depicted in Figure 2, wherein a number of RSUs are uniformly distributed along the side of straight road segment with length $h$ in meters. The RSUs are assumed to be spaced by the length of $ε$ in meters, with the radio coverage radius of about $ε / ε 2 2$ . Under the IVT architecture, each vehicle is equipped with IVT system that is responsible for the communication with other vehicles as well as RSUs. We assume that each link in this network topology follows a bidirectional transmission structure. We then model the bidirectional network topology as an ordinary graph $G = (V, L)$ , where $V = {v_{1}, v_{2}, \dots, v_{n}}$ denotes a non-empty finite set of vertices and $L$ denotes a non-empty finite set of links. In graph $G$ , each vertex $v_{i} \in V$ , for $i = 1, 2, \dots, n$ , corresponds to one vehicle node, and each link $l_{i, j} \in L$ , for $i, j = 1, 2, \dots, n$ , connects two vehicle nodes $v_{i} \in V$ and $v_{j} \in V$ if there exists a contact or communication opportunity between them. It is assumed that each vehicle node maintains its own constant velocity in IoV scenario. Without loss of generality, a non-empty finite subset of $V$ is defined as a multicast group $M$ , that is, $M \subseteq V$ , aiming to receive the service messages on SCHs. In addition, we assume that there are $k$ source vehicle nodes to transmit service messages on SCHs and different types of beacon messages on CCH. We use $ϕ$ to represent the number of types of beacon messages. Thereby, the set of types of beacon messages can be formulated as $Φ = {1, 2, \dots, ϕ}$ . Let $K = {v_{1}, v_{2}, \dots, v_{k}}$ and $v_{s} \in K$ be the set of source vehicle nodes and one particular source vehicle node, respectively, for $K \subset V$ . With regard to multicast group $M$ and source vehicle node $v_{s} \in K$ , other vehicle nodes belonging to multicast group $M$ constitute a non-empty finite set of destination vehicle nodes, which is further defined as $D \subseteq M - {v_{s}}$ . To gain a better understanding of congestion control mechanism at a possible bottleneck vehicle node, we focus on a scenario that multiple beacon messages on CCH converge at this bottleneck vehicle node. Specifically, we denote the possible bottleneck vehicle node in graph $G$ by $v_{C}$ , for $v_{C} \in V$ . Note that bottleneck vehicle node $v_{C}$ is a little more inclined to be the congested vehicle node when aggregated data load of beacon messages exceeds its own available capacity due to buffer overflow. We employ the Cartesian coordinate system to describe the location of each vertex in graph $G$ . Under such circumstances, the coordinates of the location of source vehicle node $v_{s}$ and bottleneck vehicle node $v_{C}$ can be explicitly determined by the ordered pairs $(x_{s}, y_{s})$ and $(x_{C}, y_{C})$ , respectively. Accordingly, the Euclidean distance between source vehicle node $v_{s}$ and bottleneck vehicle node $v_{C}$ can be given as

d_{s, C} = \sqrt{{(x_{s} - x_{C})}^{2} + {(y_{s} - y_{C})}^{2}}

(1)

Figure 2.

Considered bidirectional network topology of IoV scenario.

Let $Ψ_{C} (t_{C})$ denote the amount of beacon messages in the buffer of bottleneck vehicle node $v_{C}$ at time $t_{C}$ . Therefore, $Ψ_{C} (t_{C})$ at time $t_{C}$ can be given by the following iterative equation

Ψ_{C} (t_{C}) = \max {\min {Ψ_{C} (t_{ℓ}) + A (t_{C}), λ} - D (t_{C}), 0}

(2)

where $λ$ is the buffer size of bottleneck vehicle node $v_{C}$ , and $A (t_{C})$ and $D (t_{C})$ are the amount of beacon messages that bottleneck vehicle node $v_{C}$ accumulates, and the amount of beacon messages that could be delivered successfully to neighbor nodes on CCH within the time interval from $t_{s}$ to $t_{C}$ , respectively. Also, we assume that source vehicle node $v_{s}$ sent beacon messages at time $t_{s}$ , for $t_{s} < t_{C}$ . Then, the transmission time of beacon messages on CCH form source vehicle node $v_{s}$ to bottleneck vehicle node $v_{C}$ is equal to

Δ t = t_{C} - t_{s}

(3)

We model the relay vehicle nodes as $v_{i}$ and $v_{j}$ , for $v_{i}, v_{j} \in V$ , respectively. It is worth noting that relay vehicle nodes can assist in relaying service messages on SCHs or beacon messages on CCH via multichannel transmission along the corresponding routes. Meanwhile, the relay vehicle nodes will be selected as the neighbor vehicle nodes if they are within the single-hop transmission area of bottleneck vehicle node $v_{C}$ . From Figure 2, we can easily observe that the route form source vehicle node $v_{s}$ to bottleneck vehicle node $v_{C}$ could be labeled by $v_{s} \to v_{i} \to v_{C}$ or $v_{s} \to v_{i} \to v_{j} \to v_{C}$ , which have been established using any of the specific routing algorithms for IoV scenario. We would like to mention here that getting the route form source vehicle node $v_{s}$ to bottleneck vehicle node $v_{C}$ analytically is beyond the scope of this work. Moreover, it is also noted that the length of the route will impact the transmission time of service messages on SCHs or beacon messages on CCH. That is, the transmission time $Δ t$ depends on the length of the route form source vehicle node $v_{s}$ to bottleneck vehicle node $v_{C}$ .

Enabling MAC² in IoV scenario

MDD scheme with RDLC constraint

The main idea for the MDD scheme with RDLC constraint is to construct a multicast tree with the minimum tree cost. Under the constraint of the multicast tree, we attempt to perform the real-time multicast data transmission of service messages on SCHs using the random-delay control strategy. Note that the real-time multicast data transmission in this section refers to the transmission of service messages on SCHs according to multicasting policy. For convenience of presentation, Table 1 lists some important notations used in our MDD scheme with RDLC constraint.

Table 1.

Important notations.

Notation	Description
$Cost (l_{i, j})$	The cost of link $l_{i, j} \in L$
$Delay (l_{i, j})$	The delay of link $l_{i, j} \in L$
$v_{i}$	The neighbor vehicle node of vehicle node $v_{j}$
$dist (v_{i})$	The length of shortest path between vehiclenode $v_{i}$ and source vehicle node $v_{s}$
$Ddist (v_{i})$	The delay of shortest path between vehicle node $v_{i}$ and source vehicle node $v_{s}$
$Nei (v_{i})$	The set of neighbor vehicle node of vehiclenode $v_{i}$
$Path (v_{i})$	The length between vehicle node $v_{i}$ and onevehicle node with shortest path
$Parent (v_{i})$	The parent vehicle node of vehicle node $v_{i}$

Definition 1 (link delay)

The delay of link $l_{i, j} \in L$ connecting vehicle node $v_{i}$ and vehicle node $v_{j}$ is defined as $Delay (l_{i, j})$ , where $Delay (l_{i, j}) : E \to R^{+}$ is a delay function that contains three delay components, namely, radio propagation delay, queuing delay, and protocol processing delay.

Definition 2 (link cost)

The cost of link $l_{i, j} \in L$ connecting vehicle node $v_{i}$ and vehicle node $v_{j}$ is defined as $Cost (l_{i, j})$ , where $Cost (l_{i, j}) : E \to R^{+}$ is a cost function.

Definition 3 (path cost)

The path cost $Cost (P)$ of path $P$ is defined as the sum of the cost of links along path $P$ , which can be formulated as

Cost (P) = \sum_{α = 1}^{PL (P)} Cost (l_{i, j})

(4)

where $PL (\cdot)$ is a function that returns the number of links along path $P$ .

Definition 4 (path delay)

The path delay $Delay (P)$ of path $P$ is defined as the sum of the delay of links along path $P$ , which can be given as

Delay (P) = \sum_{α = 1}^{PL (P)} Delay (l_{i, j})

(5)

Definition 5 (tree delay)

The multicast tree $T = (V_{T}, L_{T})$ for $V_{T} \subseteq V$ and $L_{T} \subseteq L$ is defined as a subtree of graph $G = (V, L)$ rooted from source vehicle node $v_{s} \in K$ , covering all of vehicle nodes in the set of destination vehicle nodes $D \subseteq M - {v_{s}}$ and an arbitrary subset of $V - D$ .

Definition 6 (tree delay)

The tree delay $Cost (T)$ of multicast tree $T$ is defined as the sum of the delay of links within multicast tree $T$ .

Our problem is that given an ordinary graph $G$ , a source vehicle node $v_{s} \in K$ , a set of destination vehicle nodes $D \subseteq M - {v_{s}}$ , and a delay bound $Δ$ , respectively, to construct a multicast tree $T = (V_{T}, L_{T})$ which spans source vehicle node $v_{s}$ and set $D$ under the condition that the path delay $Delay (P)$ of path $P$ and the tree cost $Cost (T)$ of multicast tree $T$ satisfy the following required constraints

Delay (P) \leq Δ

(6)

Cost (T) = \arg \min {Cost (P) = \sum_{β = 1}^{NP (T)} \sum_{α = 1}^{PL (P)} Cost (l_{i, j})}

(7)

where $NP (\cdot)$ is a function that returns the number of paths within multicast tree $T$ .

If link $l_{i, j} \in L$ does not exist, we set $Cost (l_{i, j}) = Delay (l_{i, j}) = \infty$ . We assume that the cost and the delay of link $l_{i, j}$ should be either positive or zero. We also define all the vehicle nodes from vehicle node $v_{i}$ to source vehicle node $v_{s}$ as path vehicle nodes if and only if vehicle node $v_{i} \in D$ . Under this condition, we set $Path (v_{i}) = 0$ . With this in mind, we devise a multicast tree construction algorithm using the proposed MDD scheme with RDLC constraint given in Algorithm 1, aiming to construct a multicast tree $T$ according to the given initialized parameters.

Algorithm 1.

Multicast tree construction algorithm using MDD scheme with RDLC constraint.

1: Input:

G

v_{s} \in K

D \subseteq M - {v_{s}}

Δ

2: Output:

T = (V_{T}, L_{T})

3: Initialize multicast tree

T

T = {v_{s}}

dist (v_{s}) = 0

4: Select vehicle node

v_{j}

, and then set

{\begin{matrix} dist (v_{j}) = \min {dist (v_{i}) | v_{i} \in V - {v_{s}}} \\ Ddist (v_{i}) < Δ \end{matrix}

5: if

T \neq {v_{s} \cup D}

then

6: repeat

7: if

v_{j} \in {D \subseteq M - {v_{s}}}

then

8: Set

Path (v_{j}) = 0

9: Add vehicle node

v_{j}

into multicast tree

T

and set

Parent (v_{j}) = v_{s}

10: else if

Cost (l_{i, j}) \neq \infty

then

11: Find each neighbor vehicle node

v_{i} \in Nei (v_{i})

of vehicle node

v_{j}

12: if

{\begin{matrix} dist (v_{i}) > dist (v_{j}) + Cost (l_{i, j}) \\ Ddist (v_{j}) + Delay (l_{i, j}) < Δ \end{matrix}

then

13: Set

{\begin{matrix} dist (v_{i}) = dist (v_{j}) + Cost (l_{i, j}) \\ Ddist (v_{i}) = Ddist (v_{j}) + Delay (l_{i, j}) \end{matrix}

14: else if

dist (v_{i}) = dist (v_{j}) + Cost (l_{i, j})

and

{\begin{matrix} Path (v_{i}) > Path (v_{j}) + Cost (l_{i, j}) \\ Ddist (v_{j}) + Delay (l_{i, j}) < Δ \end{matrix}

then

15: Vehicle node

v_{i}

has lower

Path (v_{i})

through vehicle node

v_{j}

16: Set

{\begin{matrix} Path (v_{i}) = Path (v_{j}) + Cost (l_{i, j}) \\ Ddist (v_{i}) = Ddist (v_{j}) + Delay (l_{i, j}) \end{matrix}

, and update

Parent (v_{i}) = v_{j}

17: end if

18: end if

19: until

T = {v_{s} \cup D}

20: else

21: Multicast tree

T

is denoted by

T_{1}

22: Use delay-based Dijkstra algorithm to compute multicast tree

T_{2}

with shortest paths.

23: Set

T = T_{1} \cup T_{2}

24: end if

It should be noticed that a multicast tree with the minimum tree cost can be constructed via the process of our MDD scheme with RDLC constraint whose pseudo-code is given in Algorithm 1. The key point to establish the multicast tree in light of the proposed MDD scheme with RDLC constraint is illustrated with a flowchart shown in Figure 3. When this multicast tree is established, the destination vehicle nodes within the multicast group will receive the Join packets that are sent by a source vehicle node. To indicate that the multicast tree has been built up, a destination vehicle node on receiving the first Join packet will send a Reply packet on a route obtained by reversing the route appended to this multicast tree. Note that this operation by the destination vehicle node is reasonable due to the assumption that the bidirectional transmission structure has been taken into account in each link as stated before. In particular, the Reply packets that are sent by multiple destination vehicle nodes simultaneously will lead to the collision of multicast data packet transfers, which may thereby reduce the transmission efficiency. Hence, we employ the random-delay control strategy to dynamically regulate the transmit time of Reply packet for each destination vehicle node, aiming to lower the collision probability of multicast data packet transfers. Let $t_{0}$ and $h$ be the constant delay of single hop and the hop number from the destination vehicle node to the source vehicle node, respectively. Thus, the random delay $δ$ owned by the destination vehicle node to send the Reply packet is characterized by

δ = t_{0} h + r

(8)

where $r$ refers to a random number, for $r \in (0, 1)$ .

Figure 3.

Flowchart of the proposed MDD scheme with RDLC constraint.

PARCEL scheme

As aforementioned, safety applications with high priority (e.g. autonomous lane change maneuver, forward collision warning, traffic signal violation, and emergency brake lights) primarily exploit periodic exchanges of beacon messages on CCH. Recall the set $Φ = {1, 2, \dots, Φ}$ of types of beacon messages. Intuitively, different types of beacon messages corresponding to different safety applications should have differentiated types of priorities. Taking into account the impact of differentiated priorities of beacon messages on delivery ratio when the congestion occurs at the possible bottleneck vehicle node, we devise a time and distance coupling function to characterize the priority of beacon message with $ς th$ type, for $ς \in Φ$ . Let $a$ and $b$ stand for the non-positive loss factors for the transmission time of beacon messages on CCH, for $a, b \leq 0$ . Moreover, we use $d_{s, C}$ to represent the Euclidean distance form source vehicle node $v_{s}$ to bottleneck vehicle node $v_{C}$ . Therefore, the time and distance coupling function $g_{s, C}^{ς}$ of bottleneck vehicle node $v_{C}$ , for $ς \in Φ$ , can be expressed as

g_{s, C}^{ς} = a \cdot g_{1} (Δ t) + b \cdot g_{2} (d_{s, C}) + θ^{ς}

(9)

where $θ^{ς}$ is an initial priority of beacon message with $ς th$ type, $g_{1}$ and $g_{2}$ are the monotonically increasing continuous functions. Remark that the transmission time of beacon messages and the Euclidean distance form source vehicle node $v_{s}$ to bottleneck vehicle node $v_{C}$ are generally bounded by upper values $τ_{s}$ and $δ_{s}$ , respectively. In this case, initial priority $θ^{ς}$ of beacon message with $ς th$ type can be further calculated as

θ^{ς} = - \frac{a}{2} τ_{s} - \frac{b}{3} δ_{s}

(10)

Substituting $θ^{ς}$ in equation (10) into equation (9), we obtain

g_{s, C}^{ς} = a \cdot g_{1} (Δ t) + b \cdot g_{2} (d_{s, C}) - \frac{a}{2} τ_{s} - \frac{b}{3} δ_{s}

(11)

Noticing that priority $g_{s, C}^{ς}$ rests on the monotonically increasing continuous functions $g_{1}$ and $g_{2}$ , respectively. In order to rigorously regulate the priority of beacon message with $ς th$ type, we move on to formulate a transition function to represent $g_{1}$ and $g_{2}$ as follows.

Definition 7 (transition function)

Given a transition function $Ψ : R^{+} \to R^{+}$ on a domain $z \subset R^{+}$ , we define the transition function as follows

Ψ (z) = \arctan (\frac{z}{u})

(12)

where $u \geq 1$ is a transformation scalar.

According to equation (12), the transition function $Ψ (z)$ with domain $z \in [0, + \infty)$ and transformation scalar $u \geq 1$ is illustrated in Figure 4. In fact, we devise the transition function $Ψ (z)$ as a monotonically increasing function with a trend of more and more stable growth when $z \to + \infty$ for the following considerations. On one hand, the range of the transition function $Ψ (z)$ holds a rapid descent over a local domain to adjust priority $g_{s, C}^{ς}$ quickly. On the other hand, there must be an upper bound on the transition function $Ψ (z)$ . As exhibited in Figure 4, it is easy to see that the monotone transition function $Ψ (z)$ is upper bounded by $π / π 2 2$ . In addition, the rapid descent is determined by the transformation scalar $u$ .

Figure 4.

Transition function $Ψ (z) = \arctan (z / u)$ with an upper bound $π / 2$ .

Thus, we can take advantage of the transition function $Ψ (z)$ to characterize $g_{1}$ and $g_{2}$ based on equation (12). Hence, priority $g_{s, C}^{ς}$ of beacon message with $ς th$ type of bottleneck vehicle node $v_{C}$ is formally formulated bearing in mind the transition function $Ψ (z)$

g_{s, C}^{ς} = a \cdot \arctan (\frac{Δ t}{u_{1}}) + b \cdot \arctan (\frac{d_{s, C}}{u_{2}}) - \frac{a}{2} τ_{s} - \frac{b}{3} δ_{s}

(13)

where $u_{1}$ and $u_{2}$ are the transformation scalars, respectively, for $u_{1}, u_{2} \geq 1$ .

Assuming that the saturation value of the buffer of bottleneck vehicle node $v_{C}$ is denoted by $℘_{C}$ , we then have the following buffer constraint to determine whether bottleneck vehicle node $v_{C}$ at time $t_{C}$ will become a congested vehicle node

{\begin{matrix} if Ψ_{C} (t_{C}) \leq ℘_{C}, bottleneck vehicle node will \\ not be congested vehicle node \\ if Ψ_{C} (t_{C}) > ℘_{C}, bottleneck vehicle node will \\ be congested vehicle node \end{matrix}

(14)

By comparing the current amount $Ψ_{C} (t_{C})$ of beacon messages with the saturation value $℘_{C}$ of the buffer, it is reasonable for bottleneck vehicle node $v_{C}$ to continue to buffer beacon messages that have been accumulated if $Ψ_{C} (t_{C}) \leq ℘_{C}$ . However, under the condition $Ψ_{C} (t_{C}) > ℘_{C}$ , bottleneck vehicle node $v_{C}$ will become a congested vehicle node, and it will turn to start the PARCEL policy via the following rules:

Rule 1. Compute priority $g_{s, C}^{ς}$ of beacon message with $ς th$ type using equation (13). Then arrange priority $g_{s, C}^{ς}$ in descending order. Finally, delete the beacon messages with the lowest priority $g_{s, C}^{ς}$ .

Rule 2. Based on priority $g_{s, C}^{ς}$ in descending order in Rule 1, select the beacon messages with the highest priority $g_{s, C}^{ς}$ and then prepare to deliver them to the proper neighbor vehicle node on CCH through single-hop broadcast.

According to Rule 2, in order to obtain the proper neighbor vehicle node as the receiver of beacon messages with the highest priority $g_{s, C}^{ς}$ , bottleneck vehicle node $v_{C}$ initiates the receiver discovery by flooding a forward request (FREQ) message on CCH to its neighbor vehicle nodes within its single-hop transmission area. The format of the FREQ message is shown in Figure 5(a). The “Type” refers to the message type and is set to 1 for the FREQ message. The “Reserved” is set to 0 for ignoring and non-zero for receiving. The pair <Congested Node Address, FREQ ID> uniquely identifies the FREQ message. The “Destination Node Address” indicates the address of the destination vehicle node and the “Congested Node Velocity” records the velocity value of bottleneck vehicle node $v_{C}$ . The “Required Buffer” records the amount of beacon messages with the highest priority $g_{s, C}^{ς}$ that needs to be sent by bottleneck vehicle node $v_{C}$ . We wish to remark that the undesirable network overhead will be caused by flooding the FREQ messages with the growth of the number of neighbor vehicle nodes, although the flooding is confined to the single-hop transmission area of bottleneck vehicle node $v_{C}$ . This problem can be resolved by the corresponding flooding algorithm (e.g. semi-directional flooding³³) to reduce or mitigate flooding overhead.

Figure 5.

(a) FREQ and (b) FREP message formats.

When neighbor vehicle node $v_{i}$ receives a FREQ message, it creates a forward reply (FREP) message including the field of “Receiver Level Value” and some other fields as depicted in Figure 5(b). Note that the receiver-level value owned by neighbor vehicle node $v_{i}$ of bottleneck vehicle node $v_{C}$ reveals the ability of neighbor vehicle node $v_{i}$ to receive beacon messages delivered by bottleneck vehicle node $v_{C}$ . That is, neighbor vehicle node $v_{i}$ of bottleneck vehicle node $v_{C}$ will incline to become the receiver of beacon messages with the highest priority $g_{s, C}^{i}$ when the receiver-level value tends to be larger. Based on this insight, the receiver-level value $Q_{i}$ of neighbor vehicle node $v_{i}$ can be formulated as

Q_{i} = ω \times \frac{η_{C} - η_{i}}{η_{i}} + (1 - ω) \times \frac{B_{i}}{σ_{i}}

(15)

where $η_{C}$ is the velocity of bottleneck vehicle node $v_{C}$ , $η_{i}$ is the velocity of neighbor vehicle node $v_{i}$ , $σ_{i}$ is the total amount of the buffer space of neighbor vehicle node $v_{i}$ , $B_{i}$ is the free buffer space of neighbor vehicle node $v_{i}$ , and $ω$ is the probability of contact or communication opportunity between neighbor vehicle node $v_{i}$ and the destination node. In addition, the process of the FREP message with regard to neighbor vehicle node $v_{i}$ can be given by the flowchart as illustrated in Figure 6. It is worth remarking that two conditions must be simultaneously met before computing the receiver-level value $Q_{i}$ by neighbor vehicle node $v_{i}$ . For the first condition, the free buffer space $B_{i}$ of neighbor vehicle node $v_{i}$ should be greater than the sum of the value of “Required Buffer” in the FREQ message and the saturation value $℘_{C}$ of the buffer of bottleneck vehicle node $v_{C}$ . For the second condition, the velocity $η_{C}$ of bottleneck vehicle node $v_{C}$ should also be larger than the velocity $η_{i}$ of neighbor vehicle node $v_{i}$ . Depending on Figure 6, when the receiver-level value $Q_{i}$ is derived by neighbor vehicle node $v_{i}$ , the FREP message will be sent to bottleneck vehicle node $v_{C}$ .

Figure 6.

Flowchart of the FREP message process.

Based on the received FREP messages from multiple neighbor vehicle nodes, the objective of bottleneck vehicle node $v_{C}$ is to select an optimal neighbor vehicle node $v_{i}^{*}$ as the receiver of beacon messages with the highest priority $g_{s, C}^{ς}$ through maximizing the receiver-level value $Q_{i}$

v_{i}^{*} = \arg \max {v_{i} | Q_{i}}

(16)

According to the selection metric for optimal neighbor vehicle node $v_{i}^{*}$ in equation (16), the process of the PARCEL performed by bottleneck vehicle node $v_{C}$ is summarized in the flowchart as illustrated in Figure 7. Note that Figure 7 demonstrates a perfect interaction between the proposed PARCEL scheme and two predefined control messages, that is, the FREQ message and the FREP message. According to our scheme, in order to send the beacon messages with highest priority on CCH to the potential neighbor vehicle node, bottleneck vehicle node $v_{C}$ should flood the forward FREQ message on CCH to all the neighbor vehicle nodes. In addition, the potential neighbor vehicle node will send the FREP message back to bottleneck vehicle node $v_{C}$ on CCH, to indicate that it is subject to two conditions as stated previously. It is evident that both of the control messages constitute the indispensable composition of our scheme.

Figure 7.

Flowchart of the proposed priority-aware congestion control scheme.

System design and experimental results

System design of RanLow module

We next proceed to employ our scheme as discussed above to devise the RanLow module, an MDD module with RDLC constraint in WCB board of IVT system. Based on the IVT architecture, the overall hardware architecture of the RanLow module as depicted in Figure 8(a) is based on the STC89C52RC Chip Microcomputer of 8-bit single-chip microcontroller. In particular, this 8-bit microcontroller connects four external circuits consisting of RF & Wireless Circuit, Serial Port Circuit, Power Circuit, and External RAM Circuit. On the basis of the overall hardware architecture, we devise a hardware circuit of the RanLow module as illustrated in Figure 9. It is worth noting that the STC89C52RC Chip Microcomputer can acquire the 5 V DC-stabilized voltage source whose power is supplied by the Power Circuit. In the External RAM Circuit, two 32 KB × 8-bit high-performance complementary metal-oxide-semiconductor (CMOS) static RAM chips are utilized to supply 64 KB dynamic data memory. Moreover, the Serial Port Circuit uses CH340 serial chip that supplies common MODEM liaison signal, used to enlarge asynchronous serial interface of computer or upgrade the common serial device to USB bus directly. Also, in the RF & Wireless Circuit, the Nordic nRF905 is chosen as a highly integrated, low power, multiband RF transceiver IC for 433/868/915 MHz ISM (Industrial, Scientific, and Medical) band. In summary, the detailed hardware settings of the RanLow module are provided in Table 2. Correspondingly, we build up the prototype system of the RanLow module as shown in Figure 8(b) by bearing in mind the overall hardware architecture of the RanLow module and four external circuits.

Figure 8.

Hardware design of the RanLow module: (a) overall hardware architecture and (b) prototype system of RanLow module.

Figure 9.

Hardware circuit development of the RanLow module.

Table 2.

Detailed hardware settings of the RanLow module.

Submodule item	Type selection	Main parameters and features
Microcomputer	STC89C52RC Chip Microcomputer	8-bit single-chip microcontroller with a compatible instruction set; On-chip 1280B/512B RAM; Dual Data Pointer (DPTR) to speed up data movement; 8 vector-address, four-level priority interrupt capability.
RF & Wireless Circuit	nRF905	Single chip multiband RF transceiver for 433/868/915 MHz ISM; Automatic cyclic redundancy check and preamble generation; ShockBurst mode for low power operation.
Serial Port Circuit	CH340	Conform to USB Specification Version 2.0; Support communication baud rate varies from 50 bps to 2 Mbps; Support common MODEM liaison signal; Supply RS232, RS485, RS422, and other interfaces.
External RAM Circuit	CY62256	32 KB CMOS static RAM; Two CY62256 chips connect to STC89C52RC chip microcomputer; Supply 64 KB dynamic data memory.
Power Circuit	USB power supply	Supply 5 V DC-stabilized voltage source.

RAM: random-access memory; RF: radio-frequency; ISM: industrial, scientific, and medical; CMOS: complementary metal-oxide-semiconductor.

Aiming at realizing the MDD scheme with RDLC constraint under the RanLow module, we conduct the software design and programming operations to keep the STC89C52RC Chip Microcomputer function properly. In general, the RanLow module will be activated by the source vehicle node when the set of destination vehicle nodes contains more than two vehicle nodes, that is, $| D | \geq 2$ , where $| \cdot |$ returns the cardinality of set $D$ . Under the constraint of delay bound $Δ$ , we will first compute the cost and delay of the link from the source vehicle node to each corresponding neighbor vehicle node. Then, we select the neighbor vehicle node with the minimum cost and delay as the forwarding vehicle node to perform the real-time multicast data transmission. Specifically, the programming flowchart diagram of the RanLow module is shown in Figure 10.

Figure 10.

Programming flowchart diagram of the RanLow module.

System design of PARCEL module

We next turn to employ the proposed PARCEL scheme as stated above to build the PARCEL module, a congestion control module with safety applications in WCB board of IVT system. According to the IVT architecture, the overall hardware architecture of the PARCEL module shown as in Figure 11(a) is based on the C8051F340 MCU of 8-bit microcontroller, which can connect four external circuits including the Serial Port Circuit, the PL2303 USB to Serial Bridge Controller, the External RAM Circuit, the Power Circuit, and the Reset Circuit. With the help of the overall hardware architecture, we devise a hardware circuit of the PARCEL module as illustrated in Figure 12. It is worth mentioning that the 8-bit C8051F340 MCU includes a powerful 8051 core with 50 MHz performance along with 64 KB Flash and 4.25 KB RAM and can acquire 3.6–5.25 V voltage sources whose power is supplied by Power Circuit. In the External RAM Circuit, three 32 KB × 8-bit high-performance CMOS static RAM chips are used to supply 96 KB dynamic data memory via CY62256 Cypress Semiconductor. Easy memory expansion is provided by an active LOW chip enable and active LOW output enable and Tri-state drivers. Moreover, the Serial Port Circuit uses MAX3223 chip that offers the electrical interface between an asynchronous communication controller and the serial-port connector. Also, the PL2303 USB to Serial Bridge Controller provides a convenient solution for connecting an RS232 full-duplex asynchronous serial device to any USB capable host. By taking advantage of USB bulk transfer mode, large data buffers, and automatic flow control, PL2303 is capable of achieving higher throughput compared to traditional UART ports. To this end, we build the prototype system of the PARCEL module as shown in Figure 11(b) by bearing in mind the overall hardware architecture of the PARCEL module and five external circuits.

Figure 11.

Hardware design of the PARCEL module: (a) overall hardware architecture and (b) prototype system.

Figure 12.

Hardware circuit development of the PARCEL module.

By comparing the current amount $Ψ_{C} (t_{C})$ of beacon messages with the saturation value $℘_{C}$ of the buffer of bottleneck vehicle node $v_{C}$ , the PARCEL module will identify whether or not to start the PARCEL policy based on Rule 1 and Rule 2. In addition, according to the process of the neighbor vehicle node $v_{i}$ as for the FREP message and the process of the PARCEL performed by bottleneck vehicle node $v_{C}$ .

Experimental results of RanLow module

In the following, we first present the experimental results to demonstrate the performance of the proposed RanLow module. Note that our experiments are carried out indoors through extensive static tests using the devised RanLow module. We consider a scenario of the IoVs, wherein $| V | = 20$ The RanLow modules as the vehicle nodes are randomly distributed. It is noteworthy that the prototype system of the RanLow module as shown in Figure 8(b) has been built up based on the overall hardware architecture of the RanLow module and four external circuits. In the experiment setting, we prepare the set of the destination vehicle nodes which is defined as $| D | = 3$ , $| D | = 4$ , and $| D | = 5$ , respectively, aiming to validate the performance of MDD. In addition, the other experiment parameters and their values for the RanLow module and the PARCEL module are summarized in Table 3. Specifically, we evaluate the impact of the size of the set of destination vehicle nodes on the average delay of MDD that the destination vehicle nodes within $D$ receive the multicast data packets. Moreover, we consider the existing classical multicast routing algorithms including constrained Dijkstra heuristic (CDKS) and Kompella, Pasquale, and Polyzos (KPP)^34,35 to compare with the RanLow module under MDD scheme with RDLC constraint. In each experiment with the specific size of the set of destination vehicle nodes $D$ , we conduct 10 times tests, and then record the average delay that the destination vehicle nodes within $D$ receive the multicast data packets.

Table 3.

Experimental parameters for the RanLow module and the PARCEL module.

Parameter	Value
Delay of single hop $t_{0}$	0.003 s
Random number $r$	0.6
Delay bound $Δ$	0.1 s
Non-positive loss factor $a$	−20
Non-positive loss factor $b$	−5
Upper value of transmission time $τ_{s}$	0.05 s
Upper value of Euclidean distance $δ_{s}$	200 m
Transformation scalar $u_{1}$	2
Transformation scalar $u_{2}$	3
Saturation value of the buffer $℘_{C}$	260 KB
Probability of contact betweenneighbor node and destination node $ω$	85%

PARCEL: priority-aware congestion control.

First, we validate the RanLow module under the experiment scenario as shown in Figure 13(a), which contains $| V | = 5$ RanLow modules. Note that one RanLow module acts as the source vehicle node. When the No. 5 RanLow module receives the multicast data packet, the indicator of the RanLow module will light up. Then, the timing will stop. As stated previously, this process will be performed at 10 times and the average delay will be recorded. On basis of this validation policy, we record the average delay under the set of the destination vehicle nodes $| D | = 3$ , $| D | = 4$ , and $| D | = 5$ , respectively. The experimental results are given in Tables 4 –6. Next, we validate the CDKS and KPP strategies under the experiment scenario as depicted in Figure 13(b). It is worth noting that the programs of the CDKS and KPP strategies have been downloaded into the module, respectively. According to the same experiment scenario and validation policy, we acquire the average delay that the destination vehicle nodes within $D$ receive the multicast data packets. From Tables 4 –6, we can see that the average delay that the destination vehicle nodes within $D$ receive the multicast data packets by the RanLow module, CDKS strategy, and KPP strategy, is 32, 51, and 85 ms, respectively. Moreover, it is seen that the average delay by the RanLow module is lower than that by the CDKS and KPP strategies. This can be explained by the fact that the RanLow module under MDD scheme with RDLC constraint uses the random-delay control strategy to dynamically adjust the transmit time of the Reply packet for each destination vehicle node, to reduce the collision probability of multicast data packet transfers. However, the CDKS strategy as well as the KPP strategy cannot give more insights into the impact of the collision of multicast data packet transfers on the transmission efficiency.

Figure 13.

Experiment scenario setting for the RanLow module: (a) experiment scenario of the RanLow module and (b) experiment scenario of the CDKS and KPP strategies.

Table 4.

Average delay by the RanLow module.

Number of destination vehicle nodes	Average delay (ms) by the RanLow module
	Number of experiment tests
	T1	T2	T3	T4	T5	T6	T7	T8	T9	T10
\|D\| = 3	26	28	25	26	27	27	25	29	27	26
\|D\| = 4	32	31	31	33	32	31	33	34	32	33
\|D\| = 5	38	36	38	37	39	37	38	38	36	39

Table 5.

Average delay by the CDKS strategy.

Number of destination vehicle nodes	Average delay (ms) by the CDKS strategy
	Number of experiment tests
	T1	T2	T3	T4	T5	T6	T7	T8	T9	T10
\|D\|= 3	41	41	44	42	43	39	40	43	40	42
\|D\|= 4	53	51	49	52	53	51	52	52	49	51
\|D\|= 5	64	60	59	58	62	59	58	61	62	60

Table 6.

Average delay by the KPP strategy.

Number of destination vehicle nodes	Average delay (ms) by the KPP strategy
	Number of experiment tests
	T1	T2	T3	T4	T5	T6	T7	T8	T9	T10
\|D\| = 3	75	73	78	75	77	76	77	77	76	78
\|D\| = 4	83	86	86	84	85	87	84	85	87	85
\|D\| = 5	90	89	92	92	91	93	92	93	92	90

Due to the limited number of destination vehicle nodes in our experiments, we also provide simulation results to evaluate the performance of the RanLow module under MDD scheme with RDLC constraint by comparing with the CDKS and KPP strategies. Based on the same setting of experiment parameters as shown in Table 3, we intend to randomly deploy various number of destination vehicle nodes to obtain the average delay of MDD that all destination vehicle nodes receive the multicast data packets. Figure 14 exhibits the average delay comparison among RanLow module, CDKS strategy, and KPP strategy according to different number of destination vehicle nodes. From the results, we can see that an increased number of destination vehicle nodes from 5 to 30 will increase the average delay of MDD. This is a direct consequence of number of destination vehicle nodes on MDD. Apparently, we can also find that the average delay the RanLow module is obviously lower than those of the CDKS and KPP strategies. The results are in line with the experimental results given in Tables 4 –6. The explanation is twofold. First, the collision probability of multicasting is reduced by leveraging the random-delay control strategy to regulate the transmit time of the Reply packet. Second, the CDKS and KPP strategies fail to tackle the problem of the collision of multicasting.

Figure 14.

Average delay comparison among RanLow module under the MDD scheme with RDLC constraint, CDKS strategy, and KPP strategy.

Experimental results of PARCEL module

In this section, we then present the experimental results to demonstrate the performance of the proposed PARCEL module. Similar to the experiments for the RanLow module, the PARCEL module is also verified indoors by means of extensive static tests. The experiments mainly involve the following steps. First, when the congestion occurs under the condition of $Ψ_{C} (t_{C}) > ℘_{C}$ , the bottleneck vehicle node $v_{C}$ as a congested node starts the PARCEL policy via the PARCEL module. Second, we record the average time interval from the beginning of congestion to the end of congestion at congested vehicle node $v_{C}$ , with the emphasis on validating the performance of the proposed PARCEL scheme. It is noteworthy that the prototype system of the PARCEL module as shown in Figure 11(b) has been built up based on the overall hardware architecture of the PARCEL module and five external circuits. Aiming to compare with the PARCEL module under the PARCEL scheme, when aggregated data load exceeds available capacity of the buffer of congested vehicle node, we consider the existing classical congestion control strategies including:^36,37 (a) drop front (DF), wherein the beacon message with longest queuing time in the buffer is dropped; (b) drop last (DL), wherein the last beacon message received in the buffer is dropped; (c) drop oldest (DO), wherein the beacon message in the buffer with the smallest remaining time-to-live (TTL) is dropped. In the following, we conduct 20 times tests for each congestion control strategies, and record the average time interval from the beginning of congestion to the end of congestion at congested vehicle node.

First, we validate the PARCEL module under the experiment scenario as shown in Figure 14, which contains $| V | = 5$ PARCEL modules. As displayed in Figure 15, there is one PARCEL module as congested vehicle node, and other four PARCEL modules belong to source vehicle nodes and neighbor vehicle nodes. When the PARCEL module depicted in Figure 15 starts to be congested under the condition of $Ψ_{C} (t_{C}) > ℘_{C}$ , the indicator of PARCEL module will light up. Then, we begin by recording the initial time of the beginning of congestion. Thus, we finish the timing under the scenario of the indicator with the light out, which demonstrates the end of congestion at congested vehicle node. As stated previously, this process will be performed at 20 times and the average time interval from the beginning of congestion to the end of congestion at congested vehicle node will be recorded. The experimental results are given in Figure 16. Next, we validate the DF, the DL, and the DO strategies under the same experiment scenario as depicted in Figure 15. It is worth noting that the programs of the DF, the DL, and the DO strategies have been downloaded into the module, respectively. Due to the fact that the beacon messages will be dropped by the DF, the DL, and the DO strategies, we only require one congested vehicle node in tests. According to this experiment scenario and validation policy, we acquire the average time interval from the beginning of congestion to the end of congestion at congested vehicle node based on different strategies under 20 times. According to the records as shown in Figure 16, we can observe that the average time interval by the PARCEL module, the DF, the DL and the DO strategies, is 1.9, 3.2, 2.5, and 2.9 s, respectively. Moreover, it is also seen that the average time interval by the PARCEL module is lower than that by the DF, the DL, and the DO strategies. This can be explained by the fact that the PARCEL module can deliver beacon messages with the highest priority to the proper neighbor vehicle node on CCH through single-hop broadcast, although the beacon messages with the lowest priority have been deleted. Hence, the beacon message drops will be reduced and the average time interval will be shortened. However, the DF, the DL, and the DO strategies fail to give more insights into the impact of the transfer of beacon messages with the highest priority on the average time interval.

Figure 15.

Experiment scenario of the PARCEL module.

Figure 16.

Average time interval comparison.

Conclusion and future work

In this article, we studied how to deal with multicasting service messages on SCHs along with periodic exchanges of beacon messages on CCH for IoV scenario. First of all, we revisited the IVT architecture, and particularly design the WCB board by incorporating MAC² modules. Apart from this, we proposed the MDD scheme with RDLC constraint, to transfer service messages on SCHs. In order to deal with network congestion, we presented the PARCEL scheme by taking into account differentiated priorities of beacon messages for safety applications on CCH. Then we conducted the system design and hardware implementation using the proposed schemes to devise the RanLow module and the PARCEL module in WCB board of the IVT architecture. In the evaluation, we constructed the hardware experimental environment to evaluate the performance of the RanLow module and the PARCEL module via extensive static tests. The experimental results were presented to demonstrate the effectiveness of our devised RanLow module and PARCEL module.

What we have discussed in this article is the portion of foundation for the IVT system in IoV scenario. Possible direction for future work within this research is to devise the prototype system of the mobile intelligent vehicle using the RanLow module and the PARCEL module in WCB board of IVT system. Based on the prototype system, we plan to build the actual settings for IoV to conduct the mobile tests. As another future work, we will try to investigate MAC² in the practical scenarios of future autonomous driving⁷ or clean-energy intelligent vehicles,⁸ to accommodate for the future IoV evolution. Moreover, it will be interesting and important to explore how to devise vehicle control-oriented applications in the IVT architecture, for example, autonomous lane change maneuver, forward collision warning, and traffic signal violation,^16–18 to enable safety, mobility, and environmental sustainability.

Footnotes

Handling Editor: Liping Jiang

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work was supported, in part, by the National Natural Science Foundation of China under grants 61402147 and 61501406; the Research Program for Top-notch Young Talents in Higher Education Institutions of Hebei Province, China, under grant BJ2017037; the Research and Development Program for Science and Technology of Handan, China, under grant 1621203037, the Natural Science Foundation of Hebei Province of China under Grants F2017402068 and F2018402198.

ORCID iD

Long Zhang

References

Cheng

Zhang

et al . Connected vehicles: solutions and challenges. IEEE Internet Things 2014; 1(4): 289–299.

Liu

Internet of Vehicles: your next connection. Huawei Winwin 2011; 11: 23–28.

Kang

Huang

et al . Location privacy attacks and defenses in cloud-enabled Internet of Vehicles. IEEE Wirel Commun 2016; 23(5): 52–59.

Duan

Liu

Wang

SDN enabled 5G-VANET: adaptive vehicle clustering and beamformed transmission for aggregated traffic. IEEE Commun Mag 2017; 55(7): 120–127.

Cheng

Zhou

et al . Routing in Internet of Vehicles: a review. IEEE T Int Transp Syst 2015; 16(5): 2339–2352.

Zhou

Cheng

et al . Internet of Vehicles in big data era. IEEE/CAA J Automat Sin 2018; 5(1): 19–35.

Chen

Tian

Fortino

et al . Cognitive Internet of Vehicles. Comput Commun 2018; 120: 58–70.

Zhang

You

et al . Exploring to direct the reaction pathway for hydrogenation of levulinic acid into γ-valerolactone for future clean-energy vehicles over a magnetic Cu-Ni catalyst. Int J Hydrogen Energ 2017; 42(40): 25185–25194.

Zhang

Chao

HC.

Cooperative fog computing for dealing with big data in the Internet of Vehicles: architecture and hierarchical resource management. IEEE Commun Mag 2017; 55(12): 60–67.

10.

Egea-Lopez

Pavon-Marino

Distributed and fair beaconing rate adaptation for congestion control in vehicular networks. IEEE T Mobile Comput 2016; 15(12): 3028–3041.

11.

Sepulcre

Gozalvez

Altintas

et al . Integration of congestion and awareness control in vehicular networks. AdHoc Netw 2016; 37: 29–43.

12.

Jabbarpour

Noor

Khokhar

et al . Cross-layer congestion control model for urban vehicular environments. J Netw Comput Appl 2014; 44: 1–16.

13.

Jemaa

Shagdar

Martinez

et al . Extended mobility management and routing protocols for internet-to-VANET multicasting. In Proceedings of the annual IEEE consumer communications and networking conference (CCNC), Las Vegas, NV, 9–12 January 2015, pp.904–909. New York: IEEE.

14.

Jemaa

Shagdar

Ernst

. A framework for IP and non-IP multicast services for vehicular networks. In: Proceedings of the international conference on the network of the future (NOF), Tunis, Tunisia, 21–23 November 2012, pp.1–6. New York: IEEE.

15.

Jiang

Zhu

Wang

et al . TMC: exploiting trajectories for multicast in sparse vehicular networks. IEEE T Parallel Distrib Syst 2015; 26(1): 262–271.

16.

Taherkhani

Pierre

Improving dynamic and distributed congestion control in vehicular ad hoc networks. AdHoc Netw 2015; 33: 112–125.

17.

You

Zhang

Lie

et al . Trajectory planning and tracking control for autonomous lane change maneuver based on the cooperative vehicle infrastructure system. Expert Syst Appl 2015; 42(14): 5932–5946.

18.

Zhang

Wang

et al . Study on self-tuning tyre friction control for developing main-servo loop integrated chassis control system. IEEE Access 2017; 5: 6649–6660.

19.

Zhang

Valaee

Congestion control for vehicular networks with safety-awareness. IEEE/ACM T Netw 2016; 24(6): 3290–3299.

20.

Kaiwartya

Abdullah

Cao

et al . Internet of Vehicles: motivation, layered architecture, network model, challenges, and future aspects. IEEE Access 2016; 4: 5356–5373.

21.

. A novel embedded vehicle terminal for intelligent transportation. In: Proceedings of the international conference on intelligent systems design and engineering applications, Zhangjiajie, China, 26–27 June 2014, pp.52–54. New York: IEEE.

22.

Zhou

Wan

C. A

smart context-aware-oriented vehicle terminal system in logistics transportation. In: Proceedings of the international ICST conference on communications and networking in China (CHINACOM), Kunming, China, 8–10 August 2012, pp.493–497. New York: IEEE.

23.

Zhou

Tian

et al . Design of a hybrid RFID/GPS-based terminal system in vehicular communications. In: Proceedings of the international conference on wireless communications networking and mobile computing (WICOM), Chengdu, China, 23–25 September 2010, pp.1–4. New York: IEEE.

24.

Yang

Zhang

et al . Intelligent vehicle control terminal of forestry monorail car based on ARM. In: Proceedings of the international conference on intelligent computation technology and automation, Changsha, China, 11–12 May 2010, pp 568–571. New York: IEEE.

25.

Sun

Yan

et al . Research and development of vehicle intelligent terminal system for engineering equipment. In: Proceedings of international conference on measuring technology and mechatronics automation, Shanghai, China, 6–7 January 2010, pp.1031–1036. New York: IEEE.

26.

Jeong

DHC

. TMA: trajectory-based multi-anycast forwarding for efficient multicast data delivery in vehicular networks. Comput Netw 2013; 57(13): 2549–2563.

27.

Chen

Lin

Lee

SL.

A mobicast routing protocol in vehicular ad-hoc networks. Mobile Netw Appl 2010; 15(1): 20–35.

28.

Zhang

A micro-artificial bee colony based multicast routing in vehicular ad hoc networks. AdHoc Netw 2017; 58: 213–221.

29.

Kim

Gerla

Cognitive multicast with partially overlapped channels in vehicular ad hoc networks. AdHoc Netw 2013; 11(7): 2016–2025.

30.

Egea-Lopez

Pavon-Marino

Fair congestion control in vehicular networks with beaconing rate adaptation at multiple transmit powers. IEEE T Veh Technol 2016; 65(6): 3888–3903.

31.

Egea-Lopez

Alcaraz

Vales-Alonso

et al . Statistical beaconing congestion control for vehicular networks. IEEE T Veh Technol 2013; 62(9): 4162–4181.

32.

Aygun

Boban

Wyglinskia

AM.

ECPR: environment-and context-aware combined power and rate distributed congestion control for vehicular communications. Comput Commun 2016; 93: 3–16.

33.

Kim

Chong

Kim

A location-free semi-directional-flooding technique for on-demand routing in low-rate wireless mesh networks. IEEE T Parallel Distrib Syst 2014; 25(12): 3066–3075.

34.

Jie

Ning

Fei

. Multicast routing algorithm with multi-QoS based on fuzzy set theory. In: Proceedings of the international conference on intelligent systems design and engineering applications, Sanya, China, 6–7 January 2012. New York: IEEE.

35.

Zhou

Ding

Zhu

Delay-constrained multicast routing algorithm based on average distance heuristic. Int J Comput Netw Commun 2010; 2(2): 155–162.

36.

Wang

Yang

A Knapsack-based buffer management strategy for delay-tolerant networks. J Parallel Distrib Comput 2015; 86: 1–15.

37.

Moetesum

Hadi

Imran

et al . An adaptive and efficient buffer management scheme for resource-constrained delay tolerant networks. Wirel Netw 2016; 22(7): 2189–2201.

MAC 2 : Enabling multicasting and congestion control with multichannel transmission for intelligent vehicle terminal in Internet of Vehicles

Abstract

Keywords

Introduction

Problem and motivation

Related works

Contributions and organization

IVT architecture

System model

Enabling MAC2 in IoV scenario

MDD scheme with RDLC constraint

Definition 1 (link delay)

Definition 2 (link cost)

Definition 3 (path cost)

Definition 4 (path delay)

Definition 5 (tree delay)

Definition 6 (tree delay)

PARCEL scheme

Definition 7 (transition function)

System design and experimental results

System design of RanLow module

System design of PARCEL module

Experimental results of RanLow module

Experimental results of PARCEL module

Conclusion and future work

Footnotes

Declaration of conflicting interests

Funding

ORCID iD

References

Enabling MAC² in IoV scenario