Uplink Scheduling

- The functions of the uplink scheduler is similar to the downlink scheduler, for each 1ms interval, which terminals are used to transmit and on which uplink resources.

- The basis for uplink scheduling is scheduling grants, containing the scheduling decision and providing the terminal information about the resources and the associated transport format for the use of UL-SCH on one component carrier.

- Only if the terminal or ue has a valid grant, it is allowed to transmit on the corresponding UL-SCH, however autonomous transmissions are not possible without a corresponding grant.

- Dynamic grant are valid for one subframe – for each subframe in which the terminal is to transmit on the UL-SCH, the scheduler issues new grant.

- Uplink component carriers are scheduled independently, if the terminal is to transmit simultaneously on multiple component carriers, multiple scheduling grants are required.

-

- Figure: Timing relations for Uplink Grants in TDD and FDD frame configuration #0 and #1.

- For FDD, the grant timing is straight forward. An uplink grant received in the sub-frame n triggers an uplink transmission in the sub-frame n+4.

- This is the same timing relation as used by uplink retransmission triggered by PHICH.

- For TDD, the situation is different. Here the sub-frame n+4 may not be uplink sub-frame.

- Therefore for TDD configurations #1 – 6, the timing relation is modified in such a way that the uplink transmission occurs in the sub-frame n+k, where k is the smallest value larger than or equal to 4 such that the subframe n+k is the uplink subframe.

- This requires some processing time for the terminal as in the case of FDD, the delay is minimized from the receipt of the uplink grant to the actual transmission.

- This implies that the time between the grant receipt and the uplink transmission may differ between two subframes.

- Another downlink heavy configurations 1 – 5, the property is that the uplink scheduling grants can only be received on some of the downlink subframes.

- In TDD configuration #0, there are more uplink sub-frames than downlinkn subframes, which has the possibility to schedule transmissions in multiple uplink subframes from a single downlink sub-frame.

- Similar to downlink case, the uplink scheduler can exploit information about the channel conditions, buffer status and priorities of the different data flows, and if some form of interference coordination is employed in the neighbouring cells interference.

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 DPCCH with DCI format 0 without any DPSCH 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.

- 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.

80 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 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 and transmit PUSCH based on the RBs specified by DCI 0 iv) Network decode the PUSCH

v) Network send ACK/NACK on PHICH

vi) If Network send NACK, go to [Retransmission] Procedure ( For the details of [Retransmission] process, refer to HARQ Process page)

82