The real-world decision the system should support
Transport hubs — railway stations, airports, bus interchanges and metro terminals — present a distinct set of conditions for Bluetooth beacon deployments. The scale is larger than a typical retail unit, the physical infrastructure is more complex, and multiple organisations often share the same space. Before evaluating beacons for a transport environment, it helps to understand what the technology can and cannot do when applied to these buildings.
Beacons broadcast small packets of data at regular intervals. A smartphone, tablet or dedicated receiver detects that signal and, depending on the setup, triggers an action such as a push notification, a map update or a log entry in a backend system. The beacon itself does not track anyone; it simply transmits. Detection, interpretation and any data processing happen on the receiving device or server side.
In a transport hub, the practical value of beacons usually falls into a few categories: helping passengers find their way, providing context-sensitive information near specific zones such as gates or platforms, supporting accessibility features, and generating anonymised footfall data for operations teams. Each of these uses depends on a receiver being present — typically the passenger's own phone running an app or a web browser with the right permissions.
The physical environment matters more here than in many other settings. Stations and airports contain large expanses of metal, glass, concrete and moving vehicles. RF reflections, absorption and interference from other Bluetooth devices are constant. A beacon placement that works reliably in a quiet museum gallery may behave unpredictably beside a busy departure gate. Any accuracy claim for a transport hub should be treated with scepticism unless it is backed by an on-site survey of that specific environment.
Privacy obligations in UK transport hubs are shaped by the UK GDPR and the Data Protection Act 2018. If the system identifies individuals or links location data to personal identifiers, the deploying organisation needs an appropriate lawful basis. Consent or legitimate interests may be relevant in some architectures, but neither should be assumed without analysing the purpose, communication channel, reasonable expectations and safeguards. Many transport operators opt for anonymised, aggregated analytics to reduce the compliance burden, but the architecture of the system determines whether that separation is genuine. The Information Commissioner's Office (ICO) guidance on location data and privacy should be consulted before any deployment that logs device presence.
Build around the venue rather than a demo
Wayfinding and zone triggers
Indoor navigation in a transport hub relies on dividing the space into zones and assigning beacons to those zones. As a passenger moves through the building, the receiving device detects which beacons are within range and updates the on-screen map accordingly. The granularity depends on beacon density, placement and the calibration work done on site.
For wayfinding to function, the passenger needs a compatible app or web page open with location services enabled. This is a significant adoption hurdle in environments where people are often in a hurry, carrying luggage or using devices provided by employers. Some operators mitigate this by combining beacons with visible QR codes at decision points, allowing passengers to load the map only when they need it rather than requiring a permanent app install.
Platform and gate notifications
Triggering a notification as a passenger approaches a specific platform or gate is one of the most frequently cited use cases. The logic is straightforward: a beacon near the gate broadcasts, the app detects it and checks the passenger's booking, then displays relevant departure information. In practice, the challenge is defining the trigger zone precisely enough that the notification arrives at a useful moment — not so early that it is ignored, and not so late that the passenger has already walked past.
Gate areas in airports and platform approaches in stations are often open, high-ceilinged spaces with limited mounting options. Beacons may need to be attached to structural columns, ceiling panels or seating. Each of these surfaces affects signal propagation differently, and the presence of crowds — particularly during peak periods — adds additional RF absorption that can shift the effective detection range.
Accessibility applications
For passengers with visual impairments or other accessibility needs, beacons can provide turn-by-turn audio guidance or confirm arrival at a specific point such as a assistance desk, a lift or a designated waiting area. This use case demands higher reliability than general wayfinding because the passenger may have no visual fallback. Redundancy — overlapping beacon coverage, fallback to NFC tags at key points and clear physical signage — is essential rather than optional.
Transport operators planning accessibility features should involve disabled passengers in pilot testing. Feedback from real users often reveals issues that RF surveys alone cannot, such as the timing of audio prompts, the clarity of instructions at noisy concourses and the behaviour of the system when a passenger pauses or changes direction.
Operational footfall analytics
When beacons are used solely for counting and movement patterns — without linking detections to named individuals — the privacy requirements are less onerous, though not absent. Scanners placed at key points detect beacon advertisements or general BLE traffic and log timestamps and signal strength. Aggregated over time, this data can reveal queue build-up, congestion hotspots and underused routes.
The limitation is that this approach measures device presence, not person count. A passenger carrying two Bluetooth-enabled devices registers twice. Someone with Bluetooth disabled is invisible to the system. These gaps need to be acknowledged when presenting analytics to operational decision-makers, particularly if the data is being used to justify staffing changes or infrastructure investment.
Placement constraints in transport environments
Mounting beacons in a station or airport is rarely as simple as sticking a unit to a wall. Access to ceilings and high-level structures often requires working at height, outside operational hours and in coordination with the facility's safety protocols. Some areas — near signalling equipment, on moving infrastructure such as escalators or within secure zones — may be off-limits entirely or require special approval.
Battery replacement follows the same logic. A beacon mounted above a busy concourse at six metres needs scaffolding or a cherry picker to service. If the deployment involves hundreds of units with varying battery lives, the maintenance schedule becomes a significant operational commitment. Choosing beacons with accessible mounting points and standard battery types, and recording exact locations in an asset register, reduces the time and cost of each replacement cycle.
What should decide whether to scale
Assuming uniform accuracy across the site
A common error is to calibrate beacons in one area — say, a quiet terminal concourse — and assume the same distance-to-RSSI relationship holds everywhere. In reality, a gate area with metal seating, a ticket hall with glass barriers and an underground passage with tiled walls each produce different RF characteristics. Calibration needs to be performed zone by zone, and the results recorded so that the system can apply the correct parameters as a passenger moves between areas.
Underestimating interference from other sources
Transport hubs host a high density of Bluetooth devices: passenger phones, headsets, luggage trackers, payment terminals and operational equipment. Wi-Fi access points operating in the 2.4 GHz band can also affect BLE performance. During a pilot, scan for other BLE advertisements in the environment and note how they vary by time of day. If the beacon protocol allows, select an uncommon advertising channel or manufacturer-specific data format to reduce the chance of false detections.
Deploying without a clear maintenance plan
Beacons are often treated as fit-and-forget hardware, but batteries deplete, units are dislodged by cleaning equipment or vandalism, and firmware may need updates. A transport hub deployment should include a documented maintenance schedule, a process for logging beacon health checks and a clear assignment of responsibility — whether to an in-house facilities team or an external integrator. Without this, the system will degrade silently, and the first indication of a problem may be passenger complaints or gaps in analytics data.
Neglecting multi-tenant coordination
Large stations and airports often host multiple operators: the transport company, retail tenants, security contractors and sometimes third-party advertising networks. If more than one organisation deploys beacons in the same space, there is a risk of signal collision, confusing app behaviour and duplicated infrastructure costs. Before deploying, establish whether a central beacon infrastructure exists or whether one should be created, with access governed by clear agreements. This avoids a situation where three different retailers each install their own beacons on the same concourse.
Key checks before committing to a deployment
- Has an on-site RF survey been conducted at representative times, including peak and off-peak periods?
- Is there a documented calibration process for each zone, with results stored and accessible to the integrator?
- Can beacons be physically accessed for battery replacement without disrupting passenger flow or requiring costly access equipment?
- Does the asset register record each beacon's ID, firmware version, battery type, installation date and precise location?
- Is the privacy position documented, including whether detections are anonymised, how long data is retained and what the lawful basis is?
- Have accessibility needs been incorporated into the pilot design, with input from actual passengers who will rely on the system?
- Is there a coordination mechanism with other organisations operating beacons or BLE scanners in the same building?
- Does the contract with the integrator specify ongoing support, firmware update procedures and a clear process for fault escalation?
Beacons can deliver genuine operational and passenger-experience benefits in transport hubs, but only when the deployment respects the physical realities of the environment and the organisational complexities of shared infrastructure. A well-run pilot — measured against defined success metrics, tested with real passengers and reviewed honestly — is the most reliable way to determine whether a full rollout is justified.
