A QoS Architecture for DVB-RCS Next Generation Satellite Networks

The standardization of a return channel via satellite (DVB-RCS) and satellite community e ﬀ orts in term of interoperability over the last few years leads to quite a positive outcome: geostationary satellite networks are intended to provide broadband access to interactive multimedia services in low-infrastructure areas. However, in order to take in account real-time multimedia tra ﬃ c, an e ﬃ cient resource management scheme is still necessary to maximize the scarce uplink capacities usage. To address this capacity issue, this paper proposes a complete DVB-RCS QoS architecture that is implemented, thanks to an emulation platform, and evaluated with real multimedia applications. This paper ﬁrst gives an overview of the QoS architecture usually used in DVB-S/RCS satellite system, especially in layers 2 and 3. It then introduces the satellite system emulation used in the experimentation and its calibration. The main contribution of this work focuses on the signaling principle designed to allow applications to take beneﬁt from the QoS features of the satellite system even if they are non-QoS aware. It is then shown how signaling in such QoS architecture allows the user to change dynamically the QoS of his application using QoS agent and QoS server applications even if the application is not QoS-aware. It is also given quantitative results related to such a dynamic QoS change in the experiments done on the satellite emulation system.


INTRODUCTION
Geostationary satellite access networks are expected to play, in a near future, a decisive role in next generation networks (NGNs) as they are intended to provide broadband access to interactive multimedia services in low-infrastructure areas.Known as a real complementary technology in geographical locations beyond reach of terrestrial means, satellite networks still suffer, in comparison to terrestrial networks, from long delays, scarce bandwidth resources, and equipment costs.
The standardization of the digital video broadcastingreturn channel via satellite (DVB-RCS) in March 2000 and the publication of the guideline document in September 2001 stand for major milestones in the development of reliable, efficient, and low-cost satellite equipment through the harmonization of RCS terminals (ST) based on this open standard.Several commercial DVB-RCS based networks are already deployed and many efforts are done in order to enhance interoperability.
Most recent commercial deployments provide either Internet access or mesh connectivity over a transparent geostationary satellite.Fixed bandwidth contracts are generally offered to consumers, thanks to a simple resource management scheme.It simplifies admission control, reduces cost, and gains experience while waiting for the standardization of finer resource management strategies and equipment.A lot of work on IP over satellite remains particularly in the quality-of-service (QoS) field and the next step is, obviously, to take benefits from DVB-RCS dynamic allocation schemes and IP QoS architectures to cope with the satellite delay and the scarce uplink resources.
This article proposes QoS architecture compliant with the recommendation made by the ETSI BSM (broadband satellite systems) working group which provides a state of the art of existing QoS mechanisms that are applicable to broadband multimedia satellite systems [1].
The implementation made in a satellite emulation platform represents a first attempt to evaluate a complete DVB-RCS QoS architecture and a set of new services in a system based on either a regenerative or transparent satellite that will be the future of satellite networks.
This paper proceeds in the following way.Section 2 gives an overview of new trends in next generation satellite systems and sums up the principle of the DVB-RCS standard.Section 3 describes the features of our QoS architecture.The QoS signalling principle is explained here.Then, Section 4 shows our satellite emulation platform and an evaluation of the new services provided by the QoS architecture, demonstrating especially the dynamic QoS change features.

Forward link
The first DVB norm described a transmission scheme based on MPEG-2 (Motion Picture Expert Group) video compression and transmission schemes, using MPEG-TS (MPEGtransport stream).This latter was adapted for satellite systems through DVB-S (DVB transmission via satellite) that defines series of options to send MPEG-TS packets over satellite links and that is currently used for digital TV.The success of this standard has caused its adoption for Internet services over satellite.Then, the encapsulation of IP over MPE (multiprotocol encapsulation) or more recently ULE (ultra lightweight protocol) is needed.This leads to a complex network stack.DVB-S2 standard [2] is intended to be a successor of DVB-S with the same applications (TV, Internet, etc.).It offers new coding techniques that can increase performance by 25% over that of DVB-S, but is still compatible with encapsulation layers as MPE or ULE.An alternative known as GS (generic stream) intends to gain direct access to the physical layer, avoiding the MPEG2-TS packet overhead, but this protocol remains a work in progress.
The satellite terminals could therefore only receive DVB-S/S2 frames from the satellite, but did not have the ability to send any traffic towards the satellite.

Return link
In 1999, the ETSI proposed a standard for a return channel via satellite, the DVB-RCS [3,4], which supplements the STs with the ability to transmit traffic towards the satellite.
According to this basis, two types of satellite can be defined.
(i) Transparent satellite simply forwards the signal received with no additional processing.A gateway (GW) is needed on the ground to convert DVB-RCS frames into DVB-S one.Each communication goes through the gateway with a "star" topology.The delay to cross the satellite network is about half a second and a double hop (at least 1 second) is needed to connect two satellite users.(ii) Regenerative satellite with onboard switching payload is able to demodulate, process, and remodulate the traffic that goes though it and therefore to multiplex several DVB-RCS signals into a single DVB-S one.The associated topology could be a "star" or a "meshed" network.The end-to-end delay decreases to only one single hop.
Furthermore, DVB-RCS requires a medium access control (MAC) protocol because satellite terminals (ST) are able to simultaneously access the return channel capacity.The standard method relies on a multifrequency time division multiple access (MF-TDMA).It basically relies on the availability of several TDMA channels (corresponding to different carrier frequencies), each subdivided into frames and further into timeslots of fixed length (bursts) during which the STs are able to transmit data through MPEG2-TS or ATM traffic bursts.
The entity responsible for this timeslot allocation within the superframe shared by competing STs is the NCC (network control center) that centralizes the satellite resources management.Thus it periodically broadcasts a signaling frame, the TBTP (terminal burst time plan) that contains the information on which STs relies to know when to transmit their bursts.
This allocation can be dynamically modified by STs requests so as to prevent from wasting satellite resources that would be otherwise statically allocated.The implementation of such a mechanism is generally known as bandwidth ondemand (BoD) algorithm.

Bandwidth on-demand mechanisms
In order to dynamically manage the bandwidth allocation, a bandwidth on demand protocol called demand assignment multiple access (DAMA) is defined.It relies on the STs ability to request frequently "capacities" to the NCC which enables a regular update of the TBTP to fit to the STs respective traffic load.The latter provides signaling schemes as well as MAC QoS classes and their mapping on capacity types.
Thus, the norm defines 4 capacity categories to fit the applications needs: (i) continuous rate assignment (CRA) which is static capacity, not subject to dynamic requests; (ii) rate-based dynamic capacity (RBDC), which is dynamic rate capacity (in slots/frame), upper-bounded by MaxRBDC, granted in response to dynamic requests from the STs to track their instantaneous traffic rate; (iii) (absolute) volume-based dynamic capacity (VBDC and AVDBC), which is also dynamic rate capacity (in slots), granted in response to dynamic requests from the STs to track their traffic queue state; (iv) free capacity allocation (FCA), which is assigned to STs on an "as available" basis from unused capacity.
Capacity types are vital to return path QoS support at MAC layer; therefore, they are described in detail in the following.Any given ST can be assigned one or a mix of the four capacity types.Generally, higher priority classes of service are associated with guaranteed capacity (CRA, RBDC), while lower priority classes are predominantly given best effort capacity (VBDC, FCA).
Even if the service classes are properly defined, the allocation algorithms implemented in the NCC to fulfill the services requirements are not specified.

QoS ARCHITECTURE
This section describes the QoS architecture we propose for DVB-S/RCS satellite systems.The main contribution is built on return link management.Thus the downlink is generally considered not to be a bottleneck and classical traffic engineering techniques are enough to managed the network.

Basis of QoS in satellite systems
To reach an optimal exploitation of uplink resources, at least three functions must be implemented to provide QoS guarantees.
(i) QoS admission control consists, before the application sends its traffic, to check that the network has enough resources.This prevents some applications from sending traffic that would otherwise lead to congestion among high priority traffic.(ii) QoS enforcement consists in checking that the admitted traffic respects its contracts, that is, that it does not use more resources than requested.This is done by policing and shaping.(iii) QoS differentiation consists in having several classes of traffic, each class provides different behavior adapted to a given service.This task is complex and needs dynamic management during the connections lifetime and must be performed at two layers: the DVB-RCS and IP layers.
Thanks to the 5 bandwidth allocation mechanisms included in DVB-RCS standard, the traffic differentiation is made easily in introducing several MAC queues in the ST stack and mapping the capacity requests over the MAC queues.Then, IP DiffServ-based router architecture can be setup over these new MAC services.However, this cannot be done without cross-layer mechanisms that ensure perfect resources use.

Cross-layer architecture
The QoS management, in the proposed architecture, is split into three levels detailed in the following paragraphs.
(i) Satellite terminal resources: is medium access control level, where the DVB-RCS DAMA allocates the bandwidth on a fixed basis for real time applications and on demand for other flows (nonreal-time traffic).(ii) Class of service resources: a specific IP level module implements a queue management system aiming at providing a differentiated service with regards to three service classes.These service classes are deemed to exploit the capabilities offered by the MAC level QoS capabilities.(iii) User level resources: this level is related to the share of previous services resource between the different users.The user is able to classify its own flows in any available service through a dedicated agent (the QoS agent) that communicates with the QoS server to deliver the classification.The goal is to exploit the capabilities offered by the IP QoS capabilities.
An overview of this QoS architecture within the ST is given in Figure 1.

QoS at DVB-RCS layer
QoS management at the MAC layer aims at sharing with optimal way the global uplink resources among the STs.Thus, the MAC layer must be able to (i) provide strict guarantees in terms of delay and jitter; (ii) preserve these resources through fitting their allocation to the effective ST traffic load.
Within the ST MAC layer, the traffic is split into 2 classes of service (CoS), DVB-RT for "real-time service" and DVB-NRT for "nonreal-time" service, which are associated to 2 different ATM permanent virtual channels (PVC).One (DVB-RT) benefits from static resource assignment through CRA; on the contrary, (DVB-NRT) relies on a dynamic resource allocation scheme also called BoD algorithm which will be further detailed in this section.
(i) Real-time queue: the CRA consists in a fixed capacity that is set at the ST log-on and is not subject to renegotiation during the ST connection lifetime.Each superframe contains one or more slots assigned to this connection.This reserved static rate is entirely dedicated to the DVB-RT traffic, since its high delay sensitive requirements hardly tolerates throughput fluctuations.(ii) Nonreal-time queue: the request category retained for DVB-NRT traffic class is VBDC and FCA.Delay and jitter tolerant traffic is supplied by the MAC scheduler to the DAMA controller that computes the adequate dynamic volume to request to the NCC.These requests are sent out of band, not in traffic slots assignments, but signaled in each SYNC slots broadcasted periodically by the NCC.
This architecture uses an original DAMA protocol that aims to reduce the allocation delays without reducing the network use.
As soon as an application produces a data, a free slot in the next super frame should be available to send it.However, the allocation done with the DAMA protocol takes at least 600 milliseconds (minimum scheduling latency-MSL).To reduce its impact on the end-to-end delay, application needs are anticipated in monitoring the DVB-NRT queue length that grows conjointly.If the queue grows, the requested capacity is increased by a factor α otherwise only the minimum is requested as.This algorithm is detailed in [5].As shown later, by properly setting α, the latency introduced by the BoD algorithm can be effectively reduced.
In addition to the VDBC requests, the MAC scheduler in the NCC distributes extra capacities to the logged STs if the network is not congested.This last capacity category (FCA) comes out to enhance the ST performance especially on low loading conditions, preventing the ST from waiting at least for the MSL to be able to transmit.

QoS at IP layer
In order to achieve a complete traffic control framework, a classifier separates IP traffic into 3 categories: (i) real-time: such an IP flow should be guaranteed a minimum bandwidth, an upper bound on queuing delay, a mean queuing delay of a few tens of milliseconds; (ii) nonreal-time: such an IP flow should be guaranteed a minimum bandwidth, a mean queuing delay of a few hundreds of milliseconds; (iii) best-effort: all IP packets not recognized as belonging to a particular IP flow are treated without any guarantee on bandwidth or delay.
The classifier then maps the packets to the 2 MAC categories.The overall goal of the architecture is to enforce the constraints for the IP categories as defined above while maximizing utilization of the available time-varying capacity.
With reference to IntServ/DiffServ traffic classes, the best-effort (BE) traffic category supports the traditional service offered by the Internet by default without any specific QoS measure and whose performance are strongly impacted by network congestion states.Real-time IP data category includes both IntServ guaranteed service class and DiffServ expedited forwarding (EF) PHB (per-hop behavior) while the nonreal-time IP category is used for IntServ controlled load service class and DiffServ assured forwarding (AF) PHB [6].

QoS enforcement
The fundamental component of the architecture is the EDF scheduler preceded by token buckets (RC-EDF, ratecontrolled earliest deadline first) which allows fixing and upper bound to queuing delay and a minimum bandwidth for separate IP flows.Namely, the presence of token buckets is a guarantee that each IP flow will receive a minimum bandwidth, given sufficient demand, equal to the relevant token rate, while the EDF scheduler will guarantee to each packet of an IP flow, once suitably regulated by a token bucket to be served within a deadline equal to its associated static parameter.
In Figure 1, the RC-EDF components are gathered under the appellation "traffic shaping/policing."The traffic policing and shaping are then realized, thanks to single-rate token buckets.

Layer 3/layer 2 mapping
The 3 traffic categories are served by a scheduler using a simple priority queuing (PQ) discipline.This means that (i) packets from NRT queues are served only when RT queues get completely emptied, (ii) packets in the BE queue are extracted only when RT and NRT queues are empty.

Application mapping
The EF traffic includes a number of real-time applications with stringent time and bandwidth requirements such as telephony or video conferencing.IP signaling which has very stringent delay requirements but which is characterized by low-data rates should use this service class too.
The AF traffic should include a number of traditional Internet applications to be served with a satisfactory level of service and transported over TCP.They include telnet, HTTP, SMTP, FTP.Such applications can greatly vary in terms of bandwidth and delay requirements.This means that applications such as telnet or HTTP should be assured small queuing delay though with limited bandwidth.
The BE class is designed to manage all traffic which is not recognized as belonging to a particular user entitled to receive better QoS or to applications with no particular delay or bandwidth requirement.SMTP or FTP should belong to this class.

QoS signaling
The link between the applications and the QoS architecture is the QoS signaling.It allows the expression of the quality of service requested by an application and the configuration of the corresponding QoS provider.
In the proposed architecture (Figure 2), the QoS provider is the ST.An application who want to take advantage of a given IP QoS service (EF, AF, BE) must configure the satellite terminal in order to redirect its packet on the appropriate queue.A classical approach consists in statically configuring the ST to associate a port to a service (e.g., the FTP port to the best effort service).Usually done by the network administrator, this approach does not work with a set of new applications that open unfixed port as, for instance, VoIP applications.
A more generic and "user-oriented" approach has been proposed.The ST could be customized on the user request.Dedicated software, the QoS agent [7], allows to associate a running application to one of the three defined services and to send this association to the ST.It dynamically monitors application connections and sends to the ST the 5 tuples source IP address, destination IP address, source port, destination port, type of protocol for each of them.The ST maintains an association's table.Each incoming packet is redirected within the ST to the appropriate queue according to this association's table.
Figure 3 shows the six connections opened by Gnomeeting, videoconference software, and their selected services.
The QoS agent can be run as a daemon to apply predetermined rules without user interaction.In that case, it extends the "classical" approach with new applications.

Emulation principle
Evaluating performances over real data links or networks is expensive, even impossible for systems in development phase.Simulation and emulation both provide the opportunity to evaluate performances, at low-cost, on more or less realistic systems.When simulation needs a complete modeling of the systems from applications to physical network and operates in virtual time, emulation is more demonstrative since real applications can be deployed over the model describing transfer characteristics, delay, and error behaviors for instance.
For these reasons, the choice was made to set up a satellite emulation platform to demonstrate the network and application services integration on next generation satellite systems and the possibility to interoperate with terrestrial networks.

Test bed
The network elements that belong to a classical satellite network (Satellite, NCC, STs) are emulated individually on a dedicated computer.A gigabit Ethernet interconnects them and emulates the satellite carrier emulation.Ethernet was chosen for its native broadcast abilities and also for its high bandwidth capacities.Each satellite channel is mapped on a single Ethernet multicast address.

Satellite link emulation
The satellite link emulator (SLE) simulates satellite link characteristics term of delay (and distribution); bit-error rate (error burst frequency distribution, error length distribution), computed according to precalculated distribution and based on real measurements.
Each channel crosses the link emulator to simulate the effects of the satellite link in real-time.The packets sent from an ST to the SLE are delayed and are subject to a sequence of bit errors at random positions before are forwarded to the emulated "downlink" (a multicast address per spot).

Network control center
The NCC is the core of the satellite network management.It with allocating radio resources to the STs according to subscriber profile and available satellite resource.It certainly implements a DAMA controller, but provides also an address resolution protocol to map IP addresses over lying protocols and a QoS admission mechanism.

Satellite terminals
The satellite terminals are based on Linux systems.They act as an access router interconnecting LAN to an Internet service provider over a satellite link.Its DVB-S/DVB-RCS interfaces allow the data emission and reception and it implements the corresponding network layers.The proposed QoS architecture is mainly located in the terminals.
The accuracy of the ST implementation is close to a prototype version and makes the emulation very realistic but also critical for its configuration.The calibration of the services given to the users has been a touchy part of this work.

Platform calibration
As we explained in the former section, the available platform will provide us with a prototype as close as possible to a real DVB-S/RCS system behavior.So the quantitative results performed on it are rather significant.To reach this result, the platform has to be calibrated, that means that the right parameters have to be set to the right value.If this stage is not properly achieved, then the results offer no interest, even if all the parts of the emulation testbed are very accurate.So, in this section, the basic platform configuration chosen in order to carry out our experimental measurements is detailed.
This configuration stands for the reference scenario from which all the calibration adjustments are done in order to ensure the significance of platform performance.Through this nonexhaustive list of the main platform configuration parameters, we emphasize the huge possibility to customize the platform which still remains, even for simplified current commercial DVB-RCS deployments, a vital and difficult task.

Physical layer
The satellite diffusion properties are configured through the SE (delay, Jitter and Losses patterns) and the return link ca- pacity segmentation scheme.The satellite emulator delay is set to 250 milliseconds, the jitter is equal to ±1 milliseconds, and the loss pattern is typical of a nice weather.Please note that last notion which could sound subjective corresponds, in the satellite emulator, to real satellite measurement traces.

MAC layer
The main parameters are closely linked to resource sharing assignment from the NCC that distinguished two CoS at the MAC layer in the ST.The ST maximum transmission rate is shared by CRA and VBDC.Therefore, the peak transmission rate is defined at first, then the CRA amount and finally the DAMA configuration through the α anticipation parameter and the FCA threshold (Table 1).The MAC queue sizes have to respect minimum thresholds so as to prevent congestion from occurring in the MAC Layer.

IP layer
Considering that EF and AF services are implemented strictly according to the single-rate token buckets and that there is no BE service conditioning, the main parameters of traffic conditioning blocks (TCB) and IP scheduling are summarized in Table 2.

Measurements
The measurements given in this section aims at evaluating the dynamic QoS change mechanism.First, the experimentation done on DAMA results that have already been presented in [5] are used to prove the right calibration of the emulation testbed, so that the result obtained further is realistic.
The second part of the measurements has been performed on a multiflow scenario involving several applications.The obtained figures and tables show that the QoS architecture implementing the QoS server allows the user to change dynamically the QoS of one application thanks to the QoS agent.

Impact of FCA and α
The following study is linked to a VBR traffic source: a DIVX streaming session.The DAMA influence cannot be neglected in these experiments when the throughput variations can be absorbed by the DAMA algorithm.Thus the basic DAMA performances can be enhanced by increasing the anticipation   factor α which enables to bring 50% of the packets delay under 1 seconds (Figures 4 and 5).
Under 0.5, the anticipation factor does not improve the end-to-end delay.If we consider this factor, the reduction of α leads to a capacity underutilization, it will be maintained to 0.5 which stands for an interesting compromise between queuing delays and uplink utilization efficiency (Figure 6).If FCA allocation is taken into account, an additional improvement can be noticed.The factor α seems to have less impact on the end-to-end delay than in the first scenario.However, this 40 Kbps allocation stands for more than 10% of the DIVX average throughput and might be considered as overestimated for a single ST.Therefore, the anticipation factor has still a relative importance on VBR traffic which is directly linked to its average throughput and variability.

Global architecture under different loading conditions
The purposes of different tests are to measure the SATIP6 QoS performances under heterogeneous traffic flows (GSM VoIP sessions, DIVX VoD, FTP, and web browsing) which are mapped onto the three different SATIP6 services.As seen previously, the voice service offers strict guarantees in terms of delay and jitter.The AF service (FTP) ensures a minimum  throughput and protects the AF traffic from losses in congestion state.Finally, the BE service is the most affected by congestion while the satellite overload implies less capacities for overall BE traffic and therefore higher delays and losses.
In Table 3, we can notice that voice service is not affected by the loading conditions when the delay experimented by FTP and BE traffic increases.Inside the DVB-NRT traffic class, FTP traffic is protected from losses at the expense of the BE class delay and loss ratio in congestion states.

Dynamic change of QoS
The change of multimedia stream QoS is done thanks to QoS agent.
The different following steps are easy to find in Figure 7.
(i) Step 1: the scenario begins as a UDP video stream starts.This stream is sent in the BE class of service.(ii) Step 2: 25 seconds later, another flow is sent on the same uplink; it is done so that the uplink is now congested.The throughput of the first stream is then reduced to 800 kbps.(iii) Step 3: 25 seconds later, the user decides to upgrade the class of service of this stream and set it up to "voice."After traffic burst, due to the addition of the EF service of 1 Mbps, and the traffic buffered before the resource reservation, the throughput is around 1 Mbps.(iv) Step 4: at t = 80 s, the stream is downgraded back to BE and the stream throughput is then around 800 kbps.
In Figure 7, the time needed to change from one Cos to another one for a flow could also be evaluated when the link is congested by other data flows.The delays given in Table 4 show as usually that the delay is around 3 seconds.It is less when a new flow is added on a link.It is longer when the QoS of a flow is upgraded and less when it is downgraded, still longer in these two cases than in the simple addition of a flow.These results conclude the section dedicated to experimental measurements by putting the stress on the proper traffic differentiation carried out by our QoS architecture and the ability to change from one class of service to the other one thanks to the QoS agent GUI.

CONCLUSION
It was proved in this paper that it was possible to specify and implement QoS architecture for DVB-S/RCS satellite system in order to provide the user with QoS guarantees even if a non-QoS-aware application is used.MAC algorithms (such as DAMA) were proved to be efficient.It was also explained how to proceed to evaluate such an architecture.Using measurement tools on a well-calibrated testbed, the global QoS of the satellite system may be evaluated accurately.
Using other capacity category than VBDC (RBDC for instance) is improving resource utilization especially if applications throughputs are known.Unfortunately, this is not usual today in the Internet.In that case, we propose to use rate-based signaling protocols (SIP) in order to set up the right capacity requests.
Other future work may also be done related to DVB-S2 and new admission control mechanisms.
terminal MAC: medium access control NCC: network control center

Figure 7 :
Figure 7: Dynamic change of class of service using the QoS agent.

Table 1 :
Basic physical and MAC layer configuration.

Table 2 :
IP TCBs and Scheduler configuration.

Table 3 :
SATIP6 QoS performance under different loading conditions.

Table 4 :
Dynamic QoS change delay.