3G/UMTS-TDSCDMA

 

 

 

Midamble/Channelization Code

 

Midamble is a reference signal located in the middle of a slot which is designed to help decoding slot's user data. (For the details of slot structure, refer to the slot structure section in Frame Structure page)

In the 1.28 Mcps option, the midamble is 144 chips long. All the users in one timeslot use cyclic shifts of one basic midamble code, so the receiver can estimate the channel of each user separately. This page shows how RRC tells the UE which midamble to use. It then shows how the midamble follows from the channelisation code when RRC leaves that choice to layer 1.

How does RRC configure the midamble and the codes ?

For each downlink timeslot, the UE needs two things. It needs the channelisation codes that carry its data, and it needs the midamble that lets it estimate the channel for those codes. RRC gives both in the same timeslot description, so let's look at a real message first.

Midamble and possible channelization code for a slot closely related and the midamble configuration and channelization code used for a slot is specified in RRC Connection Setup or Radio Bearer Setup message as shown below.

Decoded RRC message from a tester log, captured. Field values are from a live capture, not from the specification.

            | +-dl-InformationPerRL-List ::= SEQUENCE OF SIZE(1..maxRL[8]) [1] OPTIONAL:Exist
            |   +-DL-InformationPerRL-r4 ::= SEQUENCE [100]
            |     +-modeSpecificInfo ::= CHOICE [tdd]
            |     +-dl-DPCH-InfoPerRL ::= CHOICE [tdd] OPTIONAL:Exist
            |     | +-tdd ::= SEQUENCE [10]
            |     |   +-dl-CCTrChListToEstablish ::= SEQUENCE OF SIZE(1..maxCCTrCH[8]) [1] OPTIONAL:Exist
            |     |   | +-DL-CCTrCh-r4 ::= SEQUENCE [110]
            |     |   |   +-tddOption ::= CHOICE [tdd128]
            |     |   |   | +-tdd128 ::= SEQUENCE [1]
            |     |   |   |   +-dl-CCTrCH-TimeslotsCodes ::= SEQUENCE OPTIONAL:Exist
            |     |   |   |     +-firstIndividualTimeslotInfo ::= SEQUENCE [0]
            |     |   |   |     | +-timeslotNumber ::= INTEGER (0..6) [6]
            |     |   |   |     | +-tfci-Existence ::= BOOLEAN [TRUE]
            |     |   |   |     | +-midambleShiftAndBurstType ::= SEQUENCE
            |     |   |   |     | | +-midambleAllocationMode ::= CHOICE [defaultMidamble]
            |     |   |   |     | | | +-defaultMidamble ::= NULL
            |     |   |   |     | | +-midambleConfiguration ::= INTEGER (1..8) [4]
            |     |   |   |     | +-modulation ::= ENUMERATED [mod-QPSK]
            |     |   |   |     | +-ss-TPC-Symbols ::= ENUMERATED [one]
            |     |   |   |     | +-additionalSS-TPC-Symbols ::= INTEGER OPTIONAL:Omit
            |     |   |   |     +-dl-TS-ChannelisationCodesShort ::= SEQUENCE
            |     |   |   |     | +-codesRepresentation ::= CHOICE [bitmap]
            |     |   |   |     |   +-bitmap ::= BIT STRING  [0000000011111111]
            |     |   |   |     +-moreTimeslots ::= CHOICE [noMore]
            |     |   |   |       +-noMore ::= NULL

Let's read the red lines from the top. The midambleAllocationMode is defaultMidamble, so RRC does not name a midamble shift. Layer 1 picks the midamble from the channelisation code instead. The midambleConfiguration is 4. The ASN.1 comment in 25.331 says that the actual value is the IE value multiplied by 2, so this timeslot uses K = 8 midambles.

The codes come in the dl-TS-ChannelisationCodesShort. Here the codesRepresentation is a bitmap of the 16 SF 16 codes. Its first bit stands for code 16, and its last bit stands for code 1. So the value 0000000011111111 gives this UE the SF 16 codes 1 to 8 in timeslot 6. The next section shows which midamble goes with each of these codes.

The listing below holds the definitions behind the red lines. IndividualTimeslotInfo-LCR-r4 carries the midamble part, and DL-TS-ChannelisationCodesShort carries the codes. The midambleAllocationMode has two more choices. With commonMidamble, one midamble serves all the codes in a downlink timeslot. With ueSpecificMidamble, RRC names the midamble shift directly.

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

IndividualTimeslotInfo-LCR-r4 ::=	SEQUENCE {
	timeslotNumber						TimeslotNumber-LCR-r4,
	tfci-Existence						BOOLEAN,
	midambleShiftAndBurstType			MidambleShiftAndBurstType-LCR-r4,
	modulation							ENUMERATED { mod-QPSK, mod-8PSK },
	ss-TPC-Symbols						ENUMERATED { zero, one, sixteenOverSF },
	additionalSS-TPC-Symbols			INTEGER(1..15)		OPTIONAL
}

MidambleShiftAndBurstType-LCR-r4 ::=	SEQUENCE {
	midambleAllocationMode				CHOICE {
		defaultMidamble						NULL,
		commonMidamble						NULL,
		ueSpecificMidamble					SEQUENCE {
			midambleShift						INTEGER (0..15)
		}
	},
	-- Actual value midambleConfiguration = IE value * 2
	midambleConfiguration				INTEGER (1..8)
}

DL-TS-ChannelisationCodesShort ::=	SEQUENCE {
	codesRepresentation					CHOICE {
		consecutive							SEQUENCE {
			firstChannelisationCode				DL-TS-ChannelisationCode,
			lastChannelisationCode				DL-TS-ChannelisationCode
		},
		bitmap								BIT STRING {
												chCode16-SF16(0),
												chCode15-SF16(1),
												chCode14-SF16(2),
												chCode13-SF16(3),
												chCode12-SF16(4),
												chCode11-SF16(5),
												chCode10-SF16(6),
												chCode9-SF16(7),
												chCode8-SF16(8),
												chCode7-SF16(9),
												chCode6-SF16(10),
												chCode5-SF16(11),
												chCode4-SF16(12),
												chCode3-SF16(13),
												chCode2-SF16(14),
												chCode1-SF16(15)
												} 	(SIZE (16))
	}
}
  • The IE value is half of K : A midambleConfiguration of 4 means K = 8 midambles in the timeslot.
  • Default midamble leaves the choice to layer 1 : RRC names no shift, and the UE derives the midamble from its codes.
  • The bitmap runs from code 16 down to code 1 : The value 0000000011111111 therefore means the SF 16 codes 1 to 8.

How does the default midamble map to the channelisation codes ?

Why tie a midamble to a code at all? The UE assumes a separate channel estimate for each midamble. When layer 1 derives the midamble from the code, RRC saves the signalling, and the receiver still knows which channel estimate belongs to which code.

The Association between Midambles and Channelisation Codes for default midamble allocation is specifed in 25.221 AA.2. The association for special default midamble allocation, which MIMO and MU-MIMO use, is in AA.3.

For example, AA.2 defines Association between Midambles and Channelisation Codes for default midamble allocation which specifies the following cases.

Most commonly used case is K=8. The K value is specified by '2 x midambleConfiguration in RRC message'. For example, if midambleConfiguration in Radio Bearer Setup message is 4, the K value becomes 8. So if the midambleAllocationMode is 'DefaultMidamble', midambleConfiguration is 4, we have to apply the association tree of AA.2.5 Association for K=8 Midambles

  • AA.2.1 Association for K=16 Midambles
  • AA.2.2 Association for K=14 Midambles
  • AA.2.3 Association for K=12 Midambles
  • AA.2.4 Association for K=10 Midambles
  • AA.2.5 Association for K=8 Midambles
  • AA.2.6 Association for K=6 Midambles
  • AA.2.7 Association for K=4 Midambles
  • AA.2.8 Association for K=2 Midambles

The choice of K depends on the delay spread. The midamble shifts are W chips apart, where W is the largest integer not above 128/K, and each window of W chips has to cover the delay spread of the channel. So K = 8 gives 16 chips, and K = 16 gives only 8 chips. In timeslot 0, K is always 8.

Now let's look into howto interpret the association tree with an example. First, you need to understand the meaning of the symbol in the mapping tree. The symbol is represented in the following format.

 

Symbol format m(a) - c(c) with subscript s for midamble code, channelization code and spreading factor

 

  • m(a) : the midamble code, where a is the midamble number from 1 to K.
  • cs(c) : the channelisation code number c at the spreading factor s.

Following is the association tree for AA.2.5 Association for K=8 Midambles. With the symbol interpretation shown above, I think you can make sense out of the tree.

 

25.221 AA.2.5 Association of midambles to channelisation codes for K=8

 

  • The columns are the spreading factors, from SF 1 on the left to SF 16 on the right.
  • At SF 16, two codes share one midamble. The even-numbered code of each pair carries a *, which marks a secondary channelisation code.
  • A node at a lower spreading factor takes the midamble of its upper branch. For example, c4(2) uses m(3), the midamble of c8(3).
  • With K = 8, the 16 SF 16 codes use the 8 midambles m(1) to m(8).

Now apply the tree to the capture. The bitmap gave this UE the SF 16 codes 1 to 8. So the UE sees the four midambles m(1) to m(4). Codes 1, 3, 5 and 7 are primary codes, and codes 2, 4, 6 and 8 are secondary codes that share their midambles.

A few allocation rules keep this scheme working. Higher layers allocate a secondary code only when its primary code is also allocated. The codes of one primary and secondary group never go to different UEs, because the UEs could not tell their channels apart. If a midamble is reserved for the beacon channels, all the codes associated with that midamble stay unused.

  • Two SF 16 codes share one midamble when K = 8 : The pair is one primary code and one secondary code.
  • A code group belongs to one UE : A shared midamble means a shared channel estimate.
  • K is a trade-off : More midambles allow more separate channel estimates, but each one gets a shorter window for the delay spread.

Reference

  • 3GPP TS 25.221 v19.0.0 : Physical channels and mapping of transport channels onto physical channels (TDD)
  • 3GPP TS 25.331 v19.0.1 : Radio Resource Control (RRC); Protocol specification