Following is overal MAC layer operation between UTRAN and UE in HSUPA. Use this one as a framework and dig into the details as much as possible refering to other pages in this site.

In HSUPA the scheduler sits in the Node B, but the data sits in the UE. So the MAC layer runs a loop between the two. The UE reports what it has, the Node B grants power, and the UE fills the grant with data. The table below lists one pass of that loop, and the sections after it explain each step with the 25.321 terms.

Followings are the topics to be covered in this page.

• What is the overall sequence ?
• How does the UE tell the Node B what it needs ?
• How does the Node B change the Serving Grant ?
• How does the UE turn the grant into a transport block ?
• Reference

What is the overall sequence ?

Each row of the table below is one event in the loop. Read the Direction column first, because it shows who acts. Three rows run only in the network, two run only in the UE, and three cross the air interface.

The rows map to 25.321 entities as follows.

• Scheduling Information : an 18 bit report at the end of a MAC-e or MAC-i PDU. It is the only row the UE starts by itself.
• Serving Grant Value : the E-DCH scheduler in the Node B decides it. 25.321 leaves the algorithm to the implementation, so the uplink interference budget is a vendor choice.
• Serving Grant, T/P Ratio : the grant is a maximum E-DPDCH to DPCCH power ratio, that is a traffic to pilot ratio. It is not a bit rate. It arrives on the E-AGCH as an absolute value or on the E-RGCH as a step.
• Dedicated Grant set by RNC : 25.321 calls this a non-scheduled grant. RRC gives it per MAC-d flow as "Max MAC-e PDU contents size", and the Node B does not control it.
• Specific HARQ process : the process is fixed by the CFN and the subframe number, as the HARQ page explains.
• Ack/Nack via E-HICH : every cell in the E-DCH active set sends one, not only the serving cell.
• Demux and Reorder : demultiplexing runs in MAC-e in the Node B. Reordering runs in MAC-es in the SRNC, because data from several Node Bs meets there in soft handover.

So the table is a single pass, but the loop never stops while the UE has data. The next sections follow the loop from the UE report to the transport block.

How does the UE tell the Node B what it needs ?

The Node B cannot see the UE buffer. So the UE has two ways to report it. The Scheduling Information carries numbers, and the happy bit on the E-DPCCH carries a one-bit opinion about the current grant.

The Scheduling Information has four fields, and 25.321 clause 9.2.5.3.2 defines them.

• HLID, 4 bits : the highest priority logical channel that has data.
• TEBS, 5 bits : the total E-DCH buffer status. The index points to a byte range, from 0 bytes at index 0 up to more than 37642 bytes at index 31.
• HLBS, 4 bits : the buffer of the HLID channel, as a percentage of the TEBS range.
• UPH, 5 bits : the UE power headroom, that is the maximum UE power relative to the DPCCH code power.

The SI is not sent at every TTI. 25.321 clause 11.8.1.6 triggers it in two situations. When the Serving Grant is "Zero_Grant", the UE sends an SI as soon as data arrives, or when data with a higher priority arrives. When the UE has a grant, it sends an SI if the grant becomes too small for even one PDU. It also sends one after an E-DCH serving cell change to a cell outside the old serving radio link set.

RRC can also add periodic reports. The timer T_SING runs while the UE has no grant, and T_SIG runs while it has one. Both come from "Periodicity for Scheduling Info" in the E-DPDCH Info IE, with values from every E-DCH TTI up to 1000 ms.

The SI of a UE without a grant needs room in a transport block. For this case, E-TFC selection assumes a non-scheduled grant for the SI. So the UE can send an SI alone, and the E-TFCI is then 0. The HARQ cycle of an SI that is sent alone ends only with an ACK from the serving radio link set or at the transmission limit. The reason is that only the serving Node B schedules the UE.

The happy bit is different. It is sent on the E-DPCCH of every E-DCH transmission, and it says "unhappy" when the UE could send more data with the power it has. The E-DPCCH page gives the three conditions.

• SI gives numbers, the happy bit gives a direction : the scheduler uses both.
• Event triggers depend on the grant state : without a grant, new data triggers an SI. With a grant, a too small grant triggers one.
• A UE with no grant can still send an SI : E-TFC selection treats it like non-scheduled data.

How does the Node B change the Serving Grant ?

The Serving Grant is a state variable in the UE, and the Node B moves it with two channels. The E-AGCH sets it to an absolute value, and the E-RGCH moves it one step up or down. Let's see why HSUPA needs both.

The E-AGCH is a shared channel, so one E-AGCH serves many UEs. The CRC is masked with the E-RNTI of the target UE. The message has 6 bits. A 5-bit Absolute Grant Value points into 25.212 Table 16B, and a 1-bit scope says "Per HARQ process" or "All HARQ processes". Two values are special. "ZERO_GRANT" stops scheduled data, and "INACTIVE" deactivates HARQ processes.

The E-RGCH is a dedicated signature on a code that several UEs share. The serving radio link set sends UP, DOWN or HOLD. The UE then moves the grant from the power ratio that it actually used in the previous TTI of the same HARQ process. The step is one index in the Scheduling Grant table. The "3-Index-Step Threshold" and "2-Index-Step Threshold" of RRC allow a bigger UP step at low grants.

A cell outside the serving radio link set can also send an E-RGCH. It can only say DOWN or HOLD. A DOWN from such a cell lowers the grant and caps it until the Non_Serving_RG_Timer expires. This is how a neighbour Node B protects itself against uplink interference from a UE it does not schedule.

The E-AGCH can also address a UE with a secondary E-RNTI, which is shared by a group of UEs. The Node B then gives one grant to the whole group, and a grant to the primary E-RNTI takes priority for one UE.

• E-AGCH for big changes, E-RGCH for small ones : the absolute grant costs more downlink resource, so the Node B uses it less often.
• Relative grants follow the power actually used : a UE that did not use its grant gets a smaller step base.
• Only the serving cell can raise a grant : non-serving cells can only lower it.

How does the UE turn the grant into a transport block ?

A grant is a power ratio, but the HARQ process needs a transport block size. E-TFC selection in 25.321 clause 11.8.1.4 converts one into the other at every new transmission. The answer also depends on the data, on the UE power and on the RRC limits.

First the UE takes the Serving Grant and turns it into a maximum number of scheduled bits. It uses the reference E-TFCIs and their power offsets from the E-DPDCH Info IE, and it extrapolates or interpolates between them. Next it adds the non-scheduled grants of the MAC-d flows that have data. The HARQ process also matters here, because RRC may allow scheduled or non-scheduled data only on some processes with the 2 ms TTI.

Then the UE checks power. An E-TFC whose power would push the UE beyond its maximum power is blocked. The E-DCH minimum set E-TFCI is an exception, because the UE may always use that E-TFC. The UE also stays within "Maximum channelisation codes", which limits the E-DPDCH configuration from one SF256 code up to 2xSF2 plus 2xSF4.

Now the UE fills the transport block. MAC-d PDUs from the logical channels are taken in priority order. They go into MAC-es PDUs, and the MAC-es PDUs go into one MAC-e PDU. The HARQ profile of the highest priority MAC-d flow sets the power offset and the maximum number of transmissions. Then the chosen HARQ process sends the block, and the E-TFCI goes on the E-DPCCH.

So the "Transport Block Size" row of the table is a chain of limits. The smallest limit wins, whether it is the grant, the data, the power or the codes.

• Grant to bits : the reference E-TFCIs translate a power ratio into a maximum payload.
• Power can override the grant : a large grant is useless at the cell edge, and the UPH in the SI tells the Node B this.
• Non-scheduled data does not wait for the Node B : it is limited only by its RRC value.

Reference

[1] 3GPP TS 25.321 v19.0.0 - clause 9.2.5, E-DCH control information, clause 11.8.1.3, Serving Grant Update, clause 11.8.1.4, E-TFC selection, and clause 11.8.1.6, Scheduling Information reporting

[2] 3GPP TS 25.212 v19.0.0 - clause 4.10, coding for E-AGCH, and Table 16B

[3] 3GPP TS 25.331 v19.0.1 - clause 10.3.6.99, E-DPDCH Info, and the non-scheduled transmission grant info