Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

The chapter deals with the QoS management in a relief communication network that enables interoperability among rescuers: different vehicles, including aerial ones, are operating in a disaster recovery scenario, and a multiplicity of services with rigorous requirements is required. Further, private and/or public communication infrastructures at the crisis site are compromised or completely out of order and, often, especially during the first beginning phases, the anarchy reigns over every rescue action due to the panic of the people. In such a scenario, the first help and the first actions can be more and more effective if detailed and organized information on the state of the sites involved in the event can be acquired in a short time and effectively distributed among the rescuers. At this end, an aerial vehicle flying over the area affected by disaster, can provide real-time transmission of data toward a Mobile Ground Station (MGS) that is located near this area and interconnected with several terrestrial communication networks. In this context, different access wireless technologies have to interoperate seamlessly to guarantee that each rescuer can perceive a given satisfactory quality of service. Such a challenging goal is typical also of the Next Generation Network (NGN) paradigm but in the considered scenario, it must be reached in a very hostile environment characterized by both time availability and preexistent infrastructures shortage.

As regards the public safety and the disaster response, an international partnership between ETSI and TIA, referred to as the MESA Project [1, 2], has defined globally applicable technical specifications for digital mobile broadband technology. In [3], it is presented a system architecture for the interoperability and integration among Private Mobile Radio (PMR) systems (TETRA), public communication networks (GSM/GPRS/UMTS), and broadband wireless technology (WiFi and WiMax), all operating in a Public Safety and Disaster Recovery scenario. In particular, in order to optimize the QoS management, the authors propose the use of appropriate mapping strategies among service classes supported by the different wireless systems involved in the integrated network architecture. This solution, however, requires the implementation of n!/[(n-2)! ⋅2!] mapping tables, where n is the number of different wireless access technologies. Moreover, the entry of a new access technology requires a rather complex procedure of upgrading since the implementation of other mapping tables among services class of the new technology and the preexisting ones must be performed. Finally, in [4], it has been proposed an interesting mobile ad-hoc satellite wireless mesh networking approach designed for an emergency scenario, in which the full mobility of rescue teams at the disaster site represents one of the major requirements for an emergency communication system. The combination of ad-hoc mobility together with IPv6 mobility mechanisms gives seamless mobility in the disaster site to rescue units. However, due to the satellite link, this solution is both very sensitive against weather conditions and very expensive for bandwidth usage.

In our proposal, the QoS provisioning in heterogeneous Relief Network (RN) is accomplished by resorting to both a specific DiffServ-based procedure and appropriate mapping strategies among DiffServ and the service classes supported by each wireless access technology. Such an approach allows one to benefit from the specific QoS management capabilities of each technology and to guarantee, at the same time, the scalability property against the number of access technologies involved in the whole network. To realize the proposed QoS Management Architecture (QMA), two steps are required:

  1. 1.

    Implementation of the DiffServ scheme for which we resort to usage and customization of Open-source Linux-based packages for the Advanced Routing and Traffic Control [5, 6]

  2. 2.

    Developing of software modules to implement mapping tables which are integrated with DiffServ scheme in order to accomplish a fully QMA.

It is worthwhile to underline that we used Commercial Off-the-Shelf (COTS) components to assure a low-cost solution for our QMA.

The chapter is organized as follows. In Sect. 2, the envisaged disaster recovery scenario is described and a RN architecture is presented. Section 3 is focused on the QoS-provisioning proposed architecture and its implementation. In Sect. 4, performance results are reported. In Sect. 5, conclusions are drawn.

2 Disaster Recovery Scenario and Relief System Architecture

Since a disaster occurs, relief vehicles move toward the crisis site and reaching the most critical areas of the disaster. It is a very useful support to get real-time information about the crisis site by means not only the satellite network but also by a properly equipped aircraft with camera and sensors. It flies over the area affected by disaster and transmits real-time video, images, and data to a mobile ground station, a vehicle located near the struck area. This station is a kind of headquarters that provides support both to local rescuers and remote public safety agencies, thanks to several types of wireless connections. Figure 1 depicts the envisaged disaster recovery scenario and the system architecture specifically designed for this scenario.

Fig. 1
figure 1_20figure 1_20

Disaster recovery scenario and relief system architecture

Full size image

The air-MGS link is based on IEEE 802.11 g wireless protocol and uses rugged Air and Ground Access Point (AAP and GAP). On aircraft, there is a laptop that runs a real-time video streaming server, Video LAN Client (VLC), and a VoIP softphone to allow on board operator to talk with the rescue units operating on ground in the injured area. In addition, some sensors, such as photogrammetric and infrared cameras, are installed to transmit images of struck area to FTP server located on MGS. These images are stored in FTP server and available for download by relief units located in far sites. On MGS, there is a rack server to provide VoIP, FTP, chat services (respectively Asterisk, FileZilla, FreeCS) to all rescue units involved in crisis management that require them. To provide conversational voice service to rescue units, it is utilized a LMR Gateway that links to existing LMR systems making critical adaptation of LMR audio and signalling to IP.

Finally, to accomplish QoS features according to our scheme, properly configured Linux Boxes have been adopted, named DiffServ Air Node (DAN) on aircraft and DiffServ Gateway Ground Node (DGGN) on MGS. More specifically, DAN has two LAN interfaces, one links to laptop, the other one links to AAP LAN interface. Similarly, DGGN, links from one side to GAP, through a LAN interface, and from the other side to MGS LAN that provides network connection to all IP devices. In addition, DGGN has specific interfaces to interconnect different access wireless technologies (Wi-Fi, WiMax, TETRA, 3GPP/HSDPA).

3 QoS-Provisioning Proposed Approach

Envisaged relief services such as VoIP, real-time streaming video, bulk and small data transfer via FTP, Telnet and remote control require different QoS treatments. In particular, VoIP is delay time, jitter and packet loss sensitive; real-time video streaming, instead, consumes a large amount of bandwidth but it is jitter tolerant and less sensitive than VoIP against the delay and packet loss. Finally, other envisaged relief services are based on TCP transport protocol, and therefore are more tolerant to packet loss, delay and jitter. In the literature, several methods have been proposed to provide quality of services control on IP networks. Such solutions are not, however, fully suitable whenever they must be adopted in a disaster recovery context. In particular, the DiffServ strategy, though it is a promising approach for its scalability and aggregation capabilities of traffic flows, does not fit well in this scenario of rescue because it doesn’t allow to exploit at best the native QoS capabilities and the characteristics of each wireless technology involved in RN. So, to achieve a certain degree of quality for these different relief services, prioritized packet scheduling over efficient DiffServ nodes and opportune QoS mapping strategies are required.

3.1 The Proposed QoS Management Architecture

The main goal of the proposed QMA is to provide an end-to-end QoS solution robust regardless the wireless technology that is being used to access the RN. Such a high level of support and transparency implies that strong and reliable integration methods have to be developed. The main design guidelines and merits of this architecture are outlined as follows:

  • the architecture must be modular, so that it is able to separate each specific communication technology, facilitating in this way the future integration of new wireless technologies into the RN;

  • the designed architecture must be enough flexible to allow the interworking of several access wireless technologies;

  • the proposed QoS scheme must exploit the well-known coarse-grained DiffServ strategy because it requires no signalling overhead, which is especially critical on the air-ground link and no signalling delay for path establishment, which makes it more efficient for short-lived flows. Morever, it is scalable because minimal state information is required at boundary DiffServ nodes (Air and Ground). Finally, it optimizes the QoS management via an adequate mapping between DiffServ classes and the specific classes of service supported by each wireless technology used in the RN; in this way, the QoS capabilities as well as the characteristics of every wireless technology are exploited at best;

  • the QoS scheme also supports the QoS in existing and common Public Safety LMR systems by means of a LMR Gateway specifically designed.

Figure 2 shows the proposed architecture.

Fig. 2
figure 2_20figure 2_20

QoS management architecture

Full size image

3.1.1 DiffServ Architecture in a Relief Network

The analysis of all application requirements has turned to be fundamental to design a fair mapping among envisaged relief services and DiffServ Classes. DiffServ nodes map the packet’s DSCP to a Per-Hop Behavior (PHB) [5], a forwarding procedure that a node performs on a packet. Both DiffServ Air and Ground Node should support the DSCP-to-PHB mapping. The PHB states how to treat the traffic belonging to an aggregate of flows at a node. In the chapter, two commonly used PHB, Expedited Forwarding (EF) and Assured Forwarding (AF) are focused. The EF aims to provide a service characterized by low delay, low jitter, low loss and assured bandwidth. In our QoS scheme, this PHB has been chosen for conversational voice service in order to provide the highest level of aggregate quality of service that is crucial in envisaged disaster recovery scenario. Thus, the arrival rate of EF packets must not exceed the service rate at the node interface, so as to satisfy the features of EF PHB. The AF defines four independent forwarding classes for packet delivery. Within each AF class, there are three kinds of drop precedence with each packet to determine the importance of the packet. For example, AF12 means high priority and middle drop precedence. AF11 and AF12 have the same priority. If the queue is full, packets marked with AF12 will be dropped first than AF11. In case of congestion, packets with high drop precedence are more likely to be discarded. In our QoS scheme, AF12 PHB has been chosen for the real-time streaming video application, a very interesting relief service that allow to know immediately the state of the sites damaged by disaster. AF11 PHB has been selected for telnet/SSH and remote data control service to adjust fundamental parameters of the applications from the MGS. Note that in the envisaged disaster recovery scenario, packets generated by such services have higher priority than the streaming video ones, since the control of the RN components on board is crucial. For the instant messaging and small data transfer/retrieval service, AF21 and AF22 PHB have been chosen, respectively. Finally, the packets of bulk data transfer/retrieval service can be forwarded in best effort mode since such services are not crucial operation for the first help and the first actions carried out after a catastrophic event. Table 1 summarizes the mapping between envisaged relief services and DSCPs, used in our QoS scheme.

Table 1 Mapping between envisaged relief services and DSCPs
Full size table

According to DiffServ architecture, Fig. 3 shows the packet treatment procedure in the DiffServ Nodes. When the packets enter into interface input, a classifier first differentiates the types of traffic. The generic flow of traffic is identified by destination IP address and port number of the incoming packets. In our system, the EF packets are sent to a queue, Queue 0, with strict priority to ensure their deliveries. The AF1-class packets are fed into a common queue, Queue 1, according to a strategy named RED (Random Early Detection) [7], which discards the packets with an increasing probability as the FIFO queue buffer fill up. This queuing strategy has been adopted because it allows a fair treatment of aggregates of TCP flows [7]. In particular, when the aggregate is constituted by several TCP flows, the RED algorithm is able to equally distribute the bandwidth among the single flows, even in presence of different rates of sources. This result is achieved by limiting the most aggressive flows by dropping their packets with a higher probability. This drop activates the flow control mechanisms of TCP giving rise to a source rate decreasing. RED strategy has been implemented also for AF2-class packets, which are fed into a common queue, Queue 2. For each queue filled with RED algorithm, the occupancy is evaluated by an exponential moving average.

Fig. 3
figure 3_20figure 3_20

Packet treatment in DiffServ nodes

Full size image

The computed occupancy value, say Avr, is compared with two thresholds, say MinThres and MaxThres. When a new packet arrives and Avr < MinThres the packet is accepted. If MinThres < Avr < MaxThres the packet is discarded with a probability p a , function of avg. If Avr > MaxThres the packet is discarded.

The strict priority scheduler accepts the inputs from Queue 0 and Weighted Round Robin scheduler (WRR). The EF traffic has the highest priority in the priority scheduler. In here, a kind of WRR scheduler called Hierarchical Token Bucket (HTB) is utilized. HTBs help in controlling the use of the outbound bandwidth on a given link. Since the maximum achievable throughput of the 802.11 g air-ground wireless link is approximately 27 Mbps [8], HTB queuing discipline for link sharing has been implemented to assure that the AF1 traffic aggregate occupies the max bandwidth of 2 Mbps and the AF2 traffic aggregate occupies the max bandwidth of 24 Mbps.

3.1.2 QoS Manager

The relief communications in a disaster recovery scenario occur in a highly heterogeneous environment where rescuers, employing different access technologies, can effectively communicate with each other. In this perspective, the data flows have to be adapted to the change of surrounding conditions. The ultimate goal is to render the RN seamless, namely, the proposed solution must assure the full interoperability of all the available technologies and guarantee, at the same time, that each rescuer perceives a given quality of service which depends on the access technology that he utilizes. More specifically, we propose to resort to mapping strategies among DiffServ and the service classes supported by the different systems involved in the integrated RN to benefit of specific QoS management of each wireless access technology by preserving their native QoS capabilities. Figure 4 depicts the functions that the QoS manager has to provide.

Fig. 4
figure 4_20figure 4_20

QoS manager

Full size image

Specifically, the incoming aggregate flow from DiffServ ground node is processed by the Class Selector, which extracts the EF packets related to voice service, AF21 packets related to instant messaging service and the packets related to all remaining relief services. The first ones are sent to a VoIP server, Asterisk-based or similar, which allows the intercommunication of different rescuers, including on board operator. The second ones are sent to a chat server, like FreeCS, which allows every rescuer to chat with each other, regardless its location. The remaining packets, related to all others relief services, are sent to input of the N-plicator Module (NM) that provides N copies of them at output. Then each copy is sent to QoS Management Module (QMM) input implemented for each of the N wireless technology used in integrated RN. QMM consists of two modules: User Application Filter (UAF) and QoS Mapper (QM). The former selects the applications that are really utilized by each specific rescue team, consistent with the used access technology. The latter deals with the mapping between DiffServ and service classes supported by the specific wireless technology. In particular, for each wireless technology used in the RN, it has been identified the QoS class that best fits the DiffServ EF class. In the same way, we proceeded to define the mapping of DiffServ AF classes. Table 2 summarizes the results of such an analysis: for any DiffServ class has been reported the corresponding QoS class of each specific technology used in the RN. Note that, unlike [3] where the addition of a new access technology to the existing n ones requires the software implementation of other n new mapping tables, in our QMA proposal the inclusion of a new access technology only requires to introduce a further column in the aforementioned mapping table, namely, only one mapping module has to be implemented among DiffServ and service classes, which are supported by the added access technology.

Table 2 Mappings table
Full size table

3.1.3 QoS Software Implementation on Linux DiffServ Nodes

The QoS management strategy has been implemented on Linux platform for both DAN e DGGN. QoS modules are already present in Linux kernels of version 2.4 and later ones. It has been needed to add the modules for DiffServ and implement new ones to support mapping with other wireless communication technologies involved in disaster recovery scenario. Finally, Linux kernel has been recompiled on DiffServ Nodes. The implementation on a DiffServ Node provides a full set of Traffic Conditioning Modules (TCM) that include a marker, a classifier, a scheduler, service handlers for EF and AF and several queuing disciplines such as token bucket filters, FIFO and RED queues. All traffic conditioners have been implemented as kernel modules that can be activated by the tc command, which is part of the iproute package [9]. The TCM, used in our implementation, are outlined as follows. The Service Handler is the marking module of the implementation. It compares all incoming packets to the flows held in its table and writes the according DSCP into the IP header. Since this module has no metering functionality, the dropping probabilities of AF packets are set by the Precedence Handler module (PHM). The Dsclsfr module is a combination of a Behavior Aggregate (BA) classifier and a scheduler. The classification procedure is executed when enqueuing a packet and forward the packets according to their DSCPs to one of seven traffic conditioners. Those conditioners are intended to handle the two AF classes and EF traffic considered. The scheduling performed by the de-queue function is a combination of priority scheduling used only by EF and WRR fair queuing implemented for AFs. The weights of the algorithm are configurable and can be specified via the command line. The PHM is a color-aware two-rate three color marker [10]. The AF-PHB defines four independent service classes, each operating at three levels of dropping probability. In our scheme, we considered only two AF classes. Traffic below the negotiated bandwidth limit has the lowest probability of being dropped (“is marked green”). A packet is marked “yellow” (to a higher dropping probability), if it does not exceed a certain exceed bandwidth. All other traffic is marked “red.” The PHM specifies the color-part of the AF-DSCP, while preserving the color of already marked incoming packets. As shown in the QMA, to assure the mapping provisioning between DiffServ and different wireless communications technologies exploited in RN, some novel module and script have been added in the DGGN based on Linux PC. In particular, for each access technology, a specific QMM has been implemented. The basic structure of each module is common to all; it is composed of two parts, which allow both the achievement of QoS requirements (expected by each RN user) and the QoS mapping.

4 Performance Results

The effectiveness of the proposed QoS management solution has been investigated through a testing campaign. More specifically, it has been set up as a testbed based on the Wideband Radio Channel Emulator made by Elektrobit, named PropsimC2. Figure 5 depicts the testbed architecture.

Fig. 5
figure 5_20figure 5_20

Testbed architecture

Full size image

Radio Frequency (RF) input of the PropsimC2 links to AAP RF output by a low-loss RF cable. AAP links to DAN by the first FastEthernet (FE) interface. The second FE interface of DAN links to server that runs VLC, FTP applications. RF output of the PropsimC2 links to GAP RF input by a low-loss RF cable. GAP links to DGGN by the FE interface. Finally, a laptop links to DGGN by 802.11 g interface configured in ad-hoc mode. The testing sessions have been performed by sending video TCP streaming, audio UDP streaming, and FTP bulk data on different ports in order to verify the different treatment operated on different classes of traffic. Through the HTB qdisc implemented in the our COTS Linux boxes (DAN and DGGN, respectively), two classes are created and the maximum rate, which each class can consume, has been set to assure that the AF1 traffic aggregate occupies the max bandwidth of 2 Mbps and the AF2 traffic aggregate occupies the max bandwidth of 24 Mbps. For the EF traffic, instead, has been set the highest priority in the priority scheduler in order to preserve the conversational voice flow in each condition. Tests have shown that the differentiated treatment of traffic works correctly; in particular, the conversational voice flow is guaranteed in each condition. The bit-rate of FTP bulk data download decreases when the channel conditions become poorer. In these conditions, FTP packets (belonging to AF23 class) are dropped, while the video steaming continues to be of good quality. If the channel conditions get worse further, it has been verified that the perceived video quality gets worse (frames with some blocks appear) while the perceived audio quality is still good. Finally, the carried out tests confirm that the QoS mapping implemented among DiffServ and 802.11 service classes works correctly.

Performance analysis are currently under study and, before the FALCO project deadline [11] which is at the end of November 2009, results in terms of delay, jitter, packet loss and throughput will be available.

5 Conclusions

This chapter deals with the inter-vehicle communication QoS management in a very hostile scenario, which is a disaster recovery. To assure that each rescuer can perceive a given satisfactory quality of service QoS regardless the used wireless technology for the access to the network a modular architecture that resorts to a DiffServ scheme is proposed. The proposed QMA not only provides seamless QoS support over different wireless technologies for the access network but exhibits a scalability property against the entry of any new access technology since the new entry can be managed just adding a new specific QMM without requiring the upgrading of the ones already present in the system. A testbed has been designed and performance evaluations are currently on the way and will be available for the project deadline.