Anyone who worked on WCDMA before LTE arrives with a working model of how a call sets up, and most of that model still fits. The parts that do not fit are few. They are worth naming one at a time, because each one changes what a log looks like.

• Overall Comparision with WCDMA
• Where the Random Access Moved
• Why NAS Rides on RRC in LTE
• How Many System Information Blocks Each One Has
• Two RRC States Instead of Four
• Reference

Overall Comparision with WCDMA

Even though overall sequence is pretty similar to WCDMA sequence, there are a couple of different points comparing to WCDMA sequence. The differences below are not all of the same kind. Two of them move a procedure from one layer to another. The rest change how much a single message carries. Both kinds show up in a log, and the first kind also changes which layer reports a failure.

First point you have to look at is that in LTE 'RACH Preamble' is sent as a part of MAC Layer process. As you know RACH process was there in WCDMA, but in WCDMA it was a part of Physical layer process.

Another part I notice is that RRC Connection Setup Complete and Attach Request is carried in a single step. This is only one example. In LTE, many of NAS Message is piggybacked on RRC Messages. This would make message decoding/encoding process complicated but it would be efficient to reduce the number of message exchange between UE and eNodeB.

These are the differences you can notice just by looking at the message type, there are more differences you will find when you go into the information elements of each messages as you will see in following sections.

Next thing you will notice would be that there are much less SIBs being transmitted in LTE comparting to WCDMA. Of course there are more SIBs not being transmitted in this sequence (LTE has 10 SIBs in total), but with only these two SIBs it can transmit all the information to let UE camp on the network. In WCDMA there are a total 18 SIBs and in most case we used at least SIB1,3,5,7,11 even in very basic configurations. And some of the WCDMA SIBs like SIB5 and 11 has multipe segments. In LTE, number of SIB is small and none of them are segmented.

• Three of the differences are visible in the message list alone : where the random access runs, how much a single message carries, and how many SIBs the cell broadcasts.
• Two of those three move work between layers : the random access changes owner, and the NAS message changes carrier.

Where the Random Access Moved

The note above puts the RACH preamble in MAC for LTE and in the physical layer for WCDMA. That is worth pinning down, because both specifications draw the line somewhere you can point at. One question settles it. Which layer holds the retransmission counter and the power ramp?

WCDMA runs the loop in Layer 1

25.214 clause 6.1 is a physical layer clause. It opens by saying that the procedure starts on request from the MAC sublayer. Layer 1 then collects a list of parameters from RRC. That list holds the preamble scrambling code, the available signatures, the Power Ramp Step, the Preamble Retrans Max and the initial preamble power.

Layer 1 runs the loop from there. It selects the access slot, selects the signature, sets the Preamble Retransmission Counter and raises the power on each attempt. MAC hands down three things only: the Transport Format, the ASC and the Transport Block Set. MAC asks for a preamble and learns the outcome.

LTE runs the loop in MAC

36.321 clause 5.1 is a MAC clause, and the whole random access procedure sits inside it. Clause 5.1.3 sets PREAMBLE_RECEIVED_TARGET_POWER from preambleInitialReceivedTargetPower, DELTA_PREAMBLE and PREAMBLE_TRANSMISSION_COUNTER multiplied by powerRampingStep. The counter is a MAC variable, and so is the power.

Clause 5.1.1 names three things that can start the procedure. A PDCCH order can, the MAC sublayer itself can, and RRC can. The physical layer is not among them.

Why the move matters in a log

A preamble that never gets an answer looks different on the two systems. In WCDMA the counter runs inside Layer 1, so MAC sees a failure rather than a count. In LTE the counter is in MAC, and MAC is also what reports a random access problem to RRC. The same radio failure therefore surfaces at a different layer, and a different trace is the one that shows it.

• The counter is the thing that moved : WCDMA keeps it in Layer 1 and LTE keeps it in MAC, and everything else follows from that.
• A failed preamble is reported by a different layer on each system : in LTE the random access problem reaches RRC from MAC.

Why NAS Rides on RRC in LTE

The note above calls the piggybacking one example, and 36.331 is stronger than that. For the first NAS message the piggyback is not something the network may choose. It is the only way that message can travel.

WCDMA sends the NAS message separately

25.331 gives the initial NAS message a message of its own. Clause 8.1.8 is the Initial Direct transfer procedure, and INITIAL DIRECT TRANSFER carries the first NAS message up. RRC CONNECTION SETUP COMPLETE goes first and carries no NAS at all. Two messages therefore leave the UE where LTE sends one.

LTE has nowhere else to put it

36.331 defines RRCConnectionSetupComplete with a dedicatedInfoNAS field, and that field carries no OPTIONAL marker. A UE completing an RRC connection has to put a NAS message in the same message. That is why the Attach Request and the RRC Connection Setup Complete arrive together rather than one behind the other.

The other carriers are more relaxed. DLInformationTransfer and ULInformationTransfer each hold a dedicatedInfoType CHOICE, and dedicatedInfoNAS is one of its three alternatives. CDMA2000 1xRTT and HRPD are the other two. RRCConnectionReconfiguration goes further still and carries dedicatedInfoNASList, which is a SEQUENCE OF DedicatedInfoNAS. One reconfiguration can therefore carry several NAS messages at once.

What the trade costs

The note above names both sides of the trade, and the specification bears them out. Decoding gets harder, because one RRC message now holds an octet string that a different decoder has to open. The exchange gets shorter, because the attach no longer needs an uplink message of its own. The count is easy to check. LTE reaches the Attach Request in one message where WCDMA needs two.

• In LTE the first NAS message has no separate carrier : dedicatedInfoNAS in RRCConnectionSetupComplete is mandatory, so the attach cannot travel on its own.
• The saving is one uplink message and the cost is a nested decode : the RRC decoder hands an octet string to a NAS decoder rather than finishing the message itself.

How Many System Information Blocks Each One Has

The note above puts LTE at 10 SIBs and WCDMA at 18. Both numbers were fair when the note was written, and both have grown since. The comparison the note draws still holds, and it holds for a reason worth stating separately from the counts.

What 36.331 defines today

36.331 v19.3.0 runs SIB1 through SIB21, then SIB24 through SIB33, with SIB26a alongside SIB26. SIB22 and SIB23 are missing from that run because those two numbers belong to NB-IoT alone. The E-UTRA total is 32 types rather than 10, and NB-IoT adds 18 more under its own names.

What 25.331 defines today

25.331 v19.0.1 runs SIB1 to SIB7 and then SIB11 to SIB25. SIB8, SIB9 and SIB10 are not there at all. It also carries variants that LTE has no equivalent for, and those are SIB5bis, SIB11bis, SIB11ter and SIB15bis. The numbered total is 22, and the variants push the real count past that.

So both counts moved, and the gap between them narrowed rather than widened. What did not move is the point the note was making with them, and the next heading is where that point actually lives.

The difference that survived both counts

Segmentation is the part that has not changed. 25.331 breaks a system information block into a First Segment and the segments that follow it, which is why SIB5 and SIB11 arrive in pieces. 36.331 has no equivalent for a SIB on BCCH. An LTE SIB is delivered whole or not at all.

LTE does segment one thing on the broadcast channel, and it is worth knowing so that it is not mistaken for the WCDMA mechanism. SIB11 and SIB12 carry the segments of an ETWS or a CMAS warning message. The notification is what gets segmented there, and the SIB carrying it is not.

• The counts in the note above were right when written and have both grown since : E-UTRA is at 32 types and WCDMA at 22 numbered ones.
• Segmentation is the difference that outlasted the counts : a WCDMA SIB can arrive in pieces and an LTE SIB cannot.

Two RRC States Instead of Four

One difference never shows up in the message list, and it shapes what the other three touch. WCDMA connected mode has four states. LTE connected mode has one. The reason for that is not a simplification of RRC, and it sits a layer lower down.

What WCDMA separates

25.331 clause 7.2 covers the processes that run in each UE mode and state. Its sub-clauses name URA_PCH and CELL_PCH together, then CELL_FACH, then CELL_DCH. What tells the four apart is what the UE holds. CELL_DCH means a dedicated channel. CELL_FACH means the common channel. The two PCH states mean neither of those, with the UE still reachable by paging.

Why LTE needs only two

36.331 clause 4.2.1 gives the UE RRC_IDLE and RRC_CONNECTED, and it adds RRC_INACTIVE only when the UE is connected to 5GC. The states that are missing are missing because the thing they separated is missing. LTE has no dedicated transport channel. Every unicast transfer runs on DL-SCH or UL-SCH, so CELL_DCH and CELL_FACH have nothing left to tell apart.

DRX covers what remains. A UE that would have waited in CELL_PCH waits in RRC_CONNECTED with a DRX cycle configured, or it moves to RRC_IDLE. The state count fell because the channel structure under it was simplified, and the Channel Mapping page shows the structure that replaced it. The State Machine page follows a UE through the two states that were left.

• The state count fell because the channel structure under it was simplified : CELL_DCH and CELL_FACH were named for channels that LTE does not have.
• DRX took over the job of the two PCH states : a connected UE with a DRX cycle is reachable without holding the radio awake.

Reference

Four specifications carry the claims compared above, two from each system. The clause numbers sit beside each claim so the wording can be checked rather than taken on trust.

• 36.321 - Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification, v19.3.0. Clause 5.1 is the random access procedure. Clause 5.1.1 lists what may start it and clause 5.1.3 holds the preamble power and the transmission counter.
• 36.331 - Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification, v19.3.0. Clause 4.2.1 defines RRC_IDLE and RRC_CONNECTED. The ASN.1 in clause 6 carries RRCConnectionSetupComplete with its mandatory dedicatedInfoNAS, the dedicatedInfoType CHOICE in DLInformationTransfer and ULInformationTransfer, and the SIB definitions counted above.
• 25.214 - Universal Terrestrial Radio Access (UTRA); Physical layer procedures (FDD), v19.0.0. Clause 6.1 is the physical random access procedure, and it lists what Layer 1 receives from RRC and from MAC before it runs the preamble loop. Only clause 6 was read for this note.
• 25.331 - Radio Resource Control (RRC); Protocol specification, v19.0.1. Clause 7.2 covers the processes in each UE mode and state, and names CELL_DCH, CELL_FACH, CELL_PCH and URA_PCH. Clause 8.1.8 is the Initial Direct transfer procedure. Clause 10.2.48 carries the segmented system information structure. This specification ships as a legacy binary document, so it was read by text extraction and only in the clauses named here.