MAC-hs is the part of the MAC layer that Release 5 added for HSDPA. It sits in the Node B, close to the air interface, so that the scheduler and the HARQ retransmissions can react every 2 ms TTI without waiting for the RNC. MAC-d stays in the RNC and keeps doing what it did in Release 99. This page follows data from MAC-d into MAC-hs in the UTRAN, then back out of MAC-hs in the UE. It then covers the reordering in the UE and the changes that MAC-ehs made. The field values are checked against 25.321 v19.0.0 and 25.331 v19.0.1.

The topics on this page are listed below.

• Overview on MAC-hs in UTRAN : HSDPA
• Overview on MAC-hs in UE : HSDPA
• How does the UE put MAC-hs PDUs back in order?
• What changes when MAC-ehs replaces MAC-hs?
• Reference

Overview on MAC-hs in UTRAN : HSDPA

When you study about MAC-hs or MAC-ehs, you always have to think of it in connection with MAC-d. So I combined the two entity as follows to help your understanding. Try following each single steps along the red path of MAC-d and all the path in MAC-hs.

In the diagram below, MAC-d is on the right and MAC-hs is on the left. The red path starts at the DCCH and DTCH at the top of MAC-d. It passes Transport Channel Type Switching, the C/T MUX / Priority setting block and Flow Control. It then crosses over to the MAC-d flows at the top of MAC-hs. Inside MAC-hs, the data goes through Priority Queue distribution, the Priority Queues, the HARQ entity and TFRC selection, down to the HS-DSCH.

MAC-d and MAC-hs side by side. The red line leaves MAC-d at Flow Control and enters MAC-hs as a MAC-d flow. That crossing is the Iub, because MAC-d runs in the RNC and MAC-hs runs in the Node B.

As a first step, let's just read the path.

i) one DTCH or DCCH RLC PDU gets into MAC-d.

ii) MAC-d add C/T field to the data and pass it to MAC-hs.

iii) MAC-hs distribute the incoming data into each of the priority queues.

iv) As time goes one, multiple MAC-d PDUs will be accumulating into Priority Queues.

v) The scheduler in MAC-hs choose one of the priority Queues in every TTI and pull out a certain number of MAC-d PDUs based on TFRI and transmit it to the transport channel. (The MAC-hs can carry only one Queue data in one TTI, meaning it cannot multiplex more than one Queue data into one TTI).

Note :

• There is one MAC-hs entity for each cell
• There is seprate HARQ entity for each user.
• The MAC-hs can carry only one Queue data in one TTI, meaning it cannot multiplex more than one Queue data into one TTI
• One Logical Channel --> One MAC-d Flow --> One Priority Queue --> One TTI (Transport Block)
• MAC-hs allows for 8 different MAC-d PDU sizes in each queue and the size is specified by SID(Size Index field)

25.321 clause 4.2.4.3 is exact about who does what in step v). The Scheduling/Priority Handling function picks the queue and decides between a new transmission and a retransmission. The HARQ entity then runs one HARQ process per TTI, and TFRC selection picks the transport format and resource. The chain of one logical channel to one queue is the simple case. The C/T field exists because MAC-d can multiplex several logical channels into one MAC-d flow, and one MAC-d flow can feed more than one priority queue.

• MAC-d in the RNC, MAC-hs in the Node B : the MAC-d flow crosses the Iub, and Flow Control on both sides limits how much data waits in the Node B.
• One MAC-hs per cell, one HARQ entity per UE : 25.321 clause 4.2.4.3 states the first, and the HARQ entity description states the second.
• One queue per TTI : a MAC-hs PDU carries MAC-d PDUs of a single reordering queue, and MAC-ehs removes that limit.

What does the RRC message configure in MAC-hs?

MAC-hs has no signalling of its own for its configuration. The RNC sets the HARQ processes and every reordering queue through RRC, and the UE builds its MAC-hs from that. The red lines in the capture below are the queue settings that the next section uses.

Following is an example of MAC-hs configuration in Radio Bearer Setup. As you see, the MAC hs setup has MAC-d configuration information as well.

Decoded RRC message from a tester log, captured. Field values are from a live capture, not from the specification.

+-message ::= CHOICE [radioBearerSetup]
  +-radioBearerSetup ::= CHOICE [later-than-r3]
    +-later-than-r3 ::= SEQUENCE
      +-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
      +-criticalExtensions ::= CHOICE [criticalExtensions]
        +-criticalExtensions ::= CHOICE [r5]
          +-r5 ::= SEQUENCE [00]
            +-radioBearerSetup-r5 ::= SEQUENCE [001000110001001010101001111]
            | +-rab-InformationSetupList ::= SEQUENCE OF SIZE(1..maxRABsetup[16]) [1] OPTIONAL:Exist
            | +-rb-InformationAffectedList ::= SEQUENCE OF OPTIONAL:Omit
            | +-dl-CounterSynchronisationInfo ::= SEQUENCE OPTIONAL:Omit
            | +-ul-CommonTransChInfo ::= SEQUENCE [0010] OPTIONAL:Exist
            | +-ul-deletedTransChInfoList ::= SEQUENCE OF OPTIONAL:Omit
            | +-ul-AddReconfTransChInfoList ::= SEQUENCE OF SIZE(1..maxTrCHpreconf[32]) [2]
            | +-dummy ::= CHOICE OPTIONAL:Omit
            | +-dl-CommonTransChInfo ::= SEQUENCE [01] OPTIONAL:Exist
            | +-dl-DeletedTransChInfoList ::= SEQUENCE OF OPTIONAL:Omit
            | +-dl-AddReconfTransChInfoList ::= SEQUENCE OF SIZE(1..maxTrCHpreconf[32]) [2]
            | | +-DL-AddReconfTransChInformation-r5 ::= SEQUENCE [0]
            | | | +-dl-TransportChannelType ::= CHOICE [hsdsch]
            | | | | +-hsdsch ::= NULL
            | | | +-tfs-SignallingMode ::= CHOICE [hsdsch]
            | | | | +-hsdsch ::= SEQUENCE [11]
            | | | |   +-harqInfo ::= SEQUENCE OPTIONAL:Exist
            | | | |   | +-numberOfProcesses ::= INTEGER (1..8) [6]
            | | | |   | +-memoryPartitioning ::= CHOICE [explicit]
            | | | |   |   +-explicit ::= SEQUENCE OF SIZE(1..maxHProcesses[8]) [6]
            | | | |   |     +-HARQMemorySize ::= ENUMERATED [hms4800]
            | | | |   |     +-HARQMemorySize ::= ENUMERATED [hms4800]
            | | | |   |     +-HARQMemorySize ::= ENUMERATED [hms4800]
            | | | |   |     +-HARQMemorySize ::= ENUMERATED [hms4800]
            | | | |   |     +-HARQMemorySize ::= ENUMERATED [hms4800]
            | | | |   |     +-HARQMemorySize ::= ENUMERATED [hms4800]
            | | | |   +-addOrReconfMAC-dFlow ::= SEQUENCE [10] OPTIONAL:Exist
            | | | |     +-mac-hs-AddReconfQueue-List ::= SEQUENCE OF SIZE(1..maxQueueIDs[8]) [1]
            | | | |     | +-MAC-hs-AddReconfQueue ::= SEQUENCE [1]
            | | | |     |   +-mac-hsQueueId ::= INTEGER (0..7) [0]
            | | | |     |   +-mac-dFlowId ::= INTEGER (0..7) [0]
            | | | |     |   +-reorderingReleaseTimer ::= ENUMERATED [rt50]
            | | | |     |   +-mac-hsWindowSize ::= ENUMERATED [mws16]
            | | | |     |   +-mac-d-PDU-SizeInfo-List ::= SEQUENCE OF SIZE(1..maxMAC-d-PDUsizes[8]) [1]
            | | | |     |     +-MAC-d-PDUsizeInfo ::= SEQUENCE
            | | | |     |       +-mac-d-PDU-Size ::= INTEGER (1..5000) [336]
            | | | |     |       +-mac-d-PDU-Index ::= INTEGER (0..7) [0]
            | | | |     +-mac-hs-DelQueue-List ::= SEQUENCE OF OPTIONAL:Omit
            | | | +-dch-QualityTarget ::= SEQUENCE OPTIONAL:Omit
            | | +-DL-AddReconfTransChInformation-r5 ::= SEQUENCE [1]
            | +-frequencyInfo ::= SEQUENCE OPTIONAL:Omit
            | +-maxAllowedUL-TX-Power ::= INTEGER OPTIONAL:Omit
            | +-ul-ChannelRequirement ::= CHOICE [ul-DPCH-Info] OPTIONAL:Exist
            | +-modeSpecificPhysChInfo ::= CHOICE [fdd]
            | +-dl-HSPDSCH-Information ::= SEQUENCE [11] OPTIONAL:Exist
            | +-dl-CommonInformation ::= SEQUENCE [11] OPTIONAL:Exist
            | +-dl-InformationPerRL-List ::= SEQUENCE OF SIZE(1..maxRL[8]) [1] OPTIONAL:Exist
            +-radioBearerSetup-r5-add-ext ::= BIT STRING OPTIONAL:Omit
            +-v5d0NonCriticalExtenstions ::= SEQUENCE OPTIONAL:Omit

The capture sets up one HS-DSCH with its HARQ processes and one reordering queue. Each red field maps to one element of MAC-hs-AddReconfQueue in 25.331, and the types in the current release are the same as in the capture.

• numberOfProcesses = 6 : six HARQ processes, the number that keeps one UE busy in every TTI. See HARQ - HSDPA.
• memoryPartitioning = explicit, 6 x hms4800 : each process gets 4800 soft channel bits, 28800 in total. That total equals the soft buffer of HS-DSCH Categories 2, 3 and 12 in 25.306.
• mac-hsQueueId = 0 and mac-dFlowId = 0 : queue 0 of MAC-hs is fed by MAC-d flow 0. The Queue ID in the MAC-hs header carries the same 0.
• reorderingReleaseTimer = rt50 : timer T1 of the reordering entity is 50 ms. In 25.331, T1-ReleaseTimer runs from rt10 to rt400.
• mac-hsWindowSize = mws16 : the receiver window of the reordering entity is 16 TSNs. MAC-hs-WindowSize allows mws4 to mws32.
• mac-d-PDU-Size = 336, mac-d-PDU-Index = 0 : SID 0 in the MAC-hs header means a MAC-d PDU of 336 bits for this queue.

What are the functional blocks of MAC-hs in the Node B?

The diagram in the previous section mixed MAC-d and MAC-hs. The figure below takes MAC-hs alone, as 25.321 draws it, so that each block can be matched with one function in the specification text.

This is the MAC component for HSDPA and the detailed structure is as follows (R99 system does not have this module). Overall process that this component is performing are :

• i) Take in multiples of MAC-d PDUs
• ii) Combine the multiple PDUs into a single big PDU
• iii) Convert the combined PDU into a HARQ entity
• iv) Encode the HARQ Entity according to the selected TFRI

< 25.321 - Figure 4.2.4.3.1 : UTRAN side MAC architecture / MAC-hs details >

• Flow Control : this block is not drawn inside MAC-hs, but 25.321 lists it as one of the four MAC-hs functions. It works per MAC-d flow, together with the flow control in MAC-d.
• Scheduling/Priority handling : it holds the Priority Queue distribution and the Priority Queues. It sets the Queue ID and TSN of each new MAC-hs PDU.
• HARQ entity : one HARQ entity per user, with one HARQ process per HS-DSCH per TTI.
• TFRC selection : it picks the transport format and resource for the data, which the HS-SCCH then announces to the UE.
• MAC - Control : the grey line on the right is where RRC configures the entity.

25.321 v19.0.0 writes the number of Figure 4.2.4.3.1 as 4.2.4.3-1. It also adds Figure 4.2.4.3-2, a variant for 1.28 Mcps TDD multi-frequency operation, where each carrier gets its own HARQ sub-entity.

What does a MAC-hs PDU look like?

The header is the only place where the UE learns which queue a block belongs to and how to cut it into MAC-d PDUs. So every field of it maps to one step of the UE side procedure in the next section.

The MAC PDU created by this module is as follows and the meaning of each field is summarized in a table following next.

< 25.321 - Figure 9.1.4.1 : MAC-hs PDU >

Note : Just by reading the PDU structure shown here you would notice a couple of characteristics as follows.

i) A MAC-hs PDU can carry the data coming from only one Priority Queue.

ii) A MAC-hs PDU can carry the mulitple MAC-d PDUs. (These MAC-d PDUs can have same or different sizes).

The field sizes give the header its limits. With a 3-bit SID and a 7-bit N, one SID, N and F set describes up to 127 MAC-d PDUs of one size. 25.321 still caps a TTI at 70 MAC-d PDUs in FDD, 45 in 1.28 Mcps TDD and 318 in 3.84 Mcps TDD. The 6-bit TSN counts from 0 to 63 and then wraps. In 1.28 Mcps TDD multi-frequency operation, RRC can extend it to 9 bits. 25.321 also leaves the UE behaviour unspecified if two consecutive SID, N sets describe MAC-d PDUs of the same size, so the Node B sends one set per size run.

• Fixed part of 10 bits : VF, Queue ID and TSN, once per PDU.
• Repeated part of 11 bits : one SID, N and F set per run of equal size MAC-d PDUs, at most 8 sets in a TTI.
• Padding fills the transport block : the transport block size comes from the TFRC, so the MAC-hs SDUs rarely fill it exactly.

Overview on MAC-hs in UE : HSDPA

In the UE the job runs in reverse. The UE has to undo the HARQ, put blocks from all HARQ processes back into queue order, and cut each block into MAC-d PDUs. 25.321 splits that work over four functions, and the figure below shows them from the bottom up.

Following is MAC-hs structure in UE. (R99 UE does not have structure). Overall procedure is as follows :

i) Take in MAC-hs PDUs ( Figure 9.1.4.1 shown above) from lower layer.

ii) Split the MAC-hs PDU into multiple MAC-d PDUs using the informations in the MAC-hs header (Figure 9.1.4.1)

< 25.321 - Figure 4.2.3.3.1 : UE side MAC architecture / MAC-hs details >

• HARQ : it combines retransmissions, generates ACK or NACK, and passes each correctly decoded MAC-hs PDU upward.
• Re-ordering queue distribution : it routes each MAC-hs PDU to the reordering buffer named by its Queue ID.
• Reordering : one entity per Queue ID. It holds a PDU until every PDU with a lower TSN has arrived or has been given up.
• Disassembly : it removes the MAC-hs header and any padding, and delivers the MAC-d PDUs to MAC-d.

Now go back to previous item ("Overview on MAC-hs in UTRAN : HSDPA") and see the MAC-hs PDU structure and try to understand how the structure will change as it flows from the bottom of this block (input) to the top of the block (output).

• The UE side has no scheduler : all decisions are taken in the Node B, and the UE follows the header.
• Reordering is per queue : two queues never block each other.

How does the UE put MAC-hs PDUs back in order?

Six HARQ processes finish in any order. A block that needed two retransmissions arrives after blocks that were sent later but decoded first. RLC expects its PDUs in order, so MAC-hs has to hold the early arrivals until the gap is filled. It also must not wait forever, because a block can be lost for good when the Node B reads a NACK as an ACK.

25.321 clause 11.6.2.3 solves this with the TSN, a receiver window and one timer. The TSN counts 0 to 63 per queue. The UE keeps next_expected_TSN, the first TSN it still waits for, and delivers every PDU with consecutive TSNs from there. The receiver window has the size RECEIVE_WINDOW_SIZE, set by mac-hsWindowSize, and ends at RcvWindow_UpperEdge, the highest TSN received so far.

Timer T1, the re-ordering release timer, handles the lost block. When a PDU arrives with a TSN above next_expected_TSN, the UE starts T1 and stores that TSN as T1_TSN. Only one T1 runs at a time. If the missing PDU arrives first, T1 stops. If T1 expires, the UE gives up on the gap and delivers everything up to T1_TSN and the run after it. With the capture above, T1 is 50 ms and the window is 16, so the UE waits at most 50 ms for one missing block.

A PDU with a TSN outside the window advances the window instead. Any PDU that falls below the new lower edge goes to the disassembly entity at once. On the Node B side, 25.321 tells the transmitter not to retransmit a PDU older than TRANSMIT_WINDOW_SIZE, so that the receiver never confuses two PDUs with the same TSN.

• TSN per queue, 6 bits : the count wraps at 64. MAC-hs-WindowSize goes up to mws32, and later releases add larger values up to mws256 in MAC-hs-WindowSize-r11.
• T1 stops the stall : a missing block delays delivery by at most T1, and RLC recovers the block if it is really lost.
• A MAC-hs reset flushes everything : 25.321 clause 11.6.2.5 empties the soft buffers, delivers and empties the reordering buffers, and restarts the TSN at 0.

What changes when MAC-ehs replaces MAC-hs?

MAC-hs has two limits that become costly at higher rates. One TTI carries only one queue, and every MAC-d PDU must fit whole into the transport block. Release 7 added MAC-ehs to remove both. 25.306 requires MAC-ehs from HS-DSCH Category 13 upward, so every 64QAM, MIMO and multi-cell UE supports it. See the HSDPA Category Table - FDD page for the categories.

25.321 clause 9.1.4 defines the MAC-ehs PDU as one MAC-ehs header and one or more reordering PDUs. Each reordering PDU carries reordering SDUs of one priority queue. So one TTI can now serve several queues. A reordering SDU can be a whole MAC-ehs SDU or a segment of one, so a large RLC PDU can be split across TTIs. The header fields change to match.

• LCH-ID, 4 bits : it names the logical channel of each reordering SDU. The value 1111 marks BCCH or PCCH carried on HS-DSCH.
• TSN, 6 or 14 bits in FDD : one per reordering PDU. RRC can configure the 14-bit TSN field extension.
• SI, 2 bits : it tells whether the first and last reordering SDUs are complete or are segments.
• L, 11 bits : it gives the size of each reordering SDU in octets, so the fixed SID table of MAC-hs is no longer needed.

The price is a longer header per SDU, because each reordering SDU brings its own LCH-ID and L. The UE side also gains a reassembly step for segmented SDUs. Which one runs is a configuration choice, and RRC tells the UE to use MAC-hs or MAC-ehs. 25.331 then selects the HS-DSCH category that sets the soft buffer, as the category page explains.

• Several queues per TTI : MAC-ehs removes the one queue limit of MAC-hs.
• Segmentation in the Node B : RLC PDUs no longer need to fit the transport block whole.
• MAC-ehs from Category 13 : a UE of Category 13 or higher supports it.

Reference

• 25.321 Medium Access Control protocol specification - v19.0.0, clauses 4.2.3.3, 4.2.4.3, 9.1.4, 9.2.2 and 11.6.2
• 25.331 Radio Resource Control - v19.0.1, ASN.1 of MAC-hs-AddReconfQueue, T1-ReleaseTimer, MAC-hs-WindowSize and HARQMemorySize
• 25.306 UE Radio Access capabilities - v19.0.0, Table 5.1a and its notes