4G/LTE - Basic Procedures

 

 

 

Downlink Subframe Decoding

 

This procedure will explain the overall procedure to decode user data (PDSCH). It assumes that Initialization, Synchronization, IB decoding, Registration is already done and UE is in connected mode. This process happens on UE's PHY Decoding process.

The Decoding Steps

The steps below run once per subframe, and they run in this order because each one needs a number the step before it produced. The sections after the list cover the two places where that dependency is easy to miss. Both of them sit in the control region at the front of the subframe.

    i) Process the first OFDM symbol of the first slot within a subframe.

    ii) Detect PCFICH channel and figure out how many symbols are used for PDCCH.

    iii) Decode PHICH channel (PHICH is also at the first symbol of the first slot). This gives you ACK/NACK for PUSCH

    iv) Based on the result of step i),ii), UE will calculate CCE index for PDCCH (Refere to PDCCH Decoding for detail)

    v) Decode PDCCH and find DCI (DCI1 or DCI1A) which is destined to the UE.

    vi) From the DCI, figure out the physical resource information (e.g, location, modulation scheme etc) for PDSCH which is allocated for the UE.

    vii) Decode PDSCH

Steps i to v run in every subframe the UE monitors, whether or not anything has been scheduled for it. Only steps vi and vii depend on a DCI having been found at all.

A subframe carrying no assignment for this UE therefore costs the same control region work as one carrying a large grant. Any saving has to come from monitoring fewer subframes rather than from doing less inside each one.

Where Each Step Is Defined

The list above names seven steps and cites nothing. Each one is looking for something a specification defines exactly. Knowing which clause that is turns a step into somewhere to look when it fails.

The physical layer clauses come from 36.211, which says where each channel sits. The coding clauses come from 36.212, which says how its bits are protected. The procedure clauses come from 36.213, which says what the UE does with them.

Step

What it is looking for

Specification and clause

i) First OFDM symbol

The control region of the subframe

36.211 clause 6.7, which places PCFICH in it

ii) Detect PCFICH

How many symbols the PDCCH uses

36.211 clause 6.7 and Table 6.7-1; the coding is 36.212 clause 5.3.4

iii) Decode PHICH

The ACK or NACK for an earlier PUSCH

36.211 clause 6.9, with the duration set by Table 6.9.3-1

iv) Calculate CCE index

Which resource element groups are left for PDCCH

36.211 clause 6.8.1

v) Decode PDCCH and find the DCI

A candidate whose CRC checks against its RNTI

36.213 clause 9.1.1 for the search, 36.212 clause 5.3.3.2 for the CRC

vi) Read the PDSCH allocation from the DCI

Resource blocks and modulation

36.212 clause 5.3.3.1 for the formats, 36.213 clause 7.1.6 for the allocation

vii) Decode PDSCH

The user data itself

36.211 clause 6.4

Two rows of that table are worth reading against each other. Step ii finds a number and step iv uses it, and nothing between them is optional. The control region is measured before it can be searched, and the sections below take each of those two steps in turn.

  • Three specifications divide the work : 36.211 says where a channel sits, 36.212 says how its bits are coded, and 36.213 says what the UE does.
  • Every step is looking for something defined exactly : a step that fails has a clause behind it, which is where the fault is visible.

Why the Control Region Has to Be Measured First

Steps i to iv look like four steps and are really one question asked in stages. The question is which resource elements the PDCCH occupies, and the UE cannot answer it by looking. Nothing in the subframe is labelled, so the boundary has to be computed from two numbers that arrive separately.

PCFICH gives the size of the region

36.211 clause 6.7 says the physical control format indicator channel carries information about the number of OFDM symbols used for transmission of PDCCHs in a subframe. Table 6.7-1 then gives the set of values that is possible, and the set depends on the downlink bandwidth and on the kind of subframe.

The important property of PCFICH is where it sits. It occupies a fixed position in the first OFDM symbol, and that position does not depend on the answer it carries. A UE can therefore find PCFICH before it knows how large the control region is, which is what makes the whole sequence possible.

PHICH takes resource elements out of it

The size alone is not enough, and step iii is the reason. 36.211 clause 6.8.1 defines a control channel element as nine resource element groups. The CCEs are counted from the groups that are not assigned to PCFICH or PHICH. Every group that PHICH occupies is therefore one the PDCCH cannot use.

So the CCE numbering in step iv depends on the PHICH layout in step iii, and not only on the symbol count in step ii. That is why the list above puts the PHICH step before the CCE step. The ACK or NACK it carries has nothing to do with the downlink assignment the UE is about to find.

One detail of step iii deserves a caution. The list says PHICH is also at the first symbol of the first slot, and that holds for the normal PHICH duration. 36.211 clause 6.9.3 makes the duration configurable by higher layers, and the extended duration reaches beyond the first symbol. A UE reading a cell configured that way finds PHICH spread across more of the control region than the list suggests.

  • The control region is measured before it is searched : PCFICH sits at a fixed place that does not depend on the size it reports.
  • PHICH changes the CCE numbering and not just the ACK : 36.211 clause 6.8.1 counts CCEs from the groups left after PCFICH and PHICH are placed.
  • The first symbol is the normal PHICH duration and not the only one : Table 6.9.3-1 makes it configurable, and the extended duration spans more symbols.

What Monitoring the PDCCH Actually Means

Step v says the UE decodes the PDCCH and finds the DCI destined for it. That sentence hides the part of the subframe that costs a receiver the most work. The UE is not told where its own PDCCH is, how many CCEs it uses, or which DCI format it carries.

36.213 clause 9.1.1 defines the word the specification uses for this. The UE monitors a set of PDCCH candidates. Monitoring there means attempting to decode every candidate in the set against every monitored DCI format. The work is trial decoding rather than a search for a marker.

Search spaces bound the number of attempts

Trying every possibility would be unaffordable, so the same clause narrows the field. The candidates to monitor are defined in terms of search spaces. A search space at a given aggregation level is itself a set of candidates.

The clause separates two kinds. There is a common search space and there is a UE specific search space, and the second is derived per UE. A UE therefore decodes a bounded list of candidates rather than the whole control region, which is what makes the step fit inside a subframe.

The CRC is what says a candidate was yours

Nothing in a PDCCH candidate carries a UE identity as a field. 36.212 clause 5.3.3.2 scrambles the CRC parity bits with the corresponding RNTI. A candidate decoded with the wrong RNTI fails its CRC check, and one decoded with the right RNTI passes.

That is the whole addressing mechanism. A UE knows a DCI belongs to it because the checksum only closes under its own RNTI. The same mechanism lets one control region carry assignments for many UEs without naming any of them.

The consequence for step v is worth stating plainly. A missed downlink assignment leaves no error and no message. The UE simply finds no candidate whose CRC checks, and the subframe passes as though nothing had been scheduled.

  • Monitoring means trial decoding : 36.213 clause 9.1.1 defines it as attempting to decode every candidate against every monitored DCI format.
  • Search spaces exist to bound the cost : the UE decodes a defined list of candidates rather than the whole control region.
  • The RNTI is in the checksum rather than in a field : 36.212 clause 5.3.3.2 scrambles the CRC with it, so a missed assignment is silent.

Reference

Three specifications carry the clauses cited above. Each entry says how far it was read, because several of the clauses are tables that a text extraction does not preserve.

  • 36.211 - Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels and modulation. Clause 6.4 is PDSCH and clause 6.7 is PCFICH with Table 6.7-1. Clause 6.8.1 is the PDCCH format and the CCE definition, and clause 6.9 is PHICH with its duration in Table 6.9.3-1. The opening text of each clause was read; the tables themselves are figures that the extraction did not preserve, so no value is quoted from them.
  • 36.212 - Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing and channel coding, v19.3.0. Clause 5.3.3.1 lists the DCI formats and clause 5.3.4 is the control format indicator. Clause 5.3.3.2 is the CRC attachment that scrambles the parity bits with the RNTI. Clause 5.3.3.2 was read; the others were confirmed from the table of contents.
  • 36.213 - Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures, v19.4.0. Clause 9.1.1 is the PDCCH assignment procedure, which defines monitoring and the search spaces quoted above. Clause 7.1.6 is the PDSCH resource allocation and clause 9.1.3 is the CFI assignment procedure. Clause 9.1.1 was read; the resource allocation clauses were confirmed from the table of contents.