QoSatAr: a cross-layer architecture for E2E QoS provisioning over DVB-S2 broadband satellite systems

Abstract

This article presents QoSatAr, a cross-layer architecture developed to provide end-to-end quality of service (QoS) guarantees for Internet protocol (IP) traffic over the Digital Video Broadcasting-Second generation (DVB-S2) satellite systems. The architecture design is based on a cross-layer optimization between the physical layer and the network layer to provide QoS provisioning based on the bandwidth availability present in the DVB-S2 satellite channel. Our design is developed at the satellite-independent layers, being in compliance with the ETSI-BSM-QoS standards. The architecture is set up inside the gateway, it includes a Re-Queuing Mechanism (RQM) to enhance the goodput of the EF and AF traffic classes and an adaptive IP scheduler to guarantee the high-priority traffic classes taking into account the channel conditions affected by rain events. One of the most important aspect of the architecture design is that QoSatAr is able to guarantee the QoS requirements for specific traffic flows considering a single parameter: the bandwidth availability which is set at the physical layer (considering adaptive code and modulation adaptation) and sent to the network layer by means of a cross-layer optimization. The architecture has been evaluated using the NS-2 simulator. In this article, we present evaluation metrics, extensive simulations results and conclusions about the performance of the proposed QoSatAr when it is evaluated over a DVB-S2 satellite scenario. The key results show that the implementation of this architecture enables to keep control of the satellite system load while guaranteeing the QoS levels for the high-priority traffic classes even when bandwidth variations due to rain events are experienced. Moreover, using the RQM mechanism the user’s quality of experience is improved while keeping lower delay and jitter values for the high-priority traffic classes. In particular, the AF goodput is enhanced around 33% over the drop tail scheme (on average).

Introduction

Within the last decades, geostationary (GEO) satellite systems have become an essential asset for Europe and all society. This infrastructure enables us to communicate and send information globally, allowing to reach large and disperse populations around the world, it makes feasible the provisioning of on-demand data and any type of Internet protocol (IP)-based services in real time.

Nevertheless, the transport of IP applications such as voice-over-IP (VoIP) and multimedia services require considering different levels of individual packet treatment through the satellite network. This differentiation must include not only the quality of service (QoS) parameters to specify packet transmission priorities across the network nodes, but also the required amount of bandwidth assignment to guarantee its delivery.

The main challenges that this technology faces in the provisioning of end-to-end (E2E) QoS guarantees are related to its native characteristics. For instance, the delay, that affects the performance of the transmission control protocol (TCP)[1], can seriously affect the delivery of time critical data to end users.

This situation is due to the fact that the standard TCP congestion control (based on the additive increase and multiplicative-decrease mechanism) is affected by the long Round Trip Time (RTT) that can reach at least 520 ms. Since, the TCP congestion window (cwnd) size is determined by the successful acknowledgement reception per RTT, the longer the RTT, the narrower the CWND growth, resulting in a slower TCP response. Therefore, a mechanism to reduce the experienced delay can be a valuable feature in order to enhance the user’s quality of experience (QoE).

Another challenge that GEO satellite systems face for the provisioning of E2E QoS guarantees is related to the available capacity or the available bandwidth. This capacity can seriously be reduced given that the satellite channel is mostly affected by rain events which are time-and-location limited. Therefore, if the available capacity is reduced by atmospheric events, it can be extended to a condition in which the satellite channel can also reach its capacity limit. As a consequence, the greater the channel capacity is reduced, the lower the available bandwidth will be left to share among flows requiring QoS guarantees. This requires the prioritization of traffic, in order to guarantee the transmission of time critical data even though a reduced and limited channel capacity is experienced in the satellite system.

In this article we propose QoSatAr, a cross-layer QoS SATellite ARchitecture to provide E2E QoS guarantees for IP traffic over the forward satellite channel. The architecture design is based on a cross-layer optimization between the physical layer and the network layer to enhance QoS provisioning when different levels of link capacity are available in the satellite system. The design is developed in compliance with the ETSI QoS broadband satellite multimedia services (BSM) standard[2] called the ETSI-BSM-QoS and the recent standard developed for the Digital Video Broadcasting-second generation (DVB-S2)[3] forward channel.

Particularly, the ETSI-BSM-QoS defines a specification based on the TCP/IP protocol suite for providing QoS guarantees for BSM services. It is characterized for being compatible with the currently standardized IP Differentiated Service (DiffServ) architecture, in which flows are aggregated into classes to obtain a specified QoS degree. In addition, the ETSI-BSM-QoS architecture is characterized by the separation between higher layers or satellite-independent (SI) layers and lower layers or satellite-dependent (SD) layers. This modular reference architecture allows enhanced control functions performed by the SI layers which can be either modified or updated regardless of the SD layer technology.

In this way, the design of the QoSatAr architecture is developed at the SI layers to establish priorities among users and applications (allocated at higher layers) that share the satellite link interface. Here, the interaction with the lower layers is defined in order to encompass the service categorization and the overall performance of the satellite network. Focusing on the SI layers, the management and control functions performed at upper layers[4] are enhanced while the SD layers (i.e., satellite physical, MAC, and link control which are strictly satellite dependent) are isolated to include different physical layer supports (i.e., for heterogeneous networks).

On the other hand, the DVB-S2 standard defines as mandatory the use of the adaptive code and modulation (ACM)[5] techniques, to attain Interactive Services. Such techniques reduce the available link bandwidth (transmission rate), if necessary, to achieve quasi-error-free channel conditions for each individual user to provide them with the most suitable Modulation and Code (ModCod) value according to the measured signal-to-noise-plus-interference-ratio (SNIR) value reported by the return channel. The major benefit of adopting ACM techniques it is that the obtained spectral efficiency is optimized, being as high as possible for all the satellite terminals. Nevertheless, there is a fundamental change related to the satellite physical layer as it is considered constantly changing.

In this way, one of the main concerns using GEO satellite systems is the management of these bandwidth variations to satisfy the specified QoS levels for different traffic classes. In this respect, the design of the QoSatAr architecture considers the fact that the bandwidth availability present in the satellite system is adapted using ACM techniques. This adaptation is performed considering the intensity of rain events.

The QoSatAr design is developed inside the DVB-S2 gateway which is the central element in the architecture. This is done in order to allow satellite operators to easily adopt the proposed architecture with low deployment cost. In addition, the proposed architecture allows the satellite operator to manage the functional parameters to establish priority levels and traffic rates according to the defined service level agreements (SLAs).

For the provisioning of QoS guarantees the design has been based on the DiffServ framework. The main goal of QoSatAr is to guarantee different QoS levels for IP traffic over the DVB-S2 channel while reducing latency and jitter values, considering the fact that the available bandwidth present in the satellite system is constantly changing. The QoSatAr design includes

• (i) A cross-layer optimization between the physical layer and the network layer to provide E2E QoS guarantees, considering the fact that the DVB-S2 forward channel is affected by the presence of rain events.

• (ii) A complete active queue management (AQM) system that considers Token Buckets (TBs) as rate limiters to regulate and guarantee a minimum transmission rate for each traffic class according to the priority levels established by the satellite operator. Here, the queue design considers the bandwidth delay product (BDP) value to dynamically set the queue lengths to enforce bounded delay values for high-priority traffic classes.

• (iii) A modified queuing policy called re-queuing mechanism (RQM) to reduce delay and jitter while improving the user’s QoE for the expedited forwarding (EF) and the Assured Forwarding (AF) traffic classes. This mechanism follows the philosophy of the DVB-S2 design, in which retransmissions are avoided because the two-way propagation delay is significantly high. In our case, the RQM mechanism prevents dropping packets that do not fulfill the DiffServ traffic class specification.

• (iv) A dynamic IP scheduler to allocate bandwidth resources for prioritizing those flows with high QoS requirements. The IP scheduler uses an algorithm that adjusts its internal values considering the capacity present in the system. This dynamic adaptation considers the cross-layer information sent by the physical layer to provide enhanced priority for specific flows when a reduced and limited channel capacity is experienced in the satellite system.

The E2E scenario defined for the design of the QoSatAr architecture is shown in Figure1. It considers a broadband satellite system in the Ka band (30/20 GHz) in a multi-beam architecture. The satellite scenario is considered transparent in star topology. We focus the design on a single time division multiplexed (TDM) carrier. Figure1 represents the typical scenario, in which remote users demand Internet services by the intensive use of the forward channel. In particular, an emergency remote vehicle requires accessing critical applications and data allocated at the regional hospital to provide the first medical aid during a emergency situation (i.e., earthquake, tsunami, etc.), where the satellite system is the only technology that remains available.

Figure 1

E2E QoSatAr scenario.

Here, three sources, with different QoS levels, send data to a remote destination by means of the broadcast GEO satellite channel. This channel represents the communication link between the ground gateway and return channel satellite terminal (RCST). Particularly, in the QoSatAr scenario, a heavy rain event is affecting the available bandwidth in the DVB-S2 channel.

In this article, we focus our research work on the DVB-S2 broadcast channel of the GEO satellite systems. However, the design of the QoSatAr architecture assumes a return link based on the DVB-RCS standard[6] with the support of a bandwidth-on-demand (BoD) mechanism to share the radio spectrum among the allocated users. In addition, the network control center is the element that monitors the link capacity for each RCST transmission.

Finally, an exhaustive performance evaluation of the proposed QoSatAr architecture is conducted using the NS-2 simulator. Here, several evaluation metrics, significant simulation results, and conclusions about the performance of QoSatAr are presented.

The key results allow us to confirm that with the adoption of the QoSatAr architecture, it is possible to keep in control the satellite system load while guaranteeing QoS levels for the high-priority traffic classes even though bandwidth variations due to rain events are experienced. The simulation results demonstrate that with the adoption of the proposed the RQM mechanism, the user’s QoE is improved while keeping bounded delay and jitter values for the high-priority traffic classes.

Moreover, with the evaluation of the dynamic IP scheduler, the high-priority traffic class is always guaranteed regardless of the channel condition affected by rain events. Here, the most important aspect in QoSatAr architecture is that the IP scheduling algorithm is able to guarantee the QoS requirements for specific traffic flows using a single parameter: the bandwidth availability. This parameter is set at the physical layer (considering ACM adaptation) and send to the IP scheduler taking advantage of the proposed cross-layer optimization.

The rest of the article is organized as follows. In section 2., the detailed design of the QoSatAr architecture is described. In section 3., the NS-2 simulation testbed is presented including the definition of the evaluation metrics, followed by a discussion of the obtained simulation results. In section 4., an overview of the most important related research works is provided. Finally, the article ends with conclusions.

E2E QoSatAr architecture

This section describes the main functional blocks inside the gateway for the provisioning of E2E QoS guarantees over a DVB-S2 satellite system.

The QoSatAr architecture is designed based on the DiffServ framework to provide E2E QoS guarantees. The DiffServ architecture defined by the IETF[7] allows IP traffic to be classified into a finite number of classes differentiated by priority, to support different QoS levels. The main components defined in the DiffServ architecture are the traffic classifiers, which select packets and assign (if necessary) their differentiated services code point (DSCP) values; the traffic conditioners which mark and enforce the rate limitation policy; and the Per Hop Behavior (PHB) that enforces the differentiated packet treatments. In this sense, there are three predefined PHBs: EF, AF, and best-effort (BE). One of the main benefits of adopting the DiffServ framework is that the network complexity is translated to edge nodes, enabling to maintain the scalability and simplicity of the IP network.

In QoSatAr, the supported traffic classes are defined according to the PHB. The EF traffic class[8] is designed to provide low-loss, low-latency, low-jitter, and to assure bandwidth services such as VoIP applications, where packets normally find short or empty queues. The AF traffic class[9] is designed for non-real-time traffic with QoS support, for instance the current Internet where hypertext transfer protocol (HTTP) applications are demanded by end users. The AF traffic class separates the network traffic into four independently forwarded AF classes which are differentiated based on their drop precedence (DP). Finally, the BE traffic class[7] is used for unclassified traffic such as file transfer protocol (FTP) applications. In this case, the end users or in general any organization will have a non-guaranteed achievable throughput.

The QoS policy defined in QoSatAr allows the EF traffic class to have the highest priority, while the AF traffic class has more priority than the BE traffic class. As a result, the BE traffic class uses the remaining link bandwidth, being able to also use the bandwidth that other classes do not use.

The proposed QoSatAr gateway design is focused on the SI layers, in order to empower the QoS functions performed at this layer, while isolating the SD layers (i.e., satellite physical, MAC, and link control) to include different physical layer supports (for heterogeneous networks)[4]. The proposed design including its separation between high SI layers and low SD layers is shown in Figure2. Particularly, the SI layers are defined to deal with QoS differentiation based on the DiffServ framework. Conversely, the SD layers are proposed for applying different DVB-S2 channel adaptations.

Figure 2

DVB-S2 QoSatAr gateway design.

The QoS blocks and their functionalities as a part of the proposed cross-layer QoSatAr architecture are described as follows: at the SI layer, the DiffServ server, the AQM system, and the IP scheduler are set up. At the SD layer, several buffers are defined for allocating packets waiting to be encapsulated and multiplexed before these are forwarded to the required RCST.

For simplicity at SI layers, we have reduced the set of DiffServ traffic classes into three (EF, AF, and BE). Similarly, at the SD layers several queues are set which are associated with different ModCods schemes. In this scenario, ModCo d _i is said to have higher spectral efficiency than ModCo d _j (where i<j), we assume that ModCods are ordered from high to low spectral efficiency.

This design complies with the ETSI-BSM-QoS functional architecture supported by the standards ETSI TS 102 157[10] and ETSI TS 102 462[2].

SI functional blocks

In order to determine the QoS treatment to be applied through the satellite network, packets coming from other IP networks are marked. In most of the cases, packet marking is typically performed at the edge nodes of the DiffServ satellite domain. However, in some cases satellite operators may require a remarking process to be performed inside the gateway to adjust the forwarding policy that will be applied.

As it is shown in Figure2, packets entering the DVB-S2 QoSatAr gateway are received by the DiffServ server. This module is responsible of receiving different flows, classifying the incoming packets, and deciding (if required) if a packet needs to be re-assigned with a different QoS level, by marking/re-marking its DSCP. In practice, the gateway implements packet classification and per hop forwarding scheduling according to the DSCP value of each packet. At this point, packets are forwarded to get in the AQM system.

The AQM system

The detailed design inside the AQM system is depicted in Figure3. Notice that the proposed scheme allows multiple flows to be aggregated and treated as a single flow per traffic class. The queuing model includes the three predefined DiffServ traffic classes (EF, AF, and BE), allowing each of them to have its own physical and separated queue. Packets coming from these queues are scheduled to the SD layers based on a dynamic IP scheduler. Here, IP scheduler functions are linked intrinsically with the satellite bandwidth allocation carried out by lower layers.

Figure 3

The AQM mechanism design inside the gateway.

As it is observed in Figure3, the high-priority traffic classes (EF and AF) implement TBs as rate limiters to guarantee certain transmission rates for each traffic class. These rates are defined in accordance with the bandwidth assignment established in the SLAs between the satellite operator and the subscribers. Importantly, the operator is able to modify these rules as a part of the operation and management tasks in the satellite gateway.

The incoming TBs limiting rates represent the transfer rates for the EF and AF traffic classes (μ_EF and μ_AF, respectively). Using TBs, packets are separated in two levels: in-profile (fulfill the SLA) and out-of-profile packets (do not fulfill the SLA).

Alternatively, the BE traffic class is not provided with a TB policer, this assumption is made considering that this traffic type does not need to adjust a committed rate. Therefore, when the BE queue is full, no particular algorithms are needed to decide which packet is going to be dropped. As a result, a simple drop tail (DT) mechanism is implemented.

The QoS policy implemented in the QoSatAr architecture allows all in-profile packets (coming from the EF and AF traffic classes) to be sent directly to the IP scheduler. This element is defined to control the order in which packets are extracted out from its queues. Here, it is important to bear in mind that the IP scheduler incoming rate is limited by each TB.

The RQM mechanism

In the same scenario of Figure3, when the TB algorithm runs out of tokens, the out-of-profile EF and AF packets are detected, which means that the sender generates more packets per time unit than the packets allowed by the SLA. For fixed networks with a relatively low RTT, the general recommendation is to drop these out-of-profile packets[9]. Nevertheless, the situation over the DVB-S2 satellite link is different, because this type of link virtually does not loose packets, given that the RTT is high.

In this condition, we propose not to drop the out-of-profile EF and AF packets, but instead send them to be en-queued again but in this case through the BE queue. We have called this modified queuing mechanism as the RQM (also shown in Figure3). It is worth mentioning that in[11], we have proposed and evaluated the improvements introduced by using this mechanism for the AF traffic class. However, in this study we have complemented the analysis and evaluation focusing not only on the evaluation of the AF traffic class, but also the EF traffic class.

In this way, assuming that the protocol used to transport the EF and AF traffic classes is the TCP protocol. It is worth noticing that if the network layer drops a certain packet, the TCP receiver has to wait until it receives the retransmitted packet, before delivering the packets with higher sequence number to the application. Therefore, having a high RTT over the DVB-S2 link increases the number of packets in the receiver buffer and those packets will have to wait a long period of time (around an RTT) to be delivered onto the application.

The main objective with the adoption of the RQM mechanism is to reduce the latency and jitter experienced by the user-application for the EF and the AF traffic classes. Given that our model does not drop these out-of-profile packets, but instead these packets are sent to the BE queue.

This modified RQM mechanism allows the out-of-profile packets to downgrade its QoS level, giving them the possibility (in the case of TCP) to reach the receiver before an RTT. The downgraded packet will get in the destination later than the other transmitted packets, since this downgraded packet will be re-classified to the BE traffic class. This packet disorder will be detected at the sender side by means of the TCP’s triple dupACK mechanism. Therefore, the TCP will trigger the fast retransmit/fast recovery algorithm as a congestion control signal. As a response the sender will reduce its congestion window, forcing to fulfill the SLA. It is worth mentioning that in this model the input traffic of the BE traffic class is not totally independent from its higher-priority traffic classes.

Conversely, if the protocol used to transport the high-priority traffic classes is different to the TCP protocol, the ability to detect out-of-order delivery will depend on the upper-laying protocol (UDP/RTP/RTCP) used to reconstruct the sender’s packet sequences at the destined user application.

The QoSatAr queue design

The design of the QoSatAr architecture requires setting the queue length for each specific traffic class in order to keep the delay bounded for the high-priority traffic classes.

To do so, we express the system load (the number of packets sent but not yet acknowledged) for each Diffserv traffic class i at time t as

$$L_i\left(t\right)={\mu }_i\left(t\right)·{\mathit{\text{RTT}}}_{\text{min}}+{\beta }_i\left(t\right)={\mathit{\text{BDP}}}_i\left(t\right)+{\beta }_i\left(t\right)$$

(1)

where L _i (t) represents the system load, μ _i (t) represents the TB’s limiting rates for each high-priority traffic class i (μ_EF and μ_AF), RTT_minrepresents the two-way propagation delay or minimum RTT (set to 560 ms in the GEO satellite scenario). β _i (t) is the queue occupancy level and B _i is the queue size.

Here, the maximum system load available for each traffic class i at time t is

$$L_i^{\text{max}}\left(t\right)={\mu }_i\left(t\right)·{\text{RTT}}_{\text{min}}+B_i$$

(2)

Therefore, the queue length and the occupancy queuing level for the EF and AF traffic classes are set to their BDP values:

$${\mu }_i\left(t\right)·{\text{RTT}}_{\text{min}}={\mathit{\text{BDP}}}_i\left(t\right)=B_i$$

(3)

However, in this scenario, it is important to consider the average packet delay experienced at each queue called Delay _i (t). Particularly, for the EF traffic class the Delay _i (t) is a function of the error term (E _p ) experienced for the treatments of individual EF packets[8]. Similarly, for the AF traffic class, this delay represents the experienced delay at each AF queue[9]. In both cases, the gateway is able to estimate E _p and${\text{Delay}}_{{\text{AF}}_i}$ values for each traffic rate[2].

Therefore the queue length considering the Delay _i (t) is set to:

$$\begin{array}{ll}{B}_i& ={\beta }_i\left(t\right)={\mu }_i\left(t\right)·{\text{RTT}}_{\text{min}}+{\text{Delay}}_i\left(t\right)+{\text{BDP}}_i\left(t\right)\\ +{\text{Delay}}_i\left(t\right)\end{array}$$

(4)

Finally, for the BE traffic class, the queue length is set considering μ_satrepresenting the available bandwidth present in the bottleneck satellite link. This is carried out to allow the BE traffic class to use the remaining link bandwidth, according to the predefined QoS policy.

Therefore, μ_BEand B_BE are set as

$$\begin{array}{l}{\mu }_{\text{BE}}={\mu }_{\text{sat}}\end{array}$$

(5)

$$\begin{array}{l}{B}_{\text{BE}}={\beta }_{\text{BE}}\left(t\right)={\mu }_{\text{sat}}\left(t\right)·{\text{RTT}}_{\text{min}}={\text{BDP}}_{\text{sat}}\left(t\right)\end{array}$$

(6)

Basically in the QoSatAr, the TBs limiting rates are used to regulate the queue occupancy level to enforce the system to work at a reference load level. This reference working point is a function of the defined SLAs for each DiffServ traffic class. By considering this queue design, it is possible to keep an optimal operation-working point while enhancing the satellite efficiency, given that the amount of packets to be buffered in the AQM system is set equal to the total in-flight packets that the satellite system is able to transport. Finally, when all packets have been queued and processed by the AQM module (see Figure3), they are sent directly to the IP scheduler.

The adaptive IP scheduler

The IP scheduler design has an important impact on providing E2E QoS guarantees[10], mainly, because the IP scheduler defines how the gateway allocates the bandwidth capacity to those flows requiring higher QoS guarantees, at the forward channel.

In the QoSatAr, the IP scheduler (which is the highest hierarchical scheduler) is responsible for queuing IP packets in the dedicated ModCod queues, providing them with QoS differentiation while tracking channel variations to determine the applicable ModCod for each forwarded packet[12].

To provide QoS differentiation among Diffserv queues, the proposed IP scheduler dynamically adapts its values to determine the number of extracted packets every time it visits a queue. It is based on the Weighted Round Robin (WRR) mechanism in which a weight adaptation is performed considering the bandwidth availability present in the satellite system. This design allows to provide QoS guarantees among DiffServ flows taking into account the link bandwidth variations reported by the physical layer.

The adaptive IP scheduler design is shown in Figure4. As it is observed, along with the IP scheduler, there is a new module responsible for calculating the weight values. This component is referred as the Cross-layer (XL) manager that takes into account the bandwidth availability to compute the suitable weight values for each traffic class (W_EF, W_AF, and W_BE). It considers as an input parameter the bandwidth availability reported by the physical layer to enhance the QoS provisioning among flows. This information is sent from the physical layer to the network layer based on a cross-layer optimization. The cross-layer design for the adaptive IP scheduler is also shown in Figure4.

Figure 4

The cross-layer design for the IP scheduler.

Here, the corresponding weight values are set within the XL manager to prioritize the resources for the high-priority traffic classes. As it is observed, this module is decoupled from the IP scheduler; therefore, the scheduler complexity is not increased and both modules can work independently based on their own settings.

It is important to mention that when a reduction of bandwidth capacity due to rain events is experienced in the satellite system, this weight adaptation becomes critical. Therefore, it is mandatory to continuously update the values of the transmission rate variations at the physical layer taking into account the changes introduced by the ACM technique in the presence of rain events.

The algorithm for assigning the weight values considers the QoS policy defined in the QoSatAr, in which the EF traffic class has the highest priority and the AF traffic class has more priority than the BE traffic class. In this condition, the proposed IP scheduler primarily allocates resources for the EF and AF traffic classes. Once both classes have guaranteed their bandwidth, the IP scheduler allows the BE traffic class to use the remaining link capacity and also the bandwidth that other traffic classes do not use.

In this way, the IP scheduler dynamically adjusts its weight values to provide QoS guarantees for the high-priority traffic classes. Here, the BE traffic class is provided with a minimum value to allocate a minimum of resources when the satellite capacity is reduced. However, if the capacity is increased, the BE traffic class should use the remaining bandwidth.

The algorithm for deriving the weight values is designed based on the proportional differentiated service (PDS) model jointly with an exponential adaptation. In this way, if the satellite bandwidth availability remains constant (i.e., clear sky conditions), the PDS model is applied, as it has been proved to successfully provide service differentiation to satellite networks with heavy load conditions[13, 14].

Conversely, if the system capacity is reduced, it becomes mandatory to provide QoS guarantees for the high-priority traffic classes (EF, AF). Therefore, we use an exponential adaptation to increase the weight values of the high-priority traffic classes[15]. This adaptation is done considering the proposed cross-layer design in which the bandwidth availability value is reported by the physical layer.

In normal operation, the IP scheduler should serve all traffic classes according to its defined priorities. However, when the system experiences a reduction (or increase) of bandwidth capacity, the IP scheduler should prioritize each traffic class according to the available bandwidth.

It is worth mentioning that in[16], we have proposed and evaluated the improvements introduced by using the dynamic algorithm when bandwidth variations are present over the satellite system. However, in this study we have complemented the analysis and evaluation considering different scenarios, traffic loads, and adding the advantages that the RQM mechanism can provide in terms of delay and jitter.

One of the main contributions of the QoSatAr architecture is that the IP scheduling algorithm is able to guarantee the QoS requirements for specific traffic flows using a single parameter: the bandwidth availability. This parameter is set at the physical layer (considering the ACM adaptation) and sent to the IP scheduler by means of a cross-layer design.

Satellite bandwidth characterization

In order to determine the values of the transmission rate variations at the physical layer, which are the input parameters of the proposed cross-layer design, we have studied the case in which the bandwidth availability in the satellite system is reduced by a heavy rain event.

The recent standards developed for the DVB-S2/RCS physical layer[6, 17] define as normative the use of the ACM[5] techniques to attain Interactive Services. One of the main advantages of using the ACM techniques is the ability to achieve quasi-error-free channel conditions for each individual user, by providing them with the most suitable ModCod value according to the measured SNIR, so that the spectral efficiency is as high as possible in all the cases. To do so, the DVB-S2 physical layer takes advantage of the SNIR value reported by each RCST[18].

As it is well recognized, the presence of propagation losses and transmission rate variations in the satellite link are mainly caused by atmospheric conditions such as the rain-fade effects, which are the most common phenomena in Ka-band (20–30 GHz) satellite systems. These events can lead to a Ka channel attenuation ranging from a few dBs up to more than 20 dBs. In addition, the maximum rain attenuation experienced in Ka systems has a difference about 5 dB (of peak reduction) between the attenuation affecting the best and worst locations[5].

According to[19], trying to describe and simulate a rain-fade distribution using a simple mathematical function becomes a difficult task. Mainly because the power spectral density (PSD) shape of rain fade is not only time variant (varying from a few seconds to some hours), but also its duration is not determined by the same phenomena. For instance, short durations are mainly due to scintillation and multiple scattering while long durations are caused by the space–time rain structure. Several approaches of Ka-band rain fade have experimentally observed that the PSD of this process can be approximated by a low-pass filter. In particular, authors of[20, 21] propose a model that estimates the time variant channel reported for a heavy rain scenario in the context of the DVB-S2 forward link. Here, a DVB-S2 physical layer adaptation considering ACM techniques is performed, taking advantage of channel state information reported by each RCST terminal. Such design considers two low-pass filters, one for characterizing the rain attenuation and a second one for the atmospheric scintillation. In addition, the design rules for setting the hysteresis thresholds are also presented.

In this way, we propose to assess the physical layer performance using this channel estimation model. Here, we have chosen several points of the estimated SNIR curve representing the ACM adaptation behavior for a heavy rain event[20]. Given this we perform a statistical regression in order to determine the relationship between each of the selected points and its corresponding estimated bandwidth. As a result, we obtained a bandwidth fluctuation wave that varies between 3.6 and 4.4 Mbps, following the distribution shown in Figure5 (black line). These calculations consider a TDM DVB-S2 forward channel with eight ModCods combinations (QPSK (1/3, 1/2, 2/3, and 3/4), 8 PSK (2/3 and 3/4), and 16-QAM (2/3 and 3/4)) in which the resulting data rate fluctuates between 51 and 204 Mbps considering 46 satellite antenna beams.

Figure 5

The ACM bandwidth characterization affected by a rain event.

Keeping this idea, we have approximated the results by matching the bandwidth fluctuation (obtained by regression) using several mathematical functions. Therefore, the particular rain event (black line) can experimentally be fitted by using a sinc function, as it is shown in Figure5 (see symbol ▴). Similarly, we have also fit the physical layer estimation by means of a sinusoidal wave (see Figure5 symbol ∗) to represent the same rain event affecting the DVB-S2 forward satellite link[16]. In this way, the peak of the sinusoidal wave, representing high link bandwidth availability will be set to 4.3 Mbps, while the valley representing a heavy rain event, will decrease the total link capacity to 3.6 Mbps. As a result, the bandwidth capacity will fluctuate between the minimum and maximum value of the sinusoidal wave.

Although the proposed functions do not perfectly match the ACM rain event as it suffers from intensive fluctuations, we believe that the proposed sinusoidal approximation allows to represent the general situation in which the satellite capacity is reduced. Therefore for simulation purposes, a single period (the valley) is enough to represent a deep reduction of capacity experienced in the satellite system.

SD functional blocks

The SD layer design inside the gateway is shown in Figure2. As it is observed, packets are sent through the SD layer (after scheduling functions) using the QoS mapping concept[22]. This implements Queue Identifiers (QID) to send the DiffServ flows from the SI layers to the SD layers. This procedure is allocated at the Satellite Independent-Service Access Point interface, which follows the guidelines defined in[4]. At this point, each QID enables the IP packet to be allocated to a virtual queue (considering its QoS characteristics) and then transported across the SD layers. For simplicity, the QoS mapping between SI and SD layers is not detailed in Figure2.

The SD layer design includes a set of physical buffers, their associated encapsulation units, a Frame Scheduler, and a DVB-S2 multiplexer. These elements are used to construct frames using IP packets and transmit them through the DVB-S2 physical layer to those destination terminals that have similar propagation conditions.

In particular, when enough packets are stored in a ModCod queue, the encapsulation units are used to build DVB-S2 frames which are served by the Frame Scheduler to feed the satellite physical layer (see Figure2).

According to the DVB-S2 frame structure, frames coming from different encapsulating units are transmitted through the satellite link using different ModCods. The corresponding ModCod is determined by the terminal that is under the worst propagation conditions, assuming that all destination terminals (in a beam) have similar propagation conditions. As a consequence, the frames sent to terminals having good propagation conditions (i.e., in clear sky) will be queued to encapsulation units using a ModCodi that provides low bit protection. Conversely, the frames sent to terminals having bad propagation conditions (i.e., facing a rain event) will use a ModCodn with higher bit protection levels, thus requiring additional overhead.

We assume that the DVB-S2 frame length is constant between 16,200 and 64,800 bits and each frame can encapsulate several IP packets. The physical queues have enough size to store at least two of these frames.

Using generic stream encapsulation, fames are encapsulated and sent to the frame scheduler which is a lower level scheduler responsible for dealing with fairness. Here, a basic frame scheduler strategy is recommended[23] to achieve acceptable overall performance in terms of low response time and high spectral efficiency. As the frame scheduler should guarantee a maximum waiting time for each IP packet while implementing the suitable fairness policy among terminals.

To guarantee a maximum waiting time for each IP packet, the QoSatAr frame scheduler follows a strategy based on the queue status[23]. In this way, if an IP packet has reached its maximum waiting time and it is still waiting in the queue (of a certain encapsulation unit), the frame scheduler should encapsulate this IP packet into the next DVB-S2 frame and transmit it through the satellite link. However, if the minimum frame size is not reached, several IP packets from other encapsulation unit (having different ModCodj that require less protection) must be used to fill the frame size. As a result it is possible to assure the maximum waiting time for each IP packet.

Finally, to guarantee fairness among terminals, the QoSatAr design (as most of the broadcast systems) is based on the TDM sharing policy with the adoption of ACM techniques[24]. In this context, terminals under good propagation conditions are able to use ModCods with lower overhead increasing their transmission rates compared to those terminals under bad weather conditions. For this reason in practice, the fairness policy applied to the DVB-S2 frame scheduler tries to shield the network layer from the effects of a time and location-dependent physical layer[25].

In this way, using ACM techniques it is possible to select the proper ModCod to guarantee a determined (low) error probability[3, 26]. Therefore, to offer homogeneous service among terminals, the DVB-S2 frame scheduler approximately assigns the same shared-service rate regardless of terminal’s propagation conditions. As a result, the offered transmission rate is the same, while the time used to transmit frames depends on the propagation conditions for each destination terminal. Notice that if the frame scheduler implements other policy like sharing the same amount of transmission time among terminals, it will penalize the terminals under the worst propagation conditions, so we would have a similar situation to what happen within DVB-S.

Performance evaluation

In this section, the proposed QoSatAr architecture is evaluated using the NS-2 simulation tool. Here, we describe the general satellite settings used to conduct the simulation tests, including the performance metrics to evaluate and compare the simulation results. In addition, we provide the results of evaluating the QoSatAr architecture working in a BSM satellite system in combination with different illustrative scenarios.

The simulated satellite topology is shown in Figure1. It considers a Ka-band (30/20 GHz) broadband satellite system in a multi-beam architecture. The satellite scenario is considered transparent in star topology. In this scenario, three sources, with different QoS levels, send data to a remote destination by means of the Ka-broadcast GEO satellite channel. The EF class supports a real-time VoIP application, simulating a constant-rate traffic, which is transferred over the user data protocol (UDP) to strictly guarantee bandwidth reservation. The AF traffic class bears a HTTP application while the BE traffic class bears a persistent FTP transaction server. Both, the AF and BE traffic classes are transported using the TCP protocol.

The DVB-S2 satellite environment is simulated using the Linux implementation for NS-2 version 2.29. The QoSatAr architecture has been integrated in the NS-2 simulator using the DiffServ module provided in[27]. Particularly, the functionalities of the RQM mechanism and the dynamic IP scheduler have been added in the code to test the capability of the proposed architecture. The objective of this simulated scenario is to conduct a performance evaluation of the QoSatAr architecture in the presence of bandwidth variations.

To evaluate the impact of adopting the QoSatAr architecture working over the proposed satellite scenario, we initially perform a simulation test to evaluate the benefits of using the RQM mechanism instead of using a simple DT.

As a second experiment, we propose to evaluate the complete QoSatAr design including the IP scheduler and the AF–RQM, considering the typical GEO satellite characteristics in the presence of bandwidth reductions caused by rain events.

General settings and performance metrics

The settings used to conduct our analysis is described as follows.

The minimum RTT_minvalue considered as the two-way propagation delay value is set to 560 ms. The buffer length of each traffic class (B_EF, B_AF, and B_BE) is set using Equations (4) and (6). The forward link is based on the DVB-S2 standard which uses the ACM scheme to achieve lower Packet Error Rate values. To perform the simulation we consider a bit error rate (BER) value set to BER = 10⁻⁷. The committed information rate values for the EF and AF TBs are set to μ_EF and μ_AF, respectively. The maximum transmission unit size is set to 1500 bytes. The satellite channel capacity considered as the bottleneck link is set considering clear sky conditions to 3.6 Mbps. The DVB-RCS link has permanent bandwidth capacity set to 256 kbps. These values have been selected because they are common parameters offered by satellite operators to provide Internet Services.

In addition, we assume that none ACK messages are lost, having more priority level than data packets when they are sent by the RCST terminal. In addition, we consider static values for the capacity allocation methods at the return channel[28]. In particular, for the proposed scenario the use of the continuous rate assignment for VoIP traffic, the rate-based dynamic capacity for HTTP traffic, and the volume base dynamic capacity for the BE traffic is assumed[29, 30]. In all simulations, the TCP variant used to transport AF and BE traffic classes is Sack TCP[31].

The metrics used to evaluate the performance of the selected TCP variants working over the proposed DVB-S2 ETSI-BSM QoS scenario are the goodput, the queue occupancy, the delay, and jitter. It is important to bear in mind that performance analysis is carried out over the DVB-S2 satellite forward link so that the performance metrics are defined considering the information measured in this link.

• (i) The goodput represents the average amount of correct received data (excluding retransmissions) which is measured during a certain period of time. Particularly, in a clear sky condition scenario, the reachable goodput value for each traffic class must be in accordance with the SLA. In this way, if the satellite capacity remains constant (i.e., 2 Mbps), we expect to reach 400 kbps of goodput for the EF traffic class (using UDP), 800 kbps for the AF traffic class, and 800 kbps for the BE traffic class.

• (ii) The queue occupancy metric represents the fullness level of each DiffServ queue which also determines the system latency. One of the main goals in any satellite system is to reduce the system latency which can be achieved by lowering the buffer occupancy levels. Therefore, it would be desirable that the proposed architecture reduces the levels of queue occupancy.

• (iii) The one-way delay metric represents the time it takes a packet to go from the gateway to the remote RCST terminal. It includes the amount of time that a destination system spends processing the packet. Using QoSatAr architecture, we should guarantee per-packet delay values less than RTT_min.

• (iv) The jitter metric represents the difference in the E2E one-way delay between selected packets traveling in a flow with any lost packets being ignored. The effect is also referred to as delay variation.

Evaluation of the RQM mechanism

In order to evaluate the proposed RQM mechanism in comparison to the DT scheme, we simulate the AQM system showed in Figure3 using the NS-2 simulation tool. Particularly, in this test the bottleneck satellite link is set to 2 Mbps, a standard Sack TCP is considered and the transmission rate for the EF and the AF traffic classes is set to 200 kbps and 1 Mbps, respectively.

The simulated scenario evaluates the performance of the EF and AF traffic classes under different traffic conditions. Specifically, different number of flows for the EF and AF traffic classes are transported (either 8 or 12 flows). The aim of this preliminary test is to overload the high-priority traffic classes in order to activate the RQM mechanism, sending the highest number of out-of-profile packets to the BE queue. As a result, the BE queue will become flooded with out-of-profile packets leading to the activation of the proposed RQM. The goal of this simulation test is to evaluate the performance of high-priority traffic classes in terms of goodput, delay, and jitter, and compare the results with those achieved by using the DT mechanism.

Figure6 shows the simulation results for the AF traffic class using both queuing options: either the RQM or the DT mechanism. These results consider the average values calculated when either 8 or 12 AF flows are working simultaneously. Particularly, Figure6b illustrates the total received AF packets at the application layer. As it is shown, when using the proposed RQM mechanism (symbols ∙ and ▴), more packets (approx. 27,000) are correctly received in both cases (8 or 12 flows) during all the simulation time. In contrast to the DT scheme in which the levels of received packets (symbols ∘, △) are less (approx. 15,000). Therefore, using RQM, the number of correctly received packets have increased in 44% (in average) compared with the DT scheme. This result is caused mainly because when using the proposed RQM mechanism, the out-of-profile AF packets are not dropped. Instead, these packets are sent to the BE queue with a downgraded QoS level, giving them the chance to reach the receiver before an RTT.

Figure 6

Simulation results for the AF traffic class (8 and 12 flows) using either the proposed RQM or the DT mechanism. (a) AF goodput, (b) total received AF packets, (c) timeouts number, (d) total retransmitted AF packets, (e) delay (seconds), and (f) jitter (seconds).

As a natural consequence, the more AF packets are received, the more the goodput level is enhanced. This result is shown in Figure6a in which it is possible to observe that using the RQM mechanism, the goodput level is enhanced reaching 1.5 Mbps. In contrast to the DT mechanism that drops all the out-of-profile AF packets, reaching only 1 Mbps of goodput. This result represents a significant goodput enhancement of 33% (in average) when using RQM. This means that the RQM mechanism enables the TCP traffic (in this case, the AF traffic class) to take advantage of the BE resources.

In a similar way, Figure6d shows the number of retransmitted packets. As it is observed, when the proposed RQM mechanism is used, the number of retransmitted packets is lower compared to the DT scheme at every time it is measured. Similarly, Figure6c shows the number of timeout events present during the simulation. As it is depicted, no timeout events are present when the proposed RQM mechanism is used, which is a desirable situation. In contrast, the DT scheme suffers from many timeout events during this simulation.

In this context, it becomes important to have a perspective related to the delay. Therefore, Figure6e shows the one-way E2E delay experienced by each AF packet (considering an example of one flow). As it is observed, when using the DT scheme, the peak delay values range between 2.5 and 6.1 s, causing longer delays at the application layer. This is done, given that out-of-profile AF packets are just discarded.

Nevertheless, when the RQM mechanism is activated, the E2E delay values have peak points that reach less than 0.5 s (see Figure6e), which are clearly lower than the RTT_min (set to 560 ms). Here, the peak values are mainly caused as a result of the packet disorder experienced at the application layer.

With the DT scheme, the period of time when the receiver detects the gap until it obtains the retransmitted packet, it is always greater than the RTT_min. Conversely, the improvement achieved by using the RQM is that it requires less time to deliver the out-of-profile AF packets to the receiver, since these packets, in fact, have not been discarded. The final result is that the application layer at the receiver get the data earlier, which improves the QoS experienced by the end user.

Similarly, Figure6f shows the jitter values experienced by each AF packet at the application layer. As it is observed, when the RQM mechanism is activated the peak jitter has values ranging 0.4 s compared to the DT scheme which has peak values around 1.2 s.

Finally, Figure7 shows similar simulation results for the EF traffic class using both queuing options: either the RQM or the DT mechanism. Here, the same performance parameters have been evaluated such as goodput, total transmitted packets, number of drop events, delay (seconds), and jitter values (seconds). As it is observed, when using the proposed RQM to transport the EF traffic class (using UDP protocol), similar results have been obtained compared to the AF traffic class.

Figure 7

Simulation results for the EF traffic class (8 and 12 flows) using either the proposed RQM or the DT mechanism. (a) AF goodput, (b) total transmitted EF packets, (c) number of packet drop events, (d) delay (seconds), and (e) jitter (seconds).

The obtained results enable us to conclude that when the RQM mechanism is employed, the EF and AF goodput levels are improved, while the E2E delay and the jitter experienced by the user application are reduced. As a consequence, the QoE experienced by end-users is enhanced.

It is worth mentioning that we have performed a detailed analysis considering the proposed RQM mechanism working simultaneously with different number of traffic flows and load conditions. Such analysis has turned out to get similar enhancements. However, in this article we have only described the most illustrative cases.

Evaluation of the E2E QoSatAr architecture

In this section, we evaluate the complete QoSatAr design including the AQM system, the adaptive IP scheduler, and the RQM mechanism considering the typical GEO satellite characteristics in the presence of bandwidth variations.

The objective of this performance evaluation is to test the QoSatAr architecture considering different traffic load conditions affecting the satellite link due to a heavy rain event.

In particular, we evaluate the DVB-S2 system response when adopting the QoSatAr architecture and compare these results against two proposals. The first comparison includes the Round Robin mechanism as a packet scheduler together with a simple DT queue as a discarding mechanism. This is called a RR-basic configuration. Similarly, the second comparison considers the same DT queuing mechanism together with the WRR scheduler that uses static weight values set to μ_EF, μ_AF, and μ_BE for the EF, AF, and BE traffic classes, respectively. These values are set considering the proportional distribution of resources[13]. This configuration is called a WRR-static. Finally, a third comparison is performed considering our proposed QoSatAr design including the AQM system, the adaptive IP scheduler, and the RQM mechanism. As it is designed QoSatAr should enforce the priority levels taking into account the link capacity variations reported by the physical layer using the proposed cross-layer optimization. Therefore, the QoSatAr should be able to guarantee the high-priority traffic classes regardless of the weather and traffic load conditions.

To perform this comparison we evaluate the goodput and queue occupancy levels for the EF, AF, and BE traffic classes when a heavy rain event reduces the bandwidth availability. Here, the bandwidth variability is represented by a sinusoidal wave period having 1000-s time duration. For such wave, the interval between 0 and 500 s represents a situation in which the satellite system experiences clear sky conditions. Conversely, after 500 s the capacity starts reducing because of the presence of a heavy rain event. Here, the satellite capacity reaches a minimum value set to 400 kbps at 750-s time point. After this point, the capacity starts increasing up to reach its steady-state condition.

To conduct the performance evaluation, we propose the following simulation tests to consider different conditions of traffic loads and bandwidth variability.

• (i) Test 1: μ _EF<μ _AF , the incoming EF rate is smaller than the AF rate.

• (ii) Test 2: μ _EF=μ _AF, the incoming EF rate is equal to than the AF rate.

• (iii) Test 3: μ _EF<<μ _AF, the incoming AF rate is greater than the EF rate.

• (iv) Test 4: μ _EFvariations, the incoming EF rate suffers from variations.

Table1 shows the performance evaluation parameters used to conduct each test, including the number of flows, the incoming rates, and bandwidth fluctuations caused by a heavy rain event.

• (i) Simulation results Test 1: μ _EF<μ _AF

Table 1 QoSatAr performance evaluation parameters

The simulation results of goodput and queue occupancy for the EF traffic class are shown in Figure8. Here, the three configurations (RR-basic, WRR-static, and QoSatAr design) working simultaneously are compared.

Figure 8

Test 1: EF goodput and queue occupancy.

As it is observed in Figure8, using the RR-basic (symbol ∙) the EF traffic class is not guaranteed when a reduction of bandwidth, due to a rain event, is experienced. Particularly, during the 750-s time point only 130 kbps of goodput level is reached. Similarly, when using the WRR-static configuration (symbol ▴), the EF traffic class is able to reach only 80 kbps of goodput at the same time point. This goodput level is lower compared to the previous case, which is mainly because the WRR scheduler uses a static proportional distribution of weights based on the incoming traffic rate. Therefore, given that μ_EF<μ_AF, the scheduler assigns higher weight values to the AF traffic class, trying to guarantee this class over the EF traffic. This represents an undesirable result according to the defined QoS policy. In both cases (RR-basic and WRR-static), during the interval between 500 and 1000 s, the queue occupancy is overloaded, reaching its limit (set to 90 packets), leading to an increase of the system latency.

In contrast to these results, when using the proposed QoSatAr architecture, the EF goodput is able to reach its 400 kbps during all the simulation time (see symbol ∗). Here, the EF buffer occupancy is reduced compared with the RR and static WRR. Particularly, the buffer occupancy for the EF traffic class is kept at lower levels, being able to reach 90 packets only during the minimum value of the bandwidth reduction (750-time point). This is a desirable result when working with QoS satellite systems.

In the same context of Test 1, the simulation results of goodput and queue occupancy for the AF traffic class are shown in Figure9. As it is observed, the more the capacity is reduced, the more the AF goodput level is affected. Similarly, the queue occupancy reaches its limit (set to 90 packets) during the rain event interval.

Figure 9

Test 1: AF goodput and queue occupancy.

Nevertheless, if we analyze the behavior at the 750-s time point (see the valley), when the bandwidth availability reaches its minimum level (400 kbps), it is possible to see that the RR-basic (symbol ∙) is able to keep 130 kbps of goodput, which is the same value reached by the EF traffic class (see Figure8). This situation is mainly because the RR scheduler extracts a packet every time it visits each queue. As a result, both the AF and EF queues receive the same treatment, having the same bandwidth assignment. Therefore, using the RR-basic, it is not possible to guarantee the priority levels established in the SLA, given that the same amount of bandwidth is assigned for all the traffic classes.

In contrast to this, when the WRR-static configuration is employed (see symbol ▴ in Figure9), the AF goodput is enhanced, being able to reach 150 kbps during the 750-s time point. However, at the same time point, the EF traffic class is able to reach only 80 kbps of goodput (see Figure8). As it can be observed, the AF traffic class is assigned with more bandwidth than the EF traffic class, although it has less priority than the EF traffic class. This is mainly because using the WRR algorithm with static weight values, the queues of the higher-priority traffic classes become much more visited, depending of their static weight values. Therefore, using a proportional, static distribution of weights (W_EF<W_AF), it is not possible to guarantees the EF high-priority traffic class in the presence of a heavy rain event.

Nevertheless, when using the proposed QoSatAr, the AF traffic class is able to reach only 20 kbps of goodput during the 750-s time point (see Figure9), which is an expected result given that the EF traffic class reaches 380 kbps of goodput, at the same time point. As a result, the bandwidth assignment for the EF and AF traffic classes are defined according to their priority levels while considering the bandwidth reduction present in the satellite system. Therefore, using the proposed cross-layer design in QoSatAr, it is possible to totally guarantee the high-priority traffic class and assign the remaining link bandwidth to the AF traffic class when a heavy rain event is experienced. This result matches the QoS policy specification in which the EF traffic class has the highest priority level, while the AF traffic class has more priority than the BE traffic class.

Finally, in Figure10, the simulation results of goodput and queue occupancy for the BE traffic class are presented. Here, it is possible to observe that in all the cases the BE traffic class is able to use the remaining link bandwidth. This is mainly because the AQM design allows the BE traffic class to use the bandwidth that other classes do not use. As a result, this class is able to follow the sinusoidal wave when an increase of bandwidth capacity is experienced in the satellite system (see the interval between 200 and 400 s).

Figure 10

Test 1: BE goodput and queue occupancy.

On the contrary, when an extreme reduction of bandwidth is experienced (see the interval between 500 and 1000 s), the bandwidth is assigned by the algorithm used in each configuration (RR, WRR, and QoSatAr scheduler). In particular, when either RR and static WRR are used (see symbol ∙ and ▴, respectively), in most of the cases the priority levels of each traffic class are not maintained, being unable to guarantee the high-priority traffic classes over the BE traffic class. However, when considering our proposed QoSatAr adaptive IP scheduler (symbol ∗) the goodput for the BE traffic class (at the same interval) is kept at the lowest level while the queue occupancy is overloaded. Therefore, the priority levels of each traffic class are kept during all the simulation time, guaranteeing the higher-priority traffic classes (EF and AF) over the BE traffic class when an extreme reduction of bandwidth is experienced.

Finally, to have a general overview of the QoSatAr performance, Figure11 shows the goodput and queue occupancy for the EF, AF, and BE traffic classes working simultaneously. It includes the sinusoidal function representing a rain event reducing the bandwidth availability up to 400 kbps. Here, it is possible to see that the EF traffic class (symbol ∙) is totally guaranteed during the whole rain event. In contrast to the AF traffic class (see symbol ▴) which is guaranteed only if the resources for the EF traffic class have been assigned. This is an expected result according to the QoS policy defined for a DVB-S2 satellite system. Finally, the BE traffic class (symbol ∗) is able to use the remaining link bandwidth during all the simulation, taking advantage of the resources that the other classes are not using.

Figure 11

Test 1: QoSatAr simulation results.

Summarizing the results obtained in Test 1: the adoption of the proposed QoSatAr architecture allows an enhanced distribution of bandwidth resources while guaranteeing the QoS requirements for specific traffic flows using a single parameter: the bandwidth availability. Such parameter is set at the physical layer considering ACM adaptation for a heavy rain event. By means of the proposed cross-layer optimization, it is possible to continuously update the bandwidth availability to keep the QoS requirements for the high-priority traffic classes. Finally, the proposed QoSatAr design allows to enforce the QoS specifications when an extreme reduction of bandwidth occurs in the satellite system.

• (ii) Simulation results Test 2: μ _EF=μ _AF

The objective of this test is to evaluate the priority levels that each traffic class is able to get when a reduction of bandwidth is experienced, considering that both the EF and AF traffic classes, require the same load conditions (800 kbps).

In a similar way, Figure12 shows the goodput and queue occupancy for the EF, AF, and BE traffic classes working simultaneously considering only the QoSatAr architecture in the presence of a heavy rain event. Here, it is possible to see that the EF traffic class (symbol ∙) is guaranteed only if the available bandwidth value is bigger than the EF traffic rate (C_out>μ_EF). Therefore, it is possible to assign all the available resources to the EF traffic class, matching the sinusoidal wave shape when a reduction of capacity is experienced (see interval between 625 and 875 s). Conversely, the AF traffic class which has more priority than the BE class (see symbol ▴) is guaranteed only if there are enough available resources to transport the highest-priority traffic class. In particular, although the same load conditions for the EF and AF traffic classes are defined, the EF traffic class is able to keep the highest priority, while the AF traffic class maintains more priority than the BE class. This is an expected result according to the QoS policy defined for a DVB-S2 satellite system. As it is observed, The BE traffic class (symbol ∗) is able to use the remaining link bandwidth during all the simulation, taking advantage of the resources that the other classes do not use.

Figure 12

Test 2: QoSatAr simulation results.

Finally, Figure13 and14 show the results for the EF and AF traffic classes, respectively, in comparison to the RR-basic and WRR-static. In both graphs, it is possible to see that neither the RR-basic nor the WRR-static are able to provide QoS guarantees for the high-priority traffic classes. In particular, Figure13 shows the enhanced result obtained using QoSatAr in which the EF traffic class is able to reach its 800 kbps of goodput, while matching the sine wave distribution (see interval between 650 and 850 s). In the queue occupancy graph, the levels for the EF and AF traffic classes are overloaded when these are facing the bandwidth reduction caused by a heavy rain event. However, it is possible to see that the EF buffer occupancy level is time reduced when adopting the QoSatAr architecture compared to the cases when using either the RR-basic or the WRR-static.

• (iii) Simulation results Test 3: μ _EF<<μ _AF

Figure 13

Test 2: EF goodput and queue occupancy.

Figure 14

Test 2: AF goodput and queue occupancy.

The objective of this test is to evaluate the priority levels that each traffic class is able to get when the EF traffic rate is lower (200 kbps) compared to the AF rate (1.2 Mbps).

The simulation results of goodput and queue occupancy for the EF, AF, and BE traffic classes using the QoSatAr architecture in the presence of a heavy rain event are shown in Figure15. Here, it is possible to see that the EF traffic class (symbol ∙) is totally guaranteed during all the simulation. This is mainly because the EF rate is lower (200 kbps) compared to the reduced bandwidth capacity (C_out=600 kbps). Therefore, it is possible to guarantee the required available resources for the EF traffic class, allowing to have a constant distribution.

Figure 15

Test 3: QoSatAr simulation results.

In contrast to this result, the AF traffic class (see symbol ▴) is guaranteed only if enough resources for the EF traffic class are available. Therefore, during the interval between 625 and 875 s, it is possible to reach a goodput level which is higher compared to the EF traffic class. This is mainly because, once the EF traffic class is guaranteed only if there are remaining resources, the AF traffic class takes the second place in the provisioning of bandwidth guarantees. Although the AF traffic class requires more bandwidth assignment than the EF traffic class, using QoSatAr it is possible to keep the priority levels allowing the AF traffic class to take advantage of the remaining resources. As a result, the priorities are kept according to the QoS policy defined for a DVB-S2 satellite system. As it is observed, The BE traffic class (symbol ∗) is able to use the remaining link bandwidth during all the simulation, taking advantage of the resources that the other classes are not using.

Finally, Figures16 and17 show the results for the EF and AF traffic classes respectively in comparison to the RR-basic and WRR-static configurations. In both graphs, it is possible to see that neither the RR-basic nor the WRR-static are able to provide the predefined QoS guarantees for the high-priority traffic classes. As it is observed in Figure16, although using the RR-basic configuration (symbol ∙), it is possible to provide similar results for the EF traffic class (reaching goodput level ranging between 200 kbps) compared to those obtained by the QoSatAr. However, Figure17 shows the comparative result for the AF traffic class, which has the same and the lowest goodput level (200 kbps), which is a result of using the RR scheduler.

Figure 16

Test 3: EF goodput and queue occupancy.

Figure 17

Test 3: AF goodput and queue occupancy.

Nevertheless when using QoSatAr (symbol ∗), the AF traffic class shows an enhanced goodput level compared to either the RR-basic or the WRR-static. In this graph, the queue occupancy levels for the AF traffic class are overloaded when facing the bandwidth reduction caused by a rain event. Finally, in Figure16, it is possible to see that the EF buffer occupancy level is reduced when adopting the QoSatAr architecture compared to the cases when either the RR-basic or the WRR-static are used.

• (iv) Simulation results Test 4: μ _EFvariations

The objective of this test is to evaluate the priority levels that each traffic class is able to get when the EF traffic rate experiences bandwidth fluctuations between 100 and 500 kbps.

Figure18 shows the goodput and queue occupancy for the EF, AF, and BE traffic classes working simultaneously considering only the QoSatAr architecture in the presence of a heavy rain event. Here, it is possible to see that the EF traffic class (symbol ∙) experiences bandwidth variations represented by a simple step function ranging between 100 and 500 kbps. As it is observed, the variable goodput for the EF traffic class is totally guaranteed even though a extreme reduction of bandwidth capacity is present in the satellite system.

Figure 18

Test 4: QoSatAr simulation results in the presence of EF variations.

Moreover, using the QoSatAr it is possible to assign all the available resources to the EF traffic class when a reduction of capacity is experienced (see interval between 600 and 800 s). Nevertheless, at the 750-s time point, the AF traffic class (see symbol ▴) is able to have more bandwidth resources than the EF traffic class, given that, at this point, the EF traffic rate is reduced. Therefore, the AF traffic class takes advantage of the resources that the EF traffic class does not use.

In particular, adopting the QoSatAr when EF rate variations are experienced, it is possible to provide the highest priority for the EF traffic class, while the AF traffic class has more priority than the BE class. This is an expected result according to the QoS policy defined for a DVB-S2 satellite system. As it is observed, the BE traffic class (symbol ∗) is able to use the remaining link bandwidth during all the simulation, taking advantage of the resources that the other classes are not using.

Finally, Figures19 and20 show the results considering the RR-basic and WRR-static respectively, for the EF, AF, and BE traffic classes working simultaneously. In both graphs, it is possible to see that neither the RR-basic nor the WRR-static are able to provide QoS guarantees for the high-priority traffic classes when EF traffic variations and bandwidth reductions are experienced. Similarly, the queue occupancy levels are overloaded (see interval between 600 and 800 s) when a bandwidth reduction is faced due to a heavy rain event. Here, it is possible to see that the EF buffer occupancy level is reduced when adopting the QoSatAr architecture compared to the cases when using either the RR-basic or the WRR-static.

Figure 19

Test 4: RR-basic simulation results in the presence of EF variations.

Figure 20

Test 4: WRR-static simulation results in the presence of EF variations.

Related work

The new challenges posed by the support of QoS over DVB-S2 satellite systems have been addressed by several authors. However, there are few works that are focused on developing and testing complete architectures to provide E2E QoS guarantees over the DVB-S2 forward channel.

The QoS provisioning over satellite systems has been concentrated on evaluating the adoption of the DiffServ architecture. For instance in[32], a QoS framework for GEO satellite networks is presented. Here, the objective is to analyze the impact on the performance of the AF traffic class considering different QoS factors such as traffic aggregation and multiple DP levels. Similarly, the work developed in[33] presents a gateway architecture to support DiffServ over satellite networks. In this architecture, a resource management algorithm and marking mechanisms are proposed to guarantee the QoS level requirements.

Moreover, in[34], the authors presented the simulation results of testing a military satellite platform considering different QoS metrics (i.e., throughput, delay, and packet losses). Here, the authors proposed a weighted random early discard (WRED) configuration to enhance service differentiation in a E2E satellite scenario. The results suggest that the implementation of a tuning WRED is essential to improve the throughput for the high-priority traffic while keeping packet loss rates at lower levels. Even though these works employ the DiffServ architecture to provide QoS guarantees, they do not consider the changes introduced by the ACM scheme over the DVB-S2 link.

Taking a different perspective, there are other works focused on providing QoS guarantees based on a cross-layer optimization. Particularly, an architecture design based on the PDS model has been addressed by the authors of[14] in the context of a BoD satellite scenario. Here, the provisioning of a proportional class-based service differentiation to TCP flows considering split-TCP connections is proposed. The scheduling algorithm for controlling the resource allocation is set up at the MAC layer (SD layers) and the PDS model is defined at TCP layer based on the throughput for each TCP flow. This proposed scheduler is based on the waiting time priority scheduler[35] which considers the average queuing delay to provide service differentiation. In addition, it proposes the use of performance-enhanced proxies (PEPs) to configure several parameters for different TCP connections.

Similarly, in[36] a cross-layer PEP architecture is proposed to provide QoS guarantees for TCP flows in the context of the ETSI-BSM-QoS satellite system. The design is focused on the SI layers which is based on a cross-layer optimization. It includes a cross-layer TCP protocol that uses two control loops to properly manage the system load. The architecture design considers the use of PEPs, as mandatory elements to continuously update the service rate and buffer occupancy values for achieving an efficient and fair bandwidth allocation. The adoption of such architecture allows to guarantee QoS requirements for several DiffServ-TCP flows while keeping the dynamics of the system in control.

Taking a different approach, in[37], a full design for QoS provisioning over DVB-S2 satellite systems is proposed. The design is developed on the SD layers. It includes a packet scheduler set up at the MAC layer[38] that considers the physical behavior of the Ka satellite propagation channel to provide QoS guarantees. Here, the scheduler determines the fraction of time assigned for every transmission by each physical layer according to its correlated area where users undergo similar channel conditions. In addition, the scheduler design considers the tunable-fairness policy proposed in[25] to provide fairness among ModCods at the SD layers. Here, the fairness levels achieved among users under different channel conditions are tunable to provide control over the system throughput.

In this article, we propose QoSatAr, an E2E architecture to provide QoS guarantees over the DVB-S2 satellite system. In contrast to the previous related works, our design is focused on the SI layers in which no PEPs are required aiming to preserve the E2E path. In addition, the management and control functions performed at upper layers are empowered while the SD layers are isolated to include different physical layer supports (i.e., for heterogeneous networks). The design proposes a complete gateway architecture including an IP packet scheduler that considers the bandwidth availability present in the satellite system to enhance QoS guarantees. The architecture is based on a cross-layer optimization between the physical layer and the network layer. Particularly, our model studies the impact on the traffic class performance when bandwidth variations due to the changes introduced by the ACM scheme over the DVB-S2 link are experienced. The proposed architecture is designed inside the DVB-S2 gateway, which is allocated in the terrestrial segment. As a result the proposed algorithm can easily be adopted by satellite operators.

Conclusions

In this article, we have presented QoSatAr, a cross-layer architecture developed to provide E2E QoS guarantees for IP traffic over the DVB-S2 satellite channel. The architecture design is based on a cross-layer optimization between the physical layer and the network layer to provide QoS provisioning based on the bandwidth variability present in the satellite system. Our design is developed at the SI layers, being in compliance with the ETSI-BSM-QoS standards.

In this study, we have detailed a complete QoS design inside the gateway, in which we have proposed the RQM mechanism to enhance the goodput for the EF and AF traffic classes while reducing the E2E delay and jitter. In addition, we have proposed an adaptive IP scheduler to guarantee the high-priority traffic classes regardless of the channel condition affected by rain events.

The implementation of this architecture has been evaluated using the NS-2 simulator. The key results allow us to confirm that using QoSatAr, it is possible to keep control of the satellite system load while guaranteeing QoS levels for the high-priority traffic classes even though bandwidth variations due to rain events are experienced. The simulation results also demonstrate that with the adoption of the proposed the RQM mechanism, the user’s QoE is improved while keeping bounded delay and jitter values for the high-priority traffic classes. In particular, an AF goodput enhancement of 33% (on average) is reached.

Moreover, with the evaluation of the dynamic IP scheduler, the high-priority traffic class is always guaranteed regardless of the channel conditions affected by rain events. Here, the most important aspect in QoSatAr it is that the proposed architecture is able to guarantee the QoS requirements for specific traffic flows using a single parameter: the bandwidth availability. This parameter is set at the physical layer (considering ACM adaptation) and sent to the IP scheduler taking advantage of the proposed cross-layer optimization.

Future work will be focused on specifying the QoSatAr detailed design for the return channel based on the DVB-RCS standard and the adoption of the DAMA scheme as a bandwidth allocation mechanism.