BaiTip of the Day - December 15th, 2016 - Physical Cell Identifiers (PCI)

When each Baicells eNodeB first connects to the Cloud EPC, it is assigned a PCI number (between 0 - 503). In some cases, I have seen this number was the same on several eNodeBs on the same tower. Operators have the ability to change these PCI numbers and SHOULD do so. You may want to come up with a plan for these numbers for your deployments, especially as they grow. Larger operators should do some reading on PCI Planning.

Remember, the PCI numbers assigned to your eNodeBs should be between 0 and 503. No two eNodeBs in close proximity to another should have the same PCI number. Please check your current deployments and make the appropriate changes. Having two or more common PCI numbers in close proximity may confuse the UEs deployed in the area.

An idea may be to use the same PCI number as the third octet in a private IP subnet you may be assigning to clients off of an eNodeB. For example if PCI = 67, then a subnet might be 192.168 67.0 or

A good article describing the value of proper PCI planning can be found at

I would also like to thank Anton Kapela for the following summarization of PCI Planning.

Anton Kapela: Let’s start with some assumptions & basic theory of operation here: a) every eNB is frame-synchronized (bits, gps, ptp, sync-e, etc) b) each eNB has been assigned a same ARFCN c) each sector serves roughly the same ‘area’ d) the overall goal is to hold more 'standing UE’s (ie. each eNB at 32 or less) for the sector heading than one eNB can hold e) users accept a random reduction in MCS rates/achievable bitrates, finally f) we’re running this mac/phy config:

-tdd frame #5, ssf #1
-10 MHz channel bw
-normal cyclic prefix
-2 antenna ports
-PHICH Ng factor of 1/2
-4 PHICH groups, 12 REGs, 32 PHICH resources, and PHICH duration of 1 symbol

…This means the first three “best case PCI’s” for us are: 0, 5, and 10 (see images later in thread). This PCI arrangement de-conflicts the important sub-channels of the LTE air frame, but not quite everything, as well read about shortly.

First, a few sub-channels that really, really, really ought not be mutually-stomped upon; that includes the following three items:

-RS (cell-specific Reference Signal), for a given Tx antenna port
-PCFICH (Physical Control Format Indicator Channel)
-PHICH (Physical Hybrid ARQ (Automatic Repeat reQuest) Indicator Channel)

Then there are are three more sub-channels which aren’t effected or steered by PCI selection; those are:

-PSCH (Primary Synchronization Channel)
-SSCH (Secondary Synchronization Channel)
-PBCH (Physical Broadcast Channel)

These sub-channels will forever reside in fixed frequency & time locations on every eNB everywhere; good news, though: their system value isn’t carrying user-related information as much providing basic timekeeping and synchronization of the downlink, and their content is scrambled such that the “pile up” of several eNB isn’t detrimental to a UE’s internal operations.

The only unaccounted parts in our overall airframe of concern, then, are the actual subframe areas that hold the “user data” – that’s the PDSCH (Physical Downlink Shared Channel), which is mapped over all LTE physical resource blocks (PRB), over the entire operating channel bandwidth. An eNB will allocate resources to UE’s on any of the available sub-frame & resource blocks, but it usually starts filling them from sub-frame 0, onwards through sub-frame 9. If we could somehow invert the “fill order” of one eNB (ie. when colocating two or more in a given “sector coverage area”), or even offset its “start filling here” position by some number of subframes, then we’d reduce user-data collisions over the PDSCH even further. This would hold until, of course all of the operating eNB’s were attempting to fully load their PRBs to 100% – it could happen!

Running this out, assuming no special PRB fill order, and assuming there’s some amount of RF isolation through different downtilt (ie. one sector at 0’, one at 3’ or something even more aggressive, with something like 15 to 17 dBi of sector gain, on a ~7’ vertical beamwidth), we’d expect to see HARQ triggered modestly (few %) more often (ie. more incremental-redundancy supplementation due to PRB collisions), and maybe a lower overall MCS rate selection in the DL and probably also the UL, but we wouldn’t expect to see the systems collapse or halt operations. Ideally, the UE’s and the eNB will drive MCS rate selection and transmission mode ™ selection based on HARQ feedback moment-to-moment–implying that PDSCH collisions should not drag things down beyond short term adaptation windows (ie. tens of seconds). Most systems aim for a packet or “burst” error rate of 8% or less, as this represents less overhead than most large-scale MCS rate steps.

Here’s the first few PRB’s that we care about – demonstrating three PCI ID’s for the config I mentioned earlier having fully-non-conflicting RS, PCFICH, and PHICH allocations.

PCI=0, port=0 – only showing PRB 0 through 7 for clarity here

PCI=5, port=0

PCI=10, port=0

And for reference, here’s direct links to the three example frame configs shown in the post:


Great article Rick thanks for the information

Thanks for the article. The provided link for PCI planning discussion is bad The Value of PCI Planning in LTE | RFAssurance. Is there another place to look?

Here are some takeaways I think I am getting from this article. Please correct me if I am wrong.

  1. Each eNB on a given site or operating in each other’s mutual rf emi envelope needs to have a different PCI
  2. PCIs control an entire set of subcarriers and data channels used by a particular eNB
  3. Some of the subcarriers and channels can be deconflicted by proper PCI selection, but others are fixed and will always step on each other to some degree
  4. PCIs 5 or more digits apart deconflict all possible subcarriers and channels

Now if the above are all true, should the PCIs for each eNB on a single tower be spaced at least 5 apart?

It would also seem our scheme of assigning PCI sequentially as we install new radios (1, 2, 3, …) is not a good practice.

If we want to change PCIs of existing operating eNB, other than stranding PCI-locked UE, are there any other consequences?