LTE PCIPlanning for Pesky Neighbors
While there are challenges associated with building any new wireless network, constructing the Long Term Evolution (LTE) network comes with a bushel of its own issues. One of these challenges is managing neighbor cells. This is a tough task even for traditional mobile networks, and it becomes even harder as new mobile technologies roll out with 2G and 3G cells already exist. These neighbor cells are firmly in place and not going anywhere. LTE must find a way to deal with the cells, properly, without making the network and/or user suffer.
To help address this, and to stay in line with 3GPP specifications, network operators are turning to Automatic Neighbour Relation (ANR) functionality. ANR relieves the burden of manually managing Neighbor Relations (NR). According to LteWorld, the ANR function lives in the eNB and manages the Neighbour Relation Table (NRT). Within this table are many facets and branches that help deal with these neighbor cells.
The neighbour detection function is responsible for finding new neighbours and adding them to the NRT. The Neighbour Removal Function removes NRs. Both the Neighbour Detection Function and the Neighbour Removal Function are implementation specific.
An existing Neighbour cell Relation (NR) from a source cell to a target cell means that eNB controlling the source cell knows the ECGI/CGI and Physical Cell Identifier (PCI) of the target cell and has an entry in the NRT for the source cell identifying the target cell.
“The ANR function relies on cells broadcasting their identity on global level, E-UTRAN Cell Global Identifier (ECGI) and allows O&M to manage the NRT. O&M can add and delete NRs. It can also change the attributes of the NRT. The O&M system is informed about changes in the NRT.” According to LteWorld, this is accomplished with Intra-LTE/frequency ANR and Inter-RAT/Inter-frequency ANR.
The eNB serving cell with ANR function, instructs each UE to perform measurements on neighbor cells, as a part of the normal call procedure. The eNB may use different policies for instructing the UE to do measurements, and when to report them to the eNB.
When UE discovers new cells’ ECGI, the UE reports that detected ECGI to the serving cell eNB. In addition, the UE reports the tracking area code and all PLMN IDs that have been detected. The eNB adds this neighbour relation to NRT.
The eNB serving cell, along with ANR function can instruct a UE to perform measurements and detect cells on other RATs/frequencies, during connection. Like with Intra-LTE/frequency ANR, the eNB may use different policies for instructing the UE to do measurements, and when to report them to the eNB.
The UE reports the PCI of the detected cells in the target RATs/frequencies. When the eNB receives UE reports containing PCIs of cells, eNB may instruct the UE to read the CGI and the RAC of the detected neighbour cell in case of GERAN detected cells and CGI, LAC and, RAC in case of UTRAN detected cells. For the Interfrequency case, the eNB may instruct the UE to read the ECGI, TAC and all available PLMN ID(s) of the inter-frequency detected cell.
The eNB updates its inter-RAT/inter-frequency Neighbour Relation Table after receiving relevant info from UE. 
When it comes to LTE PCI, adequate planning needs to be done. Harish Vadada lists two main strategy options in his white paper LTE PCI Planning. The first strategy involves grouping neighboring sites into clusters and then assigning those clusters a code group. Each site is assigned a specific code group and each sector a specific color group. The second strategy is random planning, meaning that the PCI plan doesn’t consider PCI grouping and does not follow a specific or tailored reuse pattern. Telecom-cloud recommends the first strategy, in order to avoid non-optimal PCI combinations for adjacent cells.
When planning PCI, Vadada recommends the following tips:
1) The same PCIs should be avoided within the same site and as neighbors
2) PCIs with conflicting k values should be avoided within the same site and as neighbors
3) PCIs with conflicting m0 and m1 values should be avoided within the same site and as neighbors
Reasons for not following these rules strictly:
1) Will not work in an irregular pattern
2) Will cause a lot of limitations on neighbors and neighbor lists would have to be shortened 
 Automatic Neighbour Relation in LTE, LteWorld, http://lteworld.org/blog/automatic-neighbour-relation-lte
 LTE PCI Planning, Harish Vadada, http://www.telecom-cloud.net/wp-content/uploads/2010/09/PCI-Planning-for-LTE.pdf