Integration Challenges of Facilities-Layer DCC for Heterogeneous V2X Services
I. Khan†, J. Härri†
†EURECOM, 450 route des Chappes, 06904 Sophia-Antipolis, France E-mails:{khanm, haerri}@eurecom.fr
Abstract—Decentralized Congestion Control (DCC) for 802.11p based inter-vehicular communication (V2X) is a critical mechanism for distributed wireless resource allocation of future connected intelligent vehicles. Studies so far mostly focused on optimizing resources for a single Cooperative Awarenessservice, whereas future connected intelligent vehicles will be based on multiple heterogeneous new V2X services. In this paper, we present a Facilities-layer DCC, currently being standardized in Europe, capable of handling heterogeneous V2X services and evaluate its integration impact with legacy DCC mechanisms.
We first emphasize significant wireless resource under-utilizations and application performance degradations stemming from con- flicting decisions between legacy and Facilities-layer DCC. We then show the capability of the DCC mechanism purely based at service layer and illustrate its flexibility for agile wireless resource allocations between V2X services for intelligent vehicles.
I. INTRODUCTION
Automated Driving and Platooning are paramount examples of benefits of future cooperative intelligent vehicles to safe and smart transportation. To reach that goal, intelligent vehi- cles must not only acquire environmental awareness through their advance embedded sensors, but also share it with other vehicles via V2X communication to increase their awareness horizon. Depending on the scope and scale, the required data will be exchanged via heterogeneous V2X services, such as Cooperative Awareness (CA), Collective Perception (CP), Position & Time (POTI), or Local Dynamic Map (LDM). The reliability of these services will depend on the dependability of the underlying V2X communication technologies.
Whether cellular or WiFi, V2X communication technologies require vehicles to take autonomous communication decision and as such operate in ad-hoc mode. In particular, spatio- temporal channel resources must be regulated among various V2X services in a fully decentralized way to guarantee reliable and fair V2X communication conditions. This process is called Decentralized Congestion Control (DCC)in Europe, and many DCC mechanisms have been proposed [1]–[4], while some have been standardized [5]–[7].
In Europe, ETSI is in charge of V2X communication standards for Cooperative Intelligent Transport System (C- ITS). In 2016, it completed a full set of specification for the first generation of C-ITS applications. The vast majority is based on a single service called Cooperative Awareness and a single message calledCooperative Awareness Message (CAM). Accordingly, DCC has been optimized mostly for this message only. While ETSI currently moves towards the second generation of C-ITS applications, such as Cooperative Adaptive Cruise Control (CACC), Platooning, or Safety of Vulnerable Road Users (VRU), DCC will need to deal with a larger set of V2X services and messages.
In this paper, we introduce a recent ETSI DCC proposal [7] designed to support heterogeneous V2X Services. Located at the ETSI Facilities layer [8], it allows V2X services to directly request wireless resources, whereas the legacy ETSI Access Layer DCC only blocks traffic based on WiFi traffic priority. Although providing more agile tuning of the required resources per V2X service, the interaction of Facilities DCC with Access DCC can be problematic, creating potential conflicts between legacy and Facilities DCC. Our contribu- tions are three folds: (i) we introduce the new ETSI cross- layer DCC architecture; (ii) we describe the Facilities-DCC mechanism, notably its key mechanisms to share wireless resources among V2X services; (iii) we finally integrate and evaluate the Facilities DCC with and without the Legacy DCC.
We show via simulations on the iTETRIS platform [9] that Legacy and Facilities DCC mechanisms strongly interfere, severely degrading V2X services while under-utilizing the available wireless resources. We also illustrate that DCC at Facilities layer alone performs better and is sufficient by itself to efficiently regulate V2X communications.
The rest of the paper is organized as follows: Section II gives a brief overview of the DCC mechanism, followed by Section III outlining the evolution of V2X services for C- ITS. Section IV introduces the Facilities DCC, illustrating the integration issues with Access DCC, followed by Section V providing performance evaluation results. Finally, Section VI concludes the paper.
II. DECENTRALIZEDCONGESTIONCONTROL- OVERVIEW
Operating in ad-hoc mode, V2X communication technolo- gies leave each node autonomously contend for channel ac- cess. Uncoordinated, such contention-based channel access may lead to severe packet collisions or channel resource exhaustions by potential selfish nodes. Moreover, considering that the CA service relies on broadcast transmissions only, collisions cannot be corrected. Therefore if individual trans- missions are not regulated, collisions rapidly increase with the number of neighbors, creating scalability concerns.
Cyber Physical
measuring channel
adjusting TX policies Fig. 1: DCC as Cyber-Physical System
V2V
Cooperative Awareness (Day 1)
Collective Perce ption
Local Dynamic Map Exchange
Trajectory Intent
Accurate Position and Time
Platoon Control TCU
OBU LTE
TCU OBU
LTE
Fig. 2: Heterogeneous Services for Day 2 In order to solve this problem, DCC protocols have been
developed to limit the transmit parameters, mainly transmit rate and power, of each vehicle based on channel condition.
Rate control sets the maximum number of transmissions allowed in a given period to limit the temporal utilization of channel, while power control sets the maximum power to limit the spatial channel utilization and optimize spatial reuse of wireless resources.
Conceptually speaking, DCC may be seen as a Cyber- Physical System (CPS), as shown on Fig 1, where transmit decisions are optimized based on a feedback loop from mea- sured channel conditions. The physical block in each node continuously senses the Channel Load (CL) conditions, via metrics such as Channel Busy Ratio (CBR). Based on the sensing metric from the physical block, the control algorithm in the cyber block adjusts its control parameters, i.e. trans- mit rate, transmit power, modulation or any other parameter influencing the metrics from the physical block.
DCC has been extensively studied in the literature and many protocols have been proposed for congestion control and resource allocations. Several proposals focused on trans- mission rate optimizations [1], [2] while keeping the transmit power constant. Other strategies such as [3], [4] have proposed adapting the transport power for better spatial channel usage.
Yet other works [10] have proposed hybrid adaptations of both rate and power. There are other approaches using different control parameters such as optimizing the data rate [11]
or the physical carrier sense threshold [12] based on the channel quality. Several studies [13], [14] have questioned the effectiveness of combining multiple control parameters for congestion control, as made available by the standards.
A survey of DCC mechanisms is presented in [15].
Nevertheless, almost all existing works, except a few (e.g.
[16]), deal with a single type of message i.e. CAM, when analyzing DCC strategies. The work in [16] highlights the problem of Access DCC when dealing with multiple types of packets, without considering Facilities DCC. In this paper, we implement Facilities DCC for managing resource allocation of multiple services and illustrate how Access DCC may hinder the functioning of Facilities DCC.
Several DCC protocols have been standardized for Day 1, by the Car2Car Consortium and ETSI in Europe and by Society of Automotive Engineers (SAE) [17] in the USA. The approach to the US DCC is cross-layer, which considers multiple sensing parameters, such as vehicular traffic density, packet error rate, neighbor tracking error. Until recently, the EU DCC has been mainly limited to the Access Layer. Although Access DCC would suffice for Day 1 considering a single message, unable to differentiate between services, it is not suitable for multiple messages and V2X services for Day 2.
III. V2X SERVICES FORCONNECTEDCOOPERATIVE
AUTOMATEDVEHICLES
Safety and traffic efficiency Day 1 applications in Europe are based on periodic CAM and occasionally event trig- gered messages called Decentralized Environment Notification Message (DENM). However as shown on Fig. 2, there will be multiple heterogeneous messages for Day 2 applications, realizing a concept called ‘extended horizon’, where vehicles gather information outside the range of their built-in sensors through cooperative V2X communications. The conjunction of the various V2X services and messages are critical for creating such ‘extended horizon’ and allows future automated vehicles to take optimal control decisions.
Accordingly, several new services are currently being de- veloped in Europe, which require new messages such as:
• Collective Perception Message (CPM) - ETSI TS 103 324: shares a vehicle’s various sensor information with other ITS stations.
• Position and Time Message (POTI) - ETSI TS 102 890–2: obtains precise position and time from other ITS stations.
• Local Dynamic Map (LDM) messages -exchanges of of the LDM [18] with other ITS stations.
Further down the road, communication capabilities will be used for cooperative driving and navigation, and it is expected that further messages will be developed to exchange a vehicle’s
‘trajectory intent’ (i.e. for vehicles to negotiate and coordinate their actions).
Accordingly, plethora of V2X services will have hetero- geneous packet size, periodicity, urgency, or relevance area.
Although existing congestion control mechanisms at Access layer may regulate cooperative services, without considering the heterogeneous message characteristics, new services will be penalized. Access DCC strategies can only drop or delay packets via queuing and flow control (more details in the next section). However Day 2 scenarios will require smarter strategies to distribute the sparse network resources or transmit opportunities among multiple applications, such as optimiz- ing modulation, packet size, or prioritizing information as a function of the application’s needs and context. Therefore, there is a need to regulate wireless channel resources for heterogeneous V2X services, which we analyze in the rest of this paper.
IV. ANALYSIS OFACCESS ANDFACILITIESDCCFOR
HETEROGENEOUSSERVICES
In European DCC standards, Transmit Rate Control (TRC) has been the most significant control mechanism. TRC can either limit the number of packets released into the medium
Application
Facilities
CAM CPM LDM
Network & Transport
Neighbor Table
VO
DCC Access Queue
VI BE BK
Rate Control
VO
MAC
VI BE BK
MAC Queue PHY DCC Management
Ton, Toff
# Neighbor
DCC Facilities
DCC Access
Channel Busy Ratio
Fig. 3: Simplified Architecture of ETSI DCC
via queuing and flow control, or limit the number of packets generated by V2X services. DCC Access employs the former technique, while DCC Facilities adopts the latter approach.
A. Access and Facilities DCC
DCC Access:DCC Access is the oldest part of the European DCC, released in 2011 as TS 102 687 [5] and is currently being revised. The input parameter to the DCC algorithm is the Channel Busy Ratio (CBR), which is a measure of Channel Load (CL), calculated as the proportion of time the channel is sensed busy. The output parameter is the time between two transmissions, defined as Toff. The Toff values for the corresponding CL are obtained via a table lookup, such as Table I, as in the specifications of Car2Car [19], and ETSI [5]. The highest Tx rate is 16.7 Hz for a CL < 19% when DCC is in Relaxed state, while the lowest rate is 2.5 Hz for CL ≥59%, corresponding to a Restricted DCC state.
The CL is sampled every 100ms, and for system stability and to avoid rate oscillation a hysteresis is applied to the rate change. If the transmit rate is sampled at time T0, it will be increased only if the CL is persistently lower than the load at T0 during the next 5 seconds. However, while decreasing the transmit rate, this hysteresis duration is only 1 second, thereby preferring rapid adaptations to rate decreases rather than increases.
Each message (except emergency ones) is first enqueued per packet priority in one of the 4 DCC Access queues at the MAC layer, as shown in Fig 3. After every Toff period, the next message from the highest priority queue is dequeued and released into the MAC layer Access Category (AC) queues.
Finally, a leaky bucket calledGate-Keeperand located below the DCC queues remains closed during the next Toff period.
DCC Facilities: Recently the European DCC is being ex- tended to upper layers. DCC Facilities, is being standardized as ETSI TS 103 141 [7], operates at the Facilities Layer below the Application Layer, and works in cooperation with a cross-layer entity called DCC Management, TS 103 175 [6]. Instead of direct rate control, DCC Facilities and Management calculate resources that can be allocated to a node. The goal is to equally share the channel resources among neighboring nodes,
TABLE I: Rate Control Parameters for Reactive Access DCC State Channel Load % Toff (ms) Tx Rate
(Hz) relaxed 0 %≥CL<19 % 60 16.7 active_1 19 %≥CL <27 % 100 10.0 active_2 27%≥CL <35 % 180 5.6 active_3 35%≥CL <43 % 260 3.8 active_4 43%≥CL <51 % 340 2.9 active_5 51%≥CL <59 % 420 2.4
restricted CL≥59% 460 2.2
without exceeding the global channel usage limit (commonly considered as 60% channel usage).
ChannelResourceLimitperN ode= ChannelU sageLimit
#N eighbors (1) The resource for each node is defined as the ratio of the transmit duration (i.e. Ton), to the sum ofTon andToff over a specificTon+Toff window, according to:
Ton
Ton+Tof f =ChannelResourceLimitperN ode (2) This method gives each node the flexibility to adapt its packet size or the Tx airtime Ton. As a consequence, a node may transmit multiple small packets or few larger ones by keeping the allocated resource limit (i.e. the control algorithm does not directly limit the transmit rate).
The total resource allocated to each node is in turn dis- tributed among the various applications according to traffic priority:
Ton
Ton+Tof f
= Ton
Ton+Tof f app1+...+ Ton
Ton+Tof f appN (3)
B. Analysis of DCC for Heterogeneous Services
Access DCC via table lookup, a.k.a Reactive DCC, has been shown to have flaws, even considering a single packet type. In this section, we show how it can be even more problematic considering multiple services with heterogeneous message types.
10 20 30 40 50 60 70 80 90 100
Nb of Communicating Nodes 100
200 300 400 500 600 700 800 900 1000
Packet Size (bytes)
10 10
10 10 10 10 10 10
10 10 10 10 5.6 5.6 5.6 5.6
10 10 10 5.6 5.6 5.6 5.6 5.6
10 10 10 5.6 5.6 5.6 5.6 5.6 3.8
10 10 5.6 5.6 5.6 5.6 3.8 3.8 3.8
10 5.6 5.6 5.6 5.6 3.8 3.8 3.8 3.8
10 5.6 5.6 5.6 3.8 3.8 3.8 3.8 3.8
10 10 5.6 5.6 5.6 3.8 3.8 3.8 3.8 2.9
10 10 5.6 5.6 3.8 3.8 3.8 3.8 2.9 2.9 16.7
16.7 16.7 16.7 16.7 16.7 16.7 16.7
16.7 16.7 16.7 16.7
16.7 16.7
16.7 16.7
16.7 16.7 16.7 16.7
4 6 8 10 12 14 16
Transmit Rate (Hz) per Node
Fig. 4: Theoretical Transmit Rate allowed by Access DCC
10 20 30 40 50 60 70 80 90 100 Nb of Communicating Nodes
100 200 300 400 500 600 700 800 900 1000
Packet Size (bytes)
28.1 25 22.5
30 25 21.4 18.8 16.7 15
28.1 22.5 18.8 16.1 14.1 12.5 11.3
30 22.5
18 15 12.9 11.3 10
9 25 18.8
15 12.5 10.7 9.4 8.3 7.5
21.4 16.1 12.9 10.7 9.2
8 7.1 6.4
28.1 18.8 14.1 11.3 9.4
8 7 6.3 5.6
25 16.7 12.5 10 8.3 7.1 6.3 5.6 5
22.5 15 11.3
9 7.5 6.4 5.6 5 4.5 40
40 40 40 40 40 40 40 40 40
40 40 40 40 40 37.5 32.1
40 40 40 37.5
40 40 37.5
40 40
40 37.5
40 32.1
40 40 40
5 10 15 20 25 30 35 40
TransmitRate (Hz) per Node
Fig. 5: Theoretical Transmit Rate allowed by Facilities DCC 1) Overly Restrictive, Non Optimum Rate Control: Fig. 4 shows the theoretical transmit rate allowed by the Access DCC to each node, for a various packet sizes between 100 to 1000 Bytes (y-axis), and nodes sharing the channel between 10 to 100 (x-axis). Each box on the heat map represents the maximum transmit rate allowed to each node by the Access DCC, when an equilibrium is reached between CL and transmission rate, using the rate control parameters of Table I.
Considering 10 nodes sharing the channel, each transmitting 800 Bytes packets, the transmit rate allowed is only 16.7Hz.
With a data rate of 6Mbps, such scenario will theoretically generate 17.8% CL. Therefore, even if more than 80% channel capacity is being unused, Access DCC will only allow a maximum transmit rate of 16.7Hz.
Figure 5 shows a similar heat map for a theoretical rate allowed by DCC Facilities, considering the same combination of packet size and number of communicating nodes. The channel usage limit is set to 60%, and is equally divided among the nodes according to Eq. 1 and Eq. 2. The highest rate is limited to 40Hz as set in the standard (ETSI EN 302 571). As shown in Fig. 5, Facilities DCC allows a minimum transmit rate of 4.5Hz and a maximum of 40Hz, almost twice as much compared to Access DCC. Thus Access DCC clearly wastes channel capacity, which will be needed by nodes for additional packets from multiple services.
2) Incompatibility between Access DCC & Facilities DCC:
In addition to inefficient channel usage, Reactive Access DCC has compatibility issues in the ETSI multi-layered DCC architecture, including the Facilities DCC.
As shown in Eq. 2, the Facilities DCC gives a node the flexibility to adapt its packet size and transmit rate. For example, ifTonis1msfor aToff of99ms, a node may transmit packets at 10Hz having 1ms air time, or 20Hzpackets from two applications, with airtime of 0.5ms per packet. However, if the rate control is performed by the Access DCC,Tonis not considered and a single packet only is allowed (up to 1ms), thus limiting the rate to 10Hz. Access DCC will therefore block packets allowed by Facilities DCC and thus will be conflicting with it.
V. PERFORMANCEEVALUATION
We evaluate the coordination between Access and Facilities DCC first in term of efficiency i.e. how efficiently the ap-
TABLE II: Simulation Parameters
Parameter Value
Transmit Rate CAM: 5 & 10 [Hz], CPM: 5 [Hz]
LDM: 1 [Hz]
Transmit Power 23 dBm
Packet Transmittime CAM: 0.4ms, CPM: 1.2ms LDM: 1.3ms EDCA queue CAM & CPM: Best Effort,
LDM: Background
DataRate 6 Mbps
Number of Nodes 60
Mobility Static
Simulation Time 40 seconds
PHY and MAC ITS-G5 802.11p in 5.9 GHz (10 MHz Control Channel) Fading WINNER B1 Urban Microcell
(Correlated Gaussian & Ricean) Preamble DetectionThreshold - 92 dBm
PerformanceIndicators Transmission Rate, Reception Rate 50 runs, 95% Confidence Interval
plication requirements are fulfilled considering the available channel capacity. We then also analyze the Facilities DCC in terms of agility and fairness (i.e. how it distributes the communication resources among several applications with varying transmit rates, packet sizes and traffic priorities).
A simple scenario is used, consisting of 60 nodes equipped with ITS-G5 transmitters and the ETSI ITS stack. We use the iTETRIS simulator [9], which has a full ITS-G5 protocol stack implemented on top of NS-3. We consider a fading channel according to WINNER B1 model, and all nodes are in Line of Sight (LOS) without any hidden node. Each node runs 3 applications, periodically broadcasting 3 types of packets on the same channel, 300 Bytes CAM, 900 Bytes CPM and 1000 Bytes LDM, as discussed in Section III.
For simplicity, the nodes are static in a grid formation with 5mgap between the nodes. In this work, we zoom in on several fundamental issues related to cross layer incompatibility and network resource allocations using a simple scenario, as node mobility is not essential to this analysis. We leave a more com- plete analysis with realistic mobility traces for future work.
The performance is evaluated in terms of packet transmissions and reception rates, and results are average over 50 simulation runs with 95% Confidence Interval. Table II summarizes the main simulation parameters.
Time [s]
0 5 10 15 20 25 30 35 40
Transmission Rate [Hz]
0 2 4 6 8 10 12
CAM Rate Asked CAM Rate Allowed CPM Rate Asked CPM Rate Allowed LDM Rate Asked LDM Rate Allowed
Fig. 6: Transmission Rate using Facilities DCC with Access DCC
A. Facilities DCC with Access DCC
Figure 6 shows the requested transmit rate, i.e. the packet generation rate for the 3 services on the y-axis versus time on the x-axis. It also shows the transmit rate eventually allocated when DCC Access is active along with DCC Facilities in each node. There are 60 nodes in this scenario and the channel usage limit is set to 60%. Therefore, each node is allocated 1% channel resource, according to Eq. 1. DCC Facilities distributes the 1% resource among the three services, according to Eq. 3, allowing 5Hz 300 Bytes CAM, 5Hz 900 Bytes CPM and 1.5Hz 1000 Bytes LDM.
However, DCC Access performs rate control according to parameters in Table I, which proves to be the bottleneck.
Initially, the CL is low, and the state of DCC Access is in Relaxed state, so a transmit rate of 4Hz CAM, 4Hz CPM and 1.5 Hz LDM is allowed. This creates a sudden peak of CL, as shown in Fig. 7, causing DCC Access to switch to a Restricted state and increase the non-transmit time Toff. The Restricted state allows a transmit rate of2-3Hz only (refer to Table I), which is used solely to transmit CAMs without any CPM or LDM, as CAMs have a higher priority over CPM and LDM in this work. Fig. 7 also shows the global CL, averaged over all 60 nodes. The offered load curve is the theoretical 60% CL generated considering all generated packets would be transmitted.
Nevertheless, the 2-3 Hz CAM transmissions produce a CL below 10%, which should subsequently allow a 16.7Hz rate (see Table I) considering aRelax state. Yet, this rate increase only occurs after a 5s delay. As discussed in Section IV, a 5s hysteresis is enforced before allowing any raise in transmit
Time [s]
0 5 10 15 20 25 30 35 40
Channel Load %
0 10 20 30 40 50 60 70 80 90 100
Offered Load Facilities + Access DCC Facilities DCC
Fig. 7: Channel Load with and without Access DCC
Time [s]
0 5 10 15 20 25 30 35 40
Reception Rate [Hz]
0 1 2 3 4 5 6 7 8 9 10
CAM CPM LDM
Fig. 8: Reception Rate using Facilities DCC with Access DCC
Time [s]
0 5 10 15 20 25 30 35 40
Transmission Rate [Hz]
0 2 4 6 8 10 12
CAM Rate Asked CAM Rate Allowed CPM Rate Asked CPM Rate Allowed LDM Rate Asked LDM Rate Allowed
Fig. 9: Transmission Rate using Facilities DCC alone
Time [s]
0 5 10 15 20 25 30 35 40
Reception Rate [Hz]
0 2 4 6 8 10 12
CAM CPM LDM
Fig. 10: Reception Rate using Facilities DCC alone rate, during which packets accumulate in the DCC queues and are suddenly released in a burst after the hysteresis. This results to a transmit rate peak, causing a high CL, triggering then a drop to a Restricted state, before starting the cycle over again. This results to a significant difference between application required and Access DCC granted rates. The peaks last only 1s, corresponding to the hysteresis period for rate decrease, as transmit rate decreases are favored over rate increase.
During transmit rate peaks, the grated rate surpasses even the requested rate. Such extreme values correspond to trans- mitted packets being as old as 1s (DCC queue TTL is 1 sec), only including out-of-date and useless information for the purpose of Cooperative Awareness or Collective Perception services.
Figure 8 shows the packet reception rate for scenario includ- ing DCC Facilities with DCC Access. It follows a similar trend as the transmit rate. The reception rate is about 1Hz lower than the transmission rate, which is due to packet collisions from CSMA/CA simultaneous stochastic transmissions.
Concluding, Access DCC via reactive rate control signifi- cantly wastes channel resources by excessively throttling the transmission rate. Periodically, it produces sudden jumps in transmit rate, yet transmitting out of date information only.
B. Facilities DCC alone without Access DCC
In this subsection, we analyze the performance of DCC Facilities without DCC Access. All other parameters are similar to the previous scenario, i.e. each node is allocated 1% resource which is distributed among its 3 services by DCC Facilities, allowing 5Hz CAM, 5Hz CPM and 1.5Hz LDM.
Figure 9 shows the required and allowed transmit rate for the 3 messages. The transmit rate in this scenario is much better than considering Access DCC with Facilities DCC. Removing Access DCC allows a full utilization of the 60% CL limit, and the allocated 1% channel resource per node is fully distributed by Facilities DCC among the three services respecting packet priorities.
Similarly, Facilities DCC without Access DCC performs better in terms of packet reception rate due to the absence of transmission bursts. As shown in Fig. 10, during the first 20 seconds, the reception and transmit rates are almost equal, with slight packet losses due to packet collisions at 60% CL.
Thus, considering an exact same scenario, nodes operating Facilities DCC alone achieve a reception rate of 4.5Hz for CAM and CPM, and 1Hz for LDM, much higher than the 2Hz CAM, 1.5Hz CPM and 0Hz LDM reception rates using Facilities DCC with Access DCC.
However, Facilities DCC also has issues. In this scenario, at the 20th second, the transmit request for CAM is increased from 5Hz to 10Hz, which is fulfilled by diverting the resource allocated to the LDM service, as LDM has the lowest traffic priority. The CAM service continues to emit at 10Hz, and the LDM service is throttled and is no longer given any transmit opportunity. This is due to DCC Facilities only using traffic priority to differentiate resources instead of sharing resources. In a congested scenario, a low priority packet may never be transmitted, due to Facilities DCC allowing resource monopolization by services having higher packet priorities.
VI. DISCUSSION ANDCONCLUSION
In this paper we show the incompatibility between the European DCC located at ITS-G5 Access layer (reactive table lookup [19]) and a new ETSI DCC (TS 103 141 [8]) located at Facilities layer, leading to inefficient allocations of transmit opportunities. DCC Access not only wastes channel resources, but unnecessarily queues up packets, transmitting them in delayed bursts with out-of-date information. On the other hand, DCC Facilities teamed up with a DCC Management, showed to be fully capable to fully exploit the available channel resource and distribute it efficiently between nodes and per node V2X services.
The results suggest that DCC functionalities should be removed from the Access Layer, leaving only DCC Facilities and Management to handle congestion control and channel resource allocations. Similarly, moving these functionalities at higher layers also has the benefit of the providing the opportunity to be technology neutral and be cross compatible with WiFi and Cellular V2X technologies.
However, removing DCC Access functionalities can be challenging for managing multi-hop packet forwarding, which is located at the Network layer. We believe this problem can be overcome through cross-layer synchronization and handled by DCC Management.We are currently studying the feasibility of this approach.
Similarly, DCC Facilities as described in TS 103 141 [8] is still in its infancy, and the distinction among various services is done simply via traffic priority, which showed to be prob- lematic in our analysis. To properly manage heterogeneous
Day 2 V2X services, DCC Facilities will need to apply more intelligent optimization strategies, using techniques of game theory or machine learning, in order to avoid the persistent blocking of lower priority packets during resource constraints.
This multi-service management of DCC Facilities under scarce channel resource and dynamic external conditions will be investigated in future work.
ACKNOWLEDGMENT
This work has been funded by the EU H2020 HIGHTS project (grant no. 636537). EURECOM acknowledges the support of its industrial members, namely, BMW Group, IABG, Monaco Telecom, Orange, SAP and Symantec.
REFERENCES
[1] J. B. Kenney, G. Bansal, and C. E. Rohrs, “Limeric: a linear message rate control algorithm for vehicular dsrc systems,” in8th ACM Workshop on Vehicular inter-networking (VANET), 2011.
[2] T. Tielert, D. Jiang, Q. Chen, L. Delgrossi, and H. Hartenstein, “Design methodology and evaluation of rate adaptation based congestion control for vehicle safety communications,” in IEEE Vehicular Networking Conference (VNC), 2011.
[3] B. Kloiber, J. Härri, and T. Strang, “Dice the tx power—improving awareness quality in vanets by random transmit power selection,” in IEEE Vehicular Networking Conference (VNC), 2012.
[4] M. Torrent-Moreno, J. Mittag, P. Santi, and H. Hartenstein, “Vehicle- to-vehicle communication: fair transmit power control for safety-critical information,”IEEE Transactions on Vehicular Technology, 2009.
[5] ETSI, “TS 102 687 (2011),”Decentralized Congestion Control Mecha- nisms for Intelligent Transport Systems operating in the 5 GHz range.
[6] ETSI, “TS 103 175 (2015),”Intelligent Transport Systems; Cross Layer DCC Management Entity for operation in the ITS G5A and ITS G5B medium.
[7] ETSI, “TS 103 141,” Intelligent Transport Systems; Facilities layer;
Communication congestion control.
[8] ETSI, “TS 102 894-1 (2013),” Intelligent Transport Systems (ITS);
Users and applications requirements; Part 1: Facility layer structure, functional requirements and specifications.
[9] M. Rondinone et al., “itetris: A modular simulation platform for the large scale evaluation of cooperative {ITS} applications,” Simulation Modelling Practice and Theory, 2013.
[10] M. Ruffini and H.-J. Reumerman, “Power-rate adaptation in high- mobility distributed ad-hoc wireless networks,” inIEEE 61st Vehicular Technology Conference, 2015.
[11] M. Sepulcre, J. Gozalvez, and B. Coll-Perales, “Why 6 mbps is not (always) the optimum data rate for beaconing in vehicular networks,”
IEEE Transactions on Mobile Computing, 2017.
[12] R. Stanica, E. Chaput, and A.-L. Beylot, “Physical carrier sense in vehicular ad-hoc networks,” in Mobile Adhoc and Sensor Systems (MASS), 2011 IEEE 8th International Conference on. IEEE, 2011, pp. 580–589.
[13] A. Autolitano, C. Campolo, A. Molinaro, R. M. Scopigno, and A. Vesco,
“An insight into decentralized congestion control techniques for vanets from etsi ts 102 687 v1. 1.1,” inWireless Days (WD), 2013 IFIP.
[14] A. Vesco, R. Scopigno, C. Casetti, and C.-F. Chiasserini, “Investigat- ing the effectiveness of decentralized congestion control in vehicular networks,” inGlobecom Workshops (GC Wkshps), 2013 IEEE.
[15] H. Song and H. S. Lee, “A survey on how to solve a decentralized congestion control problem for periodic beacon broadcast in vehicu- lar safety communications,” in Advanced Communication Technology (ICACT), 2013 15th International Conference on, 2013.
[16] H.-J. Günther, R. Riebl, L. Wolf, and C. Facchi, “Collective perception and decentralized congestion control in vehicular ad-hoc networks,” in Vehicular Networking Conference (VNC), 2016 IEEE.
[17] SAE, “SAE J 2945/1 on-board system requirements for v2v safety communications.”
[18] ETSI, “ETSI EN 302 895 (2014),”Intelligent Transport Systems; Vehic- ular Communications; Basic Set of Applications; Local Dynamic Map (LDM).
[19] T. Buburuzan et al., “C2C-CC basic system profile. version 1.1.0. CAR 2 CAR Communication Consortium, dec. 2015.”
