A real 4G and 5G network, per user, in a browser.

How a run works

You press Run. The progress panel names the stage the network is in and holds there until it really reaches the next one.

Measured on trace5g.com: 1 m 40 s from pressing Run to the first decoded record, and 9,654 records by the time that run was stopped 541 s later.

Every run is yours alone. Your network does not share a core, an IP range or a radio with anyone else, so its timing is its own.

Networks supported

Three networks, all real, all on the same radio.

Reading this table. OK means a run did it and its verdict recorded it. available means the product offers it and it has its own tests, and it is shown elsewhere on this page rather than here. — means not applicable to that network.

Nodes

What you can place on the canvas, what it really is, and where it is defined.

5G core (5G SA)

4G core (EPC)

IMS

The CSCF chain and the IMS subscriber database: what a session between two subscribers of one IMS needs, from REGISTER through to the media.

Interfaces

The canvas draws 34 interfaces and the run carries them. These are the reference points, not labels on a picture: traffic on them appears in the trace under the interface’s own name.

Protocol coverage

Not a list of what the analyzer could decode. This is a count of what two real runs actually produced. Every layer below appeared in the trace, with its own channel, direction and decode.

On the two empty cells. The 4G run had no IMS in its topology, so it produced no SIP. Neither run is 5G SA, so neither produced SBI. A 5G SA run does: on trace5g.com run a 5G SA run had SBI as its fourth busiest layer with 864 records, beside SIP 153, Diameter 96 and PFCP 220.

Channels seen in one 4G run

// distinct `channel` values in a 4G trace
DRB1   SRB1   SRB2   CCCH        // radio bearers and the common control channel
DL-SCH UL-SCH PDCCH PDSCH        // transport and physical channels
PUSCH  PUCCH                      // uplink shared and control
S1-MME S1AP  NAS   GTP            // core-facing

Radio profiles

Every parameter here is written into the real cell configuration and really boots. The band is a number on this radio; see the FAQ for exactly what that does and does not mean.

4G LTE and the NSA anchor

Channel bandwidth is physically real, and the throughput follows it. Measured on three labs of one run: 5 MHz → 1.16 MB/s, 15 MHz → 1.77 MB/s, 20 MHz → 2.26 MB/s, all at 0 % ping loss.

5G NR

The UE radio runs 15 kHz subcarrier spacing, so these four FDD bands are the supported set in 5G SA and in EN-DC. Reference: TS 38.101-1 Table 5.2-1 for the duplex mode, Table 5.3.5-1 for the channels.

Other radio parameters

Scenario library

A scenario is a list of real commands run against the live network after it boots. You build one in the Run dialog, or fire single actions from a node’s menu while the run is up. Every action below executes on the real node of the run.

The full action list

Reading a message

The Trace page is one screen with four parts. Everything on it is derived from the run’s own records.

1

2

3

4

5

6

• 1
  Menu bar. Run, Trace, View, Analysis, Scenario, Export, Help. Filters, layouts, per-node actions and downloads all live here.
• 2
  Message trace. One row per record: time, delta, protocol, node, channel, message, direction. Sortable and filterable by every column. The counter above it says exactly how many of how many are on screen.
• 3
  Decode panes. JSON · Message · Text · Hex. Four views of the selected record, described below.
• 4
  Sequence chart. The same records as a ladder between nodes. Click an arrow to select that record in the table, and vice versa. Tabs beside it switch to Timeline, Steps, KPIs and UE views.
• 5
  KPI strip. Procedures completed, procedure timings, rejects, DL/UL rate, BLER and SNR, all computed from this run’s records.
• 6
  Recorder. REC state, elapsed time, time left on the run, and Stop. Clicking it while a run boots reopens the progress panel.

Screenshot: a live 5G SA run on trace5g.com, 2026‑09‑10. Status bar reads “live · showing 1,356 of 5,272 records · 3,916 informational lines hidden”.

The four panes

Select any record and the right-hand pane shows it four ways. This is one real rrcReconfiguration, 110 bytes, sent by the gNB to UE‑2.

1

2

3

4

• 1
  The selected row in the trace, highlighted.
• 2
  The header of the decode: time, node, direction, protocol, channel, byte count and who sent it to whom: 110 bytes · gNB → UE-2.
• 3
  The decode itself, here as JSON: every information element, nested exactly as the ASN.1 defines it.
• 4
  The same record in the ladder, selected in step with the table.

JSON: the record as data

{
  "Time": "37.333 s",
  "Timestamp": "2026-09-10T22:48:08.246Z",
  "Source": "gNB",  "UE": "UE-2",
  "Protocol": "RRC", "Interface": "DCCH", "Direction": "DL",
  "Message": "c-rnti=0x4602: DL rrcReconfiguration (110 B)",
  "Length": 110,
  "IEs": { /* the full tree, below */ }
}

Copyable from the pane. This is the shape every record has, so a trace can be processed outside the product as well as read inside it.

Message: the IE tree

1

DL-DCCH-Message → message → c1 → rrcReconfiguration
  rrc-TransactionIdentifier : 3
  criticalExtensions → rrcReconfiguration
    radioBearerConfig
      srb-ToAddModList  → [0] srb-Identity : 2
      drb-ToAddModList  → [0]
        cnAssociation → sdap-Config
            pdu-Session : 1
            sdap-HeaderDL : absent
            sdap-HeaderUL : absent
            defaultDRB : true
            mappedQoS-FlowsToAdd : [0] 1
        drb-Identity : 1
        pdcp-Config → drb
            discardTimer : infinity
            pdcp-SN-SizeUL : len18bits
            pdcp-SN-SizeDL : len18bits
            headerCompression : …

What you are looking at. A data radio bearer being added, with its SDAP mapping to PDU session 1 (TS 37.324), its DRB identity, and its PDCP configuration: 18-bit sequence numbers, no discard timer, header compression off. Reference: TS 38.331 §6.3.2 RadioBearerConfig.

Hex: the bytes on the wire

1

0000  06 8a 80 40 9a 01 e0 02 05 e3 f0 a5 00 d2 c0 15   ...@............
0010  84 88 8b d7 63 80 83 2f 00 05 8e 01 86 2a fe 40   ....c../.....*.@
0020  90 69 e0 80 20 46 00 40 11 1f 80 b9 56 c3 ea 40   .i.. F.@....V..@
0030  df 80 1a 00 40 0d 4b 80 40 70 84 40 02 40 40 01   ....@.K.@p.@.@@.
0040  8c 4c

The octets the tree above was decoded from. Offset, hex, ASCII: the usual three columns, so you can check the decode against the spec yourself.

Text: the flat form

00:00:37.333 [gNB] RRC / DCCH — c-rnti=0x4602: DL rrcReconfiguration (110 B)
  [0] DL-DCCH-Message
    message  c1  rrcReconfiguration
      rrc-TransactionIdentifier : 3
      criticalExtensions  rrcReconfiguration  radioBearerConfig
        srb-ToAddModList [0] srb-Identity : 2
        drb-ToAddModList [0] cnAssociation …

The same tree without punctuation, for pasting into a ticket, an email or a report.

KPIs

The strip along the bottom is computed in your browser from the records of your run. Nothing on it is a default, and a value with nothing behind it reads — rather than zero.

// read from the live page
13/16 procedures ok · Registration <1 ms · PDU session … · RRC setup 99 ms
0 rejects · DL 48 kb/s · UL 93 kb/s · BLER 0.0% · SNR 69.6 dB

A run’s full radio metrics are richer than the strip: PRB counts per direction, modulation histograms, HARQ retransmissions, PRACH count, PUCCH count, per-RNTI breakdown and timing-advance reading are all recorded.

Building a lab, running it, keeping it

Build

1

2

3

4

5

• 1
  Lab name and summary. UEs, base stations, core nodes, services and interfaces, counted from what is on the canvas. While a run is recording it describes the run.
• 2
  Technology tabs. 5G SA, 5G NSA, 4G LTE. Switching rebuilds the topology for that network.
• 3
  The element rail. Base stations, UEs, the voice core and the application function. Click to add; the count beside each is what the lab holds.
• 4
  Node inspector. Every parameter of the selected node. Here the gNB: band, bandwidth, SCS, numerology, PRB count, Ts, gains, antennas, ARFCN, PLMN, PCI, TAC.
• 5
  Run. Opens the run dialog.

Note Address (assigned on run) — at the bottom of the inspector: before a run there is no address, so the field is empty rather than guessed.

Choose what happens after it boots

1

2

3

• 1
  Boot estimate and the promise that steps are optional: a lab can simply boot and wait for you.
• 2
  The steps. Each one picks a target, an action and its parameters, plus when to run it: so many seconds after boot, or after the previous step. Each row says what it expects, e.g. expect: SIP 200 OK (REGISTER).
• 3
  Run. The network boots and the steps execute against it in order.

What a call and a text look like as steps

1

• 1
  With two subscribers on the voice core, the UE’s action list carries Call another UE and Send an SMS to another UE beside register, hang up, deregister and status. With only one subscriber they are absent, because a call needs somebody on the other end.

While it boots

1

• 1
  The panel names the stage the run has really reached and holds there until it reaches the next one, rather than running a timer. Dismiss it and the REC chip in the header brings it back.

History and replay

1

2

• 1
  Every finished run of yours: when, which network, how long, how many records.
• 2
  open trace reloads the whole run into the analyzer: the same table, ladder, decodes and KPIs as when it was live.

Screenshot of a saved 4G trace reopened in the analyzer (4G LTE, 1 UE, 3 m 37 s, 232,952 records).

Radio parameters are pickers, not prose

1

• 1
  Band and channel bandwidth for a 4G cell: bands 1, 3, 7, 8, 20 and 28 at 5, 10, 15 or 20 MHz. The derived facts (n_PRB, Ts, the valid EARFCN range for the chosen band) update beside them.

What’s new

Capabilities the platform gained, most recent first.

Specifications

What a lab supports today. The list grows; nothing here is a permanent ceiling.

3GPP index

The specifications this platform implements against, referenced directly in its source. Fifty-two distinct documents.