MAC-ehs is the enhanced MAC-hs that 3GPP introduced in Release 7 for HSPA+ on the HS-DSCH. It keeps the job of MAC-hs, which is scheduling and HARQ in the Node B and reordering in the UE, but it changes how a transport block is built. A MAC-ehs PDU can carry data from several logical channels and several priority queues, and MAC-ehs can cut a MAC-ehs SDU into segments. Let's walk through the UTRAN side first, then the MAC-ehs header with a decoded example, then the UE side. The last section maps the MAC parameters to the RRC IEs that configure them.

• Overview on MAC-ehs in UTRAN : HSPA+
• Overview on MAC-ehs in UE : HSPA+
• Correlation of MAC parameter and RRC Information Elements
• Reference

Overview on MAC-ehs in UTRAN : HSPA+

Now let's look into MAC-ehs which is for HSPA+ (HSPA Evolution). Just by looking at the following figures, it don't see much differences from MAC-hs (figure 4.2.4.3.1). But in reality it has a couple of important difference from MAC-hs.

As in MAC-hs, 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-ehs.

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

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

ii) MAC-d associate each block of MAC-d PDUs of a logical channel with the related LCH-ID, regardless whether one or several logical channels are multiplexed onto one MAC-d flow. (MAC-ehs needs LCH-ID because there is possibility that more than one DTCH or DCCH can be multiplexed into a transport block)

iii) MAC ehs 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 HARQ process in MAC-ehs choose one or more 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.

Step v is where MAC-ehs differs most from MAC-hs. The Priority Queue MUX can take octets from more than one priority queue in the same TTI. The Segmentation block can also cut a MAC-ehs SDU so that the rest of it goes in a later TTI. A MAC-hs PDU carries one priority queue and no segments.

Following is an example of MAC-ehs 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 [criticalExtensions]
            +-criticalExtensions ::= CHOICE [criticalExtensions]
              +-criticalExtensions ::= CHOICE [r7]
                +-r7 ::= SEQUENCE [00]
                  +-radioBearerSetup-r7 ::= SEQUENCE [00100011010000000000111110]
                  | +-ura-Identity ::= BIT STRING OPTIONAL:Omit
                  | +-supportForChangeOfUE-Capability ::= BOOLEAN OPTIONAL:Omit
                  | +-cn-InformationInfo ::= SEQUENCE OPTIONAL:Omit
                  | +-specificationMode ::= CHOICE [complete]
                  | |   +-dl-DeletedTransChInfoList ::= SEQUENCE OF OPTIONAL:Omit
                  | |   +-dl-AddReconfTransChInfoList ::= SEQUENCE OF SIZE(1..maxTrCHpreconf[32]) [2]
                  | |     +-DL-AddReconfTransChInformation-r7 ::= SEQUENCE [0]
                  | |     | +-dl-TransportChannelType ::= CHOICE [hsdsch]
                  | |     | | +-hsdsch ::= NULL
                  | |     | +-tfs-SignallingMode ::= CHOICE [hsdsch]
                  | |     | | +-hsdsch ::= SEQUENCE [11]
                  | |     | |   +-harqInfo ::= SEQUENCE OPTIONAL:Exist
                  | |     | |   | +-numberOfProcesses ::= ENUMERATED [n6]
                  | |     | |   | +-memoryPartitioning ::= CHOICE [implicit]
                  | |     | |   |   +-implicit ::= NULL
                  | |     | |   +-dl-MAC-HeaderType ::= CHOICE [mac-ehs] OPTIONAL:Exist
                  | |     | |     +-mac-ehs ::= SEQUENCE [10]
                  | |     | |       +-mac-ehs-AddReconfQueue-List ::= SEQUENCE OF SIZE(1..maxQueueIDs[8])
                  | |     | |       | +-MAC-ehs-AddReconfReordQ ::= SEQUENCE [0]
                  | |     | |       |   +-mac-ehs-QueueId ::= INTEGER (0..7) [1]
                  | |     | |       |   +-reorderingReleaseTimer ::= ENUMERATED [rt50]
                  | |     | |       |   +-reorderingResetTimer ::= ENUMERATED OPTIONAL:Omit
                  | |     | |       |   +-mac-ehsWindowSize ::= ENUMERATED [mws16]
                  | |     | |       +-dummy ::= SEQUENCE OF OPTIONAL:Omit
                  | |     | +-dch-QualityTarget ::= SEQUENCE OPTIONAL:Omit
                  | |     +-DL-AddReconfTransChInformation-r7 ::= SEQUENCE [1]
                  | +-frequencyInfo ::= SEQUENCE OPTIONAL:Omit
                  | +-multi-frequencyInfo ::= SEQUENCE OPTIONAL:Omit
                  | +-dtx-drx-TimingInfo ::= SEQUENCE OPTIONAL:Omit
                  | +-dtx-drx-Info ::= SEQUENCE OPTIONAL:Omit
                  | +-hs-scch-LessInfo ::= SEQUENCE OPTIONAL:Omit
                  | +-mimoParameters ::= SEQUENCE OPTIONAL:Omit
                  | +-maxAllowedUL-TX-Power ::= INTEGER OPTIONAL:Omit
                  | +-ul-DPCH-Info ::= SEQUENCE [1] OPTIONAL:Exist
                  | +-ul-EDCH-Information ::= SEQUENCE [1] OPTIONAL:Exist
                  | +-dl-HSPDSCH-Information ::= SEQUENCE [11] OPTIONAL:Exist
                  | +-dl-CommonInformation ::= SEQUENCE [110] OPTIONAL:Exist
                  | +-dl-InformationPerRL-List ::= SEQUENCE OF SIZE(1..maxRL[8]) [1] OPTIONAL:Exist
                  | +-mbms-PL-ServiceRestrictInfo ::= ENUMERATED OPTIONAL:Omit
                  +-radioBearerSetup-r7-add-ext ::= BIT STRING OPTIONAL:Omit
                  +-v780NonCriticalExtensions ::= SEQUENCE OPTIONAL:Omit

The red lines are the MAC-ehs part of the HS-DSCH transport channel. The field dl-MAC-HeaderType is set to mac-ehs, so the UE builds a MAC-ehs entity instead of a MAC-hs entity. The message adds one reordering queue, mac-ehs-QueueId 1. Its reorderingReleaseTimer rt50 sets the re-ordering release timer T1 to 50 ms, and mac-ehsWindowSize mws16 sets a receiver window of 16 TSNs. The harqInfo field gives 6 HARQ processes with implicit memory partitioning. The current 25.331 still defines MAC-ehs-AddReconfReordQ with the same four fields, and it adds -r9 and -r11 versions of the queue IEs for later features.

Unlike in MAC-hs, in MAC-ehs you see two separate path under HARQ entity. This indicate it can create two transport blocks simultaneously. In turn, it means that it can serve two HS-DSCH transport channels, one for each cell, as in DC-HSDPA.

Another important difference is that MAC-ehs can multiplex (combine) the data stream from multiple different logical channels and multiple different Priority Queue into a single MAC-ehs PDU. The block labeled as 'Priority Queue MUX' indicate that MAC-ehs can multplex the data from multiple Priority Queue. If you see MAC-esh PDU structure following this figure, it shows a field LCH-ID. It means there can be data coming from multiple different logical channels.

This way.. if you follow each and every component of these figures and try to think of what is the purpose of these component, you will get a lot of information on your own even without reading the description part of the specification.

And also if you do this kind of figure analysis before you read the description part of the specification, you will make much more sense out of the description part of the specification.

25.321 Figure 4.2.4.6-1 below is the UTRAN side MAC-ehs entity on its own. MAC-d flows and MAC-c flows enter Scheduling/Priority handling at the top, and Priority Queue distribution places the data into priority queues. Each queue has its own Segmentation block, and Priority Queue MUX builds the MAC-ehs PDU from them. Under the HARQ entity, the figure draws one TFRC selection block and one HS-DSCH for each cell.

The two HS-DSCH columns follow a rule in 25.321. One MAC-ehs entity may serve HS-DSCH transmission in more than one cell of the same Node B, and there is one HARQ entity per HS-DSCH. MIMO is a different case. With dual stream MIMO, one HS-DSCH carries two transport blocks in the same TTI, and the HARQ entity of that HS-DSCH uses two HARQ processes for them.

25.321 Figure 9.1.4-2 below shows the MAC-ehs PDU. A MAC-ehs header comes first, followed by one or more reordering PDUs and optional padding. The header holds one set of LCH-ID, L, TSN, SI and F fields for each reordering SDU, and the dashed TSN and SI boxes mark the fields that can be absent.

Two notes on these sizes. The TSN is 6 bits by default, but in FDD it grows to 14 bits when RRC configures the TSN field extension for the MAC-ehs entity. 25.331 turns it on for large configurations, for example HS-DSCH reception on three or more cells, or on two cells with MIMO. Also, TSN and SI do not appear for every reordering SDU. If LCH-ID_i maps to the same reordering queue as LCH-ID_i-1, the header carries no TSN_i and no SI_i.

25.321 Table 9.2.2-1 below defines the four SI values. SI describes the first and the last reordering SDU of a reordering PDU. For each of them, it says whether the SDU is a complete MAC-ehs SDU or a segment.

Example 1 : MAC ehs PDU (See Full Data)

Let's read Example 1 field by field. The first three octets, EB BC 04, give a 24-bit header: LCH-ID 1110, L 10111011110 = 1502 octets, TSN 000000, SI 10 and F 0. By 25.321 Table 9.2.2-0, LCH-ID 1110 means logical channel 15. The decimal 14 in the table is only the value of the four bits.

The next two headers, EB BC and EB BC, are 16 bits each. They repeat LCH-ID 1110 with L = 1502 and carry no TSN or SI, because the LCH-ID maps to the same reordering queue. The last header, E4 7B, gives L = 573 octets and F = 1, so the reordering PDU starts right after it. The whole header is 9 octets, and it describes one reordering PDU with four reordering SDUs from logical channel 15. SI 10 says that the first reordering SDU is a complete MAC-ehs SDU. The last one, the 573-octet SDU, is the first segment of a MAC-ehs SDU that continues in a later TTI.

• One PDU can mix logical channels and queues : The LCH-ID in each header set tells the receiver where every reordering SDU belongs.
• MAC-ehs can segment : The SI field tells the receiver whether the first and the last reordering SDU are complete or segments.
• TSN and SI belong to a reordering PDU : Only the first reordering SDU of a queue carries them, so later header sets can be 16 bits long.
• Two HS-DSCH columns mean more than one cell : MIMO uses two HARQ processes on one HS-DSCH instead.

Overview on MAC-ehs in UE : HSPA+

This is UE side of MAC-ehs. Everything is in reverse order of UTRAN side. You have to read from the bottom of this figure to the top.

Reading 25.321 Figure 4.2.3.5-1 from the bottom, the UE handles a MAC-ehs PDU in six steps. Each step undoes one step of the UTRAN side.

• HARQ : There is one HARQ entity per HS-DSCH. It combines retransmissions, generates the ACK or NACK, and passes correctly decoded MAC-ehs PDUs up.
• Disassembly : This removes the MAC-ehs header and any padding.
• Re-ordering queue distribution : This routes each reordering PDU to the right reordering queue, based on the received LCH-ID.
• Reordering : There is one reordering entity per MAC-ehs Queue ID. It delivers data in TSN order, and the re-ordering release timer T1 decides how long it waits for a missing TSN. BCCH and PCCH get no reordering.
• Reassembly : This joins the segments of a MAC-ehs SDU back together, using the SI field.
• LCH-ID Demux : This sends each MAC-ehs SDU to its logical channel, towards MAC-d for dedicated channels or towards MAC-c/sh/m for common ones.

Compare the two figures and you will see the mirror pairs. Segmentation in the Node B matches Reassembly in the UE, and Priority Queue distribution matches Re-ordering queue distribution. The reordering queues are the ones RRC configured in the Radio Bearer Setup capture above. So mac-ehs-QueueId 1 creates one Reordering block with T1 = 50 ms and a window of 16. In case of Multiflow, 25.321 allows two MAC-ehs entities in the UE when upper layers configure them.

• The UE side is the UTRAN side in reverse : Read the UE figure from the bottom to the top.
• Reordering works per queue : The Queue ID from RRC, not the logical channel, defines a reordering entity.
• Segments wait for reordering first : Reassembly sits above Reordering, so the UE joins segments only after they are in TSN order.

Correlation of MAC parameter and RRC Information Elements

For the details for this, you have to refer to 25.321 8.3.2 Parameters and look up the meaning of each parameters in 25.331. But I would pick up some major parameters which is mainly used in  RRC Connection Request, RRC Connection Setup, RRC Connection Setup Complete, Radio Bearer Setup and summarize them in this section. You can you this section as a kind of dictionary when you are analyzing RRC messages for troubleshooting the protocol stack.

25.321 v19.0.0 clause 8.3.2 lists two more TrCH parameters that the tables above do not cover. They are the TSN field extension for the MAC-ehs entity, FDD only, and the TSN field extension for the MAC-i/is entity. The UE derives the MAC-ehs one from its HS-DSCH configuration by the rules of 25.331 clause 8.5.60, so no single field of the Radio Bearer Setup carries it.

A row with an empty path is a parameter for which this page gives no RRC path. Also check the two periodicity rows against the IE names. The IE periodicityOfSchedInfo-Grant is the period for Scheduling Information with a grant, and periodicityOfSchedInfo-NoGrant is the period without one.

• 25.321 clause 8.3.2 is the index : It lists the MAC parameters, and 25.331 defines each of them as an RRC IE.
• Most MAC-ehs and E-DCH parameters come in one message : Radio Bearer Setup carries the queue, HARQ, E-DPDCH and DTX-DRX settings together.
• Some MAC settings are derived, not signalled : The TSN field extension for MAC-ehs follows from the multi-cell and MIMO configuration.

Reference

• 3GPP TS 25.321 v19.0.0 : Medium Access Control (MAC) protocol specification
• 3GPP TS 25.331 v19.0.1 : Radio Resource Control (RRC); Protocol specification