5G-NR: Bandwidth Part (BWP)

Introduction:

            A Bandwidth Part is a set of contiguous Common Resource Blocks. A Bandwidth Part may include all Common Resource Blocks within the channel bandwidth, or a subset of Common Resource Blocks

=>    Bandwidth Parts are an important aspect of 5G because they can be used to provide services to UE which do not support the full channel bandwidth, i.e. the Base Station and UE channel bandwidth capabilities do not need to match.

      ->For example, a Base Station could be configured with a 400 MHz channel bandwidth, while a UE may only support a 200 MHz channel bandwidth. In this case, the UE can be configured with a 200 MHz Bandwidth Part and can then receive services using a subset of the total channel bandwidth.

=> A UE can be configured with up to 4 downlink Bandwidth Parts per carrier and up to 4 uplink Bandwidth Parts per carrier. Only a single Bandwidth Part per carrier can be active in each direction. A UE receives the PDCCH and POSCH only within an active downlink Bandwidth Part. A UE transmits the PUCCH and PUSCH only within an active uplink Bandwidth Part. A UE can complete measurements outside the active bandwidth part but this can require the use of Measurement Gaps.

     Below Figure illustrates some example Bandwidth Part allocations for an operator using 2 x 400 MHz RF carriers. These examples illustrate the flexibility which Bandwidth Parts allow when configuring frequency domain resources.

=> the first UE is assumed to support the complete 400 MHz channel bandwidth and inter-band Carrier Aggregation

=> the second UE is assumed to support inter-band Carrier Aggregation but a maximum channel bandwidth of200 MHz

=> the third UE is assumed to support both inter and intra-band Carrier Aggregation with a maximum channel bandwidth of200 MHz. This combination allows the UE to use all 800 MHz of spcctrum simultaneously, i.e. a single active Bandwidth Part per Component Carrier.

=> the fourth VE is also assumed to support both inter and intra-band Carrier Aggregation. However, this UE is assumed to support a maximum channel bandwidth of 100 MHz and is configured with multiple Bandwidth Parts per Component Carrier

=> the fifth UE is assumed to support only one of the two operating bands and a maximum channel bandwidth of200 MHz. For the purposes of this example, the UE is allocated only a single Bandwidth Part to illustrate that the set of allocated Bandwidth Parts do not have to cover the complete channel bandwidth.

UE 1 configured with:

2 Camponent Carriers (inter-band Carrier Aggregation). 

Single Bandwidth Part per Carrier

 UE 2 configured with:

2 Component Carriers (inter-bond Carrier Aggregation)

2 Bandwidth Parts per Carrier

UE 3 configured with:

4 Campanent Carriers (intra & inter-band Carrier Aggregation)

Single Bandwidth Parts per Carrier

UE 4 configured with:

4 Camponent Carriers (intra & inter-band Carrier Aggregation)

Up to 4 Bandwidth Parts per Carrier

UE 5 configured with:

1 Component Carrier

1 Bandwidth Part

In above Figure, the second and third UE appear to have very similar configurations, i.e. both UE arc configured with 2 x 200 MHz Bandwidth Parts within each operating band. The second UE is configured with 2 Component Carriers and 2 Bandwidth Parts per carrier, whereas the third UE is configured with 4 Component Carriers and I Bandwidth Part per Carrier. This difference in configuration has implications upon some lower level procedures and also the RF performance requirements.

=> at the MAC layer there is a HARQ entity for each serving ce:11. The second UE which is configured with 2 Component Carriers would have 2 HARQ entities and HARQ re-transmissions can be switched between Bandwidth Parts by dynamically changing the active Bandwidth Part (field within the PDCCH DC] can be used to change the active Bandwidth Part). The third lJE which is configured with 4 Component Carriers would have 4 HARQ entities and HARQ re-transmissions cannot be switched between Component Carriers.

=> RF performance requirements such as out-of-band emissions are specified per carrier rather than per Bandwidth Part. This means that the second UE has to achieve its RF requirements at the edge of each 400 MHz carrier, while the third UE has to achieve its

RF requirements at the edge of each 200 MHz carrier.

BWP Types:

    A UE uses an 'Initial' Bandwidth Part when first accessing a cell. The Initial Downlink Bandwidth Part can be signalled within SIB-1 using the inilia/DownlinkBWP parameter structure presented in below table. This parameter structure uses the  locationAndBandwidth information element to specify the set of contiguous Common Resource Blocks belonging to the Initial Downlink Bandwidth Part. The value is coded using Resource Indication Value (RIV) rules with N size of BWP = 275 (these rules are described in section 3.6.4.2.2 within the context of allocating Resource Blocks for the POSCH). The RB start value which is derived from the locationAndBandwidth value is

added to the offsetToCarrier value  i.e. the starting position of the Bandwidth Part is relative to the first usable Resource Block. The initia/DownlinkBWP parameter structure also specifics the subcarrier spacing to be used for the Bandwidth Part and provides the UE with cell level information for receiving the PDCCH and PDSCH.

The initial Downlink BWP parameter structure can also be provided to the UE using dedicated signalling. If the parameter structure is not provided to a UE then the Initial Downlink Bandwidth Part is defined by the set of Rcsource Blocks belonging to the Control

Resource Set (CORESET) for the Type O PDCCH Common Search Space. These Resource Blocks can be deduced from information within the MIB.

Information regarding the Initial Uplink Bandwidth Part can also be signalled within SIB-1 or by using dedicated signalling.

The Base Station can use dedicated signalling to configure up to 4 Downlink Bandwidth Parts per cell and up to 4 Uplink Bandwidth Parts per cell. The parameter structure used to configure a Downlink Bandwidth Part. The Initial Bandwidth Part is referenced using an identity of 0, whereas other Bandwidth Parts are allocated an identity within the range 1 to 4

=> In the case of TDD, an Uplink and Downlink Bandwidth Part with the same bwp-ld share the same center frequency

=> The Base Station can dynamically switch the Active Bandwidth Part using the Bandwidth Part Indicator field within DCI Formats 0 and 1_1. The switching procedure is not instantaneous so the Base Station cannot allocate resources immediately after changing the Active Bandwidth Part. The switching delay is specified within 3GPP TS 38.133.

=> A UE can also be configured with a Default Downlink Bandwidth Part (identified using defaultDownlinkB WP-Id which points to one of the configured hwp-id values). If a UE is not explicitly provided with a Default Downlink Bandwidth Part then it is assumed to be

the Initial Downlink Bandwidth Part.

=> If a UE is configured with a bwp-lnactivityTimer then the UE switches back to the Default Downlink Bandwidth part after the inactivity timer has expired while using a non-Default Downlink Bandwidth Part.

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.

https://www.5gfundamental.com/2021/02/5gnr-scheduling-request.html

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.

5G-NR: SIGNALLING RADIO BEARERS:

5G-NR: SIGNALLING RADIO BEARERS:

Indroduction:

          The eNodeB is the Master Node so the majority of RRC signalling procedures terminate at the eNodeB rather than the gNodeB. Signalling Radio Bearer-0 (SRB0), SRB 1 and SRB2 terminate at the eNodeB. This means that the 4G RRC signalling protocol

specified in 3GPP TS 36.331 is applicable. SRB-I and SRB2 ,can be configured as 'split' SRB. This allows RRC messages to be transmitted and received by both the eNodeB and gNodeB.

      SRB3 can be setup at the request of the 5G Secondary Node. SRB3 terminates al the Secondary Node (gNode B) and so the 5G RRCsignalling protocol specified in 3GPP TS 38.331 is applicable. SRB3 is used for signalling procedures which are time sensitive with

respect to the gNode B, e.g. mobility procedures. SRB3 supports a limited number of signalling messages, i.e. RRC Reconjiguration, RRC Reconfiguration Complete and Measurement Report messages. 

SIGNALLING RADIO BEARERS:

=> The RRC signalling protocol operates between the UE and Base Station.

=> The Non Access Stratum (NAS) signalling protocol operates between the UE and AMF/SMF 5G NR in BULLETS.

=> Signalling Radio Bearers (SRB) are used to transfer RRC messages between the UE and Base Station. RRC messages can encapsulate NAS messages so SRB are also responsible for transferring NAS messages between the UE and Base Station. The NG Application
Protocol (NGAP) is used to transfer NAS messages between the Hase Station and AMF. NAS messages associated with Session Management terminate at the SMF rather than the AMF. The AMF acts a relay between the Base Station and SMF for Session Management NAS messages

=> below figure illustrates the protocol stacks used for both RRC and NAS signalling. The set of SRB provide a logical connection between the RRC layers within the UE and Base Station.

3GPP has specified 4 types ofSRB for New Radio (NR):

=> SRB-0 transfers RRC messages which use the Common Control Channel (CCCH) logical channel.

=>SRR-1, 2 and 3 transfer RRC messages which use the Dedicated Control Channel (DCCI-I) logical channel

=> SRB-1 supports RRC signalling between the UE and Base Station but can also encapsulate NAS messages prior to the setup of SRB2.

=> SRB-2 is always setup after security activation and is used to encapsulate NAS messages. SRB 2 messages arc handled with lower priority relative to SRB-1 messages.

=> SRB-3 is applicable when using the 'E-UTRAN New Radio Dual Connectivity' (EN-DC) configuration. In this case, SRIJ 0, 1 and 2 are managed by the E-UTRAN Master Node while SRB 3 is managed by the NR Secondary Node. SRB 3 allows RRC messages

to be transferred directly between the Secondary Node and the UE. SRB 3 is limited to transferring RRC Reconfiguration and Measurement Report messages. These messages arc a subset of those transferred by SRB-1

=> Below figure illustrates the concept of a 'Split SRB' which is applicalblc to SRB-1 and SRB 2 when using a Dual Connectivity configuration. A split SRB means that RRC messages can be transferred using the Master Node air-interface, the Secondary Node airinterface

or both air-interfaces. The use of both air-interfaces helps to improve reliability. The concept is applicable to both the uplink and downlink so the UE can be instructed to transmit uplink RRC messages on both air-interfaces

      Above  is based upon the Non-Standalone EN-DC configuration so SRB 3 is also shown within the Secondary Node. SRB O is only applicable to the Master Node. Splitting SRB I and SRB 2 creates SRB IS and SRB 2S which use the X2 Application Protocol (X2AP) to transfer RRC messages to and from the Secondary Node

The RRC messages associated with each SRB are presented in below Table

SRB-0 uses Transparent Mode (TM) RLC while SRB 1 and 2 use Acknowledged Mode (AM) RLC.

=>SRB-0 transfers messages associated with establishing, re-establishing and resuming a connection. The uplink messages are transmitted as MSG3 within the Random Access procedure, while the downllink messages can be transmitted as MSG4. The VE is allocated a DCCH logical channel once an RRC connection has been established so SR.B 1 and 2 are able to transfer subsequent messages.

=>The RRCResumeRequest message is an exception which has been specified to use the CCCH logical channel rather than the CCCH logical channel. The CCCHI logical channel is intended to transfer larger messages than the CCCH logical channel

=> After security activation, all messages transferred by SRB-I, 2 and 3 arc integrity protected and ciphered by the Packet Data Convergence Protocol (PDCP). In addition, NAS messages use integrity protection and ciphering between the UE and AMF.

=> The Uplink Information Transfer and Downlink Information Transfer messages are dedicated to sending NAS messages and do not include any RRC signalling content. These messages arc transfcned using SRB 2 unless SRB2 has not yet been configured

=> 3GPP References: TS 38.331, TS 37.340