AmbiRSU — the C-V2X Roadside Unit (RSU) development kit, and the stationary node.
AmbiRSU is a Cellular Vehicle-to-Everything (C-V2X) Roadside Unit (RSU) development kit — roadside V2X hardware for infrastructure, vehicle manufacturer (OEM) and research integration work, from Ambimat Electronics, an embedded design and manufacturing house in Ahmedabad, India. It is a mature, production-ready V2X development platform available to order from Ambimat, built around a direct 5.9 GHz C-V2X PC5 radio at 3GPP Release 14 with a global navigation satellite system (GNSS) receiver, a separate 4G LTE backhaul and optional AmbiSEC security. It is not certified, homologated or type-approved, and no ingress rating or environmental qualification is claimed for the standard configuration.
A roadside unit is the equipment mounted beside or above the road — on a pole, a gantry or a signal head. It is the stationary participant: fixed position, known location, signing the infrastructure messages a vehicle acts on. The kit is supplied for algorithm development, integration, testing and demonstration, with no programme partner required first, and manufacturable in quantity. Production ready describes that maturity and orderability rather than environmental qualification, and it is not a certified production roadside product. Choose a development setup →
An On-Board Unit talking to a Roadside Unit is Vehicle-to-Infrastructure (V2I) communication — a signal, a work zone or a hazard telling an approaching vehicle something its own sensors cannot see. It is meant to be developed against the On-Board Unit development kit rather than in isolation, because a roadside node with nothing to talk to proves very little.
A roadside unit is permanent outdoor infrastructure carrying real-time road-safety communications, which makes it a rather different engineering problem from traffic equipment that only reports upward. India has effectively no deployed RSUs and no domestic manufacturer.
AmbiRSU is available to order from Ambimat.
AmbiRSU is a mature, production-ready V2X development platform available to order from Ambimat. It is supplied for algorithm development, integration, testing, research and demonstration — a complete roadside-unit development endpoint, not a bare radio evaluation board. No programme partner and no custom-engineering commission is required first. Environmental qualification of the standard configuration for extreme temperature, high humidity, ingress, vibration, shock or outdoor roadside installation is not claimed unless explicitly stated; homologation and certification for a permanent roadside installation remain specific to the final integrated product, the site and the target programme. Choose a development setup →
Download the AmbiRSU datasheet (PDF, 4 pages) — the development configuration, interfaces, security status and qualification boundary in one document.
The roadside counterpart to AmbiOBU, on the same foundation.
AmbiRSU is a configurable roadside V2X development platform built on the same compute, positioning, connectivity and ROS 2 software foundation as AmbiOBU. It is intended for vehicle-to-infrastructure and infrastructure-to-vehicle research and roadside integration work — not presented as a certified production roadside unit.
| Component | Development configuration |
|---|---|
| Product class | Mature, production-ready roadside V2X development platform, available to order from Ambimat. Static endpoint, supplied for algorithm development, integration, testing and demonstration, and manufacturable in quantity. Environmental qualification of the standard configuration for extreme temperature, high humidity, ingress, vibration, shock or outdoor roadside installation is not claimed unless explicitly stated; it is not a certified production roadside unit, not homologated and not type-approved |
| Compute | NVIDIA Jetson Orin Nano Super, 8 GB LPDDR5 — the same compute platform and memory configuration as AmbiOBU. Why both endpoints share it → |
| Operating environment | Ubuntu 22.04 LTS |
| Developer middleware | ROS 2 Humble Hawksbill — C++ and Python development against documented interface packages |
| Software | AmbiV2X Developer Stack — the same application and integration environment as AmbiOBU |
| Direct V2X | 5.9 GHz C-V2X PC5 subsystem, 3GPP Release 14, the same radio baseline as AmbiOBU, including C-V2X power-saving modes where applicable. PC5 is the direct communication path to nearby V2X participants; the local exchange does not go through a mobile network. This is the only radio direction Ambimat develops and supplies for V2X. What Release 14 and PC5 are → |
| GNSS | u-blox MAX-M10S — a u-blox M10 standard-precision GNSS module, professional grade, with concurrent reception of four constellations: GPS/QZSS L1C/A, Galileo E1-B/C, GLONASS L1OF and BeiDou B1I/B1C, all in the L1 band. u-blox specifies typical 1.5 m CEP under its own stated test conditions. The positioning detail → Why a roadside unit still needs GNSS time → |
| Motion sensing | 9-axis IMU — accelerometer, gyroscope, magnetometer. A static roadside node does not need inertial data to function; it is present because the common hardware baseline is deliberate, and it makes device-state data available for installation alignment, pole-movement or vibration studies, and platform experiments where a programme wants it |
| Cellular | SIMCom A7672-series 4G LTE Cat 1 module for backhaul, telemetry, remote diagnostics, backend and IP services. This cellular connection is separate from the direct C-V2X radio and does not provide PC5. |
| Security | Optional AmbiSEC integration. Where included, AmbiSEC provides protected key storage, protected cryptographic operations and device-bound identity for the roadside endpoint. The V2X message-security implementation that uses them is being developed, on the same basis and with the same boundaries as the vehicle-side platform. What is implemented and what is being developed → |
| Protocol development | IEEE 1609.3-2020 including WSMP and WME, IEEE 1609.2-2016, and SAE J2735-2022 message development — BSM, SPaT, TIM and MAP as candidate messages, with the profile selected per programme. Development and integration, not certified conformance |
| Roadside interfaces | Programme-configurable. Traffic-signal and controller data, externally supplied intersection state, road and environment sensors, backend systems and experimental instrumentation are scoped to the target programme rather than fixed in advance |
| Enclosure and environment | Defined per programme. Enclosure, environmental protection, mounting, power conditioning and site interfaces are specified according to the development or pilot programme. No ingress rating, environmental qualification or roadside homologation is claimed for the development platform |
| Power input | 12 VDC development supply, distributed through the Ambimat AE170 Power Distribution Unit (V02.04) to the internal development electronics. The AE170 provides regulated rails — 19 V at 3 A, 12 V at 2 A and 5 V at 1 A — and the compute platform is supplied from the 19 V rail. The 12 VDC figure is the external development input; it is not the voltage every internal component runs at. This is a development-platform power architecture: no mains input, no Power over Ethernet, no automotive 24 V compatibility, and no surge, lightning or roadside power-conditioning qualification is claimed. Site power conditioning beyond this input remains scoped to the programme |
What AmbiRSU is not. It is not part of the optional 1:10-scale movable development platform — that belongs to the on-board unit, which is the moving participant. AmbiRSU is the static endpoint it talks to. A complete research setup normally contains both: one or more moving AmbiOBUs and a fixed AmbiRSU.
The power path, so the two voltages are not confused. The 12 VDC figure is what the unit is fed; the 19 V figure is what the compute platform receives from the AE170 after regulation.
On signal interfaces, external input and output beyond the interfaces listed above remains development-configurable. The compute platform exposes more than the roadside unit necessarily brings out to a connector, and this page does not list an interface as available on AmbiRSU merely because the compute module supports it. Which signals are exposed, and how, is part of the programme design.
The common development platform.
AmbiOBU and AmbiRSU are deliberately built on one architecture. The difference between them is where they sit, not what they run.
| AmbiOBU | AmbiRSU | |
|---|---|---|
| Role | Mobile development endpoint — the moving participant | Static roadside development endpoint — the fixed participant |
| Primary experiments | V2V, V2I, moving-node and relative-motion work | V2I, I2V, roadside application development, infrastructure experiments |
| Optional moving platform | Can be run on the 1:10-scale movable development platform | Not applicable — AmbiRSU is the static endpoint |
| Enclosure and siting | Vehicle-mounted or platform-mounted development configuration | Roadside enclosure, mounting and power defined per programme |
The point of the shared architecture is practical. A team develops against one operating system, one ROS 2 runtime, one set of application tooling and V2X interfaces, one GNSS platform and one backhaul path, and moves work between the mobile and roadside sides of an experiment with fewer platform-specific differences to absorb. It is a common application environment rather than a promise of binary-identical deployment: the two endpoints are packaged differently, sited differently and powered differently, and their external interfaces are scoped separately.
A compromised roadside unit is a weapon, not a fault.
An RSU that broadcasts unsigned messages, or whose firmware can be silently replaced, can inject false traffic alerts, spoof emergency-vehicle signals, or disable collision warnings across an entire corridor — continuously, from a fixed and well-chosen position, to every vehicle in range.
It is also a trusted insider in the PKI. Roadside units hold application certificates with service-specific permissions that vehicles do not have: an RSU may sign SPaT, MAP and IVI messages; a vehicle may not. Compromise it and you inherit those permissions. How those permissions are encoded →
Eight requirements, and how the platform meets each.
| Requirement | AmbiRSU implementation |
|---|---|
| PKI certificate management | AmbiSEC holds the roadside credentials inside its security boundary. Issuance, renewal and revocation over the backhaul are being developed, and the authority they talk to is external to Ambimat |
| Signed messages | ECDSA signing and verification inside the AmbiSEC boundary are implemented; the IEEE 1609.2 secured-message path that carries them is being developed |
| Secure OTA | Firmware authenticated by the secure element before installation; rollback protection on failed update |
| Hardware-backed credential storage | RSU identity keys and V2X certificates held in the hardware-isolated secure element |
| Secure boot | Boot sequence cryptographically verified before the unit becomes operational |
| Tamper detection | Anti-tamper mesh on the PCB triggers alarm and credential wipe on physical breach — critical for unattended roadside deployment |
| Device-bound identity | Where AmbiSEC is integrated, a unique identity key held inside the secure element and non-extractable by hardware design, anchoring identity operations to the individual roadside endpoint |
| Application permissions | Message permissions scoped in the certificate — an RSU signs only the message types its service-specific permissions authorise |
That last row is worth dwelling on. Permissions are carried in the certificate itself, as a PSID and SSP pair, so what a device is allowed to say is enforced cryptographically rather than by configuration. Separating credentials by application is therefore a design decision taken once, at architecture time — it is not something that can be added later in software.
What a roadside unit inherits, and what it still has to earn.
AmbiRSU is designed and built by an embedded hardware house, and the disciplines it draws on are the ordinary ones: mixed digital and RF board layout on a single PCB, enclosure and thermal design carried out as part of the electronics design rather than bought in afterwards, and production and test tooling designed alongside the product. Those are capabilities, not qualifications, and it is worth being precise about the difference.
What is not claimed. There is no published environmental, thermal or soak qualification for AmbiRSU, and none is claimed here — no operating-temperature rating, no ingress rating and no burn-in figure. Sealing, ingress rating, solar gain, surge, pole-mount mechanics and the environmental test envelope for a specific site are development work on an AmbiRSU programme, not something the platform already carries.
A fixed position also changes the radio design: unlike a vehicle, a roadside unit knows which approaches matter and can aim its antenna along the carriageway rather than radiating equally in every direction. AmbiRSU applies the same security architecture as AmbiOBU, adapted for fixed infrastructure deployment with a multi-sensor environmental payload and cellular backhaul. The sensor stack and full specification are pending client-supplied requirements, and no sensor table is published until they are confirmed.
An open question in India, and one worth engaging publicly.
Our position: authorisation should be a licence with a security bar, not a procurement footnote.
Plausible operator classes: licensed telecom operators, who already hold spectrum, tower estate, backhaul and 24×7 network operations discipline; cloud and software infrastructure providers, who can run the ITS application layer, edge compute and credential-management back end; and highway, tolling and transit concessionaires, who own the roadside asset, power and access rights on the corridors that matter first and have a commercial reason to maintain the units.
Conditions of authorisation should include certified, MTCTE-tested equipment with a tamper-resistant secure element and secure boot; enrolment as an end entity under an approved Root CA with an audited Certification Practice Statement and no self-signed roadside trust; physical-security and tamper-response obligations at the pole with incident-reporting SLAs; and strict separation of safety-message permissions from commercial-service permissions. Where the Indian position currently stands →
An orderable development platform, and a homologated roadside unit, are two different things.
AmbiRSU is a mature, production-ready V2X development platform available to order from Ambimat, and the design is manufacturable in quantity. It is supplied for algorithm development, integration, testing, research and demonstration. Contact Ambimat for configuration, lead time and pricing; no price, stock position or delivery commitment is published here, because none is fixed in advance of an enquiry.
Production ready is a statement about maturity, manufacturability and orderability — not about environmental qualification. Environmental qualification of the standard configuration for extreme temperature, high humidity, ingress, vibration, shock or outdoor roadside installation is not claimed unless explicitly stated, and no operating-temperature range or ingress rating is published for it. Where a deployment needs one, that is an IDH engagement → Homologation and certification for a permanent roadside installation remain specific to the final integrated product, the site and the target programme: this platform is not in production deployment, not certified, not homologated and not type-approved, and no ingress rating or environmental qualification is claimed for it.
What comes with the platform: mixed digital and RF multi-sensor PCB integration; cellular backhaul design; the AmbiSEC security layer with tamper detection, secure boot and hardware-held credentials; and OTA and provisioning infrastructure.
Where a programme wants more than the standard platform — a corridor, an intersection set or a campus to design against, traffic-controller and command-centre integration, an outdoor enclosure qualified for a named site, or a defined conformity regime — AmbiRSU can be the engineering baseline for a customer-specific production roadside unit. That is optional Ambimat custom engineering, taken up after you have the platform, and it is not a condition of buying one. The eight integration surfaces →
Work we take on beyond the platform itself.
Commissioned development work around roadside infrastructure — custom RSU hardware to a published specification, sensor payload integration, secure-element and credential-lifecycle integration into an existing RSU design, provisioning-line design, and firmware and OTA work for deployed roadside fleets.
On the software side, AmbiRSU runs the same open ROS 2 environment as the on-board unit, described in the reference configuration above. Roadside interfaces, sensor payload and backend integration are scoped according to the target programme rather than fixed in advance. The AmbiV2X Developer Stack →
If you are building roadside infrastructure, the standard platform is orderable on its own and the engineering above is available on top of it. Commercial arrangements for that engineering — custom development, licensing, contract manufacture, joint pilots — are discussed directly. Reach out →
Need a deployment-specific production design?
The standard AmbiOBU and AmbiRSU are production-ready development platforms, available to order exactly as they are, and manufacturable in quantity. Where a programme instead needs automotive, roadside, outdoor or other environment-specific qualification, Ambimat Technologies Pvt Ltd can act as your IDH — independent design house — partner, and adapt or develop the V2X hardware around that programme's electrical, mechanical, RF, environmental, security and integration requirements.
Requirements are captured first. The qualification scope, and the evidence that closes it, are agreed and validated as part of that programme rather than assumed from the standard configuration or promised in advance. It is a separately scoped engineering engagement, and it is not a prerequisite for buying anything — the standard platforms can be ordered directly, with no IDH engagement, no programme partnership and no custom-engineering commission first.
Where this fits.
V2I
What an RSU broadcasts, and the eight systems it has to touch.
AmbiSEC
The secure element holding the roadside credentials.
India regulation
Why RSUs are excluded from the OBU licence exemption.
SCMS vs CCMS
How each trust model treats roadside stations and their permissions.
Threats and attacks
RSU compromise as a threat class, with its countermeasures.
AmbiV2X Developer Stack
The ROS 2 V2X development environment this node runs, and how its roadside interfaces are scoped.
AmbiOBU
The vehicle-side counterpart, on the same security architecture.
Scoping a roadside deployment or an RSU development programme?
Bring the site, the controller integration and the conformity regime. We will bring the hardware baseline and the security architecture, developed as part of a V2X development programme — and the OBU development kit to give the roadside node something to talk to.
Questions this page answers.
What is a Roadside Unit?
The V2X equipment mounted beside or above the road — on a pole, a gantry or a signal head. It has a fixed, known position and signs the infrastructure messages vehicles act on: signal phase and timing, work zones, hazards. It is the stationary participant.
What is a Roadside Unit development kit?
A complete roadside-unit development endpoint rather than a bare radio evaluation board. AmbiRSU pairs a 5.9 GHz C-V2X PC5 subsystem with the same AmbiSEC secure element as the vehicle-side platform, plus tamper detection, secure boot and hardware-held credentials. Outdoor ingress qualification for a particular site is development work on the programme.
Can I order the AmbiRSU development platform, and how do I request a quotation?
Yes. AmbiRSU is a mature, production-ready V2X development platform available to order from Ambimat, with no programme partner and no custom-engineering commission required first. Email Ambimat with the setup you want, how many nodes and what you intend to develop; enquiries reach the V2X engineering team directly. Price, lead time and delivery terms are quoted per enquiry and are not published on this site. Choose a development setup.
Can Ambimat customise AmbiRSU for a site's temperature, ingress or power requirements?
Yes, as optional engineering rather than as something the standard platform already carries. Where a programme requires a specific operating-temperature range, ingress rating, vibration profile, power-input condition, enclosure or installation format, Ambimat can provide independent design-house (IDH) engineering — that is, engineering carried out by an independent design house on the customer's behalf — to develop and validate the required configuration. No ingress rating or environmental qualification is claimed for the standard development platform. Where that work sits.
How does it work with the On-Board Unit kit?
Together they give you Vehicle-to-Infrastructure (V2I) communication: the roadside node signs a message about something the vehicle cannot see, and the On-Board Unit development kit in the moving vehicle verifies the signature before acting on it. A roadside node with nothing to talk to proves very little, which is why the two kits are designed to be developed together.
Does AmbiRSU use the same software environment as AmbiOBU?
Yes. Ubuntu 22.04 LTS with ROS 2 Humble Hawksbill and the AmbiV2X Developer Stack — the same application and integration environment, with C++ and Python development against the same documented interface packages. That is the point of the shared architecture: a team develops against one environment and moves work between the mobile and roadside sides of an experiment. It is a common application environment rather than a promise of binary-identical deployment.
Does AmbiRSU use the same compute platform as AmbiOBU?
Yes — an NVIDIA Jetson Orin Nano Super with 8 GB of 128-bit LPDDR5 memory on both endpoints. Note that the compute platform exposes more than the roadside unit necessarily brings out to a connector; which external interfaces AmbiRSU presents is part of the programme design rather than inherited from the module.
Which GNSS does AmbiRSU use?
The same u-blox MAX-M10S as AmbiOBU — a u-blox M10 standard-precision module with concurrent reception of GPS/QZSS, Galileo, GLONASS and BeiDou on their L1-band signals, and typical 1.5 m CEP under u-blox's own stated test conditions. It is a standard-precision receiver: no RTK, no dead reckoning, and no lane-level or centimetre-level claim.
Does AmbiRSU include LTE?
Yes — a SIMCom A7672-series 4G LTE Cat 1 module for backhaul, telemetry, remote diagnostics and backend or IP services. It is separate from the direct C-V2X radio and does not provide PC5. Direct V2X uses the 5.9 GHz C-V2X PC5 subsystem at 3GPP Release 14, and the local exchange over it does not go through a mobile network.
Does AmbiRSU contain an IMU?
Yes — the same 9-axis IMU development baseline as AmbiOBU. A static roadside node does not need inertial data to function. It is present because the common hardware baseline is deliberate, and it makes device-state data available for installation alignment, pole-movement or vibration studies, and platform experiments where a programme wants it.
How is AmbiRSU powered?
From a 12 VDC development supply, distributed through the Ambimat AE170 Power Distribution Unit to the internal development electronics. The AE170 provides regulated rails and the compute platform is supplied from its 19 V rail — so 12 VDC is the external input to the unit, not the voltage every internal component runs at. This is a development-platform power architecture: there is no mains input, no Power over Ethernet, no automotive 24 V compatibility, and no surge, lightning or roadside power-conditioning qualification is claimed.
Is AmbiRSU part of the moving development platform?
No. The optional 1:10-scale movable development platform applies to AmbiOBU, which is the moving participant. AmbiRSU is the static roadside endpoint it communicates with. A full research setup normally has both.
Can AmbiSEC be included with AmbiRSU?
Yes, as an optional integration. Where it is included it provides secure key storage, hardware-backed cryptographic operations and device-bound identity — a unique identity key held inside the secure element and non-extractable by hardware design, so identity operations are anchored to that individual roadside endpoint. Ambimat does not operate the Root CA and is not a PKI operator.
Is this a production roadside unit?
No, and the two statements sit together without contradicting each other. AmbiRSU is a mature, production-ready V2X development platform available to order from Ambimat, and manufacturable in quantity — and environmental qualification of the standard configuration for extreme temperature, high humidity, ingress, vibration, shock or outdoor roadside installation is not claimed unless explicitly stated. It is not a certified production roadside product, not homologated and not type-approved for permanent roadside installation; that remains specific to the final integrated product, the site and the target programme. Taking a platform to a deployed roadside product is optional development work on top of it.
Why is roadside hardware a different problem from vehicle hardware?
The constraint set inverts. Cost per unit matters less and access cost dominates — a unit on a gantry is expensive to reach — so enclosure sealing, thermal management without moving parts, surge and power resilience, and an update path that cannot brick the device are what decide the design. The trust requirements do not relax.
Last updated 2026-10-01 · Technical reference maintained by Ambimat Electronics, Ahmedabad, India. Corrections: v2x@ambimat.com