Multiple Flow Mobile Transfer
GHINI V., MESSINA A., PANZIERI F.
Department of Computer Science, University of Bologna, Bologna, Italy
({ghini | messina | panzieri}@cs.unibo.it)
Abstract
This paper introduces the design and preliminary experimental evaluation of a hardware and software infrastructure that enables the transfer of large log data files between a mobile “client” application, running in a system on board a train approaching a railway station, and a fixed “server” system possibly located in that station. This architecture is based on cheap, off-the-shelf hardware components implementing the IEEE 802.11g standard protocol for wireless communications, and guarantees that a data file of a up to 1 GB is delivered to its destination server in a short time interval (namely, less than 3 minutes), provided that the train speed be below 20 Km/h during the file transfer, and that the train be within the range of a 802.11g wireless communication network connected to the destination server.
Keywords: mobile data transfer, wireless communication, self configuring system
1. Introduction
Current high speed trains are equipped with a number of control devices that can generate a large amount of log data concerning the status of specific on board apparatuses. Typically, these data are stored in files homed in hard disks located on board the train itself. A train may travel for hundreds of kilometers and stop at several intermediate railway stations. By the time that train reaches its final destination, the log data files generated by its control devices may have reached a size of some GB. In general, when a train is at its final destination, a human operator downloads the log files and sends them to a control center. The control center examines the output of the different devices so as to detect symptoms of malfunctioning and schedule maintenance operations that can prevent possible failures. Unfortunately, scheduling these operations when the train has reached its final destination inhibits the possibility of anticipating the train maintenance, and may cause that the train be kept not operational for a time period longer than necessary.
The objective of our infrastructure is to anticipate the analysis of the log files by automatically uploading these files into their destination server as the train approaches an intermediate station, requiring no human intervention. The file transfer from the train to the server can be carried out based on wireless communication technology characterized by a short transmission range and a high data rate, such as the IEEE 802.11g [1] technology. This technology is automatically accessed as the train slows down to approach the intermediate station.
In this context, a crucial issue to be considered is the short time interval available for uploading the log file to a server located in the station. We estimate that, in practice, this time interval should not exceed 6 minutes, owing to the following motivations. When a train is close to an intermediate station, it reduces its speed. Typically, the train speed ranges between 10 and 20 km/h in the last kilometer before the train stops (which entails a 6 to 3 minutes travel time over a 1 km distance). Assuming that the train stops at the station for 3 minutes in order to allow passengers both to leave and to board the train, a 6 minutes (minimum) time interval is available for uploading the log file.
In order to speed up the log file upload in the server, our approach enables the upload application to use a number of wireless network adapters on board the train, and a number of access points in the station, in parallel. Thus, in essence, this application fragments the log file in multiple fragments that are transmitted to the server in parallel, and re-assembled before being delivered to this server.
To this end, each station where the log file upload is to be carried out can deploy a number of so-called Extended Service Sets (ESSs), as illustrated in Figure 1 below. Each ESS consists of a number of IEEE 802.11g Access Points (APs) transmitting over the same frequency channel. APs in different ESSs are configured so as to use different, non overlapping frequency channels in order to prevent that their home ESSs interfere with each other (e.g., the channels 1, 6 and 11 in Figure 1). Thus, for example, three APs, each belonging to a separate ESS, can be grouped to form what we have termed a Parallel Access Point (PAP) in Figure 1; a PAP enables communications on interference-free channels, simultaneously.
In the station, a server manages the authentication of the train wireless devices and collects the log file. The hardware communication system installed on the train consists of a number of IEEE802.11g wireless network adapters that matches the number of ESSs deployed in a station (at least). Thus, in Figure 1 for example, three wireless adapters are installed on board the train; i.e., one adapter for each ESS available in the station. As the train approaches the station and enters the transmission range of the ESSs in that station, each wireless adapter on board the train associates with an AP of a different ESS in that station. Hence, each wireless adapter can support interference-free communications with the AP with which it has associated. Finally, it is worth observing that, as the set of links the wireless adapters provide access to can be used simultaneously for uploading the log file, the file upload application will perceive an aggregated bandwidth made available by these links notably larger than that available on each single link.
Figure 1. Scenario in a railways Station.
This paper is structured as follows. In the next Section we introduce the hardware and software architecture we propose. In Section 3 we summarize the experimental results we have obtained from an initial (and incomplete) implementation of this architecture. Section 4 discusses some concluding remarks, and introduces are future research activity.
2. Material and methods
The system we have developed consists of two main component subsystems; namely, (i) a hardware subsystem and (ii) a software subsystem. These two subsystems are described in the following, in isolation.
2.1 The hardware subsystem
The hardware subsystem is depicted in Figure 2. This subsystem consists of:
1. the storage and authentication servers located at the station or elsewhere;
2. the Parallel wireless Access Points at the station; each PAP incorporates three APs that operate on different and nonoverlapping frequency channels;
3. a wired network that interconnects the servers and the parallel access points;
4. a mobile client, incorporating the file upload application mentioned earlier, with three wireless network adapters on board the train.
Figure 2. The hardware.
The above subsystem can be constructed out of off-the-shelf components; in particular, the PAPs can be obtained by assembling commercial IEEE 802.11g devices.
Since its first introduction in 1977, the wireless network standard 802.11, commonly termed WiFi, has been changed up to the definition in 2001 of the standard 802.11g; this standard supports a 54 Mbps maximum data transmission rate, in theory. The 802.11 standard allows 14 channels to overlap partially, as depicted in Figure 3; this channel overlap produces interferences and increases the error rate. The channels having indexes 1, 6 and 11 do not overlap; hence, they do not interfere with each other.
Figure 3. Channel distribution in the frequency space.
The standard can work in the followings two configurations:
l in presence of a base station (i.e., an AP) implementing the IEEE802.11g standard and possibly connected to a wired network through which all the communications flow. All the APs of a given ESS modulate a given channel frequency, and enable access to the mobile stations (MSs) that possess the required authentication credentials, only. An MS has to select (and associate with) an AP of the ESS before it can access the data transmission services of that ESS. This process can be performed actively or passively, and is referred to as scanning [2]. Specifically, an MS selects the AP emitting the strongest signal that MS receives, and for which it possesses the necessary authentication credentials, and associates with it; this association is maintained until the MS is powered off or the AP shuts down.
l in absence of an access point; in this case, different computers, in motion or stationary, can communicate directly among them as they are interconnected in a so-called “ad-hoc” network.
The standard 802.11g uses the modulation method OFDM (Orthogonal Frequency Division Multiplexing) of the earlier 802.11a standard, works in the restricted ISM (Industrial, Scientific, Medical) band at 2.4 GHz, as the earlier 802.11b standard [3], and covers a distance of 300 m outdoor, approximately.
The commercial products usually available and satisfying the standard 802.11g are characterized by acceptable reliability, average lifetime and low cost (obtained by avoiding the use of expensive technology such as the full duplex technology, for instance). The performance of the systems based on these products can change remarkably. Tests performed with stationary systems show a wide variation among different products of the same manufacturer; e.g., using different products from the same manufacturer, the time required to transmit 1 GB of data can range from 356 s up to 640 s. Needless to say, performance gets worse with motion.
The technical characteristics of the 802.11g standard [4, 5] show that the principal scope of this standard is to support device mobility, rather than the transfer of large data files among mobile devices. Thus, this standard may not be suitable for supporting such applications as the multimedia applications that require to transmit and manipulate large data objects. However, we believe that this standard can be conveniently used to support effectively the class of file upload applications mentioned earlier in this paper. In particular, components implementing this standard can be used to construct a reliable and low cost infrastructure such as that illustrated in the Figures 1 and 2 above. The software subsystem that can govern and exploit that infrastructure is discussed in the next Subsection.
2.2 The software subsystem
This subsystem supports client/server applications that implement file transfer from a mobile client to a fixed server. As depicted in Figure 4, a process named monitor at the client side manages the different wireless adapters; a high level application, the load_balancer, is responsible for transmitting the files to the server. The client side software implements the following 7 principal functionalities.
Figure 4. The software architecture at the client (the train) side.
1. Identification of the host network. Identification and selection of a set of preconfigured APs. This functionality is implemented by a modified wpa_supplicant application that monitors the state of the client side network interfaces. A periodic scanning of the transmission band detects the presence and the identity of possible new APs. When detected, a new AP is included in a list of active APs, and its data link interface is configured according to the required security.
2. Authentication. A new client is authenticated by means of one of the standard protocols (for instance, WEP, WPA, WPA2,...) implemented in the wpa_supplicant application mentioned above.
3. Interface configuration. This functionality entails the identification and dynamic configuration of the client network interfaces corresponding to each active AP. It is implemented by a modified DHCP client receiving information from a DHCP server on the same network as the client. Using this information, both the client network interfaces and the dynamic routing through these interfaces are configured.
4. TCP connection management. The establishment or re-establishment of one or more TCP connections between the mobile client and the server is responsibility of the high level load_balancer application. This application implements the transmission of the log file to the server via all the available wireless network adapters, and recovers from possible crashes of the TCP connections. In essence, the load_balancer application establishes a TCP connection with the destination server through each wireless adapter. At the beginning of the connection establishment phase, the load_balancer uses the bind() system call to assign the IP address of the chosen adapter to the local end point of that TCP connection. Thus, all IP datagrams belonging to that TCP connection have their IP adapter address as their source IP address. All IP datagrams belonging to a TCP connection are routed through the adapter to which that TCP connection is bound. In case repeated errors and timeout occur through an adapter, the AP associated to that adapter is assumed to be “not active”, and is no longer used.
5. Parallel Upload. The client-to-server upload is implemented by the load_balancer by distributing the data across the different open TCP connections, taking into account the quality of service (QoS) these connections deliver (e.g., data transfer rate, packet loss rate, status), which can change in time. The client data are maintained in a circular buffer until an acknowledgment from the server is received. The transmission capacity of the i interface (CTi) is evaluated calculating the data transfer rate of the data block transmitted through that interface. Before data transmission, this estimate is based on the time required to establish a TCP connection through the i interface. For each data block, the data block transmission time (TT) for each interface is calculated, and the interface with minimum TT selected. The TT of each interface i is obtained by summing the size, in bytes, of the data block to be transmitted to the number of bytes still present in the TCP socket buffer and not yet transmitted, and by dividing this sum by CTi. The timeout for the receipt of the acknowledgement is defined based on the CTi value. If this timeout expires, the connection is closed and the data are transmitted through a different interface. After an error or the closing of a connection, the system continues to try periodically the connection through the same interface. Finally, a mechanism based on the transmission of periodic “probe” messages through any interface, including those not in use, is implemented in order to detect possible connection problems.
6. Connection restoring. When a communication error is detected over a TCP connection, the load_balancer may restore that TCP connection and continue the data upload.