HSUPA in TD-SCDMA is the E-DCH of 1.28 Mcps TDD, and it gives the UE uplink resources in two ways. In scheduled transmission, the Node B scheduler decides in each TTI which timeslots, which code and how much power the UE may use. In non-scheduled transmission, RRC gives the UE a fixed allocation in advance, and the UE uses it without asking. Let's compare the two message flows first. Then we'll look at the configuration behind each of them.
- What is the difference between scheduled and non-scheduled HSUPA ?
- How does the UE ask for a scheduled grant ?
- How does RRC configure a non-scheduled grant ?
- Reference
What is the difference between scheduled and non-scheduled HSUPA ?
Both modes carry E-DCH data on the E-PUCH and get HARQ feedback on the E-HICH. What differs is who decides the resource, and when. Let's put the two message flows side by side, because the difference is visible in only two arrows.
The diagram below shows scheduled HSUPA on the left and non-scheduled HSUPA on the right. Both flows start with a Radio Bearer Setup from the network. On the left, the UE then sends an E-RUCCH, which is a random access burst. The network answers on the E-AGCH with physical resource information. The loop of E-PUCH data and E-HICH Ack/Nack starts only after that grant. On the right, the same loop starts directly after the Radio Bearer Setup.
- E-RUCCH : the E-DCH Random Access Uplink Control Channel. The UE uses it to send its Scheduling Information and its E-RNTI when it has no E-PUCH resource.
- E-AGCH : the E-DCH Absolute Grant Channel. The Node B uses it to give the UE a power grant, a code, a set of timeslots and the E-HICH to listen to.
- E-PUCH : the E-DCH Physical Uplink Channel. It carries the E-DCH transport block and the E-UCCH control information.
- E-HICH : the E-DCH HARQ Acknowledgement Indicator Channel. It carries the Ack or Nack for each E-PUCH transmission.
- The loop arrow : the E-PUCH and E-HICH exchange repeats in every TTI in which the UE has a resource.
The two modes also use different HARQ processes. In TDD, HARQ processes 0 to 3 serve scheduled transmission, and HARQ processes 4 to 7 serve non-scheduled transmission. The physical layer does not send the top bit of the process number. The Node B can infer it from the type of resource that the UE used.
So when does a network use each mode? RRC gives non-scheduled grants to individual MAC-d flows in order to reduce the transmission delay. This fits a flow that needs a low delay and a predictable rate. Scheduled transmission fits bursty packet data, because the Node B can move the E-DCH timeslots from one UE to another in every TTI.
The difference is the grant, not the data channel : Both modes send data on the E-PUCH and receive the Ack/Nack on the E-HICH.A scheduled UE has to ask first : Without a grant, the UE reports its buffer on the E-RUCCH and waits for an E-AGCH.A non-scheduled UE already has its resource : RRC gives the timeslots, the code, the power and the repetition pattern in advance.The HARQ process tells the two apart : Processes 0 to 3 are scheduled, and processes 4 to 7 are non-scheduled.
How does the UE ask for a scheduled grant ?
A UE in scheduled mode starts without any E-PUCH resource, so it cannot put its request inside E-DCH data. It needs another uplink path to the Node B. In 1.28 Mcps TDD, that path is a random access on the E-RUCCH, and RRC configures it in advance.
The diagram below repeats the scheduled flow on the left and expands the E-RUCCH step on the right. The step has two parts. First the UE sends a SYNC-UL code in the UpPTS. Then it sends the E-RUCCH burst itself. The note at the top says that this part is almost the same as a normal PRACH burst. The tree under the bursts is the e-RUCCH-Info from the Radio Bearer Setup. The green box configures the UpPTS part, and the red box configures the E-RUCCH burst.
- sync-UL-InfoForE-RUCCH : prxUpPCHdes 25 is a desired UpPCH receive power of -95 dBm, because the value 0 stands for -120 dBm. The powerRampStep 1 raises each new SYNC-UL attempt by 1 dB. The value tr8 of max-SYNC-UL-Transmissions allows 8 SYNC-UL transmissions in one power ramping sequence. The mmax 32 is the maximum number of synchronisation attempts.
- e-RUCCH-Sync-UL-Codes-Bitmap 11111111 : Each bit stands for one of the 8 SYNC-UL codes of the cell. So all 8 codes are available for the E-RUCCH access.
- prach-information : The E-RUCCH burst uses timeslot 1 and the channelisation code cc8-3, which is an SF 8 code. Its midamble is a default midamble with midambleConfiguration 4, which means 8 midambles in the timeslot.
Why does the E-RUCCH look like a PRACH? The UE may not have uplink synchronisation, so it cannot send a normal burst in a traffic timeslot. It first sends a SYNC-UL code in the UpPTS. The Node B answers on the FPACH with a timing and power correction. The E-RUCCH burst then goes out on the same random access physical resources as the PRACH, with spreading codes based on the PRACH codes.
The request itself is small. The E-RUCCH carries 23 bits of Scheduling Information and the 16-bit E-RNTI. The Scheduling Information holds five fields. TEBS, the Total E-DCH Buffer Status, gives the amount of data waiting. HLID and HLBS name the highest priority logical channel and its buffer. UPH, the UE Power Headroom, and SNPL, the Serving and Neighbour cell Pathloss, describe the power situation. The Node B uses all of them to choose the power grant and the physical resources.
The Node B answers on the E-AGCH. The grant carries a power value, an OVSF code, a timeslot bitmap and the E-HICH to use for the Ack/Nack. The UL Grant page explains these fields. RRC also sets T-RUCCH and N-RUCCH, which control repeated E-RUCCH attempts. When the UE reaches Mmax synchronisation attempts, MAC reports an E-RUCCH failure to RRC.
The listing below holds the three IEs that the tree in the diagram shows. E-RUCCH-Info has a tdd128 branch, and its last two fields point to the other two definitions.
Following is based on
E-RUCCH-Info ::= SEQUENCE {
modeSpecificInfo CHOICE {
tdd384-tdd768 SEQUENCE {
e-RUCCH-ConstantValue INTEGER (-35..10),
e-RUCCH-PersistenceScalingFactor PersistenceScalingFactor,
t-RUCCH ENUMERATED {ms40, ms80, ms120, ms160, ms200,
ms240, ms280, ms320} OPTIONAL,
e-RUCCH-TS-Number INTEGER (0..14) OPTIONAL,
e-RUCCH-Midamble ENUMERATED {direct, direct-Inverted} OPTIONAL,
t-adv ENUMERATED { sec1, sec2, sec4, sec8, sec16,
sec32, sec128, infinity } OPTIONAL,
t-SCHED ENUMERATED { zero, ms40, ms80, ms160, ms250,
sec1, sec2, sec4 } OPTIONAL,
modeSpecificInfo CHOICE {
tdd384 CHOICE {
sF16 SEQUENCE (SIZE (1..8)) OF SF16Codes,
sF8 SEQUENCE (SIZE (1..8)) OF SF8Codes
},
tdd768 CHOICE {
sF32 SEQUENCE (SIZE (1..16)) OF SF32Codes,
sF816 SEQUENCE (SIZE (1..16)) OF SF16Codes2
}
}
},
tdd128 SEQUENCE {
t-RUCCH ENUMERATED { ms20, ms40, ms60, ms80, ms120,
ms160, ms200, ms240, ms280, ms320,
ms400, ms500, ms600, ms800, ms1000,
ms2000 } OPTIONAL,
n-RUCCH INTEGER (0..7) OPTIONAL,
t-WAIT ENUMERATED { everyEDCHTTI, ms40, ms80, ms160,
ms320, ms640, ms1000, ms2000 } OPTIONAL,
t-SI ENUMERATED { everyEDCHTTI, ms20, ms40, ms60, ms80,
ms160, ms200 } OPTIONAL,
extendedEstimationWindow INTEGER (2..5) OPTIONAL,
e-RUCCH-AccessServiceClass E-RUCCH-AccessServiceClass OPTIONAL,
e-RUCCH-PersistenceScalingFactor PersistenceScalingFactorList OPTIONAL,
sync-UL-InfoForE-RUCCH SYNC-UL-InfoForE-RUCCH OPTIONAL,
prach-information PRACH-Information-LCR-List OPTIONAL
}
}
}
SYNC-UL-InfoForE-RUCCH ::= SEQUENCE {
prxUpPCHdes INTEGER (0..62) OPTIONAL,
powerRampStep INTEGER (0..3) OPTIONAL,
max-SYNC-UL-Transmissions ENUMERATED { tr1, tr2, tr4, tr8 } OPTIONAL,
e-RUCCH-Sync-UL-Codes-Bitmap Sync-UL-Codes-Bitmap,
mmax INTEGER(1..32)
}
PRACH-Information-LCR ::= SEQUENCE {
timeslot TimeslotNumber-PRACH-LCR-r4,
prach-ChanCodes-list-LCR PRACH-ChanCodes-List-LCR,
midambleShiftAndBurstType MidambleShiftAndBurstType-LCR-r4,
fpach-Info FPACH-Info-r4 OPTIONAL
}
E-RUCCH is a PRACH-like access : The UE sends SYNC-UL on the UpPCH, waits for the FPACH, and then sends the E-RUCCH burst on PRACH resources.The request is 39 bits : It holds 23 bits of Scheduling Information and the 16-bit E-RNTI.RRC sets up the access in advance : sync-UL-InfoForE-RUCCH and prach-information give the codes, the timeslot and the power ramping.
How does RRC configure a non-scheduled grant ?
A non-scheduled UE uses no E-RUCCH and no E-AGCH. So everything that a grant would carry has to arrive earlier in an RRC message. In the flow above, that message is the Radio Bearer Setup. The grant sits in the IE non-ScheduledTransGrantInfo, inside UL-EDCH-Information.
Following is based on
Non-ScheduledTransGrantInfoTDD-r9 ::= CHOICE {
tdd384-768 SEQUENCE {
timeslotResourceRelatedInfo BIT STRING (SIZE (13)),
powerResourceRelatedInfo INTEGER (1..32),
activationTime ActivationTime,
repetitionPeriodAndLength RepetitionPeriodAndLength OPTIONAL,
codeResourceInfo UL-TS-ChannelisationCode
},
tdd128 SEQUENCE {
n-E-UCCH INTEGER (1..8) OPTIONAL,
n-E-HICH INTEGER (4..15) OPTIONAL,
timeslotResourceRelatedInfo BIT STRING (SIZE (5)),
powerResourceRelatedInfo INTEGER (1..32),
activationTime ActivationTime,
sfnNum INTEGER (0..1),
repetitionPeriodAndLength RepetitionPeriodAndLength OPTIONAL,
codeResourceInfo UL-TS-ChannelisationCode,
e-HICH-Info SEQUENCE {
timeslotNumber TimeslotNumber-LCR-r4,
channelisation-Code HS-ChannelisationCode-LCR,
midambleAllocationMode CHOICE {
defaultMidamble NULL,
ueSpecificMidamble INTEGER (0..15)
},
-- Actual value midambleConfiguration = IE value * 2
midambleConfiguration INTEGER (1..8),
signatureSequenceGroupIndex INTEGER (0..19)
},
t-SI-nst ENUMERATED {
everyEDCHTTI, ms20, ms40, ms60, ms80, ms160,
ms200 } OPTIONAL
}
}
Let's read the tdd128 branch field by field. The timeslotResourceRelatedInfo is a 5-bit bitmap for TS1 to TS5, the same form as the timeslot field on the E-AGCH. The codeResourceInfo gives the OVSF code. The powerResourceRelatedInfo is an index that sets the maximum E-PUCH resource the UE may use. So the three parts of a scheduled grant, power, code and timeslots, are all here as fixed values.
The time pattern is fixed as well. The activationTime and the sfnNum give the radio frame and the subframe where the allocation starts. The repetitionPeriodAndLength says how often the allocation comes back, from every TTI up to every 64th TTI. Without that field, the allocation is continuous. The e-HICH-Info tells the UE where to look for the Ack/Nack, because no E-AGCH will carry an E-HICH indicator. The n-E-UCCH sets the number of E-UCCH instances in each TTI. The n-E-HICH sets the minimum number of slots between the start of the last active slot of a TTI and the start of the Ack/Nack on the E-HICH.
The buffer report also works differently. A UE with only non-scheduled transmission never starts the E-RUCCH procedure. It puts its Scheduling Information inside the E-PUCH data instead. This happens when the transport block has room, or when the timer t-SI-nst expires. The r9 version of the IE carries t-SI-nst inside the tdd128 branch. The older version carries it in a separate extension IE.
Power control changes too. For scheduled transmission, the UE takes TPC commands for the E-PUCH from the E-AGCH and from the E-HICH. For non-scheduled transmission, the TPC commands come on the E-HICH only.
All grant fields come from RRC : The timeslot bitmap, the code, the power index, the start time and the repetition are fixed in the Radio Bearer Setup.The E-HICH is configured, not signalled : e-HICH-Info replaces the E-HICH indicator that a scheduled UE reads on the E-AGCH.A non-scheduled-only UE never uses the E-RUCCH : Its Scheduling Information travels inside the E-PUCH data.The E-HICH also carries the TPC : Non-scheduled E-PUCH power control uses TPC commands on the E-HICH only.
Reference
- 3GPP TS 25.221 v19.0.0 : Physical channels and mapping of transport channels onto physical channels (TDD)
- 3GPP TS 25.224 v19.0.0 : Physical layer procedures (TDD)
- 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