We propose in this article an architecture called 3TCA that provides intrusion tolerant routing and QoS for MMR networks. In more detail, we propose to guarantee QoS in terms of delay, bandwidth and jitter for the multihop relay networks while addressing mobility through performing handover disturbance compensation in case of mobile RSs. Meanwhile, we tolerate particular timely-based and DoS attacks through compensating their impact on the agreed QoS level.
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.1 QoS Estimation over routes linking fixed entities
In our network model, the MR-BSs and the fixed RSs form a fixed backbone and each MR-BS, RS and SS should be uniquely identified within the network. We assume that each fixed RS knows exactly its superordinate on the path to the MR-BS. Such information may be assigned by the operator or provided by the managing MR-BS. The MR-BS assigns a unique path-ID to each branch and each fixed RS records the path-ID(s) of the path(s) it belongs to. We propose that each fixed RS periodically initiates a QoS estimation over the link between it and its superordinate. The estimated QoS values in terms of Delay (ms), Rate (bits/s) and Jitter (ms) are sent to the superordinate within a B S-Q o S-I N F O message and should be forwarded until the MR-BS.
After collecting the QoS information of each link, the MR-BS deduces the global QoS that can be guaranteed over the whole path (branch) as the maximum value of delays over the links forming the path, the minimum values of rates over the links forming the path and the maximum value of jitters over the links forming the path. Besides, each MR-BS periodically estimates the QoS over the wireless links between it and its neighboring MR-BSs. The period value may be fixed by the network operator. Note that the QoS estimation procedure should be initiated from the leaf fixed RS to the root MR-BS in order to minimize the number of transmitted signalling messages (i.e., overhead).
4.2.2 Admission control of handing over mobile relays
When a mobile RS enters a new coverage area, the mobile RS needs to serve multiple service flows issued by its managed SSs. A separate admission control procedure should be executed for each service flow. We think that the available QoS between the managed SSs and the mobile RS needs to be re-estimated since the physical properties of the wireless link may change. The mobile RS needs to adapt the provided QoS in order to compensate the handover disturbance and the probable modification of the available QoS on the edge links (i.e., links between it and the managed SSs). For that reason, we propose that each mobile RS entering a new coverage area initiates an edge QoS re-estimation with each managed SS and then adapts the QoS requirements of each flow issued by the concerned managed SS. After that, the mobile RS sends a DSA-REQ on its name to its superordinate for each flow. That request encompasses the source identifier, the destination identifier and the required QoS in terms of minimum rate, maximum delay and tolerated jitter. Note that in our case, the DSA-REQ will travel from a subordinate mobile RS to its superordinate in order to minimize the overhead.
In our model, the MR-BS already has an estimate of the QoS on the sub-path from the mobile RS to it, the MR-BS can also receive QoS information of other paths on the backbone. The MR-BS may directly route flows which can not tolerate delays using the QoS information of the candidate paths. The MR-BS may also send a DSA-REQ to all the RSs on the candidate path(s) in order to request an admission control decision as specified by the IEEE 802.16j amendments because the QoS information can be updated, especially when the configured period of QoS re-estimation is relatively high.
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 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 , 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 C0 = 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.
4.3.1 Intrusion tolerance context
The relay RSs within multihop relay networks are controlled by the operator. Therefore, the probability of taking control over RSs is relatively low. We propose to only use the insecure wireless channel to forward the signalling messages within multihop relay networks but we use the 3TCAC services to detect some attacks. Using only the insecure wireless channel enhances the scalability property of our protocol and reduces the overhead.
In order to protect the integrity of the signalling messages and verify the identity of the sender, each 3TCAE (n) forwards the received message to its 3TCAC (n) which uses encryption keys for un-signing and verifying it. Besides, all the signalling messages are produced by the 3TCAC and signed by it then relayed to the entity. Therefore, we are sure about the validity of the control information composing the message.
4.3.2 Tolerating time-based attacks
Let us assume that the entity of the RS (subordinate 3TCAE (n - 1) or current 3TCAE (n)) does not send the control message at time. Two principal causes may be responsible of this incident. The first cause is that the processing capacities of the RS (n) or of RS (n - 1) are saturated. The second cause is that either RS (n), or RS (n - 1), or both have been controlled by a malicious party and that it has become a malicious RS. If the RS becomes malicious, the delay and/or jitter will seem much longer on the route; thus probably causing DoS to managed SSs. The managed SSs will probably hand over because they can not be correctly served. If multiple malicious RSs are injected within a certain region/area of the network, a distributed DoS occurs.
In order to tolerate the previously described attack, we define two threshold values: the M a x D e l a y T h r e s h o l d and the M a x J i t t e r T h r e s o l d. When the RS-3TCAC (n) computes the jitter or the delay on the link between itself and its subordinate, it compares the obtained values to the threshold ones. If the obtained values are larger than the thresholds, we propose that RS-3TCAC (n) renews its entity and then increments the p r o b a b l y-m a l i c i o u s-R S variable for it and its subordinate. When the p r o b a b l y-m a l i c i o u s-R S variable reaches a pre-configured threshold, the concerned 3TCAC sends 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 signaling message which will be forwarded till the MR-BS. The values of M a x D e l a y T h r e s h o l d and M a x J i t t e r T h r e s o l d may be dynamically updated according to numerous factors such as the history of the feasible QoS on the links, the load conditions, etc.
When 3TCAE (n - 1) asks its 3TCAC (n - 1) for providing the QoS-Estim message that will be used for jitter estimation, 3TCAC (n - 1) will verify that it is really receiving the demand for that signalling message every 20 ms using its trusted absolute timestamping service. However, note that 3TCAC (n - 1) can not verify whether 3TCAE (n - 1) has really sent the QoS-Estim message as soon as it (i.e., that entity) received the demanded message.
The trivial idea to prevent the malicious RSs from succeeding in their attacks is that the MR-BS isolates them. However, isolating the malicious RSs will decrease the coverage area. More precisely, the more the isolated malicious RS is close to the root MR-BS within the network tree, the more the probability of deleting multiple routes increases and the more the coverage area of the network is minimized. Besides, even if the isolated malicious RS is a leaf in the network tree, all the SSs served by it need to change their access entity and a whole area will become uncovered. Nevertheless, only the route comprising that malicious leaf RS will be deleted and multiple other routes will not be affected by the isolation.
We think that isolating the malicious RSs will have severe consequences on the performance of the MR network. If the previously described time-based attack occurs when evaluating the QoS for the first time, the MR-BS may temporarily adopt the estimated values (i.e., which are worse than the values that would be estimated if the RS was not malicious) and then trigger a maintenance procedure that will be handled by the operator’s control center. However, if the detection of a malicious RS occurs during the data transmission phase, the MR-BS which receives 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 signaling message has already stored the QoS that can be provided on each link of the concerned route. In order to tolerate the attack, the MR-BS calculates the delay and/or jitter induced by the presence of the malicious RS by comparing the new QoS values enclosed in 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 signaling message to the old QoS values which were used to admit the flows. Then, the MR-BS chooses the links (i.e., RSs) that will be involved in the compensation procedure according to the load and sends them a DSC-REQ signaling message while indicating the new values of delay, jitter and throughput. The MR-BS also triggers the maintenance procedure in order to rapidly fix the cause of the malicious behavior of the attacking RS.
4.3.3 Tolerating attacks caused by the SSs and attacks on the backbone
SSs are mobile entities which can either directly attach to the MR-BSs or access the MR network via RSs. Colluding SSs acting within the same coverage area may try to cause a DoS to their access point by sending multiple requests at the same time in order to saturate the processing capabilities of the managing RS or MR-BS. In order to tolerate such attack, 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.
In order to tolerate replay attacks on the backbone, we indicate that each 3TCAC which composes a new signalling message should append to it the current timestamp value. As all 3TCAC modules are synchronized, the replay attacks attempted by malicious entities will be easily detected when the receiving 3TCAC verifies whether its current timestamp value is much superior to the value indicated within the received signalling message added to the delay on that link.
4.3.4 Tolerating RSs refusing to forward signalling messages on the backbone
Malicious RSs may refuse to participate in the periodic QoS estimation procedure or may refuse to forward the signalling messages such as QoS-Estim, BS-QoS-INFO, etc in order to prevent an efficient management of the QoS. If they collude with other malicious RSs, they may refuse to forward 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 in order to prevent the MR-BS from adapting the QoS disturbance compensation and triggering the maintenance procedure. In order to tolerate the attacks targeting QoS estimation, each 3TCAC (n) module should verify whether it is receiving the signalling message from 3TCAC (n - 1) within a tolerance period. If it is not the case, 3TCAC (n) will increment its own p r o b a b l y-m a l i c i o u s-R S variable and the p r o b a b l y-m a l i c i o u s-R S variable of its subordinate and send 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 describing the RS for which the p r o b a b l y-m a l i c i o u s-R S variable has reached the configured threshold.
The tolerance period is computed as the period of estimating QoS added to the previously-computed delay on the link added to a maximum threshold value. Colluding malicious RSs which refuse to forward 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 are not easily tolerated as each RS can only have one superordinate. In more detail, if the RS (n)’s superordinate and subordinate are both colluding malicious RSs, 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 sent by RS (n) in order to inform about the malicious behavior of the subordinate will never reach the MR-BS and RS (n) will not be able to detect that fact.
4.3.5 Tolerating RSs refusing to forward data flows
We already specified that the MR-BS stores the QoS information related to the routes but that it may perform admission control for certain flows. Note that certain malicious RSs may indicate negative responses to the received DSA-REQ. To tolerate such an attack, the managing MR-BS should keep the history of the negative responses. As the QoS estimation is periodically processed, a malicious RS that tries to pretend higher delay and jitter values will be easily detected by its 3TCAC as it has been described earlier (i.e., detecting time-based attacks). In this case, the fact that the RS negatively responds to the DSA-REQs may confirm that it has a malicious behavior. However, if the RS is malicious but it has correctly performed the QoS estimation within the next period, the value contained in the p r o b a b l y-m a l i c i o u s-R S table will be incremented. Besides, if that value reaches a threshold, the MR-BS will order the SSs which are managed by the concerned RS to hand over and then trigger the maintenance phase.
A malicious RS may try to cause DoS for some of its managed SSs by refusing to relay their flows and by stopping relaying the MR-BS messages to them while updating the list of its managed SSs. The 3TCAC of the malicious RS will no longer receive data from the attacked SSs. The MR-BS deduces that the attacked SSs have been shutted down because if they were alive and they quited the coverage area, they should have initiated a handover process. This attack is more severe if the malicious RS is a mobile one because the IEEE 802.16j specifications indicate that the managed SSs of a mobile RS need to handover with it (i.e., follow it) so that the attacked SSs can not independently perform handover or network re-entry. This attack is not easy to counter because the managed SSs may suddenly shut down in case of power shortage for example. When the 3TCAC of an RS can no longer receive messages from a threshold number of SSs, the p r o b a b l y-m a l i c i o u s-R S variable should be incremented. When that variable reaches a threshold value, 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 will be sent to the 3TCAC kernel of the managing MR-BS over the secure wireless channel in order to trigger the maintenance procedure.