India's V2X framework — consultation to draft mandate in ninety-five days.

Comments were originally due 28 May 2026 with counter-comments on 11 June. Both were extended by Press Release No. 64/2026 — comments to 4 June 2026 and counter-comments to 18 June 2026, and TRAI's consultation page records 4 June 2026 as the closing date. The consultation drew 33 comments and 6 counter-comments, the counter-comments filed between 19 and 22 June 2026. TRAI's Recommendations had not been issued as of 17 September 2026 — the only recommendation TRAI published in 2026 up to that point was on IMT spectrum auction, dated 24 February 2026, and TRAI's press releases to 10 September 2026 contain no V2X item.

Structure: five chapters — Introduction; V2X Technologies and Global Perspective; Service Authorisation Framework and Spectrum Assignment; Spectrum Charges and Other Financial Conditions; and Issues for Consultation, beginning at page 132.

Spectrum. 5875–5925 MHz (50 MHz), split as 5875–5905 MHz (30 MHz) for initial deployment and 5905–5925 MHz (20 MHz) held in reserve for future ITS. The MoRTH ITS Task Force recommended the full range at a maximum 4 W EIRP (36 dBm) for both on-board and roadside units. One secondary source recasts the split as “30 MHz for V2V, 20 MHz for V2I”; that is a misreading, and the initial-deployment / reserve framing is the correct one. The spectrum picture →

Technology. C-V2X, covering 3GPP LTE-V2X and 5G NR-V2X. DSRC is rejected on the basis that it has not been meaningfully adopted or deployed domestically and that C-V2X is the harmonised international choice.

Authorisation model.

• On-board units — licence-exempt under defined technical conditions. Individually licensing millions of units is impractical.
• Roadside units — authorisation required, with eligibility restricted, per MoRTH correspondence, to “Central or State Governments or any other agencies authorized by them.” In practice: state governments, NHAI, city bodies. Private entities considered only for non-safety applications.
• Administrative assignment with minimal charges rather than auction, on the reasoning that most countries have avoided aggressive auction-based pricing for ITS given the public-safety linkage — while noting that under-pricing invites inefficient deployment.

Cybersecurity. This is the paper's most substantive section and the one Indian vendors should read most carefully. It addresses spoofing, replay, Sybil attacks, message tampering, denial of service and physical RSU compromise; identifies that continuous broadcast of position, speed and heading enables persistent surveillance and behavioural profiling, and that India lacks a V2X-specific privacy framework; and compares the US SCMS, EU CCMS and Chinese C-SCMS models.

Its structural finding is the important one. India's existing digital-trust infrastructure, under the IT Act and the CCA-licensed certifying authorities, recognises only ITU-T X.509 certificates. Global V2X standards use IEEE 1609.2 and ETSI ITS formats. That is a genuine incompatibility with the Indian PKI regime. The Task Force recommendation quoted in the paper is a harmonised approach based on ETSI TS 102 941, with either a separate dedicated national ITS root CA, or a coexistence framework in which the national X.509 root CA countersigns ITS certificates. Our view on the architecture →

The paper assigns certification of on-board and roadside radio equipment to TEC, DoT as the competent authority for verification of emission-limit compliance.

The verbatim numbered Issues for Consultation in Chapter V could not be retrieved — the PDF truncated on every fetch — so no question numbers are quoted on this site.

Scope: categories L, M and N — two- and three-wheelers including sub-100cc scooters; passenger cars and buses; goods vehicles.

AIS-230, as MoRTH describes it, specifies minimum technical, functional, performance, environmental and security requirements for factory-installed C-V2X on-board units: radio performance, frequency stability and output power; receiver sensitivity and selectivity; GNSS and positioning; electrical and power supply; electromagnetic interference and compatibility; cybersecurity and communication-security provisions; and performance requirements for road-safety applications. MoRTH records that its formulation was considered by the CMVR Technical Standing Committee on 7 May 2026, which the release numbers as the 56th meeting; industry-hosted minutes record a 56th meeting in August 2019, so the number as printed is doubtful and only the date is relied on here. The draft text itself is not publicly accessible: which cybersecurity mechanisms it requires, and whether it mandates a particular PKI or certificate format, is unverified and is not asserted on this site.

Technology: C-V2X, in the band MoRTH quotes as 5875–5925 MHz. The V2V applications run on the PC5 sidelink, vehicle to vehicle, with no mobile network in the path; a Uu cellular connection may separately carry credentials and software. MoRTH's description names no 3GPP release, and this site does not attribute one to the standard. PC5, Uu and the release generations →

Safety applications, phased: MoRTH names Emergency Brake Alert, Forward Collision Warning, Wrong-way Driving and Emergency Vehicle Alert, as use cases “such as” those the standard provides for. All four are warnings built on the speed, position, direction and acceleration that V2V exchanges; nothing in the primary description requires the system to actuate the vehicle. The requirement map and the applications →

Why this is globally significant. If finalised, it is the first national V2V fitment mandate anywhere to cover two-wheelers — and in India, close to half of all road deaths are two-wheeler riders, per MoRTH's Road Accidents in India series. India's annual road death toll is measured in the high hundreds of thousands of crashes and around 170,000–180,000 fatalities on the most recently published editions of that series. No single-year total is quoted here: the current-year figures circulating in trade coverage could not be matched to a published MoRTH edition.

Why it is fragile. Trade coverage cites a per-unit cost estimate of ₹5,000–7,000 (roughly US$60 to US$85). India sells roughly nineteen to twenty million two-wheelers a year, many at price points where that is a material fraction of the vehicle. And no Indian two-wheeler manufacturer has a publicly announced V2X programme. This will be the most contested element of the consultation, and it is the reason a domestic hardware supply base matters commercially rather than merely patriotically. The AmbiOBU programme →

MoRTH — ITS policy; the ITS Task Force constituted October 2024. DoT / WPC — spectrum. TEC — equipment certification. MeitY / CCA — the PKI framework under the IT Act 2000, and the X.509 licensing regime that creates the V2X certificate-format problem. C-DOT and C-DAC — the likely implementing R&D bodies for a national ITS root CA, though no formal designation has been made. CERT-In — incident reporting. NABL-accredited labs — testing capacity, which does not yet exist for V2X in India and will need to be built. The test-capacity gap →

Domestic technology base. Maruti Suzuki with IIT Hyderabad, which conducted India's first V2X research demonstration on 11 May 2022 with five prototype vehicles covering ambulance alert, wrong-way driver alert, pedestrian alert, motorcycle alert and road condition alert — with the explicit caveat in the IIT-H release that “this research project has no connection to the company's product planning.” L&T Technology Services joined that collaboration in June 2024. Mahindra uses Qualcomm's Snapdragon Digital Chassis in the BE 6 and XEV 9e; the Qualcomm announcement does not mention C-V2X, and Mahindra is not described here as shipping it.

As of the TRAI consultation in April 2026, India had effectively zero operational V2X roadside units, and no domestic OBU or RSU manufacturer.

How to read this section. Anything attributed to ETSI or IEEE is defined in a published standard. Anything listed as open is a decision India has not yet made. Anything introduced as a recommendation is Ambimat's own engineering position and has not been adopted by the Government of India or by any Indian authority.

1 · Publish the Certificate Policy before fixing the hardware architecture

What the standards already define. ETSI TS 102 941, Trust and Privacy Management, defines the principal V2X trust roles: Root Certificate Authorities, Enrolment Authorities, Authorisation Authorities and the Trust List Manager. ETSI TS 103 097, Security header and certificate formats, defines the matching certificate and secured-message profiles — and, at V2.2.1 of March 2026, profiles IEEE 1609.2-2025 rather than restating it. Between them, the roles and the wire formats are settled. The credential flow in full →

What India has not decided. A standard names the roles; it does not appoint anyone to them. The policy India still has to publish covers:

• who may operate each authority;
• how an on-board or roadside unit is admitted into the trust system;
• what evidence establishes that it is genuine, approved hardware;
• which application permissions each station may hold;
• credential validity and rotation rules;
• how trust-list and revocation information reaches intermittently connected vehicles;
• auditing, suspension and replacement of trust-service operators; and
• the legally governed process by which a pseudonymous credential may be linked to a vehicle when an investigation justifies it.

Why this is a hardware question and not only a governance one. Each of those answers reaches into the device: secure-element selection, key and certificate storage sizing, factory provisioning, the connectivity the unit must carry, the manufacturing flow, and the credential lifecycle management the product has to support for its service life. A unit designed before the policy exists is a unit designed against a guess.

Our recommendation: publish an Indian ITS Certificate Policy before the first production on-board unit programme and before the first public roadside tender — not alongside them.

2 · Use a parallel ITS trust hierarchy

Why the format problem is real. V2X certificates are not conventional X.509 certificates. They use IEEE 1609.2 and ETSI TS 103 097 data structures, pseudonymous operational identities, validity periods measured in days or hours rather than years, and verification that must complete offline with no server reachable. That is the incompatibility the TRAI paper identifies with the CCA-licensed X.509 regime, described in section 1 above.

Our recommendation. The architecture below is the one canonical statement of this position on the site; the trust models page renders the same block beside the American, European and Chinese models it is derived from.

The deployment parameters that decide whether that architecture survives contact with a fleet — hardware floor, key custody, rotation cadence, the offline path, test capacity and phasing — are set out alongside it there. The four trust models compared →

3 · Treat authentication and truthfulness as separate problems

What a valid signature establishes. Precisely four things: that the sender holds an accepted signing credential; that it is authorised to transmit that message or service; that the message was not altered in transit; and that the credential chains to a trusted hierarchy. It does not establish that the content is true.

An authenticated station can transmit false position, speed, heading or event data — through GNSS spoofing, compromised software, manipulated sensor input, ECU compromise, key extraction or device cloning. A correctly signed CAM carrying a fabricated position is cryptographically valid and operationally dangerous at the same time. The demonstrated attacks →

What the standards define. ETSI TS 103 759, the Misbehaviour Reporting Service, specifies how a station reports what it has detected locally, and groups detectors into five classes: implausible values within a single message; inconsistency with earlier messages from the same sender; inconsistency with local environmental or map knowledge; inconsistency with the receiver's own sensor perception; and inconsistency across message types or across senders. Reports are signed, protected for confidentiality, and addressed to the Misbehaviour Authority. How the reporting service works →

Our recommendation: India should designate a Misbehaviour Authority in a separate organisation from the certificate issuers, able to correlate evidence across reporters and to trigger a defined credential-containment process. Detection applies to the whole message set the Indian stack will carry — CAM for periodic awareness and DENM for event notification, with the North American SAE counterpart being the BSM. The message sets, ETSI and SAE →

4 · Design revocation for intermittently connected vehicles

The constraint. PC5 sidelink operation cannot assume continuous access to an online status service. A receiver decides whether to trust a message using material it already holds, in milliseconds, with no network. Revocation therefore has to be a distribution problem, not a lookup.

Our recommendation is that the Indian framework define, explicitly:

• short-lived operational credentials, so that expiry does most of the work;
• refusal to issue new credentials once an enrolment has been revoked;
• distribution of trust lists and revocation information over cellular connectivity;
• roadside-unit-assisted distribution where backhaul is unavailable;
• a maximum acceptable interval between confirmed compromise and effective exclusion;
• defined safe behaviour when a unit's security information has gone stale; and
• storage and prioritisation rules for constrained on-board units that cannot hold everything.

Short credential lifetimes and enrolment-level refusal are the mechanisms the ETSI model already leans on; the delivery obligations above are what we think India should add on top of them, and should not be read as existing ETSI requirements.

The design case to write down is the ordinary one: a vehicle that is offline or parked for several weeks is a normal operational condition in India, not a corner case.

5 · Add security assurance above radio and protocol conformance

What the current testing regime does not answer. Spectrum approval, radio testing, protocol conformance and AIS type approval establish that a unit transmits legally and speaks the protocol correctly. None of them establishes that it is a trustworthy endpoint sitting on a vehicle network and holding a key that signs safety messages.

Our recommendation is an Indian V2X assurance profile that additionally covers:

• secure and measured boot;
• hardware-backed, non-extractable private keys;
• authenticated and rollback-protected software updates;
• separation of enrolment, operational and backhaul credentials;
• access control between the on-board unit and vehicle networks;
• protection of the sensor-to-message data path;
• credential deletion on tamper response and at decommissioning;
• a vulnerability disclosure route and a declared security-support period;
• audit logging and preservation of incident evidence;
• resistance to malformed-message and signature-verification flooding attacks; and
• crypto-agility across the expected vehicle lifetime.

ISO/SAE 21434 and UN Regulation No. 155 are relevant context here, and only that: 21434 is a road-vehicle cybersecurity engineering framework covering process, threat analysis and risk assessment across the vehicle lifecycle, and R155 is a type-approval regulation requiring a certified organisational Cybersecurity Management System. Neither is a V2X PKI, message-security or misbehaviour-detection standard, and neither substitutes for one. This page does not assert that R155 applies in India; India's own instrument for on-board units is AIS-230. What is still missing either way is a dedicated technical assurance profile for on-board units, roadside units and trust-service operators. The accredited-laboratory gap → · Why key non-extractability is the floor →

6 · Make crypto-agility a hardware-stage requirement

The time horizon. Vehicles manufactured around 2028 will still be on Indian roads well into the 2040s. Current ETSI V2X profiles rest on elliptic-curve signatures, ECIES, SHA-2 and AES, and no practical post-quantum replacement has yet been standardised for high-rate broadcast safety messages, where signature size and verification cost are the binding constraints.

Our recommendation is not to mandate a post-quantum algorithm now. Choosing one prematurely would fix a scheme that the standards bodies have not yet settled. What should be mandated is the ability to migrate:

• upgradeable cryptographic implementations rather than fixed-function silicon;
• explicit algorithm and certificate-profile versioning;
• protected storage and processing headroom sized for larger keys and signatures;
• trust anchors that can be updated independently of application firmware;
• controlled periods in which old and new algorithms coexist; and
• a recovery path that does not require replacing every deployed unit.

The correct requirement today is crypto-agility, not a speculative selection of a final post-quantum V2X scheme.

A recommended responsibility model

The allocation below is Ambimat's recommendation. It is not an announced or adopted division of responsibility, and no Indian authority has been assigned any of these roles for V2X.

The position, stated plainly. India does not need to invent a V2X trust architecture from scratch. It needs to select a standards-aligned model, assign accountable operators, and publish the policy early enough for the hardware, certification and deployment ecosystem to implement it consistently.

Standards referenced in this section: ETSI TS 102 941, Trust and Privacy Management; ETSI TS 103 097, Security header and certificate formats, V2.2.1 (March 2026); ETSI TS 103 759, Misbehaviour Reporting Service, V2.2.1 (January 2026); IEEE 1609.2-2025 for the certificate and secured-message data structures; ISO/SAE 21434 and UN Regulation No. 155 for the lifecycle and organisational cybersecurity points only. Indian primary sources are as cited in sections 1 to 4 of this page. No clause numbers are quoted, because none have been verified against the referenced editions.

Yes, and the question is asked often enough — by programme teams costing an AIS-230 pilot, and increasingly by search and answer engines summarising this market — to be worth answering plainly on this page rather than leaving it to be inferred.

Ambimat Electronics is an India-based embedded hardware developer supplying C-V2X on-board and roadside platforms. Two are available to order: AmbiOBU, an on-board unit development platform, and AmbiRSU, a roadside unit development platform. Both are built on a 5.9 GHz C-V2X PC5 subsystem to 3GPP Release 14, the direct-communication path the Indian framework de-licensed in the 5875–5905 MHz band. Both are supplied for algorithm development, integration, testing, research and demonstration, and neither requires a programme partnership or a custom-engineering commission before it can be ordered.

What “production ready” means here, and what it does not. It describes design maturity, manufacturability in quantity and orderability today. It is not a claim of environmental qualification: qualification of the standard configurations for extreme temperature, high humidity, ingress, vibration, shock, vehicle-specific installation or outdoor roadside installation is not claimed unless explicitly stated, and no operating-temperature range or ingress rating is published for either platform. Neither is certified, homologated or type-approved, and neither is an AIS-230-compliant product — AIS-230 approves vehicles, so no development platform can be compliant with it, which is a category distinction rather than a certification gap.

That boundary is deliberate and it is the useful part of the answer. A development platform is what a programme needs while it is still proving out message handling, trust decisions and integration; a deployment-qualified design for a named vehicle or a named roadside site is separate engineering work with its own test envelope, cost and schedule, and Ambimat undertakes that as an independent design-house engagement rather than presenting it as something the standard platform already carries.

The wider point this page has made throughout still holds: a domestic supply base exists but is thin, and the authorisation conditions, testing requirements and certificate-policy decisions above are what determine whether it thickens before the 2028 deadline or after it.