> For the complete documentation index, see [llms.txt](https://docs.gxc.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.gxc.io/usecases-workflows/warehousing-and-logistics/asset-and-forklift-tracking.md).

# Asset & Forklift Tracking

## Overview

A distribution center always knows what it has. It rarely knows where. Inventory systems track stock against a location record that was correct at the moment it was written, and diverges from reality with every mis-scan, every pallet moved to make room, and every trailer that gets loaded out of sequence. The cost shows up as search time, as re-picks, and as the safety incident that happens when a pedestrian and a reach truck arrive at the same aisle intersection.

Tracking over private 5G puts position underneath the inventory record rather than beside it. Forklifts, tugs, pallets, cages, and high-value assets report position continuously; the tracking platform on the Onyx Edge resolves those reports into locations, zones, and dwell times; and the WMS gets a live picture rather than a record of the last scan. The same position stream drives proximity safety (a warning when a vehicle and a pedestrian converge) and that safety flow carries different network requirements from the telemetry flow, and that tension is what the design has to resolve.

Two traffic profiles, one network: thousands of endpoints sending very small packets, plus a small number of low-latency safety messages that must not queue behind them.

***

## How It Works

### Two traffic planes on one network

<figure><img src="https://1757002526-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F4cpyhgEABOCzEQhYuIZ4%2Fuploads%2F6ZYJABlIOWnYjaUTPSvS%2Ftracking-two-planes.svg?alt=media" alt="Asset tracking on two separate bearers: a telemetry plane carrying position reports from thousands of tags, and a proximity safety plane on its own delay-critical bearer."><figcaption><p>Telemetry and proximity safety travel on separate bearers. Thousands of position reports must never queue in front of a safety warning.</p></figcaption></figure>

### What each component does

| Component                 | Role in this workflow                                                                                                                                                         |
| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Asset tags**            | Battery 5G devices on pallets, cages, and high-value assets. Reporting interval matched to how fast that asset class actually moves                                           |
| **Vehicle telematics**    | Mains-powered from the forklift, so it can report frequently and carry the safety flow as well as position, telemetry, and impact detection                                   |
| **Pedestrian devices**    | The worker's PTT handset or a dedicated wearable, contributing position to proximity safety                                                                                   |
| **Onyx RU**               | Coverage everywhere an asset can be: including the yard, dock approaches, and outbuildings that Wi-Fi RTLS typically does not reach                                           |
| **FHM / shared cell**     | No handover events, so no position discontinuities as assets cross the site                                                                                                   |
| **Onyx Edge · 5G Core**   | Two QoS treatments: 5QI 70 non-GBR for telemetry, 5QI 84 delay-critical GBR for safety. **The constraint here is device density and small-packet scheduling, not throughput** |
| **RTLS platform**         | On the Onyx Edge. Resolves reports into positions, zones, dwell times, and geofence events                                                                                    |
| **Convergence detection** | Also on the edge. Evaluates vehicle and pedestrian positions and triggers in-cab warning and speed limiting                                                                   |
| **Onyx Portal**           | Bulk tag provisioning, per-group policy, and per-device connectivity diagnostics across thousands of endpoints                                                                |
| **Mesh Node**             | Wireless backhaul to RUs across a yard where conduit is impractical                                                                                                           |

### The two paths

**Telemetry plane · 5QI 70, non-GBR, 200 ms budget**

| # | From → To                          | What happens                                                                                                  |
| - | ---------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| 1 | Tag → Onyx RU                      | Small packet: position, state, battery. 5–50 kbps, on an interval from 1 s (vehicles) to 300 s (bulk storage) |
| 2 | RU → FHM → Onyx Edge               | Aggregated; no handover, so no position gap                                                                   |
| 3 | UPF → RTLS platform                | Local breakout. Reports resolved into zones and rack areas                                                    |
| 4 | RTLS → WMS / TMS / yard management | Position published where it becomes a decision                                                                |

**Proximity safety plane · 5QI 84, delay-critical GBR, 30 ms budget**

| # | From → To                      | What happens                                                                                         |
| - | ------------------------------ | ---------------------------------------------------------------------------------------------------- |
| 1 | Vehicle + pedestrian → Onyx RU | Position on a **separate bearer**, 1–5 s interval, mains-powered so frequency is not battery-limited |
| 2 | RU → Onyx Edge                 | Delay-critical scheduling: this traffic does not queue behind telemetry                              |
| 3 | Convergence detection          | Evaluates converging tracks against geofences and proximity rules                                    |
| 4 | → In-cab warning + speed limit | Operator informed; vehicle speed limited where integration allows                                    |

### Accuracy is a per-zone decision

Accuracy is expensive, and most of a site does not need much of it.

| Tier          | Accuracy | Answers                                           | Delivered by                                                     |
| ------------- | -------- | ------------------------------------------------- | ---------------------------------------------------------------- |
| **Zone**      | 5–15 m   | Is this pallet in inbound, outbound, or the yard? | Cell and RF-fingerprint methods                                  |
| **Aisle**     | 1–5 m    | Which aisle, and which end of it?                 | Same, with denser RU coverage and calibration                    |
| **Sub-meter** | < 1 m    | Which rack position?                              | Supplementary UWB or BLE anchors, not the cellular network alone |

Zone-level tracking eliminates most search time; aisle-level supports traffic management. Specifying sub-meter across an entire site is an expensive answer to a question most sites are not asking.

### Why the planes must not share a bearer

This is the central design decision on the page. Twenty megabits per second of aggregate traffic is trivial. Ten thousand simultaneously connected devices, each waking to send a few hundred bytes, is a **scheduling and signaling** problem, and if a proximity-safety message has to queue behind thousands of telemetry reports, it arrives late. A proximity warning that arrives 200 ms late is not a warning.

**Proximity safety is a warning system, not a protective one.** It reduces incidents by informing an operator. It is not a safety-rated interlock and must never be presented as one to a safety review. Where a protective function is required, it belongs in the vehicle's own safety-rated systems.

***

## Network Requirements

| Parameter                               | Target                                                                  |
| --------------------------------------- | ----------------------------------------------------------------------- |
| Per-tag data rate                       | 5–50 kbps depending on reporting interval                               |
| Per-vehicle data rate                   | 50–200 kbps including safety flow                                       |
| Aggregate, 5,000 tags plus 200 vehicles | < 20 Mbps                                                               |
| Connected device density                | 1,000–10,000 per site: verify against the deployed core and cell limits |
| Reporting interval                      | 1–5 s vehicles · 30–300 s slow-moving assets                            |
| One-way latency, telemetry              | < 100 ms                                                                |
| One-way latency, proximity safety       | < 30 ms                                                                 |
| Jitter                                  | < 20 ms                                                                 |
| Packet error rate                       | 10<sup>-6</sup>                                                         |
| Positioning accuracy                    | Zone 5–15 m · aisle 1–5 m · sub-meter requires supplementary technology |
| Availability                            | 99.99%                                                                  |
| Telemetry QoS                           | **5QI 70**: non-GBR, mission-critical data, 200 ms PDB                  |
| Safety QoS                              | **5QI 84**: delay-critical GBR, 30 ms PDB, 10<sup>-5</sup> PER          |
| Battery life target, tags               | 2–5 years with extended DRX and interval matched to asset class         |
| Bands                                   | n77, n78, n48 (CBRS), n40                                               |

## Deploying It

1. **Design accuracy by zone** using the tiers above, and define geofences: pedestrian walkways, vehicle-only zones, hazardous areas, dock approaches, and any zone with a dwell-time rule.
2. **Validate the device-density budget** against the deployed core and cell configuration at full tag count, before committing to a tag population. This, not bandwidth, is what the network has to absorb.
3. **Provision two subscriber groups**, Tracking Telemetry on 5QI 70 and Proximity Safety on 5QI 84. Configure power-saving deliberately: extended DRX and RedCap-class devices trade reporting latency for battery life, and the trade should be made per asset class rather than site-wide.
4. **Fit and bind.** Mains-powered units on forklifts and tugs; battery tags on pallets, cages, and high-value assets. Provision in Onyx Portal and bind each tag to its asset in the tracking platform.
5. **Deploy and calibrate.** RTLS platform on the Onyx Edge. Walk the site with a reference device to build the RF fingerprint or validate positioning against known ground-truth points.
6. **Establish battery management before go-live.** A tracking fleet degrades silently. Configure low-battery alerting and an expected-report watchdog that flags tags gone quiet. Name an owner for the replacement process before a gap turns up during a stock count.
7. **Use the data.** Search elimination is the immediate return. Congestion heat maps identify where layout costs throughput. Dock and yard dwell times become measured rather than estimated. Near-miss events by location give the safety team a map instead of anecdotes.
8. **Add recalibration to change management.** Positioning that depends on RF characteristics depends on the racking that shapes them.

## Devices & Ecosystem

* [**Battery 5G asset tags**](https://docs.gxc.io/devices/gxc-compatible-devices/modules): RedCap-class or LTE-M-class devices sized for multi-year battery life at a reporting interval matched to the asset.
* **Vehicle telematics units**: mains-powered from the forklift, carrying position, telemetry, impact detection, and the proximity safety flow.
* **Pedestrian devices**: the worker's PTT handset or a dedicated wearable, contributing position to the proximity-safety system.
* **In-cab display and speed control**: the actuation end of proximity safety; integration with the vehicle's own controller is vendor-specific and should be scoped early.
* **RTLS platform**: hosted on Onyx Edge, resolving reports into positions, zones, and events.
* **Supplementary UWB or BLE anchors**: where sub-meter accuracy is genuinely required in a defined area.
* **WMS / TMS / yard management integration**: the systems that turn a position into a decision.

## Design Considerations

**Specify accuracy per zone, and resist over-specifying.** Sub-meter accuracy across an entire site is an expensive answer to a question most sites are not asking. Zone-level tracking eliminates most search time; aisle-level supports traffic management. Reserve high-accuracy technology for the areas that demonstrably need it.

**The constraint is device density, not bandwidth.** Twenty megabits per second is trivial. Ten thousand simultaneously connected devices, each waking to send a few hundred bytes, is a scheduling and signaling problem. Validate the connected-device budget against the deployed core and cell configuration before committing to a tag count.

**Separate the safety flow from the telemetry flow at the bearer level.** This is the decision that defines the design. A proximity warning that arrives 200 ms late is not a warning. Put it on a delay-critical bearer where thousands of telemetry reports cannot queue in front of it.

**Proximity safety is a warning system, not a protective system.** It reduces incidents by informing an operator. It is not a safety-rated interlock, and it should never be presented as one to a safety review. Where a protective function is required, it belongs in the vehicle's own safety-rated systems.

**Battery management is the operational risk.** A tag fleet degrades silently. Build low-battery alerting, an expected-report watchdog that flags tags that have gone quiet, and a replacement process with an owner, before the deployment, not after the first gap in coverage is discovered during a stock count.

**Recalibrate after layout changes.** Positioning that depends on RF characteristics depends on the racking that shapes them. Add recalibration to the site's change-management process alongside the coverage re-survey.

**Consult on tracking that includes people.** Where pedestrian position is collected for proximity safety, be explicit about what is collected, what it is used for, how long it is retained, and who can see it. Deploy it as a safety system with a defined purpose limitation, engage the workforce and any representative body early, and confirm the approach against the site's local privacy and employment obligations. A tracking program that is perceived as surveillance will be resisted regardless of its safety benefit.

## Validation Checklist

* [ ] Accuracy requirement defined per zone, with high-accuracy technology confined to areas that need it
* [ ] Geofences defined for walkways, vehicle-only zones, hazardous areas, and dock approaches
* [ ] Connected-device budget validated against the deployed core and cell configuration at full tag count
* [ ] Telemetry and safety flows on separate bearers; safety latency verified with full telemetry load running
* [ ] Proximity safety latency measured under 30 ms end to end, including in-cab actuation
* [ ] Positioning accuracy verified against ground-truth points in each accuracy zone
* [ ] Coverage validated across the full yard, dock approaches, and outbuildings: not just inside the building
* [ ] Reporting interval and DRX configuration set per asset class, with battery life modeled
* [ ] Low-battery alerting and gone-quiet watchdog configured; replacement process has a named owner
* [ ] Recalibration trigger added to the site change-management process
* [ ] WMS integration verified: position updates reconcile against inventory records
* [ ] Proximity safety documented as a warning system, and the vehicle's safety-rated functions confirmed independent of it
* [ ] Workforce consultation completed and purpose limitation documented where pedestrian position is collected
* [ ] Full-site peak test with every tag and vehicle reporting concurrently

***

## Next steps

* **Size it.** Take these requirements through [Plan Your Network](https://docs.gxc.io/plan-your-network): capacity, coverage, architecture, and a preliminary bill of materials.
* **Compare it.** [Network Requirements at a Glance](https://docs.gxc.io/usecases-workflows/network-requirements-at-a-glance) puts every workflow side by side, for sites carrying more than one.
* **Talk to us.** For a validated design and a quote, [contact GXC](https://gxc.io/contact-us/).

## Related reading

* [Connected Worker Push-to-Talk](/usecases-workflows/warehousing-and-logistics/connected-worker-push-to-talk.md) : voice for the people working alongside the fleet
* [AGV and AMR Fleet Control](/usecases-workflows/manufacturing/agv-and-amr-fleet-control.md) : closed-loop control, where tracking becomes steering
* [Network Requirements at a Glance](/usecases-workflows/network-requirements-at-a-glance.md) : all workflows side by side


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.gxc.io/usecases-workflows/warehousing-and-logistics/asset-and-forklift-tracking.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.