CAVICO

Title

Context-Aware Video Controller for autonomous transport and security monitoring

Organization

ITTI

Experiment description

Tests of the developed system that is able to control the video streaming on the basis of measured QoS and QoE parameters were divided into a few stages in order to minimize risks of errors in the developed software. The system was implemented in a client-server model. VNF based on a VM of Ubuntu Linux was deployed using 5GINFIRE Portal and it acted as a server site that manages the control process in a feedback loop between the server and client. The client site was designed and developed for a Raspberry Pi board equipped with a video camera. The Raspberry Pi board used the OBU device to communicate with the core network via available wireless interfaces. Moreover the OBU device provided geographic coordinates from a GPS receiver built in it.

The three stages of tests were the following:

• local tests at the ITTI premises using local server and client instances;
• remote tests with RPi and VNF in Portugal where the client was immobile in a laboratory;
• remote tests in the field where RPi and VNF were deployed in Portugal and the RPi client was driven in a vehicle in the campus in Aveiro.

Results of these tests are presented in Section 2 and Section 3.

An overview on the system architecture is shown in Figure 1.

Figure 1. System architecture

The network infrastructure in Aveiro that was used for CAVICO project is presented in Figure 2. CAVICO client software was installed in the RPi board. It communicates with OBU via IEEE 802.11p interface. The OBU device provides access to the core network via WLAN access. This wireless transmission was handled by RSU. Routing and authentication between the network infrastructure in Aveiro and the remaining network resources including the NFV cloud were managed by the LMA gateway.

Simulation tests and results

Simulation tests were performed using local Wi-Fi connection between PC with the server application and Raspberry Pi 3 Model B with the client application. Tests were made using pathchirp [2] software for throughput testing and simulated GPS signal. The GPS server created to perform tests in a simulated environment loads txt file containing desired movement speed ( ) and waypoint coordinates. Every time it receives request, it calculates new location using basic integral and trigonometric operations. The GPS server was simulating a route in campus of University of Aveiro.

Test results are shown on figures below. Figure 3 shows subsequent vehicle location during simulation tests (red dots). It is easy to see in Figure 4 that the location types correlated with the use case were found correctly and without any disturbance. Figure 5, Figure 6 and Figure 7 visualise test conditions for video and network. As it is shown in Figure 8 and Figure 9 parameters of the video stream are not constant and they change during tests. In the first phase of the experiment (0-75 s) there were performed extra moves in front of the RPi camera to simulate dynamic changes of the environment. The frame rate of the stream grows (from 26 to 32 FPS) but resolution stays constant. Between 35 and 50 s of the test the vehicle goes on parking, so the base of the control process is changed – both FPS and resolution adjust to another use case. In the middle phase of the test (100-225 s) TA in the video is low, so the frame rate drops to reduce network usage. When vehicle enters an area of the fuel station (225 s) ControlApp changes parameters of the video stream once more to adapt to user’s expectations because higher resolution is required and lower frame rate is acceptable to save bandwidth of the radio interface.

Figure 3. Test route

VNF tests

Another test was performed using VNF (10.154.8.117) as the server and Raspberry Pi (10.6.0.95) as the client. Tests were made using iperf [1]. The test route was the same like in Section 2.1. Results of the test are shown in figures below. The image in front of the camera was static, so Temporal Activity remains on low level, and the control algorithm has reduced frame rate of the video stream. Nevertheless video stream parameters are not constant. Network throughput was highly unstable, and it is easy to see its influence on video resolution that fluctuates between 130 and 250 s.

System tests during driving in the field

Final tests of the system were done in the campus of University of Aveiro, in Aveiro, Portugal. The client application installed in RPi module and connected to OBU module was mounted in a car which was driven along roads in the campus where parking places are also situated. Both RPi client and VNF server were launched. The server site received:

1. information about the vehicle position (from a GPS receiver installed in OBU),
2. transmission channel throughput (measured by the dedicated software),
3. video stream (from the RPi camera).

Positioning data (1) allowed identifying the use case. In these field tests there were two use cases – road and parking, or ‘unknown’ location could be identified (Figure 18). The information about throughput (2) was sent from RPi to VNF. The video stream received by the server was analyzed to evaluate a set of QoE parameters using a dedicated software [3]. All these data were used to tune parameters of the video encoder.

The route covered during this test campaign is shown in Figure 22. In three periods (t = {[94.299,113.121),[176.861,191.831),[466.932,475.424)} the system detected a parking place  (Figure 18). This triggered a switch to a lower number of FPS (Figure 20) and to a higher video resolution (Figure 21). Because the vehicle stopped there for a moment, the throughput could increase (Figure 19) as the transmission became more fixed than mobile.

We can also notice that in three periods (t={286.692,404.302,451.812) the system lost the transmission (Tr.↓). It means that it could not recognize among the defined use cases and selected ‘unknown’ use case. It initiated the decrease of the number of FPS to save the channel capacity and in the same time the increase of the video resolution to provide better video quality in order to compensate from the lower FPS.

Conclusions

Results

Within CAVICO project we demonstrated how several techniques can be merged to provide a new class of services on the basis of partial results. We measured video QoE and network QoS to adjust video encoder in order to save transmission bandwidth or improve image fidelity depending on the transmission environment and user’s expectations. The CAVICO system uses client-server architecture to process video stream and adapt its encoding parameters to:

• use case determined automatically by the location,
• network throughput,
• quality of the video (Blockiness, Block loss and TA).

Tests proved that this concept meets assumptions. It is possible to control the video encoder in a feedback loop that takes into consideration a set of parameters related to different quality domains. Tests were done in:

• simulation environments for routes in Poznań,
• near real environment based on final components located in Aveiro where the camera did not move,
• real conditions in the vicinity of the campus of University of Aveiro.

It was possible to observe how video encoding parameters are modified by the control algorithm in the response to instant limitations of the wireless network or to needs correlated with the video visualization tailored to user’s requirements.