1xBTS: Best CDMA2000 Base Station Stack for Lab Engineers in 2026

What Is 1xBTS?

1xBTS is an experimental CDMA2000 1x base station and core-network stack built by Chris Moos in Rust. 1xBTS is one of the best CDMA2000 Base Station Stacks tools for Lab Engineers and RF Researchers. It covers BTS, BSC, MSC, HLR, SMSC, packet data, voice, SDR radio backends, and a web dashboard, so one repo spans the full 3GPP2 1x path across eight node roles. The project is aimed at research, interoperability testing, and lab use, with active development and six tested handset models listed in the repo as of Feb 2026.

Quick Overview

1xBTS is split by protocol boundary instead of hiding everything behind one monolith. That matters because CDMA2000 lab work usually fails at integration seams, not in isolated unit tests.

Who Should Use 1xBTS?

• RF researchers validating CDMA2000 signaling, radio behavior, and service flows on real SDR hardware without paying for closed telecom stacks.
• Telecom lab engineers who need to stand up BTS, BSC, MSC, HLR, SMSC, and packet data roles in a single controlled environment.
• Interop testers reproducing handset quirks across SMS, circuit-switched voice, and packet data using the same core stack.
• Builders of legacy-device demos who want to revive CDMA handsets in a legal lab and observe end-to-end behavior on supported radios.

Not ideal for:

• Production carriers that need vendor support, hardening, and predictable handset interoperability across large subscriber populations.
• Teams without SDR or Linux experience because 1xBTS expects native dependencies, kernel modules, and radio-specific build flags.
• Anyone without RF authorization since transmitting on live spectrum without permission is the wrong use case and can be illegal.

Key Features of 1xBTS

• Full 3GPP2 node split — 1xBTS implements BTS, BSC, MSC, HLR, SMSC, PCF, PDSN, voice-gw, and NIB as distinct processes. That gives you the same architectural seams you would debug in a real 1x deployment, including Abis, A1, A8/A9, and A10/A11 reference points.
• Network-in-a-box launcher — cdma-nib runs the full stack in one process for local integration and fast bring-up. That is useful when you want to validate configs, services, and handset behavior before splitting nodes across machines.
• SDR backend selection at build time — 1xBTS supports bladerf-backend, uhd-backend, and lime-backend, with the repo explicitly saying to enable exactly one backend per build. That keeps the hardware abstraction narrow and avoids runtime guessing.
• PostgreSQL-backed subscriber state — HLR and SMSC state are stored in PostgreSQL, and the docs show a local 1xbts database on port 45432 via Docker Compose. That is the right trade-off for stateful telecom services that need repeatable test data.
• Web dashboard and management APIs — the dashboard ships in 1xbts-web as a Next.js app backed by gRPC management APIs. You get a browser control plane for observing node state and operational settings without adding a second admin tool.
• Voice and packet-data paths are first-class — voice-gw uses SIP and Baresip libre/re for outbound voice calls, while PDSN handles packet data over FoU/TUN. That means 1xBTS is not only a signaling demo; it exercises service traffic too.
• Config layering for lab overrides — sibling <name>.local.json files deep-merge on top of checked-in config and are gitignored. That is the cleanest way to keep lab-specific radio parameters out of shared defaults.

1xBTS vs Alternatives

Pick 1xBTS when the target is CDMA2000 1x and you need the full stack from radio to core. Pick OpenBTS, YateBTS, or Osmocom when the lab is GSM/UMTS-oriented and the device compatibility target is different.

If you need operational visibility around the service graph, pair 1xBTS with OpenTrace to inspect inter-node calls and gRPC boundaries. If you are scripting repeatable lab deployment or environment setup, djevops is the more relevant companion for automation.

How 1xBTS Works

1xBTS uses a Rust workspace with first-party crates under crates/ and external integration wrappers under external/. The design keeps protocol logic close to the code that owns it, while the proto directory defines protobuf services and the 1xbts-web dashboard consumes the management gRPC APIs.

The stack follows the 3GPP2 1x reference architecture instead of collapsing everything into one binary. BTS handles air-interface PHY and MAC work, BSC handles radio resource management over Abis, MSC handles circuit-switched core behavior over A1, HLR persists subscribers in PostgreSQL, PCF bridges A8/A9 and A10/A11, and the packet path terminates through PDSN using FoU/TUN. That separation makes the system easier to reason about when a service fails, because the failing boundary is explicit.

The network-in-a-box launcher is the shortest path to a working lab environment. It starts the services with a single command, loads the config tree, and wires the control plane together with the selected SDR backend.

git clone https://github.com/chrismoos/1xbts.git
cd 1xbts
cargo run --release -p cdma-nib --no-default-features --features bladerf-backend -- --config-dir config --radio-config config/radio_bladerf_micro2.json

That command starts the network-in-a-box process with the bladeRF backend, loads the checked-in config directory, and points the radio layer at the sample bladeRF Micro 2.0 profile. In a real lab, you would also bring up PostgreSQL and the dashboard through Docker Compose, then adjust the radio and service configs with local override files before transmitting.

Pros and Cons of 1xBTS

Pros:

• Full-stack coverage — BTS, BSC, MSC, HLR, SMSC, packet data, and voice are all in the same project, which reduces glue-code drift between services.
• Rust implementation — the main stack is written in Rust, which narrows the unsafe surface compared with large C/C++ telecom codebases.
• Real SDR support — tested hardware includes bladeRF Micro 2.0, Ettus USRP B210, and LimeSDR Mini v2 as of Feb 2026.
• Operational dashboard — the Next.js dashboard gives the team a browser view of a system that would otherwise require shell access and log scraping.
• Repeatable lab state — PostgreSQL-backed HLR and SMSC state make subscriber fixtures and SMS state easier to reproduce.
• Reference-point clarity — explicit Abis, A1, A8/A9, and A10/A11 links map directly to telecom docs and make troubleshooting less ambiguous.

Cons:

• Experimental status — the repo says production hardening is still incomplete, so 1xBTS is not a carrier-grade deployment choice.
• Hardware and OS friction — protoc, pkg-config, libclang, C compilers, Docker, and kernel modules are part of the normal setup path.
• Backend choice is static per build — you enable one SDR backend at compile time, so changing hardware usually means rebuilding.
• Handset support is variable — the repo explicitly says behavior depends on handset, backend, channel configuration, and service option.
• RF authorization is mandatory — 1xBTS is designed for research and lab use, so unauthorized transmission is a non-starter.

Getting Started with 1xBTS

The fastest path is to install the native dependencies, clone the repo, start the support services, and run the network-in-a-box launcher. On Ubuntu or Debian, the repo lists build-essential, pkg-config, protobuf-compiler, libssl-dev, libclang-dev, and libre-dev as common prerequisites.

sudo apt-get update
sudo apt-get install -y build-essential pkg-config protobuf-compiler libssl-dev libclang-dev libre-dev
git clone https://github.com/chrismoos/1xbts.git
cd 1xbts
docker compose up -d
cargo run --release -p cdma-nib --no-default-features --features bladerf-backend -- --config-dir config --radio-config config/radio_bladerf_micro2.json

After those commands finish, PostgreSQL and the dashboard come up through Docker Compose, and the launcher starts the protocol nodes in a single process. If port 3000 is already taken, set ONEXBTS_WEB_PORT=3001 before launching the dashboard. For local tuning, add sibling *.local.json files next to the base configs so you can override radio parameters without touching shared defaults.

Verdict

1xBTS is the strongest option for CDMA2000 1x lab bring-up when you need a single Rust codebase that covers radio, core, SMS, packet data, and voice. Its biggest strength is the full node model; its caveat is experimental hardware support and lack of production hardening. Use it for authorized research labs, not live networks.