HSUPA - UL Grant/E-AGCH,E-RGCH

In HSDPA case, data source is NodeB and destination is UE. Since Network (the data source) is the master and it has all the authorities for data transmission scheduling, it doesn't need any Grant ("approval for data transmission"). Basically Network can transmit the data anytime it is ready. But in HSUPA case the situation is different. The data source is UE and Network is data sinc(reciever), but UE is not the master of the scheduling. Network is scheduling master all the time. It means that in HSUPA, the transmitter (UE in this case) has to have "approval for transmission" from the data reciever (Network in this case). The "Approval for transmission" is called "UL Grant", and overall mechanism for UL Grant and data transmission in HSUPA goes as follows.

Let's keep one idea in mind while reading this page. An HSUPA grant is a power budget, not a data rate. The network tells the UE how much E-DPDCH power it may use relative to its DPCCH, and the UE turns that power into a transport block size through E-TFC selection. Two downlink channels carry the grant. The E-AGCH sets it directly, and the E-RGCH moves it up or down from its current value.

UL Grant Overview

Before looking at each channel, let's see where the grant sits in the HSUPA loop. The UE tells the network about its buffer and power situation on the uplink. The Node B scheduler answers with a grant on the downlink, and the UE then sends E-DPDCH data within that grant.

As you see, there are two different types of UL Grant called "Absolute Grant" carried by AGCH(Absolute Grant Channel) and "Relative Grant" carried by RGCH(Relative Grant Channel).

Absolute Grant can be transmitted by the network in any TTI. Each one is addressed to a specific UE, or to a group of UEs sharing one E-RNTI, through the E-RNTI specific CRC.

Relative Grant can be transmitted in the same TTI as the E-HICH. The E-RGCH and the E-HICH share one channelisation code, and different signature sequences separate them.

The sequence diagram below shows the channels between the SS, the test equipment acting as the network, and the UE. AGCH and RGCH run in the downlink and carry the grant. E-DPCCH and E-DPDCH run in the uplink and carry the control information and the data. HICH closes the loop with the ACK or NACK for each E-DPDCH transmission. The Happy Bit on the E-DPCCH is the UE's one-bit answer to the grant: it says whether the UE could use more.

HSUPA UL grant sequence with AGCH, RGCH, E-DPCCH, E-DPDCH and HICH between SS and UE

Following is some key notes for UL Grant

AGCH can be transmitted by only Serving Cell
Serving Cell can transmit any of RGCH value (UP, HOLD, DOWN)
Non-Serving Cell can send only RGCH and cannot transmit AGCH.
Non-Serving Cell can send only DOWN and HOLD value of RGCH (No UP value)

Read the callouts in the diagram as a test equipment view. They say that AGCH is sent in every TTI with a value common to all UEs, and that RGCH is not sent when HICH is sent. In a live network, the Node B sends an Absolute Grant to a UE whenever its scheduler decides to set a new grant for that UE. The UE checks the E-AGCH in every TTI for a CRC that matches its own E-RNTI. The Details of RGCH section shows how the E-RGCH and the E-HICH share one code.

A grant is a power ratio : Both AG and RG change the E-DPDCH to DPCCH power ratio that the UE may use. The data rate follows from E-TFC selection.
AG sets the grant, RG adjusts it : The E-AGCH gives an absolute value from a 32-entry table. The E-RGCH moves the current grant up or down.
Only the serving side can raise the grant : A non-serving cell can only hold or lower the grant. This protects that cell from uplink overload caused by UEs it does not schedule.

Details of AGCH

The E-AGCH is a shared downlink channel with a fixed rate of 30 kbps and SF 256. Every UE that uses it listens to the same channel, so each message has to say which UE it is for. That address is hidden in the CRC rather than sent as a separate field.

Followings are the type of information carried by AGCH.

UE Address : UE-ID(E-RNTI).

This can be primary or secondary E-RNTI
Primary and secondary identifier is conveyed through ID-specific CRC
If secondary identifier is used, the scope is always set to all HARQ processes
These address can be set to be common to multiple UEs

Grant Value : Traffic-to-Pilot Ratio in 5 bits (0~31). Value 0 means "deactivation of HARQ process".
HARQ Process Control : Indicator to Deactivate/Activate HARQ Process

When the Grant Value is 0 (deactivated process), no HARQ process should be scheduled
When any value other than 0, a particular or all HARQ process should be activated

Scope : Used for HARQ process control in 1 bits.

Indicate if an HARQ process is for one specific HARQ process or for all HARQ process
For 10 ms TTI, the scope is always set to be "All processes"
Can be used as an indicator to switch between primary and secondary grant

Over the air, the message is only 6 bits long. It holds a 5-bit Absolute Grant Value and a 1-bit Absolute Grant Scope. So HARQ Process Control is not a separate field. The Node B controls HARQ processes by sending the value INACTIVE together with the scope. The 6 bits get a 16-bit CRC that is masked with the 16-bit E-RNTI. After rate 1/3 convolutional coding and puncturing to 60 bits, the message fills one 2 ms E-AGCH subframe. For a UE with a 10 ms TTI, the same 60 bits are repeated in all five subframes of one 10 ms E-AGCH frame.

The value for the Absolute Grant can be 0 ~ 31. Except the value 0~1. All the remaining value is mapped to a certain level of power value that UE can use for data transmission. (At the beginning, I was so confused about this value. When we say "Grant", I expected each of the value would mean "Yes, you can transmit the data and this is the data rate you can transmit". But what I see from the following Absolute Grant table is "Here is the amount of power you can use for the data transmission".

Then you may ask "Is there any predefined algorithm running on UE side which maps this power value to the real data rate ?".

Excellent question ! Yes, there is. UE is performing a special E-TFCI selection algorithm based on how much power it can use for data transmission and this Grant value determines "how much power is available for the data transmission".

Following is Absolute Grant table from 25.212 v9.4.0.

In 25.212 Table 16B, each index from 2 to 31 maps to a maximum E-DPDCH to DPCCH power ratio written as (x/15)². The highest entries carry an extra multiplier of 2, 4 or 6. Index 4, (15/15)², therefore gives the E-DPDCH the same power as the DPCCH. Index 1 is ZERO_GRANT and index 0 is INACTIVE, and 25.321 defines what both of them mean.

25.212 Table 16B Mapping of Absolute Grant Value

Table 16B still reads the same in 25.212 v19.0.0, but a second table now stands next to it. Table 16B.1 is an alternative mapping that reaches (377/15)²x4 at index 31. RRC selects it through the "BetaEd gain E-AGCH table selection" field in the UL 16QAM settings. Without that field, the indices on the E-AGCH refer to Table 16B.

The address sits in the CRC : The UE finds its grants by checking the E-RNTI masked CRC. A group of UEs can therefore share one secondary E-RNTI and receive the same grant.
INACTIVE is a control command, not a power value : With the primary E-RNTI, INACTIVE deactivates one HARQ process or all of them. When a secondary E-RNTI is configured, INACTIVE with the All HARQ processes scope switches the UE to its stored secondary grant.
A 10 ms TTI always uses All HARQ processes : The Per HARQ process scope is valid in CELL_DCH only with the 2 ms TTI.

Details of RGCH

Now let's look into the Relative Grant. Relative Grant carries three different status (Command), UP, HOLD, DOWN and the meaning of this command is defined in 25.212 as follows.

25.212 Table 17 Mapping of RG value

25.212 Table 17 says three things. A cell in the serving E-DCH RLS can send UP as +1, HOLD as 0 or DOWN as -1. A cell in any other radio link can send only HOLD or DOWN, so it can never raise the grant. And HOLD is the value 0, which means the Node B transmits nothing on the E-RGCH for that command.

Physically, the E-RGCH is a dedicated downlink channel with SF 128. In each slot, the Node B sends the RG value multiplied by a 40-bit orthogonal signature sequence, and higher layers give the signature index. A serving RLS cell sends one command over 3 slots for a 2 ms TTI UE, or over 12 slots for a 10 ms TTI UE. A non-serving cell always uses 15 slots, which is one 10 ms radio frame.

The E-HICH that carries the ACK/NACK has the same slot structure. In each cell, the E-RGCH and the E-HICH assigned to a UE use the same channelisation code. The two channels differ only in their signature sequence, so the UE can receive a Relative Grant and an ACK/NACK in the same TTI.

HOLD costs no power : The RG value 0 means no transmission. A serving cell that has nothing to change sends nothing.
A non-serving DOWN is an overload signal : It comes from a cell that does not schedule the UE. It tells the UE that this cell receives too much uplink interference.
E-RGCH and E-HICH share a code : One SF 128 code per cell serves both, and the signature sequence tells them apart.

How does the UE turn AG and RG into a Serving Grant ?

The UE never uses an AG or an RG directly. It keeps one state variable, Serving_Grant, and 25.321 updates it at every TTI boundary. The update takes the AG, the serving RG and the non-serving RGs that apply to that TTI. The order of the checks decides which command wins when several arrive together.

Let's walk through the baseline procedure for a UE in CELL_DCH. First, the UE checks for an Absolute Grant. A primary AG with any value other than INACTIVE replaces the Serving_Grant. The new value is never below the lowest configured serving grant value, unless the AG is ZERO_GRANT. A secondary AG updates Stored_Secondary_Grant. It changes the Serving_Grant directly only while the UE already follows the secondary grant. The stored value becomes active when the primary E-RNTI sends INACTIVE with the All HARQ processes scope.

Each primary AG also restarts AG_Timer. The UE applies a serving RG only when no AG arrived in the TTI and AG_Timer has expired. It also needs an active HARQ process, a Serving_Grant other than Zero_Grant, and a scheduled transmission in the previous TTI of that HARQ process. So an RG cannot move a fresh AG for a short time.

The size of an RG step comes from the Scheduling Grant table in 25.321, which has 38 entries with index 0 to 37. On UP, the UE looks up the table index for the power ratio of the previous transmission on that HARQ process. It then moves up by 3, 2 or 1 index. The "3-index-step threshold" and the "2-index-step threshold" from RRC decide which step applies, so a UE with a small grant climbs faster. On DOWN, the UE moves one index down.

The UE handles a non-serving DOWN last, and this command limits the grant from above. The UE lowers its Serving_Grant by one index, stores the result as Maximum_Serving_Grant and starts Non_Serving_RG_Timer. Until that timer expires, the Serving_Grant stays at or below that maximum.

An AG wins over a serving RG in the same TTI : The UE evaluates the serving RG only when no Absolute Grant was received.
Small grants rise faster : The 3-index and 2-index step thresholds let a low grant climb several table entries per UP command.
A non-serving DOWN sets a ceiling for a while : The Maximum_Serving_Grant holds until Non_Serving_RG_Timer expires.

Reference

3GPP TS 25.211 v19.0.0 : Physical channels and mapping of transport channels onto physical channels (FDD)
3GPP TS 25.212 v19.0.0 : Multiplexing and channel coding (FDD)
3GPP TS 25.213 v19.0.0 : Spreading and modulation (FDD)
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