This page takes one LTE attach apart step by step and lists 161 of them, from the first MIB the UE reads to the moment it returns to idle. It is the companion to Basic Call Processing, which shows the same call as decoded messages. Here the interest is the order of events rather than the contents of any one message.

The view is the network's, and that shapes everything in the table. Every row is something an eNB or a test system would log, so the table holds three kinds of entry rather than one. Some rows cross the air interface. Many more are primitives handed between layers inside a single node. A few are state changes that nothing transmits at all. The sections after the table sort those apart, and name the block that repeats around every message.

Followings are the topics :

• Typical Packet Call (Details)
• What do the Direction values mean ?
• What is the pattern that keeps repeating ?
• What do the internal primitives mean ?
• Reference

Typical Packet Call (Details)

Now the next step is to describe each of the steps in as much detail as possible. The more in detail you can describe, the easier the development, testing, troubleshooting will be. There are many steps I couldn't describe here because the most of steps not described here would be related to company confidentials (Of course, you can say "Every details are in 3GPP specification".Yes, that's true, but 3GPP says only about "What to do", it doesn't say much about "How to do". In real implementation, this "How to do" part is as important as "What to do") You can take this as a minimum of possible-detailed description. Going through this table, think about how much additional comments you think you can put in 'Memo' column. (If you want to see what's really happening in real network, see the live air example in Full Stack page and Call Processing in Detail with Amarisoft page)

NOTE : Following sequence is based on the sequence that would be seen in eNB. Of course, you should see the same sequence on UE side except that UE should have its counter part sequence to < NW >. Some people may think I am writing this table just to confuse people :), but this table is what I have been most often for protocol troubleshooting.

What do the Direction values mean ?

The Direction column takes four different values, and only two of them describe something that is actually transmitted. Reading every row as an air interface message is the quickest way to misread the table, so it is worth fixing the four in mind before working down the rows.

The counts are the surprise. Of the 161 steps, 51 are downlink and 31 are uplink. The other 79 never reach the air at all. Nearly half the table is the network talking to itself, and that is deliberate. Those rows are there because an eNB log prints them, and because a missing one tells you which layer the chain stopped at.

SS is the system simulator, and it is the network side throughout this table. Two rows work the other way. Steps 15 and 20 describe what the UE's own MAC is doing, because a test system can see both ends, and those are the only two places the table uses that.

The memo on step 15 is worth checking against the specification, because it is the one row that names a parameter. It reads that the contention resolution timer is set in SIB2, and that is right. 36.331 puts mac-ContentionResolutionTimer inside RACH-ConfigCommon, under ra-SupervisionInfo, with values from sf8 to sf64, and SIB2 is what carries RACH-ConfigCommon to the UE.

• Only 82 of the 161 rows reach the air : 51 downlink and 31 uplink, with everything else internal to one node or the other.
• Angle brackets mean nothing was transmitted : < NW > is a primitive inside the network and < UE > is a state change inside the UE.
• A missing internal row is a diagnosis : the chain stops at the layer that never logged its primitive.

What is the pattern that keeps repeating ?

Most of this table is one block repeated. Once you can see the block, 161 rows collapse into a handful of RRC and NAS messages with the same machinery around each of them. The steps below are the NAS Security Mode Command exchange, taken from the table exactly as it stands.

Two things about the order look wrong at first, and both are worth understanding rather than correcting.

The message is listed before the DCI that schedules it, and before the primitives that carry it down the stack. The row order follows the network's own sequence. The decision to send comes first, then the handover down the layers, then the transmission. A sniffer watching the air sees the DCI first instead, because nothing on PDSCH can be decoded without it.

The second is the cost of every uplink message. The UE has no standing grant, so it cannot simply transmit. It asks with a Scheduling Request and waits for a DCI 0 carrying the grant. That pair appears eleven and twelve times in the table, which makes it the most repeated thing in the whole sequence. An RLC acknowledgement pays the same price as a full RRC message, because it is a transmission like any other.

• A few real messages carry the whole table : the rest is the same block of scheduling, acknowledgement and inter-layer handover repeated around each one.
• The row order is the network's, not the air's : the message is listed before the DCI that schedules it, because that is the order the eNB does things in.
• Every uplink message costs a request and a grant : the UE has no standing allocation, so a Scheduling Request and a DCI 0 come before each one.
• An RLC ACK is a transmission in its own right : it needs its own grant, its own transmission and its own HARQ acknowledgement.

What do the internal primitives mean ?

Seventy-four rows carry a name such as MAC_DATA_REQ or PHY_DATA_IND, and not one of them is a 3GPP message. They are the primitives that one layer passes to the next inside a single node, printed because the log prints them. The naming is regular enough to read at a glance once the two suffixes are clear.

REQ is a request travelling downward. A layer is handing something to the layer beneath it and asking for it to be sent. IND is an indication travelling upward. A layer has received something and is telling the layer above.

The order of the names therefore gives you the direction without reading the Direction column at all. A downlink message shows PDCP_DATA_REQ, RLC_DATA_REQ, MAC_DATA_REQ and PHY_DATA_REQ in that order, from the top of the stack to the bottom. An uplink message shows PHY_DATA_IND, MAC_DATA_IND, RLC_DATA_IND and PDCP_DATA_IND, from the bottom back up. Steps 74 to 77 and steps 88 to 91 are those two halves side by side.

One caution goes with these names. They are the primitives this particular log prints, not terms a 3GPP specification defines, and another vendor's eNB will show the same events under different labels. What carries across is the shape rather than the spelling: a request chain going down for anything transmitted, and an indication chain coming up for anything received.

• REQ goes down and IND comes up : a request asks the layer below to send, and an indication tells the layer above that something arrived.
• The order of the names gives the direction : PDCP first means downlink, and PHY first means uplink.
• None of these rows reaches the air : they are internal to one node, and they appear because a log prints them.
• The names are the vendor's, not 3GPP's : another eNB logs the same events differently, but the request-down and indicate-up shape is the same.

Reference

Only one row of the table names a specification parameter, and both entries below were read for that row and for the contention resolution step it belongs to.

• 36.331 - Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC) protocol specification. RACH-ConfigCommon carries ra-SupervisionInfo, which holds mac-ContentionResolutionTimer with values sf8 to sf64, and SIB2 carries RACH-ConfigCommon to the UE.
• 36.321 - Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification. Clause 5.1.5 is contention resolution, which the memo on step 15 cites.