Remote access to 6G research equipment for the Brasil 6G program

The problem

Partners booked equipment by email. Someone from the team then had to pick a day, turn the equipment on and stay in the lab with the visitor, who had to travel there. There was no remote access. Every session cost staff time, and the program could offer only the equipment someone could supervise in person.

The rest of the team were telecom engineers. There was no software team, so the architecture, backend, frontend and access design were all mine.

The design

Three services, each with one job:

• Web platform (React, NestJS, PostgreSQL): registration and admin approval, the equipment inventory, a calendar per piece of equipment, and booking management (accept, decline, who is allowed, who requested your equipment).
• Scheduling and access control: decides who can reach which equipment, and on which days.
• Remote connection, built on Apache Guacamole: RDP, VNC and SSH sessions run in the browser, with nothing for the partner to install.

Security in layers

The equipment sits on a research network, so access is defended at every step, not at the front door only:

1. VPN. I designed the platform to run behind the VPN and around how the VPN shapes its use; Inatel's IT department issues and revokes the credentials.
2. Approved accounts only. You do not sign up, you request an account; an admin approves it inside the platform.
3. Multi-factor login with a code by email or an authenticator app.
4. A separate access platform that accepts your login only on the date you booked.
5. A single-use connection link. Each connection gets an encrypted link built from its connection parameters and the time of the request. Change any part and the connection is refused; replay it later and it has expired.

Modelling the program

Permissions had to mirror how the program actually works, so the data model carries its real structure:

• Organizations have teams, and an employee can be on more than one team.
• Organizations partner with other organizations, and a partnership shows only the teams each side chooses.
• An organization owns assets. An asset is one or more pieces of equipment, and a piece of equipment can be part of several assets. An asset belongs to one or more teams, and partners can book it only through a partnership.
• Organizations, teams and partnerships each have admins, managers, regular users and invited outsiders.
• A booking has an owner, admins and members, so several people can work on the same equipment during one booked day.

Bookings that fit the equipment

Because equipment is shared between assets, bookings block the asset's calendar, not a single piece of equipment's. Booking requests go into an outbox, and a single worker processes them in order, checking each one against the asset's calendar. Two requests for the same slot are never checked at the same moment, so the second always sees the first. Conflict rules depend on the equipment: what only one person can use cannot be double-booked, while equipment that supports several users at once can be shared.

Partners are spread across institutions and countries, so the interface ships in English, Portuguese and Spanish, with a timezone selector and the calendar and date pickers built for booking.

The tradeoff: security over ease of first use

Five layers is a lot to learn on a first visit, and new partners feel it. I chose that cost on purpose. The platform opens physical lab equipment on a research network to people outside the institution, and a smoother login was not worth a weaker boundary.

The outcome

• About 90 times more equipment available. Remote access made almost all of the lab's equipment bookable, not only what a staff member could supervise on site.
• 95% less time from request to confirmed booking, compared with email plus finding a team member to be in the lab.
• Partners no longer travel to use the equipment, and staff no longer sit in on every session.

Looking back

I am proud of this one, and I would make the same calls again. I built it before my Claude Code workflow, with Cursor for autocomplete and questions. Today I would build it with Claude Code.

Inatel describes the platform on its own Brasil 6G multi-user platform page (in Portuguese).