4G/LTE - Basic Procedures

 

 

 

Frequency and Bandwidth Detection

 

LTE support various different options of channel bandwidth, which are 1.4, 3, 5, 10, 15, 20 Mhz. How can a UE figure out which bandwidth to use when it try to attach to the network ? This is the procedure in which UE figures out the bandwidth.

The Detection Steps

The six steps below run in order, and each one narrows what the UE still has to guess. The bandwidth is the last thing to arrive, and the listing at the end of the section is where it arrives. The two sections after this one say why it cannot come any sooner.

    i)Search the center frequency

      Note 1: This algorithm would be the most complicated and is up to each chipset manufacturer for implementation

      Note 2: Depending on UE PHY protocol stack implementation, UE may measure RSSI and determine whether it goes to next step or not.

    ii) Decode PSS (Primary Sync Signal)

    iii) Decode SSS (Secondary Sync Signal)

      Note 1 : If UE combined the result of PSS, SSS, UE can figure out Cell ID. (So if you see Cell ID in UE trace log and it matches the one eNodeB is configured, it means UE successfully detected PSS, SSS

    iv) with the result of step ii) and iii), UE can detect cell specific Reference Signal

    v) Decode BCH which occupies 72 subcarriers (6 RBs) at the center frequency.

    vi)BCH (MIB) tells the frequency information of the system (eg. System Frequency Bandwidth)

     

Following is based on 36.331 v19.3.0 (Release 19)

MasterInformationBlock ::= SEQUENCE {
    dl-Bandwidth                  ENUMERATED {n6, n15, n25, n50, n75, n100},
    phich-Config                  PHICH-Config,
    systemFrameNumber             BIT STRING (SIZE (8)),
    schedulingInfoSIB1-BR-r13     INTEGER (0..31),
    systemInfoUnchanged-BR-r15    BOOLEAN,
    partEARFCN-r17                CHOICE {
        spare                         BIT STRING (SIZE (2)),
        earfcn-LSB                    BIT STRING (SIZE (2))
    },
    spare                         BIT STRING (SIZE (1))
}

The listing above is the current definition rather than the one this note was first written against. Release 8 ended the structure with ten spare bits, and every release since has spent some of them. The section below follows where they went.

Why the Bandwidth Cannot Be Read Any Earlier

The step list has a circular look to it. The UE needs the bandwidth before it can build a full resource grid. The bandwidth itself arrives in a message that has to be decoded off that grid. The specification breaks the circle with one decision, and the decision is a number.

That number is six. 36.101 Table 5.6-1 sets the transmission bandwidth configuration for each channel bandwidth, and the narrowest LTE carrier is six resource blocks wide.

Channel bandwidth

Transmission bandwidth configuration NRB

dl-Bandwidth value

1.4 MHz

6

n6

3 MHz

15

n15

5 MHz

25

n25

10 MHz

50

n50

15 MHz

75

n75

20 MHz

100

n100

Six resource blocks is therefore the one amount of spectrum every LTE carrier has, whatever its width. Put the synchronization signals and the broadcast channel inside those six, and a UE can find them without knowing anything about the carrier. Step v above says exactly that, with the 72 subcarriers it names being those six resource blocks.

The circle breaks there. Steps ii to v need only the centre of the carrier, so they run before the bandwidth is known. Step vi then reads the bandwidth out of what they decoded, and everything wider than the centre becomes reachable afterwards.

The MIB never names a bandwidth in MHz

One detail of the table above is worth carrying away. 36.331 describes dl-Bandwidth as the transmission bandwidth configuration in downlink, and it points at 36.101 Table 5.6-1 for the meaning. The values are n6 through n100, and each one counts resource blocks.

So a UE reading the MIB learns that the carrier is 50 resource blocks wide. Calling that 10 MHz is a translation the reader performs, and the table above is where the translation comes from. A log that reports n50 and a log that reports 10 MHz are reporting the same field.

  • Six resource blocks is the amount of spectrum every LTE carrier shares : putting the sync signals and the broadcast channel there lets a UE find them before it knows the width.
  • dl-Bandwidth counts resource blocks and not megahertz : 36.101 Table 5.6-1 is the mapping between the two.

What the MIB Carries Besides the Bandwidth

The bandwidth is what this page is about, and it is one field of five in the listing above. The others are worth a paragraph each. Two of them answer questions the step list raises, and the rest record how the message has changed.

The frame number is short by two bits, on purpose

systemFrameNumber is eight bits wide while the SFN runs to ten, and 36.331 says where the other two come from. The P-BCH has a 40 ms transmission interval, which covers four radio frames. The position inside that interval supplies the two least significant bits. The first radio frame is 00, the second is 01, the third is 10 and the last is 11.

A UE therefore learns the frame number by decoding the MIB and by noticing which of the four copies it decoded. Neither half is enough on its own, and that is why the field can be two bits shorter than the quantity it carries.

phich-Config is read even by UEs that ignore it

phich-Config specifies the PHICH configuration, and 36.331 adds a condition worth knowing. A BL UE or a UE in coverage enhancement shall ignore the field. The bits are still transmitted and still decoded, because the MIB is one fixed structure for every UE. Only the acting on them is skipped.

Ten spare bits, spent one release at a time

Release 8 closed the MIB with a ten bit spare field, and the listing this note was first written against shows it. Three later releases have each taken bits from it, and the arithmetic is exact. One spare bit is left.

The table below accounts for all ten.

Field

Added in

Bits

What it carries

schedulingInfoSIB1-BR-r13

Release 13

5

The index into the SystemInformationBlockType1-BR scheduling tables, with 0 meaning not scheduled

systemInfoUnchanged-BR-r15

Release 15

1

TRUE when SIB1-BR and the SI messages have not changed over the SI validity time

partEARFCN-r17

Release 17

3

A choice of spare or the two least significant EARFCN bits, for NTN bands on a 100 kHz raster

spare

What is left

1

Still spare

The choice in the third row costs three bits rather than two. One bit selects which alternative is present, and the alternative itself is two bits wide. That is the ordinary cost of a two way CHOICE, and it is why the four rows add to ten rather than nine.

The direction of travel is worth noting for its own sake. A message decodable by a UE that knows nothing about the cell cannot be extended freely. Its spare bits are the only room it has. Seventeen releases have left one bit of that room.

  • The MIB has almost no room left : ten spare bits in Release 8 have become one, and the three fields that took them are all in the listing above.
  • A two way CHOICE costs three bits, not two : the selector is a bit of its own, which is what makes the arithmetic close exactly.

Reference

Two specifications carry the claims above. The clause and table numbers sit beside each one so the wording can be checked rather than taken on trust.

  • 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 the MasterInformationBlock reproduced above. The MasterInformationBlock field descriptions give dl-Bandwidth, systemFrameNumber with its two implicit bits, phich-Config, schedulingInfoSIB1-BR and systemInfoUnchanged-BR the meanings quoted here.
  • 36.101 - Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) radio transmission and reception. Table 5.6-1 is the transmission bandwidth configuration for each E-UTRA channel bandwidth, reproduced above. Clause 5.6 and that table were read; the rest of the specification was not.