Reading a Signalling Trace (Wireshark)

Why capture the control plane, and where you tap it

The control plane is the signalling that arranges everything before (and around) user data: authentication, security, context setup, session establishment, handover. When a UE fails to attach, cannot get an IP address, or drops during mobility, the answer is almost always sitting in a control-plane message that carried a reject cause, a missing IE, or a mismatched capability. A trace lets you see that message verbatim instead of guessing from counters.

The catch is where you can realistically tap. The radio interface — NR-Uu in 5G, LTE-Uu in LTE — is over the air and encrypted; you cannot sniff it with a NIC. So you capture on the wired interfaces between network functions, or you rely on instrumented test tools and node logs. The most productive tap points are:

For a first attach investigation the single best capture is N2 (or S1-MME in LTE): one interface gives you both the RAN-signalling procedures and the NAS messages the UE exchanges with the core. Air-interface RRC is only visible if your gNB or UE simulator exports it — real deployments dump it to node logs rather than a NIC.

The protocol stack inside one packet

Reading a trace is really about reading nesting. One frame on N2 is not one protocol — it is a stack of them wrapped inside each other, outermost transport first, innermost application last. For an InitialUEMessage the layers are Ethernet / IP → SCTP → NGAP → NAS-5GS. Wireshark shows exactly this nesting as an indented tree; learning to read the indentation is 80% of the skill.

Ethernet II, Src: gNB (aa:bb:cc:00:00:02), Dst: AMF-GW (aa:bb:cc:00:00:10)
Internet Protocol Version 4, Src: 10.10.0.2, Dst: 10.0.0.10
Stream Control Transmission Protocol
    Source port: 60138   Destination port: 38412
    Verification tag: 0x1a2b3c4d
    DATA chunk (ordered, stream: 0, ssn: 0)
        Payload protocol identifier: NGAP (60)
NG Application Protocol (NGAP)
    NGAP-PDU: initiatingMessage (0)
        procedureCode: id-InitialUEMessage (15)
        protocolIEs
            RAN-UE-NGAP-ID: 1
            NAS-PDU: 7e004179000d... [Registration request]
NAS-5GS Mobile Management Message
    Extended protocol discriminator: 5GS mobility management (126)
    Message type: Registration request (0x41)
    5GS registration type: initial (1)

Notice how the tree resets to column 0 four times — once per protocol layer (Ethernet, IP, SCTP, NGAP, then NAS-5GS). Everything indented under a layer is a field of that layer. Read top to bottom and each question answers the next: which machines (Ethernet/IP), which association and dissector (SCTP ports + PPID), which RAN procedure (NGAP procedureCode), and finally which NAS message the UE actually sent (NAS-5GS Message type).

Wireshark essentials: panes, filters, streams

Wireshark has three stacked panes and you use all three. The packet list (top) is one row per frame — number, time, source, destination, protocol, length, and an info summary. The packet details (middle) is the nested tree from the previous section for whichever row you selected. The packet bytes (bottom) is the raw hex; you rarely need it except to confirm an octet a dissector got wrong.

The single most important skill is the display filter — the expression bar that hides everything except matching frames. It does not delete packets, only shows a subset, so you can iterate freely. Type a protocol name to keep only that protocol, or a field expression to zoom in:

Filters combine with &&, ||, and !: ngap && nas-5gs isolates NGAP frames that carry a NAS payload, and !sctp.chunk_type == 3 hides SCTP SACKs so heartbeats stop cluttering the list. Right-clicking any field in the details pane offers Apply as Filter, which writes the correct expression for you — the fastest way to learn field names.

Follow Stream (right-click → Follow) reassembles one conversation end to end. For HTTP/2 SBI or SIP it stitches the request/response pairs; for SCTP it follows one association so you see a single UE's NGAP dialogue without interleaving.

Colouring rules give the list visual meaning: TCP resets and SCTP aborts turn red, retransmissions go black-on-red, and you can add a custom rule (for example, colour nas-5gs.mm.message_type == 0x44, a Registration reject, bright orange) so failures jump out of a long trace.

Reading NAS inside NGAP

The most confusing thing for newcomers is that NAS is not a separate packet on the wire. NAS messages travel between the UE and the AMF as an opaque octet string — the NAS-PDU IE — carried inside NGAP procedures such as InitialUEMessage, DownlinkNASTransport, and UplinkNASTransport. The RAN never interprets NAS; it only relays the bytes. Wireshark, however, recognises the NAS-PDU IE and automatically re-dissects those bytes as NAS-5GS, showing them as a fresh layer at column 0 below the NGAP tree.

So when you select an InitialUEMessage and expand it, you get two things in one row: the NGAP envelope (procedure code, RAN-UE-NGAP-ID, location) and, nested through the NAS-PDU, the full Registration request the UE composed — its registration type, its concealed identity (SUCI), its security capabilities, and its requested slices.

NG Application Protocol (NGAP)
    NGAP-PDU: initiatingMessage (0)
        procedureCode: id-InitialUEMessage (15)
        protocolIEs
            RAN-UE-NGAP-ID: 1
            NAS-PDU: 7e004179000d0119... [dissected below]
            UserLocationInformation: nR-CGI (PLMN 311/480, NCI 0x00A1B2C0)
            RRCEstablishmentCause: mo-Signalling (3)
NAS-5GS Mobile Management Message
    Extended protocol discriminator: 5GS mobility management (126)
    Security header type: Plain NAS message, not protected (0)
    Message type: Registration request (0x41)
        5GS registration type: initial (1)
        5GS mobile identity: SUCI, MCC=311 MNC=480, scheme=ECIES profile A
        ngKSI: no key available (7)
        UE security capability: 5G-EA0/1/2, 5G-IA1/2

Read it as a handoff: NGAP tells you the gNB relayed the UE's first message and where the UE is; the nested NAS-5GS tells you the UE is doing an initial registration, is hiding its identity behind a SUCI, and has no security key yet (ngKSI = 7). In LTE the same pattern holds — NAS travels as a NAS-EPS octet string inside S1AP and Wireshark re-dissects it identically.

An annotated attach, packet by packet

Here is the spine of a registration as it appears on N2. Follow the numbers and read the one-line cue under each block — that is the field to check first.

NG Application Protocol (NGAP)
    procedureCode: id-InitialUEMessage (15)
    RAN-UE-NGAP-ID: 1
    NAS-PDU: Registration request (initial), SUCI 311/480

Look for: Message type: Registration request and 5GS registration type. This is where the dialogue starts and where the RAN-UE-NGAP-ID is born.

NG Application Protocol (NGAP)
    procedureCode: id-DownlinkNASTransport (4)
    AMF-UE-NGAP-ID: 1   RAN-UE-NGAP-ID: 1
NAS-5GS Mobile Management Message
    Message type: Authentication request (0x56)
        ngKSI: 0   ABBA: 0x0000
        Authentication parameter RAND / AUTN present

Look for: the appearance of AMF-UE-NGAP-ID (the core now has a context) and RAND/AUTN in the NAS. Still Plain NAS, so every field is readable.

NAS-5GS Mobile Management Message
    Security header type: Integrity protected (1)
    Message type: Security mode command (0x5d)
        Selected NAS security algorithms: 5G-EA2, 5G-IA2
        ngKSI: 0   Replayed UE security capabilities present

Look for: Selected NAS security algorithms. From the UE's Security mode complete onward, NAS is ciphered and only headers stay visible.

NG Application Protocol (NGAP)
    procedureCode: id-InitialContextSetup (14)
    AMF-UE-NGAP-ID: 1   RAN-UE-NGAP-ID: 1
    SecurityKey: K_gNB (256-bit)
    UESecurityCapabilities / GUAMI / AllowedNSSAI present

Look for: SecurityKey (the K_gNB handed to the gNB) and AllowedNSSAI. This NGAP-only procedure sets up AS security and the UE context on the RAN.

NAS-5GS Mobile Management Message
    Security header type: Integrity protected and ciphered (2)
    Message type: Registration accept (0x42)
        5G-GUTI assigned
        TAI list / Allowed NSSAI present

Look for: Message type: Registration accept and the assigned 5G-GUTI. If instead you see Registration reject, the 5GMM cause field is your root cause. This is the message that means the attach succeeded.

Common gotchas

A few things routinely trip people up when they first read control-plane traces.

Encrypted NAS. After Security mode command/complete, NAS messages carry Security header type = Integrity protected and ciphered. Wireshark can show the header and the message type wrapper but the plaintext body is opaque — you will not see the IEs unless you feed Wireshark the keys or capture before security activates. If a field you need has gone missing mid-trace, this is usually why.

SCTP multihoming and multiple streams. An SCTP association can run over two IP paths (multihoming), so the same logical link may show two source addresses; do not mistake them for two associations. Within one association there are many streams, and different UEs' NGAP dialogues ride different stream numbers — filter by SCTP verification tag or use Follow Stream to isolate one UE rather than reading by IP alone.

Wrong PPID. If NGAP shows up as undecoded data, the sender set a non-standard Payload Protocol Identifier. Use Decode As to map the SCTP port or PPID to the NGAP dissector.

Fragmented reassembly. Large messages (a big RRCReconfiguration, a fat InitialContextSetupRequest) span multiple SCTP DATA chunks or IP fragments. Keep Allow subdissector to reassemble enabled, and read the frame Wireshark marks as the reassembled whole, not the individual fragments.

GTP-U versus GTP-C. Both use the name GTP but are different planes: GTP-C (control) on port 2123 signals tunnel management in EPC, while GTP-U (user) on port 2152 carries the actual data on N3/S1-U. When chasing signalling, filter gtp can flood you with user-plane frames — narrow to gtpv2 for control or exclude udp.port == 2152.

Display-filter reference

Keep this table beside you. Start broad (a protocol name), confirm the conversation, then narrow to a field once you know what you are chasing.