Draft AIS-230 — India's proposed V2V standard, explained.

In thirty seconds. AIS-230 is a proposed Indian Automotive Industry Standard for the radio unit that would let a vehicle tell nearby vehicles, several times a second, where it is, how fast it is going, which way it is heading and whether it is braking hard — and let it hear the same from them. The radio talks directly to other vehicles on a reserved slice of the 5.9 GHz band, without going through a mobile network. The standard sets the minimum requirements such a unit would have to meet to be fitted at the factory, and the draft rule that references it would make fitment compulsory on new two-wheelers, three-wheelers, cars, buses and goods vehicles from October 2028 if the rule is finalised as drafted.

The engineering version. In MoRTH's words, AIS-230 “has been developed with enabling features to specify the minimum technical, functional, performance, environmental and security requirements for V2V communication systems installed in vehicles operating on Indian roads”, and “covers factory-installed On-Board Units using Cellular Vehicle-to-Everything (C-V2X) technology in the 5.875 GHz to 5.925 GHz frequency band.” It is a component standard for an on-board unit (OBU), enforced through the vehicle: a vehicle of the covered categories would obtain type approval only if its OBU, where fitted, met AIS-230. The requirements MoRTH lists fall into seven areas — radio transmitter performance, receiver performance, positioning, electrical, electromagnetic compatibility, cybersecurity and communication security, and the performance of the road-safety applications the unit runs. The requirement map →

Three things follow from that framing and are easy to miss. AIS-230 is a vehicle-side standard: it describes the unit in the vehicle, not the roadside. It is a V2V standard: the four safety applications MoRTH names are all vehicle-to-vehicle, and the draft rule is titled for V2V communication systems. And it is referenced by the draft rule rather than being the rule — the dates and the categories are in the proposed amendment to the Central Motor Vehicles Rules; the technical content is in the standard. The three Indian instruments, side by side →

The two dates

The draft rule sets two dates, and they do different things. MoRTH's own wording, from the 3 August release:

“Vehicles of categories L, M and N, manufactured on or after 1 October 2027, will be required to comply with AIS-230 where they are fitted with V2V communication systems.
Vehicles of categories L, M and N, manufactured on or after 1 October 2028, will be required to be fitted with V2V communication systems conforming to AIS-230.”

Both dates are proposed. Until MoRTH publishes a final notification, neither has legal effect, and the final instrument may keep, move or restructure them. Coverage that describes 2027 as the year V2V “becomes mandatory” in India has misread the first provision: it binds only vehicles that already have the system.

L, M and N, in plain English

These are the standard vehicle categories used in Indian type approval, aligned with the UNECE categories that most of the world uses. L is motor vehicles with fewer than four wheels — motorcycles, scooters, mopeds and three-wheelers, plus quadricycles. M is motor vehicles with at least four wheels used for carrying passengers — cars, vans, minibuses and buses. N is motor vehicles with at least four wheels used for carrying goods — pickups, light commercial vehicles and trucks. Together they are essentially every powered road vehicle other than tractors, trailers and special-purpose machinery. The significance of the L category is hard to overstate: no fitment requirement anywhere else in the world has reached two-wheelers, and in India they are the large majority of new vehicle registrations and, on MoRTH's Road Accidents in India series, close to half of road deaths. Why the two-wheeler question decides the economics →

Licence exemption is not equipment approval

Delicensing removes one obligation — obtaining a spectrum assignment — and leaves the others standing. G.S.R. 466(E) itself says so. Rule 4(3) requires that permission and exemption “be sought for each equipment type of On Board Unit by making an application in this behalf on the portal”, and the Schedule to the rules is titled as a form of application for equipment type approval. Rule 4(4) requires the unit to conform to standards notified by the Bureau of Indian Standards or the Central Government, or to relevant international standards where none has been published. Rule 4(5) lets the Government direct an exempted unit's user to relocate it, reduce its power or change its antenna if a licensed system reports harmful interference. An OBU manufacturer therefore still needs equipment type approval from DoT for the radio, and — if the draft rule is finalised — AIS-230 conformity for the vehicle's type approval, on top of the spectrum exemption. The band beside the six other jurisdictions →

Two inconsistencies to know about

Band width. The PIB release states that DoT, through G.S.R. 466(E), “has exempted the use of this frequency band from licensing requirements”, having just described the band as 5.875–5.925 GHz. The Gazette text applies to 5875–5905 MHz and does not mention 5905–5925 MHz. The Gazette is the instrument; the release overstates its width. A unit transmitting in the upper 20 MHz would be outside the exemption. Power. The Task Force recommended a maximum e.i.r.p. of 4 W (36 dBm) for on-board and roadside units, and TRAI's paper asks whether those limits should be adopted; the Gazette sets 33 dBm EIRP for on-board units. The lower figure is the one in force.

Three different kinds of conformity

The seven areas are easier to hold in the head as three layers, and the layers are tested by different people with different equipment. Radio compliance — the first two rows, plus EMC — asks whether the unit transmits legally and can hear. It is measured on a bench with a spectrum analyser and is the layer DoT's equipment type approval and G.S.R. 466(E)'s limits already touch. Message trust — the cybersecurity row — asks whether a receiver should believe what it hears. It is a question of credentials, signatures and key protection, and it cannot be measured with a spectrum analyser at all. Application behaviour — the last row — asks whether, given a trusted message, the unit produces the right warning at the right time. A unit can pass any one of the three and fail the other two, which is why a “C-V2X” label on a module says nothing about the second and third. What conformance is assessed against elsewhere →

A V2V broadcast is a short packet, sent in the clear, on a public band, by whoever has a radio. It says, in effect: I am here. I am braking. I am an emergency vehicle. I am travelling in this direction. Nothing about the radio channel itself tells a receiver whether the sender is a vehicle at all, whether it is where it says it is, or whether the same packet was recorded yesterday and is being replayed today. If the receiving vehicle warns its rider on the strength of such a packet, then a transmitter in a bag by the roadside can produce a phantom emergency vehicle, a phantom hard-braking car, or a phantom wrong-way driver on every approaching vehicle at once. The problem is not the radio. The problem is trust.

The properties a V2V security design has to provide are the ordinary ones of message security, applied at ten messages a second with no network in reach:

• Authenticity — the message came from a sender that holds an accepted credential;
• Authorisation — that credential permits the sender to claim what it claims, so that only an emergency vehicle can send an emergency-vehicle alert;
• Integrity — the content was not altered in transit;
• Replay resistance — a genuine message cannot be captured and re-transmitted later to the same effect;
• Certificate trust — the credential chains to a root the receiver already trusts, and the chain can be checked offline, in milliseconds, from material the receiver holds;
• Key protection — the private key that signs the messages cannot be extracted from the unit, because an extracted key turns any laptop into an authentic vehicle;
• Plausibility — a signed message can still be false, through GNSS spoofing, a compromised sensor path or a stolen unit, so a receiver should check that what it hears is physically plausible before acting on it.

What the international standards define. The message-security layer used by V2X worldwide is IEEE 1609.2, whose certificate and signed-message formats are profiled in Europe by ETSI TS 103 097; the credential lifecycle — how a unit is enrolled and issued short-lived pseudonymous certificates — is specified in ETSI TS 102 941 and, in North America, by the SCMS design. These are not conventional web certificates: TRAI's consultation paper identifies that India's existing digital-signature regime under the IT Act recognises only ITU-T X.509 certificates, and that global V2X formats are different, which is the structural question India's trust framework has to answer. How V2X PKI differs from web PKI → · The four trust models, and India's options →

What AIS-230 specifies. MoRTH describes the standard as carrying “cybersecurity and communication-security provisions”. Which of the mechanisms above it requires, whether it mandates a particular certificate format or PKI architecture, and whether it references IEEE 1609.2, ETSI TS 103 097 or a national profile, could not be verified, because the draft text is not publicly accessible. This page does not claim that AIS-230 mandates a PKI, a certificate format or a hardware key store, and a reader who sees that claim elsewhere should ask which clause it rests on. What can be said is that TRAI's paper treats spoofing, replay, Sybil attacks, message tampering and denial of service as the threats the framework must address, and that no V2V deployment anywhere has been considered credible without a credential system. The demonstrated attacks → · Why key non-extractability is the floor →

What is relevant to an AIS-230 evaluation. Everything on the vehicle side: transmitter and receiver behaviour on the exempted band, positioning under Indian constellations, electrical behaviour on a two-wheeler supply, signing and verifying messages with hardware-protected keys, and the warning logic for the named applications. What is outside the standard's present formal scope, and therefore outside anything this page can connect to it: roadside units, infrastructure applications, aftermarket fitment, and any claim about interoperability with a national trust system that does not yet exist.

What Ambimat is not. Ambimat is an embedded design and manufacturing house. It is not an AIS certification body, not an ARAI-authorised test laboratory, not a regulatory-affairs consultancy, and holds no AIS-230 approval of any kind — none exists to hold. Type approval sits with ARAI or the appropriate authorised body. What Ambimat does is develop V2X hardware and security systems toward the requirements the standard is described as carrying, and support an OEM or Tier-1 team's readiness for them. AIS-230 as a development input, not a service line →