Definition
Real-Time Location (RTL) refers to the capability of IoT devices to acquire and report their current geographic coordinates (latitude, longitude, altitude, speed, direction, etc.) in real time. Real-time location is an application form of location technology, emphasizing "real-time" — location data needs to be collected and reported to the platform within a short period (e.g., on the order of seconds, second-level). Real-time location supports applications such as logistics tracking, full trajectory, boundary alerts, geofencing, boundary notifications, and others.
Unlike historical trajectories, real-time location emphasizes 'where it is now'; compared to real-time positioning , real-time location focuses more on the business application of location data (such as display and alerts), whereas real-time positioning emphasizes the positioning technology itself. In cross-border scenarios, real-time location needs to support multi-country positioning and continuous online reporting, a single card for multiple countries ensures location reporting during cross-border travel.
Technical Features and Architecture
The real-time location technology architecture includes: positioning layer — obtaining coordinates through GNSS, base station positioning, RTK , etc.; collection layer — reporting collected locations periodically or triggered by events ; transmission layer — reporting location data to the platform via cellular network, supporting data compression ; application layer — platform parses location, determines geofence , triggers boundary crossing alerts and boundary crossing push notifications . Combined with trajectory , it can form trajectory playback ; combined with second-level reporting, high-frequency real-time location can be realized. In cross-border scenarios, multi-country maps and unified coordinate systems need to be considered.
The frequency of real-time location reporting affects traffic and power consumption, which needs to be balanced according to business needs; sleeping devices need to be awakened before they can report location.
Application in IoT and cross-border scenarios
Real-time location is widely applied in: Logistics and delivery —— Logistics trackers , Logistics tracking , Full trajectory monitoring, real-time location of drivers and vehicles; Vehicles and charging ——In-vehicle terminals, Charging station navigation, triggering boundary-cross alert when vehicles enter geofences ; Asset monitoring ——Real-time location and boundary-cross alarms for high-value assets; Drones and aviation ——Real-time location broadcasting in Remote ID . Scenarios such as cross-border logistics, cross-border charging, and cross-border fleets all rely on real-time location to achieve full visibility , with one card for multiple countries ensuring cross-border connectivity.
SimtoLink provides stable connectivity for IoT devices in real-time location scenarios, covering 200+ countries and regions, supporting cross-border logistics tracking , charging stations and other scenarios.
Freshness of Real-Time Location as a Business Object
A real-time location is the record, in a business system, of where this device is now. It contains the coordinate, the solution time, optional speed and heading, and how long the record may still be trusted. What it emphasizes is freshness, not which satellite was used. A precise coordinate from three hours ago is no longer a real-time location for dispatch. A cell point that was just reported, with an error of several kilometers, should not be drawn as the vehicle's current position merely because the time is new. The display should look at age and error together. If the age exceeds the business agreement, relabel it last known location. If the error is larger than the current use, do not use it for a lane or a fence decision.
Store the solution time and the time the platform received the report separately. On a cross-border link the two can differ by many seconds or even minutes. Judging arrival by the received time counts a vehicle still outside the fence as already arrived. A catch-up upload must keep the original solution time. Playing points in arrival order draws the route backward. Speed and heading show whether the point is moving or stopped. Stationary jitter should not be joined into a high-speed track. If the business only needs in or out of the site, the report rate can be lowered, the allowed age of a real-time location can be relaxed to minutes, and the interface should state that age instead of labeling everything real-time.
When the Current Position May Be Shown Outside
The current position may be shown outside when the latest point is younger than the threshold agreed for that scene, the error radius is smaller than the decision distance of that scene, the coordinate reference frame matches the map, and there is no unhandled reversal of time. For logistics dispatch asking whether a vehicle is near a warehouse, the threshold may be tens of seconds to a minute or two. Whether an asset has left a yard has to be set separately against the fence width. The last point before a device sleeps should drop, once it is past the threshold, to last known location, and it should stop raising new boundary events. Holding the previous state when there is no new point is steadier than continuing to alarm on an extrapolated position. A cross-border display should also confirm that the viewer is allowed to see a fine coordinate in that region. A summary view can stop at the city or the site.
A Cached Point Labeled as the Current Point
A common mistake is a map that keeps using a cached point while the icon still says real-time, and dispatch sends a vehicle from that point. Another is that server time overwrites device time. Points buffered in a tunnel are reported together at the exit and drawn as the vehicle jumping. A third is a fence engine that consumes an expired point, so a vehicle long gone does not alarm, or a vehicle still inside alarms because an old point is outside. When accuracy is ignored, a representative point of an urban cell fix happens to fall inside the fence, and an asset is treated as recovered. A fourth is multiple location sources with no priority, so a beacon point and a satellite point overwrite each other and the icon jumps between indoors and outdoors. The display interface should return age, error, and a status word. Use current only when both age and error qualify. Otherwise use last known. The fence engine should subscribe only to qualified points.
The query interface returns age, error, and the status word together. The caller uses them to decide whether the point may be used for dispatch or an alert. The platform does not rewrite an unqualified point into the current coordinate.