Intrusion tolerant QoS provision in mobile multihop relay networks

2.1 IEEE 802.16j specifications regarding QoS, handover and path management

An MMR network encompasses fixed multihop relay base stations (MR-BSs), fixed or mobile relay stations (RSs) managed by the network operator and mobile subscriber stations (SSs) moving at vehicular speed. The wireless link between the SS and the managing MR-BS or RS and the wireless link between the MR-BS or RS and a subordinate RS during network entry are both called “access links” while the wireless link between a MR-BS and a RS or between two RSs is called “relay link” as depicted by Figure 1. Access and relay links can be either uplinks or downlinks. The IEEE 802.16j amendments specify that a dynamic service addition request (DSA-REQ) signalling message is used for admission control and path management in the context of multihop relays with scheduling RSs, [1]. The DSA-REQ can only be sent over relay links from the MR-BS or the RS to its subordinate RS. Generally speaking, a MR-BS sends a DSA-REQ to all RSs on the path to request an admission control decision. That request is processed by each RS on the path and forwarded to its subordinate RS. The DSA-REQ encompasses the service flow parameters described by Type/Length/Value (TLVs) fields. A RS sends a DSA-RSP message to the MR-BS when it can not accept the service flow indicated in the DSA-REQ or in order to confirm the path management operation requested in the correspondent DSA-REQ. On the other hand, the MR-BS should send a DSA-ACK to all RSs on the path upon receiving a DSA-RSP from an access RS for the purpose of admission control. Each intermediate RS processes the DSA-ACK and forwards it to its subordinate RS. The IEEE 802.16j amendments also define the dynamic service change request (DSC-REQ) signalling message which is used for admission control and path management whenever a dynamic change of the parameters of an existing service flow is required.

Routing in wireless multihop relay networks is tree-based. In order to address path establishment, maintenance and release, the IEEE 802.16j amendments propose to base routing decisions on metrics such as radio resource availability, radio link quality and traffic load at the RSs and propose to take these decisions at the MR-BS level based on information provided by the RSs, [1]. However, the amendments do not specify how the decisions should be made, [10]. Besides, the standard proposes two approaches to path management namely the embedded path management approach and the explicit path management approach.

The embedded path management approach allocates the connection identifiers (CIDs) in a hierarchical manner. More precisely, the MR-BS allocates CIDs to its subordinate stations so that the CIDs allocated to all subordinate RSs of any station are a subset of the allocated CIDs for that station. Consequently, the path management is simplified because there is no need to store specific routing tables at the RS level and there is a reduced need for signaling to update the path information. On the other hand, the explicit path management approach uses an end-to-end signaling mechanism in order to distribute the routing table along the path. In more details, each path is identified by a path ID to which the CIDs are bound. The MR-BS needs to send the required information to the RSs belonging to the concerned path whenever it is created, updated or removed. Optionally, the MR-BS may specify the QoS requirements associated with each CID in order to enable the RSs to take the scheduling decision independently in case of distributed scheduling mode. The explicit path management approach needs small routing tables at the RSs and enables a reduction of the overhead required to update these tables, [10].

Authors of [7] propose a path selection method for the non-transparent mode of IEEE 802.16j networks that finds the lowest latency and the best path with high throughput. The proposed method uses metrics such as link available bandwidth, signal-to-noise ratio (SNR) and hop count in order to determine the path cost. The desirable path should then balance the load with other paths fairly by favoring smaller hops and less robust channel coding schemes. Authors of [7] suggest an example network model for applying the proposed method and prove its effectiveness. Nevertheless, the proposed method does not consider the security and may suffer from numerous attacks such as DoS.

Regarding handover, when a mobile RS hands over, all the SSs attached to it should also hand over with it. Besides, the RS-BS can exchange context info on the backbone in order to accelerate the handover process.

2.2 Intrusion tolerance in wireless networking

The fault tolerance concept was firstly introduced in the field of software engineering, [3, 11]. Its aim was to preserve the delivery of correct service despite the presence of active faults, [3]. Fault tolerance is fulfilled through the error detection and then the subsequent system recovery. The malicious and accidental fault tolerance for internet applications (MAFTIA) project involved experts from five countries and six organizations and lasted from January 2000 to February 2003 in order to investigate the tolerance paradigm for security, [12]. In more details, the MAFTIA project proposed an integrated distributed architecture based on intrusion tolerant systems and designed the required mechanisms and protocols to form the building blocks of large scale dependable applications. The MAFTIA project main results were the provision of a dependable middelware, dependable trusted third parties, distributed authorization mechanisms and large scale Intrusion Detection Systems. Note that the trusted timely computing base (TTCB) components were part of the proposed architecture.

Most of the research works that are interested in providing intrusion tolerance for wireless networks are targeting wireless sensor networks. For instance, Ma et al. [13] propose a fault-intrusion tolerant framework called WSN-TUM that incorporates both conventional non-security fault and intrusion fault management in order to ensure fault-intrusion tolerant routing. In more details, the WSN-TUM identifies four types of faults that can target WSNs which are hardware faults, software faults, middelware faults, and intrusion faults and then adopts multi-path, multi-version and fragmentation techniques in order to fulfill the intrusion tolerance property. Ma et al. [13] assume that there exists a routing protocol that has already established multiple paths before the data transmission and that the base station and the sensor nodes have pre-built cryptographic algorithms and pre-distributed keys to generate the session keys before the deployment of WSN. They indicate that at the sending node level, each data packet should be split into N fragments and then reorganized into M groups where M is the number of cryptographic algorithms supported by the sending node. Each group is then encrypted with a different encryption algorithm, [13]. Each packet of the N encrypted fragments is encoded into N + K fragments using the forward error correction (FEC) erasure coding before transmission. The obtained fragments are finally transmitted to the destination using multiple disjoint paths. After the reception of more than N encrypted fragments and their authentication and integrity checking, the receiving node reconstructs the encrypted data packet. The combination of data fragmentation over multiple paths combined with the multi-version encryption minimizes the chances of an attacker to get the complete data at one time, [13].

The scheme proposed in [13] can not be adopted for multihop relay networks as the routing architecture is a tree where each RS has only one superordinate. More precisely, it is not possible to transmit the packets of one flow on different disjoint routes because there exists only one branch (i.e., route) from the sending RS to the MR-BS. Another shortcoming of this protocol is that all the sensor nodes are involved in securing the transmission; this means that the base station has not to make an extra effort for guaranteeing security even if it is more powerful in terms of processing capabilities and power. Besides, this scheme makes it hard to ensure global QoS since fragments of the same packet will use different routes with different QoS capabilities and the destination needs to wait for getting the fragments; which may induce additional delays.

Tang et al. [14] designed two routing protocols that minimize the number of hops between a source node and a destination node while maximizing the lifetime of sensor networks. Besides, they considered security challenges targeting the wireless sensor networks and proposed a secure routing protocol called SecMLR which works in an energy-efficient way in order to resist potential attacks, [14]. In more detail, the adopted architecture combines wireless sensor networks and mesh networks by deploying mesh routers within the monitoring areas (i.e., sensor networks) and mesh gateways in order to transmit the sensed data in long-distance and reliable fashion. The mesh gateways play the role of sink nodes, routers and gateways.

In order to optimize the performance of the routing service in the hybrid architecture, [14] proposed two routing protocols called shortest path routing (SPR) and maximal network lifetime routing (MLR) and then tried to secure the last one. The SPR protocol minimizes the number of hops of data transmission between each sensor node and a gateway; thus minimizing the total hops of a sensor network. However, the MLR protocol maximizes the network lifetime (i.e., the time when the first sensor node drains its energy) by minimizing the total energy consumption of all sensors in the network while minimizing the differences between individual nodes energy consumption and average energy consumption. Securing the MLR protocol by different measures gives birth to the secure maximal network lifetime routing (SecMLR). A node that needs to send data but does not have set up a routing table broadcasts a routing query to m destinations. When a node receives the request for the first time, it broadcasts the message after appending itself in the path field. Duplicate requests are not re-broadcasted. When a gateway receives a routing query packet, it verifies the authenticity of the sender and verifies whether the message is replayed by a malicious node by checking a counter value. After that, the gateway waits for a timeout in order to collect multiple path information and then calculates the shortest path between the source and the destination using a particular formula, [14]. Finally, a routing response is given back to the source. The gateways need to broadcast their new places using the μ Tesla protocol, [15], in order to achieve authenticated broadcast.

The fault or intrusion tolerance is simply achieved by setting up routing tables with multiple entries ending to specified gateways so that data which failed to reach the destination using a particular route may choose a different path. This scheme can be adopted for multihop relay networks only on the backbone between the neighboring intermediate BSs (i.e., from the sender MR-BS to the destination MR-BS). In more detail, the route from the sending RS to its MR-BS and the route between the destination MR-BS and its managed destination RS are already known and fixed (i.e., branches of one tree). Therefore, we do not have to choose from different paths. Besides, this scheme was designed in order to save the energy of the sensing nodes adopting it. In multihop relay networks, the MR-BSs which are the unique entities able to adopt this scheme do not have energy constraints. Last but not least, authors of [14] did not consider particular QoS constraints in terms of delay, jitter or throughput in their proposed secure routing protocol. Therefore, applying this scheme for multihop relay networks will not provide us with the required QoS guarantees.

To the best of authors’ knowledge, there is presently no research work that addresses the issue of intrusion tolerance within relay networks. This is mainly due to the fact that the proposed intrusion tolerance solutions for ad hoc, sensor or mesh networks can not be applied to the relay context without introducing some modifications induced by the particularities of the relaying concept. More precisely, the network topology of the multihop relay is a tree rooted at the MR-BS which differs from the mesh topology of ad hoc, sensor or mesh networks. Second, the Multihop Relay mode is simpler than the ad hoc or mesh mode as mobile nodes within a relay network just enjoy the connection while all the processing regarding the relaying activity is transferred at the Relay Station level. Moreover, the relay mode is intended to be more stable than the ad hoc, sensor or mesh ones because the MR nodes relaying traffic and signalling have more computing and power capabilities and are managed by the network operator.

2.3 Requirements for an efficient QoS provision over MMR networks

The IEEE 802.16j amendments introduce multiple concepts related to QoS provision such as service flow QoS scheduling, dynamic service establishment and two-phase activation model, [1]. Five data delivery services are defined which are the unsolicited grant service (UGS), the real-time variable-rate service (RT-VR), the non-real-time variable-rate service (NRT-VR), the best effort service (BE) and the Extended real-time variable-rate service (ERT-VR). These services support real-time applications generating fixed and variable data rates along with applications requiring a guaranteed data rate while being insensitive to delays and applications with no rate or delay requirements. Nevertheless, the IEEE 802.16j amendments do not indicate how to implement such services. Although the amendments identify QoS parameters such as maximum latency, tolerated jitter, minimum reserved traffic rate, maximum sustained traffic rate and traffic priority that implement the provided services, the choice of a specific algorithm or procedure that implements the QoS provision and optimizes it is left to the network operators, [1].

Besides, the IEEE 802.16j amendments define signalling messages that are used when discovering routes with a predefined QoS level but do not specify an algorithm that manages the routes establishment and maintenance in case of a handover while providing the required QoS level. Therefore, specific call admission control (CAC) algorithms and route maintenance in case of mobility algorithms should be defined by the network operators with regard to their specific needs. Meanwhile, the IEEE 802.16j amendments do not indicate particular procedures that enable the QoS estimation over the links. For instance, it is not indicated how to evaluate the delay or the throughput value over a wireless link. Besides, it is not indicated how to verify the pretended QoS values over the wireless links.

If security is considered as an additional QoS parameter, the IEEE 802.16j amendments do not specify particular procedures that enable the detection of potential attacks conducted by malicious SSs and probably malicious RSs. Therefore, a successful timely-based attack or denial of service (DoS) or distributed DoS (DDoS) attack against the MMR network may degrade the QoS requested by legitimate customers and impair the corporate image of the network operator.

In order to achieve an efficient QoS provision, the MMR networks should implement efficient algorithms for CAC that enlighten the choice of the best routes affording the required QoS level. Besides, specific procedures should enable the route maintenance in case of RSs or SSs mobility so that the customers can enjoy ubiquitous services with nearly the same QoS level despite their high mobility. Last but not least, the MMR network should be intrusion tolerant in order to continue providing the agreed QoS level despite intrusions. In more detail, an intrusion tolerant MMR network will enhance the QoS provision through using specific ways to detect potential intrusions and efficiently reacting to them without dramatically altering the QoS level agreed with the customer.

3.1 3TCA definition

The 3TCA architecture is formed by the interconnection of trusted software components called 3TCA components (3TCACs). The 3TCACs are implemented on the access nodes which are the RSs and the MR-BSs and form a backbone allowing fast and protected communication between its nodes. The interconnection of 3TCACs within the relay network gives birth to a distributed component that provides trusted time-related and secure-related services along with an intrusion-related service that guarantee intrusion detection and tolerance to a set of attacks. Meanwhile, the 3TCACs provide QoS compensation in order to minimize the negative impact of handover and possible attacks on the provided QoS. The interconnection of 3TCACs is assumed to be accomplished via a completely secure wireless channel that implements cryptographic tunnels as illustrated by Figure 2.

The 3TCA architecture also defines 3TCA Entities (3TCAEs) which are application-level entities that reside over the Operating System and communicate via insecure wireless channels. 3TCAEs may be attacked and behave maliciously. The 3TCAEs use the trusted services of the 3TCACs in order to participate in the 3TCA’ protocols implementation within an intrusion-tolerant environment.

Thanks to the 3TCACs, the 3TCA architecture enables the provision of trusted services and the correct implementation of the 3TCA protocols despite the probably malicious behavior of the 3TCAEs and the attacks that may target the wireless insecure channel. Since all the 3TCACs are synchronous while 3TCAEs are asynchronous and since all 3TCACs are assumed to be secure while 3TCAEs may be malicious, we conclude that the 3TCA architecture provides a hybrid intrusion-controlled environment with distributed trusted components. The 3TCACs implement the necessary validations and verifications to provide trusted values of QoS, detect the possibly malicious behaviors and most importantly compensate the negative impacts of group mobility and some time-related and DoS attacks.

3.2 3TCA services

The 3TCA services are provided by the trusted 3TCACs and may be summarized as follows:

3.3 3TCA compensation

The 3TCA architecture provides QoS compensation for handing over RSs by accelerating the affected flows. More precisely, once the duration of the handover process is computed by the 3TCACs, the QoS of the affected flows is revised through decreasing the delay values and optionally decreasing the jitter values and increasing the bandwidth by adopting either a linear approach or an exponential approach. A new CAC is processed with the updated QoS values on chosen links in order to rapidly find a suitable route.

On the other hand, malicious RSs may try various time-related and DoS attacks. Unfortunately, isolating such malicious actors will dramatically decrease the coverage area since the relay topology is a tree and the isolation of one RS may doom a whole branch. To address this issue, the MR-BS managing the malicious RS will calculate the delay and/or jitter induced by its presence and then it will compensate it according to the load of the involved links. The compensation is fulfilled through executing a new CAC with updated values of delay, jitter and throughput. Note that the MR-BS may send a different signalling message containing different delay, throughput or jitter values in order to individually perform admission control on the links forming the path to the destination as each link may have a different load condition. However, the MR-BS will choose the values for CAC so that the end-to-end QoS requirements are met even if each link on the path may provide a different QoS.

The trusted timely computing base (TTCB) is a software component which has been developed in the malicious and accidental fault tolerance for internet applications (MAFTIA) project. The main goal of the MAFTIA project is to construct dependable trustworthy applications implemented by a set of distributed components with varying degrees of trustworthiness, [3]. The TTCB module can be viewed as a secure real-time distributed component that guarantees trusted services related to time and security such as the trusted block agreement, the trusted duration measurement, and the trusted absolute timestamping, [16]. In an Internet architecture, each host has a local module called the local TTCB. These modules are interconnected by the secure control channel and form the distributed trusted component (DTC). The TTCB assists the applications running between participants in the concerned hosts which are interconnected by a vulnerable Payload Channel and form the payload system subject to arbitrary byzantine failures. Nevertheless, the TTCB modules do not handle threshold values in order to detect malicious behavior and react in time. Moreover, the TTCB modules were not programmed to perform QoS compensation.

3.4 3TCA detailed description

The 3TCA architecture is a novel architecture designed for MMR networks which provides QoS and intrusion-tolerance despite group mobility and probable attacks that may target the access nodes (i.e., RSs and MR-BSs). This architecture is based on trusted 3TCACs which offer time-related, security-related and intrusion-related services in order to form a secure communication environment with QoS guarantees. QoS provision is achieved first through securely estimating the QoS parameters using the trusted 3TCACs services and second through compensating the negative impact of handover and a set of attacks on the previously agreed QoS level. The TTCB component defined in the frame of the MAFTIA project lacks threshold management and compensation processing and offers useless services (i.e., such as trusted agreement) for the relay context; therefore, it needs to be revised in order to be adopted within the 3TCA architecture.

The 3TCACs are enriched with tables and matrices describing the network entities so that they become able to control their behavior. Besides, some threshold variables were included so that the 3TCAC component can decide whether an entity is malicious. Furthermore, we made the 3TCAC component the sole entity that creates the control messages, signs or encrypt them (i.e., sender’s 3TCAC) and then verify and process them (i.e., receiver’s 3TCAC). Last but not least, we used the time related services to make the 3TCAC component detect timely-based attacks and compensate the impact of both handover and malicious behaviors.

Moreover, the 3TCACs have been enhanced in order to provide intrusion tolerance for multihop relay networks while respecting the QoS constraints. Even if malicious entities try various attacks, their potential damage will be limited since routing actions will be globally processed and secured by the 3TCACs while a timed behavior is supported to provide QoS guarantees. The 3TCACs are deployed on each RS and MR-BS. Each 3TCAC is equipped with a matrix encompassing the registered SSs and subordinate RSs along with the QoS and intrusion information related to them. The signalling messages are created and processed by the 3TCACs in order to validate the contained information and detect the entities trying to compromise the integrity or the identity of the issuer.

We also defined threshold values for delay and jitter that may be dynamically updated in order to detect the entities that refuse to participate in the QoS routing process through pretending higher delay and jitter values. The p r o b a b l y-m a l i c i o u s-R S variable is incremented each time the 3TCAC notices an infraction. When the p r o b a b l y-m a l i c i o u s-R S value reaches a pre-configured threshold, a p r o b a b l y-m a l i c i o u s-R S-A l e r t message is forwarded until the MR-BS. Upon receiving that alert, the 3TCAC of the MR-BS will try to compensate the QoS disturbance caused by the malicious behavior through updating the QoS values on some chosen links.

Furthermore, the 3TCACs which are synchronized will raise an infraction if they do not receive the signalling messages within a pre-configured threshold period. In this case, they will increment the p r o b a b l y-m a l i c i o u s-R S variable and send a p r o b a b l y-m a l i c i o u s-R S-A l e r t message when required. Multiple colluding SSs may decide to generate simultaneous requests to cause a distributed DoS to the managing RS. To address this issue, the 3TCAC kernels will be configured to not process more than a threshold value of requests sent by the same SS within a period of time and to not process more than n requests or QoS estimations overall.

4.1 Network modeling

The multihop relay networks are organized in a tree topology and define the RS stations which relay the traffic of N-LoS SSs to the MR-BSs. MR-BSs manage the subscribers of their coverage areas and enable the communication with external networks. The assumed multihop relay network depicted in Figure 3 accommodates three kinds of nodes. The relay stations may be fixed or mobile. The RSs and the MR-BSs host 3TCACs while SSs do not. The hosted 3TCACs will be respectively called RS_3TCAC and BS_3TCAC. Non Line of Sight SSs (NLoS SSs) connect to the MR-BSs through the RSs. However Line of Sight SSs (LoS SSs) may directly be managed by MR-BSs. Viewed by a NLoS SS, the network topology is tree-rooted at the MR-BS where a branch is formed by intermediate RSs. We also assume that a mobile RS (i.e., always found in trains and other transportation systems) can only be a superordinate access station for the passengers’ SSs moving with the vehicle and that it can only have fixed RSs as superordinates. We argue that having mobile RSs as superordinates for non-passengers’ SSs wastes time and resources as the mobile superordinate may move away from its subordinate either during the management phase (i.e., network entry, path establishment, etc) or during the data transfer phase. In this case, the managed subordinate should reprocess the management procedure or wait until a new path is found. Therefore, we always consider a fixed network backbone while the mobile RSs will only manage mobile SSs that are moving with them.

4.2 QoS provision within the multihop relay networks

We design an architecture called 3TCA that provides QoS in a trusted way. Mobility will be particularly addressed in order to compensate the delays induced by handing over RSs. Besides, timely-based attacks will be tolerated while respecting the particularities of the multihop relay networks.

4.2.3 QoS estimation

In this section, we detail the procedures adopted in order to estimate the QoS parameters in a reliable manner using the 3TCAC modules. We also overview the mechanisms that will be used to fulfill handover disturbance compensation.

If a sequence of packets is sent from a source point A to a destination point B, each of the packets will need a slightly different time to reach the destination. Formally, jitter may be defined as the statistical variance of the data packet inter-arrival time. According to [17], and when adopting the real time protocol (RTP), jitter is measured in timestamp units. For example, if the transmitted audio is sampled at the usual 8000 Hz, the unit will be $\frac{1}{8000}$ of a second. The endpoint computes an estimate using a simplified formula (i.e., a first order estimator). More precisely, to estimate the jitter J(i) after the reception of the i thpacket, we need to calculate the change of the inter-arrival time, and then divide it by 16 to reduce noise and add it to the previous jitter value as described by the following formula $J\left(i\right)=J(i-1)+\frac{\left(\right|D(i-1,i)|-J(i-1\left)\right)}{16}$, where the value D(i-  1,i) is the difference of relative transit times for the two packets. That difference is computed as D(i,j) = (R _j  - R _i ) - (S _j  - S _i ) = (R _j  - S _j ) - (R _i  - S _i ) where S _i  is the timestamp from the packet i and R _i  is the time of arrival for packet i, [17]. The assumption which is made is that the sender sends one packet each 20 milliseconds and that the ideal transit time is 10 milliseconds. The computation also starts from zero and not from a random value, which means that S _i  = 0 and R _i  = 10. The jitter value starts to grow slowly despite large differences. In fact, when the large differences disappear (i.e., i > 8), the estimate starts to approach the approximate mean value, [17].

We estimate the jitter value using the 3TCAC related services which are the trusted absolute timestamping service and the trusted duration measurement service. The QoS values will be estimated only on the insecure wireless channel. In order to estimate the jitter in a reliable fashion on the backbone, we propose that 3TCAE (n - 1) calls its RS-3TCAC (n - 1) each 20 ms in order to get a QoS-Estim message and then send it to 3TCAE (n) on the insecure wireless channel as shown in Figure 4. 3TCAE (n) forwards the received message to its 3TCAC which verifies the QoS-Estim and then extracts the valuable information required to compute the jitter. That pre-described procedure is repeated 9 times in order to estimate a mean jitter value. If the computed jitter value does not exceed a pre-configured M a x J i t t e r T h r e s h o l d, 3TCAC (n) will add it to a BS-QoS-INFO message that will be given back to the application entity in order to forward it to the superordinate.

In order to estimate the jitter on the wireless edge links between the RS and the managed SSs, the RS-3TCAC sends a QoS-REQ signalling message to its payload entity and then triggers the trusted absolute timestamping service. The 3TCAE entity forwards the received packet to the SS which should answer with a first QoS-RSP message. 3TCAE receives the QoS-RSP and then forwards it to the RS-3TCAC which computes the edge delay between the RS and the SS. As the jitter computation requires a synchronization between the entity which will send the equivalent of the RTP packets each 20 ms and the entity which will receive them, the RS-3TCAC and the SS need to have the same clock values.

However, we already stated that only 3TCAC modules are synchronized. Therefore, the SSs may have completely different clock values compared to their managing RSs. To address this issue, we propose to use the already computed delay value in order to synchronize the SS and its managing RS. In more detail, on receiving the first QoS-RSP message, the RS-3TCAC generates a QoS-Sync message and then sends it to its application entity.

The QoS-Sync message indicates the clock value that should be adopted by the SS when sending the next 12 QoS-RSP messages. That clock value is given by the following formula C₀ = c u r r e n t T i m e s t a m p + α + computed edge delay, where c u r r e n t T i m e s t a m p is the value of the timestamp when computing the clock value and α is the delay of the communication between the 3TCAC and its entity added to the delay required by the receiving SS to process the incoming message added to an estimate of the possible error. When receiving the QoS-Sync message, the SS synchronizes its clock and then sends 12 consecutive QoS-RSPs to the 3TCAE entity of the managing RS-3TCAC. We propose to use only 9 received packets in total in order to estimate the mean jitter value on the edge link; the 3 remaining packets are sent in order to tolerate possible packets loss. After getting 9 packets, the RS-3TCAC ignores the other packets. If the jitter estimation fails, it will be resumed after a configured threshold period in order to tolerate the behavior of malicious entities which try to conduct a DoS by over-exploiting the RS’s resources.

The delay estimation on the wireless edge links and on the backbone is very similar to the jitter estimation one. More precisely, the delay will be estimated using the same control packets required to compute the jitter. Note that the mobile RS should re-estimate the delay on the edge links in case of handover. Besides, the requested delays for the served flows will be updated in order to compensate the handover delays.

4.2.4 Handover disturbance compensation

The handover process induces delays mainly caused by the signalling exchange and the switching of the connection to a new access station. Therefore, the additional delays should be compensated in order to provide the level of QoS that was agreed. Besides, we assume that the handing over RS does not start the compensation procedure before performing handover and allowing each managed SS to perform the QoS re-estimation. We propose that when the handing over mobile RS begins the handover process, it triggers the trusted duration measurement service. When the mobile RS attaches to a new access node and the managed SSs terminate the QoS re-estimation procedure, the trusted duration measurement should be stopped in order to compute a trusted value of the duration of the handover process. The obtained delay is then subtracted from the delay values of the current flows if its value is smaller than the previously agreed value. However, if this is not the case or if we may not find an available route that offers the updated value, we may try to subtract a portion of the handover delay using either a linear approach or an exponential approach. Note that regarding the first attempt of QoS compensation, the MR-BS managing the handing over RS may select a route based on the stored values of QoS offered by the routes to the destination. Nevertheless, that first attempt of QoS compensation may fail because the MR-BS may take its decision before the periodic update of the offered QoS.

Regarding the linear approach, we assume that a mobile q x milliseconds to execute the handover process. We also assume that we updated the delay value by subtracting the delay needed for handover and that we performed a first CAC on a selected route and that CAC was fruitless. The 3TCAC component of the handing over RS triggers the trusted duration measurement service in order to compute the delay of the first admission control process. Let that delay be equal to del. We propose to launch 8 parallel admission control procedures, first we update the delay value by subtracting x + del - 8y, and then we subtract x + del - 7y and so on until we find a suitable route that supports an updated delay value. the choice of the value of y may be random or it may be proportional to the value of x; it will vary according to the environment conditions and the load. We may then sense the satisfaction degree of the user when the compensation is processed and the satisfaction degree of the user when the compensation is not processed. The handover disturbance compensation using the linear approach in case where the handover delay is smaller than the initial flow’s delay and where the first processed CAC is fruitless is described by the pseudo-code in Algorithm 4.2.4.

The choice of executing 8 parallel admission control procedures is totally random, other numerical scenarios may be experimented. We remind that the choice of the value of y may be random or it may be proportional to the value of x; it will vary according to the environment conditions and the load. Nevertheless, the value of x + del - y needs to be inferior to x. Regarding the exponential approach, we propose to launch 4 parallel admission control procedures, first we update the delay value by subtracting x + del - 8y, and then we subtract x+del-4y, and then we subtract x + del - 2y and finally we subtract x + del - y until we find a suitable route that supports an updated delay value.

As the jitter is the variation in time between packets arriving, accelerating packets through the network will reduce the jitter. More precisely, the jitter caused by handover may be compensated through determining when packets should arrive at the destination and then accelerating them accordingly. Moreover, the handover disturbance compensation in terms of delay or jitter may also be achieved through augmenting the value of the minimum required rate since providing more bandwidth to a flow results in accelerating that flow. Besides, the handover compensation in terms of bandwidth may be combined to the handover compensation in terms of delay in order to minimize the handover impact on the QoS sensitive flows and increase the probability of finding a suitable new route that fulfills the new QoS constraints.

Algorithm 1 Handover compensation using the linearapproach

4.3 Intrusion tolerance within the multihop relay networks

The intrusion tolerance concept is implemented through performing the intrusion detection and then implementing mechanisms in order to survive the detected intrusion. In an IEEE 802.16j context, the RSs are normally controlled by the operator; thus, the probability of attacking them is much smaller than the probability of attacks within a traditional mesh network. Even if some attacks, such as selfish behavior, are not very common because the RSs do not have their own flows to transmit, an attacker may take control of one or more RSs or place a rogue RS, [18]. In order to fulfill the intrusion tolerance property, we enable the sub/superordinate RS or the MR-BS to detect the malicious party and then act.

6.1 Mathematical representations

Let SS  _j  and D _j  be two communicating SSs belonging to the MRS network. Let SS  _j  be managed by a mobile RS  _m  and D _j  managed by RS${}_{D_j}$. Let MR-BS(RS  _m ) be the MR-BS managing RS _m  and MR-BS(RS${}_{D_j})$ be the MR-BS managing RS${}_{D_j}$. We define HO _d  as the delay required by RS _m  to perform the handoff process. This delay includes the delay required by the managed SSs to re-estimate the QoS available on the edge links between them and the mobile RS _m  in its new position. Let Ad_i,j be the agreed delay for flow i of the managed SS _j . Therefore, Ad_i,j = Min [Ad1_i,j, Ad2_i,j], where Ad1_i,j is the agreed delay for flow i of the managed SS j before handoff and Ad2_i,j is the agreed delay for the flow i of the managed SS j after the handoff and the QoS re-estimation. Let R be the set of the available routes between MR-BS(RS _m ) and RS${}_{D_j}$. The following cases are considered.

Note that the HO _d  may be replaced by Intrusion _d  which is the delay induced by an intrusion in case of QoS compensation under intrusions.

where α is the mean delay of a hard IEEE 802.16j handoff.

where (dtrans_REQ) _l  is the delay required for transmitting a DSA-REQ or DSC-REQ message on the wireless link l and (dtrans_RSP) _l  is the delay required for transmitting a DSA-RSP or a DSC-RSP message on the wireless link l.

As MR-BS(RS _m ) knows the periodically updated values of the QoS offered by the routes belonging to R, it may select the most appropriate route r_selected∈R that offers the required QoS after handover. We define the delay del_i,j required to process a first delay compensation as the delay of transmitting the DSA-REQs or DSC-REQs on the selected route r_selected

note that, after processing the CAC on the n selected routes, the MR-BS(RS _m ) will send a unique DSA-RSP or a DSC-RSP indicating the route offering the minimum delay on which the flow will be transmitted.

note that, after processing the CAC on the k + 1 selected routes, the MR-BS(RS _m ) will send a unique DSA-RSP or a DSC-RSP indicating the route offering the minimum delay on which the flow will be transmitted.

note that, after processing the CAC on the n selected routes, the MR-BS(RS _m ) will send a unique DSA-RSP or a DSC-RSP indicating the route offering the minimum delay on which the flow will be transmitted.

note that, after processing the CAC on the k + 1 selected routes, the MR-BS(RS _m ) will send a unique DSA-RSP or a DSC-RSP indicating the route offering the minimum delay on which the flow will be transmitted.

Note that when (R 2 _{s e l} ) _n  = (R 1 _{s e l} ) _n , (del2lin_i,j) _n  will be obviously superior than (dellin_i,j) _n by del_i,j. Similarly, when (R 2 _{s e l} ) _k  = (R 1 _{s e l} ) _k , (del2exp_i,j) _k  will be obviously superior than ${\left({\text{delexp}}_{{}_{i,j}}\right)}_k$ by del_i,j.

6.2 Simulation model

In order to estimate the performance of the 3TCA architecture for QoS routing and intrusion tolerance provision within the multihop relay network, we adopt the network shown in Figure 5. The network encompasses mobile N-LoS RSs such as the RS12, fixed LoS RSs such as RS11 and RS13 and a set of MR-BSs interconnected with a wireless backbone. The mobile RS12 hands over and enters into the coverage area of RS11. RS12 manages two SSs which are SS11 and SS12. Each SS has a unique flow to be transmitted. The fixed and mobile RSs along with the MR-BSs host trusted 3TCACs.

We propose to perform four simulations. To that aim, we wrote the code implementing the 3TCA features and then we fixed simulation scenarios and we computed the execution cost of the scenarios implementation. The first considered scenario consists of a mobile RS that moves with its two managed SSs. The other scenarios consider legitimate and malicious RSs performing QoS re-estimation. First, we only detect the attack, and then we detect the attack and we tolerate it through processing QoS compensation. This will be further detailed when we describe each simulation context.

The goal of the first simulation is to evaluate the connection establishment delay when QoS compensation is processed after handover. The second simulation intends to determine the overhead induced by the QoS compensation process after handover. In both simulations, we consider the scenario when RS12 hands over to enter into the coverage area of RS11. In the third simulation, we propose to estimate the processing delay when our network is under attack and we evaluate the cost of guaranteeing intrusion-tolerance and of performing QoS compensation after being the victim of an intrusion. Finally, the last simulation aims at determining the overhead caused by the QoS compensation in case of intrusion. Note that for the described simulations, we assume that the delay is proportional to the number of executed operations.

6.3 Evaluating the performance of the 3TCA’s protocols

The first curve shown in Figure 6 estimates the number of operations executed when the RS12 moves with its managed SSs. The first attempt reflects the situation when the handover delay is smaller than the already agreed delay and when the handover compensation is successful from the first time. Therefore, the delay required to process the first attempt includes the delay described by Equation (6) along with the delay required to process the QoS re-estimation between the managed SSs and the handing over RS after handover. The second attempt reflects the situation when the handover delay is superior to the already agreed delay so that a linear approach is adopted. Therefore, the second attempt includes the delay described by the Equation (9) and the delay of QoS re-estimation. The third attempt reflects the situation when the handover delay is smaller than the already agreed delay and when the handover compensation is not successful from the first time so that a linear approach is adopted. Therefore, the third attempt includes the delay described by the Equation (7) along with the delay of QoS re-estimation. The simulated case assumes that for the two times where the linear approach has been adopted, (R 2_sel) _n  = (R 1_sel) _n . Note that three points of the abscissa axis reflect the three main scenarios of the handover’s impact compensation.

The experimental results confirm the theoretical results. More precisely, when the handover delay is smaller than the already agreed delay and the first compensation attempt is successful from the first time (i.e., the first point in the abscissa axis), only a CAC on a chosen route is performed and that route is able to provide the updated values of QoS. The delay of performing that successful first CAC is del_i,j. Moreover, when the handover delay is larger than the already agreed delay (i.e., the second point in the abscissa axis), only a first compensation attempt is performed. In this case, the CAC is processed on n routes and the resulting delay is (dellin_i,j) _n . Note that (dellin_i,j) _n  is superior than del_i,j because we perform the CAC on n routes and not only on one chosen route. However, when the handover delay is smaller than the already agreed delay and the first compensation attempt is fruitless, we perform a second compensation attempt (i.e., the third point in the abscissa axis). As we simulate the case where (R 2_sel) _n  = (R 1_sel) _n , (del2lin_i,j) _n  will be superior than (dellin_i,j) _n  because it includes del_i,j.

We may conclude that adopting the compensation induces some delay when it is not successful from the first time. Note that the delay caused by an unsuccessful compensation for the first time is taken into consideration when trying the compensation for the second time.

The second curve shown in Figure 7 estimates the number of the signalling messages exchanged when the RS12 hands over with its managed SSs. The same simulation scenario of the estimation of the connection establishment delay with handover compensation is adopted. Note that the number of exchanged messages increases especially when the compensation is not successful from the first time, which is an expected behavior.

In order to evaluate the performance of the 3TCA architecture with respect to intrusion tolerance, we consider various situations in which some RSs become malicious during the periodic QoS estimation on the backbone. More precisely, we increase the number of malicious nodes and we observe the delay and overhead induced by detecting and tolerating the intrusions. The first point of the abscissa axis shown by Figures 8 and 9 reflects the situation when the QoS re-estimation procedure is normally processed (i.e., without facing any intrusions). The second point of the abscissa axis reflects the situation when the QoS re-estimation faces an intrusion at the RS23 level but the threshold value of the p r o b a b l y-m a l i c i o u s-R S variable is not yet reached. In this case, only the value of that variable is incremented without affecting the normal QoS re-estimation procedure. The third point of the abscissa axis reflects the situation when the QoS re-estimation faces an intrusion at both RS23 and RS31 levels. In this case, the intrusions are detected but the 3TCACs do not react because the p r o b a b l y-m a l i c i o u s-R S threshold is not yet reached. Lastly, the fourth point of the abscissa axis reflects the situation when RS23, RS31, and RS15 are malicious and a compensation procedure is processed for RS15 while the intrusions of RS23 and RS31 are only detected. The 3TCACs do not react because the p r o b a b l y-m a l i c i o u s-R S threshold is not yet reached for both RS23 and RS 31. However, the delay estimated by RS14 is superior to the threshold and the threshold value of the p r o b a b l y-m a l i c i o u s-R S variable is reached. In that case, RS14 sends the p r o b a b l y-m a l i c i o u s-R S-A l e r t to the MR-BS1 which reacts by attempting an intrusion compensation on the link RS 13→ MR-BS1. Note that the four points of the abscissa axis are particularly chosen to reflect the main intrusion tolerance behavior in case of attacks.

As shown by Figure 8, the processing delay increases in case of intrusion. Moreover, the more the number of malicious RSs increases, the more the intrusion tolerance processing delay augments. The delay of the compensation attempt is important as the MR-BS needs to ask the involved RSs of the compensation links in order to decide whether the compensation is possible.

Let us now further evaluate the performance of our proposed architecture regarding intrusion-tolerance. To achieve this, we propose to compare the simulation results obtained within the MMR networks context to those of an intrusion tolerant routing protocol within the mesh context. Such a routing protocol, called MERQIT, has been presented in [9]. We think that such a comparison is appropriate for two reasons. On one hand, both protocols address the combination of the intrusion tolerance property and the QoS provision within the context of mobile wireless networks. On the other hand, the MERQIT protocol relies on clusterheads in providing connection to Non Line of Sight mobile subscribers. Indeed, the clusterheads considered by MERQIT may be compared to the relays considered by the MMR networks; the main difference between them is that the relays are managed by the network operator while the clusterheads are not.

We note that the simulation results obtained for the 3TCA architecture in case of intrusion confirm the results describing the MERQIT protocol behavior in case of intrusions. Particularly, Figure 8 shows the processing delay according to the number of malicious nodes within a mesh network. We notice that the processing delay does not highly increase when a malicious clusterhead is only detected without being isolated, but that the same delay becomes very important when the number of malicious access nodes increases (i.e., for example when a router presents malicious entities and should broadcast its status to its neighbors or when a clusterhead should be completely isolated) [9].

Nevertheless, we notice that MERQIT achieves better delays in the case of intrusions. First, because the simulated case of MERQIT is limited to QoS provision in terms of delays and does not consider QoS provision in terms of jitter, and second, because the MERQIT protocol isolates the malicious clusterheads or routers and asks the neighboring access nodes to take over if the QoS can be met. For example, since the same MN is managed by two clusterheads and if the managing router discovers that the first clusterhead is malicious, it will ask the second clusterhead to take over. In this case, minor treatments are processed as the second clusterhead has already all the information required to fulfill the failover. The 3TCA architecture rather processes QoS compensation by negotiating updated QoS values with candidate RSs of chosen links in order to accelerate the flows affected by the intrusion. Figure 8 also shows that adopting the isolation principle of the MERQIT protocol within the MMR networks is not appropriate. More precisely, when the probably malicious RS15 and RS14 are isolated, the whole branch of the tree rooted at RS14 becomes isolated. Consequently, the managed SS13 and SS14 are isolated and need to be rescued. In order to minimize the isolation impact, MR-BS1 needs to ask the neighboring MR-BS2 whether it is managing an RS that is in LoS with the isolated SSs and whether that candidate rescuing RS belongs to a path that fulfills the SSs’ QoS requirements. If it is the case, the isolated SSs will handover in order to attach to the rescuing RS and then they will process an edge QoS estimation with their new managing access node. This costly procedure in terms of processing delay may fail especially when the number of isolated SSs is important. For these reasons, we argue that adopting compensation in case of intrusion is more suited to the MMR context.

Now let us estimate the overhead when tolerating intrusions for our proposed scheme relative to MMR networks and let us adopt the same simulation scenario considering the processing delay with intrusion tolerance. As shown in Figure 9, the number of exchanged messages is the same when the normal QoS re-estimation is processed and when the intrusion affecting one RS is detected but not tolerated. That number increases when the number of malicious RSs increases and when the MR-BS1 tries to compensate the intrusion.

The overhead estimation results obtained in the MMR context confirm those obtained for MERQIT. In fact, we notice that the number of exchanged messages does not highly vary when a clusterhead is detected as malicious without being isolated. However, the overhead increases when the number of malicious access nodes increases. For example, the overhead augments when a router on the backbone should broadcast its status or when a manager should be isolated, [9]. Note that the number of exchanged messages in the context of MMR networks is superior to that number in the context of mesh networks mainly because we have implemented the jitter estimation within MMR networks. In fact, as stated in Section 2.3, the jitter estimation over a wireless link requires the exchange of at least 9 packets; thus, increasing the overhead of both QoS estimation and QoS compensation. Note that adopting isolation instead of compensation in case of intrusion within MMR networks induces an important overhead that increases exponentially with the number of managed SSs. This overhead results from the CAC processed by each neighboring MR-BS and its managed RSs along with the overhead caused by processing the handover operation and implementing the edge QoS re-estimation with the rescued SSs.

The simulations adopted in this article estimate the complexity of the 3TCA architecture in terms of processing delay and induced overhead. We may conclude that the obtained results are expected since one observes an increase of complexity and overhead when compensation is processed. This increase is the normal cost of an advanced management of QoS that adopts several attempts of compensation in case of handover and attacks in order to preserve the initial level of QoS or come close to that level. The simulation results obtained when adopting the pre-described simulation model may be generalized since we simulated the main scenarios of handover’s impact compensation and of intrusion tolerance behaviors.