Spectrum control, hop by hop

The grant lifecycle, live

Run the chain end to end, or step through it one message at a time. Trigger an incumbent detection to watch a suspend propagate through every hop, or terminate the grant outright and watch the radio go dark, then get re-granted on a different channel.

Payloads are structurally faithful to the SAS-CBSD protocol; identifiers and timestamps are placeholders.

Why any of this exists

3550 to 3700 MHz was federal spectrum and still is. The US Navy runs shipborne radar in it, and fixed-satellite earth stations sit in it too. Rather than clear the band, the FCC opened it in 2015 under 47 CFR Part 96 as shared spectrum with three tiers of priority. Nobody in tiers 2 or 3 owns a channel. They borrow one, moment to moment, from a database that knows where the incumbents are and what every other radio is doing. That database is the SAS.

The consequence for a radio: it may not transmit until a SAS has told it where and how loud, and it must go quiet fast when told to. When an ESC sensor reports radar, the SAS has 300 seconds to move or suspend the affected radios, and each radio has 60 seconds to comply once told. Those two numbers set the timing budget for everything that follows.

Watch a radar detection propagate through the chain

What a SAS is

A Spectrum Access System is an FCC-certified, cloud-hosted coordinator for the band. It is not a radio and not a network element. Certified SAS administrators (Google, Federated Wireless and others) operate them; a network operator subscribes and pays per device. In the FCC's model the SAS is the enforcement point: the rules are written so that a radio cannot be compliant without one.

What it does, in the order a radio meets it:

• Registration. The radio identifies itself: FCC ID, serial number, category (A: up to 30 dBm/10 MHz EIRP, B: up to 47 dBm/10 MHz), location, antenna height and gain. For category B and outdoor category A devices those installation parameters must be attested by a Certified Professional Installer (CPI) and signed.
• Spectrum inquiry. Optional: "what is available here?" The SAS answers with channels and the EIRP it would allow on each.
• Grant. The radio asks for a frequency range and a maximum EIRP. The SAS checks incumbent protection, PAL protection areas and aggregate interference from every other CBSD it knows about, then issues a grant with an expiry time and a heartbeat interval.
• Heartbeat. The lease renewal. A grant alone does not authorize transmission; the first successful heartbeat does. Each response carries a transmitExpireTime. Miss it and the radio must stop.
• Suspend, terminate, relinquish. The SAS can pull a grant at any heartbeat: 501 SUSPENDED_GRANT (keep the grant, stop transmitting, keep heartbeating) or 500 TERMINATED_GRANT (the grant is gone, ask again). The radio relinquishes when it is done.
• SAS-to-SAS sync. Administrators exchange CBSD registrations and grants so that every SAS computes interference from the whole population, not just its own customers.

The wire protocol is the WInnForum SAS-CBSD interface (WINNF-TS-0016): JSON over HTTPS, mutually authenticated with certificates issued under the CBRS PKI. Requests are arrays, so one HTTP call can carry many radios.

Response codes worth knowing

For lab work, OpenSAS (an open-source SAS from the Virginia Tech CCI testbed) implements the same object model and response codes, serving https://host:1443/sas-api/{registration, spectrumInquiry, grant, heartbeat, relinquishment, deregistration}. It lets you exercise the full lifecycle without a commercial subscription, but it is not a certified SAS: it proves that your chain behaves correctly, not that your deployment is legal.

What a Domain Proxy is

The SAS speaks exactly one protocol and expects a certificate-holding, well-behaved client that sends batched JSON, tracks grant state per radio and heartbeats on time. A radio's own management interface is something else entirely: NETCONF/YANG for an O-RAN RU, TR-069 or TR-369 for a small cell, a vendor CLI for the rest. Something has to sit between the two and act as the SAS client on the radio's behalf. WInnForum calls that a Domain Proxy.

It owns five things:

• The CBRS PKI certificate and the TLS session to the SAS. One trusted endpoint instead of a certificate on every radio.
• Batching: N radios, one request array, one HTTPS call. This matters at scale, because a SAS rate-limits per call as well as per device.
• The WInnForum state machine per CBSD: unregistered, registered, granted, authorized, with the heartbeat timers, retries, back-off and the 60-second stop deadline.
• Translation of grant parameters into whatever the network side understands.
• Propagation of the SAS's decisions downward: suspend and terminate have to reach the transmitter, not stop at a log line.

Could the radio just carry the SAS client itself? It can, and some small cells do. But the moment you have more than a handful of radios, or radios from more than one vendor, or radios whose management plane is NETCONF rather than HTTP, the proxy is the only sane place for the certificate, the state and the batching to live. It also gives you a single log where an auditor can see every grant the network ever held.

Magma's dp/ directory is a complete open-source example: a configuration controller that talks to the SAS, a radio controller that talks to the radios, a database service holding grant state, and an active-mode controller that drives the lifecycle. Commercial small-cell vendors ship the equivalent inside their element management systems.

Where the DU and CU fit

In FCC terms the CBSD is the thing that radiates: the radio unit. The RU is the certified device; the DU is not. But an RU does not pick its own carrier. In a Split 7.2 system the DU decides band, ARFCN, bandwidth and power budget, and drives the RU over Open Fronthaul. So a grant has to become DU configuration before it can become RF.

The CU is untouched. RRC, PDCP and the NG interface to the core do not care which 10 MHz the cell is on. Spectrum control is a DU-and-below concern, which is also why it belongs outside the 3GPP stack proper: nothing in F1 or NG carries a grant.

The join is a small piece of glue, a grant adapter, that takes what the Domain Proxy hands it and maps grant state to carrier action:

The last hop: M-Plane into the RU

O-RAN WG4 defines four fronthaul planes. Three of them (C, U, S) carry the live cell. The Management Plane is the one that configures the radio: NETCONF over SSH (or TLS), with YANG models the RU publishes. The carrier lives in o-ran-uplane-conf as a tx-array-carrier object with a centre frequency, a bandwidth, a gain and an active state of INACTIVE, SLEEP or ACTIVE.

The path from grant to RF:

What actually crosses the wire for an authorized grant:

<rpc message-id="7" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target><running/></target>
    <config>
      <user-plane-configuration xmlns="urn:o-ran:uplane-conf:1.0">
        <tx-array-carriers>
          <name>txarray0</name>
          <center-of-channel-bandwidth>3595000000</center-of-channel-bandwidth>
          <channel-bandwidth>10000000</channel-bandwidth>
          <gain>30</gain>
          <active>ACTIVE</active>
        </tx-array-carriers>
      </user-plane-configuration>
    </config>
  </edit-config>
</rpc>

A suspend is the same message with active set to SLEEP (or gain to 0); a termination sets it INACTIVE. One edit-config completes in well under a second, which is why the 60-second Part 96 deadline is comfortable once the chain exists and impossible when it does not.

Two practical notes. M-Plane sessions are long-lived, so the client should hold the session open rather than reconnect per grant; SSH key exchange on an embedded RU can take longer than the edit itself. And the RU's supported YANG revision matters: o-ran-uplane-conf has changed across WG4 M-Plane releases, and a client written for one revision will fail validation on another. Fetch the RU's capabilities with a NETCONF <get> before assuming anything.

Why it is mandated, and who owns which duty

Transmitting in 3550 to 3700 MHz without a SAS grant is unlicensed operation in a band shared with federal radar. Part 96 is the set of conditions under which it becomes legal. The SAS is the FCC's enforcement point; the Domain Proxy, the DU adapter and the M-Plane hop are how a network obeys it. Each rule below lands on a specific hop.

So the responsibility splits cleanly. The radio vendor owns device authorization. Whoever builds and operates the chain owns conformant spectrum-control behaviour: register before transmit, stay inside the grant, stop on time. Proving the second end to end in a lab, against an open SAS and a mock radio, is the cheap part. Certification against a commercial SAS, with CPI data, WInnForum conformance testing and a CBRS PKI certificate, is months of external lead time and a separate project from the engineering.

Section references are to 47 CFR Part 96 as commonly cited. Confirm wording against the current eCFR text before relying on it.

Sources and references

• 47 CFR Part 96, Citizens Broadband Radio Service (eCFR).
• WInnForum WINNF-TS-0016, SAS to CBSD Technical Specification (response codes, object model, heartbeat semantics).
• WInnForum WINNF-TS-0096, SAS Test and Certification Specification.
• O-RAN WG4 Management Plane Specification and the o-ran-uplane-conf YANG model.
• Open-source examples named above: OpenSAS (CCI-NextG-Testbed), Magma Domain Proxy (magma/dp), Open M-Plane, and srsRAN-derived DU and CU stacks.

Written by telecogeco, a ugeco brand. The lifecycle lab above walks a synthetic CBSD through the WInnForum message set on the client side only; it is not connected to a live SAS or a real radio.