End-to-End Attach Call Flow in LTE 4G

Introduction

The LTE Attach is the one procedure that takes a device from "powered off" to "online with an IP address and a working data pipe". It is where the radio side (cell search, random access, RRC) and the core side (MME, S-GW/P-GW, HSS) meet: a single successful attach authenticates the subscriber, registers their location, creates an IP session, and switches on a Data Radio Bearer for user traffic. It happens at power-on, after coming back from a long detach, and after certain failures — and every "device cannot get service" ticket eventually gets traced through it.

Attach is best understood as four phases (used throughout this page): physical-layer cell search where the UE synchronises to PSS/SSS, decodes the MIB on PBCH and reads SIB1/SIB2 to camp (A); contention-based four-message random access that establishes uplink and carries the first NAS message to the MME (B); primary authentication with the HSS over S6a and NAS security establishment (C); and default-bearer session creation across S-GW/P-GW followed by Initial Context Setup, RRC reconfiguration and Attach Accept so data can flow (D). Everything is grounded in TS 23.401 (EPS procedures) and TS 36.300 (E-UTRAN overall architecture).

Because attach is a long chain of distinct messages across many interfaces, a failure almost always lives in one specific step. Walking the messages in order — and knowing which node owns each one — turns a vague "attach failure" into a precise, testable hypothesis. That is why each step below lists the exact 3GPP message, the interface it crosses, the key Information Elements with realistic example values, a representative packet capture, and per-step debugging notes.

Why Attach is needed

Concretely, four things must happen before a single user packet can flow. The subscriber must be authenticated so the network knows the USIM is genuine and the UE knows the network is genuine (mutual EPS-AKA). The UE's location must be registered with the HSS so the network can page it later. Security must be established so NAS and AS signalling are ciphered and integrity-protected. And an IP session must be created — a default EPS bearer with an IP address and a QoS profile — because EPS is always-on by design and there is no data path until that bearer exists. Attach performs all four in one procedure.

Call flow

The message-sequence chart below condenses the whole Attach into a single picture: the UE sets up RRC, the eNB relays the first NAS message to the MME, the MME authenticates the subscriber against the HSS and builds the default bearer across the S-GW/P-GW, and the radio bearer is switched on so data can flow.

1. RRCConnectionRequest — the UE requests an RRC connection over the air.
2. RRCConnectionSetup — the eNB grants SRB1 and the RRC connection.
3. RRCConnectionSetupComplete carrying the NAS Attach Request and PDN Connectivity Request.
4. The eNB relays the NAS PDU to the MME in an Initial UE Message (S1AP).
5. The MME fetches authentication vectors from the HSS (Authentication Information Request/Answer) and runs EPS-AKA with the UE.
6. NAS Security Mode Command / Complete activates NAS ciphering and integrity.
7. The MME registers the UE's location with the HSS via Update Location Request/Answer.
8. The MME builds the default bearer across the S-GW/P-GW with Create Session Request/Response.
9. Initial Context Setup Request hands the eNB the Attach Accept and the activation of the default EPS bearer.
10. The eNB delivers it to the UE in RRCConnectionReconfiguration (embedding the Attach Accept).
11. The UE confirms with RRCConnectionReconfigurationComplete.
12. The eNB returns Initial Context Setup Response (with its downlink S1-U TEID) to the MME.
13. The UE sends Attach Complete up as an UL Information Transfer.
14. The MME stitches the downlink path with Modify Bearer Request/Response and user data flows.

Call flow at a glance

Phase A — Power-On & Cell Search (Steps 1–4)

When you power on, the UE has no timing, no frequency lock, and no idea which cell to use. This phase covers the entirely physical-layer-driven process of finding a synchronisation signal, decoding the minimum system information on PBCH, reading SIB1/SIB2, and finally deciding the cell is suitable to camp on. Nothing is transmitted by the UE here — it is receive-and-measure until camping completes and the NAS layer triggers Attach.

On power-up the modem loads its supported-band table and reads the USIM to obtain the permanent identity (IMSI) and the Home PLMN. If a previously used carrier is stored, the UE tunes there first for fast camping; otherwise it performs an initial cell-selection full scan across each supported band's EARFCN raster. For every candidate carrier it measures wideband RSSI to rank the strongest cells before attempting PSS/SSS correlation.

LTE PHY Layer-1 trace (UE modem, not a radio frame)
    Event: power-on / USIM read
    USIM: IMSI=310410123456789  HPLMN=310/410  EPS supported
    Cell-selection: mode=stored-information (3 stored freqs)
    Band scan: B7  EARFCN 2850 → f=2680.0 MHz
    Wideband RSSI: -71.4 dBm (candidate, shortlisted)

The UE correlates the received signal against the three Primary Synchronization Signals (Zadoff-Chu sequences) to acquire OFDM symbol timing and the physical-layer identity within the group, N_ID(2) ∈ {0,1,2}. It then decodes the Secondary Synchronization Signal to obtain the identity group N_ID(1) ∈ {0..167} and forms the Physical Cell ID as PCI = 3×N_ID(1) + N_ID(2). SSS position also tells the UE whether it is FDD or TDD and yields 5 ms half-frame timing, and the UE measures RSRP on the reference signals to gauge cell quality.

LTE PHY Layer-1 trace (PSS/SSS acquisition, not a decoded packet)
    PSS: correlation peak, N_ID(2)=0, symbol offset 137
    Coarse timing locked, CFO +1.1 kHz corrected
    SSS: N_ID(1)=56  duplex=FDD  half-frame=0
    PCI = 3*56 + 0 = 168
    CP: normal  frame boundary at subframe 0
    Measurement: RSRP -88.1 dBm  RSRQ -10.5 dB  SINR 9.8 dB

With timing and PCI in hand the UE decodes the Physical Broadcast Channel, which carries the Master Information Block in the centre 72 subcarriers of subframe 0. The MIB is deliberately small: it provides the downlink channel bandwidth (in resource blocks), the PHICH configuration (duration and Ng resource), and the most-significant bits of the System Frame Number. The four MIB copies within a 40 ms window let the UE resolve the full SFN and confirm decode by blind detection of the scrambling. The MIB is the minimum needed before the UE can find SIB1.

LTE Radio Resource Control (RRC) protocol
    BCCH-BCH-Message
        message: mib
            mib
                dl-Bandwidth: n100 (5)
                phich-Config
                    phich-Duration: normal (0)
                    phich-Resource: oneSixth (0)
                systemFrameNumber: 01101001 [8 MSB, SFN 420]
                schedulingInfoSIB1-BR-r13: 0 [not present]
                spare: 0000000000 [10 bits]

The UE monitors PDCCH for a DCI whose CRC is scrambled by the SI-RNTI (0xFFFF), which schedules SystemInformationBlockType1 on the PDSCH. SIB1 advertises the cellAccessRelatedInfo (PLMN list, trackingAreaCode, cellIdentity), cell-barring status, the cell-selection q-RxLevMin, and the scheduling of the remaining SIBs. SIB2 follows in its SI window and delivers the shared radio resource configuration — crucially the RACH-ConfigCommon the UE needs to attempt random access. After checking the S-criteria and confirming the PLMN is allowed, the UE camps and the NAS layer triggers Attach.

LTE Radio Resource Control (RRC) protocol
    BCCH-DL-SCH-Message
        message: c1 (0)
            c1: systemInformationBlockType1 (0)
                systemInformationBlockType1
                    cellAccessRelatedInfo
                        plmn-IdentityList: 1 item
                            plmn-Identity: MCC=310 MNC=410
                            cellReservedForOperatorUse: notReserved (1)
                        trackingAreaCode: 0x1a2b
                        cellIdentity: 00a1b20 [28 bits]
                        cellBarred: notBarred (1)
                        intraFreqReselection: allowed (0)
                    cellSelectionInfo
                        q-RxLevMin: -62 [-124 dBm]
                    freqBandIndicator: 7
                    schedulingInfoList: SIB2 (si-Periodicity rf16)
                    si-WindowLength: ms20 (4)

Phase B — Random Access & RRC Connection (Steps 5–9)

To move from camped/idle to connected the UE performs contention-based four-step random access. Msg1 is a PRACH preamble, Msg2 is the MAC Random Access Response granting timing advance and an uplink allocation, Msg3 is the first scheduled uplink transmission carrying RRCConnectionRequest, and Msg4 resolves contention while delivering RRCConnectionSetup and SRB1. The UE then completes the setup and piggybacks its first NAS message — the Attach Request — inside RRCConnectionSetupComplete.

The UE selects a random contention-based preamble from the 64 available Zadoff-Chu sequences and transmits it on a PRACH occasion derived from the SIB2 prach-ConfigIndex. It computes the RA-RNTI from the time/frequency of the chosen PRACH resource so it can later find its response. Transmit power follows open-loop rules (preambleInitialReceivedTargetPower plus estimated pathloss) and ramps up by powerRampingStep on each retry if no RAR arrives. This is contention-based access because the UE has no dedicated preamble.

LTE PHY Layer-1 trace (PRACH preamble Tx, no decodable payload)
    RA trigger: initial access (RACH config from SIB2)
    Serving cell: PCI 168 (RSRP -88 dBm)
    preamble-Index (RAPID): 27  [group A]
    ra-RNTI: 0x0002  (subframe 1, PRACH freq resource 0)
    PRACH format 0, prach-ConfigIndex 3, freqOffset 2
    Tx power: +6 dBm  (target -104 dBm + pathloss ~110 dB, attempt 1)

The eNB detects the preamble and, within the ra-ResponseWindow, transmits a MAC PDU addressed by the RA-RNTI on PDSCH. The RAR echoes the detected RAPID, carries an 11-bit Timing Advance command to align uplink timing, an uplink grant for Msg3, and a Temporary C-RNTI. The UE matches the RAPID to its chosen preamble, applies the timing advance to achieve uplink synchronisation, and prepares Msg3 on the granted resources.

MAC-LTE
    Context
        Direction: Downlink
        RNTI Type: RA-RNTI
        RA-RNTI: 0x0002 (7)
    MAC subheader
        E: 0   T: 1 (RAPID present)
        RAPID: 27 (matches transmitted preamble)
    MAC RAR
        Timing Advance Command: 31
        UL Grant: 0x1A2F4 (MCS 4, 3 PRB, Msg3 56 bits)
        Temporary C-RNTI: 0x3D01
        Backoff Indicator: not present

Using the Msg2 uplink grant, the UE sends RRCConnectionRequest on CCCH/SRB0, scrambled with the Temporary C-RNTI. It carries a 40-bit ue-Identity — the S-TMSI if the UE has one from a prior EPC attach, otherwise a random value — plus an establishmentCause that tells the network why the connection is needed (here mo-Signalling for the attach). Because multiple UEs may have used the same preamble, this message begins contention resolution.

LTE Radio Resource Control (RRC) protocol
    UL-CCCH-Message
        message: c1 (0)
            c1: rrcConnectionRequest (1)
                rrcConnectionRequest
                    criticalExtensions: rrcConnectionRequest-r8 (0)
                        rrcConnectionRequest-r8
                            ue-Identity: s-TMSI (0)
                                s-TMSI
                                    mmec: 0x01
                                    m-TMSI: 0x0c1a55e3
                            establishmentCause: mo-Signalling (2)
                            spare: 0 [bit length 1]

The eNB responds with RRCConnectionSetup on DL-CCCH, echoing the CCCH bits for contention resolution and promoting the Temporary C-RNTI to a permanent C-RNTI. The message carries radioResourceConfigDedicated that establishes SRB1 with its RLC (acknowledged mode), logical channel and MAC main configuration, plus physicalConfigDedicated for the UE. Once the UE applies it and confirms contention resolution, the RRC connection moves to RRC_CONNECTED and signalling continues on SRB1.

LTE Radio Resource Control (RRC) protocol
    DL-CCCH-Message
        message: c1 (0)
            c1: rrcConnectionSetup (0)
                rrcConnectionSetup
                    rrc-TransactionIdentifier: 0
                    criticalExtensions: c1 (0)
                        c1: rrcConnectionSetup-r8 (0)
                            radioResourceConfigDedicated
                                srb-ToAddModList: 1 item
                                    srb-Identity: 1
                                    rlc-Config: explicitValue (am)
                                    logicalChannelConfig: priority 1
                                mac-MainConfig: explicitValue
                                physicalConfigDedicated: pucch/pdsch cfg

The UE answers Msg4 with RRCConnectionSetupComplete on SRB1, and inside it piggybacks the very first NAS message: the Attach Request together with a PDN Connectivity Request. Attaching to EPS is always-on by design — the network creates a default EPS bearer as part of attach, so bundling the PDN Connectivity Request lets the MME start building the IP session immediately and saves a round-trip. The Attach Request declares the attach type, the UE identity (GUTI if known, otherwise the network asks for IMSI), the UE network capabilities (supported EEA/EIA algorithms) and DRX parameters. On a first-ever attach there is no security context yet, so this message is neither ciphered nor integrity protected.

LTE Radio Resource Control (RRC) protocol
    UL-DCCH-Message
        message: c1 (0)
            c1: rrcConnectionSetupComplete (4)
                rrcConnectionSetupComplete-r8
                    selectedPLMN-Identity: 1 [310/410]
                    dedicatedInfoNAS: 7441...
Non-Access-Stratum (NAS) PDU
    EPS mobility management message
        Security header type: Plain NAS message (0)
        Message type: Attach request (0x41)
        EPS attach type: EPS attach (1)
        EPS mobile identity: IMSI 310410123456789
        UE network capability: EEA0/1/2 EIA1/2
        ESM message container: PDN connectivity request (PDN type IPv4)

Phase C — Attach, Identity & Authentication (Steps 10–12)

The MME now owns the procedure. The eNB relays the Attach Request over S1-MME, the MME resolves the subscriber identity and runs EPS-AKA against the HSS over the Diameter S6a interface, and then activates NAS security. From the end of this phase every NAS message is ciphered and integrity protected.

The eNB extracts the NAS PDU from RRCConnectionSetupComplete and forwards it to a selected MME in an S1AP Initial UE Message over the S1-MME interface. NAS and AS are separate layers: the eNB only sets up the RRC connection, while the Attach Request is meant for the MME, so piggybacking it on the first uplink RRC message gets it there in the earliest possible message. The eNB binds an eNB UE S1AP ID, includes the RRC Establishment Cause, and reports the TAI and E-UTRAN CGI so the MME knows where the UE is. The MME creates a UE context and begins the EMM attach procedure.

Stream Control Transmission Protocol
    Source port: 36412   Destination port: 36412
    Payload protocol identifier: S1AP (18)
S1 Application Protocol
    initiatingMessage
        procedureCode: id-initialUEMessage (12)
        eNB-UE-S1AP-ID: 1024
        NAS-PDU: 7441... [Attach request]
        TAI: PLMN 310/410, tAC 0x1a2b
        EUTRAN-CGI: PLMN 310/410, cell-ID 0x00a1b20
        RRC-Establishment-Cause: mo-Signalling (0)
        S-TMSI: mMEC 0x01, m-TMSI 0x0c1a55e3

If the MME cannot resolve the UE from a GUTI it first runs Identity Request/Response to obtain the IMSI, then performs EPS-AKA. It asks the HSS for an authentication vector with the Diameter S6a Authentication-Information-Request; the HSS runs Milenage and returns an EPS Authentication Vector in the Authentication-Information-Answer — RAND, AUTN, XRES and the key K_ASME derived for this serving network. The MME then challenges the UE with the NAS Authentication Request (RAND, AUTN, KSI_ASME). The USIM verifies AUTN (network authenticity and sequence number), computes RES, and the UE returns it in the Authentication Response. The MME compares RES to XRES; a match means mutual authentication has succeeded and K_ASME is anchored on both sides.

Diameter Protocol
    Version: 0x01
    Command Code: 318 (Authentication-Information)
    Flags: 0xc0 (Request, Proxyable)
    ApplicationId: 3GPP S6a/S6d (16777251)
    AVP: User-Name (1) = 310410123456789
    AVP: Visited-PLMN-Id (1407) = 310/410
    AVP: Requested-EUTRAN-Authentication-Info
        Number-Of-Requested-Vectors (1410): 1
        Immediate-Response-Preferred (1412): 1
    AVP: Auth-Session-State (277) = NO_STATE_MAINTAINED (1)

S1 Application Protocol
    initiatingMessage
        procedureCode: id-downlinkNASTransport (11)
        MME-UE-S1AP-ID: 40551
        eNB-UE-S1AP-ID: 1024
        NAS-PDU: 0752...
Non-Access-Stratum (NAS) PDU
    EPS mobility management message
        Security header type: Plain NAS message (0)
        Message type: Authentication request (0x52)
        NAS key set identifier (eKSI): 0
        Authentication parameter RAND: 8f3a...c21d
        Authentication parameter AUTN: 1b77...a904

The MME selects a ciphering algorithm (EEA) and an integrity algorithm (EIA) and sends an integrity-protected NAS Security Mode Command, replaying the UE's security capabilities so the UE can detect a bidding-down attack. The UE derives K_NASenc and K_NASint from K_ASME, verifies the MAC, and answers with a ciphered and integrity-protected Security Mode Complete which may carry the IMEISV. From here every NAS message is protected.

S1 Application Protocol
    initiatingMessage
        procedureCode: id-downlinkNASTransport (11)
        MME-UE-S1AP-ID: 40551
        eNB-UE-S1AP-ID: 1024
        NAS-PDU: 3721...
Non-Access-Stratum (NAS) PDU
    EPS mobility management message
        Security header type: Integrity protected with new EPS context (3)
        Message type: Security mode command (0x5d)
        Selected NAS security algorithms: EEA2 / EIA2
        NAS key set identifier (eKSI): 0
        Replayed UE security capabilities: EEA0/1/2, EIA1/2
        IMEISV request: requested (1)

Phase D — Session Creation, Bearer Setup & Attach Accept (Steps 13–18)

With the subscriber authenticated and NAS security active, the MME builds the IP session across the S-GW/P-GW, hands the eNB everything it needs to set up the radio bearer and AS security, and delivers the Attach Accept. Once the UE confirms, the downlink path is stitched end-to-end and user data flows on the default EPS bearer.

The MME creates the EPS session on the user plane using GTPv2-C. It sends a Create Session Request to the Serving Gateway over S11, which relays it to the PDN Gateway over S5/S8. The P-GW allocates the UE's IP address (PDN Address), sets up the default EPS bearer with the negotiated QoS (QCI and ARP), and returns the S5/S8 and S1-U TEIDs in the Create Session Response. The core-side data path is now half-built — it still needs the eNB's downlink TEID, which arrives later in Step 17.

User Datagram Protocol, Src Port: 2123, Dst Port: 2123
GPRS Tunneling Protocol V2
    Flags: 0x48 (version 2)
    Message Type: Create Session Request (32)
    Tunnel Endpoint Identifier: 0x00000000
    IMSI: 310410123456789
    Access Point Name (APN): internet
    Bearer Context [Grouped IE]
        EPS Bearer ID (EBI): 5
        Bearer Level QoS: QCI 9, ARP 8
    F-TEID: S-GW S1-U, TEID 0x0A00071E, IPv4 10.10.10.1
    PDN Address Allocation (PAA): IPv4 10.44.7.201
    Aggregate Maximum Bit Rate (APN-AMBR): DL 150M, UL 50M

The MME hands everything the eNB needs in one S1AP message. It carries the AS root key K_eNB (derived from K_ASME), the UE Security Capabilities, the UE-AMBR, the E-RAB To Be Setup List for the default bearer (E-RAB ID, QoS, and the S-GW S1-U TEID for uplink data), and — embedded as a NAS PDU — the Attach Accept with the Activate Default EPS Bearer Context Request for the eNB to deliver to the UE. The eNB uses this to compute the AS keys and to build the RRC reconfiguration.

Stream Control Transmission Protocol
    Payload protocol identifier: S1AP (18)
S1 Application Protocol
    initiatingMessage
        procedureCode: id-InitialContextSetup (9)
        MME-UE-S1AP-ID: 40551
        eNB-UE-S1AP-ID: 1024
        uEaggregateMaximumBitRate: DL 150M / UL 50M
        E-RABToBeSetupListCtxtSUReq: 1 item
            E-RAB-ID: 5
            E-RABlevelQoSParameters: QCI 9, ARP 8
            transportLayerAddress: 10.10.10.1
            gTP-TEID: 0x0A00071E
        SecurityKey (KeNB): 6a1f...e0b3
        UESecurityCapabilities: EEA2 / EIA2
        NAS-PDU: 0742... [Attach accept, embedded]

The eNB activates access-stratum security and configures the radio bearers. In practice AS security (K_RRCenc, K_RRCint, K_UPenc derived from K_eNB) is turned on first, then the eNB sends RRCConnectionReconfiguration adding SRB2 for NAS transport and the default Data Radio Bearer with its drb-Identity, eps-BearerIdentity, PDCP/RLC and logicalChannelConfig. The same message carries the NAS Attach Accept inside dedicatedInfoNAS so the UE receives it in one shot. The UE applies the configuration and prepares to confirm.

LTE Radio Resource Control (RRC) protocol
    DL-DCCH-Message
        message: c1 (0)
            c1: rrcConnectionReconfiguration (3)
                rrcConnectionReconfiguration
                    rrc-TransactionIdentifier: 1
                    criticalExtensions: c1 (0)
                        rrcConnectionReconfiguration-r8
                            radioResourceConfigDedicated
                                srb-ToAddModList: srb-Identity 2
                                drb-ToAddModList: 1 item
                                    drb-Identity: 1
                                    eps-BearerIdentity: 5
                                    logicalChannelConfig: priority 13
                            dedicatedInfoNASList: Attach accept

The UE applies the new configuration and replies with RRCConnectionReconfigurationComplete on SRB1, confirming SRB2/DRB establishment and active AS security. The eNB then sends the S1AP Initial Context Setup Response to the MME, importantly providing the eNB's downlink S1-U GTP-TEID so the S-GW can later route downlink data. The default-bearer radio leg is now fully set up.

Stream Control Transmission Protocol
    Payload protocol identifier: S1AP (18)
S1 Application Protocol
    successfulOutcome
        procedureCode: id-InitialContextSetup (9)
        MME-UE-S1AP-ID: 40551
        eNB-UE-S1AP-ID: 1024
        E-RABSetupListCtxtSURes: 1 item
            E-RAB-ID: 5
            transportLayerAddress: 10.30.30.5
            gTP-TEID: 0x0C0A0201

The Attach Accept that reached the UE assigned a new GUTI, the TAI list, and the Activate Default EPS Bearer Context Request with the UE IP, APN and negotiated QoS. The UE stores the GUTI/TAI list and answers with the NAS Attach Complete, which carries the Activate Default EPS Bearer Context Accept, sent up as an UL Information Transfer / Uplink NAS Transport to the MME. One loose end remains on the core: the S-GW still does not know the eNB's downlink TEID. The MME closes this with a GTPv2-C Modify Bearer Request to the S-GW carrying the eNB S1-U TEID; the S-GW answers with Modify Bearer Response. The downlink tunnel is now stitched end-to-end.

S1 Application Protocol
    initiatingMessage
        procedureCode: id-uplinkNASTransport (13)
        MME-UE-S1AP-ID: 40551
        eNB-UE-S1AP-ID: 1024
        NAS-PDU: 0743...
Non-Access-Stratum (NAS) PDU
    EPS mobility management message
        Security header type: Integrity protected and ciphered (2)
        Message type: Attach complete (0x43)
        ESM message container
            Activate default EPS bearer context accept (EBI 5)

User Datagram Protocol, Src Port: 2123, Dst Port: 2123
GPRS Tunneling Protocol V2
    Flags: 0x48 (version 2)
    Message Type: Modify Bearer Request (34)
    Tunnel Endpoint Identifier: 0x0A00071E
    Bearer Context [Grouped IE]
        EPS Bearer ID (EBI): 5
        F-TEID: eNB S1-U, TEID 0x0C0A0201, IPv4 10.30.30.5
    [Response] Modify Bearer Response: cause Request accepted (16)

With the downlink tunnel stitched, uplink and downlink IP packets flow on the default EPS bearer. On the air interface they ride the DRB (mapped to logical channel, RLC-AM, PDCP with 12-bit SN); on S1-U they are encapsulated in GTP-U G-PDUs between the eNB and the S-GW, and on S5/S8 between the S-GW and the P-GW toward the internet. The example below shows an uplink G-PDU carrying the UE's first packet from IP 10.44.7.201 out through the S-GW S1-U TEID. The attach is complete and the UE is EMM-REGISTERED.

User Datagram Protocol, Src Port: 2152, Dst Port: 2152
GPRS Tunneling Protocol (GTP-U)
    Flags: 0x30 (version 1, PT=1)
    Message Type: G-PDU (0xff)
    Length: 96
    Tunnel Endpoint Identifier: 0x0A00071E
    Internet Protocol Version 4
        Source Address: 10.44.7.201
        Destination Address: 93.184.216.34
        Protocol: TCP (6)
            TCP: 49876 → 443 [SYN] Seq=0 Win=64240

Summary

The fastest way to root-cause an attach failure is to find the first phase that broke. A → B → C → D: if the UE never camps, it is cell search (band/EARFCN, PSS/SSS, MIB, SIB, PLMN/S-criteria). If it camps but never connects, it is random access and RRC (preamble, RAR window, Msg3 CRC, contention resolution). If RRC comes up but the UE is rejected, it is authentication and security (S6a vectors, RES vs XRES, AUTN, EEA/EIA). If everything authenticates but there is no data, it is session and bearer setup (Create Session, APN/IP, default DRB, and the Modify Bearer that stitches the downlink).

Used log-in-hand, each numbered step gives you an exact message on a named interface with the IEs to verify. The first field that does not line up — a wrong RA-RNTI, a RES mismatch, a missing eNB DL TEID — is almost always the root cause, and it tells you which node (UE, eNB, MME, HSS, or S-GW/P-GW) to look at next.