As you may know, 'Duplex' means a communication system that allows bi-directional communication (both transmission and reception). It means it is not Reciever only nor Transmission only communication. Then what 'Half' mean here ? 'It allows 'Duplex communication' but with some limitation. What kind of limitation does it mean ? In this case, the limitation is 'it does not allow bidirectional communication at the same timeslot', meaning 'it does not allow simultaneous bidirectional communication'. In other words, it can do transmission only at one time and do reception only at another time. (Walkie-Talkie with the push-to-talk button would be one of the typical example of Half Duplex).

• Why LTE uses half duplex FDD
• What the scheduler must avoid
• Type A and Type B guard periods
• How the network learns a UE is half duplex
• Reference

Why LTE uses half duplex FDD

Half duplex FDD is not a separate air interface. It runs on frame structure type 1, the same grid that full duplex FDD uses. Clause 4.1 of 36.211 says so directly. What changes is one restriction on the UE, which cannot transmit and receive at the same time. This section asks what that restriction buys.

What does it mean by Half-Duplex in LTE FDD case ? It is originally designed for Full Duplex and probably more easier to operate in Full-Duplex mode. Actually FDD Half-Duplex was discussed even from the initial LTE design, but hasn't gotten much attraction for a long time. However, recently as IoT /M2M /MTC /Category 0 /Category M/LTE-M over LTE becomes a hot topic, FDD Half-Duplex is coming back to surface. This kind of application (IoT/M2M/MTC) does not require high throughput but require very efficient (low) energy consumption. With Half Duplex, UE (terminal device) may save a lot of energy by turning off Transmitter or Reciever when it is not used.

The saving is in the radio rather than in the processor. A full duplex FDD UE receives while its own transmitter is running, a few tens of megahertz away on the same antenna. Holding the two apart takes filtering, and the filtering has to be sharp. A half duplex UE never meets that case. Its receiver never works beside its own transmitter, because the two never run together.

The cost is downlink throughput. Every uplink subframe takes part of the downlink subframe in front of it, and under Type B it takes a whole subframe on each side. A device with little to send loses little. A device that needs a steady downlink loses a great deal, and that is why half duplex FDD saw so little use for years.

• The frame structure does not change : half duplex FDD runs on frame structure type 1, the same one full duplex FDD runs on.
• The restriction is on the UE alone : 36.211 clause 4.1 states it of the UE, and asks nothing of the eNB.
• The saving is in the receiver : it never works beside a running transmitter, so the front end need not reject one from the other.
• The price is downlink subframes : every uplink subframe takes part or all of the downlink either side of it.

What the scheduler must avoid

The scheduler carries the restriction, because the UE cannot report it back once an assignment has been sent. An eNB can grant uplink and downlink in the same subframe, and the result is a collision. The UE resolves that collision by dropping something. The paragraph below lists the combinations to keep apart.

With point of eNB perspective, there are couple of things to be considered to implement Half-Duplex meaning there is no Downlink/Uplink simultaneous transmission. It should be careful about PDSCH/PUSCH scheduling so that there is NO such a case as follows.

• PDSCH + PUCCH (HARQ ACK/NACK, CSI Report etc)
• PDSCH + PUSCH
• PUSCH + PHICH (HARQ ACK/NACK)

36.213 does not forbid these combinations. It states what the UE does when one of them happens, which is a different thing. Clause 8.0 covers the uplink shared channel. A PUSCH can collide with a PDSCH that an MPDCCH scheduled, and the UE then drops the PUSCH, provided the PUSCH had no MPDCCH of its own. Clause 10.1.1 covers the control channel, and drops a PUCCH format 2 that collides with a repeated PDSCH reception under two stated conditions.

Both clauses use one phrase that changes the arithmetic: including half-duplex guard subframe. A scheduler has to keep more clear than the uplink subframe on its own. The footprint is that subframe together with the guard subframes the UE builds around it. Under Type B it comes to three subframes for one subframe of data.

• The specification does not ban the collision : 36.213 names the transmission the UE drops, and leaves the avoidance to the scheduler.
• The guard subframes belong to the uplink : both drop rules count a PUSCH or a PUCCH as including the half-duplex guard subframe.
• One uplink subframe can block three : under Type B the subframe either side of it is part of the same footprint.
• A dropped PUSCH is not free : the data goes out again a few subframes later, and the cell spends the capacity twice.

Type A and Type B guard periods

36.211 gives a UE two ways to make room for the switch, and they differ only in how much downlink each one gives up. The clause is quoted below, and Release 19 has not changed a word of it. The names Type A and Type B carry no meaning beyond the two lists that follow them.

Also eNB has to consider following two modes of Half-Duplex mode defined in 36.211 (ts_136211v120700p.pdf) 6.2.5 Guard period for half-duplex FDD operation as described below.

For type A half-duplex FDD operation, a guard period is created by the UE by

• not receiving the last part of a downlink subframe immediately preceding an uplink subframe from the same UE.

NOTE : Type A Half-Duplex is defined in Rel 8, but not much used in real deployment (as far as I know, not used at all)

For type B half-duplex FDD operation, guard periods, each referred to as a half-duplex guard subframe, are created by the UE by

• not receiving a downlink subframe immediately preceding an uplink subframe from the same UE, and
• not receiving a downlink subframe immediately following an uplink subframe from the same UE.

NOTE : Type B Half-Duplex is a kind of newly defined mode for Category 0 or Cat-M. Since Category 0 is rarely adopted in real deployment, major application of LTE-M would be Cat-M.

This mode of operation would be illustrated as below. As you see in this illustration, in Type A Guard period is very short (a fraction of one subframe) right before Uplink transmission, but in Type B Guard period takes a full subframe both before and after the start and end of uplink transmission. This wide guard period would make hardware design easier and simpler.

In both panels the UE lifeline runs down the left and the eNB down the right, with three subframes stacked from top to bottom. Green arrows point left, from eNB to UE, and carry downlink. The one blue arrow points right and carries the uplink in subframe n. Shading marks the guard period.

< Types of FDD Half-Duplex >

• The shaded band in Type A sits at the tail of subframe n-1 : it takes a slice of one downlink subframe, and nothing at all follows the uplink.
• The shaded bands in Type B cover subframe n-1 and subframe n+1 whole : two full downlink subframes go, one on each side of the uplink.
• The green arrow still crosses both Type B guard subframes : the eNB keeps transmitting and the UE stops receiving, which is how 36.211 words it.
• Subframe n is unshaded in both panels : neither type gives anything up in the uplink subframe itself.

The drawing raises a question the clause does not answer. Type A takes a guard before the uplink and nothing after it, and clause 8.1 of the same specification explains why. A UE starts its uplink frame ahead of the downlink frame by the timing advance. An uplink subframe therefore finishes before the downlink subframe of the same number finishes at the UE. The UE already has time to switch back to reception, and it has no time to switch away from it. Only the subframe in front can supply that.

The clause puts no figure on the last part of that subframe. The UE creates as much of it as its own retuning needs. That is the trade-off between the two types. Type A is cheap in downlink and demanding of the hardware, while Type B is expensive in downlink and needs no precise timing from the hardware.

• Type A gives up part of one subframe : only the tail of the downlink subframe in front of the uplink.
• Type B gives up two whole subframes : the one before and the one after, each of them called a half-duplex guard subframe.
• Only the Type B guard has a name : 36.211 names the half-duplex guard subframe, and 36.213 then uses that name in its drop rules.
• The asymmetry in Type A comes from the timing advance : the uplink already ends early, so only the switch away from reception needs room of its own.

How the network learns a UE is half duplex

The scheduler needs two facts before it can leave any guard subframe clear. It has to know whether this UE is half duplex at all, and which of the two types the UE uses. The UE supplies both. One arrives as a capability bit, and the other follows from a number the UE sends for other reasons.

The declaration is made band by band

Half duplex is a property of a band on this UE, not a property of the UE. A device can be full duplex on one band and half duplex on another. 36.331 therefore gives every entry in the supported band list a boolean of its own.

Following is based on 36.331 v19.3.0 (Release 19)

SupportedBandEUTRA ::=              SEQUENCE {
    bandEUTRA                           FreqBandIndicator,
    halfDuplex                          BOOLEAN
}

36.331 gives the meaning in one line. If halfDuplex is set to true, only half duplex operation is supported for the band, and otherwise full duplex operation is supported. 36.306 adds the one limit on it. For TDD the half duplex indication does not apply, which follows from TDD never transmitting and receiving at once.

The type follows from the UE category

The UE never signals the type on its own. Clause 4.2.6 of 36.306 makes it a parameter set by the UE category, alongside buffer sizes and transport block limits. The choice therefore arrives with a number the UE sends anyway.

Tables 4.1-5, 4.1A-5 and 4.1C-5 of 36.306 v19.3.0, gathered into one place

The table gives two readings. Every category that predates low cost devices takes Type A, which is the note above stated as a rule. Every category built for a low cost device takes Type B, and those are the categories deployed in half duplex today.

• The declaration is per band : halfDuplex is one boolean inside each supported band entry.
• TDD never uses it : 36.306 says the half duplex indication does not apply to a TDD band.
• The type is never signalled on its own : 36.306 clause 4.2.6 derives it from the category the UE already reports.
• Every low cost category takes Type B : DL Category 0, M1 and M2 and Category NB1 and NB2, while Category 1 to 12 take Type A.

Reference

[1] LTE Radio Access Part V: TDD, half-duplex FDD (YouTube)

[2] 36.211 : 3GPP - E-UTRA; Physical channels and modulation, v19.3.0. Clause 4.1 gives frame structure type 1 and the half duplex restriction, clause 6.2.5 the two guard period types, and clause 8.1 the uplink to downlink frame timing.

[3] 36.213 : 3GPP - E-UTRA; Physical layer procedures, v19.4.0. Clause 8.0 and clause 10.1.1 give the drop rules that count a half-duplex guard subframe as part of the uplink transmission.

[4] 36.306 : 3GPP - E-UTRA; User Equipment radio access capabilities, v19.3.0. Clause 4.2.6 defines the half-duplex FDD operation type, Tables 4.1-5, 4.1A-5 and 4.1C-5 map it onto the UE category, and clause 4.3.5.1 covers the per band indication.

[5] 36.331 : 3GPP - E-UTRA; Radio Resource Control, v19.3.0. SupportedBandEUTRA carries the halfDuplex boolean, and the field description gives its meaning.