# Sensors and Communication Simulation for Unmanned Traffic Management
## 5 Proposed Simulation Models for Key Elements
### Communications Simulation  
Public communication networks are modeled using a simple communication hierarchy integrating two different types of agents: mobile communication nodes, which will be simulated as multiple agents (each base station is an independent agent) in the mobile communications simulation service, and a fixed network that interconnects all the agents among them and with the UTM system. The fixed network is modeled through a single aggregation agent, within the network simulation service. Following these considerations, we can define our simulated network architecture in Figure 7, which is completely hierarchical. All simulated information traffic generated by drones, GCSs, or sensors accesses the simulated network through the different mobile nodes and their messages are then sent to the aggregation network. More complex network models might be simulated by including more aggregation agents, our simulator, in principle, being agnostic with respect to the underlying network topology. It is important to differentiate between the message bus  
Figure 6: Drone position simulation process. and action bus messages, used to run the distributed simulation and synchronize agents' behavior, and these simulated information messages, which are simulated counterparts of actual communications present in a real UTM system. Once in the aggregation network, simulated information messages can be forwarded to the interface with evaluated UTM system (traffic flow shown in red in Figure 7) in case they are addressed to the UTM system (sending telemetry, tracks, alerts, etc.) or back to the mobile communications network (in green) if the traffic has a drone or a GCS as destination (ground-to-air channel in BVLOS flights). In other words, the simulated network can carry simulated traffic in both directions. On the other hand, the C2 communication channel for VLOS operations (in blue) is established through an ad-hoc, independent, wireless channel between the drone and the GCS, to be explained in Section 5.4. In order to forward traffic across the different microservices according to the previously defined architecture, we implemented a three-level communications stack simulating the usual TCP/IP (transmission control protocol/internet protocol) tower levels: physical level, link level, and network level. First, the network level ensures that packets follow the correct end-to-end route between different services. To do this, it models packets as objects with the following parameters: protocol (robust/not robust), timestamp, source and destination services, source and destination agent within each microservice, and a payload with the information to transmit. Then, the link level takes care of packet routing between agents within the same network segment: actor-mobile network, mobile network-fixed network, fixed network-UTM interface. At this level, we model the packet in a similar way to the previous one: a payload and two 2-tuples (service-agent) that define the source and destination of the packet within the current network segment. Due to the low complexity of the network architecture, manual routing tables have been implemented to calculate the next hop (link level addresses) from the network level source and destination addresses. Finally, we find the physical level that is in charge of transmitting the packets and that has been implemented making use of a separated logical channel of the message bus. By using this separate logical channel, it is possible to emulate traffic forwarding by publishing messages (sending packets) and subscribing agents to the appropriate topics (receiving packets). Before sending a package through the message bus, each node simulates network disturbances: packet loss, packet burst formation, and packet transmission delay. According to our tests in the field, UTM-bound traffic from drones, sensors, or GCSs is practically negligible compared to other users' traffic, as UTM-related messages are generally short (\(<\)1 Kb) and do not have too high frequency (i.e., around 1 Hz).