Logical, Transport & Physical Channels in 5G NR

1. Why Three Layers of Channels

The three-layer channel model is not taxonomy for its own sake. Each layer exists because a different part of the system needs to make a decision, and each layer hides from the layer below exactly the information that layer must not depend on.

Table 1. The separation is what makes NR's flexibility affordable: a new logical channel needs no physical-layer change, and a new numerology needs no change to the logical channel model.

The consequence worth remembering is that the mapping is many-to-one going down and ambiguous coming up. Five downlink logical channels collapse onto three transport channels and then onto two physical channels. Recovering the logical channel from a received transport block is possible only because MAC put a subheader in front of every SDU — and for broadcast and paging, not even that: those use a transparent MAC PDU with no subheader at all, and the receiver knows what it is holding purely from the RNTI that addressed the PDCCH.

2. The Complete Mapping, Downlink and Uplink

The asymmetry between the two pictures is entirely explained by who is talking to whom. Downlink has to address an audience it cannot see — hence BCCH and PCCH, hence broadcast transport channels, hence the transparent MAC PDU. Uplink always has exactly one sender and one receiver, both of which already know each other, so the whole broadcast branch disappears.

3. Logical Channels, One by One

BCCH

PCCH

CCCH

DCCH

DTCH

Table 2. The five Uu logical channels. RLC transparent mode means no RLC header at all — which is why a broadcast SDU crosses the whole stack with almost no overhead.

Rel-17 adds two more downlink logical channels for multicast/broadcast services — MCCH for the multicast control information and MTCH for the multicast traffic itself — both mapped to DL-SCH and addressed by G-RNTI rather than by a UE's own C-RNTI. They are the first downlink logical channels that are neither cell-wide broadcast nor single-UE dedicated. Everything else below applies to the five Rel-15 channels.

The RLC mode column carries more weight than it looks. TM adds no RLC header, provides no segmentation and no retransmission — appropriate for something the network broadcasts repeatedly and never expects an acknowledgement for. AM adds a two- or four-octet header with a sequence number, does ARQ, and is what makes SRB1 reliable enough to carry a reconfiguration. UM adds a header and does segmentation and reassembly but no retransmission, which is what a voice bearer wants. See the companion 07 MAC PDU and Control Elements document for the header formats themselves.

4. Which Messages Ride Which Logical Channel

This is the table most often wanted and least often written down: given a message name in a log, which logical channel was it on?

MIB

PCCH

RRCResumeRequest1

DCCH

DCCH

DCCH

DCCH

DTCH

Table 3. Message-to-logical-channel mapping. The two entries worth memorising are the CCCH size split and the fact that RRCReestablishment is on SRB1, not SRB0.

5. LCID, eLCID, and the Subheader on the Wire

A logical channel becomes concrete at exactly one place: the 6-bit LCID field in the MAC subheader. Everything above it is naming; everything below it is bits. Six bits gives 64 codepoints, and Rel-15 spent nearly all of them, which is why Rel-16 had to add an extension mechanism.

5.1 DL-SCH LCID values

Table 4. DL-SCH LCID codepoints, TS 38.321 Table 6.2.1-1. Note the structure: SDUs at the bottom of the range, control elements at the top, extension escapes in the middle.

5.2 UL-SCH LCID values

Table 5. UL-SCH LCID codepoints, TS 38.321 Table 6.2.1-2. The asymmetry at 0 and 52 exists purely so that the two CCCH sizes are distinguishable without a length field.

5.3 The extended LCID space

Rel-16 needed more control-element codepoints than the 6-bit field had left, and could not simply reuse reserved values because a receiver that does not recognise a fixed-size CE cannot find the next subheader — there is no length field to skip over. The solution was two escape codepoints that introduce a wider field.

In a decoded log the eLCID appears as a two-line construct: an LCID of 33 or 34, then a codepoint. Older decoders that predate Rel-16 print LCID 33 or 34 as reserved and then desynchronise on the rest of the PDU, which produces a spray of nonsense subheaders after the first extended CE. That signature — one plausible subPDU followed by garbage — is almost always a decoder version problem, not a radio problem.

6. Transport Channels and Their Properties

A transport channel is defined by how MAC offers data to the physical layer, and the property list is short because it is exactly the set of things the physical layer has to know.

BCH

PCH

DL-SCH

UL-SCH

RACH

SL-BCH

SL-SCH

Table 6. Transport channel properties. DL-SCH is the only one that is HARQ-protected and dynamically scheduled and able to carry either broadcast or dedicated content — which is why almost everything ended up on it.

Two entries in that table are unusual enough to be worth stating plainly. RACH carries no transport block. It exists in the model so that the preamble has a place in the layered picture, but there is no MAC PDU, no CRC, no coding and no HARQ; the physical layer detects a sequence and reports an index and a timing offset. BCH has a fixed transport format, meaning the transport block size, the coding, the rate matching and the resource mapping are all constants rather than scheduler decisions — because a UE has to be able to decode it before it knows anything at all.

7. Transport Blocks, CRC, and Channel Coding

The transport block is where the layered model becomes arithmetic. MAC hands the physical layer a bit sequence of a size the scheduler chose; the physical layer attaches a CRC, possibly segments, encodes, rate matches to the resource elements available, and modulates. All of that is specified in TS 38.212.

BCH

Table 7. Coding per channel, TS 38.212 clause 5 onward. The pattern is consistent: LDPC where the block is large and HARQ exists, Polar where the block is small and there is no second chance.

The reason for the split is not aesthetic. LDPC has excellent performance on long blocks and supports incremental-redundancy HARQ naturally through its rate-matching circular buffer, which is exactly what a data channel needs. Polar performs better on very short blocks and has no HARQ requirement to satisfy, which is exactly what control needs. BCH sits at the extreme: 56 bits into 864, a code rate of about 0.065, because there is no retransmission, no feedback and no prior channel knowledge.

8. Physical Channels and Physical Signals

TS 38.211 cl. 4.3.2 draws a distinction that the word "channel" tends to blur: a physical channel is a set of resource elements carrying information that originated in a higher layer, while a physical signal is a set of resource elements used by the physical layer that carries no higher-layer information at all. PSS, SSS, DM-RS, PT-RS, CSI-RS and SRS are signals. They are not channels, they have no logical or transport channel above them, and they never appear in any mapping diagram.

PBCH

PDSCH

PDCCH

PUSCH

PUCCH

PRACH

Table 8. Physical channels. Only three of the six sit under a transport channel; the other three terminate their own chains.

DM-RS

PT-RS

CSI-RS

SRS

TRS

Table 9. Physical signals. None of them has a transport channel, a MAC header, a CRC or a HARQ process — which is why a 'CSI-RS failure' is never a decode failure, only a measurement that came back wrong.

9. RNTIs: Who Addresses What

Because five downlink logical channels share two physical channels, the receiver needs something to tell it what it is about to decode. That something is the RNTI used to scramble the PDCCH CRC. The RNTI is therefore part of the channel mapping, not an addressing detail bolted on beside it — it is the only thing that distinguishes a PDSCH carrying SIB1 from a PDSCH carrying a video frame.

SI-RNTI

P-RNTI

RA-RNTI

MSGB-RNTI

TC-RNTI

C-RNTI

MCS-C-RNTI

CS-RNTI

SFI-RNTI

INT-RNTI

TPC-SRS-RNTI

CI-RNTI

PS-RNTI

SP-CSI-RNTI

Table 10. RNTI to content mapping, TS 38.321 cl. 7.1. Everything except SI-RNTI and P-RNTI is assigned per UE or per group, so the same numeric value means different things in different cells.

10. DCI: Formats and Content

DCI is the content of PDCCH. It has no logical channel and no transport channel; it is generated by the physical layer of the gNB and consumed by the physical layer of the UE, and its only relationship to the mapping model is that it tells the UE which mapping to expect next.

0_0

0_1

0_2

1_0

1_1

1_2

2_0

2_1

2_2

2_3

2_4

2_5

2_6

2_7

Table 11. DCI formats, TS 38.212 cl. 7.3.1. Only 0_0/0_1/0_2 and 1_0/1_1/1_2 schedule a transport channel; every 2_x format is pure physical-layer control with no data underneath.

10.1 What is actually in a scheduling DCI

For DCI format 1_0 with a C-RNTI, the fields in order are: format identifier (1 bit), frequency-domain resource assignment, time-domain resource assignment (4 bits, an index into a configured table of start-symbol and length pairs), VRB-to-PRB mapping (1 bit), modulation and coding scheme (5 bits), new data indicator (1 bit), redundancy version (2 bits), HARQ process number (4 bits), downlink assignment index (2 bits), TPC command for the scheduled PUCCH (2 bits), PUCCH resource indicator (3 bits) and PDSCH-to-HARQ-feedback timing indicator (3 bits). That is a complete description of one PDSCH and its acknowledgement.

DCI 1_0 addressed to SI-RNTI uses the same format with a different field interpretation: there is no HARQ process number, no NDI and no DAI, because system information is not HARQ-protected and not UE-acknowledged; the freed bits become reserved. This is why a decoder that applies the C-RNTI field layout to an SI-RNTI DCI produces a plausible-looking but wrong PRB allocation — a failure mode worth recognising, because the symptom is a PDSCH decode failure with perfect PDCCH statistics.

11. UCI and the PUCCH Formats

UCI is the uplink counterpart: physical-layer control, no logical channel, no transport channel, no MAC PDU. It carries four kinds of information:

• HARQ-ACK — acknowledgement of received PDSCH transport blocks or code block groups. The number of bits is the codebook size, which is semi-statically or dynamically determined and can be anything from 1 to several hundred with carrier aggregation.
• Scheduling Request (SR) — a single bit per configured SR configuration, meaning "I have uplink data and no grant". See the companion 10 BSR, PHR, SR document.
• CSI — channel state reports, split into Part 1 (fixed size: rank indicator, CQI, and the information needed to size Part 2) and Part 2 (variable size, dependent on Part 1).
• Link Recovery Request — Rel-16, for beam failure recovery on a secondary cell where RACH is not available. See the companion 12 Beam Failure Recovery document.

0

1

2

3

4

Table 12. PUCCH formats, TS 38.211 cl. 6.3.2 and TS 38.213 cl. 9.2. Formats 0 and 2 are the short formats, 1, 3 and 4 the long ones; the payload split at 2 bits is the dividing line between sequence-based and coded transmission.

12. Sidelink Channel Mapping

NR sidelink (PC5, used for V2X and for public-safety direct communication) reuses the three-layer model wholesale, which makes it easy to read once you know the Uu version. The differences are all consequences of there being no base station in the path.

SBCCH

SCCH

STCH

SL-BCH

SL-SCH

PSBCH

PSSCH

PSCCH

PSFCH

Table 13. Sidelink channels. The two-stage SCI is the notable structural difference from Uu: the first stage is on its own physical channel so that any nearby UE can read it for sensing, while the second stage is inside the data resource and only the intended receiver needs it.

13. Multiplexing Rules: What Can Share a Transport Block

The mapping diagrams say what may map where. The multiplexing rules say what may travel together, and they are what a decoder actually relies on.

Table 14. Multiplexing rules and what each one implies when you are staring at a decoded PDU. The placement rules are the ones a decoder depends on.

14. End-to-End Traces: Six Messages Down the Stack

The chains below are structural: the field names, sizes and encodings follow 3GPP, while the identity and sequence-number values are constructed for this document so that the six traces stay consistent with each other. They are not a capture from any deployed or lab network.

MIB

SIB1

Paging

RRCSetupRequest

HARQ-ACK

Table 15. The summary table. The header column is the interesting one: overhead ranges from nothing at all to seven bytes, entirely determined by which logical channel was used.

14.1 MIB — the shortest chain in NR

RRC:   MIB  (24 bits of ASN.1, unaligned PER)
  |
  +--> logical channel  BCCH        -- RLC transparent mode: NO RLC header
       |
       +--> transport channel  BCH  -- transparent MAC PDU: NO MAC subheader
            |  PHY prepends 8 additional payload bits:
            |    SFN 4 LSBs (4), half-frame bit (1), k_SSB MSB or SSB idx (3)
            |  = 32-bit PBCH payload
            |  + 24-bit CRC (CRC24C)        -> 56 bits
            |  Polar encode, N = 512
            |  rate match to E = 864 bits   -> code rate ~ 0.065
            |  QPSK -> 432 REs
            +--> physical channel  PBCH     -- symbols 1,2,3 of the SSB

Total overhead above the physical layer: ZERO bytes.
Total UE prior knowledge required: the SSB position. Nothing else.

14.2 SIB1 — broadcast, but on the data channel

RRC:   BCCH-DL-SCH-Message { message: c1: systemInformationBlockType1 }
  |    ~ 400 - 900 bytes of ASN.1 depending on configuration
  +--> logical channel  BCCH        -- RLC TM: NO RLC header, NO segmentation
       |
       +--> transport channel  DL-SCH
            |  transparent MAC PDU: NO MAC subheader, NO LCID
            |  A = TBS bits, A > 3824 -> CRC24A -> B = A + 24
            |  LDPC base graph 1 or 2 depending on A and R
            |  segmentation if B > K_cb
            +--> physical channel  PDSCH
                 scheduled by DCI 1_0, CRC scrambled by SI-RNTI 0xFFFF
                 in the Type0-PDCCH common search space of CORESET#0

-- Why SIB1 is not on BCH: BCH's transport format is FIXED at 32 payload
-- bits. SIB1 is two orders of magnitude larger and its size varies with
-- configuration, so it needs a scheduled, variable-size transport channel.

14.3 Paging — a broadcast channel carrying targeted content

RRC:   PCCH-Message { message: c1: paging }
  |      pagingRecordList: up to 32 records, each with a ue-Identity
  +--> logical channel  PCCH        -- RLC TM
       |
       +--> transport channel  PCH  -- transparent MAC PDU
            |  no HARQ: an idle UE has no HARQ entity and cannot ACK
            +--> physical channel  PDSCH
                 scheduled by DCI 1_0, CRC scrambled by P-RNTI 0xFFFE
                 in the Type2-PDCCH common search space

-- The alternative path with no PDSCH at all:
     DCI 1_0 with P-RNTI, Short Message Indicator = 'short message only'
       Short Message (8 bits):
         bit 1  systemInfoModification
         bit 2  etwsAndCmasIndication
         bits 3-8  reserved / later releases
     -- no PCCH, no PCH, no transport block. The DCI IS the message.

14.4 RRCSetupRequest — the smallest real uplink message

RRC:   UL-CCCH-Message { message: c1: rrcSetupRequest }
  |      rrcSetupRequest
  |        ue-Identity        CHOICE { ng-5G-S-TMSI-Part1 | randomValue }  40 bits
  |        establishmentCause ENUMERATED, 16 values                         4 bits
  |        spare              BIT STRING (SIZE(1))                          1 bit
  |      + 3 bits of CHOICE encoding                    = 48 bits = 6 bytes
  |
  +--> logical channel  CCCH (48-bit variant)   -- RLC TM, no header
       |
       +--> transport channel  UL-SCH
            |  MAC subheader: R | R | LCID = 52     -- 1 byte, R/LCID form,
            |                                          no L field: fixed size
            |  MAC PDU = 1 + 6 = 7 bytes, padded to the TBS
            |  A <= 3824 -> 16-bit CRC
            +--> physical channel  PUSCH
                 granted by the UL grant inside the RAR, TC-RNTI 0x4C08

-- The first 48 bits of this CCCH SDU are what the gNB echoes back in the
-- UE Contention Resolution Identity MAC CE (DL LCID 62). That is why CCCH
-- must be exactly 48 bits and why it cannot be segmented.

14.5 A downlink data PDU — the full seven bytes of header

Application:  53-byte IP packet on QoS flow 5
  |
  +--> SDAP     + 1 byte  { RDI | RQI | QFI = 5 }            -> 54 bytes
       |            (SDAP header may be suppressed if configured)
       +--> PDCP + 2 bytes { D/C | R R R | SN(12) }          -> 56 bytes
            |       payload ciphered; MAC-I appended only if the DRB has
            |       integrity protection configured (+ 4 bytes)
            +--> RLC AM + 2 bytes { D/C | P | SI | SN(12) }  -> 58 bytes
                 |       SI = 00 -> complete SDU, no segment offset
                 +--> logical channel  DTCH, LCID 4
                      |
                      +--> transport channel  DL-SCH
                           |  MAC subheader R | F=0 | LCID=4 , L = 58
                           |  -> 2 + 58 = 60 bytes
                           |  plus a 2-byte TA Command subPDU at the front
                           |  plus padding subheader = 64-byte TB
                           +--> physical channel  PDSCH, C-RNTI 0x4C08

53 bytes of payload in a 64-byte transport block: 17 % overhead.

14.6 HARQ-ACK — the chain that does not exist

PHY (UE):  PDSCH transport block CRC check passes for HARQ process 6
  |
  +--> UCI: 1 bit of HARQ-ACK
       |    no logical channel      -- nothing came from RLC
       |    no transport channel    -- no transport block, no CRC
       |    no MAC PDU              -- MAC is not involved at all
       |
       |  PUCCH resource selected by the PUCCH resource indicator in the
       |  scheduling DCI; slot given by the PDSCH-to-HARQ feedback timing
       |  indicator (k1)
       +--> physical channel  PUCCH format 1
            1 PRB, 4-14 symbols, BPSK on the data symbols, DM-RS on the
            others, spread by a time-domain OCC

-- No RNTI is needed: the resource itself identifies the UE, because the
-- network told this UE and no other to use it.

15. Failure Modes and What Each One Means

Table 16. Channel-mapping failures. The pattern to internalise is that almost all of them are silent on at least one side, because the mapping is agreed by configuration and never negotiated on the wire.

16. Illustrative Message Traces

16.1 Walking a downlink MAC PDU, octet by octet

14:22:08.1035  [MAC-DL] C-RNTI 0x4C08, HARQ process 6, TBS 512 bits = 64 bytes
               raw: 3D 21 04 3A 84 B4 83 68 05 45 00 00 35 ...  3F 00

  offset 0  : 0x3D = 0011 1101   R=0 R=0 LCID=61   Timing Advance Command
  offset 1  : 0x21 = 0010 0001   TAG=0  TA Command=33
              -> fixed-size CE, 1 octet payload, no L field
  offset 2  : 0x04 = 0000 0100   R=0 F=0 LCID=4    DTCH  (DRB 1)
  offset 3  : 0x3A = 58                             L = 58 bytes follow
  offset 4  : 0x84 = 1000 0100   D/C=1 P=0 SI=00 SN[11:8]=0100
  offset 5  : 0xB4                                 SN[7:0] -> RLC SN 1204
              -> RLC AM PDU, complete SDU, no poll requested
  offset 6  : 0x83 = 1000 0011   D/C=1 R=000 SN[11:8]=0011
  offset 7  : 0x68                                 SN[7:0] -> PDCP SN 872
  offset 8  : 0x05 = 0000 0101   RDI=0 RQI=0 QFI=5
  offset 9..61                                     53 bytes of IP
  offset 62 : 0x3F = 0011 1111   R=0 R=0 LCID=63   Padding
  offset 63 : 0x00                                 padding byte

  -- reconciles: 2 (CE) + 2 (subhdr) + 58 (SDU) + 1 (pad subhdr) + 1 = 64

Listing 1. The same PDU as the bitfield figure, decoded from the octets. Every layer's header is visible and the byte count reconciles exactly against the transport block size.

16.2 An uplink PDU: SDU first, control elements after

14:22:09.7150  [MAC-UL] C-RNTI 0x4C08, grant 24 PRB, TBS 1544 bits = 193 bytes

  subPDU 1   R=0 F=0 LCID=1   L=42     DCCH  (SRB1)
               RLC AM PDU, SN 88
                 PDCP Data PDU, 12-bit SN 512, integrity-protected
                   RRC: MeasurementReport
                     measId 1, servCellId 0, rsrpResult 68, rsrqResult 41
  subPDU 2   R=0 F=0 LCID=4   L=132    DTCH  (DRB 1)
               RLC AM PDU, SN 3311, SI=01 (first segment of a larger SDU)
  subPDU 3   R=0 R=0 LCID=61          Short BSR
               LCG ID=1  Buffer Size index=12   -> 1132 .. 1326 bytes
  subPDU 4   R=0 R=0 LCID=57          Single Entry PHR
               PH=41 (2.0 .. 3.0 dB)  P_CMAX index=23
  subPDU 5   R=0 R=0 LCID=63          Padding, 6 bytes

  -- note the ORDER: SDUs (subPDU 1,2) come before CEs (3,4) in the uplink.
  -- The BSR reports the buffer AFTER this PDU was built, which is what
  -- makes it useful to the scheduler and why it must come last.

Listing 2. An uplink PDU carrying two logical channels and two control elements. The placement order is the reverse of the downlink and is what makes a padding BSR meaningful.

16.3 The transparent case: SIB1 with no MAC header at all

14:19:55.0200  [PHY-DL] PDCCH candidate, CORESET#0, aggregation level 8
               DCI format 1_0, CRC descrambled with SI-RNTI 0xFFFF -> match
                 frequencyDomainResourceAssignment ... 24 PRB from PRB 0
                 timeDomainResourceAssignment ........ row 2 (S=2, L=12)
                 vrb-to-PRB mapping .................. non-interleaved
                 modulationAndCodingScheme ........... 4
                 redundancyVersion ................... 0
                 systemInformationIndicator .......... sib1
                 reserved ............................ 15 bits
               -- no HARQ process number, no NDI, no DAI: SI is not
               -- HARQ-protected and not UE-acknowledged

14:19:55.0203  [MAC-DL] transport block 2 976 bits = 372 bytes
               transparent MAC PDU: the entire TB is one MAC SDU
               NO subheader, NO LCID, NO length field

14:19:55.0203  [RLC]    BCCH is transparent mode: SDU delivered unchanged
14:19:55.0204  [RRC-DL-BCCH] BCCH-DL-SCH-Message
                 message: c1: systemInformationBlockType1
                   cellSelectionInfo, servingCellConfigCommon,
                   si-SchedulingInfo, ue-TimersAndConstants, ...

-- A decoder that looks for a MAC subheader here will read the first two
-- bytes of ASN.1 as R/F/LCID/L and produce a confident, wrong answer.

Listing 3. Broadcast reception with no MAC or RLC header anywhere. The RNTI did all the work that a subheader would otherwise do.

16.4 A failure: an extended LCID an old decoder cannot follow

15:08:41.3300  [MAC-DL] C-RNTI 0x4C08, TBS 328 bits = 41 bytes
               raw: 22 1C 3D 21 04 12 C4 ...

  offset 0 : 0x22 = 0010 0010   R=0 F=0 LCID=34
             -> Rel-16 one-octet eLCID escape
  offset 1 : 0x1C = 28                       eLCID 28 -> codepoint 64+28 = 92

  DECODER A (Rel-18 aware):
    codepoint 92 recognised, fixed size 2 octets, consumed
    offset 4 : 0x04  R=0 F=0 LCID=4  DTCH -> parses cleanly to the end

  DECODER B (Rel-15 tables only):
    offset 0 : LCID=34 -> 'Reserved' in the Rel-15 table
               no length field and no known size: the walk cannot resume
               (a decoder that assumes zero length carries on anyway:)
    offset 1 : 0x1C = 0001 1100  read as R=0 F=0 LCID=28
               -> 'logical channel 28', which is not configured for this UE
    offset 2 : 0x3D              read as L = 61 bytes of SDU
               61 claimed, 38 remaining in a 41-byte TB -> overrun
    result: 'malformed MAC PDU'. The real control element and the real
            DTCH SDU are both lost, and a logical channel that does not
            exist appears in the per-LCID statistics.

-- Both decoders report success. Only one of them is right. This is the
-- most dangerous class of channel-mapping fault because it is silent.

Listing 4. Two decoders, one PDU, two confident answers. An unrecognised fixed-size codepoint desynchronises everything after it, which is precisely why the eLCID escape exists rather than reusing reserved values.

17. Configuration Reference (ASN.1 and Ranges)

Logical channels are configured one at a time, each as an RLC-BearerConfig that binds a logical channel identity to a radio bearer, an RLC configuration and a set of MAC parameters. There is no single "channel mapping" IE — the mapping is implicit in which bearer the logical channel serves.

RLC-BearerConfig ::= SEQUENCE {
    logicalChannelIdentity      LogicalChannelIdentity,   -- INTEGER (1..32)
    servedRadioBearer           CHOICE {
        srb-Identity                SRB-Identity,         -- INTEGER (0..3)
        drb-Identity                DRB-Identity          -- INTEGER (1..32)
    }                                                     OPTIONAL,
    reestablishRLC              ENUMERATED {true}         OPTIONAL,
    rlc-Config                  RLC-Config                OPTIONAL,
    mac-LogicalChannelConfig    LogicalChannelConfig      OPTIONAL,
    ...
}

RLC-Config ::= CHOICE {
    am SEQUENCE {
        ul-AM-RLC   UL-AM-RLC,       -- sn-FieldLength: size12 | size18
        dl-AM-RLC   DL-AM-RLC        -- t-Reassembly, t-StatusProhibit, ...
    },
    um-Bi-Directional  SEQUENCE { ul-UM-RLC, dl-UM-RLC },
    um-Uni-Directional-UL  SEQUENCE { ul-UM-RLC },
    um-Uni-Directional-DL  SEQUENCE { dl-UM-RLC },
    ...
}
-- note: there is no 'tm' branch. Transparent mode is used only for
-- BCCH, PCCH and CCCH, none of which is configured by RLC-BearerConfig.

LogicalChannelConfig ::= SEQUENCE {
    ul-SpecificParameters SEQUENCE {
        priority                    INTEGER (1..16),
        prioritisedBitRate          ENUMERATED {kBps0, kBps8, kBps16,
                                                ..., kBps65536, infinity},
        bucketSizeDuration          ENUMERATED {ms5, ms10, ms20, ms50,
                                                ms100, ms150, ms300,
                                                ms500, ms1000, ...},
        allowedServingCells         SEQUENCE OF ServCellIndex   OPTIONAL,
        allowedSCS-List             SEQUENCE OF SubcarrierSpacing OPTIONAL,
        maxPUSCH-Duration           ENUMERATED {ms0p02, ms0p04, ms0p0625,
                                                ms0p125, ms0p25, ms0p5,
                                                ...}           OPTIONAL,
        configuredGrantType1Allowed ENUMERATED {true}           OPTIONAL,
        logicalChannelGroup         INTEGER (0..maxLCG-ID)      OPTIONAL,
        schedulingRequestID         SchedulingRequestId         OPTIONAL,
        logicalChannelSR-Mask       BOOLEAN,
        logicalChannelSR-DelayTimerApplied  BOOLEAN,
        ...
    }                                                          OPTIONAL,
    ...
}
-- maxLCG-ID = 7, so eight logical channel groups for BSR reporting.

Listing 5. Abridged from TS 38.331. ... marks omitted enumeration members and extension markers. Note the absence of a transparent-mode branch in RLC-Config.

logicalChannelIdentity

srb-Identity

drb-Identity

rlc-Config

sn-FieldLength

priority

prioritisedBitRate

logicalChannelGroup

integrityProtection

Table 17. Configuration that determines how much header a logical channel costs and how it competes for resources. Typical values are what many vendors ship, not specification requirements.

18. Release Deltas: Rel-15 to Rel-18

Table 18. Channel-mapping changes by release. Almost every entry adds either a codepoint or a new physical-layer control format — the three-layer model itself has not changed since Rel-15.

19. Reading Channel Mapping in Logs: A Checklist

1. Start from the RNTI, not the payload. The RNTI that descrambled the PDCCH CRC tells you what the PDSCH contains before you decode a single byte of it (§9). SI-RNTI means BCCH, P-RNTI means PCCH or a Short Message, RA-RNTI means a RAR, C-RNTI means DCCH or DTCH.

2. Decide whether a MAC subheader should exist at all. For BCCH, PCCH and BCH there is none — the PDU is a transparent MAC PDU. Parsing one produces confident nonsense (§16.3).

3. Walk the subheaders and reconcile the byte count. Every subPDU is either a subheader with an L field, or a subheader whose LCID implies a fixed size. If the total does not equal the transport block size, your walk went wrong somewhere — probably at an unrecognised LCID.

4. Map each LCID to a logical channel using the right table and the right direction. LCID 61 is a Timing Advance Command in the downlink and a Short BSR in the uplink. The tables are different (§5).

5. Check LCID 33 and 34 first if anything looks corrupt. An eLCID escape parsed by an old decoder produces a plausible spray of spurious control elements (§16.4).

6. Verify the logical channel is configured at both ends. Compare the LCIDs appearing on the wire against logicalChannelIdentity in the RLC-BearerConfig list. A bearer with sender-side counters and no receiver-side counters is a configuration mismatch, not a radio problem.

7. Separate the three loss counters. PHY transport block CRC failures, RLC retransmissions and PDCP loss are three layers reporting overlapping events. Only PDCP loss is loss to the application (§7).

8. For anything on PDCCH or PUCCH, stop looking for a logical channel. DCI and UCI have none. If a tool prints one, it is guessing.

9. When UCI seems to be missing, size the PUCCH resource against the worst-case payload. CSI that arrives less often than configured, with no errors, is almost always dropped UCI rather than a reporting fault (§11).

10. Read the message name and predict the chain before you look. If RRCReestablishment appears on CCCH, or a MeasurementReport on SRB2, or a NAS message on SRB1 after SRB2 was established, something is not what you think it is (§4).

20. Glossary

21. References

• 3GPP TS 38.300 — NR overall description. Clause 6.1 (protocol architecture), 6.2 (channels and channel mapping, including the downlink and uplink mapping figures), 6.3 (physical layer), 16 (sidelink).
• 3GPP TS 38.321 — NR MAC protocol specification. Clause 4.2 (channel architecture and logical channels), 4.4 (sidelink), 5.4 (uplink data transfer and logical channel prioritisation), 6.1 (MAC PDU formats, subheader variants and the transparent MAC PDU), 6.1.2 (subheader formats and subPDU ordering), 6.2.1 (LCID and eLCID tables, Tables 6.2.1-1 and 6.2.1-2), clause 7.1 (RNTI values, Table 7.1-1).
• 3GPP TS 38.211 — Physical channels and modulation. Clause 4.3.2 (the physical channel / physical signal distinction), 6.2 and 6.3 (uplink physical channels and signals, PUCCH formats), 7.3 and 7.4 (downlink physical channels and signals, PBCH and the SS/PBCH block).
• 3GPP TS 38.212 — Multiplexing and channel coding. Clause 5 (CRC, LDPC and Polar coding, code block segmentation), 7.1 (BCH encoding: payload generation, scrambling, CRC, Polar, rate matching to 864), 7.2 (DL-SCH and UL-SCH), 7.3.1 (DCI formats), 6.3 (UCI coding).
• 3GPP TS 38.213 — Physical layer procedures for control. Clause 9.2 (UCI on PUCCH, resource determination and formats), 9.2.5 (UCI multiplexing and dropping rules), 10 (search spaces and RNTI monitoring), 11.1 (slot format indication).
• 3GPP TS 38.322 — RLC protocol specification. Clause 6.2 (TM, UM and AM PDU formats and header sizes).
• 3GPP TS 38.323 — PDCP protocol specification. Clause 6.2 (data PDU formats, 12-bit and 18-bit sequence numbers, MAC-I).
• 3GPP TS 37.324 — SDAP protocol specification. Clause 6.2 (SDAP header formats, uplink and downlink).
• 3GPP TS 38.331 — RRC protocol specification. RLC-BearerConfig, LogicalChannelConfig, RLC-Config, SDAP-Config, PDCP-Config, SRB-Identity, DRB-Identity, and the UL-CCCH-Message, DL-CCCH-Message, UL-DCCH-Message, DL-DCCH-Message, BCCH-DL-SCH-Message and PCCH-Message containers.

Companion documents in this set

• 02 Radio Frame Structure — the resource grid every physical channel is placed on, and where the SS/PBCH block sits inside it.
• 03 Random Access — the CCCH/UL-SCH/PUSCH path for MSG3, the RAR that has no logical channel, and the UE Contention Resolution Identity CE.
• 05 HARQ — what the transport channel HARQ property in §6 actually does, and code block group retransmission.
• 07 MAC PDU and Control Elements — the subheader formats of §5 and every MAC CE the LCID tables point at, in detail.
• 08 Scheduling — how a DCI's resource allocation fields turn into the PDSCH and PUSCH of §8.
• 09 Logical Channel Prioritisation — how an uplink grant is divided between the logical channels of §3.
• 10 BSR, PHR, SR — the uplink control elements and the SR that rides as UCI.
• 13 RRC Overview / 15 RRC Procedures — the messages of §4 and the SRBs they use.
• 17 System Information / 18 MIB and SIB1 IEs — the BCCH content of §14.1 and §14.2.
• 19 Paging — the PCCH/PCH path and the Short Message alternative.
• 26 UE Capability — which control elements, DCI formats and PUCCH formats a given UE actually supports.