Innovative DAMA algorithm for multimedia DVB-RCS system

Abstract

Satellite is often used as an access network in the Next Generation Networks landscape, where multimedia and real-time services are supported by return channels. However, these satellite return channels are a very limited resource with many terminal stations competing for its use, making its efficient assignation one of the key problems to solve in order to increase network performance. This article presents an innovative implementation of the resource allocation mechanism demand assigned multiple access (DAMA) applied to satellite return channel assignment, which provides support for dynamic allocation and quality-of-service. This resource allocation mechanism has been validated with the special purpose advanced Internet network emulator, using the test lab implementation to optimize traffic mapping and queue parameters directly in the field. The numerical results for the different test cases considered are presented, showing that the DAMA algorithm provided is an efficient way of assigning resources, and also helping in the comparison of the different capacity request mechanisms described in the standard.

1. Introduction

In the world of convergent multimedia communications and Next Generation Networks, satellite systems play an important role as access networks [1–3] due to their capability of providing global coverage, and recent research works [4–6] are pushing further the limits of this technology. However, the modern end user wants to access multimedia, real-time, and interactive services, demanding increasing amounts of bandwidth, through satellite systems, and with strong quality-of-service (QoS) requirements [7]. Coping with these requirements becomes a challenge for satellite networks, which, due to their specific space nature, present important limitations in capacity and capabilities.

Digital video broadcasting-return channel via satellite (DVB-RCS) [8–10] is a key European standard published by European Telecommunications Standards Institute (ETSI) focused on the specification of an interactive bi-directional channel inside a broadband satellite system, with which multimedia QoS-enabled IP communications are possible. The successor to this standard, called DVB-RCS2, has recently been approved in May 2012 [11–13]. The next generation of DVB-RCS systems must provide cost-effective solutions in order to be competitive with respect to other terrestrial access technologies.

The DVB-RCS standard has widely been used in systems deployed all around the world, as for instance in the AmerHis platform offered by Hispasat [14] or several other commercial solutions as detailed by the European Space Agency (ESA) [15].

However, DVB-RCS systems suffer from the typical problems of satellite architectures, including long delays and limited and expensive bandwidth. In the past, satellite systems divided the bandwidth in fixed allocations and therefore the number of users was limited, and it was quite clear that a more efficient approach had to be designed in order to make a more efficient use of that expensive bandwidth. The importance of bandwidth management is so high that in the new DVB-RCS2 standard, even random access to the medium is allowed in order to optimize resource usage.

The demand assigned multiple access (DAMA) [16] has been included in the specification of DVB-RCS and DVB-RCS2 as a resource allocation mechanism capable of dynamic channel assignment. However, the standard specification of DAMA does not define how different traffic classes have to be treated, prioritized, dropped, and relayed inside the satellite system. In addition, real-world implementations are usually proprietary to the vendor.

Therefore, the aim of this study is to design a specific implementation of the DAMA mechanism capable of dealing with the different requirements of next generation multimedia and real-time services, including QoS management, and validate and optimize it using a high fidelity test bed based on the special purpose emulator advanced internet network emulator (AINE) [17].

This article is organized as follows. Section 2 presents the DVB-RCS standard. Section 3 introduces some generalities about resource allocation mechanisms. In Section 4, the DAMA algorithm designed along this study is discussed. The testbed implemented, together with the emulation platform, and the measures obtained are described in Sections 5 and 6, respectively. Finally, Section 7 summarizes the conclusions of this study.

2. DVB-RCS system description

The DVB-RCS and DVB-RCS2 standards [8, 11] present the specification of a satellite system comprised by two channels, a broadcast channel, and an interaction channel. This interaction channel is bi-directional, meaning that information flows from the service provider towards the terminal, and from the terminals towards the service provider as well. For that, the interaction channel is divided into two paths, a forward interaction path (from the service provider to the user) which may be embedded within the broadcast channel; and a return interaction path (from the user to the service provider).

The satellite interaction network, as depicted in the scheme shown in Figure 1, is composed by the following entities

• Return channel satellite terminal (RCST): A terminal device providing access to the satellite network to an end-user.

• Network Control Center (NCC): A centralized entity in charge of control and monitoring functions, which sends timing and control signals (including resource assignments) using one or several feeders.

• Feeder: Transmits the forward link signal with multiplexed user data, control, and timing signals.

• Traffic gateway: Receives the RCST return signals and provides accounting functions, interactive services, and connections to other external service providers.

  Figure 1

  

  Scheme of DVB-RCS architecture.

One of the most important problems that DVB-RCS has to deal with is resource assignment, given that satellite bandwidth is scarce, expensive, and to be shared among all the terminal stations. For this purpose, the DVB-RCS standard defines different capacity request procedures (managed by the NCC) to allow the differential treatment of capacity requests coming from applications with specific QoS requirements, while trying to optimize resource usage. DVB-RCS2 carries on with the same definition of capacity request procedures, which are defined as follows:

• Continuous rate assignments (CRA) is rate capacity which shall be provided in full while required.

• Rate-based dynamic capacity (RBDC) is rate capacity which is requested dynamically by the RCST. RBDC capacity shall be provided in response to explicit requests from the RCST to the NCC, such requests being absolute.

• Volume-based demand assignment (VBDC) is volume capacity which is requested dynamically by the RCST. VBDC capacity shall be provided in response to explicit requests from the RCST to the NCC, in this case such requests being cumulative.

• Absolute volume-based demand assignment (AVBDC) is a variant of VBDC where VBDC capacity shall be provided in response to explicit requests from the RCST to the NCC, but such requests being absolute.

• Free capacity assignment (FCA) is volume capacity which shall be assigned to RCSTs from capacity which would be otherwise unused.

3. Resource allocation mechanisms

Nowadays, broadband satellite systems are requested to provide high bit rates to the end user in order to support new multimedia services with QoS capabilities. As bandwidth is a scarce resource in the wireless communications such as satellite, it is necessary to define strategies in order to efficiently exploit the frequency resources. The efficient management of the network resources requires a combination of methods and techniques between the NCC and the RCST terminal.

However, while the DVB-RCS and RCS2 [8, 11] standards specify different resource reservation classes, there is no definition on how they have to be implemented or treated inside the satellite system or the priority they receive, nor address other end-to-end networking issues. Therefore, the standard covers how terminals have to ask for resources, but not how the NCC assigns them competitively in the (more than likely) event of congestion. The objective of this article is thus to present an efficient policy that draws advantages from the dynamic allocation of the satellite bandwidth, trying to avoid any resource waste during the periods of inactivity or rate reduction of some traffic sources. This will additionally allow the implementation of QoS features, giving a higher priority to real-time communications (sensible to jitter and delay) in detriment of, for instance, bulk data download.

There are two primary strategies for assigning capacity to multiple users (RCSTs): fixed assignment and demand assignment.

In fixed assignment protocols like fixed assigned multiple access (FAMA) [18], the allocation of the channel bandwidth to a station is static, and independent of stations activities. This can be done by partitioning the bandwidth space into slots which are assigned in a predetermined fashion. In FAMA, the channel assignment is tightly controlled and is not adaptive to traffic changes. This can result in the waste of capacity when the traffic is asymmetric.

On the contrary, DAMA protocols (of which different variants exist [19, 20] with the common feature of dynamic assignment of resources) were initially designed exactly for satellite communications. In situations where the traffic pattern is random and unpredictable, fixed allocation of the channel bandwidth leads to inefficient use of transponder capacity. It is desirable to design medium access control (MAC) protocols that allocate capacity on demand in response to the station request for capacity. Dynamic allocation using reservation based on demand increases the transmission throughput, at the price of introducing additional delays and overhead related to the resource request and planning processes.

Combined free DAMA [21, 22] is the protocol chosen from all DAMA types since it allows the allocation of free capacity, which is a design requirement due to the existence of the FCA capacity request type defined in DVB-RCS specification.

Several research works have been carried out recently dealing with resource assignment and DAMA protocols within DVB-RCS. For instance, Chini et al. [23] present a resource allocation solution linking transport control protocol (TCP) and MAC layers for increasing efficiency. Gayraud and Berthou [24] study how to allow applications to take advantage of the QoS mechanisms implemented in the satellite access network, even if they are located in higher layers of the protocol stack and are not QoS enabled. Inzerilli et al. [25] report the results of the SATIP6 European project, describing a QoS architecture for DVB-RCS with the aim of differentiating IP flows to optimize resource utilization. Santoro and Pietrabissa [26] propose an algorithm for dynamically computing the capacity request with the maximum accuracy with respect to real application requirements in order to optimize usage of the link and minimize transmission delays in return channels. The European project SatSix produced a proposal for the inclusion of the IPv6 protocol in DVB-S2 and DVB-RCS satellite networks [27]. Morell et al. [28] take advantage of adaptive encoding schemes to propose a method for dynamic assignment of resources in DVB-RCS.

However, the literature does not present a complete specification of the DAMA algorithm. Some high-level models with very simplified features [29] are reported for the purpose of studying congestion, but only covering generalities and not allowing a complete implementation.

This article presents an innovative DAMA-based protocol dissected in the next sections.

4. DAMA protocol design

DAMA mechanisms define the way return link bandwidth resources are requested by the terminal and assigned by the NCC, which has to distribute available bandwidth among all active terminals. The DAMA mechanism relies on two logical entities: a DAMA agent (located in the RCST), and a DAMA controller (located in the NCC). Along this work, the protocols employed for communication between the entities during the resource asking process have been the same ones defined in the standards [8, 11].

It is worth mentioning again that while the DVB-RCS standard and even the SatLabs group [30] defines capacity request messages and even a certain number of QoS parameters and some general guidelines, this provides only a framework which leaves a lot of space for implementation decisions, specifically the resource management algorithms. As DVB-RCS system manufacturers do not make their specific implementation details publicly available, DAMA mechanisms used for this work (operating under the general scheme depicted in Figure 2) have been built on the basis of academic sources [31] and adapted in order to follow SatLabs System Recommendations v2 QoS [30]. The specific implementation has a big impact on the performance, as shown by the experimental results, and it is explained in detail in the following sections.

Figure 2

Resource allocation temporal diagram.

4.1. DAMA agent

Once the RCST is logged, the DAMA agent within the RCST continuously monitors bandwidth-related parameters (e.g., RCST queue lengths and queue input rates) and issues capacity request (of RBDC or VBDC type) to the DAMA controller. Both kinds of capacity requests are defined in this implementation in order to allow the agent choose the most suitable option for each specific traffic type, and also to allow the study of the differences between RBDC and VBDC during the experimental phase of this work.

The RCST periodically receives terminal burst time plan (TBTP) messages sent by the DAMA controller, containing information on assigned timeslot resources for the next super-frame (SF) period. The implementation developed in this study departs from SatLabs [30] in one aspect: the TBTP table includes information about the channel_ID associated to each timeslot. This facilitates keeping track of assigned and still pending resources, especially for the VBDC case.

4.1.1. Request classes and capacity requests

An RCST handles three types of request classes (RC): real-time (RT), critical data (CD), and best effort (BE) [32]. Each of these RCs may use either RBDC or VBDC type capacity requests, which are calculated as shown in Sections 4.1.2 and 4.1.3. Although the algorithms used are the same for all RCs, the required input parameters (i.e., queue lengths and input rates) are taken from those IP packet queues associated to the RC.

Figure 2 shows a temporal diagram of the resource request process. Each arbitrary request period k, the DAMA agent checks lengths, and incoming bytes of the different IP queues within the RCST and calculates RBDC and VBDC resource requests for each RC, CR_RBDC (capacity request RBDC), and CR_VBDC (capacity request VBDC), which may be forwarded or not to the DAMA controller, depending on the request opportunities (i.e., situations under which the agent is allowed to send a CR) as broadcasted by the DAMA controller in the TBTPs. Issued requests are “remembered” and taken into account when requesting further resources, so that the feedback delay of the system (i.e., the time between sending a request and receiving an answer for it) can be accounted for.

4.1.2. RBDC calculation

Each time a TBTP message is received RBDC resources to be requested at an arbitrary period k are calculated as follows

• First, required RBDC resources are calculated using the following equation:

  $$\mathit{CR}\_\mathit{RBDC}\left[k\right]=?r_{\mathrm{IN}}+max\left\{0,\frac{K}{T_c}\left(\begin{array}{l}\text{QueueLength}-T_C·r_{\mathit{IN}}-\\ -T_C{\displaystyle {?}_{i=1}^{n_{\mathit{FB}}}\mathit{CR}\_\mathit{RBD}{C}_{\mathit{Real}}\left[k-i\right]}\end{array}\right)\right\}?$$

  (1)

It has a first term associated to the incoming traffic rate (r_IN) and a second term, related to queue occupancy, required to recover from congestion. Table 1 describes the parameters of the equation.

Table 1 RBDC parameters

The algorithm then checks whether it is possible to send a CR and calculates CR_RBDC_Real as follows:

• If it is possible to send a capacity request:

  • ○ If CRA is used, subtract it from the capacity to be requested:

    $$\mathit{CR}\_\mathit{RBDC}\left[k\right]=max\left(0,\mathit{CR}\_\mathit{RBDC}\left[k\right]-\mathit{CRA}\right)$$

    (2)

  • ○ Apply granularities as specified in Bandwidth Granularity Section (see below).

  • ○ Limit requested capacity to RBDCmax:

    $$\begin{array}{l}if(\mathit{CR}\_\mathit{\text{RBDC}}[k]>RbdcMax)\\ \begin{array}{c}\hfill \mathit{CR}\_\mathit{RBDC}\left[k\right]=\mathit{RbdcMax}\hfill \end{array}\end{array}$$

    (3)

  • ○ Send Capacity Request to the DAMA Controller if capacity request is not null or previously sent request was not null.

  • ○ Set RBDC timer to RBDCtimeout.

  • ○ Set CR _RBDC_Real[k] = CR _RBDC[k]

• If it is not possible to send a capacity request, the DAMA agent assumes that previous RBDC requests are taken into account by the DAMA Controller until they expire after RBDCtimeout ms.

  • ○ If RBDC timer has expired: CR _RBDC_Real[k] = 0

  • ○ If not: CR _RBDC_Real[k] = CR _RBDC[k–1]

4.1.3. VBDC calculation

Whenever a TBTP message is received, the DAMA agent checks whether it is possible to issue a capacity request.

If this is the case, the following algorithm is applied

• Calculate required VBDC capacity using the following formula:

  $$\begin{array}{c}\mathit{CR}\_\mathit{VBDC}={\mathrm{Volume}}_{\mathrm{IN}}+\max \left\{0,K\left(\mathrm{QueueLenght}\right)\right\}\hfill \\ -{\mathrm{Volume}}_{\mathrm{IN}}-\mathrm{PendingVbdcCounter}\hfill \end{array}$$

  (4)

The first term is related to new volume needs and the second, related to queue occupancy, is needed to recover from congestion. Table 2 explains the equation’s parameters.

• Check that the maximum allowed backlog is not surpassed. In this case, the requested VBDC amount is limited:

  $$\begin{array}{l}If\left(\mathit{CR}\_\mathit{VBDC}+\mathit{PendingVbdcCounter}\ge \mathit{VbdcMaxBackLog}\right)\\ \mathit{\text{Then}}\\ \left\{\mathit{CR}\_\mathit{VBDC}=\mathit{VbdcMaxBackLog}-\mathit{PendingVbdcCounter}\right\}\end{array}$$

  (5)

• If capacity has to be requested (i.e., CR_VBDC > 0):

• ○ Apply granularities as specified in bandwidth granularity subsection below and update CR _VBDC value accordingly

• ○ Send VBDC request.

• ○ Reset VBDC_timer timer to VBDCTimeout (ms).

• ○ Update pending VBDC request counter:

  $$\begin{array}{c}\text{PendingVbdcCounter}=\text{PendingVbdcCounter}\hfill \\ +\mathit{CR}\_\mathit{VBDC}\hfill \end{array}$$

  (6)

• Finally, the DAMA agent always updates PendingVbdcCounter with assignments made for this SF period as follows

  $$\begin{array}{c}\text{PendingVbdcCounter}=\text{PendingVbdcCounter}\hfill \\ -\text{VbdcAssignment}\left[k\right]\hfill \end{array}$$

  (7)

  Where VbdcAssignment[k] (in bytes) corresponds to VBDC assignments made for the RC within the TBTP table.

Table 2 VBDC parameters

4.1.4. VBDC re-synchronization

Re-synchronization is a procedure required in order to handle anomalous situations like, for example, that

• The DAMA controller has not been able to assign required capacity due to congestion and has flushed requested queues.

• Issued capacity requests have been lost.

• RCST flushes queues.

It prevents dead-lock situations where the DAMA agent requires bandwidth, but no requests are issued (either because they have already been issued before or because VbdcMaxBackLog has been reached) and no assignments are made (because the DAMA controller is not conscious of the bandwidth needed or because of congestion).

Each time an RCST issues a VBDC capacity request, it sets the VBDC_Timer to VbdcTimeOut (expressed in ms). If this timer expires and PendingVbdcCounter is not zero, the re-synchronization procedure is triggered

• Set PendingVbdcCounter = 0.

Next VBDC CR message will be AVBDC instead of VBDC. After this CR, normal operation will be resumed.

4.1.5. Bandwidth granularity

A DVB-RCS system imposes a certain granularity when issuing CRs. The values in Tables 3 and 4 are applied.

Table 3 RBDC granularity

Table 4 VBDC granularity

For VBDC, volume units are asynchronous transfer mode (ATM) cells (53 bytes), i.e., an RCST can request between 0 and 216 kbytes.

4.2. DAMA controller

The DAMA controller receives Logon/off and CRs from the different DAMA agents of all active terminals. According to available bandwidth resources, current and past bandwidth requests and RCST RC parameters, it generates TBTP messages each SF period containing information on timeslots assigned to each RCST.

The DAMA controller maintains a data list for each RCST that is currently logged. This list includes RCST configuration (mainly RC parameters related to terminal SLA—service level agreement) and RCST state information (pending VBDC requests, etc.).

4.2.1. Logon process

When the DAMA controller receives a logon_request from an RCST, it accepts the request if associated CRA resources can be assigned.

When the DAMA controller receives a logoff_request from an RCST, it removes the RCST from the data list and removes CRA assignment.

4.2.2. Bandwidth scheduling process

The DAMA controller uses two algorithms. The first algorithm handles RCST data list updates and the second one handles the actual capacity assignment. These algorithms are invoked periodically in each SF. Since capacity requests from the RCSTs may arrive at any time during the SF, the scheduler stores these requests in an incoming request queue and processes them at the beginning of the next SF.

Note that the algorithms take into account a possible overbooking situation, i.e., total uplink capacity < total guaranteed capacity (see the following section).

The RCST data list update algorithm processes incoming capacity requests, and updates RBDC requests (refreshing RBDC timers) and cumulated VBDC requests.

The bandwidth assignment algorithm is in charge of capacity assignment. First it checks whether RBDC timers have expired and, if this is the case, set requests to zero. Then it assigns bandwidth starting with CRA, going on with the RT request class, then processing CD requests and finally serving BE requests. If, after this, bandwidth is still available, it distributes resources using FCA. Within the same request class, it always assigns RBDC before VBDC resources.

FCA resources are distributed taking into account issued VBDC requests, thus avoiding that resources are wasted on terminals with no or little on-going traffic. Resource share is proportional to the sum of RT, CD, or BE VBDC requests issued during the SF period.

Note that assignments are made in timeslots (i.e., as multiples of certain volume units). Assignments are always rounded down to the nearest volume unit multiple. The remaining bytes are handled by using fraction counters, as explained in more detail in Section 4.2.5.

Each terminal is limited by a maximum transmission capacity (512 kbps in case of consumer terminals and 2048 kbps in prosumer terminals) and by its SLA. Therefore, in each assignment it is necessary to check this limitation. The capacity will be assigned only if the limit has not been reached yet.

The DAMA controller informs in the TBTP table about the RC of the assigned resources by setting the Channel_Id value adequately. FCA resources use a specific Channel_Id value.

Note that use of timers associated to VBDC request is not considered mandatory, as these timers are redundant with the ones located within the DAMA agents (VBDCTimeout timers).

4.2.3. Overbooking strategy

The DAMA controller supports overbooking, i.e., that the aggregate bandwidth demand (including CRA and capacity requests) is above available virtual satellite network (VSN) bandwidth. The strategy to cope with this situation differs depending on the capacity request type:

• CRA—A logon request is denied if requested CRA resources cannot be allocated for the whole session. The RCST may retry later.

• RBDC—If available resources are not sufficient to cope with all RBDC requests, available bandwidth is shared fairly by assigning to RCST j a proportion r _j of available bandwidth, which depends on the requested amount:

  $$r_j=\frac{{\mathrm{Requested}\_\mathrm{amount}}_j}{{\displaystyle {?}_{\mathrm{i}}^{\mathrm{All}}{\mathrm{Requested}\_\mathrm{amount}}_{\mathrm{i}}}}$$

  (8)

• VBDC—This capacity request type is, in principle, not guaranteed, so that the term overbooking does not really apply. In any case, if resources have to be shared between a number of requesting terminals, the number of SF periods a RCST j has been in congestion (T _j ) is used to calculate the proportion r _j of available resources which correspond to this particular terminal:

  $$r_j=\frac{T_j}{{\displaystyle {?}_i^{\mathit{All}}{T}_i}}$$

  (9)

4.2.4. CRA fractions

Required CRA rates are specified in bps and, moreover, values may be smaller than the system bandwidth resolution, Resolution = 1 payload/SF. To enhance the CRA resolution, the number of slots assigned per SF period will not be necessarily constant but vary in order to adapt to the specified rate.

4.2.5. RBDC, VBDC, and FCA fractions

RBDC values are expressed in bps, but final bandwidth assignments are specified as a certain number of slots each SF period. In order to handle situations where fractions of slots have to be assigned [either because RBDC is not a multiple of system resolution (1 payload/SF) or because resources are shared between a number of requesting terminals in overbooking situations], the following method will be employed

For each RBDC assignment to a RCST:

• Round assignment value always to the lowest integer number of timeslots.

• Increment RBDCFractionCounter with the fraction of slot which could not be assigned.

Finally, the remaining timeslots will be assigned as follows:

For each remaining timeslot:

• Assign timeslot to RCST with highest RBDCFractionCounter.

  • Decrement RBDCFractionCounter for this RCST (note that the RBDCFractionCounter may get negative):

    $$\mathrm{RBDCFractionCounter}=\mathrm{RBDCFractionCounter}-1$$

    (10)

Note that the same reasoning and algorithm applies to VBDC and FCA type resources.

5. Test bed description

5.1. Test characterization

The modeled DVB-RCS system is mainly based on the TSS-A1 reference architecture described in ETSI standard TS 102 402 [32], which considers a network with star topology using a transparent satellite.

The considered scenario is a VSNwithin a real DVB-RCS system, with a dedicated capacity of 16 Mbps over the forward link and a dedicated capacity of 8 Mbps over the return link. The main system elements are a HUB station and a number of satellite terminals (RCSTs), which communicate with terrestrial networks through the HUB. The forward channel (from the HUB to the terminals) is compliant with DVB-S standard [34] while the return channel (from the terminals to the HUB) uses the DVB-RCS standard [8].

The HUB station includes an NCC, which, among other tasks, is in charge of terminal authentication, system synchronization, and resource allocation. In particular, the DAMA controller is the element within the NCC which processes capacity requests received from the different terminals and, based on the RCST profiles, assigns resources through the system’s TBTP table.

Testing characterization will be performed independently for the two user terminal profiles considered most typical within DVB-RCS arena: prosumer and consumer profiles.

• Prosumer terminal (up to 2048 kbps return link transmission capacity) refers to a terminal aggregating traffic from circa 50 end-users.

• Consumer terminal (up to 512 kbps return link transmission capacity) refers to a terminal aggregating traffic from only one end-user.

And the following configuration values (Table 5):

Table 5 Configuration values

5.2. Emulation platform

In order to emulate DVB-RCS, the AINE [17] emulation platform will be used. Figure 3 illustrates the interface between real-world applications and equipment and emulated elements.

Figure 3

AINE emulation platform interfaces.

AINE emulates the impairments experienced by an IP packet from the moment it enters the RCST hardware through its LAN interface until it exits the terrestrial WAN (after traversing the HUB) and, obviously, the other way round. Customer premises equipment connected to RCSTs and terrestrial network servers (e.g., Web servers) attached to the Internet are not emulated, but, instead, real computer hardware, TCP/IP stacks, and applications are used.

The AINE platform is able to emulate up to 51 logged RCSTs, each of them with full functionality.

Traffic entering the AINE through its LAN interface is assigned to the different RCSTs according to a table mapping IP addresses and TCP/UDP ports to the different emulated terminals.

The complete emulated DVB-RCS system model, which runs in the AINE, is shown in Figure 4.

Figure 4

DVB-RCS system model.

6. Measurements

Two different test cases have been studied using DAMA algorithm in order to analyze its behavior.

6.1. Web browsing test

Web browsing using the HTTP is considered in the first test case. A single user browsing the web is modeled using two random variables:

• A random thinking time between web requests, following a Gamma distribution (shape = 0.9936, rate = 0.0504; mean of 35 s).

• A random web page length, following a Pareto distribution (a = 1.164, k = 104.25; mean of 123 kbytes).

Two different test cases are considered: “low load” and “full load” (Tables 6 and 7).

Table 6 Low load test case parameters

Table 7 Full load test case parameters

A first general observation is that RBDC has a very low efficiency for short-lived HTTP request TCP flows (only around 20%), while QoS only benefits slightly from over-assignments (see Figure 5).

Figure 5

Goodput comparison between consumer and prosumer profiles (kbps).

The reasons behind inefficient RBDC behavior are related to the RBDC timeout functionality. Note that while the DAMA controller does not receive a new RBDC request from a certain terminal, it maintains the assignments during a certain timeout period (600 ms in our emulation). When the traffic flow is more or less continuous, impact on overall efficiency is low. However, with more irregular traffic like HTTP, this leads to low resource utilization.

A rather significant impact is observed in Figures 6 and 7 for the prosumer case, where response times degrade considerably. For VBDC, mean value increases about 2 s, but maximum value is very high (close to 19 s). Behavior is even worse for RBDC: mean response times are around 13 s with a maximum value of nearly 25 s. Moreover, five web requests could not be completed, probably because of time-out errors.

Figure 6

Response time with low/full load—prosumer & VBDC.

Figure 7

Response Time with low/full load—prosumer & RBDC.

This behavior can be explained considering the way RBDC resources are shared in case of overbooking (i.e., when the sum of requested RBDC resources is higher than the available bandwidth).

With VBDC, effects of load are not as negative as for RBDC. However, while mean response time values are reasonable, maximum values are sometimes unacceptably high.

6.2. Videoconference test

The second test will be focused on a real videoconference call, using a standard videoconference software (Gnomemeeting/Ekiga[35]).The test consists on establishing a single real videoconference call handled by a consumer RCST and executed both for VBDC and RBDC.

6.2.1. VBDC

Figures 8 and 9 represent resource request/assignment behavior for VBDC. The initial request peak is associated to the traffic volume accumulated during the time period the terminal is waiting for a request sending opportunity (i.e., a SYNC slot, as no traffic is active). Afterwards, requests adapt to incoming data rate, although now and then requests are five times higher than the mean. Likewise, pending VBDC requests present also reasonable values (requests * feedback delay).

Figure 8

Pending VBDC requests (bytes).

Figure 9

Assigned bandwidth (kbps)—VBDC.

6.2.2. RBDC

Figures 10 and 11 represent resource request/assignment behavior for RBDC. Note how RBDC requests are more restrictive than VBDC requests, as they are limited by RBDCmax to 320 kbps. Assignments are very similar to requests, as there is no congestion.

Figure 10

RBDC requests (kbps).

Figure 11

Assigned bandwidth (timeslots/SF)—RBDC.

Resource utilization efficiency is calculated as the ratio between bytes used to transmit MAC packets and bytes assigned by the DAMA controller. For VBDC, this ratio is 96.4% while for RBDC this ratio is 99.8%. Efficiency for RBDC is rather high, mainly because the small SF period (25 ms) allows that RBDC requests are updated frequently. This confirms that difference observed in delay is caused by VBDC not using resources as efficiently as RBDC. However, efficiency reduction is very small, while videoconference call quality is enhanced significantly.

The videoconference test case has revealed the impact of rounding issues. It shows that if VBDC and RBDC requests can be sent each SF period, RBDC capacity requests have a better resolution than VBDC: VBDC requests have to be rounded up to an entire number of ATM cells (i.e., resolution of 17 kbps), whereas RBDC requests can have a resolution of as low as 2 kbps. This helps to reduce over-requesting.

7. Conclusions

This article presents the design and test of a DAMA mechanism implementation, providing guidelines on several aspects related to this assignment mechanism.

Besides analyzing DAMA impact on QoS from a more qualitative point of view, the article provides quantitative QoS and resource utilization efficiency measurements for different test conditions and even for real applications.

In general, in the presented DAMA algorithm implementation, VBDC resource mapping performs better than RBDC resource mapping. Normally, VBDC conveys bandwidth needs to the DAMA controller more effectively than RBDC. Note that VBDC can be limited in two ways: either by limiting VBDC requests to VBDCmax or by allowing VBDC requests higher than VBDCmax, but limiting the total outstanding volume to MaxBackLog.

Some performance advantages of VBDC versus RBDC observed under congestion are related to the specific design of the DAMA controller algorithm defined in this article. Another disadvantage of RBDC versus VBDC is that it is less efficient when capacity request sending opportunities are low (e.g., when traffic starts after a silence period or when traffic is bursty), as RBDC relies on the RBDC timeout mechanism while VBDC directly indicates the amount of required resources.

However, in favor of RBDC it must be said that its capacity requests have a better resolution than VBDC. VBDC requests have to be rounded up to an entire number of ATM cells (i.e., resolution of 17 kbps), whereas RBDC requests can have a resolution of as low as 2 kbps. This reduces over-requesting under some conditions.

From the study presented in this article, some issues could be interesting subject for further investigation (e.g., the mapping of DVB-RCS capacity types with other technologies as wireless [36]) and give guidelines on some aspects related to DAMA mechanism implementation (contributions to SatLabs forum). Another open point is whether the mix of capacity request types (RBDC and VBDC), for instance by alternating them in time, may provide advantages either from a resource utilization or QoS performance point of view.

The support of a connection control protocol by the DVB-RCS standard opens up a complete set of new QoS issues to be investigated, going from the impact of connection establishment delays on experienced QoS to the adequate co-existence of conventional and new capacity request methods.