UWB & BLE RTLS for Indoor Positioning

What problem does this solve?

Zone-based tracking answers where something was when it last passed a reader. That is enough for inventory and gates, but not for the questions that come from safety and production: is anyone inside the exclusion zone around that crane right now, which bay is the forklift actually in, how long did the maintenance crew spend in the substation, and where is the mobile ventilator on this floor. Answering those needs a position that updates continuously, not an event from an hour ago.

Teams that try to stretch existing infrastructure into this role are usually disappointed. Wi-Fi and plain BLE signal-strength positioning move with people, doors, stock levels and humidity; the same tag can appear to jump ten metres when a pallet is placed between it and a gateway. Accuracy quoted in a supplier proposal is typically an open-space, static-tag figure, while the operational requirement is a moving tag in an aisle surrounded by steel.

The third problem is the aftermath. An RTLS produces a very large number of positions per second, and without zones, rules and a calibrated floor plan it becomes a screen with dots that nobody watches. The engineering effort that matters is not installing anchors — it is the survey, the calibration, the zone model and deciding which few events deserve an alert.

How the solution works

A working indoor RTLS has four parts: surveyed anchors with known coordinates and synchronised timing, tags sized to the asset and its duty cycle, a positioning engine that fuses ranging measurements into filtered positions, and a rules layer that converts positions into zones, dwell times and alerts. UWB is used where centimetre-level accuracy changes a decision — safety exclusion zones, tool and process positioning, dense high-value storage. BLE is used where knowing the room or area is enough, which covers most search-and-find and utilisation use cases at a fraction of the infrastructure cost.

Swedish Technology delivers this as custom development around MOWQIE for the tracking and rules layer and, where a spatial context is needed, RASM for the floor-plan and 3D digital-twin overlay. The anchor survey, calibration files, zone definitions and integration code are handed over, so accuracy can be re-verified and the system extended to new areas by your own team.

1. 1
   Input — tags and anchors Each tracked asset, vehicle or person carries a UWB or BLE tag with a defined transmit rate. Anchors or gateways are mounted at surveyed X/Y/Z coordinates, powered over Ethernet where cabling allows.
2. 2
   Capture — ranging measurements UWB anchors measure time of flight to the tag by two-way ranging, or the difference in arrival time between synchronised anchors (TDoA); AoA arrays measure the angle a signal arrives from. BLE gateways measure signal strength, or angle when direction-finding hardware is used.
3. 3
   Processing — solve and filter The engine trilaterates or multilaterates a raw position, then applies filtering (Kalman or similar), floor and wall constraints and speed limits, so a tag cannot jump through a wall or teleport between aisles.
4. 4
   Zoning — apply the site model Positions are matched against the zone model: rooms, bays, exclusion zones, muster points, production cells. Most business logic works on zone and dwell, not on raw coordinates.
5. 5
   Integration — publish events Zone entry and exit, dwell thresholds, occupancy counts and last-known position are published over MQTT, REST or a message queue to the WMS, EAM, safety systems, GIS or digital twin.
6. 6
   Action — alerts and interlocks Rules raise control-room alerts, mobile notifications or, where the safety case allows it, signals to a supervisory system: person in exclusion zone, vehicle over speed in an aisle, asset leaving an authorised floor, no movement for N minutes.
7. 7
   Reporting — utilisation and evidence Historical tracks feed utilisation, cycle-time and congestion analysis, muster reports after an evacuation drill, and an evidence trail for incident investigation, with retention rules agreed in advance.

Reference architecture

Keep positioning, rules and presentation in separate tiers. Positioning is hardware-specific and may be replaced; the rules and the site model should outlive any one vendor's anchors.

Deployment options: Anchors, engine and rules run on-premise on a segmented operational network. Dashboards can be published to a UAE-region private cloud for multi-site views, or kept entirely internal for classified sites; air-gapped deployments are supported with local update packages.

Key capabilities

Integrations

Positions are only useful when they reach the systems people already work in. All of the following are implemented as custom development against documented APIs.

Industry use cases

Implementation approach

1. 1
   Requirements and rules workshop (1 week) List the questions and alerts that must work on day one, the areas where they apply, and who acts on each alert. Alerts without an owner are removed at this stage.
2. 2
   Accuracy target per area Agree, in writing, the accuracy needed in each area — centimetre, metre or room — and accept BLE where a cheaper answer is sufficient.
3. 3
   Site survey Measure obstructions, ceiling structure, metal density, cable routes and power availability; produce an anchor layout with expected coverage and blind spots.
4. 4
   Pilot area Install one representative area, survey the anchor coordinates, calibrate, and verify accuracy against marked reference points with a moving tag, not only a static one.
5. 5
   Zone and rule modelling Draw zone polygons on the floor plan, define hysteresis, dwell thresholds and escalation paths, and tune until alert volume is manageable.
6. 6
   Integration build Publish events to MOWQIE, the twin, the WMS or EAM with a stable asset key and idempotent messages; agree replay behaviour after an outage.
7. 7
   Rollout and acceptance Extend area by area, repeating the verification procedure; acceptance is measured accuracy and alert behaviour, not the number of anchors installed.
8. 8
   Hand-over and maintenance plan As-built anchor survey, calibration data, zone definitions, source code, spare tags and anchors, battery replacement schedule and operator training.

Security & deployment

An RTLS that tracks staff or contractors is a personal-data system and is designed accordingly: role-based access to live positions, aggregated views for supervisors, full detail only for authorised safety and security roles, and an agreed retention period after which tracks are aggregated or deleted. Anchors and the positioning engine sit on a segmented operational VLAN with no inbound internet route; tag identifiers are meaningless outside the database, and the mapping from tag to person is held in a restricted table with its own audit log. Integration to enterprise systems is one-way where possible, uses service accounts with least privilege, and every published event is logged. For classified facilities the entire stack, including map data and floor plans, is deployed on-premise or air-gapped.

Limitations & prerequisites

• UWB accuracy of 10–30 cm assumes line of sight to at least three or four anchors; behind machinery, inside metal cages or through thick walls the error grows and can degrade to metres.
• TDoA deployments need tight time synchronisation between anchors, usually via cabling or a wireless sync master — this is a real installation constraint, not a configuration setting.
• BLE signal-strength positioning is affected by stock levels, people, doors and humidity; expect area-level accuracy and re-calibration after significant layout changes.
• Battery life quoted for tags assumes a specific update rate; running a tag at 10 Hz for safety use can shorten life from years to months.
• Anchor and cabling cost scales with area and obstruction density, so a large low-value warehouse rarely justifies full UWB coverage.
• The floor plan and zone model must be maintained; when racking or partitions move and the model is not updated, alerts become wrong before anyone notices.
• Tracking people requires policy approval, consent or works-council style agreement depending on the organisation; the technical deployment is usually not the critical path.

UWB vs BLE vs RFID zones for indoor positioning

Choose the least infrastructure that answers the question. Many sites combine all three.

A common design is BLE across the whole building for search and utilisation, UWB only in the safety-critical or high-density areas, and passive RFID at doors and gates for custody evidence.

FAQ

Related topics & solutions

• RFID vs Barcode vs BLE vs UWB: Choosing a Tracking Technology
• RFID Site Survey & POC Checklist
• RFID Asset Tracking for Enterprise & Government
• RFID Integration with SAP, Oracle, Odoo & IBM Maximo
• MOWQIE ÔÇô RTLS Tracking
• RASM ÔÇô Digital Twin
• Smart Warehouse Safety
• Octopus WMS