Slot Decoding

This page describes how a 1.28 Mcps TDD receiver, the TDD option that TD-SCDMA networks use, gets its data out of one timeslot. The job has two parts. The receiver first needs a channel estimate, which it takes from the midamble in the middle of the burst. Then it despreads the data symbols with its own codes and passes them to the channel decoder. The four steps below list this order, and the sections around them explain where each piece of information comes from. The values are checked against 25.221 v19.0.0, 25.223 v19.0.0 and 25.331 v19.0.1.

The topics on this page are listed below.

What does the receiver get in one slot ?

Let's look at the burst before we decode it. Every normal timeslot of 1.28 Mcps TDD carries the same traffic burst, and the position of each part is fixed. So the receiver knows where the midamble sits before it has decoded anything.

Figure 1 draws the burst of 25.221 subclause 5A.2.2. A data field of 352 chips comes first, then a midamble of 144 chips, a second data field of 352 chips, and a guard period of 16 chips. The total is 864 chips. At 1.28 Mcps, that is 675 microseconds.

Figure 1. Traffic burst of a 1.28 Mcps TDD timeslot. The midamble carries no data and is neither spread nor scrambled, so the receiver can use it as a known training sequence.

The two data fields hold the user data : at SF 16 each field holds 22 QPSK symbols per code, and at SF 1 it holds 352 symbols.
The midamble is the training sequence : 25.221 subclause 5A.2.3 states that the midambles are not subject to channelisation or scrambling.
The guard period separates the slots : its 16 chips absorb timing differences, so the next burst does not overlap this one.

The midambles of different users in the same cell and the same timeslot are cyclic shifts of one basic midamble code of 128 chips. The receiver can therefore estimate the channel of every user in the slot from the one 144-chip field. That is why the midamble comes before the data in the decoding order, even though it sits in the middle of the burst.

One slot is 864 chips : two data fields of 352 chips, a midamble of 144 chips and a guard period of 16 chips.
All users share one basic midamble code : each user, or each code, gets its own cyclic shift of it.
The receiver buffers the whole burst : it needs the midamble in the middle before it can use the data at the start.

Which steps decode a slot ?

Now let's walk through the decoding itself. The receiver must estimate the channel before it can despread, and it must despread before it can decode. The four steps below follow that order.

i) Store the demodulated data of a slot (in real implementation,we store the data a little wider than a slot)

ii) Detect midamble according to the midamble configuration specified in RRC Connection Setup or Radio Bearer Setup

iii) If midamble matches, despread the slot user data using Channelization Code (Channelization code is also specified in RRC Connection Setup or Radio Bearer Setup)

iv) Decode data

Step i buffers more than one slot for a good reason. The UE does not know the exact arrival time of the burst, and multipath spreads the burst in time. A margin on both sides keeps the late paths of the burst inside the stored samples.

Step ii checks the midamble against the midamble shifts that the configuration allows. A match means that the burst is present, and the correlation also gives the channel impulse response for each shift. With the default midamble allocation, each channelisation code is tied to a fixed midamble shift. So a detected shift also tells the receiver which codes are present in the slot.

Step iii undoes the two code layers of the transmitter. 25.223 spreads each symbol with the channelisation code, an OVSF code of SF 1 to 16, and then scrambles the chips with a cell-specific scrambling code of length 16. The receiver applies both codes in reverse, together with the channel estimate from step ii. 3GPP does not specify the receiver algorithm. One common approach in TD-SCDMA, joint detection, uses the channel estimates of all users in the slot to remove their interference at the same time.

Step iv is the reverse of the 25.222 coding chain. The receiver removes the TFCI, SS and TPC bits that the slot format places in the data fields. It then collects the data bits of all slots of the TTI, undoes the interleaving and the rate matching, and decodes the transport blocks.

The midamble comes first : without a channel estimate, the receiver cannot despread the data reliably.
Two codes are removed : the cell-specific scrambling code and the channelisation code of the physical channel.
The slot format tells which bits are data : the TFCI, SS and TPC bits come out before channel decoding.
The receiver algorithm is an implementation choice : 3GPP specifies what is sent, not how the UE detects it.

Where does the receiver get the codes and the midamble ?

Steps ii and iii refer to RRC Connection Setup or Radio Bearer Setup, but the codes come from more than one place. Some codes follow from the cell, and others from the dedicated configuration of the UE. Let's separate them.

The cell gives the scrambling code and the basic midamble code. In 25.223 subclause 8.3, each of the 32 SYNC-DL codes is tied to four scrambling codes and four basic midamble codes. The scrambling code and the basic midamble code of a cell carry the same ID, from 0 to 127. The RRC IE cellParametersID, with values 0 to 127, gives this ID in a dedicated message.

The dedicated message gives the rest, timeslot by timeslot. The IE midambleAllocationMode selects defaultMidamble, commonMidamble or ueSpecificMidamble. The IE midambleConfiguration gives the number of midamble shifts in the slot, and 25.331 defines the actual value as the IE value x 2. The channelisation codes come as a bitmap of SF 16 codes, or as an all-zero bitmap for SF 1 in the downlink.

The slot format page shows such a message. Its DL timeslot 6 carries cellParametersID 127, defaultMidamble, midambleConfiguration 4 and the bitmap 0000000011111111. So the receiver uses the scrambling code and the basic midamble code with ID 127, and it expects up to 8 midamble shifts. It despreads eight SF 16 codes, codes 1 to 8, with the default midamble shift of each code.

cellParametersID picks two codes at once : the scrambling code and the basic midamble code share one ID from 0 to 127.
midambleConfiguration is scaled : the value 4 in a log means 8 midamble shifts.
The allocation mode decides how the shift is found : from the code with defaultMidamble, from the code count with commonMidamble, or from an explicit shift with ueSpecificMidamble.
The codes come per timeslot : each timeslot of a CCTrCH carries its own midamble settings and codes.

Reference

25.221 Physical channels and mapping of transport channels onto physical channels TDD - v19.0.0, subclauses 5A.2.2 Burst format, 5A.2.3 Training sequences for spread bursts and 5A.6 Midamble allocation
25.222 Multiplexing and channel coding TDD - v19.0.0
25.223 Spreading and modulation TDD - v19.0.0, subclause 8.3 Code Allocation
25.331 Radio Resource Control RRC protocol specification - v19.0.1, subclauses 10.3.6.9 Cell parameters Id and 10.3.6.17 Downlink channelisation codes, and the ASN.1 comment on midambleConfiguration