LTE physical cell ID and PRACH root sequence planning to 3GPP TS 36.211, for new networks and for expanding live ones. Lock the cells already on air, plan the new ones around them against the real neighbour list, and hand the configuration team a CSV in TS 36.331 field names. Infeasible inputs are reported as infeasible rather than quietly approximated.
Free forever on a Standard account. No credit card.
This is a real, recurring, error prone job with no free tool for it, and the errors it produces are quiet ones. A PCI collision does not throw an exception, it degrades handovers in one part of the network. A PRACH root reused too close does not fail outright, it makes random access intermittent for some users some of the time. Both are the kind of fault that gets blamed on coverage for months.
Most of the time the job is not greenfield. A systems integrator is handed a network that is already on air and asked to add a site, or to check that what is configured is sound. So the planner takes the existing plan as fact. A cell pasted with its PCI and root keeps them, the new cells are placed around them, and a conflict that was already there is reported as pre-existing rather than blamed on the new plan. Paste the whole network locked and the tool audits it instead of planning it.
Every rule is a statement about neighbours, so the neighbour graph decides the plan. On a live network it should be the eNB's own neighbour relation table or a drive-test overlap list, pasted as pairs and used as given. Without one, geometry stands in, two cells being neighbours when their separation is within a threshold times the sum of their radii, and the result says which source was used wherever it matters.
PCI allocation runs over the 504 identities that TS 36.211 clause 6.11 defines as 168 cell groups times three identities. Five rules can be enabled independently: no collision, where neighbours share a PCI and a UE cannot resolve them; no confusion, where two neighbours of the same cell share one and the serving cell cannot resolve them; and avoiding the same PCI mod 3, mod 6 and mod 30 between neighbours. Those last three are not arbitrary conventions. Mod 3 selects the primary synchronisation sequence. Mod 6 is the cell specific reference signal frequency shift v_shift from clause 6.10.1.2. Mod 30 selects the uplink demodulation reference signal base sequence group from clause 5.5.1.3. Each is explained on the panel rather than just named, including that mod 3 subsumes mod 6, so enabling both is not twice the constraint.
The allocator orders cells by neighbour degree and backtracks. When the rules cannot all be met it gives them up one at a time, never collision, and says which ones it gave up and between which cells. Twelve cells that all hear each other cannot avoid sharing a PCI mod 3, because mod 3 has only three classes, and a tool that returns twelve PCIs for that input without saying so has quietly dropped the rule it was asked to hold. The finished allocation is then re-checked by code that did not produce it, against the rules that were asked for, so a bug in the allocator cannot certify itself.
The PRACH side follows a chain where every link can be got wrong. The largest cell fixes the smallest usable cyclic shift N_CS. N_CS fixes how many preambles come from one root sequence, as the floor of 839 over N_CS. That fixes how many roots each cell needs to reach its 64 preambles. And that fixes how many cells the 838 logical root indices can serve before one has to be reused. Reuse that cannot be avoided is placed between cells that are not neighbours, and any that remains between neighbours is named. The result is shown in three groups, what TS 36.211 specifies, what was assumed and what was derived, so the one assumption in the chain, the multipath allowance, cannot be mistaken for a 3GPP value.
A pasted cell that carries a PCI or a root is locked. The allocator places the locked cells first as facts and searches only the free ones, so an expansion never redesigns what is on air. Conflicts between two locked cells are reported as pre-existing, apart from the plan's own violations, and do not make the new cells infeasible.
Paste the whole network with every PCI and root filled in and nothing is planned. The verdict becomes Clean or Conflicts and every collision, confusion and modulo clash already on air is listed with the cells and the rule. It is the first thing to run on a network someone else built.
Paste the eNB neighbour relation table or a drive-test overlap list as pairs and geometry is not consulted at all. The tool reports how many pairs it used and names any id it does not recognise. An empty list refuses to plan rather than reporting a meaningless feasible.
Cells are ordered by neighbour degree and the allocator backtracks rather than taking the first fit, because a greedy pass fails on exactly the dense clusters where the allocation matters most.
No PCI collision, no PCI confusion, and avoiding the same PCI mod 3, mod 6 and mod 30. Every one names the clause of TS 36.211 it comes from and what breaks if it is violated, so the choice to disable one is made knowingly. They are labelled as what they are, planning preferences a design philosophy may or may not hold.
When the rules cannot all be met the tool gives them up one at a time, cheapest first and never collision, and names which ones and between which cells. The result is re-checked by code independent of the allocator against the rules you asked for, so a relaxed plan shows exactly which rules it breaks.
Site lists arrive from a spreadsheet, an eNB export or this tool's own CSV, and none of them share a column order. A header row is recognised and columns are taken by name. Every rejected line is named with its line number; nothing is skipped silently.
N_CS is selected as the smallest value whose zero correlation zone still covers the round trip to the furthest cell edge in the network, and the result prints how much the largest cell could grow before the next N_CS is needed. One oversized cell sets the constraint for everything.
Every cyclic shift with its maximum radius, preambles per root and roots per cell, so the cost of the choice is visible. Moving one step down the table can halve the root budget.
Locked roots are kept. New cells take unheld blocks first, and when the 838 roots run out, reuse is placed between cells that are not neighbours. Any two neighbouring cells that still share roots are named in the table and in a warning, because their preambles collide.
N_CS, the sequence length and the logical root order come from TS 36.211. The delay spread allowance does not, and published cell radius tables disagree because each bakes in its own. It is an explicit input, shown in its own group on the result and printed in the CSV preamble.
One row per cell under the TS 36.331 field names: physCellId, rootSequenceIndex, zeroCorrelationZoneConfig and highSpeedFlag, with the Rel-14 HighSpeed fields for restricted set type B. The same file pastes straight back in with every cell locked to what was exported, so it is the project record.
Paste them with their PCI and root filled in. A cell that carries either is locked: it keeps that value and the allocator plans the free cells around it. Conflicts between two locked cells are reported separately as pre-existing, because the allocator did not create them and cannot fix them, and they do not make the new cells infeasible.
Yes. Paste every cell with its PCI and root and nothing is planned. The verdict becomes Clean or Conflicts and every collision, confusion and modulo clash already configured is listed with the cells and the rule it breaks.
From you, ideally. Paste the eNB's neighbour relation table or a drive-test overlap list as pairs and the plan is made against that; geometry is not consulted. Without a list, two cells are neighbours when their separation is within a threshold times the sum of their radii, and the result says so wherever the neighbours are used. A pair list is directed on the eNB; the tool treats every pair as mutual, which is the conservative reading.
They are consequences of the specification, not conventions. PCI mod 3 is N_ID(2), which selects the primary synchronisation sequence, so neighbours sharing it interfere on synchronisation itself. PCI mod 6 is v_shift, the frequency offset of the cell specific reference signals, so neighbours sharing it put their reference signals on the same subcarriers. PCI mod 30 selects the uplink demodulation reference signal base sequence group. Each has its clause printed beside it, and each is a planning preference a design may or may not hold, which is why every one can be switched off.
No. Mod 3 subsumes mod 6: two PCIs with the same value mod 6 necessarily share it mod 3 as well, so a plan that avoids the same PCI mod 3 between neighbours already avoids the same PCI mod 6. Enabling both is the same constraint as enabling mod 3 alone. The tool says so on the panel, because the assumption that they stack is common and leads people to conclude an allocation is harder than it is.
The allocator gives them up one at a time, cheapest first and never collision, and reports which ones it gave up and between which cells. The plan is marked infeasible against what you asked for, and the re-check lists every rule the delivered plan breaks. Twelve mutually visible cells cannot avoid sharing a PCI mod 3, because mod 3 has only three classes, and any tool that returns twelve PCIs for that input without saying so has dropped the rule without telling you.
As the smallest N_CS whose zero correlation zone still covers the round trip delay to the largest cell edge in the network, and the headroom before the next N_CS would be needed is printed. Choosing it too small breaks random access at the cell edge; too large wastes the root budget, because preambles per root is the floor of 839 over N_CS. The whole table is shown so the trade is visible rather than hidden behind a single recommendation.
The delay spread allowance. TS 36.211 gives the cyclic shift and the sequence length, not how much of the zero correlation zone to reserve for multipath, and published cell radius tables disagree because each bakes in a different allowance. It is an input here, shown in its own group on the result next to the cell radii and the neighbour source, and printed in the CSV preamble, so it can never be read as a 3GPP value.
Yes, and long range networks genuinely do. There are 838 logical root indices for preamble formats 0 to 3. A large cyclic shift means fewer preambles per root, which means more roots per cell to reach the 64 a cell needs, which means fewer cells before the budget is exhausted. When reuse is unavoidable the tool places it between cells that are not neighbours and names any neighbouring pair that still shares roots.
Yes, and it warns when the format rather than the cyclic shift is the binding constraint on cell size. The preamble format sets its own reach through the cyclic prefix and guard time, and there are configurations where no choice of N_CS rescues a cell that the format cannot reach. Reporting the cyclic shift alone in that case would point at the wrong lever.
One row per cell under the TS 36.331 field names the configuration team already works in: physCellId, rootSequenceIndex, zeroCorrelationZoneConfig and highSpeedFlag, with the Rel-14 HighSpeed fields when restricted set type B is chosen, plus each cell's neighbours and any conflicts. Preamble lines record the neighbour source, the rules, the verdict and the multipath allowance. Paste the file back into the Network tab and every cell returns locked to what was exported.
Because an allocator that validates its own output can only confirm its own assumptions. The verification is written against the rule definitions rather than against the search, and it runs against the rules you asked for rather than the ones the allocator kept, so a defect in the search shows up as a failed check rather than as a confidently wrong plan.
Free forever on a Standard account. No credit card.
