confusion.

In Oktober of 2007 I finished my first academic studies as a Bachelor of Science in Computer Science and Communication Systems at the HTW in Saarbrücken, Germany. To do so, I had to write a bachelor thesis during the last months of the semester. Together with a fellow student, Thomas Stein, we decided to do something more special than a typical software implementation (which sometimes is more than challenging for such a short thesis time, too).

Fortunately we were in good contact to some profs from the high frequency, computer science and telecommunication departments who had a complex problem in their current field of research, which was WiMAX (Wikipedia has some info, if you don’t know WiMAX). They wanted to precisely measure the variability of packet transmission latency over time, which is commonly known as “jitter” or packed delay variation (see RFC 3393).

Measuring jitter in computer networks is typically done in two ways: For precise one-way-measurement (variance in transmissions from one network device to another one), loop-devices can be used. These have two network-interfaces, one for the outgoing packet and a second one for the incoming. As both are driven by the same timer-base, the measurement accuracy is only dependent from the operating system’s qualities. As second way to measure jitter is to use round-trip-measurements. To do so, the measurement sends a packet over the network to a recipient who transmits a packet back to the sender.  This is quite similar to the commonly known “ping” command. So, if you know that the client always needs the same time to respond, you can measure the jitter by comparing the transmission times over time. Both methods have their own big ”but …”. The first one, the one-way-measurement, is only applicable for “local” installations as you need the cabled loop. The latter one can only measure round-trip times, which is quite dissatisfying if you expect different delay and jitter measurements for up- and downstream (especially in asymmetric or wireless networks).

As a solution for this problem we developed “SynchronQoS”,

[...] a measuring device for quality aspects of IP-based networks was developed using a real time platform and the global satellite system GPS. It provides the ability to analyse one way trip times, round trip times, packet loss and the variance of trip times. Time measurement accuracy is below 10 μs independent from the global placement of the gauging stations.

Aim of the work was to create a system that is able to measure packet transmission (especially one-way jitter) aspects between two globally distributed endpoints. Because we wanted to develop a system that can be used for any distance between the two endpoints, it had two consist of two independent devices that could not be time-synchronized with an additional reference cable (e.g., fibre cable), which is a quite common solution for short distances, too. In order to measure one-way delay and it’s jitter, however, the devices needed to be synchronized. To solve to problem we decided to rely on the global positioning system (GPS) which is also a time-critical system and therefore can (and needs to) provide a precise timing (and position).

Basically, GPS receivers measure the difference in runtimes of signals coming from multiple satellites. As the signal runtime is equal to the distance from the satellite, a receiver can triangulate it’s position on the surface – three satellites are sufficient for a position on the earth’s surface, a fourth satellite provides a height above the zero-level (typically, more satellites are used for speed and precision improvement). However, to measure the relative runtime between multiple signals, the transmission-times needs to be known. Therefore, each GPS satellite contains an atomic clock and transmits it’s position and the time of transmission. By using the satellites’ positions, the runtimes and additionally position correction information, a quite exact position determination is possible. Furthermore, knowing the exact position from triangulation, the receiver can quite exactly synchronize to the global time by adding the signal runtime to each signals transmission time and averaging on multiple time/runtime sets from different satellites.

In our project, for which the basic concept is shown in the figure, we used two separate devices whose time is synchronized using the GPS. With this common time base, packet transmissions over a local, distributed or even global network (like the internet) can be measured. To reduce costs of production and increase the usage flexibility we decided that both devices, the transmitter and receiver should be identical and the operation mode should be defined by software.

The software, in turn, was another great challenge. We had to design a quite low-cost and easy to build device with a software whose function execution (time) is highly predictable. To achieve these key requirements we decided to base up on a microcontroller-centric real-time platform. Communication with the device should be implemented using standard TCP/IP communication, like telnet.

Finally, after a lot more of project planning and discussions, we concluded with a reliable concept, ready for implementation. Thanks to another good contact from the HTW, we managed to get hands on a TriBoard TC1130.300 microcontroller board with a TriCore MPU. For the GPS part we bought two Resolution T receivers from Trimble with external antennas for high signal gain. The receiver had two advantages: First, it was designed for high precision position measurement using a multi-measurement smoothing algorithm that could be configured to use several thousands of triangulation rounds to fix the position very precisely. Second, the device is able to generate a pulse-per-second signal with an astonishing one-sigma-precision of 15ns, we used as an interrupt to synchronize the microcontrollers time once every second.

Finally we pieced everything together: The GPS receiver was connected to the TriBoard using a custom-built signal level shifter board and an additional interrupt signal for the PPS. Voltage regulators were added to operate the device with a single power supply of 9V DC. The TriBoard itself could be connected to a PC using Ethernet for serial setup and using JTAG for programming.

To reduce the time of implementation and to have a reliable base for real-time operation we used PXROS-HR by HighTec EDV-Systeme (the same company who gave us the boards), a high-performance real-time operation system for the TriCore platform. We use 5 different tasks with different priorities to minimize the response time for time-critical parts like processing the PPS or incoming TCP/UDP packets in measurement mode.

Although facing a lot of problems we finally built up two prototypes we could use for first tests and measurements before our thesis time was over and we had to refocus on the challenges of the Master courses . Our measurements using available network hardware showed that we could reach a precision of about 10-30 µs without optimization. Looking back on our work we finally added a large chapter on possible improvements and further work-to-do to our thesis document; a lot of things we concerned but couldn’t focus on due to the time-limitations. In this case, time had been a challenge in every aspect – or to say it with Hector Berlioz’ words:

“Time is a great teacher, but unfortunately it kills all its pupils.”

– Hector Berlioz –