5G-NR: UPLINK RESOURCE REQUEST


5G-NR: UPLINK RESOURCE REQUEST:

Introduction:
              The Base Station packet scheduler is responsible for allocating resources to transfer uplink data. In some cases, it is not necessary for the UE to request those resources:


   The Base Station may allocate resources in a proactive manner, i.e. provide the UE with capacity on the PUSCH before it is actually requested. This approach helps to reduce latency because the UE is able to transmit uplink data without having to request resources and subsequently wait for those resources to be allocated. Proactive scheduling is generally applicable to cells which are not heavily loaded. Cells transferring a lot of data may not have sufficient capacity to allocate resources which may not be required, i.e. proactive scheduling grants arc typically given low priority by the packet scheduler. 

   The Base Station may provide the UE with 'Configured Grants' lo allow uplink retansmission on the PUSCH without having to receive individual resource allocations on the PDCCH. A UE configured in this way is not free to transmit on any Resource Block

at any time, but is configured to allow periodic transmission on a specific set of Resource Blocks. This type of resource allocation is also known as 'Grant Free' resource allocation and is analogous to Sem-Persistent Scheduling (SPS) in the downlink.

UE can request uplink resources using the following mechanisms:
1- Scheduling Request 
2- Buffer Status Reporting
3- Random Access procedure 

1- Scheduling Request:
              A UE uses the Scheduling Request (SR) procedure as a mechanism to request air-interface resources for a new uplink transmission.

=> Below figure illustrates the sequence of events associated with the transmission of a Scheduling Request. Uplink data belonging to a specific Logical Channel is queued for transmission within the UE buffer. This uplink data triggers the UE to send a Scheduling
Request using PUCCH resources which have been configured specifically for the Logical Channel which has the uplink data ready for transmission. The Base Station receives the Scheduling Request and is able to deduce the Logical Channel (or group of Logical
Channels if multiple Logical Channels have been linked to the same set of PUCCH resources). Knowledge of the Logical Channel helps the Base Station to priorities the Scheduling Request.


=>The Base Station then proceeds to allocate uplink resources on the PUSCH using a PDCCH transmission. The UE uses those resources to send a Buffer Status Report (BSR) in combination with at least some of the buffered data. The Buffer Status Report provides the Base Station with information regarding the volume of data waiting to be transferred. Alternatively, if the UE buffer can be emptied using the initial uplink resource allocation, the UE can exclude the Buffer Status Report and send only the uplink data.





=> Once a Scheduling Request has been triggered, it is categorized as 'pending' until it is 'cancelled', i.e. a Scheduling Request remain categorized as 'pending' after it has been transmitted. A Scheduling Request is 'cancelled' after the UE has received an uplink resource allocation and has sent a Buffer Status Report, or after the UE has received an uplink resource allocation and has been able to empty its transmission buffers.

=> Scheduling Requests are sent using the PUCCH physical channel. All PUCCH Formats can accommodate a Scheduling Request, i.e. Formats 0, I, 2, 3 and 4.  Scheduling Request resources arc always configured using either PUCCH Format 0 or PUCCH Format 1.  Other PUCCH formats can be used when PUCCH transmissions coincide, e.g. a Scheduling request transmission using PUCCH Format 0 coincides with a CSI Reporting transmission using PUCCH Format 3. In that case, both the Scheduling Request and CSI Report can be transferred using PlJCCH Format 3.

=> A UE is not free to transmit a Scheduling Request at any instant in time. Instead, the Base Station provides the UE with timing information which defines the time instants that a UE is permitted to transmit a Scheduling Request. This timing information includes
the SR-periodicity and SR-offset.

=> The SchedulingRequestResourceConjig parameter structure which configures both the SR-periodicity and SR-offset using the periodicityAndOffset information clement.


RRC Parameters:



=> The schedulingRequestld represents a pointer towards an additional set of parameters associated with the Scheduling Request resources.

= > sr-ProhibitTimer defines the minimum time between consecutive scheduling
Requests, i.e. this timer is started after sending a Scheduling Request and the UE must wait for this timer to expire before sending another Scheduling Request

=>  sr-TransMax specifies the maximum number of Scheduling Requests which can be sent to the Base Station. If the number of Scheduling Requests reaches this upper limit before receiving an uplink resource allocation, the UE releases its PUCCH and SRS resources and initiates the random access procedure.


2- Buffer Status Reporting:
               AUE uses Buffer Status Reporting (BSR) to provide the Base Station within information regarding the volume of uplink data waiting to be transferred. Buffer Status Reports are sent on the PUSCH using a MAC Control Element. The provision of a Buffer Status Report helps the Base Station to allocate an appropriate quantity of air-interface resources .

=> Both the PDCP and RLC layers provide the MAC layer with data volume figures so the UE is able lo signal the total buffered data volume to the Base Station.

=>Buffer Status Reports are sent per 'Logical Channel Group' (LCG) rather than per 'Logical Channel' (although it is possible for an LCG to include only a single Logical Channel). In general, Logical Channels with similar priority are linked to the same LCG. This allows the Base Station to differentiate between the volume of high priority data and the volume of lower priority data.

There are three categories of triggering mechanism for Buffer Status Reports (BSR):

1- Regular BSR triggering is applicable if:

->  new uplink data becomes available for transmission, and that uplink data belongs to a Logical Channel which has higher priority than the Logical Channels associated with the previously available uplink data.

-> new uplink data becomes available for transmission after having no uplink data  
available for transmission the retxBSR-Timer expires when there is uplink data waiting to be transferred.

-> The retxBSR-Timer has been specified to help avoid the deadlock situation which occurs when the Base Station fails to receive a Buffer Status Report while the UE believes
that reception has been successful, i.e. the UE fails to receive the request for a re-transmission. In this situation the UE waits for an uplink resource allocation but the Base Station does not provide any resources because it failed to receive the Buffer Status Report. The retxBSR-Timer helps to resolve the situation by triggering a re-transmission of the report.

2-Periodic BSR triggering is applicable if:
    the periodicBSR-Timer expires. This timer can be set to 'infinity' so periodic Buffer Status Reports are optional. The periodic timer is re-started after each Buffer Status Report transmission unless the 'truncated' report format is used.


3-Padding BSR triggering is applicable if:
    uplink resources have been allocated such that the number of padding bits equals or exceeds the size ofa Buffer Status Report. In this case, a Buffer Status Report is included within the uplink packet to reduce the quantity of padding, i.e. taking advantage of the unused uplink capacity.


= > Four formats have been specified for the Buffer Status Report:
 1- Short BSR,
 2- Short Truncated BSR,
 3- Long BSR and 
 4- Long Truncated BSR.

=>If the BSR is triggered using either the Regular or Periodic mechanisms then either a Long or Short BSR is generated. The Long BSR is designed to accommodate information regarding multiple LCG so this format is generated if more than a single LCG has uplink data to transfer. Otherwise, a Short BSR is generated to provide information regarding a single LCG.


=>Tfthe BSR is triggered using the Padding mechanism then the BSR format depends upon the quantity of padding which is available to accommodate the BSR. It is assumed that the quantity of padding is always at least as large as a Short BSR otherwise the Padding BSR
would not have been triggered. If there is sufficient padding to accommodate a Long BSR then a Long BSR is generated. Otherwise, if only a single LCG has data to transfer then a Short BSR is generated. Otherwise, if multiple LCG have data to transfer but the size of
the padding can only accommodate a Short BSR then Short Truncated BSR is generated for the LCG with the highest priority Logical Channel. Otherwise, a Long Truncated BSR is generated for the LCG with the highest priority Logical Channels.










=> The MAC Control Elements have the same format and have a fixed size. The actual payload of the MAC Control Element is I Byte. J\n additional I Byte subheader is included to identify the payload of the MAC Control Element. 

An LC ID value of 61 is used to identify a Short BSR, whereas an LCID value of 59 is used to identify a Short Truncated BSR (LCID stands for Logical Channel Identity but within this context it is used to identify a MAC CE rather than a Logical Channel)




=> The size and structure of a Short and Short Truncated BSR are the same. The only difference is that the Short BSR provides information when only a single LCG has data to transfer, whereas the Short Truncated LCG provides information regarding the LCG which includes the highest priority Logical Channel when multiple LCG have data to transfer.

=> The 5 bits used to quantify the Buffer Size. The values within this table have units of Bytes.




No comments:

Post a Comment