Fundamental Information

There are many important information affecting the detailed protocol behavior both on UE and Network. How a UE or Network make variations in the details of the protocol sequence is in most case up to their implementation.. not specified by 3GPP. So usually a huge set of tests are going on in modem manufacturer and UE manufacturer.

The Four Sources

Four kinds of information shape what a UE does, and they differ in where they come from. Two of them are settled before the UE is ever switched on. One arrives from the card. The last one has to be collected from the air every time the UE looks at a cell.

UE Capability : UE Category, Frequency Band, Sync Signal Sequence, General Radio Resource Info, General MIMO Parameter, Duplex Mode, Preamble sequence generation algorithm. There are roughly two types of UE capability we can think of. The term (Configured UE capability, Reported UE capability) is not 3GPP term.

Configured UE Capability : These informations are usually configured and stored in a specific memory location on UE. These are usually configured by modem manufacturer and UE manufacturer.
Report UE capability : These are the information reported by UE to Network via UE capability Enquiry/UE capability Information process. Depending on this information, Network would apply different procedure / configuration for each specific UE.

USIM : Network Operator's PLMN list, Subscription Information, Access Barring

Stored Information : Most recently used frequency band, PLMN, Tracking Area Code, Cell ID, S-TMSI, InterRAT Frequency Band

Information that UE needs to get: Frequency and Timing Synchronization info, System Bandwidth, Number of MIMO Antennas, Identities (C-RNTI, Physical Cell ID, Tracking Area Code), Network PLMN, Signaling & Traffic Radio Resouce, RACH_ROOT_SEQUENCE & PRACH Config.

The four sources differ in when they are fixed : two are built into the device, one comes with the subscription, and the last is read from the cell each time.
Only the last of the four changes when the UE moves : the capability and the card travel with the device, and the cell information does not.

UE Category and What the UE Actually Reports

The paragraph above splits capability into a configured half and a reported half, and it warns that neither term comes from 3GPP. The split itself is real even so. 36.306 defines the reported half, and one field on that list causes more confusion in a capability log than all the others together.

ue-Category was one number, and then it became three

36.306 clause 4.1 defines ue-Category as a combined uplink and downlink capability. One number therefore fixed both directions at once, and clause 4.2 lists the parameters it sets. The same clause carries a rule that catches people reading a capability message. A UE indicating category 6 or 7 has to indicate category 4 as well. A UE indicating category 11 has to indicate 9, 6 and 4.

A capability message listing four categories is therefore not describing four devices. It is one device declaring the fallbacks it also supports.

Clause 4.1A then splits the idea in two. The fields ue-CategoryDL and ue-CategoryUL define the downlink and the uplink capability separately. A device can therefore pair a high downlink category with a modest uplink one. A log carrying all three fields is not contradicting itself.

The configured half is the part 3GPP never sees

36.306 defines what a UE may report. It says nothing about how the modem searches, how long it dwells on a carrier, or which band it tries first. Those choices sit in the device and reach no message. Two handsets reporting an identical capability can therefore still behave differently, which is the gap the opening paragraph of this page names.

Field	What it fixes	Clause in 36.306
ue-Category	Uplink and downlink together, as one number	Clause 4.1
ue-CategoryDL	The downlink capability on its own	Clause 4.1A
ue-CategoryUL	The uplink capability on its own	Clause 4.1A
supportedBandCombination	Which bands may be aggregated, and in what combinations	Clause 4.3.5.2
accessStratumRelease	The release the access stratum claims to follow	Clause 4.3.8.1A

Several categories in one message describe one device : 36.306 clause 4.1 makes the higher categories carry their fallbacks with them.
A separate downlink and uplink category is not a contradiction : clause 4.1A defines ue-CategoryDL and ue-CategoryUL to be read on their own.

What the USIM Holds, File by File

The USIM line above names three things, and each one is a named file on the card with an identifier of its own. 31.102 defines them. Knowing the file name turns a vague reference into something a card reader can be pointed at directly.

The table below maps the three items to the files that hold them.

Item on the USIM line	File	31.102 clause	What it holds
Network Operator's PLMN list	EF_PLMNwAcT	Clause 4.2.5	The user controlled PLMN selector, with the access technology for each entry
Network Operator's PLMN list	EF_FPLMN	Clause 4.2.16	The forbidden PLMNs
Network Operator's PLMN list	EF_HPPLMN	Clause 4.2.6	How often to search for a higher priority PLMN
Subscription Information	EF_IMSI	Clause 4.2.2	The IMSI
Access Barring	EF_ACC	Clause 4.2.15	The assigned access control class or classes

The access barring file is smaller than its importance suggests. 31.102 clause 4.2.15 gives it two bytes, marks it mandatory, and describes fifteen classes. Ten of those are allocated at random to ordinary subscribers, and five are reserved for specific high priority users. 22.011 is where the classes are given their meaning.

The stored information is largely on the card as well

The Stored Information line and the USIM line above are less separate than they look. 31.102 clause 4.2.91 defines EF_EPSLOCI as eighteen bytes holding exactly three things. The GUTI takes the first twelve bytes. The last visited registered TAI takes the next five, and the EPS update status takes the last one.

Three of the items the Stored Information line names are inside that one file. 23.003 builds the GUTI from the GUMMEI and the M-TMSI. The GUMMEI comes in turn from the MCC, the MNC, an MME Group ID and an MME Code. The PLMN is therefore the first part of the GUTI. The S-TMSI is the MME Code and the M-TMSI, so it is the last part of the same field. The Tracking Area Code sits in the five bytes that follow.

The rest of that line does not live on the card. The most recently used frequency band, the cell identity and the inter-RAT band list stay in the modem's own storage. That puts them back in the configured half again. A card swapped into a different handset therefore carries the registration forward and leaves the frequency history behind.

One more file belongs beside these. EF_EPSNSC, at 31.102 clause 4.2.92, holds the EPS NAS security context. That context lets a UE returning after a power cycle protect its first NAS message rather than authenticate again.

A vague stored item usually has a file number : EF_EPSLOCI at clause 4.2.91 holds the GUTI, the last visited TAI and the EPS update status in eighteen bytes.
The card carries the registration and the modem carries the radio history : moving a USIM moves the GUTI and leaves the frequency and cell history behind.

Where Each Item the UE Needs Comes From

The last line above is the only one of the four that has to be collected fresh. Every item on it arrives from the cell, and each one arrives by a particular route. The table below names that route for each, because a missing item is best chased in the message that should have carried it.

Two of the rows are worth reading closely. Neither item is a field anywhere, and both are often looked for in the wrong place.

Item, as the line above names it	Where it arrives	Field or mechanism
Frequency and Timing Synchronization info	PSS and SSS	36.211 clause 6.11
System Bandwidth	MIB	dl-Bandwidth, one of n6 to n100
Number of MIMO Antennas	PBCH, without a field	The CRC mask, 36.212 Table 5.3.1.1-1
Physical Cell ID	PSS and SSS, without a field	The group from SSS and the identity within it from PSS
C-RNTI	Random Access Response	Temporary C-RNTI, 36.321 clause 5.1.4
Tracking Area Code	SIB1	trackingAreaCode in cellAccessRelatedInfo
Network PLMN	SIB1	plmn-IdentityList in cellAccessRelatedInfo
Signaling & Traffic Radio Resouce	SIB2, then RRCConnectionSetup	radioResourceConfigCommon, then radioResourceConfigDedicated
RACH_ROOT_SEQUENCE & PRACH Config	SIB2	rootSequenceIndex, 0 to 837, in PRACH-ConfigSIB

The antenna count is carried by a checksum

The number of eNodeB transmit antenna ports appears in no field of the MIB. 36.212 Table 5.3.1.1-1 gives PBCH a set of CRC masks, one for each antenna port count. The UE learns the count from whichever mask makes the CRC check pass. A UE that has decoded the MIB at all has therefore already learned the antenna count, without reading it anywhere.

The cell identity is carried by the sequences themselves

The Physical Cell ID is not a field either. 36.211 clause 6.11 defines 504 physical-layer cell identities, grouped into 168 groups of three. The group number comes from the secondary synchronization signal, and the identity within the group comes from the primary one. The UE holds the Physical Cell ID before it has decoded a single message.

The C-RNTI is the one item on the line that no broadcast carries. It reaches the UE as a Temporary C-RNTI inside the Random Access Response, which 36.321 clause 5.1.4 covers. Contention resolution in clause 5.1.5 then decides whether the UE keeps it. Until that point the identity is not yet the UE's own.

Two items on the list are carried without a field : the antenna count rides on the PBCH CRC mask, and the Physical Cell ID rides on the synchronization sequences.
Everything else has a message and a field name : the bandwidth is in the MIB, the identities are in SIB1, and the RACH configuration is in SIB2.
One item is not broadcast at all : the C-RNTI starts as a Temporary C-RNTI in the Random Access Response and becomes the UE's own at contention resolution.

Reference

Six specifications define the fields and files named above. Each entry says which clauses were read.

36.306 - Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) radio access capabilities, v19.3.0. Clause 4.1 defines ue-Category and the rule that a higher category also indicates its fallbacks. Clause 4.1A defines ue-CategoryDL and ue-CategoryUL. The clause 4.3 field names were taken from the table of contents.
31.102 - Characteristics of the Universal Subscriber Identity Module (USIM) application, v19.5.0. Clause 4.2.2 is EF IMSI, clause 4.2.5 is EF PLMNwAcT and clause 4.2.6 is EF HPPLMN. Clause 4.2.15 is EF ACC, clause 4.2.16 is EF FPLMN, clause 4.2.91 is EF EPSLOCI and clause 4.2.92 is EF EPSNSC. The bodies of clause 4.2.15 and clause 4.2.91 were read in full and the rest by their clause headings.
23.003 - Numbering, addressing and identification, v20.0.0. It builds the GUTI from the GUMMEI and the M-TMSI. The GUMMEI comes from the MCC, the MNC, an MME Group ID and an MME Code, and the S-TMSI from the MME Code and the M-TMSI.
36.331 - Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification, v19.3.0. The ASN.1 in clause 6 carries MasterInformationBlock with dl-Bandwidth, the cellAccessRelatedInfo of SystemInformationBlockType1, and PRACH-ConfigSIB with rootSequenceIndex.
36.321 - Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification, v19.3.0. Clause 5.1.4 is Random Access Response reception, where the Temporary C-RNTI is taken, and clause 5.1.5 is contention resolution.
36.211 - Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels and modulation. Clause 6.11 carries the 504 physical-layer cell identities and their grouping. Only that clause was read.
36.212 - Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing and channel coding, v19.3.0. Table 5.3.1.1-1 is the CRC mask for PBCH, which is how the antenna port count reaches the UE. The table title was confirmed and the clause body was not read.