Most uplink traffic is bursty, so a network that granted every UE a slot in every subframe would waste almost all of them. The alternative is to make the UE ask first. This page follows one such request, from the Scheduling Request to the acknowledgement. It then traces the same procedure through a live log.

One warning before you start. This page and its companion use Persistent Scheduling to mean that the network sends a UL Grant in every subframe, which is a lab arrangement rather than a 3GPP feature. The specification also defines Semi-Persistent Scheduling, and that is a third mode again. The section on Semi-Persistent Scheduling compares all three.

• Uplink Data Transmission Scheduling - Non Persistent Scheduling
• What decides the timing between SR, grant and data ?
• How does this differ from Semi-Persistent Scheduling ?

Uplink Data Transmission Scheduling - Non Persistent Scheduling

In Persistent Scheduling mode, UE can send the data to Network anytime since Network is sending UL Grant all the time. But what if Network does not send UL Grant all the time ? In this case, UE has ASK the network to send UL Grant (DCI 0). If network send UL Grant, then UE can send UL data as allowed by the UL Grant.

Overall procedure is as follows :

• i) UE send SR (Scehduling Request) on PUCCH
• ii) Network send UL Grant (DCI 0) on PDCCH
• iii) UE decode DCI 0 (How UE can figure out a DCI 0 information in PDCCH is allocated for it ? Simply put, it performs the blind decoding for the whole PDCCH area (PDCCH Search Space) and check if there is any DCI 0 information that has CRC value encoded with C_RNTI allocated to it).
• iv) UE Transmit PUSCH based on the RBs specified by DCI 0.
• v) Network decode the PUSCH (How network figure out which part of Uplink subframe (UL RB) is for which UE ? It is simple. eNB knows exactly knows which UE send PUSCH at which RB because network specified this location in DCI 0 at step iii)
• vi) Network send ACK/NACK on PHICH
• vii) If Network send NACK, go to [Retransmission] Procedure ( For the details of [Retransmission] process, refer to HARQ Process page)

Following is the illustration of SR based PUSCH scheduling for FDD (Refer to refer to SR/DCI 0 Timing, DCI 0/PUSCH Timing  of TDD Overview for TDD scheduling)

Figure 1. SR based PUSCH scheduling in FDD. All three gaps are drawn as 4 sub frames, but only the second and the third are fixed by the specification.

• Four exchanges run down the chart: SR on PUCCH, then UL GRANT carried in DCI 0, then User Data on PUSCH, then Ack/Nack on PHICH. The red arrows are uplink and the blue arrows are downlink.
• The callout at the lower left covers the second and third gaps. It says these timings for FDD are defined in 3GPP, so the grant to PUSCH gap and the PUSCH to PHICH gap are both fixed at 4 sub frames.
• The callout at the top left says the opposite about the first gap. Some eNBs and eNB simulators put 4 ms between SR and UL Grant, and 3GPP does not specify that delay.
• The diamond near the bottom sends a NACK into Perform Retransmission. One pass down the chart is therefore the best case, and the chart does not draw what a retransmission costs.

Now let's look at a real life example, which might look more complicated and confusing but hopefully look more interesting :). This shows an example of what's happening during the initial process (RACH process) after you turn on your mobile phone.

Again, the log and background RB map is from Amarisoft LTE Network simulator. All the labels were put manually (If you roll over the mouse pointer onto each channel it shows some detailed information, but it would not show information on the exact contents. This is understandable.. because Physical channel by itself does not have any detailed knowledge on the contents).

In this example, you can see almost every cases that might happen in the real communication. You may ses SR and DCI 0 in response to SR and even PUSCH retransmission due to CRC failure.

Figure 2. The same procedure on a live resource block map. The four small marks at the lower right are one transport block sent four times, and they sit at two different heights because the eNB moved the allocation.

• The map has two panels. The upper panel is the downlink and the lower panel is the uplink, and the digits along the bottom count frames and subframes.
• The left of the map is the RACH procedure. PRACH goes up, PDSCH RAR comes back, PUSCH carries Msg 3 as the RRC Connection Request, and PDSCH carries Msg 4 with Contention Resolution and RRC Connection Setup.
• PUCCH is labelled twice in the lower panel, once as the HARQ ACK for Msg 4 and once as the Scheduling Request. That Scheduling Request is where the procedure of this page begins.
• The green dashed lines in the upper panel mark PDCCH. The one labelled UL Grant (DCI 0) is the answer to that Scheduling Request.
• Three hatched marks in the lower panel are labelled PUSCH (CRC Error), and a solid mark after them is labelled PUSCH. Both labels name PHR and SBSR as the contents, so all four carry the same report.
• Those four marks do not sit at the same height. The first two are lower than the last two, and the log in Figure 3 explains why: the eNB moved the allocation from rb_start=2 to rb_start=8.
• A taller red bar further right is labelled RRC Connection Setup Complete. It is a much larger allocation than the PHR and SBSR reports.

How can I figure out all the details printed on each labels shown above ? It came from the text based log as shown below.

It took me almost an hour to pul all the lables shown above based on the log below. However, this can be a good practice if you are at learning phase of LTE protocol.. or you HAVE TO go through this tedious process when you are in troubleshooting situation.

Figure 3. The Amarisoft log behind Figure 2. The SFN column reads as frame and subframe, so the 4 subframe spacing of Figure 1 can be counted directly from it.

Figure 4. The end of the same log. The fourth copy of the transport block passes CRC at 7.2 dB, and the PHICH that follows carries hi=1.

• The Scheduling Request is the PUCCH line at SFN 512 with sr=1. The UL Grant is the PDCCH line at 512.4 with dci=0, and the PUSCH follows at 512.8. Both gaps are 4 subframes, which is exactly what Figure 1 draws.
• Only the second of those two gaps is fixed by the specification. This simulator happens to answer the Scheduling Request after the same 4 subframes, which is the behaviour the Figure 1 callout describes.
• The first PUSCH at 512.8 carries tb_len=42 with rv_idx=0, and it comes back crc=KO at snr=2.3 dB. The PHICH at 513.2 carries hi=0, and that is the NACK.
• Three more attempts follow at 513.6, 514.4 and 515.2, with rv_idx 2, 3 and 1. Each PUSCH sits 8 subframes after the one before it, which is the FDD HARQ round trip.
• The SNR climbs across the four attempts, 2.3, 3.8, 5.2 and 7.2 dB, and only the last reports crc=OK. The transport block never changed. The redundancy version did, and the eNB combined the copies.
• At 514 the log says adaptive retransmission to avoid collision. PHICH carries hi=1 there and a fresh PDCCH carries dci=0, so the eNB stopped the plain repeat and granted a new position instead. The next PUSCH moves from rb_start=2 to rb_start=8.

• The UE pays for asking : a Scheduling Request and a DCI 0 have to travel before any uplink data does, and neither of them carries user data.
• Only some of the delay is in the specification : the grant to PUSCH and PUSCH to PHICH gaps are fixed for FDD. The wait from SR to grant is not, and it depends on the eNB and on the UE’s SR opportunity.
• A retransmission is not a resend : the log shows the same transport block with four different redundancy versions, so each attempt adds information rather than repeating it.

What decides the timing between SR, grant and data ?

Figure 1 draws every gap as 4 sub frames, and that is easy to read as a single rule. Two different things produce that same number. Some of these gaps are fixed by the specification and cannot move, and one of them is a scheduler decision that varies from network to network. Telling them apart matters, because only one of them is worth complaining to a vendor about.

So three of the four gaps are arithmetic and one is a policy. A UE with data ready still cannot send it until its next SR opportunity arrives, and that opportunity is configured rather than continuous. On a quiet cell the eNB may answer in 4 subframes as this trace does. On a busy one it may not answer at that SR opportunity at all.

The 8 subframe HARQ round trip is the number to remember. Each failed attempt costs 8 subframes, so the four attempts in Figures 3 and 4 spread one transport block across 24 subframes of extra delay. That is why the SNR trend matters more than any single CRC result.

These numbers are the FDD ones. TDD moves them, because the uplink and downlink subframes no longer alternate one for one. The page already links SR/DCI 0 Timing and DCI 0/PUSCH Timing for the TDD versions.

• Three of the four gaps cannot be tuned : n+4 is in the specification for FDD, so a vendor cannot shorten the grant, the PUSCH or the PHICH timing.
• The SR opportunity is the one to check first : it is configured per UE, and a long period adds latency before the eNB has done anything at all.
• Count HARQ in round trips, not in attempts : every retransmission costs 8 subframes in FDD, so three failures cost more than the whole successful exchange did.

How does this differ from Semi-Persistent Scheduling ?

If you know 3GPP, you will expect Persistent Scheduling to mean Semi-Persistent Scheduling, and on this site it does not. Three arrangements exist here, and only two of them are named on these pages. Separating them matters, because the third one is what a real network actually uses for voice.

The middle row is not something a live network does. Granting every UE in every subframe would consume the whole uplink, so it belongs to a test setup where one UE has the cell to itself. It is useful precisely because it removes the Scheduling Request from the exchange, which is what makes it a good first step when bringing a UE up.

The third row solves a real problem. A voice codec produces a small packet every 20 ms, and the exchange in Figure 1 would repeat for every one of them. The Scheduling Request and the DCI 0 carry no user data, so that overhead appears on PUCCH and PDCCH every 20 ms for every call in the cell. Semi-Persistent Scheduling configures the period once and then lets the allocation repeat, so the UE transmits without asking and without a grant each time.

The word semi matters. The allocation repeats, but the eNB can still release it or change it with a PDCCH addressed to the SPS C-RNTI. The UE also falls back to the procedure on this page for anything that does not fit the configured allocation.

• Persistent on this site is not SPS : the companion page means a grant in every subframe, while Semi-Persistent Scheduling means a grant that repeats on a configured period.
• SPS exists to remove the Scheduling Request : for periodic traffic the SR and the DCI 0 are pure overhead, and they repeat as often as the payload does.
• SPS does not replace dynamic scheduling : anything that does not fit the configured allocation still goes through the SR and grant exchange described on this page.