Model Features
The 5G Frame Structure
In 5G-NR the physical time and frequency resources correspond to OFDM symbols (time) and subcarriers (frequency) respectively. The physical radio resources in each frame (or subframes) can be considered as a resource grid made up of OFDM subcarriers in the frequency domain, and OFDM symbols in the time domain. The smallest physical resource, known as the resource element (RE), comprises one subcarrier (frequency) and one OFDM symbol (time).
5G NR supports a flexible OFDM numerology to support diverse spectrum bands/types and deployment models. The numerology, \(\mu\), can take values from 0 to 4 and specifies the Subcarrier-Spacing (SCS) as \(15 \times 2^{\mu}\) kHz and a slot length of \(\frac{1}{2^{\mu}}\) ms. With \(\mu\) varying from 0 to 4, SCS varies from 15 to 240 kHz. NetSim supports \(\mu\) = 0, 1, 2 for FR1 and \(\mu\) = 2, 3 for FR2. The setting \(\mu = 0\) corresponds to the LTE (4G) system configuration.
Figure-1: NR Frame Structure when numerology μ is set to 3
In the time domain (to support backwards compatibility with LTE) the frame length in 5G NR is set to 10 ms, and each frame is composed of 10 subframes of 1 ms each. The 1 ms subframe is then divided into one or more slots in 5G, whereas LTE had exactly two slots in a subframe. The slot length depends on the numerology, \(\mu,\) and is equal to \(\frac{1}{2^{\mu}}\) ms. The number of OFDM symbols per slot is 14 for a configuration using normal cyclic prefixes. For extended cyclic prefixes, the number of OFDM symbols per slot is 12. See section 3.9.9.1- Numerologies, for more information.
In the frequency domain, the number of subcarriers per physical resource block (PRB) is fixed to 12, and the Subcarrier-Spacing (SCS) is \(15 \times 2^{\mu}\) kHz.
Physical Resource Block (PRB): The PRB is the minimum unit of resource allocation in the frequency domain, i.e., the width of a resource block, 180 kHz. It is a system-level constant. For example, a PRB can either contain 12 subcarriers of 15 kHz each. As a formula, \(PRB_{Width} = 12 \times 15 \times 2^{\mu}\) kHz.
Resource Block (RB): It is the minimum unit of resource allocation, i.e., 1 PRB by 1 slot. NetSim’s scheduler performs resource allocation every subframe (TTI, transmission time interval), however, the granularity of resource allocation is 1 slot in time, i.e., the duration of a resource block, and 1 PRB in frequency. One sub-carrier by one symbol is defined as a resource element.
Data Transmission Overview
In NetSim only the DL and UL traffic channels (PDSCH and PUSCH) are modelled. The control signals and control channels are abstracted; these abstractions are explained in various parts of this document.
In TDD operation the UL and DL transmissions are separated in the time-domain over different frames/subframes/slots/symbols and use the same carrier frequency. In FDD operation UL and DL transmissions are separated in the frequency domain, with different frequencies used for UL and for DL transmission.
Higher layer packets arrive at the RLC buffer for each UE and each gNB.
Prior to transmission, the MAC scheduler in the gNB determines the allocation of PRBs (PHY resources) to users. In this module the Transport block size (TBS) (explained in 3.9.12) is computed using the channel quality index (CQI). The CQI is determined by the Adaptive Modulation and Coding (AMC) function based on the SNR.
Now, the received SNR is determined from a) large scale pathloss and shadowing calculated per the 3GPP’s stochastic propagation models, and b) the small-scale fading which leads to beamforming gains when using MIMO . These models provide signal attenuation as an output. Several parameters are used in the model, including the distance between the transmitter and the receiver. These computations are executed by each associated UE-gNB pair, in DL and UL, at the start of simulation and again at every mobility event. In calculating SNR, the noise power is obtained from \(N = k \times T \times B\).
Note that the SNR/CQI is not computed/fed-back using reference signals/control channels but is computed on the data channel (PDSCH and PUSCH). Then it is assumed to be instantaneously known to the transmitter and receiver. This assumption is known as perfect CSIT and CSIR. With perfect CSIT the transmitter can adapt its transmission rate (MCS) relative to the instantaneous channel state (SNR).
Based on this SNR the AMC determines a wideband CQI which indicates the highest rate Modulation and coding scheme (MCS), that it can reliably decode, if the entire system bandwidth were allocated to that user. The modulation scheme defines the number of bits that can be carried by a single RE. Modulation schemes supported by 5G include QPSK (2 bits), 16 QAM (4 bits), 64 QAM (6 bits), and 256 QAM (8 bits). The code rate defines the proportion of bits transmitted that are useful. It is computed as the ratio of useful bits by total bits that are transmitted. The modulation order\(\ Q_{m}\), which denotes the number of bits per RE, and the code rate denoted by \(R\) are jointly encoded as a modulation and coding scheme (MCS) index. These values of \(Q_{m}\) and \(R\) are then passed to the TBS determination function.
At each gNB a frame of length 10 ms is started. Each frame in turn starts 10 sub frames each of length 1ms. Each sub frame then starts a certain number of slots based on numerology.
The PHY layer in NetSim then notifies the MAC about the slot start. The MAC sub layer in turn seeks a buffer status report from the RLC layer and invokes the MAC scheduler. It then notifies the RLC of the transmission. The RLC then transmits the transport block to the PHY layer. The downlink and uplink data channels (PDSCH, PUSCH) receive this transport block as its service data unit (SDU), which is then processed and transmitted over the radio interface.
5G NR Stack
Figure-2: User Plane Protocol Stack
Figure-3: Control Plane Protocol Stack
SDAP (Specification: 37.324)
The features in NetSim SDAP are: - Mapping between a QoS flow and a data radio bearer (DRB) per the new QoS framework - Marking QoS flow ID (QFI) in both DL and UL packets.
Figure-4: 5G Quality of Services (QoS)
In NetSim the SDAP module’s Set Mode function maps the Application QoS Type (which can be set in NetSim’s GUI) to RLC mode.
Application QoS (Set in NetSim GUI) |
RLC Mode |
Priority |
|---|---|---|
nrtPS, ertPS, rtPS, UGS |
UM Mode |
GBR |
BE |
AM Mode |
Non-GBR |
Table-1: Mapping of Application QoS to RLC mode in NetSim
In the same function, the logical channel is also set to DTCH which is the dedicated traffic channel. Next comes the MAC_OUT function. This function determines what the current device is connected to i.e., if it is a UE, it finds the associated gNB, else if the current device is a gNB it finds the associated UEs. The SDAP header is then added which contains the QFI. Recall that the NetSim 5G NR library only supports unicast transmissions (i.e., broadcast is not supported).
After this is the SendToNetwork function. This function is called when a packet is at MAC-IN at the receiver. The function creates the Network Event, sets all the Event-Details and sends the packet to the IP layer. And finally, the HandleMacIN function decides whether the packet must be sent to another interface (if intermediate device) or sent to a network layer (if end device). The header is stripped off.
5G QoS characteristics
5G Quality of Service (QoS) model is based on QoS Flows. Each QoS flow has a unique identifier called QoS Flow Identifier (QFI). There are two types of flows: Guaranteed Bit Rate (GBR) QoS Flows and Non-GBR QoS Flows. Every QoS flow has a QoS profile that includes QoS parameters and QoS characteristics. Applicable parameters depend on GBR or non-GBR flow type. QoS characteristics are standardized or dynamically configured.
The current NetSim COTS build does not implement 5G QoS. All traffic flowing is categorized as non-GBR. A framework has been provided for users to modify the underlying code to implement QoS flow categorization in terms of:
Resource type (GBR, Delay critical GBR or Non-GBR);
Priority level.
Packet delay budget.
Packet error rate.
RLC (Based on specification 38.322)
NetSim RLC entity is based on 3GPP Technical specification 38.322. The RLC layer sits between PDCP and MAC layer. The RLC has three different modes of operation: TM (Transparent Mode), UM (Unacknowledged Mode) and AM (Acknowledge mode) as shown in Figure-5.
Figure-5: RLC Modes of operation and RLC Entities
A summary of key features of these modes is as follows:
TM: No RLC Header, Buffering at Tx only, No Segmentation/Reassembly, No feedback (i.e., No ACK/NACK)
UM: RLC Header, Buffering at both Tx and Rx, Segmentation/Reassembly, No feedback (i.e., No ACK/NACK)
AM: RLC Header, Buffering at both Tx and Rx, Segmentation/Reassembly, Feedback (i.e., ACK/NACK)
Each of these modes can both transmit and receive data. In TM and UM, separate entity is used for transmission and reception, but in AM a single RLC entity perform both transmission and reception,
NetSim implements all the 7 entities for the RLC that are shown in Figure-5. Note that each of logical channels use a specific RLC mode:
BCCH, PCCH, CCCH use RLC TM only.
DCCH uses RLC AM only.
DTCH uses RLC UM or AM. (Which mode is used for each DTCH channel, is determined by RRC message).
The RLC entities provide the RLC service interface to the upper PDCP layer and the MAC service interface to the lower MAC layer. The RLC entities use the PDCP service interface from the upper PDCP layer and the MAC service interface from the lower MAC layer.
UM stands for 'Unacknowledged Mode'. 'Unacknowledged Mode' means 'it does not require any reception response from the other party'. 'Reception response' simply means 'ACK' or 'NACK' from the other party. (UM mode is similar to TM mode in that it does not require any ACK/NACK from the other party, but it is different from TM in that it has its own header)
The RLC transmit side:
Buffers the data and generates an RLC Header.
Segmentation of the RLC SDU and modification RLC Header (Some fields in RLC header may be changed based on the segmentation status)
Adds RLC header.
NOTE: If you compare this in LTE process, it seems that UM RLC does not perform any 'Concatenation'. According to the following statement from 38.322 v0.1.0, the 'concatenation' process is moved to MAC layer. From RAN2 NR#1: Working assumption on no RLC concatenation taken at RAN2#96 is confirmed (i.e., concatenation of RLC PDUS is performed in MAC).
The RLC on the receive side:
Buffers. Here the RLC waits for all the fragments to arrive.
Reorders, if required
Strips the RLC header.
Reassembles
Figure-6: RLC UM working.
NetSim GUI RLC Configurable parameters
The following timers are configured per TS 38.331:
t-PollRetransmit: This timer is used by the transmitting side of an AM RLC entity in order to retransmit a poll. The default value in NetSim is set to ms5 (5 milliseconds). Range is provided in the GUI dropdown menu.
t-Reassembly: This timer is used by the receiving side of an AM RLC entity and receiving UM RLC entity in order to detect loss of RLC PDUs at the lower layer. If t-Reassembly is running, t-Reassembly shall not be started additionally, i.e., only one t-Reassembly per RLC entity is running at a given time. The default value in NetSim is set to ms5 (5 milliseconds). Range is provided in the GUI dropdown menu.
t-StatusProhibit: This timer is used by the receiving side of an AM RLC entity in order to prohibit transmission of a STATUS PDU. Default value in NetSim is set to ms5 (5 milliseconds). Range is provided in the GUI dropdown menu. The following parameters are configured per TS 38.331 [5]:
maxRetxThreshold: This parameter is used by the transmitting side of each AM RLC entity to limit the number of retransmissions corresponding to an RLC SDU, including its segments. Default value in NetSim is set to t1. Range is provided in the GUI dropdown menu.
pollPDU: This parameter is used by the transmitting side of each AM RLC entity to trigger a poll for every pollPDU PDUs. Default value in NetSim is set to p4(PDUs). Range is provided in the GUI dropdown menu.
pollByte: This parameter is used by the transmitting side of each AM RLC entity to trigger a poll for every pollByte bytes. Default value in NetSim is set as kB25 (KBytes). Range is provided in the GUI dropdown menu.
RLC-AM (Based on specification 38.322)
AM stands for 'Acknowledge Mode'. This means an ACK/NACK is required from the receiver unlike RLC-UM where no ACK/NACK is required from the receiver. The code for RLC-AM mode is written in the file LTENR RLC AM.c
Figure-7: RLC AM Working
The functionality of RLC-AM is:
After the RLC transmitter does the segmentation/concatenation process, it adds an RLC header and then it creates two identical copies and transmits the one copy of the data out to lower layer (MAC) and sends another copy to Retransmission buffer.
If the RLC gets Nack or does not get any response from the receiver for a certain period of time, the RLC PDU in the retransmission buffer gets transmitted again. If the RLC gets ACK, the copy of the packet in retransmission buffer is discarded.
There are four buffers maintained in RLC-AM. There is no size defined in the standard and hence NetSim implements an infinite buffer (see LTENR RLC.h and LTENR RLCBuffer.c for related code). There are 3 buffers for transmit operations and 1 for receive operation:
Transmission buffer: Queues SDUs received from higher layer (PDCP)
Transmitted buffer: Queues SDUs that have been transmitted but for which ACK/NACK has not yet received.
Re-transmission Buffer: Queues RLC SDUs which are considered for retransmission. (i.e. for which NACK has been received)
Reception Buffer: Queues fragments of SDUs (receiver side)
The MAC sub layer then seeks a Buffer Status Report from the RLC. Here the packet is added to the Transmission Buffer. Then based on the MAC scheduler, the MAC layer sends a notification to RLC, which in turn sends a packet by first checking the Re Transmission Buffer followed by the Transmission-Buffer.
The T POLLRetransmit determines if a packet needs to be re-transmitted. If RLCAM- Ack is not received, the packet is moved from transmitted buffer to retransmission buffer. The codes for T POLLRetransmit are in the section #pragma region RLCAM T POLLRetransmit.
Transmit Operations
The transmitting side of an AM RLC entity shall prioritize transmission of RLC control PDUs over AMD PDUs. The transmitting side of an AM RLC entity shall prioritize transmission of AMD PDUs containing previously transmitted RLC SDUs or RLC SDU segments over transmission of AMD PDUs containing not previously transmitted RLC SDUs or RLC SDU segments. The transmitting side of an AM RLC entity shall maintain a transmitting window according to the state variable
TX Next Ack as follows:
a SN falls within the transmitting window if TX Next Ack <= SN < TX Next Ack + AM Window Size;
a SN falls outside of the transmitting window otherwise.
The transmitting side of an AM RLC entity shall not submit to lower layer any AMD PDU whose SN falls outside of the transmitting window.
For each RLC SDU received from the upper layer, the AM RLC entity shall:
associate a SN with the RLC SDU equal to TX Next and construct an AMD PDU by setting the SN of the AMD PDU to TX Next;
increment TX Next by one.
When submitting an AMD PDU that contains a segment of an RLC SDU, to lower layer, the transmitting side of an AM.
RLC entity shall:
set the SN of the AMD PDU to the SN of the corresponding RLC SDU.
The transmitting side of an AM RLC entity can receive a positive acknowledgement (confirmation of successful reception by its peer AM RLC entity) for an RLC SDU by the following:
STATUS PDU from its peer AM RLC entity.
When receiving a positive acknowledgement for an RLC SDU with SN = x, the transmitting side of an AM RLC entity shall:
send an indication to the upper layers of successful delivery of the RLC SDU;
set TX Next Ack equal to the SN of the RLC SDU with the smallest SN, whose SN falls within the range
TX Next Ack \(\leq \ \) SN \(\leq \ \) TX_Next and for which a positive acknowledgment has not been received yet.
Receive Operations
The receiving side of an AM RLC entity shall maintain a receiving window according to the state variable RX Next as follows:
a SN falls within the receiving window if RX Next \(\leq \ \) SN < RX Next + AM Window Size;
a SN falls outside of the receiving window otherwise.
When receiving an AMD PDU from lower layer, the receiving side of an AM RLC entity shall:
either discard the received AMD PDU or place it in the reception buffer.
if the received AMD PDU was placed in the reception buffer:
update state variables, reassemble and deliver RLC SDUs to upper layer and start/stop t-Reassembly as needed when t-Reassembly expires, the receiving side of an AM RLC entity shall:
update state variables and start t-Reassembly as needed.
After submitting an AMD PDU including a poll to lower layer, the transmitting side of an AM RLC entity shall:
set POLL SN to the highest SN of the AMD PDU among the AMD PDUs submitted to lower layer;
if t-PollRetransmit is not running:
start t-PollRetransmit.
else:
restart t-PollRetransmit
Actions when a RLC PDU is received from a lower layer.
On receiving the AMPDU NetSim checks if
It is within the receive window.
The packet is not already received i.e. not a duplicate packet.
If both the conditions are true, the AMPDU is placed in the Reception Buffer and the Reassembly Timer is started. If the PDU has a Poll Request then it starts constructing the StatusPDU.
Reception of a STATUS report
Upon reception of a STATUS report from the receiving RLC AM entity the transmitting side of an AM RLC entity shall:
if the STATUS report comprises a positive or negative acknowledgement for the RLC SDU with sequence number equal to POLL SN:
if t-PollRetransmit is running:
stop and reset t-PollRetransmit.
PDCP (Based on specification 38.322)
The PDCP layer receives a packet (data/control) from the upper layer, executes the PDCP functions and then transmits it to a lower layer.
PDCP Entity: The PDCP entities are located in the PDCP sublayer. NetSim currently implements one PDCP entity per UE (users can add more by modifying the code). The same PDCP entity is associated with both the control and the user plane.
The PDCP functionality supported in NetSim is:
Transmit PDCP SDU
Sets the PDCP Sequence Number
Adds RLC Header.
Calls RLC service primitive.
PDCP Association
This call back function is invoked when the UE associates/dissociates from a gNB.
Maintenance of PDCP sequence numbers (to know more check the PDCP entity structure)
Discard Timer:
When the discardTimer expires for a PDCP SDU, or the successful delivery of a PDCP SDU is confirmed by PDCP status report, the transmitting PDCP entity shall discard the PDCP SDU along with the corresponding PDCP Data PDU.
Discarding a PDCP SDU already associated with a PDCP SN causes a SN gap in the transmitted PDCP Data PDUs, which increases PDCP reordering delay in the receiving PDCP entity.
Transmission Buffer (size is assumed to be infinite): This is where PDCP SDU's are stored before being sent down to a lower layer.
MAC Layer
Overview
NetSim 5G NR MAC implements the following features:
Multiplexing/de-multiplexing of MAC SDUs into/from transport blocks for DL-SCH and UL-SCH data transfer.
Buffer status reporting.
MAC Scheduler.
MAC Scheduler: Introduction
Base stations (gNBs) generally deal with multiple mobile stations UEs, some of which require larger bandwidths than others and some of which have better connections (signal quality) than others. In ideal circumstances the base station has plenty of resources (e.g., bandwidth) and each UE gets the resources it needs. However, usually resources are limited, and the base station needs some way of fairly allocating the resources between the UEs.
Consider the downlink of a single gNB 5G cellular system. Several\(\ \)UEs are receiving data from ongoing transfers, for example, TCP controlled file downloads. Assuming that the bottleneck on the transfer path for these connections is this gNB to UE wireless access, the downlink per-UE queues in the gNB will be nonempty. At the beginning of each downlink slot (TTI) the gNB scheduler has to decide which of the UEs’ waiting data to transmit in that slot.
At each gNB the MAC scheduler decides the PRB allocation, per carrier, per TTI (slot), in the PDSCH (DL) and in the PUSCH (UL). Control packets such as the buffer status report (BSR) and UL assignment, are assumed to be sent out of band. The resources for transmission of these control packets are part of Overhead as defined in 3.9.21.
Round Robin Scheduler
It divides the available PRBs among the active flows, i.e., those logical channels which have a non-empty RLC queue. The MCS for each user is calculated according to the received CQIs.
Proportional Fair Scheduler
For data transfers, an important performance measure is long term throughput in bits/second, say, \(T_{i},\ \ 1 \leq i \leq n,\) where \(n\) is the number of UEs. One approach to designing a scheduler is to evaluate the goodness of the throughput vector \((T_{1},\ \cdots,\ T_{n})\) by a network utility, which is the sum of individual user utilities. The utility (or, usefulness) of a throughput \(T,\ \)to a user, increases with increasing throughput, but for large throughputs, increasing throughput further gives diminishing increase in usefulness. This property is modeled as a nondecreasing concave function of throughput. A common measure of utility is the log function, i.e., for the throughput vector \(\left( T_{1},\ \cdots,\ T_{n} \right),\) the utility of throughput \(T_{i}\) to user \(i\) is measured as \(\ln T_{i}\). The network utility is, then, given as
A Proportional Fair (PF) scheduler works by scheduling users in slots so that the utility of their long-term throughputs is maximized. In the 5G setting, the scheduling decisions at the beginning of a TTI are based on the physical rates that each UE can get in each Resource Block (RB). If we are given statistical models of these rates, then a nonlinear optimization problem can be formulated and solved to obtain the schedule. This is not a practical approach, however, and a learning algorithm is desired, which, based on slot-by-slot CSI measurements, takes scheduling decisions, which lead to PF optimal throughputs.
The Proportional Fair Scheduler is such a learning scheduler, that uses the throughputs that users are expected to get in the next slot, and the average throughputs they have each obtained up to this slot, to decide which UEs to schedule in the next slot. The practical PF scheme, described below, is based on information such as a presently available data rate for each user in each RB in the next slot (obtained by CSI measurements), and an average data rate over an immediately prior predetermined interval for each user.
Implementation
Since NetSim uses a flat fading model, in each slot, each UE achieves the same MCS in every RB in that slot. In other words, different UEs achieve, possibly, different MCSs, but a single UE has the same MCS across all RBs in a slot. Under this assumption, it is optimal to schedule the same UE in every RB in that slot. Since the channel condition can stochastically vary from slot to slot, the MCSs that the UEs achieve will vary from slot to slot. Under this assumption, the following algorithm is Proportional Fair optimal.
Let \(i,j\) denote generic users and let \(t\ \)be the slot index. A resource block index \(k\) is required given the flat fading assumption. Let \(M_{i}(t)\) be the MCS seen by user \(i\) at time (slot) \(t\). The channel CQI (derived from the data channel SINR) is used by the adaptive modulation and coding (AMC) module to determine the MCS. We denote by \(S(M,\ B)\) the TB size in bits for a given MCS, \(M\), and a given number of physical resource blocks (PRBs), \(B\). The achievable rate \(R_{i}\ (t)\) in bit/s for user \(i\) in slot \(t\) is defined as
where \(\tau\) is the TTI, i.e., \(1\) slot duration. At the start of each slot \(t\), the user index \(i^{*}(t)\) - selected by the scheduler - to which required PRBs (per that user’s demand) is assigned at time \(t\) is determined as
This selection is carried out by the scheduler till all PRBs in slot \(t\) are allocated. In the above expression, \(T_{j}(t)\) is the past throughput performance perceived by the user \(j,\) and is defined as
where \(\ \alpha\) is the time constant (in units of slots) of the exponential moving average. NetSim uses \(\alpha = 50\), and \({\widehat{T}}_{j}(t)\) is the actual throughput achieved by the user \(i\) in the subframe \(t\). If \({\widehat{B}}_{j}(t)\) is the number of PRBs allocated to user \(j\), we finally get
The value of α can be changed by the user by editing the NetSim’s source code; it cannot be changed via the GUI. The PF scheduler thus selects a user having the maximum among values obtained by dividing a present possible data rate by an average data rate during a predetermined interval at every scheduling time point.
Remarks
When there is no channel variation, i.e., each UE achieves the same MCS in every RB in every slot, then the throughput of the PF scheduler equals that of the round robin scheduler.
The difference between the RR and PF schedulers can be seen when the radio channel varies stochastically over the slots.
Mobility cases: NetSim pathloss computations do not follow continuous math since it will mean a potentially infinite number of calculations. These PL calculations are discrete time instants i.e., every time a UE moves with the UE movement update determined per the update interval parameter in the UI or via a mobility file. Let u denote the time difference between updates as \(\Delta T.\ \)The UE is assumed to instantaneously move to a point \(P_{T}\) at time \(T\) and stay there till just before time \((T + \Delta T)\). At the moment, \((T + \Delta T)\), the UE instantaneously moves to point\(\ P_{T + \Delta T}\). Pathloss is computed at (\(P_{t},\ T\)) and then at (\(P_{T + \Delta T},\ T + \Delta T\)). Therefore, (and again) differences between the RR and PF scheduler will be appreciable only if the update interval is of the order of milliseconds.
Max Throughput Scheduler
The Max Throughput (MT) scheduler aims to maximize the overall throughput of the Base station (gNB or eNB). It allocates each PRBs to the user that can achieve the maximum achievable rate in the current TTI. The highest achievable rate is calculated by wideband MCS, that is derived from the CQI which in-turn is computed from the SINR. The scheduler allocates the required PRBs to this UE in the current TTI (slot). The calculation of achievable rate is similar to what is explained in the PF scheduler.
We denote \(S(M,\ B)\) as the TB size in bits for a given MCS, \(M,\) and a given number of physical resource blocks (PRBs), \(B\). The achievable rate \(R_{i}\ (t)\) in bit/s for user \(i\) at slot \(t\) is defined as
where \(\tau\) is the TTI i.e., \(1\) slot duration. At the start of each slot \(t\), the user index \(i^{*}(t)\) - selected by the scheduler - to which required PRBs (per that user’s demand) is assigned at time \(t\) is determined as
While MT can maximize cell throughput, it cannot provide fairness to the UEs that experience poor channel condition.
When there are several UEs having the same achievable rate, NetSim implements RR scheduling amongst these UEs that have the same achievable rate.
Special cases
Carrier aggregation case: the scheduler runs on a per carrier basis.
PF Scheduler: \({\widehat{T}}_{j}(t)\) is computed and maintained independently for each carrier.
NSA mode: Traffic is split between 4G and 5G (eNB and gNB) above the MAC. The scheduler runs independently on the eNB and gNB.
Association and Handover: PF Scheduler: At time of association or handover, say \(t_{a}\), NetSim sets \(T_{j}\left( t_{a} \right) = 1\)
Application priorities and heterogenous traffic: In 5G, the types of QoS are
GBR, which is transmitted in RLC UM mode. In NetSim, Applications which have a UGS priority set are transmitted in UM mode.
Non-GBR, which is transmitted in RLC AM mode. In NetSim, Applications which do not have a UGS priority set are transmitted in AM mode.
Control channel traffic, which is transmitted in RLC TM mode. NetSim assumes ideal control plane behaviour and doesn’t model these transmissions.
The MAC scheduler allocates resources on a combined (UM plus AM) RLC requirement. Once UE wise allocation is complete, RLC would first transmit the UM mode traffic followed by the AM mode traffic, to that UE. And so on for all UEs.
Log File
The resource allocation and the rank, i.e., \(\left( \frac{R_{j}(t)}{T_{j}(t)} \right)\ \)computations are logged in the Radio Resource Allocation csv file.
Figure-8: Radio resource allocation log file showing allocation per carrier per slot between each gNB and its associated UEs.
PHY Layer
Overview of the PHY implementation
NetSim is a packet level simulator for simulating the performance of end-to-end applications over various packet transport technologies. NetSim can scale to simulating networks with 100s of end-systems, routers, switches, etc. NetSim provides estimates of the statistics of application-level performance metrics such as throughput, delay, packet-loss, and statistics of network-level processes such as buffer occupancy, collision probabilities, etc.
To achieve a scalable simulation that can execute in reasonable time on desktop level computers, in all networking technologies the details of the physical layer techniques have been abstracted up to the point that bit-error probabilities can be obtained from which packet error probabilities are obtained.
Of all the wireless access technologies implemented in NetSim, the most sophisticated is 5G NR, in which the physical layer utilizes a variety of techniques that go well beyond even 4G LTE. These include multiple subcarrier bandwidths in the same system, slot lengths that depend on the subcarrier bandwidth, flexible time-division duplexing, a wide range of constellation sizes and coding rates, multiuser MIMO-OFDM, etc. Particularly with regard to MIMO-OFDM, with the attendant channel estimation (the errors therein), and the complexities of signal processing, NetSim has taken the design decision to replace these by idealized, symbol level models, where the statistics of the effective stochastic channel gains, and the statistics of the effective stochastic noise and interference are modelled in an idealized setting. Such models then permit the calculation of the required bit error rates, and thereby code block error rates, etc.
Overview of the 5G NR PHY:
5G NR utilizes an implementation of OFDMA, with several different carrier bandwidths, and a wide range of modulation and coding schemes.
Users would be sharing the same RF bandwidth but would be using different modulation schemes and thus obtaining different bit rates. As the devices involved in the communication move around, the radio channel between them also keeps changing.
The received SNR is determined from pathloss calculated per the 3GPP’s stochastic propagation models. The models provide signal attenuation as an output. Several parameters are used in the model, including the distance between the transmitter and the receiver.
A CQI is computed for all the symbols in one TB, based on the SNR calculated on the data channels (DL and UL). The SNR calculation is done at the start of the simulation, then every UE measurement interval and at every instant a UE moves. In calculating SNR, the noise power is obtained from \(N = k \times T \times B\).
Based on the SNR, the Adaptive Modulation and Coding (AMC) functionality determines the values of \(Q\), the modulation order, and \(R,\ \)the code rate, in the TBS formula. The SNR is computed on a per UE level for UL and DL.
The transport block size in NetSim is as per the MAC procedure for TBS determination standardized in TS 38.214 Section 5.1.3.2 (DL) and 6.1.4.2 (UL).
An approximate estimate of the TBS per carrier is.
Where \(R\) is the code rate, \(Q\) is the modulation order, \(\nu\) is the number of MIMO layers, \(n_{sc}^{rb}\) is the number of subcarriers per resource block, \(n_{symbol}\) is the number of symbols per slot, \(N_{PRB}\) is the number of PRBs and \(OH\) is the overheads specified in the standard.
The available PHY resource is shared dynamically between the users, with the resource allocation being dynamically adjusted per user demands and channel conditions. The MAC Scheduler determines the data (how much to and from, which UE and gNB) that is to be transmitted, from the higher layer RLC buffer, in units of Physical Resource Blocks (PRBs). It is transmitted at a rate determined using \(R\), code rate and \(Q\), modulation order of the UE – gNB channel.
Transmit power, Total Radiated power and EIRP
According to 3GPP standard 38.901 section 7.8, and common simulation practice, the Transmit Power parameter in a NetSim gNB or eNB is the power of a single transmitter (antenna port). The default value is \(40\ dBm.\)
In contrast, vendor datasheets usually specify the total combined power of the radio unit, which may contain multiple transmitters. The relationship is
where \(TRP\) is the Total Radiated Power and \(NTXU\) is the Number of Transmitters.
Example: If a user configures the antenna counts as 32 transmit and 32 receive (32T32R), then
EIRP (Effective Isotropic Radiated Power) is the radiated power in the most favorable direction. It includes antenna gain.
If \(3\ dB\) loss is assumed between conducted and radiated power,
And if the maximum antenna gain was \(25\ dBi\), we have
Finally, if the bandwidth was set to 100 MHz, then the EIRP density would be
MIMO and Beamforming
For a transmitter (gNB or eNB) with \(t\ \)antennas and a receiver with \(r\ \)antennas, the \(r \times t\) channel gain matrix (between every transmit-receive antenna pair) has complex Gaussian elements. We assume in the standard model that the complex Gaussian elements are statistically independent across elements, and each element is a circularly symmetric Gaussian. We denote this matrix by \(H.\ \)
For the channel matrix \(H\) being defined as above, the Wishart Matrix is defined as follows:
\(W = H\ H^{\dagger}\ \ \ \ \ \ r < t\),
\(W = \ H^{\dagger}H\) \(r \geq t\)
Therefore, letting\(\ m = \min{(r,t),\ }\ \) \(W\ \)is an \(m \times m\ \) nonnegative definite matrix, with eigenvalues \(\lambda_{1} \geq \lambda_{2} \geq \lambda_{3} \geq \cdots \geq \lambda_{L} > 0 = \ \lambda_{L + 1} = \cdots = \ \lambda_{m}.\ \)It is these eigenvalues that are used in the parallel SISO models described below.
NetSim permits the user to enable or disable a stochastic fading model. Fading is modelled by the elements of \(H\ \)being time varying, with some coherence time. Such time variation results in the eigenvalues of \(W\) also varying. NetSim models such time variation by letting the user define a coherence time during which the eigenvalues (fast fading gains) are kept fixed. For each \((r,t)\) value, NetSim maintains a list of samples of eigenvalues for the corresponding Wishart matrix. To model fading, a new set of eigenvalues is used by NetSim in successive coherence times.
Putting the above discussions together, if fast fading with eigen-beamforming is enabled in NetSim’s GUI, then the MIMO link is modelled by several SISO channels (see below), with the symbol level channel gain being derived from the eigenvalues of the Wishart matrix.
\[BeamFormingGain\ (dB) = 10\log_{10}(EigenValue)\]It must be noted that the eigenvectors are not required as they are only a part of the receive and transmit signal processing, and NetSim only needs to work with the equivalent symbol-by-symbol flat fading SISO channels.
If fast fading is disabled, NetSim reduces the MIMO transmission to a set of parallel, independent channels with constant gain, since the Beamforming gain does not change with time.
Note that the LOS probability parameter in NetSim is solely used to compute the large scale pathloss per the 3GPP 38.901 standard. This parameter is not used in the channel rank (MIMO layers) computations.
Fading and Beamforming |
No. of MIMO layers |
Beamforming Gain (per layer) and Model |
|---|---|---|
No Fading MIMO unit gain |
Min \({(N}_{t},\ N_{r})\) |
Unity (0 dB). A theoretical model useful for benchmarking. |
No fading MIMO array gain |
Min \({(N}_{t},\ N_{r})\) |
Max \({(N}_{t},\ N_{r})\) Assumes Matched Filter Precoding (MFP) and Maximal Ratio Combining (MRC) |
Rayleigh with Eigen beamforming |
Min \({(N}_{t},\ N_{r})\) |
Eigenvalues of the Wishart Matrix. Assumes MFP and MRC |
Rician with Eigen beamforming |
Min \({(N}_{t},\ N_{r})\) |
Eigenvalues of \({HH}^{H}\) (Rician channel covariance matrix). Assumes MFP and MRC. |
Table-2: Determination of (i) No. of MIMO layers and (ii) Gains in each layer using Fading and Beamforming parameters.
MIMO (Digital) Beamforming Assumptions in NetSim
NetSim makes the following assumptions to simplify MIMO operations for a packet-simulator:
Operation in spatial multiplexing mode only and not in transmit diversity mode.
The \(LayerCount = Min\ (N_{t},\ N_{r})\) where \(N_{t}\) is the number of transmit antennas and \(N_{r}\) is equal to the number of received antennas.
The rank of the channel is assumed to be equal to the layer count. NetSim doesn’t perform any Rank indicator (RI) computations.
Each layer is reduced to a flat fading SISO channel, i.e., for layer \(j,\ 1 \leq j \leq LayerCount\),
\[y_{j} = \sqrt{\lambda_{j}}\ x_{j} + w_{j}\]where, \(x_{j}\) is the symbol transmitted, \(\lambda_{j}\) is the corresponding eigenvalue of the Wishart matrix obtained as in the previous section, \(w_{j}\) is circular symmetric complex Gaussian noise, and \(y_{j}\) is the complex valued baseband received symbol.
Since the distance between the transmitter and receiver is much larger than the antenna spacings, a common pathloss is assumed for every layer. The pathloss is modelled, as usual, using distance dependent pathloss (power law), log normal shadowing, and a statistical model for fast fading (e.g., Rayleigh fading).
Then, given the transmit power in the symbol \(x_{j},\) the layer SNR can be obtained directly from the flat fading SISO equivalent model displayed above.
It is assumed that the transmit power is equally split between all \(Layers\ \)transmitted. At a high SNR, (iterative) water-filling will lead to nearly equal power allocation across all subcarriers and all layers.
The transmit power (or total radiated power) is not split equally among the antennas. The per-antenna power depends on the beamforming vector used. For example, if the (eigenvalue) beamforming vector is \(\lbrack 1,\ 0\rbrack^{T}\) in the 2-antenna case, all the power is radiated out of the first antenna. If it is \(\left\lbrack \frac{1}{\sqrt{2}},\frac{1}{\sqrt{2}} \right\rbrack^{T}\), then the power is split equally among the antennas ... and so on. NetSim abstracts out the actual beamforming operation and computes the received SINR when the beamforming vectors are used.
Downlink parallel transmission to multiple users is enabled by utilising multiple parallel resource blocks. Within each resource block, all MIMO layers are transmitted to the same UE.
UEs receive no interference from other gNBs, and a gNB does not receive interference from UEs connected to any other gNB.
Error free channel: This arises due to the practical fact that the adaptive MCS algorithm chooses the modulation order and coding scheme based on the SNR, in such a way that the data is decoded successfully at the receiver with a very high probability.
The MAC scheduler will assign the subcarriers to the UEs. If required, all available subcarriers can also be assigned to a single UE.
The channel is flat across the bandwidth per user. Modelling frequency selective fading within each user has been avoided to reduce computation time; NetSim already chooses a different fading gain every coherence time. Hence further averaging over frequency is not modelled. Note that scheduler does not allot RBs based on CQI feedback and hence modelling frequency selectivity is not necessary.
Figure-9: An example NetSim output showing SINR vs. time for each MIMO layer, as the UE moves away from the gNB. The beamforming gain is recalculated every coherence time.
In summary, NetSim models the effect of eigen-beamforming in MIMO systems via the eigenvalues of the gram matrix formed using (random) channel instantiations. These eigenvalues are used to compute layer-wise SNRs and the corresponding CQI. The CQI values are used by a scheduler to fix the TBS parameters, and this in turn determines the throughput.
NetSim's power lies in its ability to incorporate the impact of link-level factors (such as beamforming) on the network-level performance with high precision and computational efficiency. This, in turn, allows the simulator to scale to 10s of gNBs and 100s of UEs, and yet return performance results in a short time.
Analog beamforming in the SSB
In Analog beamforming, multiple antennas are used to concentrate the radiated power towards a particular direction (e.g., a part of a sector), thus improving the received SINR and the probability of detecting the SSB from the gNB (at a UE.)
Analog beamforming and digital beamforming are different as shown in the Table-3.
Analog Beamforming |
Digital Beamforming |
|
|---|---|---|
Benefit |
Array gain |
Spatial Multiplexing/Diversity |
Principle |
Use the antennas to steer the main lobe towards the users in a particular area (e.g., a sector, and e.g., using a phased array) Directional (Spatial) Channel independent |
Transmit and receive coding to create parallel channels Eigen vector based Channel dependent |
Use Case |
mmWave Short range LOS |
Low and Mid Band Medium and long ranges NLOS |
Table-3: Difference between Analog and digital beamforming
In NetSim, downlink Analog beamforming is implemented only in the control plane, i.e., broadcast beams for the SS/PBCH channel. If Analog beamforming is enabled in the UI then it will be used in signal strength calculations for purposes of Initial access (association) and Handovers.
The Analog beamforming gain computed is a wideband estimate.
A certain fraction of the (time-frequency) resources is deducted for control plane operations, when computing available resources in the PDSCH. This fraction is termed as overheads (OH) and the fractions are different for DL, UL and for FR1, FR2 as explained in section 3.9: Beamforming in NetSim. Analog beamforming measurements are assumed to be part of this overhead.
The Initial access and handover decisions are based on received SSB SNR, defined as
\[SNR = \frac{RxSignalLevel\ (dB) + AnalogBFGain(dB)}{N_{0} \times W}\]where \(N_{0}\) is the noise spectral density and \(W\) is the channel bandwidth. Recall, that rate (MCS selection) is based on PDSCH SINR.
Given the directional beamforming and the periodic transmission bursts we assume that SSB interference from other gNBs to be NIL. The probability of two SSB (directional) beams from two gNBs arriving at the same time at a UE is low. Even if this were to occur then both beams would be impacted almost equally by interference and the relative impact is negligible. This stems from the fact that UEs would see nearly equal powers from each gNB when H/O is occurring. Hence \(SNR\) is used.
In the above formula
\[RxSignalLevel = gNBTxPower + PathGain + ShadowFading\]
The \(gNBTxPower\) is the transmit power in the SSB. This is different from the per-layer transmit power that NetSim uses in PDSCH transmissions. The SSB power is set equal to the total power across all layers in the data channel (PDSCH).
NetSim does not (currently) implement Analog beamforming in the PDSCH or in the PUSCH. Digital beamforming can be enabled in the PDSCH/PUSCH as explained in section 3.9.
Analog beamforming is supported both in 5G (gNBs) as well as 4G (eNBs).
Assumptions
A1. The UE’s optimal receive beam is perfectly aligned to the gNB’s optimal transmit beam. As shown in the figure below, UE needs to measure RSRP based on the selected best SSB from serving cell and neighbouring cells, respectively. In the figure, UE measures the SS-RSRP from SSB with analog beamforming direction 3 from the serving cell, and from SSB from analog beamforming direction 1 from neighbouring cell. In this example, NetSim assumes beam 3 from s-gNB and beam 1 from neighbor gNB in perfectly aligned with the UE’s receive beams
Figure-10: UE Measuring RSRP using Beamforming
A2. Based on A1, NetSim computes an upper bound on the average Analog beamforming gain (dB) as \(10\log_{10}{(N_{t} \times N_{r})}\). Here \(N_{t}\) is the transmit antenna count at the gNBs and \(N_{r}\) is the receive antenna count at the UE.
A3. The beam selection and alignment are assumed to occur instantaneously. There is no time delay to account for beam-selection, SSB burst periodicity etc. Users requiring such time delays can attempt modelling it using the Handover interruption time variable available in the gNB properties. In any case, the beam selection/monitoring of the best beams from both serving and neighbouring cells are assumed to be occurring in parallel with the other data processing taking place at the UE.
Logging
There is a change in radio measurements data logging in comparison with v13.1.
The column DL/UL is being replaced as "Channel" and will have three types of entries (i) PDSCH (ii) PUSCH and (iii) SSB.
PUSCH/PDSCH transmit/receive powers will continue to be logged on a per MIMO layer basis.
The SSB is transmitted/received as a single stream using all Tx/Rx antennas. Hence this will have a single value for Tx-power (equal to the gNB Tx-power set in UI), for Rx-power and for AnalogBFGain.
Rank Estimation
The channel rank determines the number of parallel data streams (layers) that can be transmitted between the base station (BS) and user equipment (UE) in a MIMO system. This value is influenced by the propagation environment, channel model and the beamforming technique used.
The table below shows the rank algorithms supported when different fading and beamforming models are used
Fading Model |
Beamforming |
Rank Algorithm(s) Supported |
|---|---|---|
No Fading |
Unit Gain |
Max Rank. \(Min\ (N_{t},\ N_{r})\) |
No Fading |
Array Gain |
Max Rank. \(Min\ (N_{t},\ N_{r})\) |
Rayleigh |
Eigen |
Max Rank. \(Min\ \left( N_{t},\ N_{r} \right)\) Max Rate |
Rician |
Eigen |
Max Rank. \(Min\ \left( N_{t},\ N_{r} \right)\) Max Rate |
Table-4: Rank algorithms with respect to Fading models.
Logging of then Channel Rank
The channel rank selected by the system is logged for each transmission instance in the file LTENR_Radio_Measurements_Log.csv, under the column titled “Rank”.
The Max Rate Algorithm
In this case, each UE sees a channel matrix H of dimensions \(N_{r}\ \times N_{t}\ \)in representing the channel from the BS to the UE. The optimal number of layers is selected by solving:
where the SINR is the Signal-to-Interference-plus-Noise Ratio (SINR) for \(i_{th}\) layer is computed as:
\[SINR\ = \ \frac{P\ .\ \ \beta\ .\ \sigma^{2}}{{(N}_{o}\ .\ \ B + I)}\]
Where
\(P\): \(t_{x}\) power of BS (gNB)
\(\beta\): the path loss between BS and \(UE_{k}\)
\(\sigma\): \(i^{th}\) largest singular value of \(H_{k}\)
\(N_{o}\): noise spectral density
\(B\): system bandwidth
\(I\): Out-of-cell Interference
Fast fading
For a transmitter (gNB or eNB) with t antennas and a receiver with r antennas, the \(N_{r} \times N_{t}\ \)channel gain matrix (between every transmit-receive antenna pair) on a given subcarrier has complex Gaussian elements. We assume in the standard model that the complex Gaussian elements are statistically independent across elements (which is the case the antennas are spread sufficiently far apart, e.g., of the order of a few wavelengths), and each element is a circularly symmetric Gaussian. We denote this matrix by H.
In NetSim, Fast-Fading is modeled by the elements of the H-Matrix being time-varying, with some coherence time. NetSim abstracts out the actual (digital) beamforming operation and computes the received SINR when the beamforming vectors are used. The MIMO link is modelled by parallel SISO channels, and the beamforming gain/loss would be equal to Eigenvalues of the Gram matrix of H (which would also be time-varying). This is the case when the transmitter/receiver uses Eigen beamforming to precode/combine the signals across antennas, respectively. In turn, it assumes the availability of channel state information at both the transmitter and receiver. In the case where multiple layers are transmitted to different users, the interference is calculated by considering its statistics, by assuming that the channels between the base station and the different users to be independent of each other.
Rician Fading for MIMO Systems
We denote \(N_{t}:\ \)Number of transmit antennas, \(N_{r}:\ \)Number of receive antennas, and \(K: Rician K-factor\). The range of \(K\) in NetSim is 0 to 10,000 with support for two decimals. When \(K\) = 0 we get Rayleigh fading and when \(K \rightarrow \infty\) we get a deterministic LOS channel i.e., a constant gain channel.
NetSim applies Eigen beamforming and precoding with the number of MIMO-layers (also called channel-rank) \(m = Min(N_{t},\ N_{r})\).
NetSim creates a \(H\ \)matrix of size \(N_{r} \times N_{t}\) with each element
where \(x,\ y\ \sim\ \mathcal{N}\left( \mu,\ \sigma^{2} \right)\) with \(\mu = \sqrt{\frac{K}{2(K + 1)}},\) and \(\sigma = \sqrt{\frac{1}{2(K + 1)}}\) [2]
Let \(\lambda_{i}\)be the eigen values of \(HH^{H}\). Then the layer wise gains (in linear scale) are given by
These gains are recorded in the columns “Beamforming Gain” in the Radio Measurements log file.
Antenna: Omni and Sector
NetSim implements both Omni and sector antennas. With Omni directional antennas the gain in all directions is 0 dB.
The sector antennas are modeled per the 2D parabolic antenna pattern given in 3GPP TR 37.840. To accurately simulate a tri-sector gNB, it is necessary to deploy three "Macro Cell Sector Antennas," each configured with the appropriate boresight angles to represent the three 120-degree sectors effectively. For example, the boresight angles could be set to 60°, 180°, and 300°. This configuration ensures that the antennas collectively cover a full 360° area, with each sector providing a 120-degree field of coverage. By adjusting the boresight angles in this manner, the configuration can accurately reflect the directional characteristics of a tri-sector gNB.
The horizontal radiation pattern of a sector antenna is given by
where,
\(A_{m}\)is the front to back ratio (i.e., the ratio of power gain between the front and rear of a directional antenna). This is a user input with a default setting is 30 dB.
\(\varphi\) is the angle formed between the direction of interest (i.e., then line connecting the UE to the gNB) and the antenna's boresight direction (azimuth angle).
\(\varphi_{3dB}\) is the 3 dB, or half power, beam width of the antenna.
The sector antenna gain is given by the expression
where,
\(A_{E,V}(\theta)\) is currently 0 dB, and is a parameter reserved for future use to include the vertical radiation pattern of the antenna, and
\(G_{E,\ max}\ \)is the maximum directional gain of the radiation element (in dB) i.e., the gain along the antenna boresight; this is a user input and the default value is 8 dBi.
The boresight angle denotes the azimuthal direction of maximum gain, or the highest radiated power, and is a user input. This can vary from 0 to 360 degrees.
Angle in NetSim is defined to start at 0 from the positive X-axis. In your scenario, if positive Y points downward, the angle increases on clockwise rotation from the positive X-axis. If positive Y points upward, the angle increases in an anti-clockwise direction from the positive X-axis. The unit for angle is degrees.
NR Frequency Bands
The definition of frequency ranges is per the table given below Table-5.
Frequency range designation |
Corresponding frequency range |
|
|---|---|---|
FR1 |
410 MHz - 7125 MHz |
|
FR2 |
FR2-1 |
24250 MHz - 52600 MHz |
FR2-2 |
52600 MHz - 71000 MHz |
|
Table-5: NR Frequency Bands Ranges
NR Band – FR 1
The FR1 bands (per 3GPP TS 38.101-1 V15.5.0 (2019-03)) implemented in NetSim are those that run:
TDD Single Band in Duplex mode, namely n34, n38, n39, n40, n41, n50, n51, n77, n78, n79, n259, n260, n261 and n262 as shown below in Table-6.
FDD Single Band in Duplex mode, namely n1, n2, n3, n5, n7, n8, n12, n20, n25, n28, n66, n70, n71 and n74 as shown below in Table-6.
NR operating band |
Uplink (UL) operating band BS receive / UE transmit FUL_low – FUL_high |
Downlink (DL) operating band BS transmit / UE receive FDL_low – FDL_high |
Duplex Mode |
|---|---|---|---|
n1 |
1920 MHz – 1980 MHz |
2110 MHz – 2170 MHz |
FDD |
n2 |
1850 MHz – 1910 MHz |
1930 MHz – 1990 MHz |
FDD |
n3 |
1710 MHz – 1785 MHz |
1805 MHz – 1880 MHz |
FDD |
n5 |
824 MHz – 859 MHz |
869 MHz – 894 MHz |
FDD |
n7 |
2500 MHz – 2570 MHz |
2620 MHz – 2690 MHz |
FDD |
n8 |
880 MHz – 915 MHz |
925 MHz – 960 MHz |
FDD |
n12 |
699 MHz – 716 MHz |
729 MHz – 746 MHz |
FDD |
n20 |
832 MHz – 862 MHz |
791 MHz – 821 MHz |
FDD |
n25 |
1850 MHz – 1915 MHz |
1930 MHz – 1995 MHz |
FDD |
n28 |
703 MHz – 748 MHz |
758 MHz – 803 MHz |
FDD |
n34 |
2010 MHz – 2025 MHz |
2010 MHz – 2025 MHz |
TDD |
n38 |
2570 MHz – 2620 MHz |
2570 MHz – 2620 MHz |
TDD |
n39 |
1880 MHz – 1920 MHz |
1880 MHz – 1920 MHz |
TDD |
n40 |
2300 MHz – 2400 MHz |
2300 MHz – 2400 MHz |
TDD |
n41 |
2496 MHz – 2690 MHz |
2496 MHz – 2690 MHz |
TDD |
n50 |
1432 MHz – 1517 MHz |
1432 MHz – 1517 MHz |
TDD |
n51 |
1427 MHz – 1432 MHz |
1427 MHz – 1432 MHz |
TDD |
n66 |
1710 MHz – 1780 MHz |
2110 MHz – 2200 MHz |
FDD |
n70 |
1695 MHz – 1710 MHz |
1995 MHz – 2020 MHz |
FDD |
n71 |
663 MHz – 698 MHz |
617 MHz – 652 MHz |
FDD |
n74 |
1427 MHz – 1470 MHz |
1475 MHz – 1518 MHz |
FDD |
n77 |
3300 MHz – 4200 MHz |
3300 MHz – 4200 MHz |
TDD |
n78 |
3300 MHz – 3800 MHz |
3300 MHz – 3800 MHz |
TDD |
n79 |
4400 MHz – 5000 MHz |
4400 MHz – 5000 MHz |
TDD |
n259 |
39500 MHz – 43500MHz |
39500 MHz – 43500MHz |
TDD |
n260 |
37000 MHz – 40000MHz |
37000 MHz – 40000MHz |
TDD |
n261 |
27500 MHz – 28350MHz |
27500 MHz – 28350MHz |
TDD |
n262 |
47200 MHz – 48200MHz |
47200 MHz – 48200MHz |
TDD |
Table-6: NR operating bands in FR1 in NetSim
Maximum transmission bandwidth configuration
The maximum transmission bandwidth configuration NRB for each UE channel bandwidth and subcarrier spacing is specified below Table-7.
SCS (kHz) |
5 MHz |
10 MHz |
15 MHz |
20 MHz |
25 MHz |
30 MHz |
40 MHz |
50 MHz |
60 MHz |
80 MHz |
90 MHz |
100 MHz |
NRB |
NRB |
NRB |
NRB |
NRB |
NRB |
NRB |
NRB |
NRB |
NRB |
NRB |
NRB |
|
15 |
25 |
52 |
79 |
106 |
133 |
160 |
216 |
270 |
N/A |
N/A |
N/A |
N/A |
30 |
11 |
24 |
38 |
51 |
65 |
78 |
106 |
133 |
162 |
217 |
245 |
273 |
60 |
N/A |
11 |
18 |
24 |
31 |
38 |
51 |
65 |
79 |
107 |
121 |
135 |
Table-7: Maximum transmission bandwidth configuration NRB
Minimum guard band and transmission bandwidth configuration
The minimum guard band for each UE channel bandwidth and SCS is specified below Table-8.
SCS (kHz) |
5 MHz |
10 MHz |
15 MHz |
20 MHz |
25 MHz |
30 MHz |
40 MHz |
50 MHz |
60 MHz |
80 MHz |
90 MHz |
100 MHz |
15 |
242.5 |
312.5 |
382.5 |
452.5 |
522.5 |
592.5 |
552.5 |
692.5 |
N/A |
N/A |
N/A |
N/A |
30 |
505 |
665 |
645 |
805 |
785 |
945 |
905 |
1045 |
825 |
925 |
885 |
845 |
60 |
N/A |
1010 |
990 |
1330 |
1310 |
1290 |
1610 |
1570 |
1530 |
1450 |
1410 |
1370 |
Table-8: Minimum guard band for each UE channel bandwidth and SCS (kHz)
NOTE: The minimum guard bands have been calculated using the following equation:
where \(N_{RB}\) are from Table 3‑10. The minimum guard band of receiving BS SCS 240 kHz for each
UE channel bandwidth is specified in Table-9.
SCS (kHz) |
100MHz |
200 MHz |
400 MHz |
|---|---|---|---|
240 |
3800 |
7720 |
15560 |
Table-9: Minimum guard band (kHz) of SCS 240 kHz from Standards Table 5.3.3-2
NR Band – FR 2
The FR2 bands (per 3GPP TS 38.101-2 V15.5.0 (2019-03)) implemented in NetSim as shown below Table-10.
Operating Band |
Uplink (UL) operating band BS receive UE transmit |
Downlink (DL) operating band BS transmit UE receive |
Duplex Mode |
||||
|---|---|---|---|---|---|---|---|
FUL_low – FUL_high |
FDL_low – FDL_high |
||||||
n257 |
26500 MHz |
– |
29500 MHz |
26500 MHz |
– |
29500 MHz |
TDD |
n258 |
24250 MHz |
– |
27500 MHz |
24250 MHz |
– |
27500 MHz |
TDD |
n259 |
39500 MHz |
– |
43500 MHz |
39500 MHz |
– |
43500 MHz |
TDD |
n260 |
37000 MHz |
– |
40000 MHz |
37000 MHz |
– |
40000 MHz |
TDD |
n261 |
27500 MHz |
– |
28350 MHz |
27500 MHz |
– |
28350 MHz |
TDD |
n262 |
47200 MHz |
– |
48200 MHz |
47200 MHz |
– |
48200 MHz |
TDD |
n263 |
57000 MHz |
– |
71000 MHz |
57000 MHz |
– |
71000 MHz |
TDD |
Table-10: NR operating bands in FR2 in NetSim
Maximum transmission bandwidth configuration
The maximum transmission bandwidth configuration NRB for each UE channel bandwidth and subcarrier spacing is specified in Table-11.
SCS (kHz) |
50 MHz |
100 MHz |
200 MHz |
400 MHz |
800 MHz |
1600 MHz |
2000 MHz |
|---|---|---|---|---|---|---|---|
NRB |
NRB |
NRB |
NRB |
NRB |
NRB |
NRB |
|
60 |
66 |
132 |
264 |
N/A |
N/A |
N/A |
N/A |
120 |
32 |
66 |
132 |
264 |
N/A |
N/A |
N/A |
480 |
N/A |
N/A |
N/A |
66 |
124 |
248 |
N/A |
960 |
N/A |
N/A |
N/A |
33 |
62 |
124 |
148 |
Table-11: Maximum transmission bandwidth configuration NRB from Standards Table 5.3.2-1
SCS (kHz) |
50 MHz |
100 MHz |
200 MHz |
400 MHz |
800 MHz |
1600 MHz |
2000 MHz |
|---|---|---|---|---|---|---|---|
60 |
1210 |
2450 |
4930 |
N/A |
N/A |
N/A |
N/A |
120 |
1900 |
2420 |
4900 |
9860 |
N/A |
N/A |
N/A |
480 |
N/A |
N/A |
N/A |
9680 |
42640 |
85520 |
N/A |
960 |
N/A |
N/A |
N/A |
9440 |
42400 |
85280 |
147040 |
Table-12: Minimum guard band for each UE channel bandwidth and SCS (kHz) from Standards Table 5.3.3-1
UE channel bandwidth
General
All UEs connected to BS (gNB) have the same channel bandwidth. This is a user settable bandwidth available in the gNB properties. Bandwidth is a single parameter in TDD; in FDD users can set DL bandwidth and UL bandwidth. It is currently not possible in NetSim to configure different channel bandwidths to different UEs connected to a BS.
The above is true even in the case of carrier aggregation (CA). All component carriers (CCs) are assigned to all UEs, and the pooled OFDM resources are shared between the UEs.
Frame structure and physical resources
Numerologies
Multiple OFDM numerologies are supported as given by Table 4.2-1 where \(\mu\) and the cyclic prefix for a bandwidth part is obtained from the higher-layer parameter subcarrierSpacing and cyclicPrefix, respectively.
\[\mathbf{\mu}\]
|
\[\mathbf{\Delta f =}\mathbf{2}^{\mathbf{\mu}}\mathbf{\cdot 15\ \lbrack}\text{kHz}\mathbf{\rbrack}\]
|
Cyclic prefix |
|---|---|---|
0 |
15 |
Normal |
1 |
30 |
Normal |
2 |
60 |
Normal, Extended |
3 |
120 |
Normal |
4 |
240 |
Normal |
5 |
480 |
Normal |
6 |
960 |
Normal |
Table-13: Supported transmission numerologies from Standards Table 4.2-1
Frames and subframes
Downlink and uplink transmissions are organized into frames with \(T_{f} = 10ms\) duration, each consisting of ten subframes of \(T_{sf} = 1ms\) duration. The number of consecutive OFDM symbolsper subframe is \(N_{\text{symb}}^{\text{subframe},\mu} = N_{\text{symb}}^{\text{slot}}N_{\text{slot}}^{\text{subframe},\mu}\).
Slots
For subcarrier spacing configuration \(\mu\), slots are numbered \(n_{\text{s}}^{\mu} \in \left\{ 0,\ \ldots,N_{\text{slot}}^{\text{subframe},\mu} - 1\ \right\}\) in increasing order within a subframe and \(n_{\text{s,f}}^{\mu} \in \left\{ 0,\ \ldots,N_{\text{slot}}^{\text{frame},\mu} - 1\ \right\}\) in increasing order within a frame. There are \(N_{\text{symb}}^{\text{slot}}\) consecutive OFDM symbols in a slot where \(N_{\text{symb}}^{\text{slot}}\) depends on the cyclic prefix as given by Table 3‑13 and Table 3‑14 The start of slot \(n_{\text{s}}^{\mu}\) in a subframe is aligned in time with the start of OFDM symbol \(n_{s}^{\mu}N_{\text{symb}}^{\text{slot}}\) in the same subframe.
OFDM symbols in a slot can be classified as 'downlink', 'flexible', or 'uplink'. Signaling of slot formats is described in subclause 11.1 of [5, TS 38.213].
In a slot in a downlink frame, the UE shall assume that downlink transmissions only occur in 'downlink' or 'flexible' symbols.
In a slot in an uplink frame, the UE shall only transmit in 'uplink' or 'flexible' symbols.
A UE not capable of full-duplex communication among a group of cells is not expected to transmit in the uplink in one cell within the group of cells earlier than \(N_{\text{Rx-Tx}}T_{\text{c}}\) after the end of the last received downlink symbol in the same or different cell within the group of cells where \(N_{\text{Rx-Tx}}\) is given by Table-16.
A UE not capable of full-duplex communication among a group of cells is not expected to receive in the downlink in one cell within the group of cells earlier than \(N_{\text{Tx-Rx}}T_{\text{c}}\) after the end of the last transmitted uplink symbol in the same or different cell within the group of cells where \(N_{\text{Tx-Rx}}\) is given by Table-16.
\[\mathbf{\mu}\]
|
\[\mathbf{N}_{\text{symb}}^{\text{slot}}\]
|
\[\mathbf{N}_{\text{slot}}^{\text{frame}\mathbf{,\mu}}\]
|
\[\mathbf{N}_{\text{slot}}^{\text{subframe}\mathbf{,\mu}}\]
|
|---|---|---|---|
0 |
14 |
10 |
1 |
1 |
14 |
20 |
2 |
2 |
14 |
40 |
4 |
3 |
14 |
80 |
8 |
Table-14: Number of OFDM symbols per slot, slots per frame, and slots per subframe for normal cyclic
\[\mathbf{\mu}\]
|
\[\mathbf{N}_{\text{symb}}^{\text{slot}}\]
|
\[\mathbf{N}_{\text{slot}}^{\text{frame}\mathbf{,\mu}}\]
|
\[\mathbf{N}_{\text{slot}}^{\text{subframe}\mathbf{,\mu}}\]
|
|---|---|---|---|
2 |
12 |
40 |
4 |
Table-15: Number of OFDM symbols per slot, slots per frame, and slots per subframe for extended cyclic prefix from Standards Table 4.3.2-2.
Transition time |
FR1 |
FR2 |
|---|---|---|
\[\mathbf{N}_{\text{Tx-Rx}}\]
|
25600 |
13792 |
\[\mathbf{N}_{\text{Rx-Tx}}\]
|
25600 |
13792 |
Table-16: Transition time N "Rx-Tx" and N "Tx-Rx" from Standards Table 4.3.2-3
Slot structure in NetSim
We show below the slot structure, in NetSim, for two examples of \(\mu = 0\) and \(\mu = 1\).
If we take \(\mu = 0\), the number of slots in a sub frame is 1. The total number of slots, therefore, in a frame is \(1 \times 10 = 10\). For different DL:UL ratios the slot structures are as follows
Ratio 1:1 |
Ratio 1:4 |
Ratio 4:1 |
|||
|---|---|---|---|---|---|
Sub Frame ID |
Slot Type |
Sub Frame ID |
Slot Type |
Sub Frame ID |
Slot Type |
1 |
UL |
1 |
UL |
1 |
UL |
2 |
DL |
2 |
DL |
2 |
DL |
3 |
UL |
3 |
UL |
3 |
DL |
4 |
DL |
4 |
UL |
4 |
DL |
5 |
UL |
5 |
UL |
5 |
DL |
6 |
DL |
6 |
UL |
6 |
UL |
7 |
UL |
7 |
DL |
7 |
DL |
8 |
DL |
8 |
UL |
8 |
DL |
9 |
UL |
9 |
UL |
9 |
DL |
10 |
DL |
10 |
UL |
10 |
DL |
Table-17: The Slot structures for different DL:UL ratios when μ=0
For \(\mu = 1\), the number of slots in a sub frame is 2. The total number of slots, therefore, in a frame is \(2 \times 10 = 20\). For different DL:UL ratios the slot structures are as follows
Ratio 1:1 |
Ratio 1:4 |
Ratio 4:1 |
|||
|---|---|---|---|---|---|
Sub Frame ID |
Slot Type |
Sub Frame ID |
Slot Type |
Sub Frame ID |
Slot Type |
1 |
UL |
1 |
UL |
1 |
UL |
1 |
DL |
1 |
DL |
1 |
DL |
2 |
UL |
2 |
UL |
2 |
DL |
2 |
DL |
2 |
UL |
2 |
DL |
3 |
UL |
3 |
UL |
3 |
DL |
3 |
DL |
3 |
UL |
3 |
UL |
4 |
UL |
4 |
DL |
4 |
DL |
4 |
DL |
4 |
UL |
4 |
DL |
5 |
UL |
5 |
UL |
5 |
DL |
5 |
DL |
5 |
UL |
5 |
DL |
6 |
UL |
6 |
UL |
6 |
UL |
6 |
DL |
6 |
DL |
6 |
DL |
7 |
UL |
7 |
UL |
7 |
DL |
7 |
DL |
7 |
UL |
7 |
DL |
8 |
UL |
8 |
UL |
8 |
DL |
8 |
DL |
8 |
UL |
8 |
UL |
9 |
UL |
9 |
DL |
9 |
DL |
9 |
DL |
9 |
UL |
9 |
DL |
10 |
UL |
10 |
UL |
10 |
DL |
10 |
DL |
10 |
UL |
10 |
DL |
Table-18: The Slot structures for different DL:UL ratios when μ=1
For a DL/UL mixed configuration, the first slot in NetSim is always UL and the second slot is always DL, and subsequent slots are based on the DL:UL ratio set.
Channel state information
Perfect CSIT and CSIR: The channel matrix H is assumed to be known perfectly and instantaneously at the transmitter and receiver, respectively. With perfect CSIT the transmitter can adapt its transmission rate (MCS) relative to the instantaneous channel state (SNR).
Channel quality indicator (CQI)
A wideband CQI is computed based on the spectral efficiency obtained from the SINR calculated on the PDSCH and PUSCH (see 3.9.15 for how NetSim computes spectral efficiency from SINR). The SINR calculation is done at the start of the simulation, then every UE measurement interval and at every instant a UE moves. In calculating SNR, the noise power is obtained from \(N = k \times T \times B\). Based on the SNR, the Adaptive Modulation and Coding (AMC) functionality determines the values of Q, the modulation order, and R, the code rate, in the TBS formula. The SNR is computed on a per UE level for UL and DL.
The modulation order and code rate are based on the table chosen by the user. In the NetSim GUI users can select “table1” (corresponding to Table-19), “table2” (corresponding to Table-20) or “table3” (corresponding to Table-21 or the URLLC table).
NetSim does not implement Sub-band Offset. The AMC determines a wideband CQI which indicates the highest rate Modulation and coding scheme (MCS), that it can reliably decode, if the entire system bandwidth were allocated to that user.
CQI index |
modulation |
code rate x 1024 |
Spec. Eff. |
|---|---|---|---|
0 |
Out of range |
||
1 |
QPSK |
78 |
0.1523 |
2 |
QPSK |
120 |
0.2344 |
3 |
QPSK |
193 |
0.3770 |
4 |
QPSK |
308 |
0.6016 |
5 |
QPSK |
449 |
0.8770 |
6 |
QPSK |
602 |
1.1758 |
7 |
16QAM |
378 |
1.4766 |
8 |
16QAM |
490 |
1.9141 |
9 |
16QAM |
616 |
2.4063 |
10 |
64QAM |
466 |
2.7305 |
11 |
64QAM |
567 |
3.3223 |
12 |
64QAM |
666 |
3.9023 |
13 |
64QAM |
772 |
4.5234 |
14 |
64QAM |
873 |
5.1152 |
15 |
64QAM |
948 |
5.5547 |
Table-19: 4-bit CQI Table 1 from Standards Table 5.2.2.1-2
CQI index |
modulation |
code rate x 1024 |
Spec. Eff. |
|---|---|---|---|
0 |
out of range |
||
1 |
QPSK |
78 |
0.1523 |
2 |
QPSK |
193 |
0.3770 |
3 |
QPSK |
449 |
0.8770 |
4 |
16QAM |
378 |
1.4766 |
5 |
16QAM |
490 |
1.9141 |
6 |
16QAM |
616 |
2.4063 |
7 |
64QAM |
466 |
2.7305 |
8 |
64QAM |
567 |
3.3223 |
9 |
64QAM |
666 |
3.9023 |
10 |
64QAM |
772 |
4.5234 |
11 |
64QAM |
873 |
5.1152 |
12 |
256QAM |
711 |
5.5547 |
13 |
256QAM |
797 |
6.2266 |
14 |
256QAM |
885 |
6.9141 |
15 |
256QAM |
948 |
7.4063 |
Table-20: 4-bit CQI Table 2 from Standards Table 5.2.2.1-3
CQI index |
modulation |
code rate x 1024 |
Spec. Eff. |
|---|---|---|---|
0 |
out of range |
||
1 |
QPSK |
30 |
0.0586 |
2 |
QPSK |
50 |
0.0977 |
3 |
QPSK |
78 |
0.1523 |
4 |
QPSK |
120 |
0.2344 |
5 |
QPSK |
193 |
0.3770 |
6 |
QPSK |
308 |
0.6016 |
7 |
QPSK |
449 |
0.8770 |
8 |
QPSK |
602 |
1.1758 |
9 |
16QAM |
378 |
1.4766 |
10 |
16QAM |
490 |
1.9141 |
11 |
16QAM |
616 |
2.4063 |
12 |
64QAM |
466 |
2.7305 |
13 |
64QAM |
567 |
3.3223 |
14 |
64QAM |
666 |
3.9023 |
15 |
64QAM |
772 |
4.5234 |
Table-21: 4-bit CQI Table 3 from Standards Table 5.2.2.1-4
Modulation order, code rate, and TBS determination
To determine the modulation order, target code rate, and transport block size(s) in the physical downlink shared channel, the UE shall first determine the modulation order (\(Q_{m}\)) and target code rate (\(R\)), and second the UE shall use the number of layers (\(\upsilon)\), the total number of allocated PRBs to determine to the transport block size
MCS tables
The user can select from the following MCS tables, for each gNB and associated UEs, from the GUI:
QAM64 Table-23 (Table 1)
QAM256 Table-24 (Table 2)
QAM64LowSE Table-25 (Table 3)
The UE and gNB then uses this table to determine the modulation order \(Q_{m}\) and Code Rate, \(R\). The selection is based on looking up the MCS for the given spectral efficiency, which is computed as explained in 3.9.15. Different tables can be chosen for DL (gNB to UE) and for UL (UE to gNB). The UL table index selection based on transform precoding selection in the GUI is given Table-22.
Transform Precoding |
MCS Table (PUSCH Config) |
MCS Table Index |
|---|---|---|
Enabled |
QAM256 |
5.1.3.1 – 2 |
Enabled |
QAM64LowSE |
6.1.4.1 – 2 |
Enabled |
QAM64 |
6.1.4.1 – 1 |
Disabled |
QAM256 |
5.1.3.1 – 2 |
Disabled |
QAM64LowSE |
5.1.3.1 – 3 |
Disabled |
QAM64 |
5.1.3.1 – 1 |
Table-22: Uplink MCS Table index determination based on transform precoding and MCS table selection in GUI
MCS Index IMCS |
Modulation Order Qm |
Target code Rate R x [1024] |
Spectral efficiency |
|---|---|---|---|
0 |
2 |
120 |
0.2344 |
1 |
2 |
157 |
0.3066 |
2 |
2 |
193 |
0.3770 |
3 |
2 |
251 |
0.4902 |
4 |
2 |
308 |
0.6016 |
5 |
2 |
379 |
0.7402 |
6 |
2 |
449 |
0.8770 |
7 |
2 |
526 |
1.0273 |
8 |
2 |
602 |
1.1758 |
9 |
2 |
679 |
1.3262 |
10 |
4 |
340 |
1.3281 |
11 |
4 |
378 |
1.4766 |
12 |
4 |
434 |
1.6953 |
13 |
4 |
490 |
1.9141 |
14 |
4 |
553 |
2.1602 |
15 |
4 |
616 |
2.4063 |
16 |
4 |
658 |
2.5703 |
17 |
6 |
438 |
2.5664 |
18 |
6 |
466 |
2.7305 |
19 |
6 |
517 |
3.0293 |
20 |
6 |
567 |
3.3223 |
21 |
6 |
616 |
3.6094 |
22 |
6 |
666 |
3.9023 |
23 |
6 |
719 |
4.2129 |
24 |
6 |
772 |
4.5234 |
25 |
6 |
822 |
4.8164 |
26 |
6 |
873 |
5.1152 |
27 |
6 |
910 |
5.3320 |
28 |
6 |
948 |
5.5547 |
29 |
2 |
Reserved |
|
30 |
4 |
Reserved |
|
31 |
6 |
Reserved |
|
Table-23: MCS index table 1 for PDSCH from Standards Table 5.1.3.1-1
MCS Index IMCS |
Modulation Order Qm |
Target code Rate R x [1024] |
Spectral efficiency |
|---|---|---|---|
0 |
2 |
120 |
0.2344 |
1 |
2 |
193 |
0.3770 |
2 |
2 |
308 |
0.6016 |
3 |
2 |
449 |
0.8770 |
4 |
2 |
602 |
1.1758 |
5 |
4 |
378 |
1.4766 |
6 |
4 |
434 |
1.6953 |
7 |
4 |
490 |
1.9141 |
8 |
4 |
553 |
2.1602 |
9 |
4 |
616 |
2.4063 |
10 |
4 |
658 |
2.5703 |
11 |
6 |
466 |
2.7305 |
12 |
6 |
517 |
3.0293 |
13 |
6 |
567 |
3.3223 |
14 |
6 |
616 |
3.6094 |
15 |
6 |
666 |
3.9023 |
16 |
6 |
719 |
4.2129 |
17 |
6 |
772 |
4.5234 |
18 |
6 |
822 |
4.8164 |
19 |
6 |
873 |
5.1152 |
20 |
8 |
682.5 |
5.3320 |
21 |
8 |
711 |
5.5547 |
22 |
8 |
754 |
5.8906 |
23 |
8 |
797 |
6.2266 |
24 |
8 |
841 |
6.5703 |
25 |
8 |
885 |
6.9141 |
26 |
8 |
916.5 |
7.1602 |
27 |
8 |
948 |
7.4063 |
28 |
2 |
Reserved |
|
29 |
4 |
Reserved |
|
30 |
6 |
Reserved |
|
31 |
8 |
Reserved |
|
Table-24: MCS index table 2 for PDSCH from Standards Table 5.1.3.1-2
MCS IndIMCS |
Modulation Order Qm |
Target code Rate R x [1024] |
Spectral efficiency |
|---|---|---|---|
0 |
2 |
30 |
0.0586 |
1 |
2 |
40 |
0.0781 |
2 |
2 |
50 |
0.0977 |
3 |
2 |
64 |
0.1250 |
4 |
2 |
78 |
0.1523 |
5 |
2 |
99 |
0.1934 |
6 |
2 |
120 |
0.2344 |
7 |
2 |
157 |
0.3066 |
8 |
2 |
193 |
0.3770 |
9 |
2 |
251 |
0.4902 |
10 |
2 |
308 |
0.6016 |
11 |
2 |
379 |
0.7402 |
12 |
2 |
449 |
0.8770 |
13 |
2 |
526 |
1.0273 |
14 |
2 |
602 |
1.1758 |
15 |
4 |
340 |
1.3281 |
16 |
4 |
378 |
1.4766 |
17 |
4 |
434 |
1.6953 |
18 |
4 |
490 |
1.9141 |
19 |
4 |
553 |
2.1602 |
20 |
4 |
616 |
2.4063 |
21 |
6 |
438 |
2.5664 |
22 |
6 |
466 |
2.7305 |
23 |
6 |
517 |
3.0293 |
24 |
6 |
567 |
3.3223 |
25 |
6 |
616 |
3.6094 |
26 |
6 |
666 |
3.9023 |
27 |
6 |
719 |
4.2129 |
28 |
6 |
772 |
4.5234 |
29 |
2 |
Reserved |
|
30 |
4 |
Reserved |
|
31 |
6 |
Reserved |
|
Table-25: MCS index table 3 for PDSCH from Standards Table 5.1.3.1-3
MCS Index IMCS |
Modulation Order Qm |
Target code Rate R x 1024 |
Spectral efficiency |
|---|---|---|---|
0 |
q |
240/ q |
0.2344 |
1 |
q |
314/ q |
0.3066 |
2 |
2 |
193 |
0.3770 |
3 |
2 |
251 |
0.4902 |
4 |
2 |
308 |
0.6016 |
5 |
2 |
379 |
0.7402 |
6 |
2 |
449 |
0.8770 |
7 |
2 |
526 |
1.0273 |
8 |
2 |
602 |
1.1758 |
9 |
2 |
679 |
1.3262 |
10 |
4 |
340 |
1.3281 |
11 |
4 |
378 |
1.4766 |
12 |
4 |
434 |
1.6953 |
13 |
4 |
490 |
1.9141 |
14 |
4 |
553 |
2.1602 |
15 |
4 |
616 |
2.4063 |
16 |
4 |
658 |
2.5703 |
17 |
6 |
466 |
2.7305 |
18 |
6 |
517 |
3.0293 |
19 |
6 |
567 |
3.3223 |
20 |
6 |
616 |
3.6094 |
21 |
6 |
666 |
3.9023 |
22 |
6 |
719 |
4.2129 |
23 |
6 |
772 |
4.5234 |
24 |
6 |
822 |
4.8164 |
25 |
6 |
873 |
5.1152 |
26 |
6 |
910 |
5.3320 |
27 |
6 |
948 |
5.5547 |
28 |
q |
reserved |
|
29 |
2 |
reserved |
|
30 |
4 |
reserved |
|
31 |
6 |
reserved |
|
Table-26: MCS index table for PUSCH with transform precoding and 64QAM. Standards table 6.1.4.1-1
MCS Index IMCS |
Modulation Order Qm |
Target code Rate R x 1024 |
Spectral efficiency |
|---|---|---|---|
0 |
q |
60/q |
0.0586 |
1 |
q |
80/q |
0.0781 |
2 |
q |
100/q |
0.0977 |
3 |
q |
128/q |
0.1250 |
4 |
q |
156/q |
0.1523 |
5 |
q |
198/q |
0.1934 |
6 |
2 |
120 |
0.2344 |
7 |
2 |
157 |
0.3066 |
8 |
2 |
193 |
0.3770 |
9 |
2 |
251 |
0.4902 |
10 |
2 |
308 |
0.6016 |
11 |
2 |
379 |
0.7402 |
12 |
2 |
449 |
0.8770 |
13 |
2 |
526 |
1.0273 |
14 |
2 |
602 |
1.1758 |
15 |
2 |
679 |
1.3262 |
16 |
4 |
378 |
1.4766 |
17 |
4 |
434 |
1.6953 |
18 |
4 |
490 |
1.9141 |
19 |
4 |
553 |
2.1602 |
20 |
4 |
616 |
2.4063 |
21 |
4 |
658 |
2.5703 |
22 |
4 |
699 |
2.7305 |
23 |
4 |
772 |
3.0156 |
24 |
6 |
567 |
3.3223 |
25 |
6 |
616 |
3.6094 |
26 |
6 |
666 |
3.9023 |
27 |
6 |
772 |
4.5234 |
28 |
q |
reserved |
|
29 |
2 |
reserved |
|
30 |
4 |
reserved |
|
31 |
6 |
reserved |
|
Table-27: MCS index table 2 for PUSCH with transform precoding and 64QAM Low SE. Standards table 6.1.4.1-2.
Transport block size (TBS) determination
The procedure for TBS determination is standardized in TS 38.214 Section 5.1.3.2 (DL) and 6.1.4.2 (UL). The standard specifies the TBS determination through Step 1, Step 2, Step 3, and Step 4, all which are implemented in NetSim.
NetSim first determines the TBS as specified below:
The UE shall first determine the number of Res (\(N_{RE})\)\(N_{RE})\) within the slot.
A UE first determines the number of REs allocated for PDSCH within a PRB \((N_{RE}'\)) by \(N_{RE}' = N_{sc}^{RB}{\times N}_{symb}^{PRB} - N_{DMRS}^{PRB} - N_{oh}^{PRB}\), where\(\ N_{sc}^{RB} = 12\) is the number of subcarriers in a physical resource block, \(N_{symb}^{slot}\)\(N_{symb}^{slot}\) is the number of symbols of the PDSCH allocation within the slot, \(N_{DMRS}^{PRB}\)\(N_{DMRS}^{PRB}\) is the number of REs for DM-RS per PRB in the scheduled duration and \(N_{oh}^{PRB}\)\(N_{oh}^{PRB}\) is the overhead configured by higher layer parameter and \(N_{oh}^{PRB}\) is set to 0.
A UE determines the total number of REs allocated for PDSCH (\(N_{RE})\)\(N_{RE})\)) by \(N_{RE} = \min\left( 156,N_{RE}' \right) \times n_{PRB}\)\(N_{RE} = \ {\overline{N}}_{RE}'*\ n_{PRB}\)\(N_{RE} = {\overline{N}}_{RE}'*n_{PRB}\), where \(n_{PRB}\)\(N_{RE} = \ {\overline{N}}_{RE}'*\ n_{PRB}\)\(N_{RE} = {\overline{N}}_{RE}'*n_{PRB}\) is the total number of allocated PRBs for the UE.
Intermediate number of information bits (\(N_{info}\)) is obtained by \(N_{info} = N_{RE} \times R \times Q_{M} \times \nu\) \(TBS_{temp} = N_{RE} \times R \times Q_{m} \times \nu.\)
When \(N_{info} \leq 3824\), TBS is determined as follows
quantized intermediate number of information bits \(N_{info}' = \max\left( 24,2^{n}\left\lfloor \frac{N_{info}}{2^{n}} \right\rfloor \right)\), where \(n = \max\left( 3,\left\lfloor \log_{2}\left( N_{info} \right) \right\rfloor - 6 \right)\).
use Table 5.1.3.2-1 find the closest TBS that is not less than \(N_{info}'\).
Index |
TBS |
Index |
TBS |
Index |
TBS |
Index |
TBS |
|---|---|---|---|---|---|---|---|
1 |
24 |
31 |
336 |
61 |
1288 |
91 |
3624 |
2 |
32 |
32 |
352 |
62 |
1320 |
92 |
3752 |
3 |
40 |
33 |
368 |
63 |
1352 |
93 |
3824 |
4 |
48 |
34 |
384 |
64 |
1416 |
||
5 |
56 |
35 |
408 |
65 |
1480 |
||
6 |
64 |
36 |
432 |
66 |
1544 |
||
7 |
72 |
37 |
456 |
67 |
1608 |
||
8 |
80 |
38 |
480 |
68 |
1672 |
||
9 |
88 |
39 |
504 |
69 |
1736 |
||
10 |
96 |
40 |
528 |
70 |
1800 |
||
11 |
104 |
41 |
552 |
71 |
1864 |
||
12 |
112 |
42 |
576 |
72 |
1928 |
||
13 |
120 |
43 |
608 |
73 |
2024 |
||
14 |
128 |
44 |
640 |
74 |
2088 |
||
15 |
136 |
45 |
672 |
75 |
2152 |
||
16 |
144 |
46 |
704 |
76 |
2216 |
||
17 |
152 |
47 |
736 |
77 |
2280 |
||
18 |
160 |
48 |
768 |
78 |
2408 |
||
19 |
168 |
49 |
808 |
79 |
2472 |
||
20 |
176 |
50 |
848 |
80 |
2536 |
||
21 |
184 |
51 |
888 |
81 |
2600 |
||
22 |
192 |
52 |
928 |
82 |
2664 |
||
23 |
208 |
53 |
984 |
83 |
2728 |
||
24 |
224 |
54 |
1032 |
84 |
2792 |
||
25 |
240 |
55 |
1064 |
85 |
2856 |
||
26 |
256 |
56 |
1128 |
86 |
2976 |
||
27 |
272 |
57 |
1160 |
87 |
3104 |
||
28 |
288 |
58 |
1192 |
88 |
3240 |
||
29 |
304 |
59 |
1224 |
89 |
3368 |
||
30 |
320 |
60 |
1256 |
90 |
3496 |
Table-28:TBS for N info ≤3824 from Standards Table 5.1.3.1-4
When \(N_{info} > 3824\), TBS is determined as follows.
quantized intermediate number of information bits \(N_{info}' = \max\left( 3840,2^{n} \times round\left( \frac{N_{info} - 24}{2^{n}} \right) \right)\), where \(n = \left\lfloor \log_{2}\left( N_{info} - 24 \right) \right\rfloor - 5\) and ties in the round function are broken towards the next largest integer.
if \(R \leq \frac{1}{4}\)
\(TBS = 8.C\left\lceil \frac{N_{info}' + 24}{8.C} \right\rceil - 24,\) where \(C = \left\lceil \frac{N_{info}' + 24}{3816} \right\rceil\)
else
if \(N_{info}' > 8424\)
\(TBS = 8.C\left\lceil \frac{N_{info}' + 24}{8.C} \right\rceil - 24,\) where \(C = \left\lceil \frac{N_{info}' + 24}{8424} \right\rceil\)
else
\(TBS = 8\left\lceil \frac{N_{info}' + 24}{8} \right\rceil - 24,\)
end if
end if
else if Table-24 is used and \(28 \leq I_{MCS} \leq 31\).
HARQ
Introduction
We start with a brief and simplistic explanation of the HARQ mechanism.
Hybrid automatic repeat request (hybrid ARQ or HARQ) is a combination of retransmissions and error correction. The HARQ protocol runs in the MAC and PHY layers.
In the 5G PHY, a code block group (CBG) is transmitted over the air by the transmitter to the receiver. If the CBG is successfully received the receiver sends back an ACK, else if the CBG is received in error the receiver sends back a NACK (negative ACK).
If the transmitter receives an ACK, it sends the next CBG. However, if the transmitter receives a NACK, it retransmits the previously transmitted CBG.
In 5G, the incorrectly received CBG is not discarded but stored at the receiver. When the re-transmitted CBG is received, the two CBGs are combined. This is called Hybrid ARQ with chase-combining (HARQ-CC).
Implementation in NetSim
HARQ is implemented in 4G (eNB) and in 5G (gNB) in both downlink and uplink.
A HARQ entity is defined for each gNB-UE pair, separately for Uplink and Downlink and for each component carrier. The HARQ entity handles the HARQ processes.
Max number of HARQ processes is 8 in 4G
Max number of HARQ processes is 16 in 5G
Each HARQ process transmits one Transport Block (TB) at any time
When operating in MIMO, each layer handles a different TB. This means that one TB is not transmitted across multiple layers.
Each TB is split into Code blocks (CBs) and CBs are grouped into Code Block Groups (CBGs).
At the receiver the CBGs are given to a multiplexer which combines the CBGs into a TB.
CBGs are always retransmitted at the same MCS as the first transmission. This restriction comes from the specification of the rate matcher in the 3GPP TS 38.212 standard.
Figure-11: We see the HARQ transmission process. The transmitter sends CBG1 which is errored. Therefore, the receiver sends a NACK. CBG1 is then retransmitted (transmission attempt 2). The receiver then soft combines the first and second transmissions, which is successful and hence sends back an ACK
HARQ entity is terminated during handover-triggered de-association from a gNB and re-created at the new gNB after the handover procedure is completed.
HARQ retransmissions have priority over new data transmissions. Within a HARQ process, new data transmissions are not taken up when retransmission data is in the queue.
HARQ processes are multiplexed in time (slots) in a round robin fashion. For example, if we had a case with 4 HARQ processes then:
Slot 1 – HARQ Process 1 > Success
Slot 2 – HARQ Process 2 > Success
Slot 3 – HARQ Process 3 > Error
Slot 4 – HARQ Process 4 > Success
Slot 5 – HARQ Process 1 > Success
Slot 6 – HARQ Process 2 > Success
Slot 7 – HARQ Process 3 > Retransmission Success
... and so on
Assumptions and limitations
The HARQ ACK/NACK is sent out-of-band by the receiver immediately after receipt (\(\Delta t \rightarrow 0^{+})\). It is then instantaneously and correctly received at the transmitter. The ACK/NACKs are not logged.
If DL/UL transmission can occur, then reverse direction (UL/DL respectively) ACK/NACK will be successful. Specifically, even if the UL data link is in outage, ACK/NACK transmitted in the UL will be correctly received by the gNB.
Transmission flow
Packets are either split or combined into transport blocks (TBs) depending on the packet size and the TB size. It is the TB that needs to be transmitted over the air.
Users can set the application layer packet size in NetSim GUI > Application properties. The packet size at the MAC is the application packet size plus transport layer and IP layer overheads. Users can obtain the MAC layer packet size from the packet trace.
The TB size is determined by the LTE and 5G NR protocol running in the MAC/PHY. Users can obtain the TB size from the code block log file (explained subsequently in section 3.9.12)
TB are then split to Code blocks (CBs). The code block size calculation and TB segmentation is explained in section 3.9.14 below.
CBs are grouped into code block groups (CBGs).
The max number of CBGs per TB can be set in the NetSim GUI (based on RRC parameter MAX CBG PER TB in the NetSim GUI)
TBs are transmitted by transmitting CBGs, which in turn comprises of CBs
BLER is applied upon CBG reception at the receiver
If any CB is in error, the transmitter retransmits the entire CBG to which that CB is a part of.
The receiver then soft combines the first transmission and all subsequent retransmissions
Soft combining is modelled by adding their SINRs in the linear scale. For example, if there were 2 retransmissions, then the combined SINR would be given by
BLER is applied on the improved (combined) SINR by tossing a biased coin
If any CB is in error, go to step 6, subject to transmit limit of 4 (retransmit limit of 3).
The transmit limit is user settable in NetSim, and by default is set to 4.
If all CBGs (in a TB) are successful, then at the receiver, the TB is sent up to the RLC
Else, the entire TB is dropped
Special cases
C1. If there is a retransmission scheduled in a multi-layer scenario, then the scheduler cannot retransmit data in one layer and transmit new data in another layer to the same UE. Hence during retransmissions, the scheduler allows other UEs to use the resources. The reason is: the next TB can only be sent after receiving a successful ACK or if the current TB is dropped. Therefore, another TB (to the same UE) cannot be scheduled on the remaining resources. For example, if Max-throughput scheduling is used, when a CBG is received in error the NDI flag is false. When the NDI flag is false, the UE is not passed through the scheduler function; only the CB that needs to be transmitted is Hence remaining PRBs left - after retransmitting the errored CBG - must be allocated to a not Max-SINR UE. Also note that, the not Max-SINR UE’s CBGs may also be errored in which case those CBGs need to be retransmitted. This above complicating factor leads to a breakdown in the general belief that Max-throughput scheduler leads to Max-SINR UE getting all throughput with other UEs getting NIL throughput.
C2. Again, consider a multi-layer scenario with CBG errors in 2 or more layers. How many PRBs should then be allocated for retransmissions and how many for new data from different UEs? In such cases NetSim calculates the PRBs required for retransmission as the max of PRBs required for retransmission in each layer.
Logging
Figure-12: HARQ log file showing code block transmission. Here CBS represents the information bits within a code block (CBS column).
Transmission attempts 1, 2, 3 and 4 are indexed as 0, 1, 2, 3. If the 4th attempt is errored, the CBG is dropped.
Packet trace only logs “packet” flow, and does not log flow of TBs, CBGs etc. Therefore, the packet trace logs a packet in the MAC OUT of the transmitter and subsequently if received successfully at the MAC IN of the receiver. If the packet is errored, it is also marked in the packet trace.
Note that if a TB is in error then all the packets that were part of the TB will be marked as error.
The transmission/re-transmission of CBs is logged in the Code Block logfile.
The remarks column would have messages for HARQ preparation and would be blank for actual transmissions.
TBS is always logged on a per layer basis.
CBGID is also on a per layer basis
SINR reported in the CBG log is the post-soft combining SINR.
Figure-13: HARQ log showing HARQ working via information provided in the Remarks columns
HARQ turn off
There are ongoing discussions of abandoning HARQ for the 1 ms end-to-end latency use case of URLLC. This decision implies that the code rate had to be lowered such that a single shot transmission, i.e., no retransmissions and no feedback, achieves the required BLER.
NetSim allows users to turn HARQ OFF via the GUI. Note that the code block log will continue to be written. Users will notice that errored CBGs are not retransmitted if HARQ is turned OFF. Since the CB/CBG is in error, that entire TB to which it belongs will be in error.
Users can inspect the packet trace and will see large numbers of packet errors if HARQ is turned OFF and if the UE is seeing a high BLER.
Segmentation of transport block into code blocks
If the transport block size is larger than 3824, a 16-bit CRC is added at the end of the transport block or a 24-bit CRC is added.
The transport block is divided into multiple equal size code blocks when the transport block size exceeds a threshold.
For quasi-cyclic low-density parity-check code (QC-LDPC) base graph 1, the threshold is equal to 8448.
For QC-LDPC base graph 2, the threshold is equal to 3840. In 5G NR, the maximum code block size number is 8448.
An additional 24-bit CRC is added at the end of each code block when there is a segmentation.
A CBG can have up to 2/4/6/8 CBs.
Maximum transport block size - 1,277,992.
LDPC BG 1, CBS Max, (\(K_{cb}\)) = 8448, LDPC BG 2, CBS Max, (\(K_{cb}\)) = 3840
\(L\ =\) Extra CRC bits, \(C\ =\) Number of Code blocks, \(TBS\ =\) Size of Transport block, \(K'\ = \ \)Information bits in code block. The base matrix expansion factor \(Zc\) is calculated by selecting minimum \(Zc\ \)in all sets of lifting size tables, such that: \(K_{b} \times Zc \geq K\). \(K_{b}\) denotes the number of information bit columns for the lifting size \(Zc.\)
BLER and CQI/MCS selection
NetSim GUI allows users to set the BLER, via the BLER drop down option. This option has two settings, and each setting in turn has different options for MCS selection. Both BLER and MCS selection are global options and will apply to all gNBs and UEs in both DL and UL in the network scenario.
Zero BLER
MCS Selection: Ideal Shannon theorem-based rate
The spectral efficiency (SE) is computed as
\[SpectralEfficiency = \log_{2}{(1 + SINR)}\]
This Spectral efficiency (SE) is matched with the Channel Quality Indicator (CQI) table, selecting the highest SE that does not exceed this calculated value. This SE (determined from the CQI table) then guides the selection of modulation and coding from the MCS table. For example if the SINR is \(- 1.4\ dB\), then \(\log_{2}{\left( 1 + 10^{- \frac{1.4}{10}} \right) = 0.782.}\) The highest SE \(\leq 0.782\) from the CQI table-2 is \(0.3770.\) This value of \(0.3770\) is then looked up in the MCS table-2; the modulation order is 2 and the code rate is 193.
Data is transmitted at this MCS with zero BLER
The spectral efficiency to MCS table is explained in section 3.9.11.1 (Modulation order and target code rate determination)
MCS Selection: Shannon rate with attenuation factor
MCS is chosen as explained as in the case of Ideal Shannon Theorem-based rate, but with the spectral efficiency calculated as
\[SpectralEfficiency = {\alpha \times log}_{2}(1 + SINR)\]Where \(\alpha\) is the attenuation factor and generally \(0.5 \leq \alpha \leq 1.00\). Default: \(0.75\)
Data is transmitted at this MCS with zero BLER.
A more general formula, available in literature, is \(Sprectral\ Efficiency = \alpha{\times log}_{2}{(1 + \beta \times SINR)}\) with \(0 < \beta \leq 1\). This can be easily programmed in NetSim by modifying the code to include \(\beta\) and then rebuilding it.
\(SINR\) in the above expressions is in linear scale
BLER Enable: Within this, users can set outer loop link adaptation (OLLA) to True or False
OLLA False: The MCS is chosen in exactly the same way as described in the Zero BLER case. Data is, however, transmitted at the chosen MCS, with BLER. The BLER is looked up from NetSim’s proprietary BLER-MCS-SINR curves.
OLLA True: In this case, the user needs to set a target BLER (t-BLER), for example 10%. Based upon the set t-BLER the MCS is dynamically adjusted based on an outer-loop link adaptation algorithm that uses HARQ ACK-NACK messages. Note that the t-BLER is based on initial transmission and not after a re-transmission. See 3.9.17 for working of OLLA.
BLER-MCS-SINR Curves
NetSim has exhaustive SINR-BLER data for various transport block sizes for all MCSs (1, 2, ..., 28) for Base graphs (1, 2) for all three tables (1, 2, 3). The SINR-BLER data was generated using an in-house proprietary link-level simulation program and the results have been carefully validated against published literature.
Outer Loop Link Adaptation (OLLA) (Part of Adv. 5G)
Figure-14: UE reports CQI based on SINR and the gNB transmits data at an MCS based on CQI
During the downlink AMC process, a user equipment (UE) reports the channel quality indicator (CQI) of the link to the gNB, as shown in Figure 3‑14. This CQI is based on the received instantaneous signal to interference plus noise ratio (SINR). OLLA is a feedback loop technique that adjusts the instantaneous SINR value by adding or subtracting an offset, using positive or negative acknowledgement signals (i.e., ACK or NACK respectively). The offset is updated continuously based on the Hybrid Automatic Repeat Request (HARQ) acknowledgement feedback, such that the average Block Error Rate (\(BLER_{A}\)) converges to a predefined target (\(BLER_{T})\)
Figure-15: MCS selection per inner loop link adaptation (without OLLA)
Rate adaptation has two parts:
an inner loop adaptation where the SINR measured by the user is used as an anchor to determine the transmission rate. This transmission rate is fed back, and
OLLA is used at the base-station to make appropriate corrections to this transmission rate
Figure-16: MCS selection with OLLA
The OLLA compensation is as follows:
Where \(e(k) = 0\) for ACK and \(e(k) = \ 1\) for NACK. The above expression can be thus written in this form given below to give a better understanding how ACK and NACK affect the evolution of the \(\Delta_{OLLA}(k).\)
We see that when a positive acknowledgment (ACK) is received, \(\Delta_{OLLA}\ \) is decreased by \(\Delta_{down}\), and when a negative acknowledgment (NACK) is received, \(\Delta_{OLLA}\ \) is increased by \(\Delta_{up}\).
The estimated SINR compensated by the OLLA mechanism is given by the following relationship in the log scale (units of dB)
We can see that a positive value of \(\Delta_{OLLA}\) leads to a lower value of\(\ \gamma_{eff}\), which translates into a pessimistic interpretation of the reported channel conditions and the selection of a conservative MCS. Conversely, a negative value of \(\Delta_{OLLA}\) leads to a higher \(\gamma_{eff}\), translating into an optimistic interpretation of the channel conditions and the selection of an aggressive MCS. At the beginning of each radio resource control (RRC) connection, \(\Delta_{OLLA}\) is initialized to a fixed value, \(\Delta_{ini}\), defined on a cell basis. As the connection progresses, \(\Delta_{OLLA}\ \)is progressively modified by OLLA based on HARQ feedback.
The ratio \(\frac{\Delta_{down}}{\Delta_{up}}\) controls the target BLER that OLLA converges to, and is given by
\(BLER_{T} = \frac{1}{\left( 1 + \frac{\Delta_{up}}{\Delta_{down}} \right)} \approx \ \frac{\Delta_{down}}{\Delta_{up}}\ \), if \(\Delta_{up} \gg \Delta_{down}\)
Typical values for \(\Delta_{up}\) and \(\Delta_{down}\) are 1 dB and 0.1 dB, respectively, to ensure quick recovery from high BLER situations and smooth convergence to equilibrium. These values yield a target BLER of 0.1 (10%).
Note that the target BLER is only reached at the end of large activity connections, for which a large number of ACKs and NACKs are received by the eNB. For these connections, OLLA reaches steady state and ∆OLLA fluctuates around the proper value due to random system errors. In contrast, for small activity connections, convergence is not guaranteed, unless ∆OLLA is properly initialized. When \(\Delta_{ini}\) is too large, \(\gamma_{eff}\) is initially far below the actual channel conditions. This leads to an excessively conservative selection of the initial MCS and, therefore, user throughput is below the maximum achievable value. Considering a typical value of \(\Delta_{down}\) 0.1 dB, OLLA needs at least 10 consecutive successful transmissions (i.e., 10 ms) to compensate for a 1 dB bias in SINR reporting. On the other hand, when \(\Delta_{ini}\) is too small, \(\gamma_{eff}\) is far above the actual channel conditions and a too aggressive MCS is initially selected. This causes high BLER figures and unnecessary retransmissions, thus lowering the net user data flow. In both cases, user throughput is negatively affected.
The target BLER for OLLA is at a transport block level and is defined as the ratio of TBs errored to the TBs transmitted. In the NetSim PHY, TBs are split into code blocks (CBs), which are sent over the air. CBs are aggregated into code block groups (CBG); the HARQ plus soft combining operates at a CBG level
Out of coverage
As explained in the assumptions, NetSim does not model physical control channels or reference signals. All measurements are made on the physical data channels. The downlink received SNR is determined from large scale pathloss and shadowing calculated per the stochastic propagation models in the 3GPP TR 38.900 standard, and fast fading calculated from the H matrix. This SNR calculation is done at the start of the simulation, and then at every instant a UE moves. It is a single wideband measurement at the center frequency. Interference from other gNBs is not considered in the SNR calculations.
Out of coverage in NetSim is based on the calculated spectral efficiency of the physical data channel. Spectral Efficiency is equal to \(\alpha \times log_{2}\left( 1 + \frac{E_{b}}{N_{0}} \right)\). A UE is out-of-coverage when this spectral efficiency falls below a threshold. This threshold is the value of the spectral efficiency of index 1 per 3GPP 38.214 Table 5.2.2.1.-2 for CQI Table 1, or 5.2.2.1.-3 for CQI Table 2, or 5.2.2.1.-4 for CQI Table 3.
The NetSim log would report CQI as 0 whenever this condition occurs. Note that the RRC connection is not released and NetSim does not currently model Radio Link Failures (RLF). If the UE’s spectral efficiency, with the same serving gNB again crosses the threshold, data transmissions can occur. Due to mobility, if the UE’s spectral efficiency from a different gNB, crosses the threshold then a handover procedure is initiated.
Carrier Aggregation
In NetSim carrier aggregation (CA) is done in both DL and in the UL. When doing CA, the PHY layer is separate for each component carrier (CC). Thus, each CC will have a different pathloss, SINR and TBS. Then the resources of all component carriers (CCs) are pooled at the MAC, and scheduling is across the pooled resources. However, in practice each UE may be assigned resources from a particular CC. Since NetSim doesn’t model frequency selective channel fading, there is generally negligible difference in network performance between allotting from a pool vs. allotting from one CC. The exception is when the data demand from any UE is greater than the capacity of a CC.
NetSim v13.3 GUI by default has options for Single Band and 2-band carrier aggregation. Loading all CA options – Single Band, 2 component carriers (CCs) and more than 2 CCs –requires the following change to be carried out.
Go to <NetSim-Install-directory>/docs/xml (for example C:Program FilesNetSimPro_v13_3Docsxml). Here you will find two folders (i) Properties, and (ii) Properties 5G All Carriers. NetSim GUI by default reads from the Properties folder which has only Single Band and 2CC CA.
Rename the Properties folder as say Properties 1CC_2CC and then rename Properties 5G All Carriers as Properties. Once this is done NetSim GUI will read the new properties folder which supports all CA options as explained in the section below.
The reason for having a separate folder with Single Band and 2 CC is because loading all CA folders takes a long time in NetSim GUI.
CA Configuration Table (based on TR 38 716 01-01 Rel 16 NR)
The Intra band CA configuration is based on TR 38716 01-01 Rel 16 NR. The interband CA configuration is based on 38 than716 02-00 for 2 bands DL / x bands UL, and TR 38.716 03 01 for 3 bands DL and 1 band UL. Carrier aggregation can be configured in the gNB's Physical layer properties. Following are the various configuration options that are available:
TDD Bands |
||||||||
|---|---|---|---|---|---|---|---|---|
CC Configuration Table |
||||||||
CC Configuration |
CC Count |
CC Type |
Frequency Range |
Uplink Low (MHz) |
Uplink High (MHz) |
|||
INTER_BAND_CC |
||||||||
CC_2DL_1UL_n39_n41 |
2 |
CC1, CC2 |
FR1 |
1880, 2496 |
1920, 2690 |
|||
CC_2DL_2UL_n39_n41 |
2 |
CC1, CC2 |
FR1 |
1880, 2496 |
1920, 2690 |
|||
CC_2DL_1UL_n41_n79 |
2 |
CC1, CC2 |
FR1 |
2496, 4400 |
2690, 5000 |
|||
CC_2DL_2UL_n41_n79 |
2 |
CC1, CC2 |
FR1 |
2496, 4400 |
2690, 5000 |
|||
CC_2DL_1UL_n40_n41 |
2 |
CC1, CC2 |
FR1 |
2300, 2496 |
2400, 2690 |
|||
CC_2DL_2UL_n40_n41 |
2 |
CC1, CC2 |
FR1 |
2300, 2496 |
2400, 2690 |
|||
CC_2DL_1UL_n50_n78 |
2 |
CC1, CC2 |
FR1 |
1432, 3300 |
1517, 3800 |
|||
CC_2DL_2UL_n50_n78 |
2 |
CC1, CC2 |
FR1 |
1432, 3300 |
1517, 3800 |
|||
CC_2DL_1UL_n41_n50 |
2 |
CC1, CC2 |
FR1 |
2496, 1432 |
2690, 1517 |
|||
CC_2DL_2UL_n41_n50 |
2 |
CC1, CC2 |
FR1 |
2496, 1432 |
2690, 1517 |
|||
CC_2DL_1UL_n39_n79 |
2 |
CC1, CC2 |
FR1 |
1880, 4400 |
1920, 5000 |
|||
CC_2DL_2UL_n39_n79 |
2 |
CC1, CC2 |
FR1 |
1880, 4400 |
1920, 5000 |
|||
CC_2DL_1UL_n40_n78 |
2 |
CC1, CC2 |
FR1 |
2300, 3300 |
2400, 3800 |
|||
CC_2DL_2UL_n40_n78 |
2 |
CC1, CC2 |
FR1 |
2300, 3300 |
2400, 3800 |
|||
CC_2DL_1UL_n40_n79 |
2 |
CC1, CC2 |
FR1 |
2300, 4400 |
2400, 5000 |
|||
CC_2DL_2UL_n40_n79 |
2 |
CC1, CC2 |
FR1 |
2300, 4400 |
2400, 5000 |
|||
CC_2DL_1UL_n77_n258 |
2 |
CC1, CC2 |
FR1, FR2 |
3300, 24250 |
4200, 27500 |
|||
CC_2DL_2UL_n77_n258 |
2 |
CC1, CC2 |
FR1, FR2 |
3300, 24250 |
4200, 27500 |
|||
CC_2DL_1UL_n78_n258 |
2 |
CC1, CC2 |
FR1, FR2 |
3300, 24250 |
3800, 27500 |
|||
CC_2DL_2UL_n78_n258 |
2 |
CC1, CC2 |
FR1, FR2 |
3300, 24250 |
3800, 27500 |
|||
CC_2DL_1UL_n79_n258 |
2 |
CC1, CC2 |
FR1, FR2 |
4400, 24250 |
5000, 27500 |
|||
CC_2DL_2UL_n79_n258 |
2 |
CC1, CC2 |
FR1, FR2 |
4400, 24250 |
5000, 27500 |
|||
CC_2DL_1UL_n78_n257 |
2 |
CC1, CC2 |
FR1, FR2 |
3300, 26500 |
3800, 29500 |
|||
CC_2DL_2UL_n78_n257 |
2 |
CC1, CC2 |
FR1, FR2 |
3300, 26500 |
3800, 29500 |
|||
CC_2DL_1UL_n41_n260 |
2 |
CC1, CC2 |
FR1, FR2 |
2496, 37000 |
2690, 40000 |
|||
CC_2DL_2UL_n41_n260 |
2 |
CC1, CC2 |
FR1, FR2 |
2496, 37000 |
2690, 40000 |
|||
INTRA_BAND_CONTIGUOUS_CC |
||||||||
CC_2DL_n41C_1UL_n41A |
2 |
CC1, CC2 |
FR1 |
2496, 2496 |
2690, 2690 |
|||
CC_2DL_n257G_2UL_n257G |
2 |
CC1, CC2 |
FR2 |
26500, 26500 |
29500, 29500 |
|||
CC_3DL_n257H_3UL_n257G |
3 |
CC1, CC2, CC3 |
FR2 |
26500, 26500, 26500 |
29500, 29500, 29500 |
|||
CC_3DL_n257H_3UL_n257H |
3 |
CC1, CC2, CC3 |
FR2 |
26500, 26500, 26500 |
29500, 29500, 29500 |
|||
CC_4DL_n257I_4UL_n257G |
4 |
CC1, CC2, CC3, CC4 |
FR2 |
26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500 |
|||
CC_4DL_n257I_4UL_n257H |
4 |
CC1, CC2, CC3, CC4 |
FR2 |
26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500 |
|||
CC_4DL_n257I_4UL_n257I |
4 |
CC1, CC2, CC3, CC4 |
FR2 |
26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500 |
|||
CC_5DL_n257J_5UL_n257G |
5 |
CC1, CC2, CC3, CC4, CC5 |
FR2 |
26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500 |
|||
CC_5DL_n257J_5UL_n257H |
5 |
CC1, CC2, CC3, CC4, CC5 |
FR2 |
26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500 |
|||
CC_5DL_n257J_5UL_n257I |
5 |
CC1, CC2, CC3, CC4, CC5 |
FR2 |
26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500 |
|||
CC_5DL_n257J_5UL_n257J |
5 |
CC1, CC2, CC3, CC4, CC5 |
FR2 |
26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500 |
|||
CC_6DL_n257K_6UL_n257G |
6 |
CC1, CC2, CC3, CC4, CC5, CC6 |
FR2 |
26500, 26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500, 29500 |
|||
CC_6DL_n257K_6UL_n257H |
6 |
CC1, CC2, CC3, CC4, CC5, CC6 |
FR2 |
26500, 26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500, 29500 |
|||
CC_6DL_n257K_6UL_n257I |
6 |
CC1, CC2, CC3, CC4, CC5, CC6 |
FR2 |
26500, 26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500, 29500 |
|||
CC_6DL_n257K_6UL_n257J |
6 |
CC1, CC2, CC3, CC4, CC5, CC6 |
FR2 |
26500, 26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500, 29500 |
|||
CC_6DL_n257K_6UL_n257K |
6 |
CC1, CC2, CC3, CC4, CC5, CC6 |
FR2 |
26500, 26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500, 29500 |
|||
CC_7DL_n257L_7UL_n257G |
7 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7 |
FR2 |
26500, 26500, 26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500, 29500, 29500 |
|||
CC_7DL_n257L_7UL_n257H |
7 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7 |
FR2 |
26500, 26500, 26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500, 29500, 29500 |
|||
CC_7DL_n257L_7UL_n257I |
7 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7 |
FR2 |
26500, 26500, 26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500, 29500, 29500 |
|||
CC_7DL_n257L_7UL_n257J |
7 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7 |
FR2 |
26500, 26500, 26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500, 29500, 29500 |
|||
CC_7DL_n257L_7UL_n257K |
7 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7 |
FR2 |
26500, 26500, 26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500, 29500, 29500 |
|||
CC_7DL_n257L_7UL_n257L |
7 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7 |
FR2 |
26500, 26500, 26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500, 29500, 29500 |
|||
CC_8DL_n257M_8UL_n257G |
8 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7, CC8 |
FR2 |
26500, 26500, 26500, 26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500, 29500, 29500, 29500 |
|||
CC_8DL_n257M_8UL_n257H |
8 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7, CC8 |
FR2 |
26500, 26500, 26500, 26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500, 29500, 29500, 29500 |
|||
CC_8DL_n257M_8UL_n257I |
8 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7, CC8 |
FR2 |
26500, 26500, 26500, 26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500, 29500, 29500, 29500 |
|||
CC_8DL_n257M_8UL_n257J |
8 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7, CC8 |
FR2 |
26500, 26500, 26500, 26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500, 29500, 29500, 29500 |
|||
CC_8DL_n257M_8UL_n257K |
8 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7, CC8 |
FR2 |
26500, 26500, 26500, 26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500, 29500, 29500, 29500 |
|||
CC_8DL_n257M_8UL_n257L |
8 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7, CC8 |
FR2 |
26500, 26500, 26500, 26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500, 29500, 29500, 29500 |
|||
CC_8DL_n257M_8UL_n257M |
8 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7, CC8 |
FR2 |
26500, 26500, 26500, 26500, 26500, 26500, 26500, 26500 |
29500, 29500, 29500, 29500, 29500, 29500, 29500, 29500 |
|||
CC_n258B |
2 |
CC1, CC2 |
FR2 |
24250, 24250 |
27500, 27500 |
|||
CC_n258C |
3 |
CC1, CC2, CC3 |
FR2 |
24250, 24250, 24250 |
27500, 27500, 27500 |
|||
CC_n258D |
2 |
CC1, CC2 |
FR2 |
24250, 24250 |
27500, 27500 |
|||
CC_n258E |
3 |
CC1, CC2, CC3 |
FR2 |
24250, 24250, 24250 |
27500, 27500, 27500 |
|||
CC_n258F |
4 |
CC1, CC2, CC3, CC4 |
FR2 |
24250, 24250, 24250, 24250 |
27500, 27500, 27500, 27500 |
|||
CC_n258G |
2 |
CC1, CC2 |
FR2 |
24250, 24250 |
27500, 27500 |
|||
CC_n258H |
3 |
CC1, CC2, CC3 |
FR2 |
24250, 24250, 24250 |
27500, 27500, 27500 |
|||
CC_n258I |
4 |
CC1, CC2, CC3, CC4 |
FR2 |
24250, 24250, 24250, 24250 |
27500, 27500, 27500, 27500 |
|||
CC_n258J |
5 |
CC1, CC2, CC3, CC4, CC5 |
FR2 |
24250, 24250, 24250, 24250, 24250 |
27500, 27500, 27500, 27500, 27500 |
|||
CC_n258K |
6 |
CC1, CC2, CC3, CC4, CC5, CC6 |
FR2 |
24250, 24250, 24250, 24250, 24250, 24250 |
27500, 27500, 27500, 27500, 27500, 27500 |
|||
CC_n258L |
7 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7 |
FR2 |
24250, 24250, 24250, 24250, 24250, 24250, 24250 |
27500, 27500, 27500, 27500, 27500, 27500, 27500 |
|||
CC_n258M |
8 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7, CC8 |
FR2 |
24250, 24250, 24250, 24250, 24250, 24250, 24250, 24250 |
27500, 27500, 27500, 27500, 27500, 27500, 27500, 27500 |
|||
INTRA_BAND_NONCONTIGUOUS_CC |
||||||||
CC_2DL_n41(2A)_1UL_n41A |
2 |
CC1, CC2 |
FR1 |
2496, 2496 |
2690, 2690 |
|||
CC_n260(5A) |
5 |
CC1, CC2, CC3, CC4, CC5 |
FR2 |
37000, 37000, 37000, 37000, 37000 |
40000, 40000, 40000, 40000, 40000 |
|||
CC_n260(6A) |
6 |
CC1, CC2, CC3, CC4, CC5, CC6 |
FR2 |
37000, 37000, 37000, 37000, 37000, 37000 |
40000, 40000, 40000, 40000, 40000, 40000 |
|||
CC_n260(7A) |
7 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7 |
FR2 |
37000, 37000, 37000, 37000, 37000, 37000, 37000 |
40000, 40000, 40000, 40000, 40000, 40000, 40000 |
|||
CC_n260(8A) |
8 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7, CC8 |
FR2 |
37000, 37000, 37000, 37000, 37000, 37000, 37000, 37000 |
40000, 40000, 40000, 40000, 40000, 40000, 40000, 40000 |
|||
CC_n260(2D) |
4 |
CC1, CC2, CC3, CC4 |
FR2 |
37000, 37000, 37000, 37000 |
40000, 40000, 40000, 40000 |
|||
CC_n260(2G) |
4 |
CC1, CC2, CC3, CC4 |
FR2 |
37000, 37000, 37000, 37000 |
40000, 40000, 40000, 40000 |
|||
CC_n260(3G) |
6 |
CC1, CC2, CC3, CC4, CC5, CC6 |
FR2 |
37000, 37000, 37000, 37000, 37000, 37000 |
40000, 40000, 40000, 40000, 40000, 40000 |
|||
CC_n260(4G) |
8 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7, CC8 |
FR2 |
37000, 37000, 37000, 37000, 37000, 37000, 37000, 37000 |
40000, 40000, 40000, 40000, 40000, 40000, 40000, 40000 |
|||
CC_n260(2H) |
6 |
CC1, CC2, CC3, CC4, CC5, CC6 |
FR2 |
37000, 37000, 37000, 37000, 37000, 37000 |
40000, 40000, 40000, 40000, 40000, 40000 |
|||
CC_n260(2O) |
4 |
CC1, CC2, CC3, CC4 |
FR2 |
37000, 37000, 37000, 37000 |
40000, 40000, 40000, 40000 |
|||
CC_n260(3O) |
6 |
CC1, CC2, CC3, CC4, CC5, CC6 |
FR2 |
37000, 37000, 37000, 37000, 37000, 37000 |
40000, 40000, 40000, 40000, 40000, 40000 |
|||
CC_n260(4O) |
8 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7, CC8 |
FR2 |
37000, 37000, 37000, 37000, 37000, 37000, 37000, 37000 |
40000, 40000, 40000, 40000, 40000, 40000, 40000, 40000 |
|||
CC_n260(2P) |
6 |
CC1, CC2, CC3, CC4, CC5, CC6 |
FR2 |
37000, 37000, 37000, 37000, 37000, 37000 |
40000, 40000, 40000, 40000, 40000, 40000 |
|||
CC_n260(4P) |
12 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7, CC8, CC9, CC10, CC11, CC12 |
FR2 |
37000, 37000, 37000, 37000, 37000, 37000, 37000, 37000, 37000, 37000, 37000, 37000 |
40000, 40000, 40000, 40000, 40000, 40000, 40000, 40000, 40000, 40000, 40000, 40000 |
|||
CC_n260(2Q) |
8 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7, CC8 |
FR2 |
37000, 37000, 37000, 37000, 37000, 37000, 37000, 37000 |
40000, 40000, 40000, 40000, 40000, 40000, 40000, 40000 |
|||
CC_n261(2H) |
6 |
CC1, CC2, CC3, CC4, CC5, CC6 |
FR2 |
27500, 27500, 27500, 27500, 27500, 27500 |
28350, 28350, 28350, 28350, 28350, 28350 |
|||
CC_n261(2I) |
8 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7, CC8 |
FR2 |
27500, 27500, 27500, 27500, 27500, 27500, 27500, 27500 |
28350, 28350, 28350, 28350, 28350, 28350, 28350, 28350 |
|||
CC_n261(2D)_n261A |
4 |
CC1, CC2, CC3, CC4 |
FR2 |
27500, 27500, 27500, 27500 |
28350, 28350, 28350, 28350 |
|||
CC_n261(2G)_n261A |
4 |
CC1, CC2, CC3, CC4 |
FR2 |
27500, 27500, 27500, 27500 |
28350, 28350, 28350, 28350 |
|||
CC_n261(3G)_n261A |
6 |
CC1, CC2, CC3, CC4, CC5, CC6 |
FR2 |
27500, 27500, 27500, 27500, 27500, 27500 |
28350, 28350, 28350, 28350, 28350, 28350 |
|||
CC_n261(4G)_n261A |
8 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7, CC8 |
FR2 |
27500, 27500, 27500, 27500, 27500, 27500, 27500, 27500 |
28350, 28350, 28350, 28350, 28350, 28350, 28350, 28350 |
|||
CC_n261(2O)_n261A |
4 |
CC1, CC2, CC3, CC4 |
FR2 |
27500, 27500, 27500, 27500 |
28350, 28350, 28350, 28350 |
|||
CC_n261(4O)_n261A |
8 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7, CC8 |
FR2 |
27500, 27500, 27500, 27500, 27500, 27500, 27500, 27500 |
28350, 28350, 28350, 28350, 28350, 28350, 28350, 28350 |
|||
CC_n261(7O)_n261A |
14 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7, CC8, CC9, CC10, CC11, CC12, CC13, CC14 |
FR2 |
27500, 27500, 27500, 27500, 27500, 27500, 27500, 27500, 27500, 27500, 27500, 27500, 27500, 27500 |
28350, 28350, 28350, 28350, 28350, 28350, 28350, 28350, 28350, 28350, 28350, 28350, 28350, 28350 |
|||
CC_n261(2P)_n261A |
6 |
CC1, CC2, CC3, CC4, CC5, CC6 |
FR2 |
27500, 27500, 27500, 27500, 27500, 27500 |
28350, 28350, 28350, 28350, 28350, 28350 |
|||
CC_n261(2Q)_n261A |
8 |
CC1, CC2, CC3, CC4, CC5, CC6, CC7, CC8 |
FR2 |
27500, 27500, 27500, 27500, 27500, 27500, 27500, 27500 |
28350, 28350, 28350, 28350, 28350, 28350, 28350, 28350 |
|||
SINGLE_BAND |
||||||||
n34 |
1 |
CC1 |
FR1 |
2010 |
2025 |
|||
n38 |
1 |
CC1 |
FR1 |
2570 |
2620 |
|||
n39 |
1 |
CC1 |
FR1 |
1880 |
1920 |
|||
n40 |
1 |
CC1 |
FR1 |
2300 |
2400 |
|||
n41 |
1 |
CC1 |
FR1 |
2496 |
2690 |
|||
n50 |
1 |
CC1 |
FR1 |
1432 |
1517 |
|||
n51 |
1 |
CC1 |
FR1 |
1427 |
1432 |
|||
n77 |
1 |
CC1 |
FR1 |
3300 |
4200 |
|||
n78 |
1 |
CC1 |
FR1 |
3300 |
3800 |
|||
n79 |
1 |
CC1 |
FR1 |
4400 |
5000 |
|||
n257 |
1 |
CC1 |
FR2 |
26500 |
29500 |
|||
n258 |
1 |
CC1 |
FR2 |
24250 |
27500 |
|||
n259 |
1 |
CC1 |
FR2 |
39500 |
43500 |
|||
n260 |
1 |
CC1 |
FR2 |
37000 |
40000 |
|||
n261 |
1 |
CC1 |
FR2 |
27500 |
28350 |
|||
n262 |
1 |
CC1 |
FR2 |
47200 |
48200 |
|||
n263 |
1 |
CC1 |
FR2 |
57000 |
71000 |
|||
FDD Bands |
||||||||
CC Configuration |
CC Count |
CC Type |
Frequency Range |
F_Low (MHz) |
F_High (MHz) |
|||
INTER_BAND_CC |
||||||||
CC_n1A_n8A |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
1920 880 2110 925 |
1980 915 2170 960 |
|||
CC_n1A_n28A |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
1920 703 2110 758 |
1980 748 2170 803 |
|||
CC_n3A_n8A |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
1710 880 1805 925 |
1785 915 1880 960 |
|||
CC_n3A_n28A |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
1710 703 1805 758 |
1785 748 1880 803 |
|||
CC_n7A_n28A |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
2500 703 2620 758 |
2570 748 2690 803 |
|||
CC_n7A_n66A |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
2500 1710 2620 2110 |
2570 1780 2690 2200 |
|||
CC_n20A_n28A |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
832 703 791 758 |
862 748 821 803 |
|||
CC_n25A_n71A |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
1850 663 1930 617 |
1915 698 1995 652 |
|||
CC_n66A_n70A |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
1710 1695 2110 1995 |
1780 1710 2200 2020 |
|||
CC_n66B_n70A |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
1710 1695 2110 1995 |
1780 1710 2200 2020 |
|||
CC_n66(2A)_n70A |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
1710 1695 2110 1995 |
1780 1710 2200 2020 |
|||
CC_n66A_n71A |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
1710 663 2110 617 |
1780 698 2200 652 |
|||
CC_n66B_n71A |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
1710 663 2110 617 |
1780 698 2200 652 |
|||
CC_n66(2A)_n71A |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
1710 663 2110 617 |
1780 698 2200 652 |
|||
CC_n70A_n71A |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
1695 663 1995 617 |
1710 698 2020 652 |
|||
CC_n66A_n70A_n71A |
3 |
CC1_UL CC2_UL CC3_UL CC1_DL CC2_DL CC3_DL |
FR1 |
1710 1695 663 2110 1995 617 |
1780 1710 698 2200 2020 652 |
|||
CC_n66B_n70A_n71A |
3 |
CC1_UL CC2_UL CC3_UL CC1_DL CC2_DL CC3_DL |
FR1 |
1710 1695 663 2110 1995 617 |
1780 1710 698 2200 2020 652 |
|||
CC_n66(2A)_n70A_n71A |
3 |
CC1_UL CC2_UL CC3_UL CC1_DL CC2_DL CC3_DL |
FR1 |
1710 1695 663 2110 1995 617 |
1780 1710 698 2200 2020 652 |
|||
INTRA_BAND_CONTIGUOUS_CC |
||||||||
CC_n1B |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
1920 1920 2110 2110 |
1980 1980 2170 2170 |
|||
CC_n7B |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
2500 2500 2620 2620 |
2570 2570 2690 2690 |
|||
CC_n66B |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
1710 1710 2110 2110 |
1780 1780 2200 2200 |
|||
CC_n71B |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
663 663 617 671 |
698 698 652 652 |
|||
INTRA_BAND_NONCONTIGUOUS_CC |
||||||||
CC_n3(2A) |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
1710 1710 1805 1805 |
1782 1785 1880 1880 |
|||
CC_n7(2A) |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
2500 2500 2620 2620 |
2570 2570 2690 2690 |
|||
CC_n25(2A) |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
1850 1850 1930 1930 |
1915 1915 1995 1995 |
|||
CC_n66(2A) |
2 |
CC1_UL CC2_UL CC1_DL CC2_DL |
FR1 |
1710 1710 2110 2110 |
1780 1780 2200 2200 |
|||
SINGLE_BAND |
||||||||
n1 |
1 |
CC1 |
FR1 |
1920 |
1980 |
|||
n2 |
1 |
CC1 |
FR1 |
1850 |
1910 |
|||
n3 |
1 |
CC1 |
FR1 |
1710 |
1785 |
|||
n5 |
1 |
CC1 |
FR1 |
824 |
859 |
|||
n7 |
1 |
CC1 |
FR1 |
2500 |
2570 |
|||
n8 |
1 |
CC1 |
FR1 |
880 |
915 |
|||
n12 |
1 |
CC1 |
FR1 |
699 |
716 |
|||
n20 |
1 |
CC1 |
FR1 |
832 |
862 |
|||
n25 |
1 |
CC1 |
FR1 |
1850 |
1915 |
|||
n28 |
1 |
CC1 |
FR1 |
703 |
748 |
|||
n66 |
1 |
CC1 |
FR1 |
1710 |
1780 |
|||
n70 |
1 |
CC1 |
FR1 |
1695 |
1710 |
|||
n71 |
1 |
CC1 |
FR1 |
663 |
698 |
|||
n74 |
1 |
CC1 |
FR1 |
1427 |
1470 |
|||
Table-29: CA Configuration Table
PHY: Omitted Features
The currently omitted features include:
Physical control channels: While calculating the TBS capacity, a fixed overhead is reduced to account for the control channels. This overhead fraction varies for UL and DL, across FR1 and FR2, and is provided in the standard.
Random access procedure
Power control
Supported max data rate
For NR, the approximate data rate for a given number of aggregated carriers in a band or band combination is computed as follows.
Where,
\(J\) is the number of aggregated component carriers in a band or band combination \(R_{\max} = 948/1024\).
For the \(j\)-th Component Carrier, \(v_{Layers}^{(j)}\) is the maximum number of supported layers given by higher layer parameter maxNumberMIMO-LayersPDSCH for downlink and maximum of higher layer parameters maxNumberMIMO-LayersCB-PUSCH and maxNumberMIMO-LayersNonCB-PUSCH for uplink.
\(Q_{m}^{(j)}\) is the maximum supported modulation order given by higher layer parameter supportedModulationOrderDL for downlink and higher layer parameter supportedModulationOrderUL for uplink.
\(f^{j}\) is the scaling factor given by higher layer parameter scalingFactor and can take the values 1, 0.8, 0.75, and 0.4.
\(\mu\) is the numerology (as defined in TS 38.211 [6]).
\(T_{s}^{\mu}\) is the average OFDM symbol duration in a subframe for numerology μ, i.e., \(T_{s}^{\mu} = \frac{10^{- 3}}{{14.2}^{\mu}}\).
Note that normal cyclic prefix is assumed, which has 14 OFDM symbols per slot or \(14 \times 2^{\mu}\) symbols per millisecond.
\(N_{PRB}^{BW(j),\mu}\) is the maximum Resource Block allocation in bandwidth \({BW}^{(j)}\) with numerology \(\mu\) as defined in 5.3 TS 38.101-1 [2] and 5.3 TS 38.101-2 [3], where \({BW}^{(j)}\) is the UE supported maximum bandwidth in the given band or band combination. The number of subcarriers per physical resource block (PRB) is fixed to 12.
\({OH}^{(j)}\)is the overhead and takes the following values.
0.14, for frequency range FR1 for DL
0.18, for frequency range FR2 for DL
0.08, for frequency range FR1 for UL
0.10, for frequency range FR2 for UL
The approximate maximum data rate can be computed as the maximum of the approximate data rates computed using the above formula for each of the supported band or band combinations.
For EUTRA in case of MR-DC, the approximate data rate for a given number of aggregated carriers in a band or band combination is computed as follows.
Where,
\(J\) is the number of aggregated EUTRA component carriers in MR-DC band combination.
\(TBS_{j\ \ }\)is the total maximum number of DL-SCH transport block bits received within a 1ms TTI for j-th CC, as derived from TS36.213 [22] based on the UE supported maximum MIMO layers for the j-th carrier and based on the modulation order and number of PRBs based on the bandwidth of the j-th carrier.
The approximate maximum data rate can be computed as the maximum of the approximate data rates computed using the above formula for each of the supported band or band combinations.
For MR-DC, the approximate maximum data rate is computed as the sum of the approximate maximum data rates from NR and EUTRA.
Propagation Models (Per 3GPP TR 38.900)
Overview
The pathloss and channel between a UE and a BS depends on:
Location: The pathloss depends on the UE’s location (UE-gNB distance) and is calculated separately for each connected UE. The pathloss computations are recomputed every time a UE moves.
Scenario: Rural Macro (RMa), Urban Macro (UMa), Urban Micro (Umi). This parameter is available as Outdoor Scenario in gNB properties > Interface (5G RAN) > Physical Layer > Channel Model. Each scenario has a different pathloss model defined in the standard. This property is common for the gNB and all connected UEs.
Whether the UE-gNB is Line-of-sight or Non-line-of-sight (LOS/NLOS): This parameter is available as LOS probability in gNB properties > Interface (5G RAN) > Physical Layer > Channel Model. The pathloss models defined in the standard differ for LOS and NLOS. This property is common for the gNB and all connected UEs. However, a different (uniform) random number is sampled for each associated UE so that different UEs will see different LOS/NLOS channels. For each UE, the LOS/NLOS random variable is sampled every time a UE moves, and hence a UE may switch from LOS to NLOS if it moves.
Shadow fading: This parameter is available as a Shadow fading model in gNB properties > Interface (5G RAN) > Physical Layer > Channel Model. This property is common for the gNB and all connected UEs. In this case, a different log-normal random variable is sampled for each associated UE. For each UE, the shadow fading random variable is sampled every time a UE moves.
Fading and beamforming: Fast fading is enabled by turning on the parameter Fading and Beamforming in gNB properties > Interface (5G RAN) > Physical Layer > Channel Model. Please see sections 3.9.3 and 3.9.4 for a detailed explanation. In essence, the eigenvalue of an (\(N_{r} \times N_{t}\)) random matrix is the fast-fading gain. Since the random matrix would be different for each gNB-UE pair the gains would be different. The fast-fading gains are recomputed every (user settable) coherence time whose default value is 10ms. The coherence time is common to all UEs attached to a gNB.
NetSim also features Indoor and Outdoor pathloss (PL) models.
NetSim GUI (gNB properties > Interface (5G RAN) > Physical Layer > Channel Model) allows users to configure both indoor and outdoor PL models. Both indoor and outdoor options are shown in the GUI irrespective of the underlying scenario.
Based on gNBs/UEs placement within or outside a building NetSim automatically chooses the indoor/outdoor propagation models. The selection is as follows:
Outdoor gNB to Outdoor UE: Outdoor PL model
Outdoor gNB to Indoor UE: Outdoor PL till building, then penetration (O2I) loss, and finally indoor PL within the building
Indoor gNB to Indoor UE: Indoor PL model
An Indoor gNB cannot be connected to an Outdoor UE in NetSim
Pathloss formulas
The pathloss models are summarized in Figure-17 and the distance definitions are indicated in Figure-17 and Figure-18. Note that the distribution of the shadow fading is log-normal, and its standard deviation for each scenario is given in Figure-17.
Figure-17: Definition of d2d and d3d from Standards Figure 7.4.1-1
Figure-18: Definition of d2d-out, d2d-in, and d2d-out and d3d-out, d3d-out for indoor UTs from Standards Figure 7.4.1-2
Note that,
\(d_{\text{3D} - \text{out}} + d_{\text{3D} - \text{in}} = \sqrt{\left( d_{\text{2D} - \text{out}} + d_{\text{2D} - \text{in}} \right)^{2} + \left( h_{\text{BS}} - h_{\text{UT}} \right)^{2}}\)
Table 7.4.1-1: Pathloss model |
||||
|---|---|---|---|---|
Scenario |
LOS/NLOS |
Pathloss [dB], fc is in GHz and d is in meters, see note 6 |
Shadow fading std [dB] |
Applicability range, antenna height default values |
RMa |
LOS |
\(PL_{\text{RMa} - \text{LOS}} = \left\{ \begin{matrix} PL_{1} & 10m \leq d_{\text{2D}} \leq d_{\text{BP}} \\ PL_{2} & d_{\text{BP}} \leq d_{\text{2D}} \leq 10\text{km} \end{matrix} \right.\ \), see note 5
\[{PL_{1} = 20\log_{10}(40\pi d_{\text{3D}}f_{c}/3) + \min(0.03h^{1.72},10)\log_{10}(d_{\text{3D}})
}{\text{ } - \min(0.044h^{1.72},14.77) + 0.002\log_{10}(h)d_{\text{3D}}}\]
\[PL_{2} = PL_{1}(d_{\text{BP}}) + 40\log_{10}(d_{\text{3D}}/d_{\text{BP}})\]
|
\[\sigma_{\text{SF}} = 4\]
\[\sigma_{\text{SF}} = 6\]
|
\[h_{\text{BS}} = \text{35m}\]
\[h_{\text{UT}} = 1.5m\]
\[W = 20m\]
\[h = 5m\]
h = avg. building height W = avg. street width The applicability ranges:
\[5m \leq h \leq 50m\]
\[5m \leq W \leq 50m\]
\[1\text{0m} \leq h_{\text{BS}} \leq 150m\]
\[1m \leq h_{\text{UT}} \leq 10m\]
|
NLOS |
\[PL_{\text{RMa} - \text{NLOS}} = \max(PL_{\text{RMa} - \text{LOS}},PL_{\text{RMa} - \text{NLOS}}')\]
for \(10m \leq d_{\text{2D}} \leq 5\text{km}\)
\[{PL_{\text{RMa} - \text{NLOS}}' = 161.04 - 7.1\log_{10}(W) + 7.5\log_{10}(h)
}{\text{ } - (24.37 - 3.7(h/h_{\text{BS}})^{2})\log_{10}(h_{\text{BS}})
}{\text{ } + (43.42 - 3.1\log_{10}(h_{\text{BS}}))(\log_{10}(d_{\text{3D}}) - 3)
}{\text{ } + 20\log_{10}(f_{c}) - (3.2(\log_{10}(11.75h_{\text{UT}}))^{2} - 4.97)}\]
|
\[\sigma_{\text{SF}} = 8\]
|
||
UMa |
LOS |
\(PL_{\text{UMa} - \text{LOS}} = \left\{ \begin{matrix} PL_{1} & 10m \leq d_{\text{2D}} \leq d_{\text{BP}}' \\ PL_{2} & d_{\text{BP}}' \leq d_{\text{2D}} \leq 5\text{km} \end{matrix} \right.\ \), see note 1
\[PL_{1} = 28.0 + 22\log_{10}(d_{\text{3D}}) + 20\log_{10}(f_{c})\]
\[{PL_{2} = 28.0 + 40\log_{10}(d_{\text{3D}}) + 20\log_{10}(f_{c})
}{\text{ } - 9\log_{10}((d_{\text{BP}}')^{2} + (h_{\text{BS}} - h_{\text{UT}})^{2})}\]
|
\[\sigma_{\text{SF}} = 4\]
|
\[1.5m \leq h_{\text{UT}} \leq 22.5m\]
\[h_{\text{BS}} = \text{25m}\]
|
NLOS |
\[PL_{\text{UMa} - \text{NLOS}} = \max(PL_{\text{UMa} - \text{LOS}},PL_{\text{UMa} - \text{NLOS}}')\]
for \(10m \leq d_{\text{2D}} \leq 5\text{km}\)
\[{PL}_{UMa - NLOS}' = 13.54 + 39.08\log_{10}(d_{3D}) + 20\log_{10}(f_{C}) - 0.6(h_{UT} - 1.5)\]
|
\[\sigma_{\text{SF}} = 6\]
|
\[1.5m \leq h_{\text{UT}} \leq 22.5m\]
\[h_{\text{BS}} = \text{25m}\]
Explanations: see note 3 |
|
Optional \(\text{PL} = 32.4 + 20\log_{10}\left( f_{c} \right) + 30\log_{10}\left( d_{\text{3D}} \right)\) |
\[\sigma_{\text{SF}} = 7.8\]
|
|||
UMi - Street Canyon |
LOS |
\(PL_{\text{UMi} - \text{LOS}} = \left\{ \begin{matrix} PL_{1} & 10m \leq d_{\text{2D}} \leq d_{\text{BP}}' \\ PL_{2} & d_{\text{BP}}' \leq d_{\text{2D}} \leq 5\text{km} \end{matrix} \right.\ \), see note 1
\[PL_{1} = 32.4 + 21\log_{10}(d_{\text{3D}}) + 20\log_{10}(f_{c})\]
\[{PL_{2} = 32.4 + 40\log_{10}(d_{\text{3D}}) + 20\log_{10}(f_{c})
}{\text{ } - 9.5\log_{10}((d_{\text{BP}}')^{2} + (h_{\text{BS}} - h_{\text{UT}})^{2})}\]
|
\[\sigma_{\text{SF}} = 4\]
|
\[1.5m \leq h_{\text{UT}} \leq 22.5m\]
\[h_{\text{BS}} = 10m\]
|
NLOS |
\[PL_{\text{UMi} - \text{NLOS}} = \max(PL_{\text{UMi} - \text{LOS}},PL_{\text{UMi} - \text{NLOS}}')\]
for \(10m \leq d_{\text{2D}} \leq 5\text{km}\)
\[{PL}_{UMi - NLOS}' = 35.3\log_{10}(d_{3D}) + 22.4 + 21.3\log_{10}(f_{C}) - 0.3(h_{UT} - 1.5)\]
|
\[\sigma_{\text{SF}} = 7.82\]
|
\[1.5m \leq h_{\text{UT}} \leq 22.5m\]
\[h_{\text{BS}} = 10m\]
Explanations: see note 4 |
|
Optional \(\text{PL} = 32.4 + 20\log_{10}\left( f_{c} \right) + 31.9\log_{10}\left( d_{\text{3D}} \right)\) |
\[\sigma_{\text{SF}} = 8.2\]
|
|||
InH - Office |
LOS |
\[PL_{\text{InH} - \text{LOS}} = 32.4 + 17.3\log_{10}(d_{\text{3D}}) + 20\log_{10}(f_{c})\]
|
\[\sigma_{\text{SF}} = 3\]
|
\[1m \leq d_{\text{3D}} \leq 150m\]
|
NLOS |
\[PL_{\text{InH} - \text{NLOS}} = \max(PL_{\text{InH} - \text{LOS}},PL_{\text{InH} - \text{NLOS}}')\]
\[PL_{\text{InH} - \text{NLOS}}' = 38.3\log_{10}\left( d_{\text{3D}} \right) + 17.30 + 24.9\log_{10}\left( f_{c} \right)\]
|
\[\sigma_{\text{SF}} = 8.03\]
|
\[1m \leq d_{\text{3D}} \leq 150m\]
|
|
Optional \(PL_{\text{InH-NLOS}}' = 32.4 + 20\log_{10}\left( f_{c} \right) + 31.9\log_{10}\left( d_{\text{3D}} \right)\) |
\[\sigma_{\text{SF}} = 8.29\]
|
\[1m \leq d_{\text{3D}} \leq 150m\]
|
||
Table-30: Pathloss model from Standards Table 7.4.1-1.
Note 1: Breakpoint distance \(\mathbf{d}_{\mathbf{BP}}^{\mathbf{'}}\mathbf{=}\frac{\mathbf{4 \times}\mathbf{h}_{\mathbf{BS}}^{\mathbf{'}}\mathbf{\times}\mathbf{h}_{\mathbf{UT}}^{\mathbf{'}}\mathbf{\times}\mathbf{f}_{\mathbf{c}}}{\mathbf{C}}\), where \(\mathbf{f}_{\mathbf{c}}\) is the centre frequency in Hz, \(\mathbf{c = 3 \times}\mathbf{10}^{\mathbf{8}}\mathbf{m/s\ \ }\)is the propagation velocity in free space, and \(\mathbf{h}_{\mathbf{BS}}^{\mathbf{'}}\) and \(\mathbf{h}_{\mathbf{UT}}^{\mathbf{'}}\mathbf{\ }\)are the effective antenna heights at the BS and the UT, respectively. The effective antenna heights h'BS and h'UT are computed as follows: \(\mathbf{\ }\mathbf{h}_{\mathbf{BS}}^{\mathbf{'}}\mathbf{=}\mathbf{h}_{\mathbf{BS}}\mathbf{-}\mathbf{h}_{\mathbf{E\ }}\), \(\mathbf{h}_{\mathbf{UT}}^{\mathbf{'}}\mathbf{=}\mathbf{h}_{\mathbf{UT}}\mathbf{-}\mathbf{h}_{\mathbf{E\ }}\), where \(\mathbf{h}_{\mathbf{BS}}\) and \(\mathbf{h}_{\mathbf{UT}}\) are the actual antenna heights, and \(\mathbf{h}_{\mathbf{E\ }}\mathbf{\ }\)is the effective environment height.
For UMi \(\mathbf{h}_{\mathbf{E\ }}\mathbf{=}\mathbf{\ 1.0m}\). For UMa \(\mathbf{h}_{\mathbf{E\ }}\mathbf{=}\mathbf{\ 1m}\) with a probability equal to \(\frac{\mathbf{1}}{\mathbf{1 + C(}\mathbf{d}_{\mathbf{2D}}\mathbf{,}\mathbf{h}_{\mathbf{UT}}\mathbf{)}}\mathbf{\ }\) and chosen from a discrete uniform distribution uniform \(\mathbf{(12,15,\ldots,(}\mathbf{h}_{\mathbf{UT}}\mathbf{- 1.5))\ }\)otherwise. With \(\mathbf{C(}\mathbf{d}_{\mathbf{2D}}\mathbf{,\ }\mathbf{h}_{\mathbf{UT}}\mathbf{)\ }\)given by
\(\mathbf{C}\left( \mathbf{d}_{\text{2D}}\mathbf{,}\mathbf{h}_{\text{UT}} \right)\mathbf{=}\left\{ \begin{matrix} \mathbf{0} & \mathbf{,}\mathbf{h}_{\text{UT}}\mathbf{< 13}\mathbf{m} \\ \left( \frac{\mathbf{h}_{\text{UT}}\mathbf{- 13}}{\mathbf{10}} \right)^{\mathbf{1.5}}\mathbf{g}\left( \mathbf{d}_{\text{2D}} \right) & \mathbf{,13}\mathbf{m \leq}\mathbf{h}_{\text{UT}}\mathbf{\leq 23}\mathbf{m} \end{matrix} \right.\ \),
Where,
\(\mathbf{g}\left( \mathbf{d}_{\text{2D}} \right)\mathbf{=}\left\{ \begin{matrix} \mathbf{0} & \mathbf{,}\mathbf{d}_{\text{2D}}\mathbf{\leq 18}\mathbf{m} \\ \frac{\mathbf{5}}{\mathbf{4}}\left( \frac{\mathbf{d}_{\text{2D}}}{\mathbf{100}} \right)^{\mathbf{3}}\mathbf{\exp}\left( \frac{\mathbf{-}\mathbf{d}_{\text{2D}}}{\mathbf{150}} \right) & \mathbf{,18}\mathbf{m <}\mathbf{d}_{\text{2D}} \end{matrix} \right.\ \).
Note that \(\mathbf{h}_{\mathbf{E\ }}\) depends on \(\mathbf{d}_{\mathbf{2D}}\) and \(\mathbf{h}_{\mathbf{UT}}\) and thus needs to be independently determined for every link between BS sites and UTs. A BS site may be a single BS or multiple co-located BSs.
Note 2: The applicable frequency range of the PL formula in this table is \(\mathbf{0.5\ < \ }\mathbf{f}_{\mathbf{c}}\mathbf{\ < \ }\mathbf{f}_{\mathbf{H\ }}\mathbf{\ }\)GHz, where \(\mathbf{f}_{\mathbf{H\ }}\mathbf{= \ 30\ }\)GHz for RMa and \(\mathbf{f}_{\mathbf{H}}\mathbf{\ = \ 100\ }\)GHz for all the other scenarios. It is noted that RMa pathloss model for \(\mathbf{> 7\ }\)GHz is validated based on a single measurement campaign conducted at 24 GHz.
Note 3: UMa NLOS pathloss is from TR 36.873 with simplified format and \({\mathbf{PL}\mathbf{\ }}_{\mathbf{UMa - LOS}}\mathbf{= \ }\mathbf{Pathloss\ of\ UMa\ LOS\ outdoor\ scenario}\).
Note 4: \({\mathbf{PL}\mathbf{\ }}_{\mathbf{UMi - LOS}}\mathbf{= \ Pathloss\ of\ UMi - Street\ Canyon\ LOS\ outdoor\ scenario.}\)
Note 5: Break point distance \(\mathbf{d}_{\mathbf{BP}}\mathbf{=}\frac{\mathbf{2\pi \times}\mathbf{h}_{\mathbf{BS}}\mathbf{\times}\mathbf{h}_{\mathbf{UT}}\mathbf{\times}\mathbf{f}_{\mathbf{c}}}{\mathbf{C}}\), where\(\mathbf{\ f}_{\mathbf{c}}\mathbf{\ }\)is the centre frequency in Hz, \(\mathbf{c = 3 \times}\mathbf{10}^{\mathbf{8}}\mathbf{m/s\ \ }\)is the propagation velocity in free space, and\(\mathbf{\ }\mathbf{h}_{\mathbf{BS}}\) and \(\mathbf{h}_{\mathbf{UT}}\) are the antenna heights at the BS and the UT, respectively.
Note 6: \(\mathbf{\ f}_{\mathbf{c}}\) denotes the center frequency normalized by 1GHz, all distance related values are normalized by 1m, unless it is stated otherwise.
NetSim enforces the following
RMa, UMa, UMI: If \(d_{2D} < 10m\) then \(d_{2D} = 10m\)
InH: If \(d_{2D} < 1m\) then \(d_{2D} = 1m\)
LOS probability
The Line-Of-Sight (LOS) probabilities are given in Table-31.
Scenario |
LOS probability (distance is in meters) |
|---|---|
RMa |
\(P_{r_{LOS}} = \begin{cases} 1, & d_{2D-out} \le 10m \\[6pt] \exp\left(-\frac{d_{2D-out}-10}{1000}\right), & 10m < d_{2D-out} \end{cases}\) |
UMi – Street canyon |
\(P_{r_{LOS}} = \begin{cases} 1, & d_{2D-out} \le 18m \\[6pt] \frac{18}{d_{2D-out}} + \exp\left(-\frac{d_{2D-out}}{36}\right)\left(1 - \frac{18}{d_{2D-out}}\right), & 18m < d_{2D-out} \end{cases}\) |
UMa |
\(P_{r_{LOS}} = \left[ \frac{18}{d_{2D-out}} + \exp\left(-\frac{d_{2D-out}}{63}\right)\left(1 - \frac{18}{d_{2D-out}}\right)\right] \left(1 + C'(h_{UT})\frac{5}{4}\left(\frac{d_{2D-out}}{100}\right)^3\right) \exp\left(-\frac{d_{2D-out}}{150}\right)\) where \(C'(h_{UT}) = \begin{cases} 0, & h_{UT} \le 13m \\[6pt] \left(\frac{h_{UT}-13}{10}\right)^{1.5}, & 13m < h_{UT} \le 23m \end{cases}\) |
Indoor – Mixed office |
\(P_{r_{LOS}} = \begin{cases} 1, & d_{2D-in} \le 1.2m \\[6pt] \exp\left(-\frac{d_{2D-in}-1.2}{4.7}\right), & 1.2m < d_{2D-in} \le 6.5m \\[6pt] \exp\left(-\frac{d_{2D-in}-6.5}{32.6}\right), & 6.5m < d_{2D-in} \end{cases}\) |
Indoor – Open office |
\(P_{r_{LOS}} = \begin{cases}1, & d_{2D\text{-}in} \leq 5m \\\exp\left(-\dfrac{d_{2D\text{-}in} - 5}{70.8}\right), & 5m < d_{2D\text{-}in} \leq 49m \\\exp\left(-\dfrac{d_{2D\text{-}in} - 49}{211.7}\right) \times 0.54, & 49m < d_{2D\text{-}in}\end{cases}\) |
NOTE: The LOS probability is derived with assuming antenna heights of 3m for indoor, 10m for UMi, and 25m for Uma |
|
Table-31: LOS probability from Standards Table 7.4.2-1
O2I penetration loss
O2I building penetration loss
The pathloss incorporating O2I building penetration loss is modelled as in the following:
\(PL = {PL}_{b} + {PL}_{tw} + {PL}_{in} + N\left( 0,\sigma_{P}^{2} \right)\) (7.4-2)
where \(\text{P}\text{L}_{b}\) is the basic outdoor pathloss given in Sub Clause 7.4.1, where \(d_{\text{3D}}\) is replaced by \(d_{\text{3D} - \text{out}} + d_{\text{3D} - \text{in}}\). \({PL}_{tw}\) is the building penetration loss through the external wall, \({PL}_{in}\) is the inside loss dependent on the depth into the building, and \(\sigma_{P}\) is the standard deviation for the penetration loss.
\({PL}_{tw}\) is characterized as:
\({PL}_{tw} = {PL}_{npi} - {10\log}_{10}{\sum_{i = 1}^{N}\left( p_{i} \times 10^{\frac{L_{material\_ i}}{- 10}} \right)}\) (7.4-3)
\(\text{P}\text{L}_{npi}\) is an additional loss is added to the external wall loss to account for non-perpendicular incidence; \(L_{material\_ i} = a_{material\_ i} + b_{material\_ i}\), \(f\) is the penetration loss of material \(i\) example values of which can be found in Table-32, \(p_{i}\) is proportion of \(i\)-th materials, where \(\sum_{i = 1}^{N}p_{i} = 1\); and \(N\) is the number of materials.
Material |
Penetration loss [dB] |
|---|---|
Standard multi-pane glass |
\[L_{\text{glass}} = 2 + 0.2f\]
|
IRR glass |
\[L_{\text{IIRglass}} = 23 + 0.3f\]
|
Concrete |
\[L_{\text{concrete}} = 5 + 4f\]
|
Wood |
\[L_{\text{wood}} = 4.85 + 0.12f\]
|
NOTE: f is in GHz |
|
Table-32: Material penetration losses from Standards Table 7.4.3-1
Table-33 gives \({PL}_{tw},\) \({PL}_{in}\), and \(\sigma_{P}\) for two O2I penetration loss models. The O2I penetration is UT-specifically generated and is added to the SF realization in the log domain.
Pathloss through external wall: \(\text{P}\text{L}_{\text{tw}}\) in [dB] |
Indoor loss: \(\text{P}\text{L}_{\text{in}}\) in [dB] |
Standard deviation: σP in [dB] |
|
|---|---|---|---|
Low-loss model |
\[5 - 10\log_{10}\left( 0.3 \cdot 10^{\frac{- L_{\text{glass}}}{10}} + 0.7 \cdot 10^{\frac{- L_{\text{concrete}}}{10}} \right)\]
|
0.5 \(d_{\text{2D} - \text{in}}\) |
4.4 |
High-loss model |
\[5 - 10\log_{10}\left( 0.7 \cdot 10^{\frac{- L_{\text{IIRglass}}}{10}} + 0.3 \cdot 10^{\frac{- L_{\text{concrete}}}{10}} \right)\]
|
0.5 \(d_{\text{2D} - \text{in}}\) |
6.5 |
Table-33: O2I building penetration loss model From Standards Table 7.4.3-2
\(d_{\text{2D} - \text{in}}\) is minimum of two independently generated uniformly distributed variables between 0 and 25 m for UMa and UMi-Street Canyon, and between 0 and 10 m for RMa. \(d_{\text{2D} - \text{in}}\) shall be UT-specifically generated.
Both low-loss and high-loss models are applicable to UMa and UMi-Street Canyon.
Only the low-loss model is applicable to RMa.
O2I model usage
The O2I Models such as Low Loss and High Loss are associated with the type of material used in the buildings and are used to calculate the penetration loss in case of an indoor scenario. In case of scenarios where UE's are not inside a building these parameters will not have any impact on the results. In an indoor scenario, users will be able to notice differences in the SNR.
Additional Loss Model
Apart from the channel losses per the 3GPP TR 38.900 specifications, NetSim allows modelling additional losses using MATLAB. This includes attenuation due to rain, fog, and gas.
Note that this implementation interfaces with MATLAB R2020(a/b). Lower versions of MATLAB are not directly supported.
The following is required to run these models:
An installed version of MATLAB R2020(a/b) in the same system where NetSim is installed or in a different system in the same network.
Registration of MATLAB as a COM server. Reference:
Configuration
Additional Loss Model can be configured in the gNB’s 5G RAN interface properties under channel models section of Physical Layer as shown in Figure-19.
Figure-19: gNB >Interface (5G_RAN) >Physical layer properties
Similarly, this can be configured in the eNB’s LTE interface properties under channel models section of Physical Layer as shown in Figure-20.
Figure-20: eNB >Interface (LTE) >Physical layer properties
Additional Loss Model is set to NONE by default. When MATLAB is selected, MATLAB MODEL drop down with options GAS, FOG, and RAIN will appear along with associated parameters as shown in Figure-21.
Figure-21: Additional Loss Model set to MATLAB in gNB >Interface (5G RAN) >Physical layer properties
Each model has associated parameters that can be configured, which is listed in Table-34.
Additional Loss Model |
Associated Parameters |
Value |
|---|---|---|
RAIN |
Rain Rate (mm/hr) |
16(default), Range 0 to 100 |
Tilt Angle |
0(default), Range -90 to 90 |
|
Elevation Angle |
0(default), Range -90 to 90 |
|
Exceedance Rain (%) |
0.01(default), Range 0.001 to 1 |
|
GAS |
Ambient Temperature (Celsius) |
15(default), Range -50 to 50 |
Dry Air Pressure (pa) |
101300(default), Range 50000 to 300000 |
|
Water Vapor Density (\(g/m^{3}\)) |
4(default), Range 1 to 10 |
|
FOG |
Ambient Temperature (Celsius) |
15(default), Range -50 to 50 |
Liquid Water Density ((\(g/m^{3}\)) |
0.5(default), Range 0 to 5 |
Table-34: Parameters in the various MATLAB additional loss models
NOTE: Rain and Gas models support frequencies from 1 to 1000 GHz and Fog model supports frequencies from 10 to 1000 GHz only.
Running Simulation
When Additional Loss Model option is set to MATLAB NetSim Simulation console waits for MATLAB Interface process to connect.
Figure-22: NetSim Simulation console waits for MATLAB Interface process to connect
MATLAB Interface process can be started and connected to the running instance of NetSim simulation using one of the following methods depending on where MATLAB is installed:
If MATLAB is installed in the same system where NetSim is installed. MATLAB Interface process can be launched directly from the design window of NetSim.
Go to Options Menu and select the Open MATLAB Interface option as shown below:
Figure-23: Open MATLAB Window Options
- Click on the OK button when the following message is displayed.
Figure-24: MATLAB Interface warning message
If MATLAB is installed in a different system in the same network, then MATLABInterface.exe (present in <NetSim Install Directory>/bin folder), can be started in that system, manually from command prompt and the IP address of the system where NetSim simulation has started can be passed as an argument as shown below:
Figure-25: MATLAB interface over an IP address
In both above cases, the MATLAB Interface process starts MATLAB process (MATLAB command window will open in minimized state) after which simulation in NetSim will start. During the simulation communication between NetSim and MATLAB is established to send inputs from NetSim to MATLAB pathloss models and to receive pathloss from MATLAB to NetSim happens via the MATLAB Interface process as shown below:
Figure-26: Runtime MATLAB interfacing window
The pathloss value obtained from MATLAB is added to the total loss calculated as per the 3GPP TR 38.900 specifications. At simulation end the MATLAB Interface process closes the MATLAB process that it started.
Downlink Interference Model
Configuration
Downlink Interference Model can be configured in the gNB’s 5G RAN interface properties under channel models section of Physical Layer as shown Figure-27.
Figure-27: gNB >Interface (5G RAN )>Physical layer properties
Downlink Interference Model is set to NO INTERFERENCE by default.
Graded distance-based Wyner model
The Wyner model is widely used due to its simplicity and analytical tractability. In this model:
Only interference from (two) adjacent cells is considered
Random user locations and pathloss variations are ignored, and
The interference intensity from each neighbouring base station (BS) is characterized by a single fixed parameter \((0 \leq \alpha \leq 1)\). The channel gain between BS and its home user is 1 and the intercell interference intensity is 𝛼. Thus, a user sees constant interference irrespective of its location.
These three simplifications lose a lot of information. We alter the Wyner model to address these flaws by:
Considering interference from arbitrary number of BSs
Factoring in the user location. The UEs distance from the interfering BS is an obvious factor that determines the interference intensity since the amount of interference caused depends on the signal attenuation with distance, the pathloss law. Since the Wyner model uses relative interference, the ratio of a UEs distance from serving and interfering BSs is used as one of the interference parameters.
Using a graded interference intensity model, whereby a UE will see a different value of 𝛼 at different locations, thereby modelling the effect of interference more accurately.
Technical description
We model DL interference from any number of interfering BSs. Let \(BS_{i}\) be the serving BS to \(UE_{k}\). Let \(BS_{j}\) be any other BS (\(j\ \neq i)\). Then the distance between \(UE_{k}\ \)and \(BS_{i}\) is denoted as \(D_{UE_{k}}^{BS_{i}}\), while the distance between UE and \(BS_{j}\) is denoted as \(D_{UE_{k}}^{BS_{j}}\).
A UE sees interference if \(\frac{\left( D_{UE_{K}}^{BS_{j}} - D_{UE_{K}}^{BS_{i}} \right)}{D_{UE_{K}}^{BS_{j}}}\ \)is within a User Defined threshold (for example, 20%). This ratio is also equal to \(1 - \frac{D_{UE_{k}}^{BS_{i}}}{D_{UE_{K}}^{BS_{j}}}\). When \(D_{UE_{K}}^{BS_{i}} \leq D_{UE_{K}}^{BS_{j}}\), we see that \(0 \leq \ \frac{\left( D_{UE_{K}}^{BS_{j}} - D_{UE_{K}}^{BS_{i}} \right)}{D_{UE_{K}}^{BS_{j}}} \leq 1\). The ratio is \(0\) when \(D_{UE_{K}}^{BS_{i}} = D_{UE_{K}}^{BS_{j}}\) and is \(1\) when \(D_{UE_{K}}^{BS_{i}} = 0\). When \(D_{UE_{K}}^{BS_{i}} = D_{UE_{K}}^{BS_{j}}\) the UE is equidistant from both BS i.e., at the cell edge. When \(D_{UE_{K}}^{BS_{i}} = 0\), the UE is at the centre of the serving BS, \(BS_{i}\).
Users at the cell-edge will see out of cell interference; as the user moves closer to the cell centre, it sees lesser interference.
We call this User Defined threshold as differential distance ratio threshold and denote it by \(DDR_{th}.\) The DDR threshold is used to define \(K\) thresholds, which are in turn used to determine the out of cell interference experienced by \(UE_{k}\), as explained below. First, we bin the \(DDR_{th}\), conditional on \(D_{UE_{K}}^{BS_{i}} \leq D_{UE_{K}}^{BS_{j}}\), into K steps, as follows:
\[0 \leq \frac{\left( D_{UE_{K}}^{BS_{j}} - D_{UE_{K}}^{BS_{i}} \right)}{D_{UE_{K}}^{BS_{j}}} < \left( \frac{{DDR}_{th}}{K} \right) \times 1\]\[\left( \frac{{DDR}_{th}}{K} \right) \times 1\ \leq \ \frac{\left( D_{UE_{K}}^{BS_{j}} - D_{UE_{K}}^{BS_{i}} \right)}{D_{UE_{K}}^{BS_{j}}} < \left( \frac{{DDR}_{th}}{K} \right)\ \times 2\]\[\ldots\]\[{\ldots }{\left( \frac{{DDR}_{th}}{K} \right) \times (K - 1) \leq \ \frac{\left( D_{UE_{K}}^{BS_{j}} - D_{UE_{K}}^{BS_{i}} \right)}{D_{UE_{K}}^{BS_{j}}} < \left( \frac{{DDR}_{th}}{K} \right) \times K}\]\[\left( \frac{{DDR}_{th}}{K} \right) \times K \leq \ \frac{\left( D_{UE_{K}}^{BS_{j}} - D_{UE_{K}}^{BS_{i}} \right)}{D_{UE_{K}}^{BS_{j}}}\]Where \({DDR}_{th}\), is a user input varying from 0.00 to 1.00 (default is 0.1 or 10%), and K, the number of steps, is a user input varying from 1 to 4 (default is 1). For example: if the given value for the DDR is 0.2 and nSteps is 4, then the range of the curves will be from 0 to \(\frac{0.2}{4} = 0.05,\) i.e 0 to 0.05, 0.05 to 0.10, 0.10 to 0.15, 0.15 to 0.2.
The relative interference for each of these steps would be \(I_{n}\ (0 \leq n \leq K)\) where \(K\ \)is the number of steps and \(n\) represents each individual step (\(n = p\) if the \(p^{th}\) inequality in the above is satisfied, counting the first inequality as the zeroth inequality).
We specify the interference power relative to the power received from \(BS_{i}\). Therefore, given the value of \(I_{n}\), interference power is calculated as the received power from \(BS_{i}\) (excluding beamforming gain) less \(I_{n}\). Thus
\[InterferencePowerfromBS_{j}\ (dB) = \ ReceivedPowerfromBS_{i}(dBm) - I_{n}^{j}(dB)\]Therefore, we have \(I_{n}^{i}(dB) = \ P_{serving}^{BS}(dBm) - \ P_{Interfering}^{BS}(dBm)\). This is equivalent to the Wyner model with \(\alpha = \frac{P_{Interfering}^{BS}}{P_{serving}^{BS}}\) in the linear scale; however, note that in our interference model, \(\alpha\) depends on the UE’s location, because \(I_{n}\) depends on the distance.
This interference powers (linear) from all interfering BSs are added to the noise power (in linear scale) and then
\[SINR = \ \frac{Received\ power\ from\ BS_{i} + BeamFormingGain}{\ NoisePower + \ \sum\ InterferencePower\ }\]Each \(I_{n}\) is a user input. It is subject to the limits \(0 \leq I_{n} \leq 20\ dB.\) NetSim will enforce the sanity check \(20 \geq \ I_{K - 1} \geq \ \ \ldots \geq \ I_{0} \geq 0\). Here \(I_{K}\ \)is the relative interference seen when the UE is near \(BS_{i}\) and \(I_{0}\) is the relative interference seen when the UE is nearly equidistant from its two nearest BSs (and hence far from \(BS_{i}\)).
In an ideal case, when the user is at the cell edge, the received power from \(BS_{i}\) will be roughly equal to the received power from \(BS_{j}\) (since it is equidistant from the two BSs), and so \(SINR_{CellEdge}\) will necessarily be less than 0 dB.
As the UE moves away from the cell edge and towards \(BS_{i}\), the received power from \(BS_{i}\) increases and that from \(BS_{j}\) decreases, and so the SINR improves. For this reason, we have the limits on \(I_{n}\) as \(0\ dB \leq \ I_{n} \leq 20\ dB\). If the user sets \(I_{n}\) to a large value, it will be equivalent to having no inter-cell interference.
Figure-28: Interference zones are the regions within the four curves and the cell boundary of gNBi. This example is for a case involving just 2 BSs with DDR = 0.4 and K = 4. The four curves are therefore the equations where (DUEKBSj − DUEKBSi) / DUEKBSj = k/4 = 0.1, 2k/4 = 0.2, 3k/4 = 0.3, and 4k/4 = 0.4. The handover interference region is also shown.
In case \(\frac{\left( D_{UE_{K}}^{BS_{j}} - D_{UE_{K}}^{BS_{i}} \right)}{D_{UE_{K}}^{BS_{j}}} > DDR_{th}\), the out of cell interference seen at the UE is set to \(I_{K}\). The default value of \(I_{K}\) is 0, i.e., cell centre users do not see any out of cell interference. The default values of \(I_{k}\) for \(k = 1,\ 2,\ \ldots,\ K - 1\) is 10 dB.
In NetSim, handover is triggered when the signal strength from \(BS_{j}\) is offset (3dB by default) higher than signal strength from \(BS_{i}\). A handover is not triggered when \(UE_{k}\) is equidistant from both BSs but only when it is slightly nearer to \(BS_{j}\). Therefore, the short time when \(D_{UE_{K}}^{BS_{i}} \geq D_{UE_{K}}^{BS_{j}}\) is a special case requiring a different interference power. We term this interference as “Handover interference” and is a separate user input. Handover interference is denoted as \(I_{- 1}\) and \(- 3dB \leq I_{- 1} \leq 0\ dB\).
Sample interference file format and example:
<gNB_i>, <gNB_j>, <DDRth>, <nSteps>,<i_-1>,<i_0>,<i_1>,<i_2> … <i_(n-1)>
gNB_11, gNB_12, 0.2, 4, -1, 1, 2, 3, 4
Exact Geometric Model
In this model NetSim computes interference from one or more interfering base-stations (BS or gNB) at a UE, based on (i) the gNB UE locations and (ii) the pathloss between the interfering gNB and the UE.
Figure-29: A simple scenario with 3 BSs and 6 UEs. The bold lines represent direct signals while the dashed lines represent interfering signals.
NetSim supports various 3GPP propagation models to calculate the pathloss between every BS (gNB) and every UE. One of the parameters in the pathloss equations is the distance between the BS and the UE. Some of the other user settable parameters used in the 3GPP models are (i) Centre frequency (chosen from the band selected) (ii) Rural or Urban environments (iii) UE-BS channel is in LOS or NLOS (iv) Shadow-fading in the UE-BS channel (v) Indoor or outdoor UE location, etc., Complete details of the 3GPP pathloss models supported in NetSim are given in 3.11.1.
Let \(BS_{i}\) be the serving BS to \(UE_{k}\). Let \(BS_{j}\) be any other BS (\(j\ \neq i)\). \(UE_{k}\) communicates with \(BS_{i}\) while all other BSs (\(j\ \neq i)\ \)act as interferers. The distance between \(UE_{k}\ \)and \(BS_{i}\) is denoted as \(D_{UE_{k}}^{BS_{i}}\), while the distance between UE and \(BS_{j}\) is denoted as \(D_{UE_{k}}^{BS_{j}}\). The power of the interfering signal from any \(BS_{j}\) at any \(UE_{k}\) depends on (i) the transmit power of the interfering BS and (ii) pathloss between the interfering BS and the UE. It can therefore be expressed as
where \(P^{BS_{j}}\) is the transmit power of \(BS_{j}\), \(PL_{UE_{k}}^{BS_{j}}\) represents the 3GPP model based pathloss between \(BS_{j}\) and \(UE_{k}\). This pathloss is dependent on \(D_{UE_{k}}^{BS_{j}}\) and the channel between \(BS_{j}\) and \(UE_{k}\). The interference powers (linear) from all interfering BSs (i.e., apart from the serving BS) are added to the noise power (in linear scale) and we get the expression
SINR determines the 5G PHY rate (throughput) that the UE would get. This is because the PHY Rate depends on the CQI/MCS which in turn depends on SINR. Section 3.2 explains the details.
The Wyner model is approximate but is computationally faster, while the geometric model is precise but computationally slower due to the calculations involved.
Interference modeling in OFDM in NetSim
NetSim doesn’t model the allocation of specific subcarriers to individual users. The aggregate resources are divided amongst the UEs per UEs’ requirements and the scheduling algorithm.
The received power at \(UE_{k}\) from \(BS_{i}\), with transmit power \(P_{i}\) is given (in the linear scale) as
\[P_{UE_{k}}^{BS_{i}} = \left( \frac{P_{i}}{PL_{UE_{k}}^{BS_{i}}} \right)\]
\(I_{ik}^{j}\) or the interference in linear scale at a \(UE_{k}\) (associated with \(BS_{i}\)) from \(BS_{j}\)
To normalize the power should we further multiply by the ratio given below
\[I_{ik} = \Sigma_{j}\ I_{ik}^{j} \times \left( \frac{RB_{UE_{k}}^{slot}}{RB_{total}^{slot}} \right)\]
Assumptions:
A1. The above formula assumes the interference seen by \(UE_{k}\) is proportional to the number of RBs allotted to\(\ UE_{k}\)
A2. Fast fading is not accounted for in the interfering signal calculations since it would require too much computational time, given that it needs to be re-calculated every coherence time, not just between BS and its associated UEs but between a BS and all the UEs in all cells. Hence NetSim calculates average interfering signal power and not instantaneous interfering signal power, which is a well-accepted assumption in multi-cell MIMO literature. Recall that NetSim accounts for fast fading in the direct signal power calculations.
The total noise seen will be
\[k \times T \times \ RB_{UE_{k}}^{slot}\]
The signal power \(P_{UE_{k}}^{BS_{i}} \times \left( \frac{RB_{UE_{k}}^{slot}}{RB_{total}^{slot}} \right)\)
Therefore,
Interference in MIMO
If \(UE_{k}\) is receiving from \(BS_{i}\) in multiple layers, the interference power \(I_{ik}^{j}\) is the same for all layers.
\[SINR_{L} = \ \frac{P_{UE_{k}}^{BS_{i}} \times \lambda_{L}}{k \times T \times \ RB_{total}^{slot} + \ \Sigma_{j}\ I_{ik}^{j}\ }\]
Where \(L\) represents a MIMO layer.
Note that neither the noise nor the interference is divided by the layer count, because the combining vector has unit norm.
Fast fading component of interfering signals
NetSim accounts for the Rx power from neighboring cells, in a statistical sense, as explained below. Let us consider an example of two BSs and two UEs with BS1 transmitting to UE1 and BS2 transmitting to UE2. The BSs employ digital (Eigen) beamforming to the UE they are transmitting to, so there is no channel-dependent beamforming between BS1 and UE2 or BS2 and UE1.
Due to this, the interference seen by UE2 due to BS1’s transmission will depend on the inner product between the beamforming vector employed by BS1 (which depends only on the channel between BS1 and UE1) and the channel between BS1 and UE2 (which is independent of the channel between BS1 and UE1.)
Now, since we model the fast-fading component of the channel as having i.i.d. circularly symmetric complex Gaussian entries, the expected interference power at UE2 is simply the transmit power by BS1 times the pathloss between BS1 and UE2. This is because the long-term statistical average of the square of the magnitude of the inner product between the (unit-norm) beamforming vector employed by BS1 and the channel between BS1 and UE2 is unity.
Limitations
In the above interference formula NetSim assumes that all interfering BSs transmit data in that slot.
The interference calculations need to be done for each slot. Enabling interference will slow down the simulation.
Uplink Interference Model
NetSim uses Interference-over-thermal (IoT), to model uplink interference. Modeling uplink interference as IoT (also called as rise over thermal noise) allows for the calculation of the interference level relative to the thermal noise level. This can provide insight into the performance of the system and the impact of uplink interference on the signal-to-noise ratio (SNR). For example, if the uplink interference level is 10 dB higher than the thermal noise level, this indicates that the interference is significantly affecting the SNR and the performance of the system.
Users can input IoT in the NetSim GUI and it available in the eNB/gNB properties. The expression for the signal to interference noise ratio is given by
Converting to linear
Therefore, with \(N\) being the thermal noise, the interference power in linear scale is
We thus get the Interference power in dBm as
This value of \(I\) in dBm units is logged in the Radio Measurements csv file (if turned on). Example outputs are provided in Table-35 for various values of IoT and Bandwidth.
Bandwidth (MHz) |
Noise (dBm) |
IoT (dB) |
Interference (dBm) |
|---|---|---|---|
100 |
-93.82 |
3 |
-63.83 |
100 |
-93.82 |
2 |
-73.87 |
50 |
-96.83 |
2 |
-76.88 |
50 |
-96.83 |
1 |
-87.29 |
10 |
-103.82 |
1 |
-94.28 |
Table-35: Example table showing interference in dBm that will be logged in radio measurements file for a different IoT (dB) and Bandwidth (MHz) settings
5G Core
NetSim 5G core functionality was introduced in NetSim v13. This 5G core includes entities, which reside within the core devices (and partially within the gNB) such as Session Management Function (SMF), Access and Mobility Management Function (AMF) and User Plane Function (UPF) and the protocols these entities use for operation.
The NetSim 5G core model provides users the means to simulate the end-to-end IP connectivity. It supports interconnection of multiple UEs to the Internet/Cloud via the Radio Access Network or RAN. The RAN consists of multiple gNBs. These gNBs connect to the 5G core in the backhaul. In NetSim, the 5G core comprises a single AMF, SMF and UPF.
Figure-30: 5G Network scenario consisting of multiple UEs and gNBs connected to 5G Core - AMF, SMF and UP. The UPF is connected to the Data Network/ Internet.
NetSim 5G Core model has been designed as follows:
The Packet type supported in NetSim 5G Core is IPv4.
A single set of SMF/UPF/AMF entities are only available. Scenarios with inter SMF mobility / inter AMF mobility are not supported in NetSim.
It is possible for a single UE to use different applications with different QoS models. Hence, multiple EPS Bearers are supported for each UE. This includes necessary classification of TCP/UDP traffic over IP done at the UE in the Uplink and at the UPF in the downlink.
The NetSim 5G model allows users to perform an XN based handover between two gNBs.
In the 5G standalone architecture, the roles played by each of the entities are different.
A UE has the following interactions:
The random-access procedure to initiate communication with the gNB.
Setup the RRC connection with the gNB.
Perform NAS level authentication.
Handle the RRC Reconfiguration from the gNB and this message sets up the default PDU session.
The UE concludes the registration procedure.
Data flow takes place in both the downlink and uplink directions.
The gNB acts as a bridge between the UE and the 5G Core. The gNB:
Handles the random-access request from the UE and assigns resources for initiating the RRC connection.
Set up the RRC connection with the UE. SRB1 is set up at this point. Starting at this point the gNB starts assigning downlink and uplink resources to the UE.
Transports the Registration Request from the UE to the AMF.
Carries the NAS signalling between the UE and the gNB.
The 5G Core initiates the default PDU session setup. A Registration Accept is also received from the UE.
Activates the default PDU session via the RRC Reconfiguration message. It also transports the Registration Complete message to the AMF.
The downlink and uplink data flow takes place between the UE and the Internet.
The AMF or Access Mobility Function coordinates the 5G Standalone registration procedure.
Handles the Initial UE Message from the gNB. This message carries the Registration Request from the UE.
On receiving the Registration Request, the AMF obtains the UE context.
AMF updates the SMF context and sends an Initial Context Setup Request to activate the default PDU session. The message also carries the Registration Accept message from the AMF.
When the gNB signals that the Initial Context setup has been completed, the AMF updates the SMF context.
The AMF also notifies the SMF when the session is ready for uplink and downlink data transfer.
All messages related to session management are forwarded over the N11 reference interface to the Session Management Function (SMF).
The SMF or Session Management Function serves as a control plane entity and it is responsible for the session management.
The SMF assigns an IP address to be used for sending uplink data.
The SMF selects the UPF to be used for the session.
The SMF updates the UPF using PFCP messages via the N4 control-data plane interface.
The UPF or User Plane function is a data plane component that handles user data.
The UPF is completely controlled from the SMF using the N4 interface. The SMF uses the Packet Forwarding Control Protocol (PFCP) to update the data plane.
The UPF is responsible for packet routing and forwarding, packet inspection, QoS handling, and external PDU session for interconnecting Data Network (DN), in the 5G architecture.
The UPF represents the data plane evolution of a Control and User Plane Separation (CUPS) strategy and is introduced as an extension to existing Evolved Packet Cores (EPCs).
The UPF identifies user plane traffic flow based on information received from the SMF over the N4 reference point. The N4 interface employs the Packet Forwarding Control Protocol (PFCP).
5G Interfaces
5G Interfaces present in NetSim are as follows:
5G_N1_N2: N1-N2 is the reference point between the gNB (gNodeB) and the AMF.
5G_N3: Interface between the RAN (gNB) and the (UPF).
5G_N4: Interface between the Session Management Function (SMF) and the UPF
5G_N6: Interface between the Data Network (DN) and the UPF.
5G_N11: Interface between the SMF and AMF.
5G_XN: Interface between two RAN (gNB) nodes.
Figure-31: 5G Network scenario depicting the 5G Interfaces in NetSim
The NG-AP interface (N2) provides control plane interaction between the gNB and the AMF. In NetSim, this interface is modelled in an abstract manner, with direct interaction between the gNB and the AMF. The encoding of NGAP messages and information elements specified in [TS36413] is not implemented.
The NG-AP primitives that are modelled are:
INITIAL UE MESSAGE AND REGISTRATION REQUEST
INITIAL CONTEXT SETUP REQUEST
INITIAL CONTEXT SETUP RESPONSE AND REGISTRATION COMPLETE
PATH SWITCH REQUEST
PATH SWITCH REQUEST ACKNOWLEDGE
The N11 interface provides control plane interaction between the SMF and the AMF using the GTPv2-C protocol specified in [TS29274]. In NetSim, this interface is modelled with direct interaction between the SMF and the AMF objects, without implementing the encoding of the messages.
The N11 primitives that are modelled are:
CREATE SESSION REQUEST
CREATE SESSION RESPONSE
MODIFY BEARER REQUEST
MODIFY BEARER RESPONSE
Of these primitives, the first two are used during the initial UE attachment for the establishment of the N2-U bearers; the other two are used during handover to switch the N2-U bearers from the source gNB to the target gNB because of the reception by the AMF of a PATH SWITCH REQUEST NG-AP message.
Cell Selection and UE attach procedure
Figure-32: A 5G network scenario with a Single UE connected to a gNB which is connected to the 5G Core and the UE downloads data from the Server (Wired Node)
As an example, consider a 5G network scenario with 5G Core devices (which consists of AMF, SMF, UPF and three L2 Switches), a UE which is connected to a gNB, and in the server side, a Wired Node which is connected to a Router which is connected to the 5G core via UPF.
Figure-33: UE Attach Procedure
The attachment process is as follows:
Radio Resource Control (RRC) Master Information Block (MIB) packets are broadcast by each gNB to all the UEs. These packets are transmitted periodically every 80 ms.
If the number of gNBs is ‘m’ and the number of UEs is ‘n’, then the number of MIB packets transmitted each time will be ‘m x n’
The transmission of MIB packets starts from the MAC Layer. The transmission time can be calculated from the MAC Layer Arrival Time in the packet trace.
The size of each MIB packet is 8 Bytes and can be observed in the Phy Layer Payload field in the packet trace.
RRC System Information Block 1 packets are broadcast by the gNBs to all the UEs. These packets are transmitted periodically every 160ms.
The transmission of SIB1 packet starts from the MAC Layer. The transmission time can be calculated from the MAC Layer Arrival Time in the packet trace.
If the number of gNBs is ‘m’ and the number of UEs is ‘n’, then the number of SIB packets transmitted each time will be ‘m x n’
The size of each SIB1 packet is 8 Bytes. This can be observed in the Phy Layer Payload field in the packet trace.
After the first set of packets, the cell selection occurs as explained below.
The UE attaches itself initially to the gNB from which it receives the highest SSB SNR.
If SNRs from multiple gNBs are equal, the UE will attach to the gNB with the lowest ID.
The gNB to which the UE is connected by the user in NetSim GUI at the network design stage, is only for visual purposes. It plays no role in determining to which gNB the UE will eventually be attached.
RRC System Information is broadcast by the selected gNBs to all UEs when the cell selection is complete.
The SI packet is sent only once during the simulation. It is not sent after every Handover.
It occurs at 160.9ms.
The transmission of SI packet starts from the MAC Layer. The transmission time can be calculated from the MAC Layer Arrival Time in the packet trace.
The size of each SI packet is 8 Bytes. The size of the packet can be calculated from the Phy Layer Payload field in the packet trace.
The RRC Setup Request will be sent by the UE to the connected gNB within 2.5ms of receipt of RRC SI packet
The RRC Setup Request is sent with the random UE-Identity and an establishment cause. This can be observed in the Headers column of the packet trace.
The RRC Setup message is used to establish SRB1.
Selected gNB sends the setup to UE which contains RRCTransactionIdentifier, RRCResponsetype, PDCP Properties: UEID and GNBID, DiscardDelayTimer, T_Reordering, Hdr Type, SN=0, dcBit.
RRC Setup Packet Size is 24 Bytes. The size of the packet can be calculated from the Phy Layer Payload field in the packet trace.
UE stops the timer (T300) when it receives the RRC Setup message.
UE makes a transition to RRC connected mode.
The RRC Setup Complete message is used to confirm the successful completion of an RRC connection establishment.
UE sends this message on receipt of the RRC Setup message.
Contains RRCTransactionIdentifier, SelectedPLMNIdentity, AMFIdentifier, Gaumi Type, Hdr Type, SN, dcBit
UE sends UE MEASUREMENT REPORT to the connected gNB. The measurement report is sent by each UE to its serving gNB and it contains SINR from all gNBs
If the SNR from another gNB is offset greater than SNR from serving gNB, it leads to handover. After the handover procedure is completed RRC Reconfiguration would happen between target gNB and UE. The UE will then send the UE MEASUREMENT REPORT to this gNB.
These can be observed in the NetSim Packet Trace.
Figure-34: RRC connection establishment in Packet Trace
5G Core connection management process
This functionality is based on (3gpp 38.413)
The gNB will introduce the UE to the 5G Core after the initial gNB- UE attachment process.
The gNB will send Initial UE message and Registration request to the selected AMF (currently NetSim supports only one AMF). The message will be transmitted when gNB receives the first NAS message to be transmitted from the radio link after the RRC Setup Complete
Upon receiving the UE message and registration request, the AMF will send Create Session Request to the SMF in-order to create a session for the UE.
The SMF will send the PFCP Session Request to UPF to denote that the UE is present in the network and the data packet flow may occur to UPF and to create/ establish/ modify PFCP session for UE.
Further, AMF will send the Initial Context Setup Request to the gNB to confirm the setup of a UE context.
The gNB will send Initial Context Setup and Registration Complete messages to the AMF and then the UE will be associated with the core.
These can be observed in NetSim Packet Trace file
Figure-35: 5G Core connection management process
When the UE attachment is completed, the data packets will be transmitted from the source to the destination via the UPF.
5G Non-Stand Alone (NSA)
Overview
NSA leverages the existing LTE radio access and core network (EPC) to anchor 5G NR using the Dual Connectivity feature. This solution provides a seamless option to deploy 5G services with very less disruption in the network. The eNB is connected to the EPC through the LTE S1 interface and to the gNB through the XN interface. The gNB can be connected to the EPC through the LTE_S1 interface and other gNBs through the XN interface. Similarly, the eNBs and gNBs will be connected to 5G Core through the N1-N2, and N3 interfaces and gNB-eNB and gNB-gNB connections through the XN interface. The control packets like RRC MIB, RRC SIB1, RRC SI in NSA modes will be transmitted from the master nodes to the UE. Similarly, the UE will send the UE MEASUREMENT REPORT and RRC SETUP messages to the master nodes. The master node will be selected according to the deployment option selected.
The NSA modes in NetSim 5G module includes:
Option 4 where only 5G Core devices are present, and EPC is not available. Here, gNB is the Master Cell and eNB is the Secondary Cell. Option 4 is categorized into:
Option 4: Only gNB connects to all the 5G Core interfaces. eNB connects to the XN interface.
Option 4a: gNB connects to all 5G Core interfaces and eNB connects to AMF and UPF through respective interfaces.
Option 7 where only 5G Core devices are present, and EPC is not available. Here, eNB is the Master Cell and gNB is the Secondary Cell. Option 7 is categorized into:
Option 7: eNB connects to all 5G Core interfaces. gNB connects only to the XN interface.
Option 7a: gNB connects to all the 5G Core interfaces. eNB connects to AMF and UPF through the respective interfaces.
Figure-36: NSA deployment - Option 4, Option 4a Networking modes
Figure-37: NSA deployment - Option 7, Option 7a Networking modes
In Options 4 and 7, the secondary node is not directly connected with the LTE-EPC/ 5G-Core. On reception of a packet, the secondary node, transmits all packet to the master node via the XN interface for uplink cases and for downlink cases, the core / EPC transmits the packets to the master node and the master node splits the traffic between itself and the secondary node, since there is no connection between the core and secondary node. The master node also transmits the packets to the UE.
In options 4a and 7a, the split happens at the EPC/UPF.
Option 4/4a
Option 4 consists of a 5G Core. The master node is the LTE NR cell or gNB and the secondary node is LTE cell or eNB.
Option 4
In Option 4 of Non-Stand-alone mode, both LTE and 5G NR radio access technologies are deployed and controlled through only the 5G Core, i.e., AMF, SMF and UPF.
The gNB has both the NG-U and NG-C interfaces. Both eNB and gNB connect over the XN interface. The interface between gNB and AMF is called N2 interface and the interface between gNB and UPF is called N3 interface, So the control plane is over N2 interface and user plane is over N3 interface.
The eNB is not connected to 5G Core, hence data traffic is split over the XN interface. The gNB is connected to 5G Core with NG-U and NG-C.
In NetSim, the gNB is connected to the UPF via Switch_5 using the 5G_N3 interface and to the AMF via Switch_4 using the 5G_N1_N2 interface, hence, gNB communicates directly with the 5G Core and eNB does not communicate directly with the 5G Core. The gNBs and eNBs are inter-connected using the XN interface via a Layer 2 Switch and the UEs present in the network consists of two interfaces, an LTE interface and a 5G_RAN interface.
Figure-38: NSA deployment- Option 4 networking mode in NetSim
Option-4a
In Option 4a, the eNB is not connected to gNB over XN interface, but it is connected to 5G Core over the NG-U interface.
The gNB has both NG-U and NG-C interfaces. Data traffic is split between 4G and 5G at the 5G Core, specifically the UPF.
In NetSim, the gNB and eNB are connected to the UPF via Switch 5 using the 5G N3 interface and to the AMF via Switch 4 using the 5G N1 N2 interface. The gNBs can be inter-connected using the XN interface and does not have XN interface for eNBs. Hence direct communication between eNB and gNB is not possible. The UEs present in the network consists of two interfaces, an LTE interface and a 5G RAN interface.
Figure-39: NSA deployment- Option 4a networking mode in NetSim
Option 7/7a
The eNB has NG-U and NG-C interfaces to 5G Core and eNB connects with gNB over XN interface. The master node is the LTE cell or eNB and the secondary node is the LTE-NR cell or gNB in these deployment options.
Option-7
In Option 7, the gNB does not communicate to 5G Core. Data traffic flows through eNB communicating to and from the 5G Core. Some part of the data can be transferred through gNB over the XN interface.
In NetSim, the eNBs are connected to the UPF via Switch_5 using the 5G_N3 interface and to the AMF via Switch 4 using the 5G N1-N2 interface. The gNBs and eNBs are inter-connected using the XN interface and hence direct communication between eNB and gNB is possible. The UEs present in the network consists of two interfaces, an LTE interface and a 5G RAN interface. The data is delivered to the UE when it comes to the 5G NR through the LTE-RAN.
Figure-40: NSA deployment- Option 7 networking mode in NetSim
Option-7a
In Option 7a, eNB and gNB are not connected via the XN interface and instead gNB is connected to 5G Core over NG-U. The eNB is connected to 5G Core over NG-C and NG-U. Data traffic is split at the 5GC (UPF).
In NetSim, the gNB and eNB are connected to the UPF via Switch 5 using the 5G N3 interface and to the AMF via Switch 4 using the 5G N1-N2 interface. The gNBs do not have an XN Interface and eNBs are inter-connected using the XN interface and hence direct communication between eNB and gNB is not possible. The UEs present in the network consists of two interfaces, an LTE interface and a 5G RAN interface.
The user data goes directly from the 5G Core to the gNB and then to the UE.
Figure-41: NSA deployment- Option 7a networking mode in NetSim
NSA Packet Flow
Option 4
Consider the following network scenario:
Figure-42: NSA deployment - Option 4 networking mode in NetSim
All the devices have default properties, application start time was set to 1s and scenario is simulated for 10s.
gNB is the Master Node and eNB is the Secondary Node in Options 4 and 4a.
The packet flow in the network takes place as explained below:
The MN, gNB will broadcast the RRC MIB packets to the UE every 80 ms and RRC SIB1 every 160 ms.
After the transmission of the RRC MIB and RRC SIB1 packets, the gNB will send RRC SI packet to the UE.
After reception of RRC SI packet, UE will send RRC Setup Request to the gNB.
On receiving the RRC Setup Request packet, the gNB will acknowledge the request by transmitting RRC Setup packet to the UE.
The UE will send back the RRC Setup Complete packet on the receipt of RRC Setup message.
The gNB will send INITIAL UE MSG AND REGISTRATION REQUEST to the AMF via Core Switch 4 through the N1 N3 interface.
AMF will send a CREATE SESSION REQUEST to SMF through N8 interface.
SMF will send PFCP SESSION REQUEST to UPF through N5 interface.
UPF will send back the response packet to SMF, i.e, PFCP SESSION RESPONSE
SMF will send back the response packet to AMF, i.e., CREATE SESSION RESPONSE
AMF will send the INITIAL CONTEXT SETUP REQUEST to the gNB via Core Switch 4.
On the receipt of Context setup request, gNB will send INITIAL CONTEXT SETUP RESPONSE REGISTRATION COMPLETE packet to the AMF via Core Switch 4 through the N1-N3 interface.
This marks the completion of UE registration process.
The UE will now send the UE MEASUREMENT REPORT every 120 ms to the MN which contains the SNR information. The time interval at which the measurement report is to be transmitted can be set by the user in the eNB/ gNB properties-> Interface LTE/ 5G RAN -> Data Link Layer.
After the UE registration, the MN node will send DC SEC CELL ADDITION REQUEST to the SN via the Core Switch 6.
On the receipt of this secondary cell addition request, the SN sends back the response packet, i.e. DC SEC CELL ADDITION RESPONSE.
After the UE attachment procedure, the data packets will be transmitted from the server to the UE based on the splitting algorithm.
As per the current splitting algorithm in NetSim, when application QoS is set to BE, RTPS, ERTPS, or NRTPS, the data packet will be transmitted to the UPF through the N6 interface. From the UPF, it goes to the gNB (MN) via Core Switch 5 through the N2 interface, and from the gNB, it will be transmitted to the UE through the RAN interface.
When the application QoS is set to UGS, the data packet will flow from the UPF to the gNB via Core Switch 5. From the gNB, the packet gets transmitted to the eNB via Core Switch 6 through the XN interface, and then to the UE.
Packet flow can be analyzed using the Packet Trace log file as shown below:
Figure-43: Packet flow can be analyzed using the Packet Trace
Option 4a
Consider the following network scenario:
Figure-44: NSA deployment - Option 4a networking mode in NetSim
All the devices have the default properties, application start time was set to 1s and scenario is simulated for 10s.
The packet flow in the network takes place as explained below:
The MN, gNB will broadcast the RRC MIB packets to the UE every 80 ms and RRC SIB1 every 160 ms.
After the transmission of the RRC MIB and RRC SIB1 packets, the gNB will send RRC SI packet to the UE.
After reception of RRC SI packet, UE will send RRC Setup Request to the gNB.
On receiving the RRC Setup Request packet, the gNB will acknowledge the request by transmitting RRC Setup packet to the UE.
The UE will send back the RRC Setup Complete packet on the receipt of RRC Setup message.
The gNB will send INITIAL UE MSG AND REGISTRATION REQUEST to the AMF via Core Switch 4 through the N1 N3 interface.
AMF will send CREATE SESSION REQUEST to SMF through N8 interface.
SMF will send PFCP SESSION REQUEST to UPF through N5 interface.
UPF will send back the response packet to SMF, i.e, PFCP SESSION RESPONSE
SMF will send back the response packet to AMF, i.e., CREATE SESSION RESPONSE
AMF will send the INITIAL CONTEXT SETUP REQUEST to the gNB via Core Switch 4.
On the receipt of Context setup request, gNB will send INITIAL CONTEXT SETUP RESPONSE REGISTRATION COMPLETE packet to the AMF via Core Switch 4 through the N1-N3 interface.
This marks the completion of UE registration process.
The UE will now send the UE MEASUREMENT REPORT every 120 ms to the MN which contains the SNR information. The time interval at which the measurement report is to be transmitted can be set by the user in the eNB/ gNB properties-> Interface LTE/ 5G RAN -> Data Link Layer.
After the UE registration, the MN node will send DC SEC CELL ADDITION REQUEST to the SN via the Core Switch 6.
On the receipt of this secondary cell addition request, the SN sends back the response packet, i.e. DC SEC CELL ADDITION RESPONSE.
After the UE attachment procedure, the data packets will be transmitted from the server to the UE based on the splitting algorithm.
As per the current splitting algorithm in NetSim, the first data packet will be transmitted to the UPF through the N6 interface and from the UPF it goes to the MN, gNB via Core Switch 5 through the N2 interface, and from the gNB it will be transmitted to the UE through the RAN interface.
The second data packet will flow from UPF to the gNB via Core Switch 5 and from the gNB, the packet gets transmitted to the eNB via Core Switch 6 through the XN interface and then to the UE.
Similarly, the third packet will flow through the MN, fourth through the SN and so on.
Packet flow can be analyzed using the Packet Trace log file as shown below:
Figure-45: Packet flow can be analyzed using the Packet Trace
Option 7
Consider the following network scenario:
Figure-46: NSA deployment - Option 7 networking mode in NetSim
All the devices have the default properties, application start time was set to 1s and scenario is simulated for 10s.
eNB is the MN and gNB is the SN in deployment options 7, 7a.
The packet flow in the network takes place as explained below:
The MN, eNB will broadcast the RRC MIB packets to the UE every 40 ms and RRC SIB1 every 80 ms.
After the transmission of the RRC MIB and RRC SIB1 packets, the eNB will send RRC SI packet to the UE.
After reception of RRC SI packet, UE will send RRC Setup Request to the eNB.
On receiving the RRC Setup Request packet, the eNB will acknowledge the request by transmitting RRC Setup packet to the UE.
The UE will send back the RRC Setup Complete packet on the receipt of RRC Setup message.
The eNB will send INITIAL UE message AND REGISTRATION REQUEST to the AMF via Core Switch 4 through the N1-N3 interface.
AMF will send CREATE SESSION REQUEST to SMF through N8 interface.
SMF will send PFCP SESSION REQUEST to UPF through N5 interface.
UPF will send back the response packet to SMF, i.e, PFCP SESSION RESPONSE
SMF will send back the response packet to AMF, i.e., CREATE SESSION RESPONSE.
AMF will send the INITIAL CONTEXT SETUP REQUEST to the eNB via Core Switch 4.
On the receipt of Context setup request, eNB will send INITIAL CONTEXT SETUP RESPONSE REGISTRATION COMPLETE packet to the AMF via Core Switch 4 through the N1-N3 interface.
This marks the completion of UE registration process.
The UE will now send the UE MEASUREMENT REPORT every 120 ms to the MN which contains the SNR information. The time interval at which the measurement report is to be transmitted can be set by the user in the eNB/ gNB properties-> Interface LTE/ 5G RAN -> Data Link Layer.
After the UE registration, the MN node will send DC SEC CELL ADDITION REQUEST to the SN via the Core Switch 6.
On the receipt of this secondary cell addition request, the SN sends back the response packet, i.e., DC SEC CELL ADDITION RESPONSE.
After the UE attachment procedure, the data packets will be transmitted from the server to the UE based on the splitting algorithm.
As per the current splitting algorithm in NetSim, when application QoS is set to BE, RTPS, ERTPS, or NRTPS, the data packet will flow from UPF to the eNB via Core Switch 5 and then from eNB to the gNB via Core Switch 6 through XN interface and then to the UE.
When the application QoS is set to UGS, the data packet will be transmitted to the UPF through the N6 interface and from the UPF it goes to the MN, eNB via Core Switch 5 through the N2 interface, and from the eNB it will be transmitted to the UE through the LTE interface.
Packet flow can be analyzed using the Packet Trace log file as shown below:
Figure-47: Packet flow can be analyzed using the Packet Trace
Option 7a
Consider the following network scenario:
Figure-48: NSA deployment - Option 7a networking mode in NetSim
All the devices have the default properties, application start time was set to 1s and scenario is simulated for 10s.
The packet flow in the network takes place as explained below:
The MN, eNB will broadcast the RRC MIB packets to the UE every 40 ms and RRC SIB1 every 80 ms.
After the transmission of the RRC MIB and RRC SIB1 packets, the eNB will send RRC SI packet to the UE.
After reception of RRC SI packet, UE will send RRC Setup Request to the eNB.
On receiving the RRC Setup Request packet, the eNB will acknowledge the request by transmitting RRC Setup packet to the UE.
The UE will send back the RRC Setup Complete packet on the receipt of RRC Setup message.
The eNB will send INITIAL UE MSG AND REGISTRATION REQUEST to the AMF via Core Switch 4 through the N1-N3 interface.
AMF will send CREATE SESSION REQUEST to SMF through N8 interface.
SMF will send PFCP SESSION REQUEST to UPF through N5 interface.
UPF will send back the response packet to SMF, i.e, PFCP SESSION RESPONSE
SMF will send back the response packet to AMF, i.e., CREATE SESSION RESPONSE.
AMF will send the INITIAL CONTEXT SETUP REQUEST to the eNB via Core Switch 4.
On the receipt of Context setup request, eNB will send INITIAL CONTEXT SETUP RESPONSE REGISTRATION COMPLETE packet to the AMF via Core Switch 4 through the N1 N3 interface.
This marks the completion of UE registration process.
The UE will now send the UE MEASUREMENT REPORT every 120 ms to the MN which contains the SNR information. The time interval at which the measurement report is to be transmitted can be set by the user in the eNB/ gNB properties-> Interface LTE/ 5G RAN -> Data Link Layer.
DC SEC CELL ADDITION REQUEST to the SN via the Core Switch 5.
On the receipt of this secondary cell addition request, the SN sends back the response packet, i.e. DC SEC CELL ADDITION RESPONSE.
After the UE attachment procedure, the data packets will be transmitted from the server to the UE based on the splitting algorithm.
As per the current splitting algorithm in NetSim, the first data packet will be transmitted to the UPF through the N6 interface and from the UPF it goes to the MN, eNB via Core Switch 5 through the N2 interface, and from the eNB it will be transmitted to the UE through the LTE interface.
The second data packet will flow from UPF to the gNB via Core Switch 5 and then from gNB to the UE.
Similarly, the third packet will flow through the MN, fourth through the SN and so on.
Packet flow can be analyzed using the Packet Trace log file as shown below:
Figure-49: Packet flow can be analyzed using the Packet Trace
Handover
Use of SNR instead of RSRP
NetSim is a packet-level simulator for simulating the performance of end-to-end applications over various packet transport technologies. NetSim can scale to simulating networks with 100s of UEs, gNBs, routers, switches, etc. In order to achieve a scalable simulation that can execute in reasonable time on desktop-level computers, many details of the physical layer techniques have been abstracted.
In keeping with the above, in NetSim’s 5G model, there are no pilots/reference/synchronization signals. The channel matrix H is assumed to be known perfectly and instantaneously at the transmitter and receiver, respectively. The only difference between the SSB and PDSCH is the beamforming gain calculations. The hand-over decision is based on the SSB-SNR measured at UE from the serving-gNB and the target-gNB. Since the noise power would typically be the same for the s-gNB and t-gNB signals, in effect the handover is based on received signal level on the SSB.
Handover algorithm
The handover logic of NetSim 5G library is based on the Strongest Adjacent Cell Handover Algorithm (Ref: Handover within 3GPP LTE: Design Principles and Performance. Konstantinos Dimou. Ericsson Research). The algorithm enables each UE to connect to that gNB which provides the highest SNR. Therefore, a handover occurs the moment a better gNB - adjacent cell has offset stronger RSRP (measured as SNR in NetSim) - is detected. If there is more than one gNB with offset higher signal strength, then the gNB with the highest signal strength becomes the target gNB. If carrier aggregation and MIMO is enabled then the SNR is averaged over all carriers and over all layers.
This algorithm is similar to 38.331, 5.5.4.4 Event A3 wherein Neighbor cell’s RSRP becomes Offset better than serving cell’s RSRP. Note that in NetSim report-type is periodical and not eventTrigerred since NetSim is a discrete event simulator and not a continuous time simulator. Therefore, the signal strength comparisons between source-gNB and all other gNBs is done every time a UE Measurement report is received at the source gNB. Note that:
The signal strength compared is the average of all layers across all carriers.
NetSim assumes that admission control during handover is always successful. Hence there are no handover failures on this count.
Ping pong handovers
The above algorithm is susceptible to ping-pong handovers; continuous handovers between the serving and adjacent cells on account of changes in SNR due mobility and shadow-fading. At one instant the adjacent cell's SNR could be higher and the very next it could be the original serving cell's RSRP, and so on. To solve this problem the algorithm uses:
Hysteresis (Hand-over-margin, HOM) which adds a SNR threshold (Adjacent cell SNR – Serving cell SNR > Hand-over-margin or hysteresis), and
Time-to-trigger (TTT) or hysteresis which adds a time threshold.
This HOM is part of NetSim implementation while TTT can be implemented as a custom project in NetSim.
Users may also be interested in measuring Ping pong handovers. For this, users should log the gNB to which the UE is attached. Users can then simulate scenarios where UE would attach to gNB1 then to gNB2, back to gNB1, again to gNB2 ... and so on, within a short time frame. Ping pong handovers can then be calculated per some (user-defined) criteria. Such scenarios can be simulated by enabling shadow-fading and fading-and-beamforming (fast fading). These phenomena would cause SINR to fluctuate over short distances and even over time at the same location.
Custom coding is required to log the "attached gNB" for each UE. NetSim radio measurements workspace (available in file-exchange/ GitHub) can serve as the base for this development effort.
Packet flow during handover
NetSim implements those aspects of the 5G handover procedure that directly affects network performance. Other aspects of the handover, for example security, are either not implemented or abstracted since they do not affect network performance. Handovers can occur in RRC CONNECTED (during active Tx or Rx) or in RRC IDLE states (no Tx or Rx).
Figure-50: Control packet flow in the 5G handover process
The packet flow (which can be observed from the packet trace) is as follows:
Once the UE connection and association procedures are completed, the UE sends a UE MEASUREMENT REPORT every UE Measurement Report Interval to the connected gNB. UE Measurement Report Interval is by default set as 5 ms in NetSim and is a user configurable parameter.
At some time, neighbor cell RSRP (measured as SNR in NetSim) becomes offset higher than serving cell RSRP.
Immediately after receiving the next UE MEASUREMENT REPORT, source gNB (also sometimes called serving gNB) sends a HANDOVER REQUEST to the target (neighbor) gNB. This packet is sent through the Xn interface via a 5G-Core Switch. All the links in the 5G Core are by default 10 Gbps.
The Target gNB sends back HANDOVER REQUEST ACK to serving gNB, again via the Xn interface. If the HANDOVER REQUEST or the HANDOVER REQUEST ACK are errored then if the target gNB signal strength continues to be offset higher than source gNB signal strength, step 1 is repeated at the next UE MEASUREMENT REPORT.
After receiving HANDOVER REQUEST ACK the serving gNB sends the HANDOVER COMMAND to UE.
Then the HANDOVER COMMAND packet is sent by source gNB to the UE.
The target gNB then sends RRC Reconfiguration message to UE. If UE is in RRC Connected mode than the target gNB is assigned as new source gNB for the UE.
The target gNB will send the PATH SWITCH packet to the AMF through the N1-N2 interface (via a core switch).
When the AMF receives the PATH SWITCH packet, it sends MODIFY BEARER REQUEST to the SMF. This is over the N11 interface.
The SMF on receiving the MODIFY BEARER REQUEST sends back the MODIFY BEARER RESPONSE to the AMF.
On receiving the MODIFY BEARER RESPONSE from the SMF, AMF acknowledges the Path switch request sent by the target gNB by sending the PATH SWITCH ACK packet back to the target gNB. This is over the N1-N2 interface, via a 5GC switch.
The target gNB then sends a UE CONTEXT RELEASE to source gNB, and the source gNB sends back UE CONTEXT RELEASE ACK to target gNB. The context release request and ack packets are sent between the source and target gNB via the Xn interface.
Then RRC Reconfiguration takes place between target gNB and UE.
UE starts sending the UE MEASUREMENT REPORT to the new source gNB
Figure-51: Screenshot of NetSim packet trace file showing the control packets involved in handover. Some columns have been hidden before the last column.
Handover Interruption Time
During this period the UE can neither transmit or receive user data. Handover Interruption time can be configured in the Data Link layer properties of the gNB as shown below
Figure-52: Screenshot showing handover interruption time in gNB properties
The value can range from 0.0 to 500.0 milliseconds. The handover process in NetSim is based on event A3 i.e., the target signal strength is offset (3 dB) higher than the source signal strength. Handover interruption time (HIT) is added at the time of handover command is delivered to the UE. During this time there is no data plane traffic flow to the UE from the source/target. The time at which the path switch is sent from the target cell to the AMF will get delayed by the Handover interruption time. This can be observed in the packet trace log file.
Time-to-Trigger
Cellular networks can suffer from Ping-pong (or rapid) handovers. In such handovers one successful handover is followed by a handover back to the original cell within short rapid handover time, \(T_{RH},\) e.g., within 3 seconds. Both handovers could potentially have been saved. Equivalently, if a successful handover is followed by another successful handover to a third cell within \(T_{RH}\), one could a single handover directly to this third cell would have served the purpose.
In the current version of NetSim, A3 based handover event is triggered the instant received SNR (on the downlink in the SSB) from target gNB, \({SNR}_{UE(SSB)}^{t - gNB}\)is offset, \(\Delta\), higher than received signal strength (on the downlink in the SSB) from serving gNB \({SNR}_{UE(SSB)}^{s - gNB}.\) This offset, \(\Delta,\) is also known as the Hand Over Margin (HOM). Thus, A3 event is triggered when, in dB scale,
where \(t\) is a discrete time instant.
Given the way NetSim measures power, \(SNR\) is used to account for differences in the bandwidth between serving and target gNBs. If their bandwidths are equal, then, in dB scale
In NetSim, SSB power between all UE-gNB pairs are computed.
when a measurement report is sent, which is every measurement interval \(T_{MI}\ \)(default 5 ms), and
at every mobility event i.e., whenever a UE moves. Recall here that in NetSim mobility is discretised over instants of time and movement is not continuous over time i.e., a UE moves to \(\left( x_{1},\ y_{1} \right)\) at time \(t_{1},\) remains at \((x_{1},\ y_{1})\) till just before time \(t_{2},\ \)and then instantly moves to \((x_{2},\ y_{2})\) at \(t_{2}.\)
Hence, the A3 trigger occurs at the instant power levels at t-gNB and s-gNB satisfies (1). This could occur at a measurement report event or at a mobility event.
By definition of time to trigger, \(T_{TTT}\), a handover event should only be triggered if (1) holds true for a duration equal to \(T_{TTT}\) .
Since NetSim is a discrete event simulator its internal virtual clock progresses (virtual) time at events. Therefore, NetSim cannot check for (1) continuously over time. The test of whether (1) would continue to hold true can only be carried out at subsequent measurement report events and mobility events.
TTT condition will be successfully met only if powers from t-gNB and s-gNB meet condition (1) at all mobility and measurement events within the TTT period. If condition (1) fails to hold at any event during TTT, then TTT condition will have failed. The A3 trigger will be removed.
NetSim does not (recursively) average, or filter, \({SNR}_{UE(SSB)}^{t - gNB}\), or \({SNR}_{UE(SSB)}^{s - gNB}\) within the \(T_{TTT}\) window and (1) is evaluated on instantaneous powers at all events.
NetSim Time-to-trigger variable
is global scope; it remains the constant across the network, and
can be set by the user in the range [0 ms, 5120 ms] as defined in the standards.
Algorithm
When A3 condition is met AddTrigger event is added
Check (1) at all measurement report events and mobility events.
If at any event (1) doesn’t hold remove the AddTrigger event
Else, if (1) holds at all events within the TTT, initiate H/O trigger upon expiry of TTT interval.
Figure-53: We see the SNR variation with time measured by UE from gNB1 (black) and gNB2 (blue). Time to trigger starts the instant SNRUEgNB2 − SNRUEgNB1 > Δ. Once this condition holds for a duration equal to time-to-trigger, handover is initiated. Users can also configure a handover interruption time during which the UE is not connected to either gNB. Post this, the UE gets associated with gNB2.
Assumptions and limitations
Time to trigger (\(T_{TTT}\)) will be implemented for 5G Standalone (SA) mode. NetSim assumes non failure of:
Measurement reports
Handover messages
Handovers are always successful. There are no handover failures on account of admission control at t-gNB.
In NetSim, UEs can be handed over to gNBs of different frequencies as long as (1) is met. There is no difference in handover functionality when the t-gNB and s-gNb operate in (i) the same frequency (say s-gNb and t-gNB in C-band) and (ii) different frequencies (say s-gNB in C-band and t-gNB in mmWave).
Time-to-trigger implementation is based on Rel 15. Enhancements added in Rel 16 namely (i) Dual active protocol stack (DAPS) and (ii) Conditional handovers, are not yet supported in NetSim.
Algorithm for implementation in NetSim
Each gNB maintains a matrix named as the Conditional HO TTT Matrix
The rows are the associated UEs, and the columns are all other gNBs in the scenario
Whenever a \(UE_{i}\) associates with a gNB
Initialize all the matrix entries for all \(j\ \)(i.e., for all gNBs) for the given row \(i\) as follows
\(T_{trigger}^{j}\)to -1 for all \(j\ \) // #define TTT_not_set = -1
Whenever a measurement report from an associated \(UE_{i}\) is received
If the condition (\({SNR}_{UE(SSB)}^{gNB} - \ {SNR}_{UE(SSB)}^{s - gNB} > \Delta)\ \)is met
If matrix entry \(T_{trigger}^{j}\ \)is currently -1, then // \(i\) is fixed
Update the matrix entry, \(T_{trigger}^{j} = T_{current}\), where \(T_{current}\) is current simulation time
Else (matrix entry is not -1)
If \(T_{current} - T_{trigger}^{j} \geq TTT\)
Initiate handover procedure
Else
If the matrix entry, \(T_{trigger}^{j}\)is not -1
Set it equal to -1
Whenever a \(UE_{i}\) disassociates with a gNB, delete the row \(i\)
Configuring Time-to-Trigger
The desired TTT value in milliseconds can be configured in the Data Link layer properties of the gNB as shown below.
Figure-54: Time-to-Trigger configuration in gNB/eNB Data Link layer properties
This value is common for all gNBs in a network i.e., TTT parameters are global in scope. Setting TTT to 0 is equivalent to disabling Time-to-Trigger.
Enabling the LTENR Handover Log
The LTENR Handover log can be enabled by clicking on configure reports in top ribbon > Plots > Select LTENR Handover log under Network Logs as shown below.
Figure-55: Enabling the LTENR Handover log
Upon running simulations with this log enabled, a LTENR Handover Log.csv file is written and can be accessed from the results dashboard as shown below:
Figure-56: Accessing Handover log from NetSim results dashboard.
The log file consists of timestamps in Milliseconds, associated UE name, the serving cell name, target cell name, serving SSB SNR, Target SSB SNR and the Remarks.
Entries are written to the file when a handover condition is met. For example, when running the 5G-Handover scenario with the Time-To-Trigger (TTT) set to 2560 milliseconds (or 2.56 seconds) and mobility configured such that the User Equipment (UE) moves toward the target gNB and then returns to the serving gNB, handovers typically occur in a ping-pong manner. The following entries are logged in the Handover log:
Figure-57: TTT log showing entries with handover conditions met at different time intervals.
From the log file we can see that initially the UE is associated with gNB7. Around 18.5 seconds, the handover is initiated when \({SNR}_{UE(SSB)}^{gNB} - \ {SNR}_{UE(SSB)}^{s - gNB} > \Delta\ (3\ dB)\).
Since UE 9 is configured with mobility, it moves back to gNB 7 from gNB 8
Again, at 43.8 seconds, the handover condition is met when the SNR from gNB 7 is greater than from gNB 8 as UE 9 moves towards gNB 7.
Similarly, you can observe that the handover conditions are met again at 51 and 57 seconds.
Buffer transfer and timers
During handover buffer is transferred from s-gNB to t-gNB, and active timers such as t-poll retransmit are stopped in the s-gNB.
Network Slicing
NetSim supports network slicing in 5G from v14.1 onwards.
RAN slicing
RAN slicing in 5G involves dividing the Radio Access Network into multiple virtual slices, each tailored to serve specific service requirements. The RAN slicing implementation in NetSim is explained below:
Scope:
Network slicing in NetSim focuses solely on RAN slicing and does not cover Core and Transport slicing.
Identification:
Each network slice is identified by a single Network Slice Selection Assistance Information (S-NSSAI) or a Slice ID, consisting of a Slice Service Type (SST) and a Slice Differentiator (SD).
Slice Type and Differentiator:
The Slice Type (SST) signifies the expected behaviour of the network slice in terms of features and services.
The Slice Differentiator (SD) distinguishes multiple instances of the same slice type.
Resource Sharing Options:
Two resource sharing options are defined (a) Static slicing (or hard slicing) and (b) Dynamic slicing (or soft slicing).
Static Slicing:
Supported Slice Types: eMBB, URLLC, MIoT, V2x.
Resource Allocation: Slices are allocated a fixed percentage of resources.
Dynamic Slicing:
Supported Slice Type: eMBB.
Proprietary algorithm: Uses PFS (Proportional Fair Scheduling) with Rate Guarantee employing stochastic online learning. The dynamic slicing algorithm is derived from Non-linear Optimization Theory.
Slice Configuration
Network Slicing can be configured in the gNB RAN interface, Datalink layer properties. Depending on the Scheduling Type selection the available Resource Allocation Techniques to choose from will vary.
Figure-58: gNB RAN Interface Datalink Layer properties with slice configuration options.
The following table contains a list of scheduling types supported in the gNBs and the corresponding resource allocation techniques that can be selected.
Scheduling Type |
Network Slicing – Resource Allocation Technique |
|---|---|
Round Robin |
Static |
Max Throughput |
Static |
Proportional Fair |
Static |
PFS with rate guarantee |
Dynamic |
Table-36: Resource Allocation Techniques based on the Scheduling type selection.
Network Slicing can be configured in NetSim using the Slice Configurator GUI or via a CSV input file. When the configuration is done via the GUI, a CSV file will be automatically generated. Network Slicing is global to all the gNBs in a 5G network and hence if enabled and configured in a gNB, will be applicable to all the gNBs.
Slice Configurator GUI
The slice configurator allows users to select the Number of slices initially, and based on the Resource Sharing Technique selected, the slice table gets populated automatically, where users can configure the properties and map UE’s to different slices.
Figure-59: Static Network Slicing Configurator GUI.
Static Slice Configurator:
Slice ID 0 is the default slice with Slice Type BE.
For all rows, the parameters, Slice ID and Slice Differentiator are non-editable.
Slice Type can be modified and set to one of the following values:
BE
eMBB
URLLC
MIoT
V2X
The resource allocation column should be configured such that the sum of resource allocation percentage is exactly equal to 100.
Figure-60: Dynamic Network Slicing Configurator GUI.
Dynamic Slice Configurator:
Slice ID 0 is the default slice with Slice Type BE. All the other slices are eMBB.
For all rows, the parameters, Slice ID and Slice Differentiator are non-editable.
Min and Max percentage of resource share can be specified individually for DL and UL in Mbps, for each slice.
Slice - UE Mapping:
Mapped UE column accepts UE IDs as input which can be.
Comma separated (“,”)
Range: specified by starting ID and ending ID separated by “-“. For e.g.: 10-20 includes all UE’s starting from ID 10 to 20.
This column can also be left blank without any UE assigned.
Network Slicing CSV input file:
Based on the configuration done in the slicing configurator GUI, a networkslicing.csv file is automatically generated as shown below:
Figure-61: Left: Network Slicing CSV log showing the Static slice configuration. Right: Network Slicing CSV log showing the Dynamic slice configuration.
The UE to Slice ID mapping is written individually for each UE in the CSV file which is read and used for simulations.
Recording slice-based resource allocation
The LTENR Resource Allocation log can be enabled by clicking on configure reports in top ribbon > Plots > Select LTENR Resource Allocation log as shown below. Refer to section 3.22 for further information.
Figure-62: Enabling LTENR Resource Allocation log.
When network slicing is enabled, the log will include additional columns such as the Slice ID, Slice Type and Slice Differentiator.
Figure-63: LTE NR Radio Resource Allocation log with entries associated with Network Slicing
This log can be used to identify the resource allocation on a per slice basis based on the network configuration. Based on the resource allocation percentage of a slice, a fraction of PRB’s will be available to be allocated to the UE’s belonging to that slice. The PRB’s allocated to the UE’s can be found in the Allocated PRB’s column.
Consider the following network with 1 gNB and 2 UE’s downloading data from a server.
Figure-64: 5G network configuration with a gNB and 2 UE’s performing download from a server
Network Slicing is enabled and configured such that UE 10 gets 55% of the resources and UE 11 gets 45% of the resources as shown below:
Figure-65: Slice Configurator showing BE and eMBB slices configured with 45% and 55% of resources.
For example, in the Pivot table (Custom) sheet, by adding Slice Type to Rows and Allocated PRBs to Values, and setting the Allocated PRB’s property to show value as % of grand total, we can obtain the percentage of resources allocated on a per slice type basis as shown below:
Figure-66: Pivot table showing the percentage of resources allocated to each Slice Type
The pivot table shows the resource allocation to slice types as per the configuration done in the slice configurator.
Plotting Slicing parameters
NetSim allows users to generate time series plots for EWMA MAC throughput and the Dynamic slicing Index Bias parameters. These plots can be enabled prior to running the simulation.
Figure-67: Enabling Index Bias and EWMA MAC throughput plots
After the Simulation the plots can be accessed from the results dashboard under the plots section.
Figure-68: Accessing Index Bias and EWMA MAC throughput plots from results dashboard
Figure-69: EWMA MAC Throughput vs Time
Figure-70: Index Bias vs Time
Detailed information about Network Slicing is provided in the link below https://support.tetcos.com/en/support/solutions/articles/14000159642-network-slicing-in-5g
Limitations
Core slicing and transport slicing are not supported.
A slice will cover the “entire” network i.e., it will apply to all gNBs. This is known as horizontal slicing. “Vertical slicing” by which only a certain subset of gNBs (also called area) implement network slicing is not supported.
Assumptions in the working of 5G Core
Any UE can connect to any slice. No frequency restriction.
Currently, there is no RAN-core signaling; hence NSSF, PCF functions are not part of the 5G core.
Single SMF, AMF and UPF. Multiple SMFs and UPFs will be made available when implementing core slicing.
NetSim’s focus is network performance; hence NSI, NSMF, NSSMF, CSMF are abstracted.
NetSim assumes that the control packet flow between the UE, AMF and NSSF for slice selection is instantaneous and successful.
All traffic from the UE uses the same slice type.
Users must take care to map the UE to the right slice type. For example: if a voice application is set at some UE, then that UE must be mapped to a URLCC slice.
Slicing is supported only in 5G SA mode.
LTENR Results, Packet Trace and Plots
Parameter |
Description |
|---|---|
AppID |
Application ID |
QFI |
QOS Flow ID |
SDAP Entity |
SDAP Entity |
SrcID |
Source ID |
DestID |
Destination ID |
SrcIP:Port |
Tuple of Source IP and Port Number |
DestIP:Port |
Tuple of Source IP and Port Number |
Packet Tx |
Total packets transmitted for a QFI |
Packet Rx |
Total packets received for a QFI |
Delay |
Average delay of all received packets within an average window |
PER (Packet Error Rate) |
Packet Error Rate Plot |
PDB (Packet Delay Budget) |
Packet Delay Budget Plot |
Table-37: LTENR results Packet trace parameter descriptions
LTE NR Log
The LTE NR packet trace file has in its last column the field LTENR PACKET INFO. This field has information relating to PDCP header and RLC header. The packet trace file can be opened from results dashboard.
Figure-71: LTE NR Packet Trace. Depending on Excel settings in some cases the entire header may not be displayed. Users can do Ctrl + A (Select All) -> Right Click -> Format Cells -> Alignment -> Wrap Text to view the complete header.
PDCP and RLC Headers logged in Packet Trace
The PDCP and RLC header fields are logged in the LTENR PACKET INFO field of NetSim’s packet trace.
The PDCP header fields are:
D/C field termed as dCBit in NetSim. This is 0 for control PDU and 1 for Data PDU
SN field is termed SN in NetSim. This provides the sequence number of the PDCP PDU
The RLC header fields are:
Header Type: If the packet is TMD, UMD or AMD PDU
Segment Information (SI) field: The meaning of each possible SI field value is defined in the table below Table-38.
Value |
Description |
|---|---|
SI=ALL |
Data field contains all bytes of RLC SDU |
SI=FIRST |
Data field contains first segment of an RLC SDU |
SI=LAST |
Data field contains last segment of an RLC SDU |
SI=MIDDLE |
Data field contains neither the first nor the last segment of RLC SDU |
Table-38: RLC header fields
SN: The SN field indicates the sequence number of the corresponding RLC SDU. For RLC AM, the sequence number is incremented by one for every RLC SDU. For RLC UM, the sequence number is incremented by one for every segmented RLC SDU. RLC service data units (SDUs) coming from the upper layer are segmented or concatenated to RLC protocol data units (PDUs) which have predefined size. Each PDU is assigned its own sequence number (SN). RLC AM on receiver side will reassemble these PDUs into SDUs using the sequence number.
SO: The SO field indicates the position of the RLC SDU segment in bytes within the original RLC SDU. Specifically, the SO field indicates the position within the original RLC SDU to which the first byte of the RLC SDU segment in the Data field corresponds.
Pollbit: The P field indicates whether or not the transmitting side of an AM RLC entity requests a STATUS report from its peer AM RLC entity. 0 indicates that the Status report is not requested, while 1 indicates that the Status report is requested.
LTENR Event Trace
Sub event types
LTENR StartFrame
Downlink and uplink transmissions are organized into frames.
There is one set of frames in the uplink and one set of frames in the downlink on a carrier.
This event is triggered when a frame is formed.
As frame length is 10 ms, the event gets triggered every 10ms.
(LTENR->LTENR Phy.c-> LTENR addStartFrameEvent() )
LTENR Start Subframe
Each frame consists of 10 subframes.
Event gets triggered every 1 ms
(LTENR->LTENR Phy.c-> LTENR addStartSubFrameEvent ())
LTENR StartSlot
Sub frames are divided into slots.
Slot size depends on Numerology (µ)
Event gets triggered every \(\frac{1}{2^{\mu}}\) ms
(LTENR->LTENR Phy.c-> LTENR addStartSlotEvent ())
LTENR Generate RRC MIB
The timer event triggered every 80ms to generate and broadcast MIB packets from gNBs to all UEs.
(LTE-NR->LTENR GNBRRC.c->fn_NetSim_LTENR_GNBRRC_GenerateMIB())
LTENR Generate RRC SIB1
The timer event triggered every 160 ms to generate and broadcast SIB1 packets from gNB to all UEs.
(LTE-NR-> LTENR GNBRRC.c-> fn_NetSim_LTENR_GNBRRC_GenerateSIB1())
LTENR Generate RRC SI
Timer event triggered when the selected gNB broadcasts RRC SI packets to all the UEs.
This event is triggered only once, at 160.9ms, during the initial attachment process.
(LTE-NR->LTENR GNBRRC.c->fn_NETSIM_LTENR_SUBEVENT_GENERATE_SI())
LTENR Generate RRC Setup Request
Triggered when RRC setup request gets transmitted by UE to connected gNB
LTENR RRC T300
The timer event triggered when RRC Setup Request is sent by UE to gNB.
The timer T300 stops when the RRC setup message is received by the UE
(LTENR->LTEGNBRRC.c->LTENR RRC START T300() and LTENR_RRC_STOP_T300() (line #1290))
LTENR Generate RRC Setup
Event triggered when RRC Setup message is sent by the selected gNB to the UE.
The RRC Setup message is generated to establish the RRC connection between the UE and the gNB.
(LTENR->LTEGNBRRC.c->fn_NetSIM_LTENR_RRC_GENERATE_RRCSETUP())
LTENR Generate RRC Setup Complete
Timer event triggered during the successful establishment of RRC connection.
LTENR Generate RRC UE Measurement Report Request
Timer event triggered every 120ms, when the gNB sends a measurement report request to UE.
LTENR Generate RRC UE Measurement Report
Timer event triggered when UE sends measurement report to the serving gNB which contains SINR information from all the gNBs.
Triggered at 240 ms after RRC connection establishment and then triggered every 120 ms.
PDCP DiscardTimer
When the discardTimer expires for a PDCP SDU, or the successful delivery of a PDCP SDU is confirmed by PDCP status report, the transmitting PDCP entity shall discard the PDCP SDU along with the corresponding PDCP Data PDU
Discarding a PDCP SDU already associated with a PDCP SN causes a SN gap in the transmitted PDCP Data PDUs, which increases PDCP reordering delay in the receiving PDCP entity.
(LTENR->LTENR PDCP.c-LTENR PDCP START DISCARDTIMER ())
LTENR Generate NAS Handover Request
Timer event triggered when the initial Handover Request is sent by the serving gNB. The handover request is triggered when the SNR from target gNB exceeds the serving gNB by a margin of 3db.
Handover Request Ack
Timer event triggered when the target gNB receives a handover request from the serving gNB and sends back an acknowledgement for the handover request.
Handover Request Command
Triggered when gNB sends Handover Command to UE after receipt of Handover Request Ack
Handover Request Command Handle
Event triggered when UE dissociates from interface of serving gNB and associates with interface of target gNB during a handover.
Functions like FindInterface(), pathswitch() and RRC_Reconfiguration() are called in this function
(LTENR->LTENR NAS.c->fn_NetSim_LTENR_NAS_GENERATE_HANDOVER_COMMAND_HANDLE())
Path Switch
Triggered when the target gNB sends the path switch packet to the EPC in order to transfer the data path from serving gNB to target gNB.
Path Switch Ack
Triggered when EPC sends acknowledgement to the target gNB on the receipt of the path-switch request.
UE Context Release
Event triggered after successful handover procedure.
Triggered when target gNB sends context release packet to the serving gNB
UE Context Release Ack
Triggered when acknowledgement is provided by serving gNB to the target gNB on receipt of context release packet.
Radio measurements log file
NetSim LTENR Radio measurements csv log file records pathloss, shadow fading loss, received power, SNR, Interference Power, SINR, MCS, CQI, and Beamforming gain.
The LTENR Radio Measurements log can be enabled by clicking on configure reports in top ribbon > Plots > Select LTENR Radio Measurements log under Network Logs as shown below.
Figure-72: Enabling LTENR Radio Measurement log.
The LTENR Radio Measurement Log.csv file will contain the following information:
Time in Milliseconds
gNB/eNB Name
UE Name
Distance between the gNB/eNB and the UE in meters
Association Status (True/False)
Carrier ID (CC ID)
Channel Type (PDSCH/PUSCH/SSB)
MIMO Layer ID
Transmitter Power in dBm
LoS State
Total Loss in dB
Pathloss in dB
Shadow Fading Loss in dB
Additional loss dB
Received Power in dBm
SNR in dB
SINR in dB
O2I (Outdoor to indoor) penetration loss in dBm
Interference Power in dBm
Beamforming gain in dB
CQI Index
MCS Index
Figure-73: LTENR Radio Measurement Log file highlighted in the Results window.
Figure-74: LTENR Radio Measurement Log.csv file
Implementation details and Assumptions:
The PDSCH channel corresponds to downlink.
The PUSCH channel corresponds to uplink.
The SSB channel corresponds to the control channel.
Parameters associated with PDSCH and PUSCH channels are logged at every slot only for associated gNB-UE pairs.
Parameters associated with SSB channel are logged once at initialization and further during each mobility event.
Initially only SSB channel entries will be found in the log since gNB-UE association takes time.
The SSB control channel transmission is over a single layer. Analog Beamforming gain is logged for this channel and is used for SSB received power computation.
Interference is not modelled for the SSB channel and hence SINR and Interference Power parameters are not logged.
The SNR computed for SSB channel is used for control decisions such as Association and Handover. It is not used to calculate the MCS/CQI Index which is used to determine PDSCH/PUSCH rate.
Radio resource allocation log file
NetSim 5G Radio Resource Allocation csv log file records information related to physical resource block allocation such as the Total PRBs, Slot Start Time(ms), Slot End, BitsPerPRB, BufferFill, Allocated PRBs, etc.
The LTENR Resource Allocation log can be enabled by clicking on configure reports in top ribbon > Plots> Select LTENR Resource Allocation as shown below.
Figure-75: Enabling LTENR Resource Allocation log.
The LTE Radio Resource Allocation.csv file will contain the following information:
gNB ID
Component Carrier ID
Slot ID
Slot
Total PRBs
Slot Start Time(ms)
Slot End Time(ms)
UE ID
BitsPerPRB
BufferFill(B)
Rank
Allocated PRBs
The log file can be accessed from the Simulations Results Window under the log file drop down in the left pane.
Figure-76: LTENR_Radio Resource Allocation Log file highlighted in the Results window.
Figure-77: LTENR Radio Resource Allocation Log.csv file
Implementation details and assumptions:
In the case of scheduling algorithms such as Max Throughput when all PRB’s are allocated to one UE, the entries for the other UEs for which allocation did not happen is not written to the log file.
Rank is a metric used for resource allocation.
Handover Log file
NetSim Handover Log records the events that occur during a handover. This contains the timestamp, UE ID ,serving cell ID, target cell ID, Serving SSB SNR(dB) , Target SSB SNR(dB) and Remarks (time at which the handover initiation and handover offset was met) - when the TTT parameter is enabled. The log can be used to identify handover attempts and the impact of TTT on handovers.
The LTENR Handover log can be enabled by clicking on configure reports in top ribbon > Plots > Select LTENR Handover log under Network Logs as shown below.
Figure-78: Enabling LTENR Handover Log
The LTE Handover Log.csv file will contain the following information:
Time in microseconds
UE ID
Serving cell
Target cell
Serving SSB SNR (dB)
Target SSB SNR (dB)
Remarks
The log file can be accessed from the Simulations Results Window under the log file drop down in the left pane.
Figure-79: LTENR_Handover_Log.csv file highlighted in the Results window.
Figure-80: LTENR Handover Log.csv file
Code Block Log file
NetSim Code Block Log Records parameters associated with Code Block segmentation such as Process ID, TB size, Modulation, Code Rate, CBS, BLER, CBG ID, etc. along with remarks on events associated with HARQ and PRB allocation. This will be useful to understand BLER model and Code Block segmentation in 5G.
The LTENR Code Block log can be enabled by clicking on configure reports in top ribbon > Plots > Select Code Block log under Network Logs as shown below.
Figure-81: Enabling LTENR Code Block Log
The LTE_CodeBlock_Log.csv file will contain the following information:
Time in milliseconds
gNB/eNB ID
gNB/eNB I/F (Interface)
UE ID
UE I/F (Interface)
Channel Type (PDSCH/PUSCH)
Carrier ID (CC ID)
Frame ID
Subframe ID
Slot ID
Layer ID
Process ID
Remarks
Transport Block Size
Modulation
Code Rate
Code Blocks
SINR
BLER
CBG ID
CB ID
NDI
Transmission Number
Status
The log file can be accessed from the Simulations Results Window under the log file drop down in the left pane.
Figure-82: LTENR_CodeBlock_Log.csv file highlighted in the Results window
Figure-83: LTENR_CodeBlock_Log.csv file
OLLA Log file
NetSim OLLA Log Records Logs parameters associated with Outer Loop Link Adaptation (OLLA) such as CQI with and without OLLA, Phy SINR, SINR Delta, Virtual SINR, etc. along with time stamps, gNB ID, UE ID, etc. This log can be used to understand OLLA mechanisms in 5G.
The LTENR OLLA log can be enabled by clicking on configure reports in top ribbon > Plots > Select OLLA log under Network Logs as shown below.
Figure-84: Enabling LTENR OLLA Log
The LTENR OLLA Log.csv file will contain the following information:
Time in ms
eNB/gNB Name
UE Name
Carrier ID
Layer ID
Frame ID
Sub-Frame ID
Slot ID
Channel
Phy SINR in dB
SINR Delta in dB
Virtual SINR in dB
CQI without OLLA
CQI with OLLA
The log file can be accessed from the Simulations Results Window under the log file drop down in the left pane.
Figure-85: LTENR OLLA Log.csv file highlighted in the Results window.
Figure-86: LTENR OLLA Log.csv file
LTENR PRB Utilization log file
NetSim LTENR PRB Utilization Log records the parameters associated with PRB Utilization, including the proportion of PRBs used out of the total PRBs available, along with timestamps. This log tracks changes in PRB utilization over time, providing data on network load. It can identify patterns such as usage times, congestion or periods of under-utilization, helping to understand PRB allocation mechanisms in 5G.
The LTENR PRB utilization log can be enabled by clicking on configure reports in top ribbon > Plots > Select LTENR PRB Utilization log under Network Logs as shown below.
Figure-87:Enabling LTENR PRB utilization log
The LTENR PRB utilization Log.csv file will contain the following information:
Slot Time(ms)
gNB ID
Slot
CC ID
Slice ID
Total PRBs
Control PRBs
Available PRBs
Total Allocated PRBs
PRB Utilization (%)
EWMA PRB Utilization (%)
The log file can be accessed from the Simulations Results Window under the log file drop down in the left pane.
Figure-88: LTENR PRB Utilization Log.csv file highlighted in the Results window.
Figure-89: LTENR PRB Utilization csv file
Enable detailed logs in 5G NR
A detailed 5G NR log can be enabled by a user, by going to the file LTE NR.h, and then uncommenting the #define LTENR_LOG , #ifdef LTENR_LOG , #define LTENR_LOG_DEV and #endif LTENR_LOG.
Figure-90: Enable LTE NR log file in visual studio
Then rebuild the code and run the simulation.
Figure-91: Rebuild 5G Project
The log file will be available under Log Files menu in the left panel of the Results Window.
Figure-92: Results Window
Among various values noted in the log file is the CQI and MCS information. For example, a user would see in the log file:
CQI Table
15 256QAM 948 7.406300
MCS Table
27 256QAM 8 948.000000 7.406300
The CQI information is according to the 38-214 Table 5.2.2.1-2, 5.2.2.1-3, 5.2.2.1-4. And in the above example:
CQI Index: 15
Modulation: 256QAM
Code Rate x [1024]: 948
Efficiency: 7.406300
The MCS information is according to the 38-214 Table 5.1.3.1-1, 5.1.3.1-2, 5.1.3.1-3. And in the above example:
MCS Index:27
Modulation: 256QAM
Modulation Order: 8
Target code Rate x [1024]: 948.000000
Spectral efficiency: 7.406300