5G NR Bandwidth Part (BWP)

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

5G Network Architecture

5G Network Architecture:

Introduction:

In this blog, we will see 5G network architecture nodes, their functionality and interfaces between different nodes. it is vary important to know about all the nodes and their functionality to understand the whole concept of 5G architecture.

Below description is taken from 3gpp TS.

In Detailed:

Core network service based architecture:

AMF: Access and Mobility Management Function:-
Like in LTE MME, In NR AMF provide the similar services to the access network and core network component. general functions of AMF are to provide the mobility management, Authentication management, NAS related management to UE and SMF selection types of services.

=>Termination point for RAN Control Plane interfaces (NG2).

=>UE Authentication and Access Security procedures.

=>Mobility Management (handover Reach-ability, Idle/Active Mode mobility state. handling)

=>Registration Area management.

=>Access Authorization including check of roaming rights;

=>Session Management Function (SMF) selection

=>NAS(non access stratum) signaling including NAS Ciphering and Integrity protection, termination of MM NAS and forwarding of SM NAS (NG1).

=>AMF obtains information related to MM from UDM.

=>May include the Network Slice Selection Function (NSSF)

=>Attach procedure without session management adopted in CIoT implemented in EPC is defined also in 5GCN (registration management procedure)

=>User Plane (UP) selection and termination of NG4 interface (AMF has part of the MME and PGW functionality from EPC.

AUSF: services Authentication Server Function: The main function of AUSF is to provide the services for Authentication procedure and communicate directly with UDM and AMF for accessing and providing the subscriber information.

=>Contains mainly the EAP authentication server functionality

=>Storage for Keys (part of HSS from EPC)

=>Obtains authentication vectors from UDM and achieves UE authentication. 72 NF Repository Function (NRF)

=>Provides profiles of Network Function (NF) instances and their supported services within the network

=>Service discovery function, maintains NF profile and available NF instances. (not present in EPC world) NRF offers to other NFs the following services:

=>Nnrf_NFManagement

=>Nnrf_NFDiscovery

=>OAuth2 Authorization Core network functions 73 Core network functions Network Exposure Function (NEF)

=>Provides security for services or AF accessing 5G Core nodes

=>Seen as a proxy, or API aggregation point, or translator into the Core Network

Policy Control Function (PCF)

=>Expected to have similarities with the existing policy framework (4G PCRF)

=>Updates to include the addition of 5G standardized mobility based policies (part of the PCRF functionality from EPC)

Session Management Function (SMF) :

=>DHCP functions

=>Termination of NAS signaling related to session management

=>Sending QoS/policy N2 information to the Access Network (AN) via AMF
=>Session Management information obtained from UDM

=>DL data notification

=>Selection and control of UP function

=>Control part of policy enforcement and QoS.

=>UE IP address allocation & management

=>Policy and Offline/Online charging interface termination

=>Policy enforcement control part

=>Lawful intercept (CP and interface to LI System) Core network functions.

Unified Data Management (UDM) :

=>Similar functionality as the HSS in Release 14 EPC User Data Convergence (UDC) concept: separates user information storage and management from the front end

=>User Data Repository (UDR): storing and managing subscriber information processing and network policies

=>The front-end section: Authentication Server Function (AUSF) for authentication processing and Policy Control Function (PCF). Core network functions

User Plane Function (UPF) :

=>Allows for numerous configurations which essential for latency reduction
=>Anchor point for Intra-/Inter-RAT mobility

=>Packet routing and forwarding

=>QoS handling for User Plane

=>Packet inspection and PCC rule enforcement

=>Lawful intercept (UP Collection)

Roaming interface (UP)

=>May integrate the FW and Network Address Translation (NAT) functions
=>Traffic counting and reporting (UPF includes SGW and PGW functionalities)

Application Functions (AF)

=>Services considered to be trusted by the operator

=>Can access Network Functions directly or via the NEF

=>AF can use the PCF interface PCF for requesting a given QoS applied to an IP data flow (e.g., VoIP).

=>Un-trusted or third-party AFs would access the Network Functions through the NEF (same as AF in EPC) Network Slice Selection Functions (NSSF)

=>Selecting of the Network Slice instances to a UE.

=>Determining the AMF set to be used to serve the UE.

=>The Application Function (AF) can be a mutually authenticated third party. – Could be a specific 3rd party with a direct http2 interface or a inter-working gateway exposing alternative API’s to external applications.

=>Enables applications to directly control Policy (reserve network resource, enforce SLAs), create network Slices, learn device capabilities and adapt service accordingly, invoke other VNF’s within the network…

=>Can also subscribe to events and have direct understanding of how the network behaves in relation to the service delivered.

Data Network (DN):

=> Services offered: Operator services, Internet access, 3rd party

TDD-UL-DL-slot Configuration

TDD Slot configuration:

5G provides a feature using which each symbol within a slot can either be used to schedule a Uplink packet (U) or Downlink packet(D) or Flexible (F). A symbol marked as Flexible means it can be used for either Uplink or Downlink as per requirement.

In NR, slot format configuration can be done in a static, semi-static or fully dynamic fashion. The configuration for Slot format would be broadcast from SIB1 or/and configured with the RRC Connection Reconfiguration message. The configuration of Static and semi-static for a slot is done using RRC while dynamic slot configuration is done using PDCCH DCI.

Note that if a slot configuration is not provided by the network through RRC messages, all the slots/symbols are considered as flexible by default.

Slot configuration via RRC consists of two parts.
1- Providing UE with Cell-Specific Slot format Configuration (tdd-UL-DL-ConfigurationCommon)
2- Providing UE with dedicated Slot format configuration (tdd-UL-DL-ConfigurationDedicated)

1- :RRC: tdd-UL-DL-ConfigurationCommon

In LTE TDD, there are 7 predefined patterns for UL and DL allocation in a radio frame. In 5G/NR, we don't have any predefined pattern. Instead, we can define the pattern in a much more flexible way using several parameters as shown below.

The IE tdd-UL-DL-ConfigurationCommon is either broadcasted within SIB1 or configured to the UE using dedicated RRC signaling.

When it is provided by RRC signaling then it is mandatory IE and when it is provided via SIB1, this IE is optional for TDD cells.

Structure of IE tdd-UL-DL-ConfigurationCommon:

A reference SCS configuration µref by referenceSubcarrierSpacing. at least one pattern is available. a pattern1 is mandatory and pattern2 is optional. Both pattern1 and pattern2 contain the same parameters but usually of different values.

The configuration in pattern1 provides

- a slot configuration period of P msec by dl-UL-TransmissionPeriodicity

- a number of slots d_slots with only downlink symbols by nrofDownlinkSlots

- a number of downlink symbols d_sym by nrofDownlinkSymbols

- a number of slots u_slots with only uplink symbols by nrofUplinkSlots

- a number of uplink symbols u_sym by nrofUplinkSymbo

dl-UL-TransmissionPeriodicity (P)	µref(SCS)
0.5	all
0.625	3
1	all
1.25	2,3
2	all
2.5	1,2,3
5	all
10	all

All the configurations provided by pattern1 is used to conclude below mentioned points.

=> a slot configuration perio of P mesc.

=> It includes S = P X 2^µ

For example, let P = 2.5 ms and µ = 3, in this case, there are 20 slots within the slot configuration period.

=> Total S slots reserve, first d_slots slots for downlink symbols and last u_slots slots for uplink symbols.

=> First d_symsymbols within the slot immediately following the last full downlink slot and last u_symsymbols in the slot preceding the first full uplink slot.

=> Consider the remaining symbols as flexible symbols. The flexible symbols can be configured for uplink and downlink symbols.

No. of flexible symbols = (S1 - d_slots- u_slots).14 - d_sym - u_sym

Note: The first symbol every 20/P period is a first symbol in an even frame.

Example:

RRC: tdd-UL-DL-ConfigurationDedicated:

The UE specific information to the slot configuration is necessary to help the network adjust DL/UL pattern based on the UE needs.

The network sends the UE-specific slot configuration using IE tdd-UL-DL-ConfigurationDedicated towards UE which further allocates the unallocated (flexible) slots and symbols.

The IE tdd-UL-DL- ConfigurationDedicated is optional. and if the network doesn’t configure this IE, the UE uses tdd-UL-DL-ConfigurationCommon IE alone to derive the slot configuration for transmission.

The configuration in tdd-UL-DL ConfigurationDedicated iE can overrides only flexible symbols per slot over the number of slots as provided by tdd-UL-DL- ConfigurationCommon that is this dedicated configuration can not change the slots/symbols which are already allocated for downlink and uplink via tdd-UL-DL-ConfigurationCommon IE.

The contents of tdd-UL-DL- ConfigurationDedicated IE are presented below;

The tdd-UL-DL-ConfigurationDedicated IE provides individual slot configuration(s) using slotSpecificConfigurationsToAddModList. Each slot configuration contains the following parameters ;

slotIndex identifies a slot within a slot configuration period given in tdd-UL-DL-configurationCommon IE.

symbols structure provides the direction (downlink or uplink) for the symbols within the slot that is being configured.

- allDownlink indicates that all symbols in this slot are used for downlink symbols;

- allUplink indicates that all symbols in this slot are used for uplink symbol;

- explicit indicates explicitly how many symbols in the beginning and end of this slot are allocated to downlink and uplink, respectively.

- nrofDownlinkSymbols is the number of consecutive downlink symbols in the beginning of the slot identified by the slot index.

- nrofUplinkSymbols is the number of consecutive uplink symbols at the end of the slot identified by the slot index.

If nrofDownlinkSymbols IE is not provided, there are no downlink symbols in the slot and if nrofUplinkSymbols IE is not provided, there are no uplink symbols in the slot. The remaining symbols in the slot are the flexible symbol.

The following illustration shows how UE-specific slot configuration overrides flexible slots/symbols provided by the cell-specific configuration.

It is important to note that a symbol can only be flexible if and only if both UE and cell-specific slot configurations indicate that the respective symbol to be flexible.

Slot Formats:

Slot format table from TS (38.213 Table 11.1.1-1).

Symbol Number in a slot

Format

62-254

Reserved

255

UE determines the slot format for the slot based on tdd-UL-DL-ConfigurationCommon, or tdd-ULDL-

D : Downlink, U : Uplink, F : Flexible

What if TDD-UL-DL-ConfigCommon is not configure ?
If a UE is not configured to monitor PDCCH for DCI format 2-0, for a set of symbols of a slot that are indicated as flexible by TDD-UL-DL-ConfigurationCommon or TDD-UL-DL-ConfigDedicated, or when TDD-UL-DL-ConfigurationCommon and TDD-UL-DL-ConfigDedicated are not provided to the UE

=> the UE receives PDSCH or CSI-RS in the set of symbols of the slot if the UE receives a corresponding indication by a DCI format 1_0, DCI format 1_1, or DCI format 0_1.

=> the UE transmits PUSCH, PUCCH, PRACH, or SRS in the set of symbols of the slot if the UE receives a corresponding indication by a DCI format 0_0, DCI format 0_1, DCI format 1_0, DCI format 1_1, or DCI format 2_3

5G(NR)-Fundamentals