Robots transmit and receive subscription data. We create network metadata and send it to the testbed monitor so we can perform network flow analytics.

Network Metadata

Here is how we create and use network metadata:

• Define our scenario:

  First, we define our robot scenario and network characteristics. The values we select define what subscriptions will travel between what robots, at what rate, with what QoS and Security profiles, using what Wifi network configuration, and with what type of robot mobility. These settings can easily cause network saturation and data loss. We want to know latency and loss for the scenarios we define.

• Prepare transmission data:

  Robots transmit subscription data based on scenario settings defined in the scenario configuration file. Before transmitting this data, however, we wrap it in a ROS2 msg data structure and add information about the transmission that we will need for reporting about network latency and loss. Here is the packet data we prepare for transmission:

  • Timestamp in nanoseconds.
  • The name of the robot transmitting the subscription
  • The name of the subscription
  • The number of times this robot sent this subscription.
  • The actual message, where its length is the length defined in the scenario file and where its value is the byte used as the first letter of the subscription name.

  Here are some links about this process:

  • Working with ROS2 msg data structures: https://index.ros.org//doc/ros2/Tutorials/Rosidl-Tutorial/
  • Our testbed msg file: https://github.com/nps-ros2/ns3_testbed/blob/master/cpp_testbed_runner/msg/TestbedMessage.msg
  • Our robot publisher and subscriber callback code: https://github.com/nps-ros2/ns3_testbed/blob/master/cpp_testbed_runner/src/testbed_robot_callbacks.cpp

• Transmit data:

  Transmit the prepared data using the frequency and QoS parameters defined in the scenario configuration file and any security settings defined for the subscriptions.

• Receive network data and log network metadata:

  Robots that receive subscrition data prepare and send out network metadata logs. Network metadata logs consists of the following fields, encoded as a CSV string:

  • The source and destination robot names with a "-" in between.
  • The subscription name.
  • The message size for the whole TestbedMessage data structure, not just the size of the message portion.
  • The number of times the message was sent by the transmitting robot.
  • The number of times the message was received by the receiving robot.
  • The timestamp of when the message was sent, in nanoseconds.
  • The latency calculated as the difference between the time the message was processed by the subscriber robot and the timestamp in the published message, in milliseconds.

  Once the network metadata log is composed, it is written to the testbed monitor's named pipe for consumption by the Testbed Monitor.

• Consume the network metadata log:

  The Testbed Monitor consumes the network metadata logs from the named pipe, stores them for future analytics, and updates its realtime table.

• Create graphs:

  As a post-processing step, we run analytics on stored network metadata logs to produce latency and loss graphs.

The Testbed's Named Pipe

The testbed's named pipe is an Operating System pipe that our testbed programs create and use for moving network matadata logs from robots that receive data to the testbed monitor program that consumes these logs and performs network flow analytics. If you have run the testbed monitor then you can see the named pipe in your home directory by typing: ls ~/_testbed_pipe.pipe. Because robots can run concurrently on multiple processors, they lock the pipe before writing to it so logs don't get fragmented.