FR1 I mean, N78 TDD.
Not FR2.
Remember, the higher the number of CSI-RS ports, the sharper the beam becomes, resulting in higher SINR for the user.
So, in general, using the maximum value is preferred, as there are typically no drawbacks to it.
According to the impact on radio network performance, when this parameter is configured as 8PORT, CSI-RS coverage is better and downlink throughput is higher. However, when configured as 16PORT in TDD or 32PORT in FDD, CSI-RS coverage may degrade and downlink throughput can decrease.
In my network, the current configuration is 8PORT. We are running n78 with 70 MHz TDD in NSA mode.
What would be your recommendation in this scenario?
Try configuring 16 or 32 CSI-RS ports on a single cell and compare the KPIs using before/after charts. If you have 5-minute counters enabled, you should already start seeing the impact within a few minutes, so there is no real need to wait 2 hours.
Also, 32 CSI-RS ports can significantly improve MU-MIMO pairing performance. With only 8 CSI-RS ports, the gNodeB may not be able to properly distinguish and pair MU-MIMO users efficiently.
So let us know how the charts look after the change 
One thing to keep in mind: 8 CSI-RS ports consume fewer resource elements (REs) compared to 32 ports. However, this overhead is often compensated by the SINR improvement and better MU-MIMO efficiency.
A possible concern is the increased uplink CSI feedback load with 32 ports, which in some scenarios could create uplink congestion.
Changes have been completed. I will share the observations once the monitoring is done.
Note: if CsirsCellResourceNum is configured as 1_RESOURCE, then FR1MaxCellCsirsPortNum must be set to either 8PORT, 16PORT, or 32PORT.
To modify the FR1 CSI-RS port configuration, CsirsCellResourceNum needs to be changed first.
For testing:
- One sector has been configured with
16PORT - Another sector has been configured with
32PORT
Ok, great.
Remember, this change mainly improves downlink performance since it enhances beamforming capabilities. For uplink, there is no major gain expected from this parameter change.
You applied it on n78 TDD, right?
Yes, we are using n78 TDD with 70 MHz. Do you have any suggestions for improving UL throughput?
Currently, the network-level UL throughput is around 1.9 Mbps, while LTE UL throughput is actually higher than 1.9 Mbps.
Man, that is really low. You either have a very high number of users or too few cells in the network.
The number of users is not high, but we have 79 sites in the network.
For uplink, you can split the traffic between LTE and NR.
So, make NR the primary path and use LTE only when the data cannot be transmitted through NR. This can be controlled using the UlDataSplitThreshold parameter.
Is this parameter for Ericsson or Huawei?
Any vendor has it. That is a UE RRC parameter.
Ok, let me check. If you have the MO, it will help me identify the parameter.
You should check the ENDC configuration and look for the uplink data split threshold parameter there.
First, set the primary path to NR, and then configure the UlDataSplitThreshold to something like 800 bytes or 1600 bytes.
In Nokia, this UlDataSplitThreshold can also work dynamically.
Increasing the number of ports will show noticeable improvements in dense urban and scattered traffic scenarios, especially during rush hours. So, configure it accordingly based on the traffic conditions.
PrimaryPath1 means that uplink data is transmitted mainly over NR.
Only when the uplink buffer data exceeds the UlDataSplitThreshold value will part of the uplink traffic also be transmitted over LTE.
Are these Layer 3 messages?