Most of wireless communication (practically every wireless communication that I know) works in very strictly synchronized timing between transmitter and reciever. This timing synchronization requirement tend to get more and more strict as you go with higher end communication technology like LTE. In most case to meet this kind of timing requirement tend to be one of the most challenging task but in most case you would not even realize that this kind of problem exists mainly because most of these problems get resolved at early stage of modem development. By the time the product gets at your hand as a user or as test engineer, these problem would not be noticeable.

However if you are really motivated enough to get the first hand experience with this, I would suggest you to get involved in verification of early stage of modem development.

On this page, I'll first show two ways to measure a timing error, and then a RACH case where it matters most. After that we'll check the 3GPP limit, so you know what "too large" means, and close with the options for fixing it.

The page covers the following topics.

• How to measure Timing Error ?
• Timing Error in RACH Procedure
• What is the requirement for Timing Error ?
• How to fix this kind of timing error ?
• Reference

How to measure Timing Error ?

The issue is how to measure / detect this kind of timing error. Most of modem vendor and test equipment vendor provides a logging tools to print out this kind of timing error. If you process those log properly, you may plot the data as shown below.

Timing error from a baseband log. It stays between about 0.05 microseconds and 0.2 microseconds for the whole run.

• Vertical axis : timing error in microseconds, from 0 to 2 microseconds.
• First 4400 ms : the trace moves in small steps between about 0.1 microseconds and 0.2 microseconds.
• After about 4400 ms : the trace becomes denser but stays between about 0.05 microseconds and 0.2 microseconds.
• Compared with 36.133 : the whole trace is inside the 12 T_s, or about 0.39 microseconds, limit shown later on this page.

However, most of those logging tool measures the timing error at baseband from the demodulated data (or after decoding). It means that the input signal went in out of sync to such a degree that proper demodulation is not possible. This kind of logging tool would not help. This is the most challenging cases where you should handle. At this step, you would need some additional equipment to measure the timing error. Following is a conceptual test setup for timing error. This is just a conceptual, in real situation you would not connect Spectrum Analyzer and Logic Analyzer at the same time. If you have very high performance digital oscilloscope, you may use it both for baseband and RF. Also for the accurate measurement, you would need a protocol test equipment that can output a trigger signal at every subframe and every frame.

Conceptual test setup. The frame and subframe trigger from the test equipment gives the reference, and the analyzer measures the signal against it.

• Test equipment with protocol stack : it carries the Uplink and Downlink to the DUT and outputs a Frame/Subframe trigger.
• Vector spectrum analyzer : used if the signal to measure is RF, triggered by the test equipment.
• Logic analyzer or digital oscilloscope : used if the signal to measure is baseband, triggered the same way.
• DUT : the modem whose transmit or receive timing is under test.

The trigger is the key part of this setup. The analyzer does not know where a subframe starts, so it measures the time from the trigger edge to the start of the signal. The trigger itself has a delay inside the test equipment and in the cable. Calibrate that delay once, because 0.39 microseconds is only about 12 samples at 30.72 MHz.

• Log based measurement : easy, but it works only while the DUT can still demodulate the signal.
• Trigger based measurement : it works even when demodulation fails, because it uses the raw signal.

Timing Error in RACH Procedure

One of the most common case where you would be struggled by these timing error would be in RACH procedure. Following is one of the examples of timing error measurement that I really experienced (Sorry I am not supposed to open the specific numbers here). If you have issues with reception of any of these signal, you may first to check DUT log or equipment log to see if you can find any clue. However, if you don't find anything from those log, you need to draw following diagram (or capture) from the additional measurement equipment as shown above.

Timing error points in the RACH procedure. Each transmission is compared with the subframe boundary it should start on.

• PRACH : the DUT (UE) sends it, and it should start on an uplink subframe boundary.
• RAR : the test equipment sends it on a downlink subframe.
• Msg3 : the DUT sends it after the RAR, on an uplink subframe boundary again.

Each of the three transmissions follows a different timing rule, so let's go through them in order. For the PRACH, the UE has no timing advance yet. 36.211 v19.3.0 clause 5.7.1 says the preamble starts at the start of the uplink subframe at the UE, assuming a timing advance of 0. So the PRACH start is tied directly to the DL timing that the UE has measured.

The eNB measures the arrival time of the preamble and returns a timing advance command in the RAR. The UE applies N_TA = T_A x 16 T_s (36.213 v19.4.0 clause 4.2.3) and sends Msg3 earlier by that amount. So an error in the PRACH timing does not disappear. The eNB includes it in the timing advance, and then the UE has to apply the timing advance correctly for Msg3.

This is why RACH shows timing problems first. The PRACH preamble has a long CP and a guard time for the round trip delay, so the eNB still detects a PRACH with a small timing error. Msg3 is a normal PUSCH, and it has only the normal CP of about 4.7 microseconds. A wrong DL timing, a wrong timing advance or a wrong subframe count all appear there as a failed Msg3.

• PRACH starts at DL timing : the UE assumes a timing advance of 0.
• RAR carries the timing advance : in steps of 16 T_s, about 0.52 microseconds.
• Msg3 is the first timing check : a normal PUSCH, with no extra guard time.

What is the requirement for Timing Error ?

Whenever I bring up this kind of timing error issue, I am asked 'what is the requirement for the timing error / tolerance'. Since I get involved this kind of situation just around once or twice at early modem development testing, I often spend hours to find this information from 3GPP spec and forget about it. When I am get into the same situation after several month, I would spend a couple of hours again to find the same information. Now I decided to put down the specification in my note here. Following is timing error requirement from 3GPP. Most of the protocol test equipment would allow the timing error from a few to over a few tens of times wider than this specification so that it can maintain the connection with the DUT even when the timing error gets slightly out of the specification. However, how much timing error is allowed is completely up to test equipment (Uplink case) or DUT (Dowlink case).

< 36.133 - Table 7.1.2-1: Te Timing Error Limit >

The same table is still in 36.133 v19.5.0 clause 7.1.2, with the same values. In microseconds, 12 T_s is about 0.39 microseconds, and 24 T_s for 1.4 MHz is about 0.78 microseconds. The 1.4 MHz limit is twice as large, and one sample at 1.92 MHz is already 16 T_s.

Note which transmissions this limit covers. T_e applies to the UE initial transmission timing: the PRACH, the first transmission in a DRX or eDRX_CONN cycle, and the first transmission after a RACH-less handover. The reference is the time when the UE receives the first detected path of the DL frame from the reference cell.

After the initial transmission, the UE has to follow the DL timing on its own, and 36.133 limits how fast it may move. One adjustment may change the timing by at most T_q, from Table 7.1.2-2 below. The aggregate adjustment rate has to be at least 7 T_s per second and at most T_q per 200 ms.

The T_q values are much smaller than the CP. The eNB receiver tracks the UE timing too, so small steps let it follow the change. A UE that corrects a timing error in one large step breaks this rule, even if the final timing is correct.

• T_e = 12 T_s, about 0.39 microseconds : for 3 MHz and above; 24 T_s for 1.4 MHz.
• It covers the initial transmission : PRACH, the first transmission in a DRX cycle, and the first transmission after a RACH-less handover.
• Autonomous adjustments are limited : at most T_q per step and T_q per 200 ms.

How to fix this kind of timing error ?

This also depends on the degree of the error. If the error is not so big (i.e, at least within the range of demodulation), it may be corrected (compensated) by the baseband algorithm (e.g, at equalization at the reciever side). In this case, the problem may be fixed in a few days or in a few weeks. However, if the degree of error, you often need to design a special circuit (like additional FPGA) for the timing adjustment. If your DUT board or modem does not have this kind of large scale timing adjustment, it would take additional month to design and add such a additional circuit. In worst case, you would need to add this kind of timing adjustment circuit on both transmitter and reciever side.

The CP sets the line between these two cases. A timing error smaller than the CP, minus the delay spread of the channel, keeps the FFT window inside one symbol. The error then appears as a phase that grows linearly across the subcarriers, 2 pi x k x 15 kHz x error for subcarrier k. The channel estimate from the reference signals contains the same phase ramp, so the equalizer removes it without extra work.

A timing error larger than the CP is different. The FFT window then includes part of the next or the previous symbol, which causes inter-symbol interference. The equalizer cannot remove this, so the timing itself has to be moved, and that is the case where extra hardware for timing adjustment becomes necessary. The Physical Layer Parameter - DL, FDD page lists the CP lengths in samples for each bandwidth.

• Error inside the CP : a phase ramp across the subcarriers, removed by the equalizer.
• Error beyond the CP : inter-symbol interference, so the timing itself has to be corrected.
• Check the limit before fixing : an error below T_e may not need any fix.

Reference

• 3GPP TS 36.133 v19.5.0 - clause 7.1, UE transmit timing, Table 7.1.2-1 and Table 7.1.2-2
• 3GPP TS 36.211 v19.3.0 - clause 5.7.1, Time and frequency structure of the random access preamble
• 3GPP TS 36.213 v19.4.0 - clause 4.2.3, Transmission timing adjustments