Guido Söldner
email: soeldner@cs.fau.de

Rüdiger Kapitza
email: rrkapitz@cs.fau.de

René Meier
email: rene.meier@cs.tcd.ie

Providing Context-Aware Adaptations Based on a Semantic Model

Smartphones and tablet PCs are on the verge of revolutionizing the information society by offering high quality applications and almost permanent connectivity to the Internet in a mobile world. They naturally support new applications that take advantage of context information like location, time and other environmental conditions. However, developing these novel context-aware applications is challenging as it is difficult to a priori anticipate their execution context and the adaptations that might be necessary to use new context information. This issue is reinforced by the semantic gap between the low-level technical realization of adaptation mechanisms and the demand to describe adaptations in abstract and comprehensible business terms. This paper presents programming support for context-aware adaptations based on a semantic model that builds on the AOCI framework. Using such a model, applications and adaptations can be described by means of easy to comprehend business terms. Thereby the model enables the AOCI framework to store and publish both context and domain-specific run-time information and provides a basis for high-level and tailored programming support. This enables to transparently select adaptations based on various criteria and integrate them into applications at run-time. At the level of adaptation mechanisms our approach supports integration for permanent changes using Aspect-Oriented Programming and more importantly for spontaneous and short-time integration of web services by means of interceptors.

Introduction and Goals

Smartphones, netbooks and tablet PCs are revolutionizing the information society as we know it today. Due to their increasing computational power and almost permanent connectivity to the Internet they provide an ideal platform for supporting high quality applications in a mobile world. These applications need to act in a context-aware manner and therefore have to deal with temporal, spatial, personal or social information provided by the environment. This demands a change of paradigm in application development towards adapting behavior to adjust to the current situation [START_REF] Coutaz | Context is key[END_REF]. This is hard to achieve as capturing all possible use cases during design-time is difficult.

As a result, developing adaptive applications remains an arduous task. Most existing approaches provide predefined adaptation mechanisms while adding further adaptation features at run-time is not possible. The reasons for these restrictions [START_REF] Charfi | A plug-in architecture for self-adaptive web service compositions[END_REF] are the tight coupling of the application business logic and the adaptation features. In consequence, most approaches omit or only have a limited separate management layer for reasoning and adapting which also impacts expressiveness and flexibility of application-specific adaptation features.

In this paper, we propose programming support for context-aware adaptations that is built upon a semantic model. Our solution is integrated within our Aspect-Oriented Component Infrastructure (AOCI) framework [START_REF] Söldner | AOCI: Weaving Components in a Distributed Environment[END_REF] that so far was limited to handle basic annotations using a semantic layer to make AOCI enhanced applications adaptable. We extend this basic support by explicit modelling of the context as well as applicationspecific domains inside this layer using ontologies of different granularity of abstraction. This allows us to store and to publish context information and provides access to the domain-specific run-time information of the applications. Adaptation developers can now use this information via a simple but yet powerful programming interface, which eases the definition of adaptations. To enable fast dynamic adaptation using external resources, we provide an interceptor-based dynamic adapter for the integration of web services. When executing interceptors, our middleware framework dynamically checks the current context and is able to select and invoke suitable services. This mechanism allows to replace methods at run-time. Hence, using this interceptor-based mechanism, current applications can easily be leveraged and adapted with other services.

Our approach has several advantages compared to other adaptation frameworks. First, due to this work, using the extended semantic layer of AOCI significantly eases the development of adaptive applications. This is due to the fact, that the semantic layer provides access to all the context and domain-specific information using a comprehensive programming interface. Second, based on the semantic layer, the AOCI framework offers different adaptation mechanisms that allow a context-dependent transparent adaptation. These mechanisms can be controlled both by the programmer as well as through configuration options. We support the use of aspect-oriented programming as provided by AOCI for long-term adaptation and newly dynamic and short-term integration of web services on an interceptor-based mechanism. We outline two practical use case scenarios of our approach by extending a Personal Information Manager (PIM) application and show how our framework supports dynamic adaptation in a mobile environment.

The paper is structured as follows: Section 2 discusses related work. Section 3 provides background information and introduces our semantic model. Section 4 describes our approach including a PIM proof-of-concept scenario. In Section 5 we outline the semantic layer and, Section 6 describes the adaptation layer. Section 7 provides an evaluation and finally we conclude this paper.

Related Work

In mobile computing scenarios, applications often face the need for adaptation as a result of spontaneous changes in their context. However, providing appropriate adaptation support is still challenging. In the following discussion, we focus on different approaches for dynamic adaptation in mobile environments.

To enable or enhance transparent adaptation, software is often extended by semantic information which can be queried by a framework to reason about adaptation. Kiczales et al. [START_REF] Kiczales | Separation of concerns with procedures, annotations, advice and pointcuts[END_REF] propose the use of annotations to define extension points, hence introducing a level of abstraction. However, these extension points are self-defined and do not comply with a semantic model. Consequently the level of abstraction remains low.

The use of so called Crosscut Programming Interfaces (XPI) [START_REF] Sullivan | Information hiding interfaces for aspect-oriented design[END_REF] is similar. XPIs represent explicit and abstract interfaces. Source code and adaptations can be separated by means of design rules. To fulfil this, there are pre-conditions for the source code and post-conditions for the execution of adaptations. XPIs allow to extract semantic information from the implementation, however an explicit meta model is not provided.

Kellens et al. [START_REF] Kellens | Managing the evolution of aspect-oriented software with model-based pointcuts[END_REF] introduce model-based pointcuts, which allow to transfer the matching of adapatations to a more conceptual level. As a semantic language for reasoning they extended the CARMA aspect language combined with the formalism of so called "intensional views". CARMA uses SOUL, a language akin to Prolog, to reason about the application of advice. However, compared to our framework, CARMA does neither support dynamic adaptation nor context-awareness.

Research has also been done to provide a common representation format for semantic modelling. For this purpose, ontologies can be used. Both SOUPA [START_REF] Chen | SOUPA: Standard ontology for ubiquitous and pervasive applications[END_REF] and SOCAM [START_REF] Gu | A service-oriented middleware for building context-aware services[END_REF] provide an ontology-based two-layer hierarchical approach. One layer is used to describe general context information and another one for domain-specific ontologies to provide additional vocabularies for supporting specific types of services. To address domain-specific issues during design-time, feature models are widely used. Such feature models are compatible with ontologies as they can be used as subset of the later.

Based on such semantic layers, frameworks can cope with context-awareness. The Context Broker Architecture [START_REF] Chen | Semantic Web in the Context Broker Architecture[END_REF] is based on SOUPA and provides a programming interface to access the context. However, in contrast to AOCI, the focus is mainly on a common semantic model and consequently automatic-adaptation is not supported. Gaia [START_REF] Román | Gaia: a middleware platform for active spaces[END_REF], Aura [START_REF] Sousa | Aura: an architectural framework for user mobility in ubiquitous computing environments[END_REF] and DoAmI [START_REF] Anastasopoulos | DoAmI-a middleware platform facilitating (re-) configuration in ubiquitous systems[END_REF] also support context-aware services and can cope with adaptation, but they neither support fine-grained nor transparent adaptation of services.

Unanticipated dynamic adaptation of mobile applications is also addressed in the MUSIC [START_REF] Rouvoy | Dynamic planning and weaving of dependability concerns for self-adaptive ubiquitous services[END_REF] project, which recently addresses aspect-oriented adaptations. Using this framework, planning-based self-adaptation is possible. To accomplish this, the authors use a meta-model and a sophisticated reasoning engine, however this model is not ontology-based. Instead they concentrate on system-level issues like quality-of-service. In [START_REF] Walraven | Aspect-based variability model for crossorganizational features in service networks[END_REF], the authors propose an aspect-based variability model for representing crossorganizational features. Based on a feature ontology, they can cope with the adaptation requirements at run-time and customize existing features to the client needs.

Background: The AOCI Framework

This section introduces the AOCI framework that provides the basis for our semantic model, its programming support and the dynamic integration of web services. The framework enables dynamic adaptation of component-based applications in a distributed environment, e.g., to account for context changes. In order to allow transparent adaptation, component developers have to introduce particular statements, so called ontology-based annotations, which adhere to an ontology-based model. This information indicates to the middleware, where adaptations can be applied and which kind of adaptation is suitable. Thus, our system supports a greybox component [START_REF] Büchi | A plea for Grey-Box components[END_REF] approach, while preserving encapsulation and the concepts of a black box to a certain degree. Conceptually, the AOCI framework can be split into two layers: A semantic layer, which is responsible for context-aware selection of adaptations and a low-level adaptation layer, which performs the necessary steps to adapt the application accordingly to the selection.

The ontology-based semantic layer enables to reason about adaptation. In general, the use of ontologies provides a means to gain a shared understanding of a set of entities, relations and functions. Ontologies are widely used in knowledge management and due to their expressiveness, the possibility for context representation and extensibility they are well suited to model application domains and context information. In AOCI, ontologies are used, first, to attach semantic information to both applications and adaptations, and second, to provide basic reasoning capabilities.

The adaptation itself is performed by the adaptation layer. It takes all the necessary steps to adapt the application. The adaptation process uses the semantic information attached to the implementation in order to identify the code which needs to be adapted. So far AOCI uses aspect-oriented programming techniques and allows an invasive change of applications typically needed for adaptations with a long-term perspective.

Our implementation specifically targets the adaptation of OSGi-based applications and therefore is implemented using Equinox [START_REF]Eclipse Foundation: Equinox OSGi framework[END_REF]. As an adaptation mechanism it utilizes Equinox Aspects which supports basic aspect-oriented programming for OSGi.

Adapting Service Ecosystems

Next, we motivate how to enable the adaptation of current applications with contextdependent web services in a dynamic fashion. We start by introducing our developer role model that eases the provision of context-aware adaptations. Then, we present use case scenarios for our approach.

Developer Role Model

To ease writing adaptive applications, our approach provides a developer role model and distinguishes three different roles, which are depicted in Figure 1. Service developers attach additional semantic information to their source code. This information has to adhere to a semantic model. The semantic model itself is modelled by the model authors, which are experts in different domain of services. They build a set of entities which represent the structure of a particular domain and its activities. Adaptation developers use the model and its semantic API to write adaptations and determine in terms of the model where and when the adaptation takes place.

Use Case Scenarios

In our scenario, a student is using a smartphone (e.g. MeeGo-based [START_REF] Schroeder | Introduction to MeeGo[END_REF]) with a PIM application running on it. She can use this application to write emails, schedule appointments and manage contacts. Moreover, her university is providing a variety of web services with attached semantic information, among others, a web service to book rooms for learning groups. However, this web service can only be used if a) the student's location is within the university campus and b) the student is member of a tutor group because there is only a small pool of rooms that can be booked on short notice. If these conditions are met, appointments can result in a booking of a room. The corresponding call to the appointment-method will be intercepted, and in case of a room booking, the method call will be transparently replaced by the invocation of the web service. The university also offers a translation web service along with a semantic description, which can be registered in the semantic layer. Using this translation-service, the application can leverage the PIM application with automatic translation capabilities when needed. These use cases can also be expressed more formally. For each use case, we first define the conditions in the context that have to be fulfilled, followed by the adaptation that should be used.

-RoomBooking: Appointment.To = 'RoomX' and UserGroup = 'Tutor' → Invoke RoomBooking -Translate: Appointment.To.Language != Me.Language → Invoke Translation Service

To realize these use cases with our framework, the different developers have to provide semantic information. The service developer attaches the PIM application with semantic annotations created by the model author, and the adaptation developer defines the web service to be invoked and sets the conditions, which have to be fulfilled to invoke the web service. Before adaptations can be applied they have to be deployed to a target system (e.g., the student's smartphone) in form of conditions and associated web services references. This can for example be performed by accessing a well-known university website. However, other discovery approaches can be imagined. From a conceptual point of view, the two use cases are not anticipated during the design of an off-the-shelf PIM application. However, by means of our middleware, these use cases can be realized at run-time by using our platform. The use cases depict the main goals of our enhancements:

-To provide a high-level semantic model in order to describe applications, adaptation conditions and the adaptation itself. -A transparent context-dependent adaptation mechanism.

Semantic Layer

In this section, we describe the architecture of our extended semantic layer in detail. First, we show how the semantic model is realized, followed by a description of how developers can use this model to attach semantic information.

Semantic Model

As stated, adaptation usually happens due to changes in the context, hence, it is a key requirement to model the different aspects within the environment like location (e.g. position, orientation), time, identity (preferences, profile) or activities (e.g. sleeping, walking, etc.) or computing resources (device, network, bandwidth, etc.) For context modelling, we use the Standard Ontology for Ubiquitous and Pervasive Applications (SOUPA) [START_REF] Chen | SOUPA: Standard ontology for ubiquitous and pervasive applications[END_REF]. SOUPA provides a core set of entities for the environment and is highly extensible. Our ontology is based on the Resource Description Framework (RDF) [START_REF] Klyne | Resource description framework (RDF): Concepts and abstract syntax[END_REF] and the Web Ontology Language (OWL) [START_REF] Bechhofer | OWL web ontology language reference[END_REF]. RDF was originally specified as a data model to describe meta data and is now used as a general method for conceptual description. OWL is based on RDF and represents a knowledge representation language for authoring and reasoning about ontologies. Furthermore, context ontologies are used to describe and define the conditions when adaptation can occur. To describe the actual adaptations and applications, our approach uses domain ontologies. Domain models are integrated together with context models in the semantic model: The SOUPA ontology serves as upper ontology for the context and is extended with ontologies for domainspecific services as lower ontology (see Figure 2).

Hence, we model the structure and its provided activities of different application domains by means of these lower-ontologies. Consequently, we introduce several OWL entities; we distinguish so called StructureNodes and ActivityNodes. To put these elements into relationships, our model provides generalization / specialization-, association-and aggregation constructs. Both the StructureNodes and the ActivityNodes span up a separate tree, which can be connected by means of an association if a structure provides a certain functionality. A subset of an ontology for the PIM is depicted in Figure 3. As stated, there are two different subtrees. The upper subtree describes the structure of the PIM domain including modules like email or calendar, the lower subtree models the different functionalities being applicable in that domain. For example, the message node supports sending functionality; consequently these two nodes are connected to each other. The sendMessage() text within the rectangle indicates that there is an instance of a reference to an adaptation stored within the ontology which adheres to a sending semantics.

Semantic Programming

To implement context-aware applications, we provide an API for managing semantic information. Application developers use annotations to attach semantics to their implementation. Figure 4 shows how to do this according to our second use case.

As the annotations adhere to the semantic model, the information can be extracted at run-time by means of our API, which extracts values based on the ontology and the Java reflection API. This API is used by the dynamic adapter of the adaptation layer, but can also be used in aspect-oriented adaptation code. Figure 5 depicts how to use this API. In our API, the AOCIContext is used as an entry point to the ontology and to access the actual execution context, in this case, the sendAppointment()-operation. Finally, adaptations can be enabled and disabled at run-time by means of policy files. They can reference concepts within the ontology and define values in the context or the domain, which have to be met to enable or disable the adaptation. This provides flexibility for controlling adaptations as the adaptation process can be defined by users or administrators. A sample scenario is depicted in Figure 6. First, it defines to use adaptations in classes that are attached with appointments semantics. The next lines specify that the adaptation is only enabled if sender and recipient have different languages and the application is used within the university. If all conditions are fulfilled, the framework will query the ontology for suitable adaptations.

@AOCI . PIM . A p p o i n t m e n t p u b l i c c l a s s A p p o i n t m e n t

Based on the outcome of the semantic reasoning, the adaptation layer transparently chooses the adaptation method and takes the appropriate steps to perform the adaptation. In this section, we initially discuss the differences between the two supported adaptation techniques from a conceptual point of view, next we detail the adaptation process using our interceptor-based approach enabling dynamic integration and invocation of web services.

Comparison of adaptation techniques

We support adaptation via aspect-oriented programming and enhanced our framework with interceptors. While the former can be understood as a generalization of the latter, we used different implementations for AOP and interceptors and due to its properties we combined the interceptors-based solution with the integration of web services.

The aspect-oriented programming support is based on the Equinox Aspect framework which features load-time adaptation of components. Adaptation code can be loaded from remote peers. While this approach provides great flexibility, it might require integration of code from an untrusted provider. Furthermore, many adaptations are location-dependent and therefore often of short-term nature, hence from an implementation point of view using load-time weaving seems unreasonable as modified application parts need not only to be reloaded for the integration of an adaptation but also for the removal of an adaptation. Of course, one could deactivate adaptations that are no longer needed but this would lead to an ever-growing number of unused adaptations thereby wasting resources. The code size of adaptations is also an important factor as the code has to be loaded via the network which can take considerable time if an adaptation provides a complex functionality that is attached with a large state (e.g., a vocabulary file in case of the translation service).

Therefore, we enhance our framework with method-level interceptors, representing an approach to easily integrate adaptations into current applications. Such interceptors can be executed before or after or even instead of a selected method. We chose to integrate generic interceptors at application startup as described below which avoids reloading or restarting actions at runtime and supports the dynamic integration and invocation of web services. Thus, a more spontaneous adaptation using services is permitted that has lower security risks compared to the aforementioned approach as loading of remote code is avoided.

Depending on the context and the required adaptation, our framework dynamically selects the appropriate mechanism at run-time if it is available. Table 1 summarizes the main differences of the two approaches.

Adaptation Process

Our interceptor-based adaptation is based on a dynamic adapter. Our middleware uses the ASM [START_REF] Bruneton | ASM: a code manipulation tool to implement adaptable systems[END_REF] framework to automatically create hooks at the beginning (respectively at the end) of annotated method calls. ASM is an all-purpose Java bytecode manipulation and analysis framework used to modify existing classes or dynamically generate classes, directly in binary form. Within these hooks, the semantic layer is queried to reason 1. Comparison of adaptation approaches about possible adaptations. In case of an adaptation, the method can be intercepted or redirected to a web service. Internally, the process consists of two subsequent phases, the transformation phase and the invocation phase.

Transformation Phase In the transformation phase, hooks are integrated within the application to enable the use of interceptors. This phase happens before loading classes into the Java virtual machine. The framework uses the hook-mechanism of the Equinox framework to intercept the classloading. The hook-mechanism allows to register a callback function which is responsible for adapting the classes. The full process is described in Figure 7. First, the processClass-method of the AOCIExtensionHook is called. Within the body, the configuration for the bundle where the class resides is requested. Upon receipt of the information, a TransformerService is requested. This service is used to transform the actual class. We use ASM to inject a call to a dynamic adapter function. Within this function, the current context is evaluated, conditions are checked and web services are invoked dynamically. The transformed class is then stored along with the original class in the AOCIBundleRegistry.

The dynamic adapter supports three strategies: pre-invoke, post-invoke and replacement. Pre-invoke is usually used before the method execution with the goal to change the values of the input parameters, hence changing the semantics of the method or in order to validate the ingoing parameters. Post-invoke is executed after the annotated method and can change the result of the function. The replacement directive provides the possibility to skip the execution of the method. This allows for a transparent way to interchange the behavior of services.

Invocation Phase The invocation phase is performed at run-time and represents the execution of the interceptors. In the first phase of the invocation phase, context conditions have to be evaluated, and based on the result, a decision whether to perform adaptations or not is taken. If the conditions are met, the dynamic adapter reasons by means of the OntologyService. This service encapsulates the ontology and provides reasoning capabilities to determine what kind of services should be integrated. The ontology provides a model for describing the structure and behavior of services and applications. This information is used at run-time to dynamically invoke web services. The ontology also contains references to these web services. For the dynamic invocation of the web Fig. 7. Transformation phase services we use the DAIOS [START_REF] Leitner | Daios: Efficient Dynamic Web Service Invocation[END_REF] framework. Compared to other dynamic invocation frameworks, DAIOS is easy to use, performs well and supports a wide variety of web service techniques. DAIOS uses a generic technique based on similarities of input parameters for the mapping between WSDL and DAIOS types and supports both simple data types as well as complex data types.

The next step is to determine the calling semantics of the web service communication. We support two different styles: blocking and non-blocking communication. The standard way to invoke web services is synchronous blocking. However, as web services are often deployed within a Service Oriented Architecture (SOA), some services may take some time to process a request. Consequently, the standard request/response style is not suitable for such long-running method invocations. Therefore we provide the support for asynchronous (non-blocking) communication.

In the last step, the actual dynamic invocation is being performed. DAIOS supports the core SOA principles: It uses dynamic services invocation, hence no static component like client-side stubs is needed, and instead arbitrary web services can be invoked using a single interface with generic data structures. Furthermore, our invocation engine is protocol-independent and supports a message-driven approach, hence leading to looser coupling of services; both SOAP-based as well REST-based [START_REF] Fielding | Architectural styles and the design of network-based software architectures[END_REF] services are supported. The process is shown in Figure 8: First, within the application's dynamic adapter, a reference to the InvocationService is fetched. Second, the invoke method is called, which in turn checks the conditions, fetches a suitable web service reference and makes a dynamic call to the web service.

Evaluation

For the evaluation, we conducted experiments to adapt our application in a short-term style by means of an interceptor-based invocation of a web service and compared the results to our previous aspect-oriented adaptation support. We attached the appointment module of the Nomad PIM [START_REF]Nomad PIM[END_REF] (an OSGi-based open-source PIM) with semantic information as described in Section 5 and provided an adaptation to translate the text body of emails by means of a translation web service. For the interceptor-based variant the evaluation includes the transformation during the start of the PIM application, the semantic meta data extraction at run-time and the dynamic invocation. Additionally, we measured the aspect-oriented weaving that is performed during class loading requiring a bundle restart of the effected OSGi components. All experiments were performed 50 times for each type of measure and the web service was co-located with the application on the same physical machine. 2 shows that our interceptor-based approach is executing with low overhead, however, due to the transformation phase, the startup of the application takes 1400 ms longer. Subsequent reasoning and invocations only need a few milliseconds. Aspectoriented adaptation, in contrast, needs a restart of the affected bundles if adaptations are integrated or removed. In both cases this results in a application downtime of 2000 ms at run-time and bears significant startup costs. Compared to the interceptor approach, subsequent invocations do not need additional reasoning, hence the approach provides low invocation costs.

In a second step, we measured the different variants of how dynamic invocation of web services can be applied. We evaluated the pre-invoke, the post-invoke and the replace style. Furthermore we conducted measures for asynchronous and synchronous calls (see Table 3). The replace strategy performs slightly better than the other styles as less reflection-based method calls are needed. Furthermore, due to the described rule-based adaption selection process of the scenario, the ontological reasoning time is quite low. In summary, an interceptor-based approach can support various scenarios where an external and code-wise unknown service needs to be integrated on demand. Furthermore, the approach is faster in respect of the integration of adaptations than our previous solution using AOP, because the components affected by the adaptations do not need to be restarted.

Conclusion

To cope with the requirements of dynamic applications, the ability to adapt due to changes in the context is essential. Existing approaches for adaptive software lack a semantic model to define and perform adaptations in a business-oriented way. In this paper we filled this gap by integrating context and domain modelling in one combined ontology. Based on this model, our application can ease the questions of "when", "what" and "how" to adapt. In combination with a flexible API to access the semantic model and the support for dynamic and possibly short-time integration of web services we provide a powerful tool set for dynamic adaptation of applications in a mobile world.

Fig. 1 .

 1 Fig. 1. Developer roles

Fig. 2 .

 2 Fig. 2. Upper and domain-specific ontology

Fig. 3 .

 3 Fig. 3. Graphical representation of a PIM ontology

Fig. 5 .

 5 Fig. 5. Querying semantic information at run-time

Fig. 6 .

 6 Fig. 6. Context condition for the appointment adaptation

Fig. 8 .

 8 Fig. 8. Invocation phase

  Appointment class annotated with PIM annotationsThe Appointment-class further contains a property referring to the recipient. The first statement extracts the current location from the upper context ontology. The second statement uses the domain ontology to navigate to the recipient user by selecting the corresponding class property and extracts his language.

	{
	@AOCI . PIM . C a l e n d a r . A p p o i n t m e n t . To
	U s e r t o U s e r ;
	@AOCI . S e n d A c t i v i t y . SendMessage
	p u b l i c v o i d s e n d A p p o i n t m e n t ( ) { . . . } }
	Fig. 4.

S t r i n g l o c = AOCIContext . L o c a t i o n . t o S t r i n g ( ) ; S t r i n g c u r L a n g = AOCIContext . c u r r e n t N o d e . g e t S t r u c t u r e N o d e ( ) . g e t P r o p e r t y ( "" ) . g e t L a n g u a g e ( ) . t o S t r i n g ( ) ;

1.1, Hook-Seq-2

	sd Transformation
	: AOCIExtensionHook	:ITransformerServiceProvider	: AOCIBundleRegisty
	1: processClass 1: processClass	(className,classBytes,classpathEntry,bundleEntry,manager) (className,classBytes,classpathEntry,bundleEntry,manager)
	1.1: getBundleConfig 1.1: getBundleConfig	(bundleID) (bundleID)
	1.2: createTransformerService() 1.2: createTransformerService()
			: TransformerService
			1.2.1: «creation» 1.2.1: «creation»	* *
	1.3: transform (classBytes,config) 1.3: transform (classBytes,config)
	2: addTransformedClass 2: addTransformedClass	(bundleID,className,loader) (bundleID,className,loader)

Table 2 .

 2 Benchmark results for interceptorsTable

	Type of measure	Min. [ms] Max. [ms] Avg. [ms]
	Interceptor integration during application startup	987	1731	1403
	Semantic meta data extraction at run-time	0,49	1,28	0,67
	Ontological reasoning at run-time	3,7	4,6	4,1
	Dynamic invocation at run-time	7,21	7,87	7,39
	Aspect-oriented adaptation	1803	2006	2357

Table 3 .

 3 Benchmark results for dynamic invocation

		Average asynchronous [ms] Average synchronous [ms]
	Pre-invoke	7,21	7,39
	Post-invoke	7,65	8,12
	Replace	6,31	6,88

Part of this work is funded by a research fellowship granted by the German Academic Exchange Service (DAAD).


Hermann Tagne Taguifang

David Monkam

Comparison of Cumulus Schemes in the Regional Climate Model (RegCM4) in Central Africa

Keywords: Area, data, schemes and methods Area

The International Center for Theoretical Physics (ICTP) RegCM4 model is used to compare the different cumulus and closures parameterization schemes of AK, EM, GAS and GFC in Central Africa. An evaluation of the nested model is presented for the Saharo-sahelian, Sahelian, Soudanian and Equatorial regions. The schemes show a slight shift of the rain bands toward the Soudanian region. The schemes are not identical. AK shows reduced rainfall in the Soudanian. EM and GFC exhibit a dry bias during July, August and June-August (JJA) in the common zone of Cameroon, Nigeria and Gulf of Guinea. Striking insufficient of precipitation over the ocean in the Gulf of Guinea due to all the schemes. The implementation of the EM and GFC schemes improves the mean seasonal simulated precipitations and surface temperatures. The EM scheme improves well in the timing and amplitude of precipitations and surface temperatures in Central Africa.

Four sub-regions are independently set as regional analysis zones to quantitatively investigate the model's performance and climatological change in rainfall and surface temperature (Fig. 1). These sub-regions represent some simplified climate zones. Data we used the following data:

Four outputs of RegCM4 model [START_REF] Giorgi | RegCM4: model description and preliminary tests over multiple CORDEX domains[END_REF] simulation data (RegCM4-AK, RegCM4-GAS, RegCM4-GFC and RegCM4-EM) (0, 25 • × 0, 25 One reanalyzed atmospheric forcing, the new ERA-Interim (EIN15) [START_REF] Dee | The ERA-Interim reanalysis: configuration and performance of the data assimilation system[END_REF] gridded reanalysis (EI-RegCM4) (1, 5 • × 1, 5 • ) EI-RegCM4 produced with 4D-Var (12 hours cycles of analysis).

Observed SSTs [START_REF] Reynolds | An improved in situ and satellite SST analysis for climate[END_REF] SSTs (from the NOAA weekly optimum interpolation analysis (version 2)).

Six different observation data from 1975 to 2005 CRU (0, 5

• ×0, 5 • ), TRMM 3B43 (0, 25 • ×0, 25 • ), GPCC (1 • ×1 • ), CMAP (2, 5 • × 2, 5 • ), GPCP (2, 5 • × 2, 5 • ), UDEL (0, 5 • × 0, 5 • ).
Schemes we used the following schemes: the Modified-Kuo Anthes (AK) scheme [START_REF] Anthes | A cumulus parameterization scheme utilizing a onedimensional cloud model[END_REF] the mass flux scheme developed by Grell [START_REF] Grell | A description of the fifth generation Penn State/NCAR Mesoscale Model (MM5)[END_REF] Two closure assumptions can be adopted:

Arakawa and Schubert (GAS)

Fritsch and Chappell (GFC) the Emanuel/Massachusetts Institute of Technology (EM) scheme [START_REF] Emanuel | A scheme for representing cumulus convection in large-scale models[END_REF][START_REF] Emanuel | Development and evaluation of a convection scheme for use in climate models[END_REF]

Methods

• To account for differences in vertical resolution and topography, a vertical interpolation is performed between RegCM and the driving fields;

• To ameliorate the model's performance, the boundary forcing is interpolated horizontally and vertically to the RegCM grid and topography at 6-h intervals;

• To ease comparison for the present period, the integration with the different schemes is considered independently in four topographical subregions:

Saharo-sahelian (16 -20 • N, 6 • W -34 • E) Sahelian (13 -16 • N, 6 • W -34 • E) Soudanian (2 -13 • N, 6 • W -34 • E) Equatorial (9 • S -2 • N, 6 • W -34 • E)

Results

Comparison of schemes

• During the season June-August (Fig. 2), RegCM4 simulations have a little wet bias in Central African coast, with isohyet 2mm/day located between 18 and 20 • N in AK, GAS and EM with a precise position at 15 • N in GFC scheme.

• During the season June-August (Fig. 3), AK ranges from 299 to 301K while EM simulates 297K in the Western Nigeria;

• Surface temperatures depend on the scheme in the Gulf of Guinea;

• AK, GAS and GFC schemes reproduce high surface temperatures explaining the extension of rains until the Sahelian latitudes;

• In EM, rains extension is the result of more low surface simulated temperatures located between 299 and 301K over the Gulf of Guinea;

• An occupation of the Equatorial Central African areas by monsoon rains is the result of the low temperature gradient between the continent and the tropical Atlantic;

• The ITCZ is found around 8 • N in simulations with the AK scheme whereas it is found around latitude 10 • N with EM, GAS and GFC schemes.

Comparison with observations

• During the season June-August (Fig. 2), CRU and GPCP present isohyet of rains band toward the coast of Central Africa;

• All the schemes have patched rainfall patterns over continental areas as opposed to the CRU observed zonal patterns; • The orographic maxima over mountainous regions in the Guinea and Cameroon highlands are not captured by all the schemes. • In general, none of the different cumulus and convective closures schemes is able to reproduce the spatial characteristics of surface temperatures as observed in EIN15; • Closeness are reinforced in the Saharo-sahelian region between all the schemes (especially GAS, GFC and EM schemes) and EIN15.

Discussions

• There is value in examining the RegCM4 model nested in one source of boundary forcing, in this case ERA-Interim reanalysis data; • The difference of the isohyet location in the (AK-GAS-EM) schemes and the GFC scheme suggest the GFC scheme is doing better; • While ITCZ appears to be found around 8 • N in simulations with AK, it is found around 10 • N in simulations with EM, GAS and GFC schemes; • RegCM4 simulation of precipitation in the Central Africa is better with both the EM and GFC schemes than both the AK and GAS schemes (Fig. 2).

Conclusions and forthcoming research

Figure 1 :

 1 Figure 1: RegCM4 model domain and topography. Also shown (areas in rectangles) the four topographical sub-regions of simulation domain. Saharo-sahelian, Sahelian, Soudanian, Equatorial.

  ) RegCM4-AK (from June to August 2006), RegCM4-GAS (from June to August 2006), RegCM4-GFC (from June to August 2006), RegCM4-EM (from June to August 2006).

Figure 2 :

 2 Figure 2: Spatial distributions of total precipitation (mm.day -1 ) (left) and surface temperature ( • K) (right) as simulated using AK, GAS, GFC and EM cumulus and convective closures schemes during June, July, August and JJA for the present day climate 2006 year over Central Africa.

Figure 3 :

 3 Figure 3: Monthly and Seasonal cycles of total precipitation ((mm.day -1 )) (top) and surface temperature (( • C)) (bottom) as simulated using AK, GAS, GFC and EM cumulus and convective closures schemes during June, July, August and JJA for the present day climate 2006 year over the four sub-regions.

Figure 4 :

 4 Figure 4: Monthly and Seasonal cycles of total precipitation ((mm.day -1 )) (top) and surface temperature (( • C)) (bottom) as simulated using AK, GAS, GFC and EM cumulus and convective closures schemes during June, July, August and JJA for the present day climate 2006 year over the four sub-regions.

•

  The focus of this work was to analyze the performance of the RegCM4 model in simulating current climate over Central Africa when driven by one reanalyzed atmospheric forcing, the ERA-Interim (EIN15) and to compare the different cumulus and closures schemes; • The implementation of the EM scheme improves well in the timing and amplitude of precipitations and surface temperatures in Central Africa; • In the continuation of this work, a paper is in preparation concerning a long term nested regional climate model RegCM4 climatologies for Central Africa using ERA-Interim reanalysis and ECHAM global model driving fields.

Acknowledgements

The authors thank the National Agency for Research (NAR) France in the PICREVA project, under the auspices of Dr. Serge Janicot of LOCEAN (Paris VI) which provided a Calculator during the performation of all the simulations.


Elizabeth Rendon-Morales
email: elizabeth.rendon@entel.upc.edu

Jorge Mata-Díaz

Juanjo Alins

José Luis Muñoz

Oscar Esparza

Jorge Mata

Adaptive Packet Scheduling for the Support of QoS over DVB-S2 Satellite Systems

Keywords: QoS, DiffServ DVB-S2, BSM and WRR

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Nowadays, the support of IP-based applications over Internet has experienced a fast and continuous growth together with the expansion of the World Wide Web. As a consequence, new IP applications such as Voice over IP (VoIP) and multimedia services require considering different levels of individual packet treatment through the network. This differentiation must include not only the Quality of Service (QoS) parameters to specify packet transmission priorities across the network nodes but also, the required amount of bandwidth assignment to guarantee its transport.

To provide this type of IP services, the geostationary (GEO) satellite infrastructure plays a crucial role. Specially, because the satellite systems can provide ubiquity and broadband access, being feasible to reach large and disperse populations around the world.

However, to provide a variety of services over satellite systems with QoS, it is important to consider the intrinsic characteristics present in GEO satellite systems that affect the QoS provisioning. Such characteristics are: delay, losses and link bandwidth variations. The presence of these link bandwidth variations need to be seriously considered, as it is necessary to preserve the QoS levels when rain events in the atmosphere are experienced, which can also reduce the available capacity in the Digital Video Broadcasting-Second Generation (DVB-S2) [START_REF]ETSI Standard for Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications (DVB-S2)[END_REF] forward channel. To address this, the DVB-S2 specification implements the Adaptive Code and Modulation (ACM) techniques to achieve quasi-error free channel conditions for each individual user, by providing them with the most suitable modulation and code (ModCod) value according to the measured signal-to-noise-plus-interference ratio (SNIR). In addition, the Broadband Satellite Multimedia (BSM) working group has defined a QoS functional architecture (ETSI-BSM-QoS) standardized in [START_REF]ETSI Standard for Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia (BSM); QoS Functional Architecture[END_REF]. This framework establishes the required QoS mechanisms (supported in the Hub) to define the priorities among users and applications based on the Differentiated Services (DiffServ) architecture [START_REF]Standard for an Architecture for Differentiated Services[END_REF].

Nevertheless, most of the predefined QoS mechanisms usually have static input parameters resulting in an inefficient resource allocation. Therefore, a solution is to use an adaptive approach that manages the bandwidth distribution (among service classes) considering the fact that the available capacity present in a satellite system is constantly changing. This adaptive approach enables sharing bandwidth resources in a more suitable way, ensuring that the required QoS levels are maintained while the satellite link capacity is optimized.

In this paper, we propose a resource sharing model that manages the QoS requirements and at the same time optimizes the utilization of the DVB-S2 satellite link capacity. The aim of this model is to share the available bandwidth between various service classes having a certain QoS level. The proposed adaptive scheme calculates the optimal weight values considering two factors used to determine the minimum required amount of resources, these are: the QoS requirements of each traffic class and the link bandwidth availability present on the satellite system.

The proposed adaptive IP packet scheduling mechanism is based on the Weighted Round Robin (WRR) scheme which is evaluated using the NS-2 simulation tool. In the simulation environment we consider both the adoption of a DiffServ model to provide QoS guarantees and the most representative characteristics affecting the DVB-S2 forward channel (i.e. delay, losses and mainly the presence of link bandwidth variations). The presented simulation results demonstrate that when our adaptive WRR mechanism is implemented, an enhanced satellite performance is achieved while maintaining the QoS levels even though a severe reduction of bandwidth is experienced.

The presented work is organized in 5 sections: in section 2 a characterization of the bandwidth link variation is presented together with a description of the adaptive Hub and the adaptive WRR algorithm. In section 3, the proposed adaptive model is evaluated using the NS-2 simulation tool and the performance evaluation results are presented. In section 4 the related studies are presented and conclusions are formulated in section 5.

Adaptive WRR Model

In this section we present a characterization of the bandwidth link variations present in GEO satellite systems, a description of the adaptive Hub and the proposed adaptive WRR algorithm.

Characterization of the bandwidth link variation

In practice, transmission rate variations in the satellite link are mainly caused by atmospheric conditions such as rain events. In order to define an adaptive WRR model that considers these link bandwidth variations, we have analyzed a rain event affecting the bandwidth availability in the DVB-S2 forward channel.

Particularly, we have considered the study presented in [START_REF] Cioni | Channel estimation a physical layer adaptation techniques for satellite networks exploiting adaptive coding and modulation[END_REF] that provides an estimation of the physical layer performance over the DVB-S2 forward link under a heavy rain event. By considering this approach, the physical layer behavior is adapted taking into account the effects of the satellite delay and the implementation of the ACM techniques. Using such techniques, it is possible to achieve an optimal operation point by selecting the most suitable ModCod depending on the satellite terminal propagation conditions. To simplify and use these results in our proposed adaptive model we approximated the physical layer estimation reported in [START_REF] Cioni | Channel estimation a physical layer adaptation techniques for satellite networks exploiting adaptive coding and modulation[END_REF] Sinusoidal approximation ACM adaptation behavior Fig. 1 ACM adaptation behavior during a heavy rain event in the forward link [START_REF] Cioni | Channel estimation a physical layer adaptation techniques for satellite networks exploiting adaptive coding and modulation[END_REF] In this way, satellite terminals allocated under clear sky conditions are characterized for having high link bandwidth availability (see Fig. 1 at the peak of the sinusoidal link wave). Therefore, those terminals will be provided with an efficient ModCod according to the satellite propagation conditions. In contrast, terminals allocated under a heavy rain event are characterized for having reduced link bandwidth availability (see Fig. 1 at the valley of the sinusoidal link wave). Therefore those terminals will be provided with a ModCod including a robust channel protection mechanism and a specific modulation scheme. As a result, the bandwidth capacity will fluctuate between the minimum (valley) and maximum (peak) values, since the ACM mechanism will be continuously working to mitigate the atmospheric impairments. This bandwidth characterization will be the input parameter of our proposed IP adaptive scheduler.

Architecture of the adaptive Hub

The proposed DiffServ model implemented over the adaptive DVB-S2 Hub fulfills the ETSI QoS Broadband Satellite Multimedia Services and Architectures standard [START_REF]ETSI Standard for Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia (BSM); QoS Functional Architecture[END_REF]. The QoS policy implemented in the DiffServ model allows the EF traffic class to have the highest priority, while the AF traffic class has more priority than the BE traffic class. As a results, the BE traffic class, which is based on a best effort scheme, uses the remaining link capacity, being able to use the bandwidth that any other class does not use.

The architecture of the adaptive Hub that supports the DiffServ model and exploits our adaptive packet scheduler based on the WRR mechanism is shown in Fig. 2. The DiffServ model includes a traffic classifier that decides if a packet needs to be reassigned with a different QoS level by remarking its DSCP. Notice that the proposed scheme allows multiple flows to be aggregated and treated as a single flow per traffic class. The enqueuing system supported at the Hub has three traffic classes allowing each of them to have its own physical queue and implementing a drop tail mechanism.

Every traffic class implements a token bucket (TB) as a rate limiter to guarantee the transmission rate according to the bandwidth assignment established in the Service Level Agreement (SLA). Each TB limiting rate is set to µ EF , µ AF and µ BE for the EF, AF and BE traffic classes respectively. Here, it is worth mentioning that our proposal considers the buffer length of each traffic class as a function of the Bandwidth Delay Product (BDP). This BDP value is set considering the minimum Round Trip Time (RTT MIN ) present in the satellite system and the associated TB limiting rate.

All packets coming from each traffic class are sent directly to the IP scheduler. The IP scheduler is based on the Weighted Round Robin (WRR) mechanism [START_REF] Shimonishi | Performance Analysis of Weighted Round Robin Cell Scheduling and Its Improvement in Atm Networks[END_REF] that controls the order in which packets are extracted out from its queues. Along with the WRR scheduler, there is a new module which is responsible for calculating the parameters of the WRR scheduler. This component is referred as the Weights calculator that takes into account the adaptive WRR model (further defined in subsection 2.3) to compute the suitable weight values. The Weights calculator's input parameter is the bandwidth availability considering the sinusoidal wave variation defined in subsection 2.1. Such value is sent from the physical layer to the network layer by means of a cross-layer mechanism.

The corresponding weight values (W EF , W AF and W BE ) are set within the IP scheduler to prioritize the resources for each traffic class. As it is observed, in Fig. 2 the Weights calculator module is decoupled from the IP scheduler. Therefore, the scheduler complexity is not increased and both modules can work independently based on their own settings.

The adaptive WRR algorithm

In order to calculate the weight values, different criteria can be used (e.g. the mean packet size [START_REF] Ito | Variably weighted round robin for core IP networks[END_REF], queue sizes [START_REF] Wang | Adaptive-weighted packet scheduling for premium service[END_REF], revenue-based [START_REF] Sayenko | Adaptive scheduling using the revenuebased weighted round robin[END_REF]). In this paper, we propose to use the current capacity of the DVB-S2 satellite link (C OUT ) as the main criteria for the allocation of network resources. To the best of our knowledge, this is the first time that such scenario has been analyzed over a DVB-S2 satellite system.

The adaptive IP scheduler design proposed in this paper actively adjusts the weight of each traffic class to enforce its QoS level. This adaptive design is linked to the ACM mechanism specification. In this way, considering the three traffic classes defined in the DiffServ architecture (EF, AF and BE), the adaptive model will therefore prioritize the EF traffic class over the AF and BE traffic classes when the satellite system experiences a capacity reduction in the presence of a heavy rain event. This prioritization is done by assigning high weight values to the EF traffic class while the AF and BE traffic classes will have the lowest weight values. Similarly, when the intensity of the rain event has diminished and the link capacity increases, the adaptive model will keep the priority levels of the EF and AF traffic classes over the BE traffic by assigning high weight values to the EF and AF traffic classes while the BE traffic class will have the lowest weight value. Finally when the rain event has ended and the bandwidth availability is enough to guarantee the high priority traffic (EF and AF), the assigned bandwidth for the BE traffic class will be reestablished and the weight values will be assigned according to the rate of the high priority classes.

To adaptively distribute the available capacity among each traffic class, two thresholds are defined: the LowerCap THR and the UpperCap THR . The LowerCap THR is set to the EF limiting rate (µ EF ) specifying when the system capacity (C OUT ) is scarce but is still enough to guarantee the EF traffic class. The upper threshold UpperCap THR is set to the sum of the EF and AF limiting rates (µ EF +µ AF ) specifying when the system capacity is enough to guarantee the rate of both priority classes. If the bandwidth capacity is kept beyond the UpperCap THR , it is considered that the available bandwidth in the system is broad enough to transport all the traffic classes.

In order to specify such functionality on an adaptive WRR scheduler, Fig. 3 shows the weight values at each interval as a function of the DVB-S2 system capacity (C OUT ). Here, the sum of the weights is set to K, where K is considered as a constant value that must be significantly high to avoid weight rounding errors:

W EF + W AF + W BE = K (1)
Given that the BE traffic class has the lowest priority level, our adaptive model allocates the excess of resources in this class. Therefore, in all cases W BE is set to W R representing a residual and constant weight value.

W BE = W R (2)
As it is shown in Fig. 3 when the system capacity is broad enough, C OUT > UpperCap THR , our adaptive model assigns constant weight values to guarantee high priority classes (EF and AF). We assume that the weight values of each traffic class are set to W B EF and W B AF for the high priority classes and W R for the BE class. Following this assumption the next relationship is obtained:

+ W B EF = W B AF K -W R (3))
To proportionally distribute the system resources [START_REF] Dovrolis | A case for relative Differentiated Services and Proportional Differentiation Model[END_REF], the ratio of W B EF over W B AF is set equal to the ratio of the associated TB limiting rates, thus:

µ AF µ EF W B EF W B AF = (4)
As a result, the W B EF and W B AF values can be expressed as a function of the TB limiting rates (µ EF and µ AF ) as:

µ AF (µ EF + µ AF ) W B AF = K -W R (5) µ EF (µ EF + µ AF ) W B EF K -W R = (6)
In a similar way, when the system capacity is scarce, C OUT < LowerCap THR , our adaptive model assigns constant weight values to guarantee the EF priority class over the AF and BE traffic classes. Therefore, W EF , W AF and W BE are set as:

W AF = W R W BE = (7)
W EF = K -2W R (8)
Finally, to guarantee the EF traffic class over the AF traffic class, when the system capacity is constrained, LowerCap THR < C OUT < UpperCap THR , our adaptive model allocates most of the resources to the EF traffic class. At this interval, we can apply either a linear or an exponential relationship between the weights of the higher priority classes (W EF and W AF ) and the satellite link capacity (C OUT ).

We have performed a practical analysis between the high priority weights and the available bandwidth at the constrained interval. Such analysis has enabled us to conclude that the weight variations must change in a progressive way following an exponential function. However, we have also analyzed the case when a linear weight function is used, resulting in a faster variation where it is not possible to guarantee the EF priority traffic class when the available capacity is close to the UpperCap THR . Therefore, in order to build a continuous weight function for each traffic class, we define W AF as follows:

W AF = W R W B AF W R C out -µ EF µ AF (9)
Similarly, the W EF is obtained as follows:

W EF = K -W R -W AF (10)

Performance Evaluation

In this section the satellite network settings and performance metrics are presented. Then, the proposed adaptive WRR model is simulated over a DVB-S2 satellite network and compared with the Round Robin (RR) and the ordinary WRR scheduler.

Satellite network settings

The simulation is carried out employing the NS-2 simulator tool 2.29. For QoS purposes the DiffServ module was developed using the library described in [START_REF] Pieda | A Network Simulator Differentiated Services Implementation[END_REF] where our adaptive WRR model has been added. The network topology used for the simulation is shown in Fig. 4. Here, three sources send data to a remote destination. Each source node supports different services, having a predefined PHB. The EF class is represented by a real-time Voice over IP (VoIP) application employing the User Data Protocol (UDP). The AF class represents Hypertext Transfer Protocol (HTTP) traffic. The BE class represents bulk data transfer generated by a persistent File Transfer Protocol (FTP) transaction server. The transport protocol used to transport the AF and BE traffic classes is the Sack [START_REF]IETF Standard for a Conservative Selective Acknowledgment (SACK)based. Loss Recovery Algorithm for TCP[END_REF] variant of the Transmission Control Protocol (TCP). We used the TCP Linux version [START_REF] Wei | A Linux TCP implementation for NS2[END_REF], which includes this TCP variant. The details of each service class are presented on Table I.

DVB-RCS Return Link

Fig. 4 DiffServ-satellite network topology All the traffic entering the edge router is directly sent to the adaptive Hub that supports the DiffServ architecture to guarantee the predefined QoS level for each traffic type. The Hub, which is the main element in the satellite system, is responsible for applying the adaptive WRR model and sending the data to the destination host via the DVB-S2 forward channel. The return channel is used to transport signaling data, based on the DVB-RCS specification [START_REF]ETSI EN 301 790, ETSI Standard for Digital Video Broadcasting (DVB); Interaction Channel for Satellite Distribution Systems[END_REF]. The DVB-S2 satellite network settings used throughout the simulation are configured as follows:

The satellite channel capacity considered as the bottleneck link is set considering the terminals in clear sky conditions will have 3.4 Mbps of bandwidth while terminals under a rain event will have a reduced capacity set to 0.4 Mbps. Therefore, the sinusoidal link variation will fluctuate between 0.4 to 3.4 Mbps. The minimum Round Trip Time (RTT MIN ) experienced by the satellite system is set to 560 msec. The buffer length of each traffic class is set to the BDP value. Particularly, the buffer length of the BE traffic class is set to 90 packets. The Packet Error Rate (PER) is set to 1x10-7.

The transfer speed for each traffic class considered for the simulation is: 400 Kbps for the EF traffic class and 800 Kbps for the AF traffic class, while the BE traffic class will use the remaining bandwidth. The LowerCap THR and the UpperCap THR values are set to 0.4 Mbps and 1.2 Mbps respectively.

Performance metrics

The proposed analysis is carried out at the bottleneck-satellite link, therefore, the relevant TCP information such as: the transmitted/acknowledged packets, the congestion window and the RTT are collected at the sender's side. Additionally, in order to asses the system performance with the proposed adaptive WRR scheduler, two metrics are considered: the goodput and the buffer occupancy.

The goodput is defined as the average amount of correctly received data (excluding retransmissions) measured over a certain period of time. The goodput per-class is calculated by dividing the amount of transmitted data by the number of active data flows (10 flows) within a service class in a given interval.

The buffer occupancy represents the fullness of the DiffServ queue during the simulation time. In our case, the simulation results consider the buffer occupancy for the IP queues allocated at the Hub.

Simulation results

In order to evaluate the performance of the proposed adaptive scheduler, three simulation tests are considered: the first test is performed to assess the DVB-S2 system response when the Round Robin (RR) mechanism is employed. The second test considers the Weighted Round Robin mechanism with static weight values set to 6, 8 and 1 (K = 15) for W EF , W AF and W BE respectively. These values are set considering the proportional distribution of resources, where the EF traffic class has higher weight value than its corresponding proportional value. Finally, a third simulation test is performed considering our proposed adaptive WRR scheduler to adjust the weight values taking into account the capacity variations. Here, we have calculated the weight values at the constrained interval considering both functions: the linear weight function and the exponential weight function. The results of plotting the dynamics of weights as a function of the sinusoidal link variation are shown in Fig. 5. In this case, the link bandwidth variation (C OUT ) oscillates between 0.4 and 3.4 Mbps. These results consider the exponential adaptive WRR algorithm (using the analysis presented in section 2.3) and the bandwidth rate previously set for each traffic class. The K value is set to 15 and W R is set to 1.

Fig. 6a illustrates the simulation results of goodput and queue occupancy considering the RR algorithm. Using this algorithm it is observable that the EF and AF traffic classes are not guaranteed when a reduction of bandwidth (due to a rain event) is experienced. Moreover, the queue occupancy is overloaded in most of the cases leading to an increase of the system latency.

In a similar way, by using the WRR mechanism (see Fig. 6b) with static weight values, the EF traffic class is able to reach its 400 Kbps. However, its goodput is affected in specific time points when the capacity is reduced (see the valleys of the sine wave). Likewise, the AF traffic class tries to keep its 800 Kbps of goodput, while the BE traffic class uses the remaining bandwidth. The buffer occupancy (considering the three traffic classes) is overloaded, allowing an increase of the system latency which is reduced compared to the latency experienced in the RR scenario. It is also observable that when an extreme reduction of bandwidth is experienced (see the interval between 3500-4000 sec) the priority levels of each traffic class are lost, being unable to guarantee the EF traffic class over the AF and BE traffic classes.

Similarly, by using the linear adaptive WRR mechanism (Fig. 6c), it is observable that the EF buffer occupancy is reduced compared to the previous case. However, given that a linear function generates a faster weight variation, it is not possible to guarantee the EF priority traffic class when the available capacity is reduced (see the interval between 3500-4000 sec).

Finally, considering our proposed exponential adaptive WRR mechanism (Fig. 6d) it is observable that the buffer occupancy for the EF traffic class is kept at lower levels and that the rate for the EF traffic class is totally guaranteed (400 Kbps) even though an extreme reduction of bandwidth is experienced. In addition, the transmission rate for the AF traffic class reaches its 800 Kbps of goodput and the BE traffic class uses the remaining bandwidth, being able to follow the sine wave when an increase of bandwidth is experienced by the system. It is also observable that when an extreme reduction of bandwidth is experienced (see the interval between 3500-4000 sec) the priority levels of each traffic class are kept, guaranteeing the EF traffic class over the AF and BE traffic classes.

Related works

In order to calculate the optimal weight values based on the QoS requirements, different criteria have been researched in the literature e.g. the mean packet size, queue sizes, revenue-based etc.

In [START_REF] Ito | Variably weighted round robin for core IP networks[END_REF], a Variable WRR (VWRR) scheduler is proposed. This model uses the average packet length to adapt its weights. A weight value is calculated considering two parameters: the bandwidth requirements and the average length of packets. The problem of adjusting weights for the WRR scheduler guaranteeing the premium service has been analyzed in [START_REF] Wang | Adaptive-weighted packet scheduling for premium service[END_REF]. This work proposes a resource allocation model considering the average queue size, which is calculated using a low-pass filter. In [START_REF] Sayenko | Adaptive scheduling using the revenuebased weighted round robin[END_REF], an adaptive scheduling scheme using the revenue-based WRR is presented. This proposal has been considered for guaranteeing the maximum service provider revenue. The proposed scheme, adjusts its weights using the revenue criteria to control the resource allocation. In [START_REF] Yi | Providing fairness in DiffServ architecture[END_REF], a modified Fair WRR (FWRR) scheduler has been proposed to protect the best effort traffic from the assured forwarding out-ofprofile packets in the core routers based on the DiffServ architecture. This policy dynamically adjusts the weights and the buffer allocation using congestion hints to avoid unfair bandwidth sharing.

Conclusions

We have presented an adaptive resource management algorithm based on a WRR scheduler. This proposed algorithm uses the link bandwidth variations present in the DVB-S2 forward link to determine the minimum amount of resources for each traffic class considering the DiffServ architecture. To calculate the optimal weight values, we have applied two functions to associate the weights of the higher priority classes and the satellite link capacity: a linear and an exponential weight function. By employing the NS-2 simulator tool we have demonstrated that using our adaptive WRR algorithm it is possible to ensure the QoS requirements for each traffic class and to optimize the bandwidth utilization when bandwidth fluctuations caused by rain events are faced. The simulation results have shown that our exponential adaptive WRR model enforces the priority levels and guarantees the QoS parameters established in the SLA, while maintaining the queue occupancy at lower levels (compared to the RR and WRR mechanism), leading to a reduction of the system latency.

  by a sinusoidal wave (see Fig.1-dotted line) to represent a rain event in the satellite DVB-

Fig. 2

 2 Fig. 2 Structure of the adaptive DVB-S2 Hub

Fig. 3

 3 Fig.3The weight values as a function of the DVB-S2 system capacity (C OUT ).

Fig. 5 .

 5 Fig. 5. Dynamics of Weights

Fig. 6 .

 6 Fig. 6. Goodput performance results and queue occupancy with different scheduler types: (a) Round Robin mechanism, (b) Weighted Round Robin, (c) Linear Adaptive WRR and (d) Exponential Adaptive WRR

Table 1 .

 1 Parameters of each service class

	Traffic Class	Max Flows Rate per-class [Kbps] Packet Size [bytes]	C OUT [Mbps]
	EF	10	400	1500	0.4-3.4
	AF	10	800	1500	0.4-3.4
	BE	10	3400	1500	0.4-3.4