Persistent Scheduling on this page means one specific thing. The network sends a UL Grant in DCI Format 0 in every subframe, so the UE never has to ask for one. No live network does that, because a grant for every UE in every subframe would consume the whole downlink control region. It is a bring-up arrangement, and it is useful precisely because it removes one variable from the test.

That makes this the simplest of the three scheduling arrangements the site describes. The companion page covers the dynamic case, where the UE has to ask with a Scheduling Request first. It also sets both of them beside the Semi-Persistent Scheduling that 3GPP actually defines.

• Uplink Data Transmission Scheduling - Persistent Scheduling
• Why does the bring-up ladder go in this order ?
• What does Persistent Scheduling mean here ?

Uplink Data Transmission Scheduling - Persistent Scheduling

There are a couple of Data Transmission Scheduling Scheme in LTE. The most simple in terms of algorithm would be the persisent scheduling. In this scheduling mode, Network send 'Grant' in DCI Format 0 for every subframe.

• i) Network send the first data on DL PDSCH and PDCCH which has DCI format 1 for DL Data Decoding and DCI format 0 for UL Grant. (If there is no downlink data to be transmitted, network transmits only PDCCH with DCI format 0 without any PDSCH data)
• ii) UE decode PCFICH to figure CFI value.
• iii) UE decode PDCCH and get the information on DCI format 1
• iv) Based on DCI format 1, UE decode DL data.
• v) UE decode the information on DCI format 0 from PDCCH
• vi) UE send ACK/NAK for DL data through UCI (UCI will be carried by PUCCH)
• vii) UE check the Grant field.
• viii) If Grant is allowed, UE transmit the uplink data through PUSCH
• ix) Network decode PUSCH data and send ACK/NACK via PHICH
• x) UE decode PHICH and retransmit the data if PHICH carries NACK

Overall flow can be illustrated as follows. This diagram would not show all the details but give you the big picture for the procedure.

Figure 1. Persistent scheduling with a grant in every subframe. Both 4 sub frame gaps are the ordinary n+4 rules, so the only thing this mode removes is the wait for a grant.

• The note at the top right states the whole idea. The network keeps sending GRANT at every subframe, and the three Grant(DCI 0) on PDCCH arrows with the dots below them stand for a stream that never stops.
• The staircase on the left is where the uplink data comes from. TE or RRC hands it down to PDCP, then RLC, then MAC, and the red arrow out of MAC is the moment the UE has something to send.
• The brackets on the right join each Grant to the UL SCH on PUSCH that answers it, and each one is labelled 4 sub frames. The brackets on the left join each PUSCH to its Ack/Nack on PHICH, and those are 4 sub frames as well.
• Colour marks direction here. Red carries the grants and the PHICH downlink, and blue carries the PUSCH uplink. The figure on the companion page pairs the colours in the opposite way, so do not read the two diagrams with the same key.
• The diagram shows no Scheduling Request at all. That absence is the whole difference from the dynamic case, and it is what makes this mode a clean starting point for bring up.

For detailed data structure of DCI Format 0, refer to TS 36.212 section "5.3.3.1.1 Format 0"

The process listed above is in reality a pretty complicated process and need a lot of troubleshoot and debugging. So in case of development and testing phase, we normally break down this process into multiple simple/small procedure and verifies it step by step.

Step 1 : DL data reception and no ACK/NACK transmission

a) Network send PDCCH and PDSCH data

b) See if UE properly decode PDSCH data

This would seem to be very simple two step process, but to make this happen UE is capable of doing step ii), iii), iv) described above.

 

Step 2 : DCI format 0 reception

a) Network send DCI Format 0(UL Grant) without PDSCH transmission

b) See if UE properly decode DCI Format 0 (You need to make it sure that Resource allocation that UE decoded matches with DCI format 0 sent by network.)

 

Step 3 : PUSCH transmission based on DCI format 0

a) Network send DCI Format 0(UL Grant) without PDSCH transmission

b) UE transmit UL Data on PUSCH

c) Network decode PUSCH data

d) see if the data decoded at Network side maches what UE transmit

To make this happen, UL DMRS for PUSCH should have been properly implemented and you have to make it sure that UE transmit the PUSCH data on the RBs that DCI format 0 specified.

 

Step 4 : DL data reception and ACK/NACK transmission

a) Network send PDCCH and PDSCH data

b) UE decode PDSCH data

c) UE has to transmit ACK/NACK accordingly

 

Step 5 : UL data transmission and ACK/NACK reception

a) Network send DCI Format 0(UL Grant) without PDSCH transmission

b) UE transmit UL Data on PUSCH

c) Network decode PUSCH data

d) Network send ACK/NACK on PHICH

e) UE has to decode ACK/NACK properly

f) UE has to retransmit the data if it gets NACK

• Only the grant stream changes : the n+4 timing from grant to PUSCH and from PUSCH to PHICH is the same here as it is under dynamic scheduling.
• The UE side of the procedure is unchanged : steps ii) to x) are what a UE does under any scheduling mode. That is what makes this a fair way to test them.
• This is a test arrangement rather than a network feature : no deployed cell grants every UE in every subframe, so nothing here describes how a real network behaves.

Why does the bring-up ladder go in this order ?

The five steps above are not five ways of testing the same thing. Each one adds exactly one capability that the step before it did not need, so the first step that fails names the block to look at. Read them as a ladder rather than as a checklist. Skipping a rung does not save time, because it only moves the failure somewhere harder to see.

Two of the rungs deserve more explanation. Step 2 deliberately sends DCI Format 0 with no PDSCH beside it, so nothing on the downlink can hide a DCI parsing problem. A failure there is the DCI and nothing else.

Step 4 is the first time the UE has to work out an uplink resource for itself. DCI format 0 names the PUSCH allocation explicitly, while the PUCCH resource for an ACK follows from the PDCCH that scheduled the downlink data. So a Step 4 failure often means the derivation is wrong rather than the transmitter.

Step 5 is the only rung where the UE acts on something the network sends afterwards. Everything before it is scheduled in advance. PHICH arrives 4 sub frames after the PUSCH, and a NACK obliges the UE to retransmit 4 sub frames after that.

The order also explains what the persistent grant is for. Steps 2, 3 and 5 all need a UL Grant, and in this mode the UE gets one whether or not anything asked for it. So none of these steps can fail because a Scheduling Request was missed or answered late.

• Each rung adds one capability : the first step that fails names the block to look at, and every step after it will fail for the same reason.
• Step 2 removes the downlink on purpose : sending DCI format 0 with no PDSCH means a decoding failure can only be the DCI.
• Step 4 is about a derived resource : the PUCCH resource for an ACK follows from the scheduling PDCCH, so check the derivation before you suspect the transmitter.
• The persistent grant keeps the scheduler out of the result : every step that needs a grant gets one, so a failure is never a scheduling problem.

What does Persistent Scheduling mean here ?

Two readers will disagree about this page’s title, and both will be partly right. The closest named feature in 3GPP is Semi-Persistent Scheduling, and that is not what this page describes. The word is being used for a test arrangement instead, and the difference matters as soon as you carry it into a real network.

This page states its own definition in the first paragraph: the network sends a Grant in DCI Format 0 for every subframe. There is no configuration, no activation and no period. The grant is simply always there.

Semi-Persistent Scheduling is arranged differently. RRC configures a period, a PDCCH addressed to the SPS C-RNTI activates it once, and the allocation then repeats on that period with no further grants. It exists to carry VoIP, where a small packet every 20 ms would otherwise cost a Scheduling Request and a DCI 0 each time. The companion page sets all three arrangements in one table.

A grant per subframe costs downlink capacity rather than uplink capacity. Every grant is a DCI 0 that needs its own PDCCH, and the control region holds only so many of those per subframe. A cell with many active UEs would spend its whole PDCCH capacity on grants that most of them did not need. So this arrangement belongs on a bench with one UE on it.

One practical consequence is worth stating. Passing every step on this page does not test the UE against a scheduler. It tests the UE against a grant that never runs out. Dynamic scheduling adds the Scheduling Request, its configured periodicity and the eNB’s decision to answer, and those are where integration problems usually appear.

• Persistent here means always, not periodic : the grant arrives in every subframe, while Semi-Persistent Scheduling repeats on a configured period.
• Nothing on this page is configured or activated : SPS needs RRC configuration and a PDCCH activation, and this mode needs neither of them.
• The ladder does not cover scheduling : the Scheduling Request, its periodicity and the eNB’s answer are all absent here, so they still have to be tested on the dynamic path.