How LTE Stuff Works?

LTE: Sounding Reference Signal Procedure

The Sounding Reference Signal (SRS) is a reference signal transmitted by the UE in the uplink direction which is used by the eNodeB to estimate the uplink channel quality over a wider bandwidth. The eNodeB may use this information for uplink frequency selective scheduling.

The eNodeB can also use SRS for uplink timing estimation as part of timing alignment procedure, particularly in situations like there are no PUSCH/PUCCH transmissions occurring in the uplink for a long time in which case, the eNodeB relies on SRS for uplink timing estimation.

SRS doesn’t need to be transmitted in the same physical resource blocks where PUSCH is transmitted as SRS may stretch over a larger frequency range.

There are 3 types of SRS transmissions defined in LTE. From release-8 onwards ‘Single SRS’ transmission and ‘Periodic SRS’ transmissions are supported. In release-10, ‘Aperiodic SRS’ transmission is introduced. We will be discussing each of these types in detail.

SRS Configuration

‘Single SRS’ and ‘Periodic SRS’ transmissions are called ‘trigger type 0’ SRS transmissions which are configured by RRC signalling. ‘Aperiodic SRS’ transmission is called as ‘trigger type 1’ SRS transmission which is configured by RRC but triggered by DCI.

The eNodeB configures the UE with UE specific SRS configuration as shown below. UE specific SRS configuration provides the UE with time domain (subframes) as well as frequency domain resources.

UE specific SRS configuration for ‘trigger type 0’ (Periodic or Single)

UE specific SRS configuration for ‘trigger type 1’ (Aperiodic)

In addition to the UE specific SRS configuration, cell specific SRS configuration defines the subframes that can contain SRS transmissions as well as the set of SRS bandwidths available in the cell. In order to prevent SRS transmissions in the PUCCH regions of the cell, several SRS bandwidth configurations (srs-SubframeConfig) are defined.

Single and Periodic SRS transmissions

The parameter duration in the UE specific SRS configuration informs the UE whether single or periodic SRS transmission to be used.

Single SRS transmission is very simple one. After receiving RRC Connection Reconfiguration message with UE specific SRS configuration and parameter duration set to FALSE, the UE transmits SRS only once which is called ‘Single’ SRS transmission.

If the parameter duration is set to be TRUE, then the UE transmits Periodic SRS indefinitely until disabled.

srs-ConfigIndex defines SRS periodicity and an offset. The periodicity ranges from 2 ms to 320 ms.

srs-Bandwidth parameter defines the bandwidth that needs to be used while transmitting SRS in a subframe.

srs-HoppingBandwidth is defined for the purpose of frequency hopping of SRS. If frequency hopping of the SRS is enabled, then srs-HoppingBandwidth is smaller than srs-Bandwidth. SRS hopping procedure will also be discussed in detail.

freqDomainPosition defines the starting position of the SRS in the frequency domain

cyclicShift can vary from 1 to 8 which generates up to 8 different SRSs which are orthogonal to each other. The eNodeB can configure SRS for up to 8 UEs in the same subframe and frequency resources but to use different cyclic shift. The cyclic shift multiplexed signals need to have the same bandwidth to maintain the orthogonally.

transmissionComb: Actually, SRS is transmitted in every alternate (every even or every odd) subcarrier in the assigned SRS bandwidth. transmissionComb takes values 0 or 1 which informs whether to transmit SRS in every even or odd subcarrier in the assigned SRS bandwidth. By doing this the eNodeB can multiplex two UEs with same cyclicShift, frequency and time resources but different transmissionComb (0 or 1).

Aperiodic SRS transmissions

Aperiodic SRS transmissions are defined from Release-10 onwards. Aperiodic SRS transmission, as the name implies, is single shot SRS transmission based a trigger.

Aperiodic SRS is configured by RRC but triggered by ‘SRS request’ flag in PDCCH DCI Formats 0/4/1A (for FDD and TDD) and DCI Formats 2B/2C for TDD alone.

Before triggering Aperiodic SRS using DCI Format 0, a single set of parameters srs-ConfigApDCI-Format0 need to be configured by RRC. Similarly, Aperiodic SRS using DCI formats 1A/2B/2C, a single common set of parameters srs-ConfigApDCI-Format1a2b2c should be configured by RRC.

For triggering Aperiodic SRS using DCI Format 4, three sets of SRS parameters, srs-ConfigApDCI-Format4, are to be configured by RRC.

For ‘Aperiodic SRS’ trigger using DCI Formats 0/1A/2B/2C, 1-bit ‘SRS request’ field is used whereas DCI Format 4 carries 2-bit ‘SRS request’ field to indicate which of the three configured parameters set to be used.

The frequency domain behavior of Aperiodic SRS is same as Periodic SRS.

A UE configured for Aperiodic SRS transmission upon detection of a positive SRS request in subframe #n shall commence SRS transmission in the first subframe satisfying subframe #n+k, k ≥ 4 and based on the Aperiodic SRS time domain configuration.

SRS transmission in detail

The SRS configurations for different types of SRS transmissions are already discussed. We will now look at the contents of SRS, its mapping to physical resources both in time and frequency.

SRS uses same sequence as uplink Demodulation Reference Signals (DMRS). Since the cyclic shift versions of the Zadoff-Chu sequence are orthogonal, several UEs (up to 8) can transmit using different cyclic shifts on the same physical radio resource.

In the configured SRS bandwidth, the SRS will be mapped every alternate subcarrier (comb-like pattern), on the other hand, since the srs-Bandwidth is always multiple of 4 RBs, SRS sequences are always a multiple of 24 RBs.

SRS is always transmitted in the last OFDM symbol in a subframe which is based on srs-ConfigIndex.

Frequency domain resource selection for SRS transmission

There are two types of SRS, wide band SRS and narrow band SRS.

Wide band SRS doesn’t necessarily over the entire system bandwidth but on the entire bandwidth of interest, whereas narrow band SRS allows the UE to do frequency hopping between transmissions.

Wide band SRS is more beneficial from the resource utilization point of view, as the UE can sound in the entire bandwidth of interest using single SRS transmission. However, the UE at the cell edge may not have sufficient power to sound over a wide bandwidth in which case, the eNodeB might configure the UE to use frequency hopping for SRS.

In the frequency domain, SRS is transmitted in srs-Bandwidth which is multiple of 4RBs. Tables 5.5.3.2-1 to 5.5.3.2-4 in 36.311 defines 4 srs-Bandwidths based on 1 of 8 srs-BandwidthConfigs which is Cell specific bandwidth configuration. One such table is shown below.

Let us consider the following example in FDD to understand how SRS is spread in the frequency domain in terms of PRBs. Let the System Bandwidth = 10MHz (50 PRBs), srs-BandwidthConfig (From SIB2) = bw0, freqDomainPosition = 0, transmissionComb = 1.

Since the system Bandwidth is 50 PRBs, there are a total of 600 subcarriers (0…599)

Example 1: Wide band SRS (no SRS Hopping)

Consider srs-Bandwidth = bw0 and srs-HoppingBandwidth = hbw0.

Since srs-Bandwidth is equal to srs-HoppingBandwidth, frequency hopping is not enabled. From the Table 5.5.3.2-2 (presented above), srs-Bandwidth of bw0 corresponds to 48 PRBs.

In the subframe where SRS is transmitted, starting from subcarrier number 13, every alternate subcarrier (13, 15, 17… 585, 587) is used for SRS transmission.

The eNodeB can allocate same time and RBs for another UE by setting transmissionComb = 0 (all other parameters are same). This implies that second UE sends SRS on subcarriers (12, 14, 16… 584, 586).

Example 2: SRS Frequency Hopping

If frequency hopping of the SRS is enabled, then srs-HoppingBandwidth is smaller than srs-Bandwidth. Let us consider srs-Bandwidth = bw3 and srs-HoppingBandwidth = hbw0 ⇨ SRS bandwidth = 4 PRBs and SRS Hopping Bandwidth = 48 PRBs.

Consider two UEs, UE1 and UE2. Let transmissionComb = 0 for both of the UEs and freqDomainPosition = 0 for UE1 and freqDomainPosition = 2 for UE2.

Since srs-Bandwidth is set to 3, both of the UEs use 4 RBs in every subframe for SRS transmission. It can be seen that UE1 is transmitting SRS over the entire bandwidth of interest (SRS Hopping Bandwidth = 48 PRBs) but not in single shot. Similar behavior holds good for UE2 as well.

There can be a lot of combinations considered. In a single subframe, the eNodeB can configure all 48 PRBs to UE1 with transmissionComb = 0, and configure a couple of UEs with 4 PRBs but using transmissionComb = 1. Similarly, other combinations of various SRS bandwidths of 4, 12, 24, and 48 resource blocks can be considered

One can try several combinations using different parameters for calculating SRS resources (frequency domain starting position) using the tool given at the end of this post.

Time domain resource selection for SRS transmission

In the time domain, a resource is nothing but the subframe where SRS transmission has to happen.

Based on srs-SubframeConfig in SIB2, the UE first derives cell specific SRS subframe. These subframe (s) are common to all the UEs in the cell.

Different UEs are configured with different UE specific SRS configuration, based on which each UE derives UE specific SRS subframe.

The UE transmits SRS only if the ‘UE specific SRS subframe’ coincides with ‘Cell specific SRS subframe’.

Example: Let us consider srs-SubframeConfig = sc8 and srs-ConfigIndex = 0.

From Table 5.5.3.3-1 in 36.211, subframes 2, 3, 7, and 8 are cell-specific subframes. From srs-ConfigIndex, UE specific subframes are 0, 2, 4, 6, and 8. So the UE transmits SRS in subframes 2 and 8.

When SRS is being transmitted by a UE in a subframe, it may overlap in frequency with PUSCH being transmitted by another UE. Due to this reason, none of the UEs in the cell transmits PUSCH in the last OFDM symbol of a cell specific SRS subframe. Since all UEs are aware of cell specific SRS configuration, they can take care of not transmitting PUSCH in the last OFDM symbol of the cell specific SRS subframe.

A UE does not transmit SRS whenever SRS and CQI transmissions happen to coincide in the same subframe.

A UE shall not transmit SRS whenever SRS transmission and PUCCH transmission carrying HARQ-ACK and/or Scheduling Request happen to coincide in the same subframe if the parameter ackNackSRS-SimultaneousTransmission in SIB2 is set to FALSE.

A UE shall transmit SRS whenever SRS transmission and PUCCH transmission carrying HARQ-ACK and/or Scheduling Request using shortened PUCCH format happens to coincide in the same subframe if the parameter ackNackSRS-SimultaneousTransmission is TRUE. In this case, the UE shall transmit shortened PUCCH format where the HARQ-ACK or the SR symbol corresponding to the SRS location is punctured.

The UE shall use shortened PUCCH format in a cell specific SRS subframe even if the UE does not transmit SRS in that subframe.

In case both periodic and aperiodic SRS transmissions would occur in the same subframe in the same serving cell, the UE shall only transmit the Aperiodic SRS.

A UE shall not transmit SRS whenever SRS and a PUSCH transmission corresponding to a RAR Grant or a retransmission of the same TB as part of the contention based RA procedure coincide in the same subframe.

SRS transmission in TDD

In TDD, SRS can be transmitted in uplink as well as in special subframes (UpPTS).

Based on the special subframe configuration (Table 4.2-1 from 36.211), the UpPTS length varies (one or two OFDM symbols).

When one SC-FDMA symbol exists in UpPTS, it can be used for SRS transmission.

When two SC-FDMA symbols exist in UpPTS, both can be used for SRS transmission and both can be assigned to the same UE.

In UpPTS, whenever SRS transmission instance overlaps with the PRACH region for preamble format 4, the UE shall not transmit SRS

The following ‘SRS Calculator’ can be used to calculate SRS transmission resources (in time as well as frequency domain) for FDD. TDD support will be added very soon.

Reference: 3GPP TS 36.211, 36.213, and 36.331

SRS Calculator

SRS calculations

LTE: Measurement GAP Calculator

E-UTRAN provides the UE with measurement GAP configuration if UE requires measurement gaps to identify and measure inter-frequency and/or inter-RAT cells

The MeasGapConfig consists of gap pattern type (gp0 or gp1) which identifies the periodicity and gapOffset

Each gap starts at an SFN and subframe meeting the following condition:

SFN mod T = FLOOR (gapOffset/10);

subframe = gapOffset mod 10;

with T = MGRP/10 and MGRP is 40 for gp0 and 80 for gp1

For FDD, the UE shall not transmit in the subframe occurring immediately after the measurement gap.

For TDD, the UE shall not transmit in the uplink subframe occurring immediately after the measurement gap if the subframe occurring immediately before the measurement gap is a downlink subframe

One can calculate measurement gap occasions by providing gap pattern type and gapOffset in the below tool.

measGAP calculations

LTE: SPS Calculator

SPS Occasions can be calculated using the below tool.

Full details about Semi-Persistent Scheduling can be found here

When calculating SPS occasions for TDD, UL-DL configuration needs to be selected whereas for the FDD, the tool ignores UL-DL Config value.

activation-SFN and activation-Subframe need to be selected based on the SPS (UL or DL) activation SFN and subframe respectively.

For uplink SPS, PUSCH occasions will be displayed.

From 36.321, section 5.10.1, for downlink SPS,

After a Semi-Persistent downlink assignment is configured, the UE shall consider that the assignment recurs in each subframe for which

(10 * SFN + subframe) = [(10 * SFN_{start time} + subframe_{start time}) + N * semiPersistSchedIntervalDL] modulo 10240 for all N>0

Where SFN_start time and subframe_start time are the SFN and subframe, respectively, at the time the configured downlink assignments were (re-) initialised

Similarly, section 5.10.2 for Uplink SPS,

After a Semi-Persistent Scheduling uplink grant is configured, the UE shall consider that the grant recurs in each subframe for which:

(10 * SFN + subframe) = [(10 * SFN_{start time} + subframe_{start time}) + N * semiPersistSchedIntervalUL Subframe_Offset * (N modulo 2)] modulo 10240 for all N>0

Where SFN_start time and subframe_start time are the SFN and subframe, respectively, at the time the configured uplink grant were (re-) initialized. Subframe_Offset should be obtained from Table 7.4-1 in 36.321 if twoIntervalsConfig (only for TDD) is enabled, otherwise, Subframe_Offset is set to 0.

SPS calculations

LTE: Scheduling Request Timing Calculator for FDD and TDD

SR configuration table is given below (Table 10.1.5-1 from 3GPP TS 36.213). SR transmission instances are the uplink subframes satisfying (10*SFN + subframe ‒ Noffset,SR) mod SRperiodicity = 0

Scheduling Request procedure in detail is presented here

SR configuration Index I_SR	SR Periodicity (ms) *SR_periodicity*	SR subframe offset N_offset,SR
0 ‒ 4	5	I_SR
5 ‒ 14	10	I_SR ‒ 5
15 ‒ 34	20	I_SR ‒ 15
35 ‒ 74	40	I_SR ‒ 35
75 ‒ 154	80	I_SR ‒ 75
155 ‒ 156	2	I_SR ‒ 155
157	1	I_SR ‒ 157

One can use the below ‘SR calculator’ to calculate subframes for transmitting SR on PUCCH

LTE: Connected Mode DRX Calculations

Long and Short DRX occasions for both FDD and TDD can be calculated using this tool. The tool basically uses the below two equations given in 36.321

Full details about Connected Mode DRX are presented here

For Long DRX, DRX onDuration starting time can calculated from,

[(SFN * 10) + subframe number] modulo (longDRX-Cycle ) = drxStartOffset

The below equation needs to be used for calculating Short DRX occasions,

[(SFN * 10) + subframe number] modulo (shortDRX-Cycle) = (drxStartOffset) modulo (shortDRX-Cycle)

When DRX is configured, long DRX is mandatory whereas short DRX can be optional.

DRX calculations

Long DRX-cycle           Offset          onDurationTimer           Short DRX-cycle


                                                                                              UL-DL Config
        Is Short DRX?         Is TDD?

Long DRX Occasions

Long DRX Occasions will be displayed here

Short DRX Occasions

Short DRX Occasions will be displayed here

LTE: Timing Advance and Time Alignment Timer

Timing advance is a negative offset, at the UE, between the start of a received downlink subframe and a transmitted uplink subframe. This offset at the UE is necessary to ensure that the downlink and uplink subframes are synchronised at the eNodeB.

A UE far from the eNodeB encounter a larger propagation delay so its uplink transmission is somewhat in advance as compared to a UE closer to the eNodeB. As an example (shown in the figure below), let us consider two UEs; UE1 is located far from the eNodeB and UE2 is located close to the eNodeB. Let δ1 be the propagation delay experienced on the downlink for UE1 and δ2 is the propagation delay experienced on the downlink for UE2. Since UE1 is located far from the eNodeB as compared to UE2, we can safely assume that δ1 > δ2. Let us say that the eNodeB has transmitted subframe #n at time t1 which is seen by UE1 at time t1+δ1 and UE2 at time t1+δ2. Both UE1 and UE2 take the downlink subframe arrival (together with Timing Advance) as a reference to calculate uplink subframe timing.

The Timing Advance is equal to 2 x propagation delay assuming that the same propagation delay value applies to both downlink and uplink directions. So, UE1 needs to start it’s uplink at t1+2δ1 whereas UE2 should start it’s uplink at t1+2δ2. This will ensure that both of the uplink transmissions (from UE1 and UE2) reach the eNodeB at the same time which means that at the eNodeB, both uplink and downlink subframes are time aligned.

If the Timing Advance is not applied, then the start of uplink transmission from UE2 for subframe #n+1 will overlap with the end of uplink transmission from UE1 for subframe #n. Assuming that same resource blocks are assigned to UE1 in subframe #n and UE2 in subframe #n+1, this overlap creates interference which causes reception failures at the eNodeB. If a proper value of Timing Advance is applied, then these subframes won’t collide.

The eNodeB continuously measures timing of uplink signal from each UE and adjusts the uplink transmission timing by sending the value of Timing Advance to the respective UE. As long as a UE sends some uplink data (PUSCH/PUCCH/SRS), the eNodeB can estimate the uplink signal arrival time which can then be used to calculate the required Timing Advance value.

Timing Advance Command in LTE

The eNodeB estimates the initial Timing Advance from PRACH sent by the UE. PRACH is used as timing reference for uplink during UE’s initial access, radio link failure, during Handover etc…The eNodeB sends Timing advance command in Random Access Response (RAR). Once the UE is in connected mode, the eNodeB keep estimating Timing Advance and sends Timing Advance Command MAC Control Element to the UE, if correction is required.

The UE shall adjust the timing of its uplink transmission at subframe #n+6 for a Timing Advance Command received in subframe #n

The UE shall adjust the timing of its transmissions with a relative accuracy better than or equal to ±4*T_S seconds to the signalled timing advance value compared to the timing of preceding uplink transmission

The timing advance command indicates the change of the uplink timing relative to the current uplink timing as multiples of 16T_s.

N_TAis the timing offset between uplink and downlink radio frames at the UE, expressed in units of Ts. where T_s = 1/(2048x15000) = 1/30720000 sec

Timing Advance Command in MAC RAR

The Timing Advance Command in RAR takes 11 bits and it can indicate an index value T_A (0, 1, 2… 1282) which used to control the amount of timing adjustment that UE has to apply. The amount of the time alignment is given by N_TA = T_A × 16. The Timing Advance obtained via RAR is always positive

Example1 (T_A = 0): When the received T_A = 0 ⇨ N_TA = 0 so no timing adjustment required.

Example2 (T_A = 1): If T_A = 1 ⇨ Timing Adjustment = N_TA = 16 Ts = 16/30720000 sec = 0.5208 μs ⇨ Distance = (3x10⁸x0.5208x10^-6)/2 = 78.12m which is the minimum

Example3 (T_A = 1282): When the received T_A = 1282 ⇨ N_TA = 1282x16Ts = 1282x16/30720000 sec = 667.66 μs ⇨ Distance = (3x10⁸x667.66x10^-6)/2 = 100.15Km which is the maximum propagation distance

The maximum distance value (of slightly above 100Km) would facilitate cell radius of up to 100Km.

Timing Advance Command MAC CE

In the case of Timing Advance Command MAC CE, it indicates relative Timing Advance which is 6-bit index value T_A (0, 1, 2… 63). In this case, N_TA,new = N_TA,old + (T_A − 31)×16 where N_TA,old is the current timing adjustment and N_TA,new indicates new value. Here, adjustment of N_TA value by a positive or a negative amount indicates advancing or delaying the uplink transmission timing by a given amount respectively

Timing Advance command in MAC RAR and MAC CE are illustrated below

Uplink Time Alignment

It was discussed above how the eNodeB controls Timing Advance that each UE has to apply. Once the UE gets a Timing Advance Command, UE applies it and now the question is for how long the UE uses the received Timing Advance value?

The eNodeB provides the UE with a configurable timer called timeAlignmentTimer. TimeAlignmentTimer is used to control how long the UE is considered uplink time aligned

The value of the timer is either UE specific (timeAlignmentTimerDedicated) and managed through dedicated signalling between the UE and the eNodeB, or cell specific (timeAlignmentTimerCommon) which is indicated in SIB2. In both cases, the timer is normally restarted whenever a new Timing Advance is given by the eNodeB. At the time of restart, the timer is restarted to a UE specific value if configured; otherwise it is restarted to a cell specific value

The UE starts/restarts the TimeAlignmentTimer based on the condition when it received the Timing Advance Command.

The Timing Advance Command is received in MAC RAR but timeAlignmentTimer is not already running: This case may arise in situations like, timeAlignmentTimer has expired (connected mode), Initial access from RRC_IDLE, during RRC Connection Re-establishment procedure etc…After the reception of RAR, the UE shall apply the Timing Advance Command value received in RAR and start timeAlignmentTimer. If the contention is not resolved/successful, then the UE stops timeAlignmentTimer, else, the UE continues running the timer
The Timing Advance Command is received in MAC RAR as part of non-contention based Random Access procedure (ex: PDCCH Order): After the reception of RAR, the UE shall apply the Timing Advance Command value received in RAR and starts/restart the timeAlignmentTimer
The Timing Advance Command is received in MAC RAR as part of contention based Random Access procedure in connected mode and timeAlignmentTimer is already running: This could be in situations like UE is requesting for uplink resources but UE doesn’t have valid PUCCH resources for SchedulingRequest etc…After the reception of RAR, the UE shall ignore the received Timing Advance Command value and shouldn’t restart the timeAlignmentTimer
When a Timing Advance Command MAC CE is received, the UE shall apply the received value of Timing Advance Command value and start/restart timeAlignmentTimer

As discussed before, the eNodeB continuously measures timing of uplink signal from the UE and adjusts the uplink transmission timing by sending the Timing Advance Command to the UE. If the UE has not received a Timing Advance Command until the expiry of timeAlignmentTimer, the UE assumes that it has lost the uplink synchronization. Hence, prior to any PUSCH/PUCCH/SRS transmission in the uplink, an explicit timing-re-alignment phase using the random access procedure must be performed to restore the uplink time alignment

The UE shall perform the following actions upon the expiry of timeAlignmentTimer:

Flush all HARQ buffers;
If configured, release PUCCH resources of Periodic CQI and Scheduling Request, and also SRS configuration. By doing so, the UE doesn’t perform transmission of SRS/PUCCH while timeAlignmentTimer is not running. The eNodeB has to configure these parameters again in order for the UE to transmit SRS/Periodic CQI/Scheduling Request after UE starts timeAlignmentTimer
Clear configured downlink assignments and uplink grants. i.e., release SPS grant (uplink) and assignment (downlink) if configured

The UE shall not perform any uplink transmission except the Random Access Preamble transmission when timeAlignmentTimer is not running.

For multiple Timing Advances in uplink Carrier Aggregation concepts in Release-11, refer to the post here.

Reference: 3GPP TS 36.321, 36.213, 36.331, 36.133, 36.300