Most RTLS projects start with a vague request: “We need real-time tracking.”

That sounds clear until the first design meeting. Real time for what? A forklift moving through a warehouse? A worker entering a restricted zone? A pallet that sits still for three days? A container moving between a yard, a truck, and a covered loading bay?

This is where many projects drift. Buyers ask for “10 cm accuracy” or “live tracking” before they define what the system must actually prove. The result is familiar: too much infrastructure in low-risk areas, not enough performance in critical zones, and a pilot that looks good on a map but is hard to operate.

A better starting point is a location Service Level Agreement (SLA).

A Real-Time Locating System (RTLS) location SLA is a written definition of what “good enough location” means for a specific site, asset type, safety process, and battery target. It can’t and shouldn’t replace technical design but makes technical design possible.

We’ve seen this often: the hard part is rarely attaching a tag. Agreeing what the tag must prove is the hard part.

What Is an RTLS Location SLA?

A useful location SLA should define accuracy, update rate, latency, confidence level, battery life, map assumptions, and failure modes. These are not marketing details. They are the difference between a system that is accepted by operations and one that becomes a permanent exception list. ⁽¹⁾

A simple SLA table might look like this:

SLA item	What it defines	Example
정확성	How close the reported location must be	Within 3 m in open warehouse zones
업데이트 속도	How often the system reports	Every 5 seconds, 30 seconds, or 1 minute
숨어 있음	How quickly the event appears	Alarm visible within 10 seconds
Confidence	How often the system must meet the target	90 percent of valid reports
Battery target	Expected operating life under the chosen settings	6 months, 1 year, or 5 years
Exceptions	What happens in blind spots or degraded conditions	Cache, last known position, unavailable status, or alarm

Notice what is missing: one universal accuracy number.

That is intentional. A chemical plant, warehouse, hospital, tunnel, port, and construction site do not need the same location behavior everywhere. A good SLA allows different service levels by zone.

How to Define RTLS Requirements Before Choosing Technology

Before choosing hardware, write the operational sentence.

Not: “We need 초광대역.”

Better: “We need to know whether a worker entered the machine safety zone, and the alarm must appear in the control room within 10 seconds.”

Not: “We need 10 cm accuracy everywhere.”

Better: “We need sub-meter positioning near automated equipment, but room-level visibility is enough in offices, storage rooms, and break areas.”

This matters because “location” can mean several things.

존재 감지 means the system knows that a tag, badge, or beacon is near a gateway, doorway, room, checkpoint, or zone. It is useful for entry and exit records, room-level monitoring, and simple safety logic.

• BLE RSSI positioning estimates location from received signal strength. It can be practical for rough indoor positioning, especially when assets do not move constantly, and the system can collect several readings.
• GNSS is a strong fit for outdoor tracking of vehicles, containers, and mobile equipment, but it should not be treated as a reliable indoor positioning method. ⁽³⁾
• Bluetooth AoA improves location by estimating signal direction. It is useful when a site needs more precision than RSSI-based BLE but still wants to use Bluetooth tags or 비콘.
• 초광대역 is the better fit when high-precision indoor positioning justifies more planning around anchors, calibration, geometry, and power. ⁽⁴⁾

The SLA should separate these needs. Do not force one technology to solve every location problem on site.

How to Specify RTLS Accuracy Requirements

Accuracy should be written with three parts: distance, probability, and zone. ⁽²⁾

A weak requirement says: “Accuracy: 1 m.”

A stronger requirement says: “In Zone A, the system shall report personnel location within 1 m for at least 90 percent of valid reports after calibration, excluding marked blind spots and maintenance periods.”

That sentence is more useful because it defines where the promise applies, how it will be judged, and what counts as an exception.

For Lansitec-style deployments, it helps to think in location classes:

Location class	Practical meaning	일반적인 적합성
존재 감지	The object is near a known point or zone	Entry, exit, room-level monitoring
BLE RSSI positioning	Approximate indoor location	Assets, corridors, warehouses
GNSS positioning	Outdoor location	Yards, vehicles, containers
블루투스 AOA	Direction-based higher precision	Personnel, tools, process zones
초광대역	High-precision indoor positioning	Safety zones, automation, critical assets

The keyword is fit. BLE RSSI is not a failed 초광대역 system. GNSS is not an indoor RTLS system. 초광대역 is not automatically the right answer for every tagged object.

Our customers often start by asking for the highest possible accuracy. After the site walk, the better question usually becomes: where does high accuracy change a decision?

RTLS Update Rate vs Latency: What’s the Difference?

Update rate and latency are different. Update rate is how often a device scans, advertises, calculates, or reports. Latency is how long it takes for the result to appear in the dashboard, alarm system, API, or third-party platform.

A tracker may support a short report interval, but that does not mean every event will appear instantly. End-to-end latency depends on the device configuration, scan window, radio backhaul, network server, application logic, and dashboard refresh.

Write both into the SLA.

예를 들어:

Weak wording	Better SLA wording
“Real-time tracking”	“Moving assets shall update every 30 seconds, with dashboard refresh within 10 seconds of server receipt.”
“Instant alarm”	“Restricted-zone entry alarms shall appear in the control room within 10 seconds for 95 percent of valid events.”
“Live worker tracking”	“Personnel updates shall run every 5 to 15 seconds in high-risk zones and every 60 seconds in normal zones.”

This protects battery life and network capacity. A worker near a confined-space entry may need fast updates. A pallet in storage probably does not.

How to Define RTLS Battery Life Requirements

Battery life is not a separate datasheet line. It is part of the location service.

A badge advertising every 100 ms behaves differently from one advertising every 800 ms. A tracker using GNSS every 30 seconds will not last like one reporting every 10 minutes or only on movement. A gateway with continuous 블루투스 수신 will consume more power than one with a shorter receive window.

So, write the battery promise under the actual reporting policy.

예를 들어:

“The badge shall support one working month between charges when configured for 1-second beacon advertising and 30-second location updates in normal zones.”

Or:

“The asset tracker shall support at least 12 months of operation when reporting every 10 minutes while moving and once per day while stationary.”

This avoids a common pilot problem: aggressive settings make the demo look great, then production fails because charging, replacement, or maintenance becomes unrealistic.

Why RTLS Maps and Calibration Matter

RTLS depends on the map.

For BLE, AoA, and 초광대역, 게이트웨이, 비콘, or anchors must be placed at known positions. If these reference points move, the system may still show a dot, but the dot may no longer be trustworthy.

을 위한 초광대역, anchor calibration is especially important because the positioning engine calculates tracker location from anchor coordinates and distance measurements. For B-고정 BLE architectures, fixed 비콘 also need correct coordinates. The same logic applies to floors, walls, restricted zones, obstructions, and large metal structures.

Add map requirements to the SLA:

요구 사항	Example wording
Reference point control	“Gateway, beacon, and anchor coordinates shall be recorded after installation.”
Floor handling	“Multi-floor areas shall use floor-specific reference points or altitude logic where supported.”
Obstruction handling	“Known blind spots, metal barriers, roofed GNSS-blocked areas, and RF-shielded rooms shall be marked before acceptance testing.”
Change control	“Any movement of anchors, 게이트웨이, 비콘, racks, or large machinery requires a validation check.”

This may sound procedural, but it matters. We like map discipline because it turns RTLS from a gadget into infrastructure.

How to Plan for RTLS Failure Scenarios

Every location system has failure modes. A good SLA names them before deployment.

BLE RSSI can hear signals from nearby rooms. Walls may weaken a signal but not fully block it. People, humidity, furniture, and metal structures can affect RSSI. GNSS can degrade under roofs, near buildings, or underground. 초광대역 performs best when anchor geometry and line-of-sight conditions are understood. AoA depends on stable gateway installation and careful placement. ⁽²⁾⁽³⁾

Do not hide these conditions. Define what the system should do.

Failure mode	SLA decision
GNSS cannot fix under a roof	Switch to BLE if available, report last known position, or mark location unavailable
BLE signal appears from adjacent room	사용 RSSI thresholds, calibration, room-specific placement, or classify as presence only
UWB 앵커 is moved	Mark the affected zone unvalidated until recalibration
Network outage	Cache where supported or show last known timestamp clearly
Battery low	Alert before the device drops below the operational threshold

An SLA that defines degraded operation is more credible than one that promises perfect tracking everywhere.

RTLS Location SLA Template for Industrial Projects

Before sending an RFQ, define these items:

Section	What to write
Business objective	What decision the location data must support
Tracked objects	People, vehicles, tools, pallets, containers, keys, visitors
Zone classes	High-risk zones, normal zones, storage zones, outdoor zones, blind spots
Accuracy target	Error radius and confidence level per zone
Update policy	Report interval, scan interval, movement logic, event-triggered reports
Latency target	Delay from movement or event to dashboard, API, or alarm
Battery target	Required life under the agreed configuration
Infrastructure assumptions	게이트웨이, anchors, 비콘, power, backhaul, mounting, calibration
Map requirements	CAD files, coordinates, floors, obstructions, change control
Exception handling	GNSS loss, weak BLE, network outage, moved anchor, low battery
Acceptance test	How the system will be tested before sign-off

A short example:

“In warehouse aisles, asset tags shall be located within 3 m for 90 percent of valid reports. Reports shall update every 60 seconds while moving and every 10 minutes while stationary. Restricted-zone entry alarms shall appear in the application within 10 seconds. Known blind spots behind metal storage structures shall be marked on the map and excluded from accuracy scoring. Battery life shall be at least 12 months under the approved configuration.”

That is clear. It is testable. It gives procurement, safety, operations, and engineering the same expectation.

How an RTLS Location SLA Helps You Choose the Right Technology

Once the SLA is written, hardware selection becomes much easier. ⁽³⁾⁽⁴⁾

• If the SLA says “room-level presence,” a BLE gateway or beacon-based architecture may be enough. You do not need centimeter-level tracking to know that a tool cart entered the maintenance room.
• If the SLA says “3 to 5 m in an open warehouse,” BLE triangulation may be sufficient, especially for assets that stay in place long enough for the system to collect stable readings.
• If the SLA says “outdoor container and vehicle tracking,” GNSS with 로라완, NB-IoT, LTE-M, or Cat-1 backhaul becomes more relevant.
• If the SLA says “sub-meter worker location in a hazardous operating zone,” Bluetooth AoA deserves serious consideration.
• If the SLA says “10 to 30 cm positioning around high-value inventory, robotics, or safety-critical equipment,” 초광대역 may justify the added infrastructure.

The portfolio should follow the SLA, not the other way around.

Best Practices for Writing an RTLS Location SLA

RTLS buyers do not really buy tags, anchors, 게이트웨이, or dashboards. They buy a location outcome.

They want to find assets faster. Reduce search time. Prove that workers entered or left defined zones. Improve emergency response. Protect high-value equipment. Reduce manual counting. Understand utilization. Avoid arguing with a map no one trusts.

That outcome needs a written SLA. Start with accuracy, latency, confidence, battery life, map quality, and failure mode. Then choose the technology. It may feel slower at the beginning, but it usually makes the pilot cleaner, the quote more realistic, and the final deployment easier to defend. And frankly, it keeps everyone honest.

참고 자료 및 추가 읽을거리:

1. NIST introduction to ISO/IEC 18305
2. MathWorks Bluetooth Location and Direction Finding
3. GPS.gov GPS Accuracy
4. FiRa Consortium UWB Regulatory Guide