The concept and functionality of NR Timing Advance is same as the LTE Timing Advance. So I suggest you to read LTE Timing Advance as well if you are not familiar with the concept.

Once the Timing Advance(TA) value is received by UE, the UE should apply the value for UL transmission 6 slot after the reception. That is, if TA is received at slot n, the value is applied from slot n+6 as stated in 38.213-4.2.

The reason the uplink needs any advance at all comes from geometry. UEs sit at different distances from the gNB, so their transmissions take different times to arrive. If every UE started its uplink frame when it saw the downlink frame begin, the far ones would arrive late. The uplink would stop being orthogonal at the receiver.

Timing advance removes that spread. Each UE starts its uplink frame early, by roughly the round trip time to the gNB. A UE 3 km away transmits about 20 microseconds ahead of the downlink it sees. A UE at the cell edge starts earlier still, and both arrive at the gNB together.

I find it easier to think of timing advance as a distance measurement expressed in time. The UE never calculates the value itself. It has no way to measure its own distance, so the gNB measures the arrival time and sends back a correction. Every mechanism on this page therefore runs from the network towards the UE.

The sections that follow cover how the value reaches the UE, and how the integer inside the message becomes a time. They also cover why the first value and later values are read differently, and what happens when alignment is lost.

• UL/DL Timing Relations
• How TimingAdvance information is delivered to UE ?
• How is the timing advance value actually calculated ?
• Why is the RAR value absolute and the MAC CE value relative ?
• What is a Timing Advance Group for ?
• What happens when timeAlignmentTimer expires ?
• Reference

UL/DL Timing Relations

Simply put, Timing Advance is a special command (notification) from gNB to UE that enable UE to adjust its uplink transmission. This kind of UL adjustment applies to PUSCH, PUCCH and SRS.

38.211 Figure 4.3.1-1 draws the relation as two frames on one timeline. The downlink frame is what the UE receives. The uplink frame is what the UE transmits, and it sits earlier by a fixed amount. The arrow between the two frame starts marks that amount, and it is (N_TA + N_TA_offset) x Tc.

Two separate quantities are added there, and they come from different places. N_TA is the UE specific part. The gNB measures it and signals it to this UE alone. N_TA_offset is a constant for the cell, and every UE in that cell applies the same value.

< 38.211 - Figure 4.3.1-1: Uplink-downlink timing relation >

Tc is marked in the figure as 0.509 ns. It is the shortest time unit NR defines, and every timing advance value is counted in multiples of it.

The lower half of the figure gives the two expressions that produce N_TA. The RAR form sets it, and the MAC CE form adjusts what is already there. T_A spans 0 to 3846 in the RAR and only 0 to 63 in the MAC CE. Why the RAR value is absolute and the MAC CE value relative works that difference through.

What is N_TA_offset and why is it there ?

N_TA can reach zero. A UE sitting directly under the antenna needs no advance for propagation. If the total advance were N_TA alone, that UE would transmit its uplink frame at the same instant it receives the downlink frame.

That is a problem in TDD, where one carrier carries both directions. The radio has to switch from receiving to transmitting, and switching is not instant. N_TA_offset buys that time. It shifts the whole uplink earlier for every UE in the cell, whatever the distance.

Coexistence is the second reason. When an NR carrier shares a band with LTE, the NR uplink has to line up with the LTE uplink. The offset is what lines them up. That is why the table splits on whether LTE-NR coexistence applies.

< 38.133 - Table 7.1.2-2 : N_TA_offset >

Two details in that table are worth keeping. FR2 uses a far smaller offset, because its symbols are much shorter and less absolute time covers the same switching gap. And the value is a constant per cell, so it never appears in a MAC CE.

ServingCellConfigCommon below carries the field that selects the offset. n-TimingAdvanceOffset is the only part of this large structure that matters here, and it is marked OPTIONAL. When it is absent, the UE assumes 25600 on an FR1 band.

The enum offers n0, n25600 and n39936, which is three of the four rows above. The FR2 value of 13792 is never signalled, because FR2 has only one value and the UE already knows it. The same offset has to be given for every uplink carrier in one Timing Advance Group. What is a Timing Advance Group for ? explains why that matters.

• The advance has two parts : N_TA is per UE and measured, N_TA_offset is per cell and configured.
• The offset is not about distance : It buys the TDD switching time and aligns NR uplink with LTE uplink.
• FR2 is not signalled : Its offset is fixed at 13792, so the enum covers the FR1 cases only.

ServingCellConfigCommon ::= SEQUENCE {

   physCellId                                   PhysCellId OPTIONAL, -- Cond HOAndServCellAdd,

   downlinkConfigCommon                         DownlinkConfigCommon OPTIONAL,

   uplinkConfigCommon                           UplinkConfigCommon OPTIONAL, -- Need M

   supplementaryUplinkConfig                    UplinkConfigCommon OPTIONAL, -- Need S

   n-TimingAdvanceOffset                        ENUMERATED { n0, n25600, n39936 } OPTIONAL,

   ssb-PositionsInBurst                     CHOICE {

      shortBitmap                               BIT STRING (SIZE (4)),

      mediumBitmap                              BIT STRING (SIZE (8)),

      longBitmap                                BIT STRING (SIZE (64))

   } OPTIONAL, -- Cond AbsFreqSSB

   ssb-periodicityServingCell                   ENUMERATED { ms5, ms10, ms20, ms40,

                                                            ms80, ms160, spare2, spare1 }

   dmrs-TypeA-Position                           ENUMERATED {pos2, pos3},

   lte-CRS-ToMatchAround                         SetupRelease { RateMatchPatternLTE-CRS } ,

   rateMatchPatternToAddModList                  SEQUENCE (SIZE (1..maxNrofRateMatchPatterns))

                                                          OF RateMatchPattern

   rateMatchPatternToReleaseList                 SEQUENCE (SIZE (1..maxNrofRateMatchPatterns))

                                                          OF RateMatchPatternId OPTIONAL,

   subcarrierSpacing                             SubcarrierSpacing    OPTIONAL,

   tdd-UL-DL-ConfigurationCommon                 TDD-UL-DL-ConfigCommon OPTIONAL, -- Cond TDD

   ss-PBCH-BlockPower INTEGER (-60..50),

   ...

}

How TimingAdvance information is delivered to UE ?

A timing advance has to reach the UE at two moments that have almost nothing in common. One message cannot serve both.

The first moment comes before any uplink alignment exists. A MAC CE cannot be used there. A MAC CE travels in a scheduled transport block, and scheduling an uplink transmission is exactly what the missing alignment prevents. Something outside the normal flow has to carry the first value, and that is the Random Access Response.

The second moment is easier. A connection is running, the UE is already close to aligned, and a small correction is all that is needed. A MAC CE fits that, and it is what the network uses from then on. The two cases that follow are in that order.

Case 1 : Through RAR

UE figures out the timing advance value from two different MAC layer command depending on situation. For the first Uplink message after PRACH, UE applies the Timing Advance value that it extracts from RAR (RACH Response). After the initial RACH process, UE would apply the timing Advance value that it extract from Timing Advance MAC CE if it received it.

NOTE : With 12 bit TA value, the max TA value can allow around 2ms delay at 15 Khz SCS, around 1 ms delay at 30 Khz SCS.  ==> This may be large enough to cover the possible delays on terrestrial network, but too short for NTN(Non Terrestrial Network) application.

Case 2 : Through MAC CE

As mentioned above, UE adjust UL transmission timing based on RAR during the initial attach. Once the initial attach is complete, UE adjust UL transmission based on the MAC CE-Timing Advance. The structure of MAC CE Timing Advance is shown in 38.321 Figure 6.1.3.4-1.

< 38.321 - Figure 6.1.3.4-1: Timing Advance Command MAC CE >

You see here the Timing Advance Command Field is 6 bits which mean 64 steps in total. One step is 16 x 64 x Tc divided by 2 raised to the numerology, and Tc is about 0.509 ns. One step is therefore about 521 ns at 15 kHz. The adjustment runs from -31 to +32 steps, or about -16.1 us to +16.7 us at 15 kHz. It halves with every step up in subcarrier spacing. How is the timing advance value actually calculated works this through.

The TAG field in the MAC CE refers to the tag-Id specified in the TAG-Config below.

MAC-CellGroupConfig ::= SEQUENCE {

   drx-Config                   SetupRelease { DRX-Config } OPTIONAL, -- Need M

   schedulingRequestConfig      SchedulingRequestConfig OPTIONAL, -- Need M

   bsr-Config                   BSR-Config OPTIONAL, -- Need M

   tag-Config                   TAG-Config OPTIONAL, -- Need M

   phr-Config                   SetupRelease { PHR-Config } OPTIONAL, -- Need M

   skipUplinkTxDynamic          BOOLEAN,

   ...,

   [[

   csi-Mask-v1530               BOOLEAN OPTIONAL , -- Need M

   dataInactivityTimer-v1530    SetupRelease { DataInactivityTimer } OPTIONAL -- Need

   PCellOnly

   ]]

}

TAG-Config ::= SEQUENCE {

   tag-ToReleaseList            SEQUENCE (SIZE (1..maxNrofTAGs)) OF TAG-Id OPTIONAL, -- Need N

   tag-ToAddModList             SEQUENCE (SIZE (1..maxNrofTAGs)) OF TAG OPTIONAL -- Need N

}

TAG ::= SEQUENCE {

   tag-Id TAG-Id,

   timeAlignmentTimer TimeAlignmentTimer,

   ...

}

TAG-Id ::= INTEGER (0..maxNrofTAGs-1) // maxNrofTAGs = 4

TimeAlignmentTimer ::= ENUMERATED {ms500, ms750, ms1280, ms1920, ms2560, ms5120, ms10240, infinity}

How is the timing advance value actually calculated ?

Both carriers of a timing advance send an integer, and neither sends a time. Turning that integer into a time takes one constant and one multiplier. The multiplier is the part that is easy to miss.

The constant is Tc, the basic time unit of NR. It is defined as 1 divided by 480000 times 4096, which is about 0.509 nanoseconds. Note the unit. Tc is measured in nanoseconds, not microseconds.

The multiplier is 16 times 64, divided by 2 raised to the numerology. One step of timing advance is therefore 16 x 64 x Tc / 2^u, which is about 521 nanoseconds at 15 kHz. A step is not one Tc. It is 1024 of them at the lowest numerology.

That division by 2^u is what ties timing advance to the subcarrier spacing. Every step up in subcarrier spacing halves the step size, and halves the total range with it.

The last column is the useful one for planning. The largest value a RAR can carry corresponds to a round trip. The distance it covers is half of that, at the speed of light. About 300 km at 15 kHz is the well known figure for the maximum NR cell radius. It comes from this table, rather than from anything about the radio.

The MAC CE column tells a different story. At 15 kHz a single command moves the transmit time by at most about 16.7 microseconds. That is a change of about 2.5 km in distance. A UE that moves further than that between commands needs more than one command.

• Tc is nanoseconds, not microseconds : About 0.509 ns, defined as 1 over 480000 times 4096.
• One step is 16 x 64 x Tc / 2^u : About 521 ns at 15 kHz, not one Tc.
• Range halves with every numerology step : The same integer means half the time at twice the subcarrier spacing.
• The RAR range sets the cell radius : About 300 km at 15 kHz, and about 150 km at 30 kHz.
• One MAC CE moves about 2.5 km at 15 kHz : A larger correction needs more than one command.

Why is the RAR value absolute and the MAC CE value relative ?

The page above says the first timing advance comes from the RAR, and every later one from a MAC CE. The two are read in completely different ways, and the difference is not just the field width.

The RAR value is absolute. The UE has just sent a preamble and holds no timing advance at all, so there is nothing to adjust. The 12 bits are read as a value from 0 to 3846, and N_TA is simply that number times the step. It can only be positive, because a UE cannot transmit later than the reference.

The MAC CE value is relative. By the time it arrives the UE already has a roughly correct timing advance. What the network wants is a correction. The 6 bits are read as a value from 0 to 63. Then 31 is subtracted before the step is applied. That gives a signed offset from -31 to +32, which is added to the value the UE already holds.

The offset of 31 is what allows a command that changes nothing. A T_A of exactly 31 subtracts nothing and leaves the timing where it is. That is useful when the network wants to restart the alignment timer without moving the UE.

Figure 1. The two carriers answer different questions. One asks where the UE is, and the other asks how far it has drifted.

• The RAR value replaces : The UE holds nothing at that point, so the 12 bits give the whole value.
• The MAC CE value adjusts : Its 6 bits are a signed offset added to what the UE already has.
• Subtracting 31 makes the offset signed : It runs from -31 to +32 rather than 0 to 63.
• A T_A of 31 changes nothing : The command still restarts timeAlignmentTimer, which is sometimes the only reason it was sent.
• The RAR value is never negative : A UE transmits earlier than the reference, never later.

What is a Timing Advance Group for ?

The ASN.1 above shows TAG-Config, tag-Id and a maximum of four groups. It does not say why more than one would be needed. On a single carrier one is plenty.

Carrier aggregation is what changes that. A UE can be served by several cells at once, and those cells are not always at the same place. A macro cell and a small cell serving one UE can sit hundreds of metres apart. The propagation delay to each is then different. One timing advance cannot be right for both.

A Timing Advance Group is a set of serving cells that share one timing advance. Cells at the same site go in the same group. Cells far enough apart to need different alignment go in different groups. Each group is corrected by its own MAC CE.

The group holding the primary cell is the primary TAG, and the others are secondary TAGs. That distinction matters when the alignment timer expires, because the consequences differ between them.

This is also what the TAG field in the MAC CE is for. Two bits address the four groups, and the field says which group the correction applies to. Without carrier aggregation the field is always 0.

• One group is one timing advance : Every serving cell in a group shares the same uplink alignment.
• Groups exist because sites differ : Cells at different locations have different propagation delays and cannot share a value.
• Up to four groups : maxNrofTAGs is 4, which is why the TAG field needs only two bits.
• The primary group is special : It holds the primary cell. Losing its alignment costs more than losing a secondary group's.
• Without carrier aggregation the field is 0 : A single serving cell needs only one group.

What happens when timeAlignmentTimer expires ?

The ASN.1 above gives timeAlignmentTimer its values, from 500 milliseconds to infinity, without saying what the timer is guarding. It is worth knowing, because expiry is expensive.

Every timing advance command restarts the timer for its group. While the timer runs the UE considers its uplink aligned for that group, and it may transmit. The timer is what makes a timing advance perishable. A UE that hears nothing for long enough has to assume its alignment has drifted out of usefulness.

Expiry for a secondary group is the milder case. The UE stops transmitting on the cells in that group. The rest of the connection continues, because the primary group is still aligned.

Expiry for the primary group is the serious one. The UE treats its whole uplink as unaligned. It flushes the HARQ buffers and releases the PUCCH and SRS configurations. It clears any configured assignments and grants, and stops transmitting. Getting back means random access, which is where the RAR at the top of this page comes in again.

Setting the timer to infinity is allowed and is occasionally right. A fixed wireless terminal does not move, so its alignment does not drift. There is no reason to make it repeat random access. A moving UE with a long timer keeps transmitting on a stale value. That interferes with everyone else in the cell.

• Every command restarts the timer : Even a T_A of 31, which changes nothing, keeps the group alive.
• Secondary group expiry is local : Transmission stops on that group, and the rest of the connection continues.
• Primary group expiry ends the uplink : HARQ buffers flushed, PUCCH and SRS released, grants cleared.
• Recovery is random access : The UE goes back to a preamble and a RAR to get a fresh absolute value.
• Infinity suits a UE that does not move : For anything mobile it means transmitting on a stale alignment.

Reference

[1] 3GPP TS 38.213 - NR; Physical layer procedures for control. Section 4.2 defines the timing advance formulas and when an adjustment applies.

[2] 3GPP TS 38.211 - NR; Physical channels and modulation. Section 4.1 defines Tc, the basic time unit.

[3] 3GPP TS 38.321 - NR; Medium Access Control (MAC) protocol specification. Section 6.1.3.4 defines the Timing Advance Command MAC CE, and section 5.2 covers the maintenance of uplink time alignment.

[4] 3GPP TS 38.331 - NR; Radio Resource Control (RRC) protocol specification. TAG-Config, TAG-Id and TimeAlignmentTimer are defined here.