BL/CE(LTE-M1) operates in 1.4 Mhz frequency block called Narrowband. The location of the Narrowband may vary in each subframe. It means that UE should need to tune to a difference frequency at every subframe. As you may guess, every freuqency retuning would take a certain period of time. It implies that we would need a certain period of guard period when transitions from one subframe to next subframe. Guard Period is a period during which no transmission and no reception occurs.

This guard period varies depending on whether it is downlink or uplink, and varies with different situations within downlink or uplink.

Followings are the topics to be covered in this page.

• Why a BL UE needs a guard period
• Uplink Guard Period
• Downlink Guard Period
• What the clauses added after Release 13
• Reference

Why a BL UE needs a guard period

A guard period is not a feature. It is the cost of a decision taken elsewhere, and the decision is that a BL UE carries one narrow receiver instead of a wide one. That receiver is tuned to six resource blocks, and moving it to a different six takes real time in the radio.

Retuning a synthesiser is not instant. The UE has to change the local oscillator, let it settle, and only then can it trust what it receives or sends. During that settling the UE can do neither, so the specification takes the symbols away from it rather than letting it corrupt them.

That gives four directions a UE can be retuning in, and 36.211 covers them in two clauses rather than one. The uplink case is Tx to Tx and lives in 36.211 5.2.5. The downlink cases are Rx to Rx and Tx to Rx and live in 36.211 6.2.8, which also covers the Rx to Tx case inside a TDD special subframe.

Figure 1. The four retuning directions. The length of the guard is the same in every one of them, and only the question of which subframe gives up the symbols changes.

One parameter sets the length for all four. 36.211 takes the value from ce-RetuningSymbols when the network sends it, and uses 2 symbols when it does not. 36.331 allows the values n0 and n1 for that field, so a network that knows its UEs retune quickly can cut the guard to one symbol or remove it.

The phrase the specification uses is worth noticing: a guard period of at most that many symbols. Where a symbol is already empty for another reason, it counts towards the guard, and nothing further is taken. The shortened PUCCH case below is exactly that situation.

• The guard exists because the UE has one narrow receiver : a wideband UE that never retunes between subframes never needs one.
• Same narrowband, no guard : every rule in 36.211 5.2.5 and 6.2.8 is conditioned on the two narrowbands having different centre frequencies.
• ce-RetuningSymbols sets the length everywhere : one parameter covers uplink and downlink, and the default when it is absent is 2 symbols.
• At most is the operative phrase : a symbol already left empty counts towards the guard, which is why two cases below take fewer symbols than the others.

Uplink Guard Period

The uplink rules are in 36.211 5.2.5, and they are the most detailed of the set. The answer depends on what the UE was sending before the retune and on what it sends after. That is why the five cases below are five different answers to one question.

Type of uplink guard periods varies depending on the characteristics of data carried by a subframe and next subframe as described below (Following description is based on 36.211-5.2.5).

Case 1 : PUSCH in First Subframe and PUSCH in Second Subframe

Case 2 : PUCCH in First Subframe and PUCCH in Second Subframe

The guard is split across the subframe boundary. One symbol comes from the end of subframe N and one from the start of subframe N+1, which is the two symbol default drawn in full.

• The two rows are consecutive subframes : subframe N along the bottom and subframe N+1 along the top, each drawn as two slots of seven symbols.
• The shaded symbols are the guard : the last symbol of subframe N and symbol 0 of subframe N+1, so the UE transmits neither.
• Splitting it is what 36.211 5.2.5 asks for here : when the retune is PUSCH to PUSCH or PUCCH to PUCCH, a two symbol guard takes one symbol from each side.
• A one symbol guard would take only the first of the two : the rule names the last symbol of the first subframe on its own when the length is one.

Case 3 : Shortened PUCCH in First Subframe and PUSCH in Second Subframe

Only one symbol is shaded, and that is the point. A shortened PUCCH format has already given up the last symbol of subframe N, so it counts towards the guard and only the symbol in subframe N+1 has to be added.

• Subframe N looks untouched and is not : a shortened PUCCH format does not use its last symbol anyway. The diagram marks only what the guard takes in addition.
• 36.211 5.2.5 still names two symbols : the rule is the last symbol of the first subframe plus the first symbol of the second. The shortened format has already supplied the first of those.
• This is what at most means in practice : the guard is never longer than the configured length, and an already empty symbol reduces what is taken.

Case 4 : Normal PUCCH in First Subframe and PUSCH in Second Subframe

A normal PUCCH format uses every symbol it has, so the guard cannot come out of subframe N. Both symbols are taken from the start of the PUSCH that follows.

• The whole guard sits in subframe N+1 : symbols 0 and 1 of the second subframe are shaded, and the first subframe is untouched.
• The PUCCH keeps its symbols, the PUSCH gives some up : 36.211 5.2.5 sends the guard to the second subframe whenever the first carries a normal PUCCH format.
• Compare this with the case above it : the same retune with a shortened PUCCH costs one symbol of PUSCH instead of two, because the shortened format contributed one.

Case 5 : Normal PUSCH in First Subframe and PUCCH in Second Subframe

With PUCCH arriving second, the guard moves entirely into the first subframe. The PUSCH gives up its last two symbols so that the PUCCH starts intact.

• The whole guard sits in subframe N : the last two symbols of the PUSCH are shaded, and subframe N+1 is untouched.
• It is the mirror of the normal PUCCH case : whichever side carries PUSCH is the side that gives up symbols.
• Every diagram here is drawn for a two symbol guard : that is the value 36.211 uses when ce-RetuningSymbols is absent, so these are the default pictures rather than the only ones.

Reading the five cases together, one rule sits underneath all of them. Wherever a PUSCH is involved, the PUSCH is the side that loses symbols, and a normal PUCCH format never does. The split across the boundary only appears when both sides carry the same kind of channel and neither has a claim on the other.

36.211 5.2.5 read as one table. The first three rows split the guard across the boundary; the last two take it entirely from one side.

• PUSCH is the side that gives up symbols : in both rows where one channel carries the whole guard, the symbols come out of the PUSCH.
• A normal PUCCH format never loses a symbol : it has no spare one to give, so the guard is pushed into the neighbouring subframe.
• The shortened PUCCH row looks like the PUSCH rows : it can give up its last symbol, so 36.211 treats it the same way.
• None of this applies without a retune : all five rows assume the two narrowbands have different centre frequencies.

Downlink Guard Period

The downlink answer is shorter than the uplink one, and the reason is that there is nothing to negotiate. The UE is receiving rather than transmitting, so no channel of its own has to be protected, and the guard always comes out of the same place.

Downlink guard period is required as in the following condition (refer to 36.211-6.2.8).

• First Downlink Narrowband Center frequency and the second narrowband center frequency is different
• In TDD, the first uplink narrowband center frequency and the second downlink center frequeny is different

The guard period is defined as follows

The downlink guard is always taken from the second subframe. The UE simply does not receive the opening symbols in the new narrowband, and the subframe it is leaving is never touched.

• The shaded symbols are in subframe N+1 : symbols 0 and 1 of the second subframe, which is the two symbol default again.
• The UE stops receiving, it does not stop anything being sent : 36.211 6.2.8 puts the guard on the UE side, and the network keeps transmitting into those symbols.
• There is only one downlink picture because there is only one rule : both conditions listed above lead to the same action in the second narrowband.
• This is the clean contrast with the uplink : uplink has five cases because the UE has channels of its own to protect, and downlink has one because it does not.

What the clauses added after Release 13

The reference at the foot of this page is 36.211 V13.2.0, and the two clauses it points at have both grown since. Neither clause moved and neither rule was withdrawn, so every diagram above still shows what a Release 13 UE does. What changed is how many situations the same rules now have to cover.

The clearest sign is the title. In Release 13 both clauses were about narrowband retuning, and both are now called guard period for narrowband and wideband retuning. That word arrived with the wider channel of Release 14, and it changes what the rules are measuring rather than what they say.

The guard length itself was fixed in Release 13. The field that changes it, ce-RetuningSymbols, arrived in Release 14. Before that a BL UE always gave up two symbols, and a network had no way to ask for fewer. A UE that retunes quickly can now be told to use one symbol, or none at all.

Release 15 added a subtler case. With a flexible starting PRB the allocation no longer has to sit inside one narrowband. 36.211 therefore had to say what the UE is retuning between when the old boundaries no longer apply. It answers with a tuning narrowband, defined one way for CE mode A and another for CE mode B.

Compared against 36.211 v19.3.0, with each release dated by the suffix of the field that configures it in 36.331. Every row widens the set of situations the rules cover rather than changing the rules themselves.

None of this makes the diagrams wrong. They show a two symbol guard between two narrowbands, which is what a Release 13 network produces and still the most common case. The thing to establish before counting symbols in a log is whether ce-RetuningSymbols was sent, and whether the UE is retuning between narrowbands or between widebands.

• The clause numbers are unchanged : 36.211 5.2.5 and 6.2.8 are the same clauses, so the page's references still point at the right text.
• Two symbols was not a default in Release 13, it was the only value : ce-RetuningSymbols arrived in Release 14 and turned it into a default.
• Wideband retuning reuses the narrowband rules : at a 5 MHz maximum bandwidth the same symbol level rules apply, with widebands in place of narrowbands.
• A flexible starting PRB needed a new unit : the tuning narrowband exists so the rules still have two centre frequencies to compare.

Reference

The clauses the cases on this page come from, and the versions they were checked against.

[1] 3GPP TS 36.211 V13.2.0 (2016-06)

[2] 3GPP TS 36.211 v19.3.0 - clause 5.2.5 and clause 6.2.8, guard period for narrowband and wideband retuning

[3] 3GPP TS 36.331 v19.3.0 - the ce-RetuningSymbols field and its value range