¶ 5G Standalone fundamentals
This page teaches 5G Standalone (SA) from the ground up: the parts of a mobile network, the protocols
that join them, the radio's time and frequency structure, the identities that let a phone onto a
network, and the sequence of messages that takes a phone from power-on to an IP address. It is
written for readers who know Linux and IP networking but not cellular systems, and every example
uses the values that the COSMOS tutorials actually run.
¶ Why this matters
Every tutorial in this group ends with the same three checks: the base station is on air, the user
equipment has registered, and it has an IP address that reaches the internet. When one of those
checks fails, the logs name the failure in 5G vocabulary: unknown-PLMN during NG Setup, a random
access that stops at Msg3, a Registration reject [95], an Unknown DNN. Without a model of what
each step is for, these messages are opaque and the only strategy left is changing settings at
random.
With the model, the failure location is usually obvious. A cell that is not on air is a radio or
configuration problem. A UE that is on the cell but never completes random access has a timing or
physical-layer problem. A UE that registers but gets no PDU session has a subscriber-data or core
problem. The rest of this page builds that model.
¶ The three parts of a mobile network
A 5G network always has three parts:
- User equipment (UE) — the phone or modem. On COSMOS the UE is either a commercial Quectel
RM520N-GL modem or a software UE (srsRANsrsue, OAInr-uesoftmodemor Amarisoftlteue). - Radio access network (RAN) — the base station, which 5G calls the gNB (next-generation
Node B). It turns IP packets into radio waves and back, and schedules every transmission in both
directions. - 5G core network (5GC) — a set of servers that authenticate the UE, decide what it may do, give
it an IP address and forward its traffic to the internet.
The interface between the UE and the gNB is the radio link, called Uu. The interface between the
gNB and the core is a wired IP network. COSMOS runs three RAN stacks (OCUDU, Duranta and Amarisoft)
and several cores (Open5GS, OAI CN5G, Aether SD-Core, and Amarisoft's own ltemme). Any COSMOS UE
can use any of them, because they share the same test network identity and address pool (see
Identities, SIMs and subscriber data).
Standalone versus non-standalone. Early 5G deployments were non-standalone (NSA): the 5G radio
carried data, but an LTE base station and an LTE core handled control. In standalone mode the UE
talks only to a 5G gNB and a 5G core. Every COSMOS tutorial in this group is SA.
¶ The 5G core: network functions and the service-based architecture
The 5G core is not one program. It is a set of network functions (NFs), each with a narrow job.
The control-plane NFs expose HTTP/2 APIs and call each other over a shared bus, which 3GPP calls the
service-based architecture (SBA). The user plane is separate: user packets never pass through the
control-plane NFs.
Figure — UE, gNB and the 5G core. Control-plane functions sit on the service-based bus; the user plane runs gNB → UPF → data network. Note that only the AMF and the UPF face the gNB.
| Network function | What it does |
|---|---|
| AMF — Access and Mobility Management Function | The UE's entry point to the core. Terminates the gNB's control connection (N2) and the UE's Non-Access Stratum signalling (N1). Handles registration, reachability and mobility. |
| SMF — Session Management Function | Creates, modifies and releases PDU sessions (the UE's data connections). Picks a UPF, allocates the UE's IP address, and programs the UPF. |
| UPF — User Plane Function | Forwards user packets between the gNB tunnel (N3) and the data network (N6). The only core component that carries user data. |
| AUSF — Authentication Server Function | Runs the authentication exchange with the UE on the AMF's behalf. |
| UDM — Unified Data Management | Holds the subscription logic and generates authentication vectors from the subscriber's key. |
| UDR — Unified Data Repository | The database behind the UDM: subscriber keys, allowed slices, allowed DNNs. On COSMOS it is backed by MongoDB (Open5GS, SD-Core) or MySQL (OAI CN5G). |
| NRF — Network Repository Function | The directory service. Every NF registers here; every NF discovers its peers here. |
| PCF — Policy Control Function | Supplies policy (QoS, charging rules) for sessions. |
| NSSF — Network Slice Selection Function | Decides which network slices a UE may use. |
The gNB connects to exactly two core functions: the AMF for control and the UPF for data. This split
of control plane from user plane is deliberate. A UPF can be placed close to the radio for low
latency, or scaled out for throughput, without touching the control plane.
¶ Interfaces (reference points)
3GPP names each logical link between two functions with an "N" number. The ones you will meet in
COSMOS logs and configs are:
| Interface | Between | Carries | Transport |
|---|---|---|---|
| Uu | UE ↔ gNB | the radio link | NR air interface |
| N1 | UE ↔ AMF | Non-Access Stratum (NAS) signalling: registration, authentication, session requests | carried inside RRC on Uu, then inside NGAP on N2 |
| N2 | gNB ↔ AMF | NG Application Protocol (NGAP): gNB setup, UE context, session resources | SCTP, port 38412 |
| N3 | gNB ↔ UPF | user packets in tunnels | GTP-U over UDP (port 2152) |
| N4 | SMF ↔ UPF | rules telling the UPF how to forward a session's packets | PFCP over UDP (port 8805) |
| N6 | UPF ↔ data network | the UE's traffic, as ordinary IP | IP |
Two practical consequences follow. First, "the gNB is up" has two halves: the gNB must complete
NG Setup with the AMF over N2 before it activates its cell, so a gNB whose AMF address or PLMN is
wrong never goes on air. Second, N1 is tunnelled: the gNB does not read the UE's NAS messages; it
forwards them to the AMF. A registration failure is therefore diagnosed in the AMF's log, not the
gNB's.
¶ The radio protocol stack
Between an IP packet on the UE and the same packet at the UPF, the RAN applies a stack of protocol
layers. Each layer has one job; knowing which job belongs to which layer tells you where a failure
can be.
Figure — UE and gNB protocol stacks, control plane and user plane. The CU/DU split (F1) cuts between PDCP and RLC; the O-RAN 7.2x split cuts inside the physical layer.
| Layer | Plane | What it does |
|---|---|---|
| NAS — Non-Access Stratum | control | UE ↔ core signalling: registration, authentication, PDU-session requests. Transparent to the gNB. |
| RRC — Radio Resource Control | control | UE ↔ gNB signalling: connection setup, radio configuration, radio-level security, measurement reports. |
| SDAP — Service Data Adaptation Protocol | user | Maps IP flows onto radio bearers according to their QoS. |
| PDCP — Packet Data Convergence Protocol | both | Ciphering and integrity protection, header compression, reordering and duplicate removal. |
| RLC — Radio Link Control | both | Segmentation and reassembly; retransmission of lost segments (acknowledged mode). |
| MAC — Medium Access Control | both | The scheduler: decides every slot which UE sends or receives on which resources; fast retransmission (HARQ); random access. |
| PHY — physical layer | both | Coding, modulation, mapping onto subcarriers, OFDM (inverse FFT and cyclic prefix), and the radio itself. |
The layers are also where the gNB can be cut into pieces. 3GPP defines a central unit (CU) that
holds RRC, SDAP and PDCP and a distributed unit (DU) that holds RLC, MAC and the upper physical
layer; they talk over the F1 interface. The CU can itself be split into a control part (CU-CP)
and a user part (CU-UP) joined by E1. O-RAN adds a further cut inside the physical layer, the
7.2x split, which moves the lower PHY and the RF into a separate radio unit (O-RU). That
split is the subject of O-RAN architecture and the 7.2x fronthaul.
¶ The radio: spectrum, numerology and frames
¶ Bands and ARFCNs
5G NR frequencies are organised into numbered bands. The COSMOS tutorials use three:
| Band | Frequency range | Duplex | Where COSMOS uses it |
|---|---|---|---|
| n78 | 3.3–3.8 GHz | TDD | O-RAN 7.2 tutorials (Benetel, LiteOn, Foxconn, the soft O-RU on osc), the SD-Core tutorial |
| n41 | 2.5–2.7 GHz | TDD | Over-the-air USRP tutorials on sb1/grid, ProtO-RU |
| n3 | 1.8 GHz | FDD | The OCUDU soft-only tutorial — configuration only, no RF is generated |
Inside a band, a frequency is written as an NR-ARFCN (Absolute Radio Frequency Channel Number),
an integer on a fixed raster defined in 3GPP TS 38.104. Below 3 GHz the raster step is 5 kHz; from 3
to 24.25 GHz the frequency is 3000 MHz + 15 kHz × (ARFCN − 600000). Two worked examples from COSMOS
configs:
- n41 over the air:
dl_arfcn 518670→ 518670 × 5 kHz = 2593.35 MHz. - SD-Core tutorial:
dl_arfcn 627340→ 3000 MHz + 15 kHz × 27340 = 3410.1 MHz.
A value that is one raster step off is a different frequency to the UE, so ARFCNs are copied
exactly, never rounded.
¶ Numerology: subcarrier spacing and slots
NR is an Orthogonal Frequency Division Multiplexing (OFDM) system: the channel is divided into many
narrow subcarriers, each carrying one modulated symbol per OFDM symbol period. Unlike LTE, NR
lets the subcarrier spacing (SCS) vary. The choice is called the numerology, μ, and it sets the
time structure too:
| μ | Subcarrier spacing | Slot duration | Slots per 10 ms frame | COSMOS use |
|---|---|---|---|---|
| 0 | 15 kHz | 1 ms | 10 | OCUDU soft-only (band 3, 10 MHz) |
| 1 | 30 kHz | 0.5 ms | 20 | every over-the-air and O-RAN 7.2 tutorial |
| 2 | 60 kHz | 0.25 ms | 40 | not used |
A slot is 14 OFDM symbols. A resource block (PRB) is 12 consecutive subcarriers, and a
channel's width is expressed as a number of PRBs. At 30 kHz SCS, the COSMOS carriers are:
| Channel bandwidth | PRBs at 30 kHz | Where |
|---|---|---|
| 20 MHz | 51 | Duranta soft O-RU on osc, SD-Core tutorial |
| 40 MHz | 106 | over-the-air n41 tutorials, ProtO-RU |
| 100 MHz | 273 | O-RAN 7.2 with a commercial O-RU |
The software must also produce samples fast enough for the channel. A 100 MHz cell on a USRP N310
runs at a sample rate of 122.88 MHz; a 40 MHz cell at 61.44 MHz. This is why the radio's master clock
matters: the N310 runs a 122.88 MHz master clock and the X310 a 184.32 MHz one, and the Amarisoft
tutorial runs the X310 at 40 MHz at most.
The 0.5 ms slot at μ = 1 is also the real-time budget of the RAN. Every slot, the MAC must decide
what to send, and the physical layer must encode it and hand it to the radio before its air time.
A server that misses that deadline produces late samples, and the radio link degrades. The
real-time host preparation page
explains how COSMOS servers are prepared to meet it.
¶ Duplexing and TDD patterns
With frequency division duplex (FDD), downlink (gNB → UE) and uplink (UE → gNB) use two
different frequencies at the same time. With time division duplex (TDD), used by n41 and n78,
both directions share one frequency and take turns. The turn-taking is a repeating TDD pattern
of slots: D (downlink), U (uplink) and S (special: some downlink symbols, a guard gap, some
uplink symbols).
Two patterns appear on COSMOS:
DDDSU— a 5-slot pattern that repeats every 2.5 ms at 30 kHz SCS. Three downlink slots, one
special slot, one uplink slot. The Duranta soft O-RU configures the special slot as 6 downlink
symbols and 4 uplink symbols.DDDDDDDSUU— a 10-slot pattern that repeats every 5 ms: seven downlink slots, one special
slot, two uplink slots.
A worked example shows why uplink is so much lower than downlink in every COSMOS performance table.
Counting only full slots, DDDSU gives the downlink three slots out of five and the uplink one; the
uplink has at most a third of the downlink's airtime before any other effect. The tutorials state
this directly: "UL is bounded by the TDD pattern (one UL slot per 2.5 ms DDDSU period)". A modem
connected to a DDDSU cell on n41 at 40 MHz measures single-digit uplink rates in some tutorials
for this reason, not because anything is broken.
The TDD pattern is not a private choice of the gNB. The UE learns it from the cell's broadcast, and
in an O-RAN split the radio unit must be configured with the same pattern, because it switches its
transmitter and receiver on that schedule. The two open stacks run the Benetel O-RU with different
patterns (Duranta DDDSU, OCUDU DDDDDDDSUU), which is one reason COSMOS enforces the golden O-RU
rule described on the O-RAN page.
¶ The SSB and cell search
A UE that powers on knows nothing about the network. It finds a cell by scanning for the
synchronization signal block (SSB), a small, periodically repeated block that every cell
transmits. The SSB contains:
- the primary and secondary synchronization signals (PSS and SSS), which give the UE symbol
timing and the cell's physical cell identity (PCI), a number from 0 to 1007; - the physical broadcast channel (PBCH), which carries the master information block (MIB):
the frame number and where to find the next piece of system information.
The MIB points at a control region called CORESET#0, which schedules SIB1 (system information
block 1). SIB1 carries the network identity (PLMN), the tracking area code, the TDD pattern and the
random access configuration. Only after reading SIB1 can the UE decide whether this cell belongs to
a network it may use.
The SSB is not necessarily at the centre of the carrier. It sits on a coarser synchronization
raster so that the UE can find it without scanning every frequency. COSMOS configs therefore carry
two numbers: the ProtO-RU tutorial uses DL ARFCN 519000 with SSB ARFCN 516030, and the SD-Core
tutorial uses dl_arfcn 627340 with SSB ARFCN 626976. When a Quectel modem reports its serving cell,
the ARFCN it prints is the SSB's, not the carrier's.
¶ PRACH and random access
A UE that has read SIB1 is synchronized in downlink but not in uplink: it does not yet know how far
it is from the gNB, and the gNB does not know it exists. It announces itself on the physical
random access channel (PRACH), a set of time-frequency resources the cell reserves for this
purpose. The PRACH configuration index in the gNB config selects the preamble format and which
slots carry PRACH occasions; the Duranta soft O-RU, for example, uses prach_ConfigurationIndex = 157, which is format B4, the only format nr-oru supports.
The random access (RACH) procedure has four messages:
- Msg1 — the UE transmits a preamble on a PRACH occasion.
- Msg2, the random access response (RAR) — the gNB detects the preamble, measures its
arrival time, and replies with a timing advance (how much earlier the UE must transmit so its
uplink arrives aligned), a temporary identifier and an uplink grant. The RAR must be sent inside
a window after the preamble. - Msg3 — the UE's first scheduled uplink transmission, carrying the RRC setup request.
- Msg4 — contention resolution and RRC setup. The UE is now connected at the radio level.
Random access is the first place where uplink timing, uplink power and gNB processing speed all
matter, which is why so many COSMOS troubleshooting rows sit here. A PRACH that is detected but a
Msg3 that never decodes is a classic symptom. Two causes on COSMOS rigs: the O-DU compresses the
fronthaul while the soft O-RU nr-oru accepts only uncompressed samples, or the MAC processing
delay is so long (max_proc_delay 15) that the gNB misses the RAR window, which is why the LiteOn
configuration uses 10.
¶ Identities, SIMs and subscriber data
A UE is admitted to a network because its SIM and the core share a secret and agree on a set of
identifiers.
| Identifier | Meaning |
|---|---|
| PLMN — Public Land Mobile Network identity | The network's ID: a 3-digit Mobile Country Code (MCC) and a 2- or 3-digit Mobile Network Code (MNC). The gNB broadcasts it; the core serves it; the SIM belongs to it. |
| IMSI / SUPI | The subscriber's permanent identity. In 5G it is called the Subscription Permanent Identifier (SUPI); for SIM-based UEs it is the IMSI: MCC + MNC + a subscriber number. |
| SUCI | Subscription Concealed Identifier: the SUPI encrypted for transmission, so the permanent identity never crosses the air in clear text. |
| Ki and OPc | The subscriber's secret key and the operator variant key. Stored in the SIM and in the core's UDR, never transmitted. Used by the MILENAGE algorithm to compute authentication responses and session keys. |
| TAC — Tracking Area Code | Groups cells for paging. The gNB's TAC must be one the core serves. |
| DNN — Data Network Name | Which data network a PDU session connects to (the 5G successor of the LTE APN). The UE requests it; the core must have it configured for that subscriber. |
| S-NSSAI — Single Network Slice Selection Assistance Information | A slice identifier: a Slice/Service Type (SST) plus an optional Slice Differentiator (SD). |
Authentication is mutual. The core sends a random challenge and an authentication token; the SIM
checks that the token was produced with its own key (so the network is genuine) and returns a
response computed with the same key (so the UE is genuine). Neither side ever sends the key.
¶ The COSMOS standard
All COSMOS 5G stacks use two fleet-wide constants:
- PLMN
00101(MCC 001, MNC 01), a test network identity. The reason it is00101and not a
3-digit-MNC PLMN is the software UEs:srsueandlteuesplit an IMSI as MCC(3) + MNC(2) +
MSIN(10) and cannot form a 3-digit MNC. With a 2-digit MNC everywhere, a whole class of
registration failures (theRegistration reject [95]that follows a malformed IMSI) cannot occur. - UE pool
192.168.100.0/22, gateway192.168.100.1, with NAT to the internet. A /22 spans
192.168.100–192.168.103, four /24s, enough for one per data network where a stack needs
several.
The commercial UEs carry programmed test SIMs. The tutorials identify them by IMSI:
001010000000032 is the Quectel modem on sdr1-in3.sb1 and 001010000000033 the one on
node1.osc; the soft UEs use 001010123456780. The keys for these SIMs are inventory held on the
core servers: each core provisions its own subscriber database from that inventory, and keys never
appear in tutorials, bundles or consoles.
The DNN is per stack, so a UE must ask for the one its core serves: internet on the OCUDU
over-the-air tutorial with Open5GS, oai on every Duranta tutorial with OAI CN5G, and COSMOS-O in
the OCUDU 7.2 bundle. The slice is SST 1 (the Foxconn tutorial's Open5GS subscriber adds SD
000001). A UE that asks for a DNN the core does not serve receives an Unknown DNN reject and then
backs off before retrying; the tutorials clear that back-off with AT+CFUN=1,1.
¶ The attach story, step by step
Everything above comes together when a UE attaches. The figure shows the full exchange; the text
below walks through it and says what each step proves.
Figure — From cell search to user data. Note where each network function first appears: the AMF at registration, the AUSF/UDM at authentication, the SMF and UPF only at PDU-session establishment.
- NG Setup (before any UE). The gNB opens an SCTP association to the AMF and exchanges NG Setup
messages. The AMF checks that the gNB's PLMN and TAC are ones it serves; if not, the gNB receives
a failure such asunknown-PLMNand never activates its cell. - Cell search. The UE finds the SSB, reads the MIB and SIB1, and checks the PLMN. A modem with
the wrong band mask never looks at the right frequency and stays inSEARCH. - Random access (Msg1–Msg4). As described above. Failures here are physical-layer or timing
problems. - RRC connection. The UE completes RRC setup. Its first NAS message, the Registration
Request, rides inside the RRC Setup Complete message; the gNB forwards it to the AMF over N2. - Authentication. The AMF asks the AUSF, which asks the UDM for an authentication vector
computed from the subscriber's key. The challenge goes to the UE; the UE's answer comes back and
is checked. A wrong Ki or OPc in the core, or an IMSI the core does not know, fails here. - NAS security. The AMF sends a Security Mode Command; from here on NAS messages are
integrity-protected and ciphered. - Access-stratum security and UE context. The AMF sends the gNB an Initial Context Setup
Request with the keys and the UE's allowed slices; the gNB activates RRC-level security with the
UE and may ask for its radio capabilities. - Registration accept. The AMF accepts the registration and assigns a temporary identity; the
UE answers Registration Complete. The UE is now registered: the modem reports+C5GREG: 0,1. - PDU session establishment. The UE requests a data session for a DNN and slice. The AMF hands
the request to the SMF. The SMF selects a UPF, allocates an IP address from the pool, and installs
forwarding rules in the UPF over N4 (PFCP). It then asks the gNB, through the AMF, to set up the
radio bearer and the N3 tunnel. - User data. Packets flow UE → gNB → (GTP-U tunnel on N3) → UPF → N6 → NAT → internet.
On COSMOS, each of these steps has a line you can find in a log:
| Step | What proves it | Where |
|---|---|---|
| NG Setup | associated AMF 1; an established SCTP association on port 38412 |
Duranta gNB log; Amarisoft ss |
| Cell on air | cell PLMN 001.01 Cell ID ... is in service |
Duranta gNB log |
| Random access | Random Access Complete |
OCUDU soft-only UE log |
| RRC | RRC Connected |
OCUDU soft-only UE log |
| Registration | [gmm] INFO: [imsi-001010000000032] Registration complete |
Open5GS AMF log |
| Registration | +C5GREG: 0,1 |
Quectel modem |
| PDU session | PDU Session Establishment Accept, UE IPv4 192.168.100.2 |
Duranta nr-uesoftmodem log |
| User data | ping 0 % loss to the core gateway and to 8.8.8.8 |
UE |
Reading a failure against this sequence narrows it quickly. A UE that reaches RRC_CONNECTED and
then gets Authentication Reject has mismatched keys between the UE and the core (the Duranta
soft-only tutorial's troubleshooting covers this case). A UE that registers but whose PDU session is rejected has a
DNN, slice or IP-type mismatch. A UE that has an address but passes no data has a user-plane
problem, which can be a UE-side USB fault rather than anything in the RAN.
¶ The three COSMOS modalities
COSMOS runs every RAN stack in up to three ways, which differ only in what stands between the gNB's
physical layer and the UE.
Figure — Soft-only, over the air and O-RAN 7.2 side by side. The protocol stack above the physical layer is identical in all three; only the radio path changes.
| Modality | What replaces the radio | Where it runs | What it teaches | What it cannot tell you |
|---|---|---|---|---|
| Soft-only | A software transport carries baseband samples between gNB and soft UE: ZMQ (OCUDU) or RFsim (Duranta) | Any COSMOS server, one node | The full protocol flow: cell search, RACH, registration, PDU session | Anything about RF. Throughput measures the CPU. |
| Over the air (OTA) | The gNB drives a USRP software-defined radio directly; a commercial modem or a soft UE on a second USRP receives it | sb1 and grid, which have the USRPs |
Real RF, real modulation and coding, a commercial UE | The O-RAN split |
| O-RAN 7.2 | The gNB becomes an O-DU; a separate O-RU (commercial, or a soft O-RU driving a USRP) does the lower PHY and RF, joined by an Ethernet fronthaul with PTP timing | Fronthaul-capable servers on osc and sb1, O-RUs from the instrument domain |
Disaggregated RAN: fronthaul planes, timing windows, O-RU management | — |
Throughput numbers are only comparable within a modality. The soft-only cells run 10 MHz (OCUDU) or
106 PRB (Duranta), the over-the-air cells mostly 40 MHz, the commercial-O-RU cells 100 MHz, and the
soft-only numbers are set by the server CPU, not by any radio.
¶ How this maps onto COSMOS
| Concept | Where it lives on COSMOS |
|---|---|
| gNB / O-DU | OCUDU gnb (ocudu.ndz), Duranta nr-softmodem (duranta.ndz), Amarisoft lteenb (amarisoft.ndz) |
| 5G core | Open5GS, native systemd (OCUDU images); OAI CN5G, Docker containers (Duranta images); Aether SD-Core, Kubernetes on its own server; Amarisoft ltemme |
| AMF, SMF, UPF … | The NFs of whichever core the tutorial uses — see Open5GS, OAI CN5G, Aether SD-Core |
| Radio (OTA) | USRP N310 and X310 in sb1 and grid; a B210 in some rigs — see SDR hardware |
| Radio (7.2) | Commercial O-RUs parked in the instrument domain — see O-RAN radio units |
| UE | Quectel RM520N-GL modems on UE nodes (lte5gue.ndz) — see Commercial UE: the Quectel modem; soft UEs srsue, nr-uesoftmodem, lteue |
| Identities | PLMN 00101, pool 192.168.100.0/22, test SIMs whose keys live only on core servers |
The 5G SA platforms page compares the
three stacks and cores and helps you choose one.
¶ Common misconceptions and pitfalls
- "The gNB process is running, so the cell is on air." A gNB that fails NG Setup never activates
its cell, and in an O-RAN rig every fronthaul counter can be clean while the radio does not
transmit. Check the "in service" line and, for 7.2, the radio's own transmit power. - "Registered means working." Registration and the PDU session are separate procedures, and a UE
with an address can still pass no traffic. A Quectel modem's USB link can fail every transmitted
frame (-EPROTO); nothing then reaches the modem, and the symptom looks like a baseband bug on
any gNB stack. A USB device reset of the modem clears it. - "A 3-digit MNC should work with a soft UE." It cannot; that is why COSMOS standardised on
00101. - "Fixing the PLMN is enough." The TAC must match too. The core in the OCUDU over-the-air tutorial
serves TAC 7; a gNB configured with the right PLMN but TAC 1 still fails NG Setup. - "A default route via the modem is harmless." On a COSMOS UE node, a
default via wwan0route
black-holes the node's own management SSH. The tutorials install only a scoped route to
192.168.100.0/22. - "Low uplink means a bad link." On
DDDSUthe uplink has one slot in five. Compare uplink
numbers against the TDD pattern before suspecting the radio. - "The antenna is the problem." COSMOS radios in
osc,rrailandsb1share an RF space and
hear each other; RF problems are not blamed on "the antenna". Only one O-RU is powered at a time on
a shared RF space.
¶ Where to go next
- O-RAN architecture and the 7.2x fronthaul — how the gNB is split into O-DU and O-RU.
- 5G SA platforms on COSMOS — choose a RAN stack and a core.
- OCUDU 5G SA soft-only or Duranta 5G SA soft-only — watch every step of the attach story in the logs, with no radio.
- Course map — the full learning path.
¶ Further reading
- 3GPP TS 23.501 — 5G system architecture: network functions, reference points, identifiers, slicing.
- 3GPP TS 23.502 — 5G procedures: registration, authentication, PDU session establishment.
- 3GPP TS 38.300 — NR and NG-RAN overall description: protocol stack, random access, RRC states.
- 3GPP TS 38.401 — NG-RAN architecture: the CU/DU split, F1 and E1.
- 3GPP TS 38.211 — physical channels and modulation: numerology, frame structure, SSB, PRACH formats.
- 3GPP TS 38.104 — base station radio: operating bands, channel bandwidths, the NR-ARFCN and synchronization rasters.
- Open5GS documentation — a readable, working implementation of the core NFs.
- srsRAN Project documentation — gNB configuration explained parameter by parameter.
- OpenAirInterface — the OAI RAN and core projects that Duranta is built on.
Author(s): COSMOS team · Last reviewed: 2026-09-24 · Tags: 5g, sa, fundamentals, architecture, 5gc, nr, numerology, tdd, prach, registration, pdu-session, plmn, concepts