Cellular

Multi-provider cellular, from line one.

Cellular is a first-class transport in Beacons. Implemented as a trait-based abstraction with provider plugins, designed so a fleet operator picks one or more providers — and Beacons routes ordering, activation, and usage queries to the right one.

A CellularProvider trait. Many implementations.

Beacons does not hard-code Telnyx (or any other vendor). The cellular subsystem exposes a stable Rust trait. Telnyx is the first implementation. The other providers below ship in Phase 4. New providers can be added without changing the rest of the system.

  • Per-SIM did:oas — auditable peers in the OAS tree
  • Per-fleet private APN
  • Provider failover policies per SIM
  • Metered through Cabbage alongside bandwidth
  • eUICC orchestration owned by Beacons (consumed by Locks)
trait CellularProvider
pub trait CellularProvider {
    fn provider_id(&self) -> &'static str;

    async fn order_sims(&self, fleet: &FleetId, req: SimOrderRequest)
        -> Result<Vec<Sim>, CellularError>;

    async fn activate(&self, sim: &Sim, apn: &ApnProfile)
        -> Result<ActivationReceipt, CellularError>;

    async fn suspend(&self, sim: &Sim) -> Result<(), CellularError>;
    async fn deprovision(&self, sim: &Sim) -> Result<(), CellularError>;

    async fn usage(&self, sim: &Sim, window: TimeWindow)
        -> Result<UsageReport, CellularError>;

    async fn provision_gateway(
        &self,
        fleet: &FleetId,
        spec: GatewaySpec,
    ) -> Result<Gateway, CellularError>;

    async fn esim_profile_install(
        &self,
        sim: &Sim,
        profile: &EsimProfile,
    ) -> Result<(), CellularError>;
}

Why per-SIM identity

Every SIM is an OAS-identified entity.

A SIM's DID is did:oas:<ns>:tool:sim-<iccid>and is published with metadata about the fleet it serves, the provider, and the device it is installed in. This makes SIMs auditable peers in the OAS lineage tree — the same model that governs agents and humans.

When a SIM is suspended at the cellular provider, its DID transitions to a revoked state in the audit chain, the policy engine drops its routes, and the device behind the SIM is removed from the fleet. When the SIM is reactivated, the reverse: it re-enrolls, gets new routes, and the audit chain records the transition.

Open a fleet

The mesh that fits agents and humans.

A `did:oas`-rooted private mesh that ships peer configurations to any device, anywhere, by policy — not by hand.

Open consoleRead the quickstart