How to skyrocket the LTE RF access performance

For this post, we will be updating it continuously with different techniques and measure that any RF engineer can apply to improve the LTE RF access performance.

Case 1: RRC access failures due to flow control

Sudden degradation of RRC setup success rate was observed during a key event which directly impacted LTE RF access performance.

The main contributor for this RRC connection setup success rate degradation was a top eNB. And the main cause was RRC.Setup.Fail.Rej.FlowCtrl.

At the time of the degradation, it was noticed a sudden increase in RRC Attempts for the same time period of the degradation.

Debug logs shows that on the same day, on several occasions (including the degradation period), number of simultaneous RRC connection Requests was above 120 which exceeds the eNB processing capabilities.

When there are too many RRC connection requests exceeding CPU processing capability, CPU load would rise

The Average CPU load was above 60 % and maximum load exceeds 85 %. The rise in load results in triggering of Flow control algorithm ,which rejects the RRC connection request.

The long term solution for this case is to distribute traffic with neighboring cells, expanding the hardware or adding new sites in the area. As an optimization measure, increase T302 timer value, this change will cause that when RRC connection request is rejected, RRC request will be retransmitted after the value of this timer. By increasing this timer, the CPU load will decrease due to delay in sending RRC connection requests nevertheless the access delay will increase.

Case 2: Access failures due to IPPATH misconfiguration

During a routine check, RF engineer found that one site was showing a degradation of eRAB access success rate and the increase of access failures due to Transport Network Layer. This failure counters as its name says, it is usually related to issues in the transport / transmission layer. For this case, the first step we should follow is to review the performance on the S1 interface.

During access procedure, the S1 setup occurs during the Initial Context Setup Request initiated by the MME.

As a starting point, we should initiate a S1 Interface trace in the eNodeB. This allows us to collect all the signalling between the eNodeB and the EPC (Evolved Packet Core). This way we can understand the kind of failure impacting the LTE RF access performance due to transport reasons. In this particular case we looked into the S1 Setup. To filter the messages, we need to be sure to review only those related with a service request which is related to the S1 Setup procedure.

Checking multiple messages for the S1 setup, we noticed that some procedures failed to setup the S1. However, most of the procedures were successfully established.

During the S1 setup, the MME messages sent to eNB show the transport layer address (IP) of user plane entity of S-GW and the reason of initial context setup failures as shown in below graph.

In this case, we can see how the S1 setup failed when SGW IP is 10.106.0.165

Comparing this message with messages where S1 setup success, we can see a difference between the SGW IPs.

This information can help us to suspect that the issue is related to the IP configuration from the eNodeB to the SGW endpoints. For this site, the configuration is based on IPPATH. Checking the configuration we noticed that the eNodeB has no IPPATH configured for the IP 10.106.0.165.

Once the eNB received an E-RAB setup attempt with the specific IP of S-GW(10.106.0.165), the eNB sends a failure response to MME because the mentioned IP isn’t configured at the affected eNB.

So the solution for this case was to add the missing IP as shown below:

As soon the configuration is commited to the eNodeB, the LTE RF access performance recovered to the normal values.

LTE RF access performance - TNL improvement