The multi-link system that we used can be roughly separated into three main com- ponents: (1) the multi-link framework, which we call MULTI [81, 77], (2) the adap- tive HTTP streaming client, and (3) the network and bandwidth lookup service. The MULTI framework is described in subsection 6.2.1 and the adaptive streaming client in sections 4.5 and 5.3. The network and bandwidth lookup service is de- scribed in section 5.3, but some additions for multi-network support are described in section 6.2.2. Figure 6.2 shows how these components interact, and also gives a high-level overview of how transparent roaming was implemented through the MULTI framework.
Figure 6.2: Overview of the MULTI framework for implementing transparent multi-link networking. Each colored box can represent a different machine in the network, but it is also possible to run the proxy, lookup and content servers on the same machine.
6.2.1
MULTI: A Transparent Framework for Multi-Link
Streaming
The MULTI component simultaneously monitors and configures the network in- terfaces, updates routing tables, and enables multiple links. Here we only briefly outline the MULTI system, as we are only using MULTI to test the multi-link per-
Figure 6.3: An example of multi-link streaming with transparent roaming. This differs from figure 6.1 in that the MULTI proxy (depicted as the yellow box in figure 6.2) shields the video server from having to manage multiple links per receiver. This is necessary to be able to seamlessly migrate connections in the middle of a file download without special logic in the web server.
formance of our streaming system. The implementation of MULTI is outside the scope of this dissertation; for the full description, see [81, 77].
The MULTI framework consists of several submodules, as shown in figure 6.2. Application transparency on the client side is achieved through the use of a local virtual network interface through which all video data is routed. The media player application sees only the virtual network interface, and can thus benefit from multi- link technology without being affected by its complexity.
To achieve transparency on the video server side, a proxy server is needed to hide the complexity of the video receiver’s multiple links (see figure 6.3). Thus, the MULTI framework also includes components that should run outside the client, on a separate proxy server. This proxy server will be a middle-man between the mobile video receiver and the video content server. It can run on its own machine, on the same machine that hosts the video content, or be installed on the client itself. The proxy server transforms the receiver’s multiple links into a single link with which the content server interacts.
6.2.2
Location-Based Network and Bandwidth Lookup for
Multi-Link Streaming
The data points representing the expected throughput at different geographical lo- cations are, as described in section 5.3, collected by the users of the video service, and the network information is stored in a database with standardized Geographic Information System (GIS) extensions for handling location-based calculations. The database used in our first prototype is PostgreSQL [31] using the PostGIS exten- sions [30].
All the information about the network and the performance from one measure- ment at a given time is stored as a single record in the database. This record in- cludes network ID, time, GPS coordinates and observed performance metrics like bandwidth, round-trip time and packet loss rate (round-trip time and packet loss
rate is only used by MULTI, not the quality scheduling system described in 5.3). Figure 6.4(b) shows an example bandwidth trace where we differentiate between different networks (3G and WLAN in this example). With such a database, appli- cations can use PostGIS queries that return historical bandwidth measurements based on location, network type, and age of the data points, as shown in the follow- ing PostGIS query example:
SELECT network_id, AVG(bandwidth) FROM table_observed_performance
WHERE query_gps = gps AND time < 10-days-old GROUPBY network_id
This returns the predicted average bandwidth for all available networks at a given GPS location based on measurements from the last 10 days. While the above infor- mation is sufficient if a user moves arbitrarily around, users often follows a given path, particularly when commuting (our scenario), which we have shown (chapter 5) can be used to perform long-term bandwidth availability prediction. Our database therefore defines a table for known paths, such as well-known commute routes in Oslo, returning a list of GPS coordinates and the respective time spent at given lo- cations (for example within the vicinity of a GPS-coordinate or at a station). Using PostGIS queries, like the one shown above, for multiple points along the expected path, the media downloader can calculate the predicted amount of data that can be downloaded. As in chapter 5, it uses this information to fill gaps in the stream that are caused by expected network outages, and it can do long-term planning of quality adaptation for a more stable video quality.
Information about the network provider of a given network ID is kept in a sepa- rate table, and can be used to look up other relevant data such as pricing. Although this parameter is not taken into consideration by our prototype, it could be added to enable users to optimize for metrics like monetary bandwidth cost, rather than performance.
6.2.3
Video Streaming and Quality Scheduling
Our video streaming and quality scheduling component is the same as that de- scribed in chapter 5, except that the bandwidth prediction data in the lookup ser- vice now contains an extra field that identifies the network that was used for each bandwidth sample.
Connection handover and link selection is currently performed transparently by the roaming client and proxy. It can happen that the client is forced to choose an- other network than the one with the highest average bandwidth (which the quality scheduler assumed we would use in its prediction). For example, this could happen if the best network is WLAN, but the network password has changed, preventing
the connection from succeeding. If something this happens, it means that the pre- diction will be too optimistic, and the reactive quality scheduler will have to rescue the predictive scheduler from buffer underrun (see the description of the hybrid re- active/predictive scheduler in subsection 5.3.4), in effect making the video quality fluctuate more rapidly than it should. This state is however corrected rapidly by telling the quality scheduler that we are using a slower network than predicted, and that the prediction must be recalculated with this in mind.