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 172.16.67.0.
A good article describing the value of proper PCI planning can be found at http://main.rfassurance.com/?q=node/79
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
-CFI=1
-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:
http://niviuk.free.fr/lte_resource_grid.html?duplex_mode=tdd&tdd_ul_dl_cfg=5&tdd_spec_subf_cfg=1&tdd_spec_subf_cfi=1&bw=10&cp=norm&n_tx_ports=2&tx_port=0&cell_id=0&cfi=1&phich_ng=1_half&phich_dur=norm&mbsfn_subf=none&mbsfn_cfi=1&marker_type=none&mrkr_subf=0&mrkr_pcfich_reg=0&mrkr_phich_reg=0&mrkr_phich_map_unit=24&mrkr_pdcch_reg_type=logical&mrkr_pdcch_cce=0&mrkr_pdcch_cce_reg=0