TDMA Synchronization

Introduction

Synchronization of anchors is essential part of Time Difference of Arrival (TDoA) location system. In order to deliver sub-meter position accuracy (1 ns = 30 cm) precise time synchronization in sub-nanosecond resolution is required. This is done via UWB radio from master anchor to all other anchors within line of sight range. It is a periodic process driven from server through backhaul (Ethernet/Wi-Fi). There could be dozens of master anchors within the RTLS deployment. Therefore, UWB transmission among anchors must be aligned into timeslots with micro-second resolution.

There are three driving schemes over the backhaul network available:

  • UDP Synchronization - Anchors are synchronized via UDP single broadcast message from RTLS Manager.
  • TCP Synchronization - Anchors are synchronized one by one via continuous TCP connection. The TCP connection is established by Anchors.
  • UDP-AD Synchronization - Anchors are synchronized by a specific anchor within local network = Anchor driven synchronization


Pros and Cons

Below you can find pros and cons of all, TCP, UDP, and UDP-AD:

Sewio strongly recommends placing the RTLS Studio host server to the same subnet as positioning system anchors to provide the best possible reliability and performance. The highest reliability requires UDP Sync mode on anchors activated. UDP Sync between server and anchors can operate only within the same subnet! 

If TCP Sync is used the host server can be distant, which provides a bit more flexibility. Moreover, TCP Sync also provides higher channel capacity, and both backhaul variants Ethernet and Wi-Fi. However, anchors within the network are logically organized to form a tree. It might take from seconds to minutes to build the tree depending on the size of the deployment. Occasionally, the tree might need to be reorganized (self-healing) within a dynamic environment. Think about big metal objects such as cranes which can block a link for a more extended period between the anchors. Therefore, some radio links might be broken, and the tree must be reorganized. This process is called self-healing. Within the self-healing, the location within the given area (sub-tree) is not available. 

UDP-AD (UDP Anchor Driven) Sync is the evolution of TDMA slot alignment via UDP broadcasting for Ethernet. UDP-AD synchronizes anchor slots via Ethernet. Thus, it provides the best stability without the need for self-healing (known in TCP Sync) in harsh environments. Furthermore, it removes previous limitations, so server and anchors do not have to be within the same L2 network. It also works with RTLS Studio deployed in the Docker environment. Currently, this feature is released in the BETA stage.

Combination of different synchronization schemes among Anchors within single deployment is not allowed. All Anchors must be set either to TCP Sync, UDP sync or UDP-AD Sync.

Comparison

Here is a brief comparison table:

Synchronization Scheme

UDP Sync

TCP Sync 2nd Gen

UDP-AD Sync

Maturity Level

STABLE

STABLE

BETA

Backhaul protocol

UDP Broadcast

TCP Unicast

UDP Broadcast

PortUDP/5001TCP/5001UDP/5001
Communication DirectionRTLS Studio - Transmitter / Anchor - Receiver

RTLS Studio - Transmitter / Anchor - Receiver / Anchor - Transmitter / RTLS Studio - Receiver

Anchor - Transmitter / Anchor - Receiver
Sync TopologyFlat

Tree

Flat

Startup TimeImmediate1 - 5min (300 anchors)Immediate

RTLS Studio location

Must be within the same L2 network - same broadcast domain

Router cannot be on the communication path.

No limitations*

Cannot have NAT on the network path

RTLS Studio could be in the different subnet then anchors. 

The selected anchor sends a synchronization message. The selected anchor must be within the same L2 network - same broadcast domain.

Cannot have NAT on the network path.

Ethernet backhaul

Complete

Complete

Complete

Wi-Fi backhaul

Ethernet only

Scalable Access Point topology

Ethernet only

Mixed Ethernet/Wi-Fi backhaul

No

Yes

No

RTLS Studio

>=1.3.2

>=2.3

>=2.5

Anchor FW

>=1.000

>=3.002, recommended 3.005

>=3.1.5