P45/1

SATIP6 : Satellite Testbed for Next Generation Protocols

O. Alphand, P. Berthou and T. Gayraud from LAAS-CNRS, Toulouse, France S. Josset from Alcatel Space, Toulouse, France

E.Fromentin from AQL, Rennes, France

Abstract Evaluating performances over real data links or network is often costly, even impossible for systems in development phase. In such situation, emulation is the key to provide a low cost and demonstrative platform. The main problem is to overcome the emulation weakness which is the accuracy of the model reproducing the systems to be evaluated . Owing to its modular design and implementation, the SATIP6 satellite emulation platform, presented in this paper, is able to emulate a complete DVB-RCS (Digital Video Broadcasting – Return Channel via Satellite) system in a realistic and flexible way. It is possible to configure the platform to simulate a transparent DVB-RCS system dimensioned around a single Hub, or to simulate a system using a regenerative satellite with an on-board switching matrix only by changing some configuration files. A DVB-RCS protocol stack is implemented, and the modulation/coding part is simulated in real time thanks to pre-calculated BER files. A DiffServ-like QoS Architecture that couples MAC and IP-Layer QoS mechanisms has also been implemented. The platform being developped, the next step was to optimally tune the different modules that comprises the satellite platform. In this paper, we mainly focus on the QoS and DAMA (Demand Assignment Multiple Access) modules. For such an evaluation, we evaluate application end-to-end QoS performances according to DAMA. Finally, experimental results enable us to determine the most significant parameters and how to tune them to observe enhanced multimedia applications performances.

I. Introduction Evaluating performances over real data links or network is often costly, 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 modelisation 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 behavior for instance. For these reasons, the choice was made for the IST SATIP6 [1] project 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 terrestrian networks. This paper first gives a concise overview of the SATIP6 project, then briefly sums up the main functionnalities of DVB-RCS satellite systems and finally describes the experimental platform configuration that was adopted. The second section depicts the design and the implementation of this full DVB-S/RCS emulated satellite platform. It mainly focuses on the satellite Physical and Data Link layers emulation techniques and the final QoS Architecture that was retained to provide differentiated QoS on a satellite network. The final section evaluates the end-to-end QoS experienced by multimedia applications through the satellite. The MAC layer is tuned to provide the best results between multimedia applications behaviour and satellite network efficiency.

II. The SATIP6 Project

A. SATIP6 objectives The aims of SATIP6 projects were to evaluate and demonstrate key issues of the integration of satellite-based access networks into the Internet in order to offer multimedia services over wide areas. IP has served as the common denominator to allow interoperability for services and transport technology within integrated networks. Most immediate technical issues facing satellite broadband access in the coming years have been examined, namely the functions to be implemented in the protocol layer between physical medium access and the IP Layer (i.e. typically layer 2). The project has considered two stages:

P45/2

short-to-medium term focussing on better adaptation of DVB-RCS access for IP services with current satellites

longer term in which protocols more optimised for IPv6 will be introduced, with next generation satellites (including both transparent and regenerative payloads)

This paper is related to the second step. In this step, the shorter term solutions defined for IP/DVB-RCS have been extended and adapted for more advanced satellite systems supplemented with mesh connectivity (directly between users) via transparent or regenerative payloads (with on-board packet switching). In addition, satellite integration into NGN (Next Generation Networks), based on IPv6 and associated with a range of advanced features has been targeted : Security [5], Mobility, Performance Enhancing Proxy, Multicast. Moreover Layer 2 protocols, such as “IP-dedicated” has been defined for more optimized transport of IPv6 over satellite compared with MPLS). One of the starting points of the SATIP6 project was the architecture developed in the IST project BRAHMS [8], and adopted within the ETSI BSM group. The SATIP6 scenario, shown in Fig. 1, consists in a geostationary satellite network with onboard switching capabilities, Ka MF-TDMA (Multiple Frequency- Time Division Multiple Access) uplinks and Ku TDM (Time Division Multiplexed ) downlinks. Satellite Terminals (STs) provide single PC or LANs with the access to the network, while Gateways (GTs) allows the connection with Internet core networks. The uplink access from each ST is managed through DVB-RCS (Return Channel via Satellite) interface, while transmission from GTs is implemented through DVB-S interfaces. STs and Gateways are boundary devices between the satellite and terrestrial links and play an important role in access to satellite resources and hence in QoS provision. In the SATIP6 architecture both devices implement IP routing and has an IP interface on the satellite segment.

Figure 1 : SATIP6 architecture

On the left of Figure 1 is depicted the end-user side of the platform. On the right is shown the provider/enterprise/Internet side of the platform. We distinguish also between the satellite network side (in the middle) and the IP network sides (on left and right ends), the frontier being delimited by satellite terminals. The satellite in our emulation covers primarily one spot. However this is not a restriction: we are able to emulate multi-spot covering. Inside a spot several channels are allocated: for the forward DVB-S path, for the return DVB-RCS path, and also a dedicated control channel. Three main components have to be distinguished in the satellite network side (middle):

• the Satellite Emulator (SE) • the Satellite Terminals (ST) • the Network Control Center (NCC)

End user

End user DVB-RCS

DVB-RCS

Server

End user

IPv6 network side, end-user or left side Satellite network side, middle side IPv6 network side, internet or right side

DVB-S spot

DVB-S spotST

STSTNCC

IPv6 Backbone

Gateway

P45/3

The SE is a regenerative satellite that use IP-dedicated [7] as an optimization layer for switching frames. Functionally ST acts as routers. That is to say that Satellite Network is considered as a special link in classical network point of view. By using special mechanisms (IP-dedicated address resolution) they are able to transmit IP packets from one side of the IP network to the other side of the IP network.

B. Introduction to DVB-RCS Architecture The first DVB norm described a transmission scheme based on MPEG-2 (Motion Picture Expert Group) video compression and transmission schemes, using MPEG-TS (MPEG-Transport Stream). This latter was adapted for satellite systems through DVB-S (DVB transmission via satellite) that defined a series of options for sending MPEG-TS packets over satellite links and that is nowadays commonly used for Digital TV. The User Satellite Terminals could therefore only received DVB-S frames from the satellite, but did not have the ability to send any traffic towards the satellite. In 1999, the ETSI proposed a standard for a return channel via satellite, the DVB-RCS [4], which supplement the STs with the ability to transmit traffic towards the satellite. From this point, two types of satellite can be defined:

Transparent satellite simply forward the signal received with no additionnal processing Regeneratice satellite with Onboard Switching Payload is able to demodulate, process and

remodulate the signal it carries and so to convert a DVB-S signal into a DVB-RCS one Furthermore, DVB-RCS requires a Medium Access Control (MAC) protocol since RCSTs (Return Channel Satellite Terminals) can simultaneously access the return channel capacity. The mostly used method is the MF-TDMA one which 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 the RCSTs 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 RCSTs is the NCC that centralizes the satellite ressource management. Thus it periodically broadcasts a signaling frame, the TBTP (Terminal Burst Time Plan) that contains the information on which RCSTs relies to know when to transmit their bursts. At last, the notion of Demand Assigned Multiple Access is introduced. It relies on the RCSTs ability to request dynamically capacities to the NCC which allows a regular update of the TBTP to fit to the RCSTs respective traffic load. However the request/assignment cycle takes time and the challenge in DAMA implementations is to minimise time delays and maximise the use of network ressources. To achieve this, three types of capacity assignments are considered in the SATIP6 project:

A static capacity assignment : a fixed RT bandwidth allocated every superframe at the RCSTs logon which is substracted to the total bandwidth available. No further static assignment is possible after RCSTs logon. Since this pre-assigned capacity is always available to the connection, low delays can be granted

A dynamic capacity assignment : Dama algorithm located in NCC allocates ATM cells for so-called "Non Real Time" flows according to the periodic RCST VDBC (Volume Dynamic Based Capacity) Requests. The advantage is that capacity assignments to the connections can actually track the traffic offered to the satellite system and hence an efficient capacity exploitation can be achieved

A free capacity assignment (FCA) provides extra capacities that is freely shared between the logon RCSTs. It was introduced in order to allocate a minimum of NRT bandwidth even for not requesting logon RCST which enables to serve at once low sporadic traffic like ping or TCP acknowledgements that would otherwise have to wait for a whole Request/Assignment to be served.

DVB-S

MPEG-2 TS

IP

Downlink (Forward link)

DVB-RCS

ATM

IP Dedicated

Uplink (Return link)

Figure 2 : SATIP6 satellite protocolstack

P45/4

Thanks to this introduction, we are able to present the SATIP6 satellite protocol stack that was finally adopted and emulated in SATIP6 testbed (Figure 2).

C. Experimental platform

To validate our proposal, a testbed has been designed. The testbed that has been developped is able to emulate the three main parts of a satellite communication system (SE, ST, NCC). It is described in Fig. 2. The middle side interconnects two user LANs (individual user, company subsidiaries …) and the right LAN (LAN 3), acting as an Internet Service Provider site or as the company headquarters. LAN 3 provides also Internet interconnection, using native IPv6. Each LAN consists of one Satellite Terminal (ST) and several user workstations (WS).

Figure 3 : Full SATIP6 testbed

III. The SATIP6 architecture implementation

A. The Satellite System Emulation In order to have the most modular platform and so preserves room for future evolution, stringent requirements were fixed before the development phase. At first, the aim was to take advantage of a linux system (Red Hat 9 Distribution) which natively supports Ipv6 and a wide panel of IPv6 applications (Apache as HTTP Server, Mozilla as HTTP Client, Vsftpd as FTP Server, Gnomemeeting for Videoconferencing, VideoLanClient for Videostreaming). Then the next step was to decide how to implement the Satellite Protocol stack and the main satellite systems functionnalities. We choose to directly reuse a derived GPL product for the runtime. It is called Margouilla [2], a C++ runtime that provides platform independent messaging, a set of common blocs ready to use (IP/ATM/Ethernet layers…), a graphical editor with SDL design style and utilities package offers basic tools, such as Configuration file and logging mechanisms for error and debug messages. For the purpose of SATIP6, Margouilla at first enables the running of automatically generated piece of codes compiled from an SDL description. Secondly, its runtime provides us with a multi-platform synchronisation toolkit and finally stands for a formal platform for collaborative development. The final SATIP6 protocol stack is the following one that is detailed in Figure 4. The bloc that were developped within the Margouilla runtime are : The satellite carrier package is responsible for the different satellite carriers emulation on top of

Ethernet (DVB-RCS, DVB-S and Signaling Channels) and the simulation of typical satellite bit errors and delay

The DVB-S/RCS package implements a framing structure compliant with the DVB-S/RCS standards. and fills DVB-RCS frames with ATM-like cells coming from the IP-dedicated layer. In order to achieve proper QoS, this layer manages synchronisation and queues according to the authorisations a DAMA algorithm delivers.

SATLAN

WS12 WS22

LAN2

ST2

WS13

LAN3

ST3

WS23

GW3

NCCSatellite Emulator

IPv6 Backbone

WS11 WS21

LAN1

ST1

P45/5

The DAMA package implements the DAMA algorithms used to manage the satellite ressources allocation at layer 2

The IP Dedicated package implements the IP dedicated layer which is responsible for segmentation and reassembly functionnalities and for a specific tagging mechanism targeted towards IP. It also implements a dynamic address resolution protocol in order to use that mechanism.

The IP QoS Package implements common mechanisms to enable differentiation at this level. It treats packets incoming from IP network and forwarded on the DVB-DCS uplink according to a committed QoS behaviour and is in charge of discriminating, regulating and scheduling this traffic in to 3 classes of Service (Real-Time, non Real-Time and Best Effort).

A detailed description of the way the different layers are emulated is done through the following paragraphs.

User

Terminal

ST

IPv6

ethernet

ip_select bloc_IP_QoS

QoS_server

QoS_agent

IP_dedicated

dvb_rcs_tal

sat_carrier sat_carrier

rcs_sat

ip_dedicated_switch

TagTable

sat_carrier

bloc_dvb_rcs_ncc

DAMA serverDAMA agent

Sat Emu NCC

ip_dedicated_ncc

Figure 4 : SATIP6 emulation platform architecture

1. The satellite carrier emulation The satellite carrier emulation is designed to operate on top of Ethernet frames and for each satellite channel corresponds an Ethernet multicast address. Ethernet was chosen for its native broadcast abilities and also for its high bandwidth capacities. For each spot, we distinguish at least 4 channels : There is a dedicated channel for each data DVB-S flow spot descending from the satellite (one channel per DVB-S

flow per spot) There is a dedicated channel for each data DVB-RCS flow on each spot ascending to the satellite There are two dedicated channels for control frames (connection request, connection confirm, TBTP, …) one for

the ascending flow and one for the descending flow

2. The Satellite Link Emulation The satellite emulator can both act as a transparent or a regenerative satellite and it was able to simulate spot changes and signal format conversion. Indeed, the regenerative satellite with an onboard switching matrix processes DVB-RCS frames, switches ATM cells received from these frames and rebuilds them into DVB-S frames. This switching table could be updated by appropriated control message. Currently, it is allocated statically. However the main functionnality of the SE is its satellite link emulation module which simulates in real time the moduling/coding part thanks to precalculated BER files. The error model is based on precalculated data files from IST BRAHMS project. In addition to inject bit errors, the satellite emulator introduces delay and jitter that can be also tuned. The default values were put to 250ms with no jitter.

3. Medium Access Control/DAMA This section deals with the MAC allocation procedure that was adopted in the SATIP6 demonstrator. Before detailing this procedure, we must precise two techniques on which the allocation procedure is based : the synchronisation emulation, the DVB-RCS frame transmission emulation over Ethernet.

P45/6

The synchronisation emulation is carried out by emitting Ethernet frame at fixed instant on all ST (super frame tick) and then internally by awaking processes each frame ticks (50ms) to send already queued packet. In this process, we are limited by a 10ms granularity imposed by Linux. The default reference values on which the allocation procedure is based are :

The superframe composed of 10 internal frames

Frame duration of 50ms Periodicity of ATM cells allocation on

a super frame basis: i.e. each 500ms. The reproduction of a typical DVB-RCS allocation structure based on ATM bursts cannot be exploited using classical ethernet hardware interface since there is no possibility for a given station to fill an ethernet frame emitted by another station. Therefore, we have to use Ethernet frames to transport our DVB frames. However, transmitting an ethernet frame every time a RCST should fill its dedicated timeslots of the current superframe generates too much overhead. On the opposite, transmitting the whole pool of ATM cells allocated by the NCC for this superframe in a unique Ethernet frame leads to a burst effect on Ethernet layer that causes loss of packets. Thus ATM cells allocated to a RCST for a superframe are shared among DVB-RCS frames encapsulated in Ethernet frames that are efficiently distributed over the superframe duration. The efficiency is directly linked to the number of ATM cells to transmit. For instance, very small isolated traffic (TCP Acknowledgment or ping) are not spanned on the length of the superframe but transmitted as soon as possible. The allocation procedure implementation in the demonstrator is described below: o At log-on STs request a fixed RT bandwidth, which is allocated by subtracting the asked capacity to the

total bandwidth available. There is no further allocation demand for that kind of traffic. o STs mainly do their request according to the number of ATM cells that feeds the NRT MAC queue

during the previous superframe and the NRT MAC buffer queue length at the beginning of the current superframe. Formulas and algorithms are detailed in [3]. In particular there is an overprovision factor that takes into account sizes of queues during the 2 last super frames. Its goal is to enhance capacity requests according to the traffic recently experienced, it helps voiding the queues if congestion occurred. It is governed by a factor (1-α). If α is equal to 0 there is maximal overprovision. If it is equal to 1 there is no overprovision.

o Each CR is launched at the beginning of a super frame. Each CR is then delayed by the satellite emulator and reach NCC 250ms±10ms (due to 10ms awoke rate in the Satellite Emulator as explained above) after. CRs are processed by NCC upon arrival.

o NCC computes allocations at the beginning of each super frame according to an internal SACT table based on CR received. Authorisations are sent back to STs using a TBTP table (if fca > 0, even not requesting logged on station will receive extra-bandwidth if available).

o Upon reception of a TBTP, allocation are stored by ST and used in the next super frame

B. The QoS Architecture

1. MAC Layer The main role of the MAC Layer DAMA component is to manage the contented access to uplink bandwidth.

IP-DVB/RCS InterfaceSegmentation

DAMA controlFraming

NRT DVB frames

DVB-RCS frames

TBTP FrameMapping

CapacityrequestsTBTP

RT DVB frames

To/From NCCTo Satellite

Threshold

Transmissionallowed/denied

Classification

PQ

Traffic Shaping/Policing

IP downstream flowto transmit

IP classes

RT IP packets

EDFEDF EDFEDF

Sch

edul

ing

BENRTRT

Figure 5 : SATIP6 QoS Architecture

P45/7

Having defined in section III.A.3 the main steps of the allocation procedure implementation in the demonstrator, we still need to link the QoS at the MAC Layer and at IP Layer, define how IP Queues are mapped onto those MAC queues and the interaction between the IP and MAC Layer. Thus the DVB-RCS RT frame emission only consumes statically assigned slots when the number of NRT frames transmitted during a superframe is only linked to the dynamic allocated slots thanks to the DAMA. All the ATM cells resulting from the segmentation of RT IP Packets are positionned into the RT MAC queue, when IP BE and NRT packets are placed into the NRT MAC Queue. Finally, in order to prevent MAC-layer buffer overflows, the scheduler no more forward IP Packets to the MAC Layer if the NRT MAC queue length exceeds a predefined threshold.

2. IP Layer The IP Layer component defining QoS classes and implementing buffer and bandwidth management mechanisms to assure fair allocation of bandwidth among contending users/applications and to control queuing delays. Differentiated Services are performed through 3 Classes of Services (RT, NRT and BE):

Real Time (VoIP, Videoconference) : delay and jitter sensitive traffic with hard constraints that must take benefit from the guarantees provided by the static capacity assignment defined in III.A.3

Non Real Time (Multiplayer gaming, Videostreaming): tolerant to delay, jitter and loss threshold. A minimum bandwidth is needed and therefore can resort to use dynamic capacity assignment.

Best Effort (Web, E-Mail …): All the traffic that can recover from medium losses and support high delay

RT and NRT traffic is policed and shaped while BE is not policed.

IV. Multimedia Application level Quality of service evaluation

The satellite platform made it possible to test and to validate in real conditions various strategies of management of resource and to test the impact of DAMA on the behaviour of the applications. The spectrum of the quality of service measurement at the application level is very large. In this study, we were mainly interested in evaluating the behaviour of Interactive applications including temporally constrained applications using video or audio streams and over NGN satellite QoS architecture.

A. Evaluation Process

This section presents the steps followed to evaluate the quality of service experienced by the application in the SATIP6 context. At first, the performance evaluation of network architecture cannot be done without accurate timing support. Monitoring the instantaneous delay of the network needs for instance to time stamp the sender packets and measure the difference at the receiver side between the local clock and the time stamp. The measurement is valid only if the sender and the receiver clocks are synchronised. To obtain sufficient accuracy a parallel dedicated network linking the workstations was built and was used to setup the NTP network. Secondly, application traffic profil reproductibility must be possible from one experiment to another in order to establish relevant comparisons between the results obtained in different conditions. Our capture and replaying software enables us to extract profiles from real experiments (for instance we capture the traffic during an audio conference session) and to easily replay the recorded traffic profil. Moreover, “replayed data” are time stamped so it becomes easy to monitor the network delay for the given applications. Thus, a set of typical application profiles have been defined and captured from Gnomemeeting (videoconferencing) and VideoLanClient (Videostreaming). Tableau 1 sums up their characteristics. Thirdly, the metrics that have the most significant influence on the end-to-end quality of an application are : Bandwidth, Delay, Jitter, Packet Loss and the Loss Pattern (burstiness). Furthermore, we can also make some assumptions on this parameters correlation. If the available bandwidth is insufficient for the application streams the delay between a data production and the delivering increase. As said previously, the jitter can be absorbed by a presentation buffer, but it increases delay. Except packet error (with FEC techniques the bit error

P45/8

rate and the packet error rate are very low), losses are mainly due to packet drops. The packet drop rate is mainly related to the play out buffer size and then it is related to the delay tolerated by the application. In

conclusion, in this particular context, all these parameters are related to the tolerated delay. If the delay tolerated by the application is short (for interactivity consideration for instance) the packet losses will be higher than if the accepted delay is high (streaming for instance).

Finally, after a short pre-campaign of test, five parameters were selected among all the customizable parameters of the platform to study their impact on applications behaviour.

The SAT BER. The bit error rate of the satellite system influences the number of packet dropped because of errors. This has a direct impact on the application restitution quality. If the application is error tolerant, as many multimedia applications, the impact is low; else it is non-neglected. Bit error rate is expressed in bit at the lower layer level. Values chosen for the experimentations ber = (0, 10-8, 10-6) mean (none, medium, high)

DAMA anticipation (α). This is the overprovisioning factor described in section III.A.3. Its goal is to enhance capacity requests according to the traffic recently experienced. Values chosen for the experimentations α = (1, 0.5, 0) means (none, medium, maximum)

DAMA Free Capacity Assignment (fca). This parameter fixes a given amount of bandwidth (if available) for each ST which is reserved for its non real-time traffic. For instance fca=80 gives 80 Kbits/s to the non real-time traffic. Values chosen for the experimentations fca = (0, 80, 1000) means (none, medium, very high)

Satellite network Load. This is the amount of the global satellite network bandwidth taken by other traffic. Values chosen for the experimentations Load = (0, 40%, 80%) means (free, loaded, congested)

Service. This is the IP class of service selected for the application streams. Service = (BE, NRT, RT)

Besides, default values were applied to all the other customizable parameters : Frame duration (50ms), Superframe duration (500ms = ten frames), Satellite Delay (250ms), Jitter = 10ms, RT bandwidth per ST (1Mbps), Total Satellite DVB-RCS Bandwidth (6 Mbps), maximum NRT capacity request per ST (up to 2Mbps).

B. Results

The impact of each of the five parameters presented before is evaluated as soon as possible independently. The platform is configured in what has been called a “basic configuration” that corresponds to the lower value of these parameters. Then, each parameter is tuned separately and the different application profiles are tested over the satellite emulator.

Sat emulator ST Workstation config BER α fca load service basic 0 0 0 kbits/s 0% Best Effort Nominal 10-8 0.5 80 kbits/s 40% FTP

Figure 7 - Configuration of the satip6 emulator

1. Bit Error Rate The bit error rate impacts the packet error rate because of the checksum control at each network architecture layer. If a single bit error is detected in a packet, either the corrupted bit can be deduced from the FEC, either the packet is discarded. At the application level, only the packet loss rate (PER) is visible. The probability to get a corrupted packet (the packet has thrown each layer without being detected as corrupted) is very low. In fact, the main application influence on the packet loss rate is related to the size of the emitted packets. The probability to get a corrupted bit in a packet is higher for big packets than for small packets.

Profiles Codecs Throughput Audio Conference G711 (HQ) 0 kbps to 64 kbps Audio Conference GSM (LQ) 0 kbps to 14 kbps Video Streaming Xvid (HQ) 250 kbps to 3.5Mbps Video Streaming MPEG (LQ) 1Mbps Audio Streaming MP3 (44Khz) 0 kbps to 250 kbps

Figure 6 : Audio and Video Codecs Characteristics

P45/9

worst case

BER = 10-4 Bad case

BER = 10-6 Nominal

BER = 10-8

Application profiles Packet size (bytes) PER PER PER GSM 111/144 1.04% 0.01% 0% G711 252 1.5% 0% 0.05% XVid 1316 6% 0.04% 0.01%

Tableau 1 - Packet error rate vs. Bit error rate

The bit error rate has a small impact on the packet loss rate for interactive application with small packet size profiles. These applications are generally losses tolerant (audio conference, video streaming …), then only a high loss rate (10-4) disturbs the application behavior. This impact is more consequent with TCP based applications.

2. DAMA anticipation (α) and Free Capacity Assignment (fca) Setting a Free Capacity Allocation of several Kbits/s intends to reduce the time to satisfy the bandwidth need of an application. In other words, if the application needs 30 Kbits/s (or additional 30 Kbits/s) it will be served immediately if some Free Capacity Allocated slots are immediately available instead of asking and waiting a capacity allocation from the NCC that takes more than one second and half (3 trips time). In consequence, this parameter is especially interesting for applications that frequently required capacity allocations. This is the case of application producing variable throughput. The following figures present the end to end delay for an audio conference profile using GSM and silence suppression coding techniques. The three following figures show the delay evolution with 3 different values of the fca factor. The Figure 8.(a) shows that if no fca is set, each throughput variation implies the need for a CR/CA sequence (capacity request/capacity allocation), then the delay is roughly 1600 ms. With fca =80 kbits/s [Figure 8.(b)] or fca =300 kbits/s [Figure 8.(c)] the impact on the application delay is immediate. Figure 8.(b) shows that the mean delay is 400ms (in comparison of 1100ms). The use of the silence suppression option generates a void traffic period. This disturbs the DAMA allocation and explains the delay observed on few packets after a silence. The remaining late packets are only experienced because of the silence suppression option.

Figure 8 : Delay graph for GSM profile (a) without fca, (b) fca = 80 kbits/s, (c) fca = 300 kbits/s

P45/10

The DAMA anticipation α factor is a dynamic over-provisioning factor. Its goal is to enhance capacity requests according to the traffic recently experienced. The α factor is especially useful to resolve congestion because the larger the capacity requests are the more important the additional capacity allocation is (the CA is based on the three previous capacity requests). A specific profile was used to artificially produce congestion with high throughput variation. A constant throughput of 256 kbit/s is sent throw the network during 20 seconds then doubled each 20 seconds until it reachs 2 Mbit/s. Every throughput variation of produced a congestion. The following graphics (Figure 9) present the packet delay experienced for this profile with the three different DAMA configurations. The oblique lines represent the time need to resolve congestions. The less the inclination is close to the verticality, the more the congestion resolution is long. For instance, when α=1 (no over allocation) the congestion duration for the 2Mbit/s period takes more than 45 seconds (from 115s to 160s). When α = 0.5, the congestion duration is only 30 seconds. With α=0, the congestion duration is near to 20 seconds. Of course this delay reduction applies to all kind of flow and especially to high quality video profile (Xvid). But the high variability of this profile do not provide a sufficiently clear impact to compare graphically the curves. The DAMA parameters provide a good way to tune the network satellite to be compliant with interactive multimedia applications. The FCA reduces the end to end delay for high variable throughput applications and especially those with a small traffic. The network efficiency is not degraded because the additional allocated bandwidth is only given when the network is non congested. On the opposite, the α factor impacts on the congestion duration and it’s impact is higher with high throughput applications. With α=0.5 congestion duration are considerably reduced and the bandwidth utilization is still over 90%.

3. Load & Service impact Demand Assigned Multiple Access (DAMA) is a deterministic method to control the medium access. Then, the network load could be high without leading to serious network problem (as for instance in Ethernet). In fact, a theoretical 100% bandwidth utilization could be reached without increasing the end to end delay. Figure 10 (a) shows a low end to end delay for an audio conference profile (G711) even when the network load is very high (80%). However, when the network is congested (b), the delay increases to 2620ms and packets are dropped because the sending buffers are full.

Figure 10 : End to end delay, (a) 80% network load, (b) 100% network load

Figure 9 : packet delay, (a) α= 1, (b)α = 0.5, (c) α = 0

P45/11

If in this bad condition a quality of service is selected for this application (Figure 11), the delay is reduced when the “voice” service (b) is used (the delay is then the network delay 300 ms) because no capacity requests are needed. If the “FTP” service (a) (based on the Non Real Time MAC Queue) is used the end to end delay is not reduced but, as the priority in the IP layer is higher than the Best Effort service, no losses are experienced. Table 2 gives the percentage losses for this flow according to selected service.

Service Network load

Best Effort FTP Voice

100% 0.97% 0.00% 0.00% 120% 7.49% 0.00% 0.00%

Table 2 - Loss percentage comparison with different service class

V. Conclusion This article has presented the emulation platform build during the satIP6 project. It aims at emulating the most accurately an IP over DVB-RCS satellite network. Both IPv4 and IPv6 are implemented. The difference between and emulator and a simulator is the possibility to use real systems and real applications on top of the emulator. The section IV has presented the evaluation of the quality of service experienced by interactive multimedia applications when using a new generation satellite network. A real application based traffic generator has been used to produce the presented results. However, the validity of these results has been confirmed by the real applications behaviour. It refutes the bias that interactive multimedia applications do not tolerate with the long delay of satellite networks. However, these networks need a fine resource management and an efficient quality of service signalisation. This is the first evaluation of the quality of service conducted on our platform. This has been proved to be complex and lot of works is still needed to find all the ins and outs of the QoS over new generation satellite networks. The platform involves for the moment a lot of computers and is hard to be configured. We are working now to reduce the number of computer from 11 to 1, thanks to the modular architecture provided by Margouilla. This will be an efficient tool for satellite networks research.

REFERENCE [1] IST SATIP6 Project (Contract IST-2001-34344), Home Page on http://satip6.tilab.com [2] Margouilla C++ Runtime : http://cqsoftware.free.fr/margouilla [3] E.Impenba, T.Inzerilli, Epaone, A.Pietrabissa, G.Tarquini. “QoS Support for Interactive Communication with DVB/RCS Satellites”, Universta di Roma “La Sapienza”, ISCC’04 [4] EN 301 790: “Digital Video Broadcasting (DVB) ; Interaction channel for satellite distribution systems” [5] L. Duquerroy, S. Josset, O.Alphand, P.Berthou, T. Gayraud “SatIPSec : an optimized solution for securing multicast and unicast satellite transmissions”, AIAA’04 [6] D. Miras, A Survey on network QoS needs of advanced Internet applications. Available at: http://www.internet2.edu/qos/wg/apps/fellowship/Docs/Internet2AppsQoSNeeds.pdf [7] S.Combes, S.Josset, P.Very, I.Buret, T.Zein, “Network Scenario for IP-Dedicated Satellite Access Scheme”, 8th Ka-Band Utilization Conference, 25-27 September 2002 Baveno (Italy) [8] Brahms IST project (Contract IST-99-10440), http://brahms.tilab.com

Figure 11: End to end delay, (a) FTP Service, (b) Voice Service