3G/UMTS

 

 

 

Channel Mapping : Cell DCH R6

 

In CELL_DCH state a Release 5 or Release 6 UE can receive its downlink data on HS-DSCH instead of a DCH. This page shows one example where the signalling radio bearers and the user plane bearer both go on HS-DSCH. MAC-hs in the Node B schedules them, and HS-PDSCH carries them over the air.

The common channels BCCH, PCCH and CCCH are not part of this mapping. They keep the mapping shown on the Cell FACH R99/R5/R6 page. The Release 7 version of this page is Cell DCH R7.

What does the CELL_DCH mapping with HSDPA look like?

HS-DSCH is one transport channel, and the Node B shares it in time among all HSDPA UEs in the cell. So MAC does not give each logical channel its own transport channel. It groups the logical channels into MAC-d flows, and the MAC-d flows feed priority queues in MAC-hs.

The diagram below reads from top to bottom. The top row lists the logical channels with their rb-id and LCID. The common channels on the left end in a box labelled Same as R99/R5/R6. The four DCCHs go into MAC Flow Id = 1, and DTCH 1 goes into MAC Flow Id = 2. Each flow feeds its own queue, and both queues end on HSDSCH/HSDPSCH at the bottom.

UMTS CELL_DCH R6 logical channel to HS-DSCH mapping with MAC-d flows and queues

Signalling and user data travel on separate MAC-d flows and separate queues, so the Node B can schedule them with different priorities.

  • Common channels are unchanged : BCCH, PCCH and CCCH keep their CELL_FACH and idle mode mapping.
  • MAC-d flow 1 carries SRB1 to SRB4 : DCCH 0 to DCCH 3, with rb-id 1 to 4 and LCID 1 to 4.
  • MAC-d flow 2 carries the user plane : DTCH 1, with rb-id 8 and LCID 8.
  • Queue 1 and Queue 2 are MAC-hs priority queues : each queue has its own reordering in the UE.
  • HSDSCH/HSDPSCH : the transport channel HS-DSCH on the physical channel HS-PDSCH.

Why split the channels into two flows? When MAC-hs is used, one TTI carries MAC-d PDUs of one reordering queue only, and each queue has one priority. With the SRBs in their own queue, the Node B scheduler can send an RRC message ahead of a burst of user data. The RRC message does not have to wait behind the DTCH queue.

  • One queue per TTI : MAC-hs cannot mix Queue 1 and Queue 2 in the same TTI.
  • Separate queues give separate priorities : signalling does not queue behind user data.

How does the UE separate the channels inside one MAC-d flow?

Four DCCHs share MAC-d flow 1, so the UE still needs a way to tell them apart after MAC-hs has delivered the data. It uses the same C/T field that separates dedicated channels on FACH. On HS-DSCH, the field sits in the MAC-d header.

The UE reads two headers, one after the other. First, the MAC-hs header carries the Queue ID and the TSN. The Queue ID sends the MAC-hs PDU to the right reordering queue. The TSN then puts the PDUs of that queue back in order, because HARQ retransmissions can deliver them out of order.

Next, MAC-hs hands each MAC-d PDU to MAC-d. The MAC-d header carries the C/T field when MAC multiplexes several logical channels onto one MAC-d flow. C/T gives the logical channel number, coded as the LCID minus one. So the LCID 1 to 4 labels on DCCH 0 to DCCH 3 are the values that the UE reads from C/T.

DTCH 1 is alone on MAC-d flow 2. MAC applies no multiplexing on that flow, so the MAC-d PDUs of DTCH 1 need no C/T field. The LCID of 8 is still part of the configuration. The row label on the left reads DCH, but every dedicated channel in the diagram ends on HS-DSCH. The uplink is not drawn.

Putting the SRBs on HS-DSCH also matters for the associated channel. HS-PDSCH always comes with an associated DPCH or F-DPCH. Release 6 added the F-DPCH, which carries only TPC commands and no transport channel. So a UE configured with F-DPCH has no downlink DCH, and it has to receive its DCCHs on HS-DSCH, as in the diagram above.

  • Queue ID and TSN come first : the MAC-hs header routes and reorders the data per queue.
  • C/T separates the DCCHs on flow 1 : LCID 1 to 4 are coded 0000 to 0011.
  • A channel alone on its flow needs no C/T : DTCH 1 on flow 2 is the example here.
  • F-DPCH needs SRBs on HS-DSCH : the F-DPCH carries no DCCH.

Reference

[1] 3GPP TS 25.301 v19.0.0 - clause 5.3.1.1.2, Mapping between logical channels and transport channels

[2] 3GPP TS 25.321 v19.0.0 - clause 9.1.4, MAC PDU for HS-DSCH, and clause 9.2.1.1a, MAC-d header for DTCH and DCCH mapped on HS-DSCH

[3] 3GPP TS 25.308 v19.0.0 - HSDPA overall description, clause 5.2, associated DPCH or F-DPCH