Sector swap identification methods

Sector swap is one of the most common and important errors that may happen during installation/maintenance activities. It can cause performance degradation and a lot of trouble for cellular network engineers.

Bad luck, it is not instantly detected and will silently stay there until suspicion is aroused. It is usually discovered during Drive Test analysis.

But what other options do we have to rule out/prove sector swap?
Here is a list that comes to one’s mind. If you know of other methods, please share in the comment section.

(Note: here we define sector swap as misplaced cells on a certain frequency. When all frequencies/all techs are in a different direction it is simply azimuth deviation)

  1. Suspicious handovers: This is a common and easy way to inspect the issue. Just by checking the handover statistics between two neighbour cells you may reach a conclusion.

  2. Suspicious user density: Based on the buildings density, you expect certain user profile for each sector e.g., your sector 2 is covering a supermarket and your sector 3 is covering open area with few buildings. More users on S3 rather than S2 is a clear sign of abnormality.

  1. Suspicious effect of tilt: It is common that AISG cable_which controls Antenna RET_ be installed only on RRUs of a certain Band. If there is a swap on another RRU, changing tilt for its cells will cause performance change in another cell.

  1. Suspicious behaviour during OPT: We can say it is a generalized mixture of 2 and 3. You realize your actions are showing results on other cells. e.g. you increase the coverage of 1 cell, but you realize user reduction of the other Band in another direction.

  1. Serial Number verification: In case you have HQ photos from tower audit, you may catch the Serial Number of RRUs under each sector and match it with the S/N you get from the OSS.

  1. Alarms that don’t disappear: This is a reflection of mismatch between HW/SW configuration. For example, VSWR alarm is not cleared after team change the cables/RRU because they are working on another sector OR when any physical failure/activity is performed ona sector, the alarm is raised on an irrelevant cell.

Can you think of any other method? Please comment below.

Credits: :point_down:

In my opinion it is an excellent general description of the methods that exist, but I think that of all these methods the first is the most effective of all because it can be completely automated. In this post there is a reference to two excellent articles that describe the implementation of specific algorithms. We have successfully implemented these algorithms (in R) in our network (with statistics from several providers: Ericsson, Huawei and Nokia) and excellent results are obtained.