• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer

Microcontroller Tips

Microcontroller engineering resources, new microcontroller products and electronics engineering news

  • Products
    • 8-bit
    • 16-bit
    • 32-bit
    • 64-bit
  • Applications
    • 5G
    • Automotive
    • Connectivity
    • Consumer Electronics
    • EV Engineering
    • Industrial
    • IoT
    • Medical
    • Security
    • Telecommunications
    • Wearables
    • Wireless
  • Learn
    • eBooks / Tech Tips
    • EE Training Days
    • FAQs
    • Learning Center
    • Tech Toolboxes
    • Webinars/Digital Events
  • Resources
    • Design Guide Library
    • DesignFast
    • LEAP Awards
    • Podcasts
    • White Papers
  • Videos
    • EE Videos & Interviews
    • Teardown Videos
  • EE Forums
    • EDABoard.com
    • Electro-Tech-Online.com
  • Engineering Training Days
  • Advertise
  • Subscribe

How do the seven types of V2X connectivity work?

June 21, 2023 By Jeff Shepard

Vehicle-to-everything (V2X) communication includes vehicle-to-network (V2N), vehicle-to-infrastructure (V2I), vehicle-to-vehicle (V2V), vehicle-to-cloud (V2C), vehicle-to-pedestrian (V2P), vehicle to device (V2D), and vehicle to grid (V2G).

This FAQ begins with a review of dedicated short-range communication (DSRC) and cellular vehicle-to-everything (C-V2X) technologies for V2X communications, looks at the four V2X service types and the structure of telematics control units (TCUs) and related MCUs used to implement V2X, presents integrated V2X communication modules and closes with an overview of vehicle platooning using V2X communications.

V2X is most often implemented using DSRC or C-V2X technologies for very high-speed and high-frequency data exchange (up to 10 times per second with millisecond latency). This low latency communications infrastructure can enable red-light running warnings rear-end crash protection, curve speed warnings, road weather warnings like black ice, motorcycle warning, intersection assistance, and more.

C-V2X technology does not rely on cellular networks. It uses the underlying technology in cellular radios, adapted for direct communications between platforms in V2X networks. C-V2X and DSRC have several similarities including:

  • Use of the 5.9 GHz band
  • The same message protocols and use cases are defined in SAE J2735 and J2945
  • Digital signatures and public key cryptography are used to support security and trust in message sources
  • There is no dedicated connection between radios. Each radio broadcasts location, speed, acceleration, and other information while at the same time listening for data from other radios.

The two technologies also have differences. DSRC uses a wireless standard called Wireless Access for Vehicular Environments (WAVE) that was specifically designed for V2X communication, and it uses the WAVE Short Message (WSM) structure. C-V2X uses long-term evolution (LTE) cellular technology. The two protocols are not compatible.

DSRC has a range of about 300 m, with a longer range possible in some circumstances. C-V2X can provide up to 30% more range and better performance when confronted with obstructions. Both technologies provide adequate performance for the intended use cases (Figure 1). DSRC was the first V2X technology to be developed and has been deployed in Japan, the U.S., and Europe. China is moving ahead with the deployment of C-V2X.

Table 1. DSRC and C-V2X have similar use cases and security capabilities but use different communications protocols and connectivity technologies (table: Autotalks).

Four V2X service types
V2X is a key element in an intelligent transport system (ITS) that’s expected to reduce or eliminate traffic congestion and improve efficiency and safety. It’s implemented with a V2X applications server that connects to the user equipment (UE) in the vehicles. The system architecture uses local gateways (L-GW) to provide localized services and reduce latencies. Four types of V2X services are defined (Figure 1):

  • V2V where both peers are UEs integrated into vehicles
  • V2P where one peer is a UE integrated into a vehicle, and the other peer is a UE used by an individual including pedestrians, bicyclists, and motorcyclists
  • V2I, where one peer is a UE integrated into a vehicle, the other peer is stationary infrastructure, called a roadside unit (RSU)
  • V2N where one peer is a UE integrated into a vehicle, and the other peer is a V2X application server
Figure 1. The seven types of V2X connectivity are used to deliver four types of V2X services (image: Rhode & Schwarz).

Telematics control units and MCUs
The TCU has direct access to the external environment and is part of the unsecured or exposed domain of the in-vehicle network. Other unsecured domains can include the in-vehicle infotainment (IVI) system and the onboard diagnostics unit (OBDU). A security gateway separates the unsecured domains from the secured interior communications buses of the vehicle. The security gateway can be a separate module or integrated into the TCU. When a separate module is used, automotive Ethernet (100BASE-T1 or 1000BASE-T1) connects the TCU to the security gateway (Figure 2).

Figure 2. TCUs require a security gateway to isolate the secure domain in most of the vehicles from the unsecured domain that connects to the outside world (image: Micron).

TCUs can be found directly below the ‘shark fin’ on the roof of the vehicle. The fin contains the antennas needed for a range of connectivity including cellular, global navigation systems (GNSS), digital video broadcasting (DVB), digital audio broadcasting (DAB), satellite radio systems, and V2X. That placement reduces the need for costly and lossy antenna cables, but it can get very hot when the vehicle is parked in the sun and demands high-temperature components including MCUs.

In a V2X application, an MCU called a hardware security module (HSM) for storing private keys and handling V2X security operations can be integrated into the TCU. The HSM includes functions like elliptic curve cryptography (ECC) private key management (generation, derivation, deletion), elliptic curve digital signature algorithm (ECDSA) signature generation, elliptic curve integrated encryption scheme (ECIES) encryption and decryption, and related data storage.

The HSM hardware architecture is often built around a 32-bit Arm SecurCore SC300 CPU with a hardware coprocessor for asymmetric cryptography and a separate high-performance cryptographic engine. The HSM communicates with the application processor through an SPI interface with data protection (Figure 3).

Figure 3. V2X system architecture shows the application processor (center) and HSM module processor (right) (image: Infineon).

HSMs are available with preprogrammed firmware; both the hardware and firmware are security-certified and ready for integration with various host application processors. Secured firmware updates with end-to-end protection are also available, and the use of a discrete HSM can provide a solution that’s agnostic to existing or upcoming modem standards, further extending design flexibility. Exemplary HSM features include:

  • Cryptographic functions according to IEEE 1609.2 and ETSI TS 103 097
  • Support for DSRC and C-V2X communication
  • Common Criteria-certified hardware platform at EAL6+ (high) according to security IC platform protection profile
  • Common Criteria-certified at EAL4+ and compliance with CAR 2 CAR Communication Consortium Protection Profile V2X Hardware Security Module
  • Support for major vehicle credential management systems including Security Credential Management System (SCMS), C-ITS Security Credential Management System (CCMS), and Efficient Security Provisioning System (ESPS)
  • Personalization that leverages a set of chip-unique and customer-individual certificates and keys enabling vendor verification, pairing, and transport protection
  • Signature generation performance of 20 signatures/sec.
  • Secured storage of private keys, V2X public key infrastructure (PKI) certificates, and sensitive customer-specific data

V2X communications modules
In some instances, the use of a V2X communications module can provide a solution to implementing V2V and V2I connectivity. The modules can support the V2X software stack from a variety of suppliers and are offered in two versions, one for use in systems with a built-in host processor and one for use in host-less systems. In addition, these modules can be programmed to support DSRC or C-V2X protocols. As a result, V2X designs can address vehicles built for Asia, Europa, and North America with the same module by simply changing the software configuration (Figure 4).

Figure 4. V2X modules are available that can implement DSRC or C-V2X protocols through software configuration (image: Murata).

Platooning
Vehicle platooning is envisioned as an advanced use of V2X communications. Platooning offers the potential for higher traffic densities plus increased safety, reduced fuel consumption and lower CO2 emissions. However, it presents a higher number of attack surfaces and presents significant security challenges.

As currently envisioned, the implementation of platooning will require the development of two technologies, cooperative adaptive cruise control (CACC) and a Vehicular Ad hoc NETwork (VANET). CACC is a cooperative extension of existing adaptive cruise control where vehicles in the platoon communicate the need to change speed or direction, and other vehicles can proactively respond. VANET will be used to exchange information such as vehicle location, speed, and acceleration. The VANET will extend beyond the platooned vehicles and will include a range of nearby nodes like cameras, pedestrians, and other road side units (RSUs).

Vehicles in a platoon use beaconing to maintain formation by continuously communicating their position, speed, acceleration or deceleration, direction, and other information to all other vehicles in the platoon. Three types of vehicles are defined in a platoon (Figure 5):

The lead vehicle is primarily driven manually for maximum safety with autonomous features used only to provide enhanced safety and driver information.

Member vehicles are primarily driven with autonomous functions, and the driver functions as an observer to maintain safe operation.

Join/leave vehicles can transition into or out of the platoon. When they join a platoon, they are driven manually until it’s deemed safe for them to switch to autonomous mode and fully integrated into the platoon. When leaving the platoon, they remain in autonomous mode until clear of the other vehicles when the driver can take manual control if needed.

Figure 5. Platooning is envisioned as an advanced application for V2X communications that can support higher traffic densities and reduce CO2 emissions (image: MDPI sensors).

Summary
The seven types of V2X communications include V2N, V2I, V2V, V2C, V2P, V2D and V2G. They can be deployed using DSRC or C-V2X communication technologies. Security is a key to successful V2X systems and can be implemented through a centralized security gateway, integrated into the TCU, or included in both. V2X systems can be built using discrete MCU-based designs or modules and support four basic types of V2X services. Advanced architectures like vehicle platooning are expected to support higher traffic densities with lower CO2 emissions.

References
DSRC and C-V2X: Similarities, Differences, and the Future of Connected Vehicles, Kimley Horn
DSRC vs. C-V2X for Safety Applications, Autotalks
Integrating V2X Into Telematics Architectures, Micron
Introduction to the vehicle-to-everything communications service V2X feature in 3GPP release 14, Rhode & Schwarz
Plug & play solution for secured V2X communication, Infineon
Vehicular Platoon Communication: Architecture, Security Threats and Open Challenges, MDPI sensors

You may also like:


  • How do MCUs support automotive infotainment systems?

  • What are the five levels of vehicle connectivity?

  • What’s different about MCUs for use in vehicle networking?

  • How many internal memories does an MCU have?

  • Exceptions, traps, and interrupts, what’s the difference?

Filed Under: Automotive, FAQ, Featured, microcontroller Tagged With: FAQ

Primary Sidebar

Featured Contributions

Engineering harmony: solving the multiprotocol puzzle in IoT device design

What’s slowing down Edge AI? It’s not compute, it’s data movement

Five challenges for developing next-generation ADAS and autonomous vehicles

Securing IoT devices against quantum computing risks

RISC-V implementation strategies for certification of safety-critical systems

More Featured Contributions

EE TECH TOOLBOX

“ee
Tech Toolbox: EMC/EMI
EE World has assembled a collection of articles that demonstrate how to measure emissions with simple antennas. We include a review of a handheld spectrum analyzer. We also look at EMC issues with IoT devices.

EE Learning Center

EE Learning Center

EE ENGINEERING TRAINING DAYS

engineering
“bills
“microcontroller
EXPAND YOUR KNOWLEDGE AND STAY CONNECTED
Get the latest info on technologies, tools and strategies for EE professionals.

DesignFast

Design Fast Logo
Component Selection Made Simple.

Try it Today
design fast globle

Footer

Microcontroller Tips

EE World Online Network

  • 5G Technology World
  • EE World Online
  • Engineers Garage
  • Analog IC Tips
  • Battery Power Tips
  • Connector Tips
  • DesignFast
  • EDA Board Forums
  • Electro Tech Online Forums
  • EV Engineering
  • Power Electronic Tips
  • Sensor Tips
  • Test and Measurement Tips

Microcontroller Tips

  • Subscribe to our newsletter
  • Advertise with us
  • Contact us
  • About us

Copyright © 2025 · WTWH Media LLC and its licensors. All rights reserved.
The material on this site may not be reproduced, distributed, transmitted, cached or otherwise used, except with the prior written permission of WTWH Media.

Privacy Policy