Traffic Contracts Based Optimizations for QoS Support in DVB-RCS Satellite Systems

The Return Channel for Satellite (DVB-RCS) standard has become a mature technology for Internet communications via satellite access networks. Because of the propagation delay, as well as the expensive and scarce resources, the QoS support has to be optimized and harmonized. Indeed, it is provided at different independent layers (mainly layer 2,3 and application level) which are potentially either redundant or inconsistent. This paper suggests optimizations (between layer 2 and 3) for the resource sharing based on traffic contracts and using cross layer mechanisms. The traffic contracts are mainly used to perform a prediction of the incoming traffic evolution in order to reduce the effects of the transmission delay. In addition, a way to coordinate layer 2 and 3 schedulers is introduced. A first performance assessment of the proposed mechanisms in a DVB-RCS context shows that the layer 3 delays (introduced by queuing) are significantly reduced.


I. INTRODUCTION TO QOS IN DVB-RCS SYSTEMS
The resource utilization on the return link of satellite systems is a key point regarding the use of satellite networks for the transport of IP.This paper suggests and evaluates some mechanisms which aim at optimizing the Quality of Service (QoS) support in DVB-RCS (Digital Video Broadcasting -Return Channel via Satellite) systems [1] [2].It focuses on the use of information included in the traffic contracts (Service Level Specification -SLS) [3] and the improvement of the consistency between layer 2 and 3.
This section provides an overview of DVB-RCS systems and focuses on the description of an RCST architecture in a QoS support context.

A. DVB-RCS overview
[1] specifies an architecture for the satellite return link assuming the use of a forward link (DVB-S [4] or DVB-S2 [5] [6]).The main entities (in addition to the ones required by the forward link) of a DVB-RCS system are the following.
• The Return Channel Satellite Terminals (RCST) send traffic on the satellite uplink.• The Gateway receives the traffic sent by the RCSTs and forwards it to external network (e.g.Internet).• The Network Control Center (NCC) implements a resource allocation algorithm in order to share resources between all the RCSTs.
• The satellite relays the traffic.In star topologies, all the traffic of the RCSTs is sent to the Gateway.In mesh topologies, the RCSTs are able to communicate with each other in only one hop and the Gateway is considered as an RCST with an access to the Internet.
The resource sharing is based on a DAMA (Demand Assigned Multiple Access) algorithm.The RCSTs send requests to the NCC to demand resources.The NCC takes into account all requests to share the available resources fairly and efficiently between all the RCSTs.Finally, the NCC broadcasts the MF-TDMA allocation plan to all RCSTs via the TBTP (Terminal Burst Time Plan).
Several kinds of allocations and requests are defined.Firstly, the Constant Rate Allocation (CRA) is a guaranteed and constant rate allocated by the NCC to all the RCST.There are two main types of request; the ones based on rate (RBDC -Rate Based Dynamic Capacity) and the ones based on volume (VBDC -Volume Based Dynamic Capacity).These requests are sent by the RCSTs to the NCC in the SAC field of the SYNC burst (they can also be sent via the Data Unit Labelling Method -DULM).When all the requests are satisfied, the NCC shares the potential remaining bandwidth; this is called the Free Capacity Allocation (FCA).Some precedent efforts have been done for the improvements of DAMA algorithm [7][8] [9][10] [11], but they do not take into account the traffic contracts and they mainly deal with the NCC side (when this paper mainly focuses on the RCST side).

B. RCST description in a QoS support context
This section describes the layer 2 and the layer 3 of an RCST considering a QoS support with a DiffServ-like [12] queuing.
At layer 3 (network layer), several queues are implemented (e.g. 6 queues; EF -Expected Forwarding, AF1 -Assured Forwarding 1, AF2, AF3, AF4, BE -Best Effort) in order to ensure that the packet treatments are performed according to the required services (in term of delay, jitter and loss rate).The classifier uses the DSCP (DiffServ Code Point) field to place the packets in the appropriate queue.A scheduler decides which queue has to be served.The packet is then sent to layer 2 (link layer).
At layer 2, incoming packets are segmented and encapsulated in layer 2 frames.Several queues are used (e.g. 3 queues EF, AF, BE) and a classifier uses the DS field (which is a layer 3 field).A scheduler decides which queue has to be served and sends the packet to the DVB-RCS framing.This architecture is depicted in Figure 1.The request calculator computes the layer 2 requests (rate and volume requests) according to layer 2 queue size evolutions (which depend on the incoming throughput).In several systems like in the IST-SatSix project [13][7], the throughput required by the EF traffic is mapped into RBDC requests, the one required by the BE traffic is mapped into VBDC requests and the one required by the AF traffic can be mapped on RBDC and VBDC requests.
Contract traffics between operators and clients are described by the Service Level Specification (SLS) [3].It specifies the technical parameters which allow to provide the guaranteed services.Among other specifications, the SLS provides the mean and the maximum rates of each class of service.This information is stored in the Policy Information Base (PIB).The PIB is used for the policing and the shaping (e.g. to define the parameters of a leaky bucket).
Section 2 presents some mechanisms aiming at improving the consistency of the layer 2 and 3 schedulers.Section 3 introduces some mechanisms taking into account the traffic contracts in the DAMA algorithm (mainly at the RCST side).Then, section 4 provides a first performance assessment.Section 5 concludes this paper.

II. LAYER 3 AND LAYER 2 SCHEDULING
As described in section I.B., QoS is both supported at layer 2 and 3.This involves some duplicate mechanisms (e.g.classification and scheduling), some losses and potential empty queues may occur at layer 2 if there is no accurate regulation of the layer 3 scheduler output.This section first introduces a mechanism to regulate the output of the layer 3 scheduler and presents some possible ways to improve the consistency between layer 2 and 3.In a second part, this section discusses the different proposals.

A. Layer 3 and layer 2 scheduling consistency
A way to regulate the output of the layer 3 scheduler is to take into account the available bandwidth at layer 2 (allocated by the NCC to the RCST).This allows to prevent queue instability avoiding a load (seen at L2) strictly superior to 1.
The first modification that can be brought by such a mechanism is the reduction of the queue sizes at layer 2 without any loss.The second modification that can be considered is the reduction of the number of queues at layer 2 (down to a single queue).
To achieve this regulation, cross layer mechanisms are required.The first one is the knowledge (by the layer 3) of the available bandwidth at layer 2. Information like the layer 2 encapsulation mechanism and the segmentation mechanism are also required to regulate the output of the layer 3 scheduler.These modifications are depicted in Figure 2.

B. Discussion
The layer 3 scheduler output regulation allows to have no loss at layer 2 (potential losses at layer 3 are related to congestions).As aforementioned, it also allows to reduce the delay and the queue sizes at layer 2 as the incoming throughput at layer 2 is equal to the available bandwidth at the output of layer 2. The delay encountered at layer 2 is now quite low and only depends on the layer 2 scheduler and on the available bandwidth.As the delay is low at layer 2, the number of queues at layer 2 can be reduced to only one queue.The advantage of such a solution is that the layer 2 is simplified.Indeed, at layer 2, neither the scheduler nor the classifier are required.Therefore there is no more redundancy between layer 2 and layer 3 functions.
The drawback of not having a layer 2 scheduler is that high priority packets may be delayed.The performance assessment (section 4) provides an evaluation of this additional delay.

III. RESOURCE REQUESTS AND ALLOCATIONS
This section first introduces how the request computing can take into account the traffic contracts (SLS).Then, a NCC algorithm which is consistent with the request computing is presented.In a third part, a way to implement the request computing is detailed.Finally, this section discusses the advantages and the drawbacks of the proposed mechanisms.

A. Requests computing taking into account the traffic contracts
At the RCST side, as there is an important delay (about 0.5 sec) between the request (computed by the RCST) sending and the allocation (computed by the NCC) reception (via the TBTP), one of the objectives is to take into account traffic contracts in order to have an approximate prediction of the incoming traffic in the request computing to get a request as close to the real traffic as possible.
The main idea is to use the SLS to evaluate the RCST incoming traffic (mainly the expected mean and maximum rates).Indeed, on one hand, when the measured incoming rate is greater than the maximum expected rate, it is highly possible that the incoming rate is going to decrease; on the other hand, when the measured incoming rate is widely inferior to the expected mean rate, there is an important probability that the incoming rate is going to increase.These features allow to make reasonable predictions as shapers are used to respect the traffic contracts.
The drawback of measuring the incoming traffic at layer 2 (for the request computing) is that it is not exactly the same as the incoming traffic at the RCST input.That is the reason why the request calculator we propose uses the measured incoming traffic at layer 3 as depicted in Figure 3. Cross layer mechanisms are required to implement such a solution.The request calculator needs to know the evolution of layer 3 queue sizes but also the layer 2 mechanisms (encapsulation, segmentation) and the information included in the PIB (Policy Information Base).This information is required to compute the requests (corresponding to layer 2 throughputs) taking into account the traffic contracts.
The simplified algorithm used to compute the requests sent every SYNC bursts to the NCC by the RCSTs is provided in Annex.The priority RBDC requests and the priority-less RBDC requests are defined.The priority-less ones correspond to the prediction.
EF and AFi traffics are mapped into (priority and priorityless) RBDC requests.BE traffic is mapped into AVBDC (Absolute VBDC) requests, that means the requests are not cumulative (an AVBDC request invalidate the precedent AVBDC requests).The AVBDC request is equal to the incoming BE traffic.

B. NCC allocation algorithm
At the reception of all the requests, the NCC (Network Control Center) have to fairly and efficiently share the available resources.A way to be consistent with the request calculator is to serve first the priority RBDC requests, then the priority-less RBDC requests (the RBDC requests in profile are first served, then the ones out of profile are served) and finally the AVBDC requests.The out of profile RBDC requests are served before the AVBDC requests as it refers to a higher traffic class than BE (mapped to AVBDC requests).

C. Implementation of priority/priority-less requests
This section describes how the priority and priority-less requests can be implemented in a DVB-RCS system.The requests are included in the SAC field.The SatLabs recommendations [14] advices a SAC length of 14 bytes (when used in the SYNC burst with Turbo Code encoding).Seven bytes are used for various fields (Group_Id, Logon_Id, Route_Id, MandC).The 7 remaining bytes can be used for the requests.Each request requires 2 bytes, therefore each SAC field may contain up to 3 requests (a priority RBDC request, a priority-less RBDC request and an AVBDC request).The request type is coded on 3 bits; the first of these 3 bits is not used and can be used for the priority.

D. Discussion
The proposed algorithm for the request computing takes into account the incoming traffic at layer 3 and the traffic contracts in order to have a basic prediction of the incoming traffic.Moreover, it is important to note that the algorithm does not depend on the traffic profile (except basic information like mean and maximum throughput deduced from all the SLStraffic contracts).However it does not provide an accurate prediction as it does not depend on the traffic profile models.
In one hand, a drawback of such a solution is that it requires some cross layer mechanisms and adds dependencies between layer 2 and layer 3, in the other hand the proposed modifications bring a better consistency of the layer 2 and 3 for QoS support.The following section shows that it allows to reduce the delay at layer 3.

MECHANISMS
This section provides a first evaluation of the proposed mechanisms using a DVB-RCS simulator developed in C language.The relative confidence intervals provided in this paper are approximately 4%.
The simulation context is introduced and both layer 2 modifications and resource sharing mechanisms are assessed.

A. Simulation context
IP/AAL5/ATM/DVB-RCS is the considered protocol stack.The topology of the simulated DVB-RCS system is composed of four identical RCSTs for a single NCC (a small number of RCST is considered to illustrate the QoS mechanisms).Four identical traffic contracts are established between each RCST and the NCC specifying the CRA, the RBDC mean, the RBDC max, the VBDC mean and the VBDC max.The schedulers implemented at layer 3 and layer 2 (when several queues are present) are Priority Queuing (PQ).Taking into account all the traffic contracts with terminal users, the RCSTs are able to compute the expected incoming throughputs (mean and maximum).
The total available resource is about 1000 kbps, including a CRA equal to 10kbps per RCST.It remains about 960kbps to share between all the RBDC and VBDC requests.In the simulated system, the requests are sent every second.
The following traffic profiles have been considered.The VoIP sessions (mapped on the EF queues) follows a Poisson arrival, and session durations are exponentially distributed with a mean duration of 3 min [15].Inside the sessions the throughputs are constant with rates and constant packet sizes [16] corresponding to various codec (LPC -54B; GSM -73B; G726-16 80B; -law 200B).Other session types (mapped on the AFi and BE queues) are modeled by Poisson arrival sessions, with exponentially distributed session durations, Poisson packet arrival inside the sessions, and various packet sizes (e.g.WWW packet size distribution is bimodal; 40bytes long packets and 1500 bytes long packets).

B. Impact of the modifications of the layer 2 scheduling
As aforementioned, thanks to the regulation of the layer 3 scheduler output, the delays introduced by the layer 2 queuing are quite low and no loss occurs.The mean waiting times experienced by the packets are provided in The reduction of the number of queues at layer 2 to only one generates an additional delay for the high priority queues.The mean waiting time experienced by the packets (all the classes) is 18ms (+/-0.6ms).Therefore only EF packets are delayed in comparison with the case where 3 queues (EF, AF, BE) are used at layer 2. The additional delay is about 15ms, what is clearly not negligible; indeed it is added to the 10 ms introduced by the layer 3.However, in a DVB-RCS context, it could be acceptable as the propagation delay is about 500ms.

C. Request computing and allocation performances
In order to provide a first performance evaluation, we have compared it to a simple request computing where the requests are equal to the observed incoming traffics without priority request and the same NCC allocation algorithm (as the one presented above) but without priority treatment.Figure 4 compares the queue delays at layer 3 for the AF2 queue with and without the proposed mechanisms.For the AF2 queue, the difference between the curves is quite low (about 5%-1ms).For AF3 queue (and a 0.8 load), the difference between the curves is more important (about 10%-9ms) and illustrates the gain of the proposed mechanisms.For the BE queue the difference is negligible.For the five other queues the proposed mechanisms allow to reduce the delay introduced by layer 3 queuing.For some queues the delay reduction is quite significant (e.g. for the AF3 queue, the gain is around 15%).This is mainly due to the prediction that reduces the effect of the delay between the request sending and the allocation reception.Indeed in case where no prediction is performed, the resources are always allocated with a 0.5 sec delay.Moreover the gain of the proposed mechanisms is higher when the load is high (except for the BE and EF queues) and higher when the CRA is low.
In both cases (with and without the proposed mechanisms) the loss rates are almost null (<0.5% except for the BE file in case of an average load of 0.95).The link utilization and the over allocation (resources allocated but not used by the RCSTs) are the same in both cases.Therefore the proposed mechanisms do not introduce resource wasting; the main difference is that they share the resources more efficiently.
The same simulations have been run with the stack IP/MPE/MPEG-2/DVB-RCS and consolidate the conclusions.

V. CONCLUSION AND FUTURE WORK
In this paper, QoS supports in DVB-RCS systems have been investigated.Some mechanisms to simplify layer 2 and to make layer 2 and layer 3 more consistent have been proposed and evaluated.They aim at improving the resource sharing in DVB-RCS systems.They mainly use the traffic contracts and the incoming traffic parameters in order to have a rough prediction and to compute priority and priority-less requests.The first performance assessment shows that these mechanisms allow to reduce the delay at layer 3 without resource wasting.The conclusions of simulation allow to consider the extension of the proposed mechanisms to other systems.Some additional studies would be interesting to extend and assess the mechanisms in the case of mesh topologies of DVB-RCS systems.As far as traffic model is concerned, traffic matrices closer to the ones corresponding to the Internet traffic could be used.
As an other part of future work, the extension of the proposed mechanisms for other satellite return link like DVB-S2 (for the return link) and the integration of these mechanisms to a BSM (Broadband Satellite Multimedia) QoS architecture [17] [18] are to be considered.

Figure 1 :
Figure 1: RCST architecture in a QoS support context

Figure 4 :
Figure 4: Layer 3 delay in the AF2 queue with a 0.8 load

Table 3
provides the delay introduced by layer 3 (in ms) queuing with and without the proposed mechanisms.Table4provides the saving (as a percentage).