DECT Capacity Planning: Traps on Large Sites
Most wireless voice deployments fail for reasons that have nothing to do with radio coverage. An installer walks the site, confirms that a handset makes a call in every zone, signs off the survey, and declares the floor covered. Six weeks later the site opens, two hundred handsets register at once, the system behaves, and then at shift change something degrades. The problem was never coverage. It was capacity, and capacity planning is a different discipline from coverage planning. On large sites — warehouses with tall racking, hospitals with multiple wings, campuses with several buildings, distribution centres with yard areas — the questions multiply: how many cells, how much registration churn, how much capacity does handover consume, and what happens when the data network next door saturates the same rack. This article sets out the planning questions that should be answered before any equipment list is produced, and the traps that catch teams who skip them.
Coverage and Capacity Are Two Different Problems
Coverage asks a simple question: can a handset hear a cell at an acceptable signal level? Capacity asks a harder one: how many concurrent voice sessions, registrations and handovers can the system sustain at that location, and does the answer hold during the busiest hour of the busiest day? A site can have perfect coverage and still fail on capacity, and it can have generous capacity and still fail on coverage. Treating the two as one question is the first and most expensive trap in DECT planning.
The distinction matters because the remedies are different. Coverage problems are fixed by moving or adding cells, tilting antennas, or adding distribution. Capacity problems are fixed by adding cell bandwidth, redistributing handsets across more cells, or moving registration-heavy devices to different cells. If the survey only measured signal strength, the design has no answer to the second class of problem.
The Traps That Show Up on Large Sites
| Trap | What it looks like in production | Planning countermeasure |
|---|---|---|
| Sizing cells by floor area alone | Handsets cluster in one cell during peak hours | Model handset density per zone, not square metres |
| Ignoring shift-change registration storms | Simultaneous registration bursts after handover of shifts | Stagger shifts or enable registration load distribution |
| Underestimating yard and dock coverage | Dropped calls the moment a truck door opens | Survey exterior zones in the same pass as interior |
| No room for growth in the design | Every new zone requires a truck and a shutdown | Reserve cell positions in the initial design |
| Confusing RF survey with capacity survey | Survey report shows strong signal, users report busy failures | Record concurrent-session load during the survey |
| Forgetting interference from adjacent sites | Intermittent one-way audio near perimeter walls | Check neighbouring spectrum users before final design |
Modelling Handset Density Before Choosing Cells
Capacity planning starts with a question that has no technical answer on its own: where do the handsets actually spend their day? A warehouse associate may spend most of a shift in one aisle. A hospital ward nurse moves between four zones repeatedly. A campus security officer walks a fixed loop. Density in those cases is nothing like an even distribution across the floor plate, and even distribution is exactly what a floor-area calculation assumes.
The practical method is a zone-by-zone density map. Divide the site into operational zones, count the people assigned to each zone during the busiest period, apply an allowance for visitors and contractors, and convert that into expected concurrent sessions. Zones with a high ratio of people to available cells usually need dedicated cells even when their floor area is small. For example, a small marshalling area with a high staff count per square metre can need more cell bandwidth than a large but sparsely occupied storage area.
Registration Load Is a Different Axis from Session Load
Every DECT handset must register with the system, and it must do so again whenever it returns to its home cell, loses and regains signal, or is switched off and back on. On a large site with many handsets, these registration events can arrive in bursts rather than being spread evenly. Shift changes, meal breaks, fire drills and the end of a shift all produce clusters of returning handsets.
A burst of registrations is a different load from a burst of calls. Calls consume media bandwidth for their duration. Registrations consume signalling capacity briefly and then release it. Systems that are comfortable with peak call load can still struggle with concentrated registration bursts if the registration handling is concentrated on a small number of cells. Design responses include distributing handsets across more cells so that no single cell absorbs the whole returning population, staggering operational schedules where the business allows, and confirming with the vendor how registration load is spread across the deployment.
Roaming Behaviour and Handover Load
Roaming between cells is not free. Each handover consumes signalling transactions on both the old and the new cell, and in dense environments where cells overlap heavily, a slow-moving handset can experience repeated handovers if the system does not apply hysteresis. The design implication is straightforward: overlap between neighbouring cells should be sufficient to survive movement, but not so wide that a stationary handset oscillates between cells.
Walk testing should therefore be done at realistic speed and with realistic devices. A survey conducted by walking slowly through each aisle with a single test handset measures coverage but tells you very little about handover behaviour. Ask for a survey that includes transit between key zones, note handover counts, and compare them with what the design expected.
| Handover symptom | Likely cause | Action |
|---|---|---|
| Handset shows one cell then another while stationary | Cell overlap too wide | Reduce overlap or adjust hysteresis |
| Calls drop while walking a corridor | Coverage gap between zones | Add or reposition a cell on the corridor |
| Busy tone when moving between departments | Cell session capacity exhausted | Add cells in the busiest zone |
| Registration repeats every few minutes in one area | Unstable RF causing drop and re-register | Investigate interference or antenna alignment |
| Coverage fine at desk, poor in a cold store | Different materials and temperature | Survey the cold zone separately |
Charging, Spares and the Operational Half of Capacity
Capacity planning is not finished when the radio design is finished. Handset battery life, charging station density and spare unit availability determine whether the design works during a twelve-hour shift. If the charging banks are concentrated near the office rather than near the picking zones, handset availability falls long before RF capacity does, and the symptom gets misdiagnosed as a wireless problem.
Plan the operational layer with the same care as the RF layer: charging points distributed to match shift patterns, a documented procedure for a failed handset, spare units held on site, and a monitoring view that shows handset online status by zone. Sites that skip this step typically report that the system works well in the morning and degrades through the afternoon, which points at battery and charging behaviour rather than at radio capacity.
A Planning Checklist for Large-Site DECT Projects
- Build a zone-by-zone handset density map based on real shift patterns, not floor area
- Survey interior, yard, dock, and cold or high-humidity zones in one pass
- Walk transit routes between zones and record handover behaviour, not just signal level
- Model shift-change registration bursts and confirm how they are distributed
- Keep neighbouring spectrum users in view, including other sites in the same building
- Reserve spare cell positions so future zones do not require a shutdown
- Plan charging and spare-unit logistics alongside the radio design
- Agree a monitoring and alerting approach before go-live, not after complaints arrive
Redstone Approach
Redstone can support wireless voice projects at the planning stage, where the decisions that determine long-term reliability are still open. This includes reviewing site layouts and operational patterns, advising on how DECT handsets should be organised across cells and zones, and outlining what a site survey should measure so that coverage and capacity are validated together rather than separately. Redstone also assists with the design intent for the phone system side of a wireless deployment, including how wireless handsets register alongside desk extensions and how calling groups behave when the answer point is a mobile device.
Because capacity decisions outlive equipment models, Redstone focuses on documenting the design assumptions — density assumptions, growth allowance, and coverage verification method — so that future expansion follows the original intent instead of introducing a second, uncoordinated design.
Redstone Systems, Inc. founded in Delaware, USA in December 2002, has been the ODM vendor for many well-known communications companies, serving the Southeast Asian market. In 2020, Redstone Systems will begin to return to the North America market with its self-developed brand.
Redstone has a complete product line of intelligent voice gateways, providing IP-PBXs, analog VoIP gateways (FXS/FXO), digital VoIP gateways (E1/T1), border appliances, and session boundary controllers (SBCs).
With advanced technology in digital signal processor (DSP), speech coding and speech processing, as well as efficient operational tools such as cloud remote management, auto provisioning, Redstone gateways are widely used in markets of enterprise communications, cloud communications, call centers, operators’ IMS/SIP trunks, bringing users friendly, efficient and reliable communication experience.
For more information about Redstone, You can follow us on Facebook, Linkedin, and Youtube to be the first to get the latest news.

Current Location :

