Release 7 keeps the CELL_DCH channel mapping of Release 6, but it adds a second MAC entity for HS-DSCH, MAC-ehs. Upper layers configure either MAC-hs or MAC-ehs for the UE. The diagram on this page has the same boxes as the Cell DCH R6 page. So the difference sits in the MAC headers, and the second section of this page explains it.
What does the CELL_DCH R7 mapping look like?
Let's check the boxes first, before looking at the headers. The dedicated channels still share one HS-DSCH, and MAC still groups them into MAC-d flows and queues. The only new label is on the common channels.
The diagram below reads from top to bottom. The top row lists the logical channels with their rb-id and LCID. BCCH, PCCH and CCCH end in a box labelled Same as R5/R6. The four DCCHs go into MAC Flow Id = 1 and Queue 1. DTCH 1 goes into MAC Flow Id = 2 and Queue 2. Both queues end on HSDSCH/HSDPSCH.
The mapping is the same as in Release 6. Only the MAC entity that serves the two queues can change.
Common channels keep their earlier mapping : the label reads Same as R5/R6, which points to the Cell FACH R99/R5/R6 mapping.MAC-d flow 1 carries SRB1 to SRB4 : DCCH 0 to DCCH 3, with LCID 1 to 4, in Queue 1.MAC-d flow 2 carries the user plane : DTCH 1, with rb-id 8 and LCID 8, in Queue 2.The diagram does not show the MAC entity : the same boxes apply with MAC-hs or with MAC-ehs.
Release 7 also adds HS-DSCH reception in CELL_FACH. That is a separate mapping, where BCCH, PCCH and CCCH can go on HS-DSCH as well. It is on the Enhanced Cell FACH R7 page, and it always uses MAC-ehs.
CELL_DCH mapping is unchanged in Release 7 : the new mapping of Release 7 is in CELL_FACH.
What changes when MAC-ehs is configured?
With MAC-hs, the UE needed two headers to find the logical channel: the MAC-hs header for the queue and the MAC-d header for C/T. MAC-ehs replaces both with one header. It also changes what one TTI can carry.
The first change is multiplexing across queues. A MAC-hs PDU carries data of one reordering queue only. A MAC-ehs PDU can carry several reordering PDUs, one per queue, so Queue 1 and Queue 2 can share a TTI. An RRC message on DCCH and user data on DTCH 1 can therefore reach the UE in the same TTI.
The second change is the logical channel field. With MAC-ehs, the MAC-d PDU has no header, so the C/T field disappears. Instead, the MAC-ehs header carries a 4 bit LCH-ID for every reordering SDU. The LCH-ID names the logical channel and also its reordering queue. Its coding matches C/T: 0000 is logical channel 1 and 1110 is logical channel 15. So DCCH 0 to DCCH 3 are sent as LCH-ID 0000 to 0011, and DTCH 1 as 0111. The value 1111 is kept for BCCH and PCCH on HS-DSCH.
The third change is segmentation. MAC-ehs can split a MAC-ehs SDU across TTIs, and the SI field in the header tells the UE how to join the segments. This lets RLC AM use flexible PDU sizes, which Release 7 RLC supports when MAC-ehs is configured. The RLC PDU size then no longer has to be one of the fixed MAC-d PDU sizes that the SID field of MAC-hs refers to.
Several queues in one TTI : MAC-ehs can mix Queue 1 and Queue 2, and MAC-hs cannot.LCH-ID replaces C/T : the MAC-d PDU has no header when MAC-ehs is configured.LCH-ID 1111 is reserved for BCCH and PCCH : it matters only in the CELL_FACH and PCH states.Segmentation allows flexible RLC PDU sizes : the SI field marks the segments.
Reference
[1] 3GPP TS 25.301 v19.0.0 - clause 5.3.1.1.2, Mapping between logical channels and transport channels, and clause 5.3.1.2, MAC functions
[2] 3GPP TS 25.321 v19.0.0 - clause 9.1.4, MAC PDU for HS-DSCH, and clause 9.2.2, MAC-ehs header parameters
[3] 3GPP TS 25.308 v19.0.0 - HSDPA overall description, MAC-hs and MAC-ehs