This note will talk about channel mapping mainly between logical channel and physical channels in LTE, and how those mappings are applied at each stages of signaling in call processing.

• Big Picture First
• What Logical, Transport and Physical Channels Each Mean
• Which Channel Can Map to Which
• Channel Mapping Table throughout Call Processing
• Cell Configuration and Channel Configuration during Call Processing
• Channels the Attach Sequence Never Uses
• Reference

Big Picture First

Depending on which level you are working on in UE development/Test procedure, the amount of knowledge you need to know would be different. But I think there are a couple of big pictures that may help almost anybody working in full protocol stack.

First big picture I would like to introduce is the channel mapping as shown below. Just try to pick any RRC messages and try to follow the arrow for the message. If you read those pages about MAC and RLC, it will remind you of a lot of detailed information.

Overall Sequence and Layer Mapping

Following is a sequence diagram showing not only the message but also basic configurations of each layer. More detailed description of each layer in the context of full protocol stack will be explained in "Full Stack" section.

Just read through this sequence whenever you have time until you can duplicate the sequence without looking into this again. This can be a good framework for your study and good guide for troubleshooting.

Downlink Channel Map

The diagram you saw above a kind of message flow(event diagram) in time sequence. The diagram shown below is not a time based, but it shows the channel mapping (or data flow across the full protocol stack). Pick one of the message from the diagram shown above and try to find right route for this digram and see how much details you can add.

For example, if you picked the message "RRC Connection Setup", the start point would be "RRC Message msg4".

• The bracket on the right names the three bands. The top one is LoCH, the middle one is TrCH and the bottom one is PHY.
• The labels along the very top are payloads rather than channels. MIB, Paging, SIB, RA Resp, RRC Message msg4, RRC Message and U plane Data each name what is being sent.
• BCCH appears twice, as BCCH 0 and BCCH 1. BCCH 0 runs down to BCH and then to PBCH, which is the MIB path. BCCH 1 runs to DL SCH0 and then to PDSCH, which is the SIB path.
• The boxes labelled SCH-B CH, SCH-RAR, SCH-CCCH and SCH-DxCH sit between the two upper bands. They are scheduler instances inside the eNB, and 36.321 names no channel for them.
• DCCH 0, DCCH 1, DTCH 0 and DTCH 1 all point at one SCH-DxCH box, and a single DL SCH 1 leaves it. That convergence is the MAC multiplexing which the LCID column further down this page records.
• Every arrow ends at the PHY Hardware bar, and one arrow leaves the bar downward. The drawing is therefore the transmit side, which here is the eNB.

Following is a tabular presentation of DL Channel Map. (LCID and TrCH Number would be different depending on the network or Network Simulator)

Uplink Channel Map

The uplink map below carries the same three bands, drawn the other way up. Its arrows start at the PHY hardware bar and run upward to the logical channels at the top. That is the receive path, so the drawing is again the eNB view. Read it from the top downward instead and you have the UE transmit path for the same message.

• The labels along the top again name payloads. RA Preamble, RRC Message msg3, RRC Message Msg5 and onwards, and U plane Data are what the four columns carry.
• RA Pre sits in the logical channel band with RACH below it. 36.321 defines no logical channel for the preamble, so that box holds a place rather than naming a channel.
• CCCH 0 and CCCH 1 feed SCH-CCCH. That is the column msg3 arrives on, and msg3 here is the RRC Connection Request.
• DCCH 0, DCCH 1, DTCH 0 and DTCH 1 converge on SCH-DxCH, which mirrors the SCH-DxCH box in the downlink map above.
• The physical band is drawn as PDSCH 0, with PDSCH 1 greyed out and joined to nothing. 36.211 clause 5.1.1 names PUSCH for the uplink shared channel and PRACH for the preamble, so the box name here reads across from the downlink drawing.

Following is a tabular presentation of UL Channel Map. (LCID and TrCH Number would be different depending on the network or Network Simulator)

What Logical, Transport and Physical Channels Each Mean

The maps above stack three rows, and those rows are not three names for one thing. Each row is a different interface inside the stack. Each answers a different question about the same byte of data. Knowing which question a row answers is what lets you place an unfamiliar message on the map without memorising it.

36.321 draws the two upper boundaries in a single sentence. Transport channels are the service access points between MAC and Layer 1, and logical channels are the service access points between MAC and RLC. MAC therefore sits between the two upper rows. Every arrow that crosses a band in the maps above crosses a MAC boundary.

A logical channel is named for what the information is

36.321 Table 4.5.2-1 splits the logical channels into control channels and traffic channels, and that split is the whole of the definition. BCCH, PCCH, CCCH, DCCH and MCCH carry control. DTCH, MTCH and STCH carry user traffic. Nothing in the name says how the data reaches the air, and nothing says where it lands in the frame.

A transport channel is named for how the information is carried

The transport channel fixes the transport format, the error protection and whether HARQ applies. DL-SCH supports HARQ and dynamic scheduling. BCH carries a fixed format and does neither. That difference is why the MIB and a SIB travel on different transport channels although both arrive on BCCH. It is also the reason the map above splits BCCH into two boxes.

A physical channel is named for where the information sits

36.211 clause 6.1.1 puts it plainly. A downlink physical channel is a set of resource elements carrying information that came from higher layers. The channel is a region of time and frequency rather than a queue of data. The mapping rules in 36.211 then say which resource elements that region holds.

The table below lines the three up against each other.

• MAC owns both upper boundaries : a logical channel meets MAC from above, and a transport channel meets it from below.
• The three bands answer three different questions : what the message is, how it is carried, and where it sits in the frame.

Which Channel Can Map to Which

The example tables further down this page record one network's choices. The specification limits what those choices can be, and the limits are short enough to hold in your head. 36.321 clause 4.5.3 fixes which logical channel may sit on which transport channel. 36.211 then fixes which physical channel carries each transport channel.

Downlink

The table below reproduces 36.321 Table 4.5.3.2-1. One row in it behaves differently from all the others, and that row explains a feature of the drawing above.

Only BCCH carries two crosses. Every other downlink logical channel has exactly one transport channel available to it, so its route is settled the moment the channel is named. BCCH is the single place where the network chooses, and content decides the choice. The MIB goes on BCH and the SIBs go on DL-SCH.

That one exception produces the two BCCH boxes in the downlink map and the two BCCH rows in the table above. BCCH 0 on BCH is the MIB, and BCCH 1 on DL-SCH carries the SIBs. Those row labels are the author's numbering rather than a specification term, because 36.321 defines one BCCH and not two.

Uplink

The uplink table is shorter, and the reason for that says something about the uplink. 36.321 Table 4.5.3.1-1 lists two transport channels and marks only one of them.

Every uplink logical channel maps to UL-SCH, so the uplink has one column that matters. RACH sits in the table with no logical channel marked against it at all. The preamble is not data handed down by RLC, because MAC generates it. That is why the RA Pre box in the uplink map has no counterpart in 36.321.

The Random Access Response has no logical channel either. DL-SCH carries it, and MAC builds it directly, which is why the tables on this page show neither an RLC mode nor an LCID against it. 36.321 clause 6.1.5 still gives it a header of its own, made of E/T/RAPID subheaders. A blank in the MAC Hdr column therefore means no ordinary LCID subheader rather than no header at all.

Transport to physical

The bottom step is the shortest of the three. Each transport channel has one physical channel, and none of them has a choice to make.

• Only BCCH has a downlink choice to make : the MIB goes on BCH and the SIBs go on DL-SCH, and every other logical channel has one route.
• The uplink mapping has one column that matters : CCCH, DCCH and DTCH all land on UL-SCH, and RACH carries no logical channel.
• A blank MAC Hdr entry is not always a missing header : the Random Access Response carries E/T/RAPID subheaders that no LCID appears in.

Channel Mapping Table throughout Call Processing

This is only an example case and Mapping (especiall LoCH No) can vary depending on situations. The point is that it will be really helpful for your troubleshooting or test case creation if you create this kind of table for your case.

Note : Refer to TS 36.331 - 9.1.1 Logical channel configurations

Cell Configuration and Channel Configuration during Call Processing

Following sequence is an example of signaling messages during the initial attach procedure and internal configurations that would happen within eNB. These internal configuration is just an example and it would vary depending on eNB hardware vendor.

Config 1) Activate Cell Physicall Layer

1) MIB

Config 2)  Activate PHY, MAC, RLC for SIB Transmission (BCCH-DL DSCH)

2) SIB 1

3) SIB 2

Config 3) Configure PHY, MAC for PRACH Reception and RACH Response Transmission

4) RRC : PRACH Preamble

5) RRC : RACH Response

Config 3) Configure PHY, MAC, RLC for Msg3 (RRC Connection Request) Reception (UL-CCCH)

6) RRC : RRC Connection Request

Config 4) Configure MAC, RLC, PDCH for DL DCCH, UL DCCH

7) RRC : RRC Connection Setup

8) RRC : RRC Connection Setup Complete + NAS : Attach Request + ESM : PDN Connectivity Request

9) RRC : DL Information Transfer + NAS : Authentication Request

10) RRC : UL Information Transfer + NAS : Authentication Response

11) RRC : DL Information Transfer + NAS : Security Mode Command

12) RRC : UL Information Transfer + NAS : Security Mode Complete

Config 5) Configure PDCP for Integrity, Ciphering (We may disable Integiry/Ciphering for some test environment)

13) RRC : Security Mode Command

14) RRC : Security Mode Complete

15) RRC : RRC Connection Reconfiguration + NAS : Attach Accept + NAS : Activate Default EPS Bearer Context Req

Config 6) Configure MAC, RLC, PDCP for DL/UL DTCH+DCCH

16) RRC : RRC Connection Reconfiguration Complete + NAS : Attach Complete + NAS : Activate Default EPS Bearer Context Accept

17) RRC : RRC Connection Release

Config 7) Deactivate all the channels related to DCCH, DTCH

Config 8) Activate channels for PCCH

< MO or MT call > : In MT call, Paging should be sent.

Config 9) Configure PHY, MAC for PRACH Reception and RACH Response Transmission

18) RRC : PRACH Preamble

19) RRC : RACH Response

Config 10) Configure PHY, MAC, RLC for Msg3 (RRC Connection Request) Reception (UL-CCCH)

20) RRC : RRC Connection Request

Config 11) Configure MAC, RLC, PDCH for DL DCCH, UL DCCH

21) RRC : RRC Connection Setup

22) RRC : RRC Connection Setup Complete + NAS : Service Request

23) RRC : Security Mode Command

24) RRC : Security Mode Complete

25) RRC : RRC Connection Reconfiguration + NAS : Activate Dedicated EPS Bearer Context Request

Config 12) Configure MAC, RLC, PDCP for DL/UL DTCH+DCCH

26) RRC : RRC Connection Reconfiguration Complete + NAS : Activate Dedicated EPS Bearer Context Accept

27) RRC : RRC Connection Release

Channels the Attach Sequence Never Uses

A reader who follows only the sequence above meets six or seven channels and never meets the rest. The maps draw some of the others anyway, and the specification defines more still. This section says what the absent ones are for. The aim is that an unfamiliar channel name in a log does not stop you.

Paging, which the map draws but the sequence skips

PCCH and PCH appear in the downlink map and in the table above, yet no row of the attach sequence uses them. The sequence starts with a UE that has already decided to connect. Paging runs before that point and reaches a UE sitting in idle mode. 36.331 clause 9.1.1.3 gives PCCH an RLC TM configuration and a TM MAC configuration, which is the same shape BCCH has. The eNB configuration list further down this page reaches paging at Config 8.

Broadcast and multicast traffic

MCCH and MTCH carry eMBMS, and MCH is the transport channel underneath them. MCH is the one downlink transport channel on this page that does not end at PDSCH, because PMCH carries it instead. SC-MCCH and SC-MTCH belong to single cell point to multipoint delivery, and 36.321 Table 4.5.3.2-1 puts both of those on DL-SCH rather than on MCH. BR-BCCH serves bandwidth reduced UEs and also sits on DL-SCH.

Physical channels with nothing above them

PDCCH, PCFICH, PHICH and PUCCH appear in neither map, and EPDCCH and MPDCCH do not appear either. A drawing that starts at the logical channels cannot reach them, because no transport channel and no logical channel sits above them. They carry Layer 1 control rather than data handed down from MAC.

They still leave a mark on the tables above. The RNTI column is where they surface. A C-RNTI that selects a PDSCH transmission is read from PDCCH, and an SI-RNTI that selects a SIB is read the same way. That column therefore records a PDCCH decision rather than anything carried on DL-SCH itself.

• A channel on the map but missing from the sequence is usually a timing matter : paging happens before the sequence on this page begins.
• The Layer 1 control channels cannot reach a map that starts at the logical channels : nothing is handed down to them, and the RNTI column is the only trace they leave.

Reference

Four specifications carry the rules quoted on this page. 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 4.5 is the channel structure. Table 4.5.1-1 lists the transport channels and Table 4.5.2-1 lists the logical channels. Table 4.5.3.1-1 and Table 4.5.3.2-1 are the uplink and downlink mapping tables reproduced above. Clause 6.1.5 is the MAC PDU for a Random Access Response.
• 36.331 - Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification, v19.3.0. Clause 9.1.1 holds the logical channel configurations that the note at the end of the mapping table points at. Clause 9.1.1.2 is the CCCH configuration and clause 9.1.1.3 is the PCCH configuration.
• 36.211 - Evolved Universal Terrestrial Radio Access (E-UTRA); Physical channels and modulation. Clause 5.1.1 lists the uplink physical channels and clause 6.1.1 lists the downlink ones. Clause 6.1.1 also carries the definition of a physical channel quoted above.
• 36.300 - Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2, v19.2.0. Clause 5.3.1 is the mapping between transport channels and physical channels.