# Prototype of 5G Integrated with TSN for Edge-Controlled Mobile Robotics
## 3 Prototype of 5G Integrated with TSN
### Setup of the TSN Network  
The TSN network consists of the endpoints receiving and sending messages as well as the TSN switches transmitting the data. **Setup of the TSN-Endpoints**  
For the integrated prototype, two different endpoints are needed: one sending the data and one receiving it. The TSN capability of the endpoints depends mainly on two factors: the correct and accurate sending of the data and the time synchronization to the rest of the system. To generate transferable results of the prototype, we decided not to use the robot PLC and the factory cloud as endpoints. For the prototype, two PCs were used that were both implemented in the same way, generating the same data traffic as the robot PLC and the factory cloud. In Figure 2, the PC endpoints and the potential connection points for the PLC and the factory cloud are indicated. To enable real time of the operating system, the kernel needs to be patched with a Preempt-RT Patch. With that patch, the Linux-Kernel is fully preemptible; therefore, it can be used as a real-time operating system [23]. Furthermore, to enable deterministic transmission and time synchronization, a network card capable of Precision Time Protocol (PTP) time synchronization and with at least two different transmission queues, one for time-critical and one for non-time-critical messages, is needed. Therefore, the Intel i210 network card was used, offering four transmission queues and hardware timestamping, which is needed for time synchronization using IEEE 802.1 AS generalized Precision Time Protocol (gPTP). \begin{table}
\begin{tabular}{c c c c} \hline \hline  & **Cloud-Based PLC** & **LiDAR** & **Camera Stream** \\ \hline \multirow{3}{*}{**Traffic Type**} & Cyclic & Events: alarm and & Video \\  & Asynchronous & Operator control & \\  & Periodic & Sporadic & Periodic \\ \hline \multirow{2}{*}{**Period**} & \multirow{2}{*}{7 ms} & \multirow{2}{*}{25–100 ms} & \multirow{2}{*}{15–30 fps} \\ \hline
**Data Delivery** & Latency Bound & Latency Bound & Throughput \\
**Guarantee** & \textless{Period 90\%} & Min. Throughput & \\ \hline \multirow{2}{*}{**Tolerance to Loss** **(Survival Time)**} & 1–4 frames & \multirow{2}{*}{Yes} & \multirow{2}{*}{Yes} \\  & (Loss of 1 to 4 consecutive frames) & & \\ \hline \multirow{2}{*}{**Data Size**} & Fixed 50–80 Bytes & Variable & Variable \\  & & 100–160 Bytes & \textgreater{}1000–5000 Bytes \\ \hline \multirow{2}{*}{**Criticality**} & High & Medium & Low \\  & Hard Real-Time & Soft Real-Time & \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Traffic characteristics for the mobile robotics use case. **Setup of the TSN Switches**  
As a set of standards, TSN offers a variety of mechanisms for reliable communication, most relying on shared time between all devices. To meet the requirements of the mobile robotics use case, deterministic data transfer needs to be enabled. This can be achieved by using the different traffic shaping mechanisms of TSN. Since TSN-enabled switches are not yet established in the market, the number of options and supported features was limited. The IEEE 802.1 Qbv-Enhancements for Scheduled Traffic [24] enables shaping of the traffic in a time-driven fashion by controlling the egress gates of a switch for different traffic classes, thereby, e.g., enabling cyclic transmission of data. For instance, the transmission can be divided into cycles. Each cycle contains different slots in which only an assigned and specific type of data traffic is allowed. In addition to the time-synchronization data, two different data types are defined in the prototype: Best Effort Traffic and Critical Data (Priority Code Point 7). Corresponding to that, the cycles have been divided into slots, as shown in Figure 3. In classical best effort use cases, the traffic arrivals can be modeled with stochastic arrivals and ON-OFF distributions [25; 26], and accordingly, scheduling algorithms are designed. For mission-critical industrial automation application use cases, traffic is typically periodic [15] and has been the focus in our work.