3G/UMTS

 

 

 

HSUPA E-DPCCH

 

The E-DPCCH is the small uplink control channel that the UE sends with every E-DPDCH transmission. The Node B must decode it first, because without it the Node B knows neither the transport block size nor the redundancy version of the data. Each field also has a second job for the scheduler or for HARQ, and this page covers both jobs.

Followings are the topics to be covered in this page.

How are the 10 E-DPCCH bits structured ?

As DPCCH carries the information required to decode DPDCH in R99, E-DPCCH carries the information required to decode E-DPDCH in HSUPA. E-DPCCH carries 10 bits structured as follows.

 

E-TFCI (7 bits)

RSN (2 bits)

Happy bit (1 bit)

 

The table shows the fields, but not the order on the air. 25.212 clause 4.9.3 multiplexes them into x1 to x10 in this way.

  • x1 : the happy bit.
  • x2 and x3 : the RSN, with the MSB in x3.
  • x4 to x10 : the E-TFCI, with the MSB in x10.

The 10 bits are then coded with a sub-code of the second order Reed-Muller code into 30 bits, z0 to z29. These 30 bits fill one 2 ms E-DPCCH subframe, which is 3 slots of 10 bits at SF256, or 15 kbps. With the 10 ms TTI, the same 30 bits are sent in all five subframes of the radio frame. The E-DPCCH has no CRC of its own.

The E-DPCCH power is set relative to the DPCCH. RRC gives the E-DPCCH/DPCCH power offset as an integer from 0 to 8, and 25.213 clause 4.2.1.3 turns it into a gain factor. Also, the E-DPCCH is never sent in a slot without the DPCCH.

  • Happy bit first, E-TFCI last : this is the multiplexing order of 25.212, which is the reverse of the table above.
  • 30 coded bits per subframe : the 10 ms TTI repeats them five times, which gives more energy per bit.
  • One E-DPCCH per radio link : it goes with the E-DPDCH, and uplink MIMO adds a second one, the S-E-DPCCH.

E-TFCI

It stands for "E-DCH Transport Format Combination Indicator" and indicates the transport format being transmitted simultaneously on E-DPDCHs. The E-TFCI tells the receiver the transport block size coded on the E-DPDCH. From this value, the reciever (Node B) can figure out how many E-DPDCHs are transmitted in parallel and what spreading factor is used.

The 7 bits give 128 values. Each value is an index into an E-DCH transport block size table in 25.321 Annex B. There are separate tables for the 2 ms TTI and for the 10 ms TTI. RRC selects table 0 or table 1 with the E-TFCI table index in the E-DPDCH Info IE. A UE that runs 16QAM adds 2 to that index, and a UE in 64QAM mode uses table 4 of the 2 ms TTI.

The physical channel configuration follows from the transport block size. 25.212 clause 4.8.4.1 picks the smallest set of E-DPDCHs and spreading factors that keeps the puncturing within limits. The set goes from one SF256 code up to 2xSF2 plus 2xSF4. So the E-TFCI is enough, and the E-DPCCH needs no separate code field.

Two cases give the E-TFCI a special meaning in practice.

  • E-TFCI 0 with a Scheduling Information alone : 25.321 Figure 9.1.5-2b uses E-TFCI 0 when the MAC-e PDU carries only the SI.
  • E-TFCI above E-TFCIec,boost : the UE boosts the E-DPCCH power, so that the E-DPCCH gives the Node B an enhanced phase reference for large transport blocks. The value comes from e-TFCI-Boost in RRC, and the default of 127 switches boosting off.

The E-TFCI is the first field to check in a log. A wrong E-TFCI table on one side gives a wrong transport block size, and every CRC on the E-DPDCH then fails.

RSN

The RSN tells the Node B which transmission of a HARQ process it is receiving. The Node B needs this for two reasons. It selects the redundancy version, and it protects its soft buffer from a wrong combination.

It stands for Retransmission Sequence Number meaning as follows :

  • 00 : New Transmission
  • 01 : First Retransmission
  • 10 : Second Retransmission
  • 11 : Higher than Second Retransmission

The UE sets the RSN in 25.321 clause 11.8.1.1.2. It starts at 0 for new data, adds 1 at each retransmission and stops at 3. So from the third retransmission on, the RSN stays 3. The Node B still knows the exact transmission number, because the retransmissions of a process come at fixed times.

The RSN also picks the redundancy version when RRC configures "rvtable". 25.212 Table 16 maps RSN 0, 1 and 2 to fixed RV indices, and RSN 3 to an RV that follows the TTI number. With "rv0" the RV index is always 0, and the RSN only counts. The HARQ page shows the full table.

25.212 clause 4.9.2.2 also describes the soft buffer protection. The Node B can flush the soft buffer of a HARQ process when it cannot decode more than 3 consecutive E-DPCCH transmissions on that process. It can also flush it when the last received RSN does not fit the current one, for example an RSN of 0 in the middle of a retransmission.

  • RSN counts transmissions : 0 for new data, then 1, 2 and 3, and it saturates at 3.
  • RSN drives the RV : only with "rvtable", and together with the code rate.
  • An RSN of 0 means new data : the Node B must not combine it with the old soft buffer.

Happy bit

The Scheduling Information gives the Node B exact buffer numbers, but the UE sends it only on a trigger or a timer. The happy bit is sent with every E-DCH transmission, so the scheduler gets a quick signal between two reports.

It carries the information whether the UE is content with the current data rate (Grant) allocated by the network or not.

  • 1 : indicate "Happy".  It means that the Grant is large enough to transmit all the data within a certain time frame.
  • 0 : indicate "Unhappy". It means that the Grant is NOT large enough to transmit all the data within a certain time frame.

25.321 clause 11.8.1.5 makes the "certain time frame" exact. The UE sets the bit to "unhappy" only when three conditions are met together.

  • The grant is used up : the UE sends as much scheduled data as the Serving Grant allows.
  • Power is left : the UE has enough power for a higher rate. It checks this with an E-TFC that is at least one RLC PDU larger, or 32 bits larger with MAC-i/is.
  • The buffer is too large : at the current grant, the TEBS would take more than Happy_Bit_Delay_Condition ms to send.

In all other cases the bit is "happy". So a UE at the cell edge with no power left reports "happy", even with a full buffer, because a bigger grant would not help it. The UE also never sends an E-DCH transmission only to carry the happy bit.

RRC sets Happy_Bit_Delay_Condition in the E-DPCCH Info IE, together with the power offset and the boosting parameters. The tile below shows the current version.

Following is based on 25.331 v19.0.1 (Release 19)

E-DPCCH-Info-r7 ::=                 SEQUENCE {
    e-DPCCH-DPCCH-PowerOffset           E-DPCCH-DPCCH-PowerOffset,
    happyBit-DelayCondition             HappyBit-DelayCondition,
    e-TFC-Boost-Info                    E-TFC-Boost-Info-r7                 OPTIONAL,
    e-DPDCH-PowerInterpolation          E-DPDCH-PowerInterpolation          OPTIONAL
}

E-DPCCH-DPCCH-PowerOffset ::=       INTEGER (0..8)

HappyBit-DelayCondition ::=         ENUMERATED {
                                        ms2, ms10, ms20, ms50, ms100, ms200, ms500, ms1000 }

E-TFC-Boost-Info-r7 ::=         SEQUENCE {
    e-TFCI-Boost                        INTEGER (0..127),
    delta-T2TP                          INTEGER (0..6)                      OPTIONAL
}

E-DPDCH-PowerInterpolation ::=      BOOLEAN

The delay condition runs from 2 ms to 1000 ms. A short value makes the UE "unhappy" with a small buffer, so the scheduler sees more requests. The e-TFCI-Boost and delta-T2TP fields are the boosting parameters of the E-TFCI section above.

  • Unhappy needs all three conditions : grant used up, power left and buffer too large.
  • Happy does not mean an empty buffer : a power limited UE is always happy.
  • The delay condition sets the sensitivity : it comes from RRC, in the E-DPCCH Info IE.

Reference

[1] 3GPP TS 25.212 v19.0.0 - clause 4.8.4.1, E-DPDCH configuration, and clause 4.9, coding for E-DPCCH

[2] 3GPP TS 25.211 v19.0.0 - clause 5.2.1.3, E-DPCCH and E-DPDCH, and Table 5C

[3] 3GPP TS 25.213 v19.0.0 - clause 4.2.1.3, E-DPCCH and E-DPDCH gain factors

[4] 3GPP TS 25.321 v19.0.0 - clause 11.8.1.1.2, HARQ process, clause 11.8.1.5, Happy Bit Setting, and Annex B

[5] 3GPP TS 25.331 v19.0.1 - clause 10.3.6.98, E-DPCCH Info, clause 10.3.6.99, E-DPDCH Info, and the ASN.1 of clause 11.3