Raja Boujbel

Sam Rottenberg

Sébastien Leriche

Chantal Taconet

Jean-Paul Arcangeli

Claire Lecocq

MuScADeL: A Deployment DSL based on a Multiscale Characterization Framework

Keywords: Multiscale distributed systems, Software deployment, Domain-specific language

With the Internet of Things (IoT) paradigm, ambient systems move from locally distributed systems to Internet distributed systems. These systems become huge in term of number of devices and imply high heterogeneity (e.g., of devices, of networks). They are continuously evolving with appearing and disappearing devices at runtime. The inner complexity of these systems, called multiscale systems, requires autonomic deployment middleware. Such middleware should deploy components where and when necessary, and adapt the architecture of the deployed systems considering the different scales of the systems. In this paper, we define MuScADeL, a domainspecific language (DSL) dedicated to multiscale and autonomic software deployment. MuScADeL allows designers to abstractly define deployment properties without exact knowledge of the devices and networks the system will be deployed on. This DSL is based on a scale-awareness framework, which helps designers to characterize the multiscale nature of a system from several viewpoints such as device, network, administration and geography. With MuScADeL, deployment designers may express multiscale properties of systems to deploy. MuScADeL is a building block for deployment middleware that targets multiscale distributed systems. We illustrate the possibilities of MuScADeL through a smart transport scenario.

I. INTRODUCTION

Smart systems built over the IoT are distributed on many various computing nodes from smart sensors and mobile computers to cloud computers. Each family of host devices deals with its specific set of technologies, languages and communication protocols. Systems cross geographic and administrative boundaries, and each geographical or administrative domain requires specific rules (e.g., of communications, of privacy). We call those systems "multiscale systems". A major issue with multiscale systems is to deal with high levels of heterogeneity.

IoT projects such as SmartSantander [START_REF] Schaffers | Smart cities and the future internet: Towards cooperation frameworks for open innovation[END_REF] and IoTI [START_REF] Presser | D2.1: Initial report on IoT applicationsof strategic interest[END_REF], come with examples of smart applications deployed at a city scale. Those applications are composed of a mass of software components in interaction. The distributed sets of machines that host them (called deployment domain) are huge, and present high heterogeneity (e.g., of devices, of networks). Moreover, these systems are mostly pervasive, and highly dynamic with devices that appear and disappear during the life of the system. Despite this, IoT projects and ambient projects rarely address software deployment issue. Nonetheless, we believe that smart deployment middleware that autonomically deploys multiscale systems, becomes essential. These middleware should adapt the architecture of the deployed systems considering the different scales of the systems by deploying components where and when necessary.

In this paper we present MuScADeL (MultiScale Autonomic Deployment Language), a domain-specific language (DSL) dedicated to autonomic software deployment of multiscale systems. MuScADeL allows designers to declare multiscale deployment properties without exact knowledge of the deployment domain. For example, the designer may specify that one server should be deployed in each local area network, or in each district of a city. One foundation of MuScADeL is MuScA (Multiscale distributed systems Scale Awareness framework), a scale-awareness framework, which includes a multiscale characterization process, and multiscale probe generation software. Through a model driven approach, MuScA helps designers to identify the multiscale nature of each system from its relevant viewpoints: for example device, network, geography or administration viewpoints. Besides, we show how multiscale probes are produced from MuScA models and how they are referenced by MuScADeL. Those probes provide scale-aware capability to future deployment middleware. This paper focuses on the MuScADeL DSL and on the multiscale probes, others parts of deployment middleware are not presented.

The organization of the paper is the following. In Section II, we motivate our work through a smart transport scenario. We depict our approach in Section III. Then, in Section IV, we position our work compared to the main DSL for software deployment and their ability to handle multiscale concerns. In Sections V and VI, we respectively present the MuScA characterization framework and the MuScADeL DSL. We show how to express multiscale deployment properties for the transport scenario. Finally, we conclude in Section VII.

II. MULTISCALE DEPLOYMENT MOTIVATIONS

In this section we introduce our deployment and multiscale vocabulary, and present a scenario that will support our illustrations through the paper.

Software deployment is a post-production process that consists in making software available for use and then keeping it operational. It is a complex process that includes a number of inter-related activities such as installation of the software into its environment (transfer and configuration), activation, update, reconfiguration, deactivation and deinstallation [START_REF] Carzaniga | A characterization framework for software deployment technologies[END_REF].

A deployment plan is a mapping between a software system (a system of software components) and the deployment domain, completed with configuration data. It must take into account two kinds of dependencies: (1) between the components themselves and (2) between the components and their runtime environment. At runtime, the software system is deployed on the hosts in accordance with the deployment plan. Traditionally, the mapping and the deployment activities are undertaken or controlled by a human operator.

Multiscale systems have very complex architectures. In order to deploy these systems, and more specifically to express the properties, it is necessary to be able to describe precisely their architecture. Therefore we propose a multiscale vocabulary that aims at describing the architecture of multiscale distributed systems. As presented in [START_REF]Systems and software engineering -Architecture description[END_REF], the architecture of a system is obtained from the study of this system from different viewpoints, each viewpoint leads to a view of the system. Following this general approach, we study multiscale distributed systems from different viewpoints. There are many viewpoints and views to consider: e.g., devices included in the system, networks crossed for interacting, administrative or social organization of the users of the system, geographical distribution of the system. Then, each viewpoint of a multiscale system can be studied through several analysis dimensions, associated with measures, to define the different scales of the system. For example, the device viewpoint can be analyzed through the storage capacity dimension, measured in bytes, which leads to identify different scales of devices in terms of storage capacity: e.g., kilobytes scale, gigabytes scale and petabytes scale. This multiscale vocabulary is more detailed and formalized in Section V-B.

B. Motivating scenario

In this section, we present a motivating scenario inspired from smart city projects such as CIVITAS 1 , and developed within the INCOME2 project (Multiscale Context Management for the Internet of Things), where we focus on context management for mass market context-aware applications [START_REF]INCOME[END_REF], [START_REF] Arcangeli | INCOME -Multi-scale Context Management for the Internet of Things[END_REF]. The context management middleware is a highly heterogeneous and dynamic component-based multiscale system. Its components can be as various as ontological knowledge bases, social network analysis components, GUI components, lowlevel sensors. They must be dynamically deployed at different levels of the system, from communicating objects to cloud computers. In this project, we aim at developing a framework for the deployment of multiscale context managers and beyond of multiscale systems. The following scenario depicts some specific parts of a multiscale system, which will be used to illustrate our proposition throughout this paper.

City of Toulouse, France, 2015. The IT Department of the city recently invested in a system called "MultiModal Mobility in MultiscalE" (4ME). Its purpose is to provide citizens with a multimodal public transport control and guidance system, which aggregates data sources and services from institutional and professional providers all around the city. Offered services are for example bus itineraries, timetables and their real-time positions, bike availability in bike sharing stations, traffic alerts, parking system information. Users of this system are equipped with a smartphone connected to a network. They can benefit from dynamic guidance services, which customize their trips according to a large set of pieces of information and events (e.g., weather conditions, night vs day, preferred itineraries collected by social networks, wish to meet friends on the road).

This multiscale system mainly contains three families of software components. At the lower level, there are components dedicated to context acquisition, such as context data collectors that should be deployed in each bus, in each bike sharing station, or in each parking. Next, there are infrastructure components, such as middleware components that transport data and events between components, or components that filter and aggregate data to infer more abstract information. At the last level, the system includes business components that comprise for example the graphical user interface for the clients, or components of the route planner that should run on some cloud computers.

These various components should be deployed on many devices (from smartphones to cloud computers). They communicate with each other on different networks (from personal area network to the Internet). They must be deployed either over the whole city or at a short distance from a given place. They allow different actors to interact (from single users to communities of users). Their host devices belong to different administrative entities. Thus, this system is multiscale in the device, network, user, geography and administration viewpoints.

Within the motivating scenario, we focus on the deployment of some 4ME software components, which highlight the interest of multiscale deployment properties. The deployment process of such a system should consider a dynamic deployment domain. Moreover, multiscale properties related to the deployed components and to the deployment domain should be expressed by the deployment designer. For instance, a context management component that contains probes counting available bikes must be deployed on each bike sharing station. For load sharing purpose, a component that provides the bike availability service must be deployed every five bike sharing stations on a device connected to a WiFi network in order to distribute the computational load close to the users. A component offering the route planner must be deployed on a cloud computer hired by the city. A middleware communication component that transfers historical data to the cloud must be deployed on each local network. For each smartphone in the group of 4ME users arriving in the city, a graphical user interface component dedicated to the services currently available in the city must be deployed. The system should be able to catch any new device appearing during the lifetime of 4ME. To enrich the service, a social network component should be deployed on one smartphone chosen among the smartphones of each group of friends. This smartphone should have at least a CPU of 1Ghz, and 1Mb of available memory. This component has to be always reachable. If ever the component or the smartphone becomes unreachable, the component is dynamically redeployed on another smartphone of the group. Finally, a business component that stores the history of messages exchanged on the social network must be deployed on the cloud owned by the bike sharing service of the city.

III. MULTISCALE DEPLOYMENT APPROACH

In this section, we justify the need for software autonomic deployment in multiscale systems (Section III-A), then we exhibit multiscale deployment features from the scenario of the previous section (Section III-B), and discuss the need for a domain specific language. Finally, we introduce our approach for multiscale software deployment (Section III-C).

A. Autonomic software deployment

The traditional way of deploying a software system consists in defining a static deployment plan, enumerating which components have to be deployed on which devices. It is often made by a human operator. Multiscale systems, come with high dynamics, devices availability concerns, topology evolutions when new devices appear, and others disappear due to disconnections or failures. With multiscale systems, the deployment domain has to be discovered just in time (i.e., just before application runtime). Thus, the deployment plan must be continuously adapted to take into account the instability of the network of machines (i.e., connections and disconnections), mobility and openness, and to variations of the availability and of the quality of the resources. Moreover, a high number of devices and of software components (with their different versions) is involved in multiscale systems. Automation and autonomy in deployment management is required again.

Traditional deployment is not an option anymore. An autonomic deployment middleware is required to be able to adapt at runtime, in an uninterrupted process, the deployment plan to the effective deployment domain topology and its properties. Indeed, the autonomic computing approach [START_REF] Kephart | The vision of autonomic computing[END_REF], where the system self-manages some properties (both for selfconfiguration and self-healing purpose) provides interesting options for multiscale distributed software deployment. This is what we call "autonomic deployment".

Appropriate methods and tools are necessary to design, control and automate the deployment process. For the deployment design, we propose to describe the deployment properties, coming from different stakeholders, considering two different sets: deployment requirements concerning the architecture of the system and constraints. As an example of deployment requirement, the deployment designer may want that a given component should be installed on every smartphone of a given geographical area, or that two components should be deployed on two different devices connected to a same local network. In addition, as an example of a constraint, the designer may specify that the mobile devices considered should run Android, have an active GPS, or be connected by WiFi. All these properties should be gathered at design time by the deployment designer.

The deployment middleware ensures the satisfaction of the requirements and constraints: at deployment design time, it computes and realizes a deployment plan that satisfies all of them (if possible) then, it checks the properties during the whole life-time of the system, handles the deployment and adapts the plan after failures or changes in the topology. Note that presenting the way to handle and adapt the plan at runtime is out of the scope of this paper.

B. DSL for multiscale deployment design

To support the description of the deployment properties, the existing platforms propose formalisms such as architecture description languages, XML or DSLs. DSLs present several advantages: they use idioms and abstractions of the targeted domain, so they can be used by domain experts; they are light, easy to maintain, portable, and reusable; they are most often well documented, coherent and reliable, and optimized for the targeted domain [START_REF] Van Deursen | Domain-specific languages: An annotated bibliography[END_REF], [START_REF] Strembeck | An approach for the systematic development of domain-specific languages[END_REF], [START_REF] Tolvanen | Integrating models with domain-specific modeling languages[END_REF].

We advocate for a DSL dedicated to the expression of multiscale deployment properties. In this paper, we propose MuScADeL. It must answers to multiscale requirements, and thus allows the deployment designer to express: With this DSL, the deployment designer can describe deployment properties from which a deployment plan can be computed. The computation of the deployment plan is done during the deployment runtime by a constraint solver that also needs as input the list of all available hosts and their properties.

In order to do that, the deployment system has to handle a system of probes that collects all the required information about the hosts. Probed data range from concrete system properties such as free RAM to more abstract multiscale properties such as dimensions and scales. As an example, a multiscale geographical probe with the three scales of city, country and continent can give the information for the underlying device for each scale if available.

C. Overview of the multiscale deployment design process

Fig. 1 shows the general approach we adopt for the deployment design process. The process is detailed with a SPEM [START_REF]Object-Management-Group[END_REF] diagram. It is divided into two main steps. In the first step, we use the MuScA metamodel and a multiscale characterization process in order to define the multiscale nature of the deployment domain (select viewpoints, dimensions and scales) with a multiscale model. This model is then used through a model driven approach to generate multiscale probes, which consolidate data given by lower level probes, called basic probes. This first step of our approach is detailed in Section V. The second step aims at expressing the deployment properties using our DSL MuScADeL, described in Section VI. By using the MuScA specific model and the multiscale probes obtained in the first step as a support of properties expression, we are able to define a deployment policy that is naturally multiscale aware. During deployment runtime at the right of Fig. 1, the deployment middleware use the data collected from the probes installed in the deployment domain to deploy and adapt the software distribution.

IV. RELATED WORKS

In this section we present an overview of related works on software deployment that propose the use of a DSL. Additionally we examine how some multiscale concerns take place to a certain extent in existing solutions for software deployment.

To facilitate the deployment designer's work, Dearle et al. [START_REF] Dearle | A middleware framework for constraint-based deployment and autonomic management of distributed applications[END_REF] define the DSL Deladas. The designer specifies the deployment domain and its characteristics and a set of deployment properties (called constraints). From this specification, the framework generates a deployment plan. The constraintbased approach frees the deployment designer from specifying exactly the location of each component, and from rewriting the plan in case of problems with a resource. Deployment is resilient: at runtime, when the deployment middleware detects a constraint violation, it tries a local repair if possible. Otherwise, a new plan is generated and then executed by a "satisfy/enact" component without human intervention. However, the management is centralized and openness is not taken into account, because the set of hosts being statically defined in a file by the deployment designer. Besides, Deladas does not allow the designer expressing multiscale properties.

Matougui et al. [START_REF] Matougui | A middleware architecture for autonomic software deployment[END_REF] present a middleware framework designed to reduce the human cost of setting up software deployment and to deal with failure-prone and change-prone environments. This is achieved by the use of a high-level constraint-based language and an autonomic agent-based system for establishing and maintaining software deployment. In the DSL j-ASD, some expressions dedicated to deal with autonomic issues are proposed. But, they only target largescale or dynamic environments (such as grids or P2P systems), at the same network scale.

Sledviewsky et al. [START_REF] Sledziewski | A DSL-Based Approach to Software Development and Deployment on Cloud[END_REF] present an approach that incorporates a DSL for software development and deployment on the Cloud. Firstly, the developer uses a DSL in order to describe a model of the application. Secondly, this DSL code is translated into a specific code in charge of the automatic deployment onto the Cloud. Authors highlight the need to facilitate the work of the deployment designer, and that using DSL is a solution for that. Nevertheless, this approach is specific to deploying on the Cloud.

When we have considered existing works on software deployment, we also tried to figure out if some multiscale concerns could be expressed. Considering the network point of view, we noticed that there is actually no tool that handles more than one kind of network (most of them target local networks). From the device point of view, deployment solutions such as the one presented in [START_REF] Satyanarayanan | The Case for VM-Based Cloudlets in Mobile Computing[END_REF] for Cloudlet, or Kalimucho [START_REF] Louberry | Kalimucho: Contextual Deployment for QoS Management[END_REF], which both allow to transfer computations from devices with limited capacity to powerful computers, handle devices at different scales. But most software deployment tools are specialized for one kind of devices: personal computers in most cases, smartphones, etc. From the geography point of view, some technologies such as Codewan [START_REF] Guidec | Opportunistic Software Deployment in Disconnected Mobile Ad Hoc Networks[END_REF], Kalimucho, or Cloudlet basically take into account the proximity between hosts. So, these technologies can be considered for deploying software for multiscale systems in the geographical viewpoint. But in practice, proximity is more related to network properties than to geographic location.

The result of this study shows that there is a lack of expressiveness in existing deployment languages for defining various multiscale properties.

V. SCALE-AWARENESS FRAMEWORK

In this section we present the MuScA framework. We present the model driven approach, detail the MuScA metamodel, and its use through an example of MuScA model and generated artefacts.

A. Model driven approach

The concept of multiscale viewpoints has been introduced in Section II-B as a way to analyze the multiscale nature of the motivating scenario. Our experience shows that each system may be analyzed through different viewpoints and scales. Each characterization defines a multiscale vocabulary for the characterized system. It can be used by the deployment designer in MuScADeL and leads to the generation of specialized probes used for scale-awareness purpose at runtime.

In order to formalize the multiscale characterization process and to use it in the deployment design, we have chosen to follow a model driven architecture (MDA) approach (using the four OMG meta-modeling layers [START_REF] Bézivin | Towards a precise definition of the OMG/MDA framework[END_REF]). We define the MuScA metamodel (M2 level) with the Ecore meta-metamodel [START_REF] Budinsky | Eclipse Modeling Framework 2.0, ser. Eclipse[END_REF] (M3 level). The classes of the MuScA metamodel represent multiscale concepts. With MuScA, we are able to define characterization models (M1 level). This characterization may be used for one or several real world systems (M0 level). We also follow the model driven approach in order to automatically produce artefacts, for instance probe artefacts for scale-awareness purpose. The MuScA metamodel is shown in Fig. 2. This metamodel is based on the vocabulary used in the multiscale characterization process -i.e., multiscale characterization, viewpoint, dimension, measure, scale set, and scale. An instance of MSCharacterization is the result of a characterization process. A characterization considers several ViewPoints (e.g., at M1: Geography, User, Device, and Network viewpoints). Each viewpoint determines a restricted view of the studied system. In a given viewpoint, the view of the system is studied through several Dimensions, which are measureable caracteristics of the elements of the view. For example, for the Device viewpoint, the system devices can be analyzed through the StorageCapacity (M1) dimension. As previously mentioned, a Dimension is measurable, which means it can be associated with one or several Measures. For example, at the M1 level, the StorageCapacity dimension may be measured with the Bytes measure or the KiloBytes measure. For the association of one dimension with one measure, the designer defines a ScaleSet, which is an ordered set of scales relevant for the studied system. For numeric measures, a Scale is defined by its min and max bounds. For some viewpoints, the system may present several instances of one scale. For example, if we take the Geography viewpoint, in the Administrative dimension, the Town scale (M1) has several instances (M0 level) -i.e., the different towns where entities of the system are present.

B. MuScA metamodel

C. MuScA model as a multiscale characterization

In this section we apply a multiscale characterization process to the scenario described in Section II-B in order to build a MuScA model of the scenario. The deployment domain of the scenario is multiscale in the device, administration, network, and user viewpoints, but we only describe the device and the administration viewpoints. Firstly, we decide to study the device viewpoint through two dimensions: the storage capacity measured in bytes (numeric measure) and the type of device measured in what we call the "device type measure" (semantic measure). For the type dimension, we identify three scales (hidden in the figure): smartphone, cloudlet, and cloud. For the storage capacity dimension, we also identify three scales: kilobytes, gigabytes, and petabytes. Secondly, we study the administration viewpoint through the administrative level dimension measured in what we call the "administration level measure" (semantic measure). We identify three scales: team, service, and enterprise.

D. MuScA probes

With a MuScA model, we automatically produce artefacts for scale-awareness purpose. In particular, we generate software artefacts called multiscale probes used in the deployment middleware. These probes are monitoring programs that are to be deployed on each device of the deployment domain in order to return its associated scale for a specific scale seti.e., for a specific dimension associated to a measure in a viewpoint. We generate one probe per viewpoint, and each probe exposes one method by dimension that returns a scale. As mentioned in Section V-B, for some viewpoints, there may be several scale instances for a scale. For example, the Town scale has as many instances as real world towns involved in the system. Therefore, the multiscale probes of these viewpoints contain one more method per scale set that returns the scale instance associated to the probes's device for a specific scale. These probes and the generated methods can be completed to implement a specific logic, in particular to call basic probes, as shown in Fig. 1, or to implement specific semantic measures.

E. MuScA achievements

We have implemented MuScA with the Eclipse Modeling Framework Project3 (EMF). The MuScA metamodel is defined as an instance of the Ecore metametamodel. EMF generates a specialized model editor, which can be used to build the MuScA model presented in Section V-C. Then, we use the Acceleo4 code generator to produce multiscale probes, which are implemented in Java. We have currently implemented device and geography multiscale probes.

VI. MUSCADEL

In this section we detail our proposition of a DSL dedicated to the autonomic deployment of multiscale distributed systems, named MuScADeL, and the use of MuScA in it.

A. Elements of the language

With MuScADeL deployment designers may express multiscale deployment properties in terms of both designer requirements and components constraints. It is possible to express the deployment properties of a monolithic or of a huge component-based software on a deployment domain, which can be composed by one to thousands of devices. MuScADeL provides abstractions and can be used without a strong expertise in the realization of the deployment activities. The MuScADeL grammar has been defined in EBNF syntax 5 .

For the presentation of the language, we rely on the scenario presented in Section II-B. The code is presented in five extracts, which respectively present components (Listing 1), criteria (Listing 2), probes (Listing 3), multiscale probes (Listing 4), and deployment requirements (Listing 5).

The unit of deployment is the component. The MuScA-DeL code lists the component types of the system (keyword Component in Listing 1). A Component description has several fields. The URL field specifies the address where the component is reachable for download. The DeploymentInterface field specifies the interface of the component, that is necessary for the interactions with the deployment system since the latter must configure, start, manage, and stop the component. The Dependency field lists required components: when installing the component, the deployment system checks that whether the required components are installed, or if not, installs them. Constraints can be given when specifying a component. The Constraint field lists hardware and software criteria defined using the keyword BCriterion, see line 4 of Listing 2 -Bcriterion stands for basic criterion in opposite to multiscale criterion, cf. VI-B -and that the component must satisfy. By default, these constraints are permanent, i.e.they must be satisfied both when generating the deployment plan and at runtime, so that the deployment system must check that there is no constraint violation at runtime. Constraints can also be defined in order to be satisfied only when generating the initial deployment plan and disregarded at runtime: the keyword InitOnly allows to specify this kind of constraint. Criteria are named and specified using the BCriterion keyword. A criterion is a conjunction of conditions concerning probed values, like in CPURAM (Listing 2, line 4). There are two kinds of conditions concerning either the existence or liveliness of a probe, or a specific value given by a probe. In the first case, the condition is composed by the probe name and the keywords Exists or Active, which are defined for any probe interface. For example, in Listing 2, at line 3, the used probe is Wifi, and the condition uses default methods Exists and Active. If it is a value condition, it is composed by the probe name, a method call, a comparator, and a value. In this case, the method is probe-specific, and defined in the probe interface. For example, in Listing 2 at line 6, the used probe is RAM, the information method used is Free, and its value is compared to the number 1, for 1Mb. A criterion can be used to define both a component constraint (cf. Listing 2, line 5) or a deployment requirement (cf. Listing 5, line 5). The code in Listing 4 was generated by MuScA and integrated when the deployment designer chose a multiscale characterization model. It defines multiscale probes using the keyword MultiScaleProbe. A specific keyword is necessary because basic and multiscale probes are considered in a different way when generating the deployment plan (see Section VI-B). As Probe, MultiScaleProbe has two fields: MultiScaleProbeInterface and URL. At runtime, a multiscale probe allows to identify the scale of their host device in a given viewpoint/dimension/measure . Once all of these elements have been specified, the deployment properties of the overall multiscale system can be expressed. The operator @ allows to specify requirements specific to a component. The overall properties can take several forms as it is illustrated in Listing 5. We describe below each deployment requirement and link it to the requirements expressed in Section III-B: The component ContextMan must be installed on all the devices that (i) have the scale Cloudlet on the dimension Type of the viewpoint Device (requirement R1 -line 3) (ii) and are administrated by the service "Toulouse.SharingBikes" (requirement R3line 4). Components BikeAvail must be deployed on devices satisfying the basic criterion WifiActive, the ratio expression (requirement R4) 1/5 specifying that there should be one BikeAvail component deployed for five ContextMan components (line 5). One component RoutePlanner must be deployed (i) on the scale Device.StorageCapacity.Giga (requirement R1) and (ii) in the city of Toulouse (requirement R3 -line 6 and 7). Components Comm must be deployed on one device of each local network area (LAN) (requirement R3 -line 8). The component GUI must be deployed on all devices of the scale Device.Type.Smartphone (requirement R1), i.e., on all the smartphones of the domain (line 9). The component SocNetHist (which keeps a history of the social network chatroom) must be deployed on a device that belongs to the same group as the device on which the component SocialNet is deployed (requirement R2 -line 12). The component Stat (which calculates statistics on bike use) must be deployed on 5 to 10 devices (requirement R4) of the scale Device.Type.Cloudlet (requirement R1 -line 15).

The keyword DifferentValue allows to specify the contrary of SameValue. Using these keywords, it is possible to define a requirement concerning a scale. For example, Comp @ SameValue Device.Type(Comp2) expresses that the component Comp must be deployed on a device that has the same type as the component Comp2. Some constructions of the DSL are particularly dedicated to the expression of properties related to dynamics and openness. We have already mentionned that, by default, constraints on the deployed components have to be satisfied at runtime. Besides, when specifying the Deployment, the keyword All states that a component should be deployed on a domain, even if the domain evolves dynamically, that is to say on devices entering the domain (and considering those leaving it). In the example, the component GUI should be deployed on every smartphone of the domain, including those that enter in the domain after activating 4ME application; so, the deployment plan evolves dynamically according to entering and leaving devices.

B. MuScA in MuScADeL

As shown in the previous code, deployment designer requirements may include multiscale related requirements. As a MuScADeL code is linked to a MuScA specific model, the MuScADeL editor can check that dimensions and scales conform to the ones defined in the MuScA model associated with it. In addition, multiscale requirements are verified at runtime by the multiscale probes generated for this MuScA model.

Fig. 3 is a UML class diagram that summarizes the MuScA and MuScADeL metamodels. Only some parts of the models are shown in order to highlight the links between them. The MuScADeL metamodel is limited to the criterion part of the deployment requirement.

In the MuScADeL metamodel, Criterion is specialized in MSCriterion to express multiscale criteria. This element is specialized in CompValue, Each, and Simple to handle the different multiscale deployment requirements policies expressed in Section VI-A (multiscale criteria appear in such a way in the MuScADeL code, cf. Listing 5; contrary to BCriterion there is no keyword to define them). For example, Each stands for "on each device". The expression of a multiscale criterion can concern either a Scale (M1 level) or a Scale Instance (M0 level). For example, we can express the deployment of a component on each LAN (M1 level) or on a specific LAN (M0 level).

This link between MuScA and MuScADeL insures a correct use of the multiscale probes in the expression of deployment requirements.

C. MuScADeL achievements

Using Xtext and Xtend frameworks 6 , we have realized an Eclipse plugin for the edition of MuScADeL. Using Java and Eclipse makes MuScADeL editor multi-platform compliant and easy-to-use for the deployment designer. Moreover, it runs alongside MuScA, allowing the deployment designer to be able within the same engineering tool to define new multiscale viewpoints, dimensions or scales, before using them in the deployment DSL.

VII. CONCLUSION

Autonomic software deployment is essential to install upto-date multiscale distributed systems. Over the past decade, some deployment frameworks for distributed systems have emerged. They have limitations in terms of the targeted deployment domain, and in term of autonomicity. In this paper, we have presented MuScADeL a domain-specific language for autonomic deployment of multiscale distributed systems such as those experienced with the IoT.

MuScADeL allows designers to abstractly define multiscale deployment properties without exact knowledge of the deployment domain. MuScADeL properties are expressed in accordance with the multiscale characterization of the system to deploy. The multiscale nature of a system is defined with MuScA, a framework to identify the relevant viewpoints, dimensions, measures, and scales for a given multiscale system. MuScA has been used with the INCOME project for software infrastructure for context management in the context of the IoT. This project targets the deployment of mass market smart applications. For this project, we have analyzed many scenarios and use cases in ambient systems. With the characterization process, we have been able to select, among existing ones, the viewpoints, dimensions and scales relevant for a given system, or to define new ones. Each characterization enables the framework to extend its multiscale vocabulary and its multiscale probes. Thus the framework learns and memorizes new viewpoints, dimensions and scales to be proposed for the next characterization.

Our contribution has been validated through a complete chain of frameworks. Specialized editors allow designers to define and validate multiscale characterization and multiscale deployment descriptors. MuScA generates multiscale probes for scale-awareness purpose. This chain will be used by multiscale deployment middleware that apply deployment properties defined with MuScADeL.

Fig. 2 .

 2 Fig. 2. MuScA: Multiscale characterization metamodel

Fig. 3 .

 3 Fig. 3. Part of the MuScADeL metamodel, including MuScA use

Design time (SPEM Process) Deployment runtime

	R1 Device requirements in terms of scales (e.g., of local
	memory, storage capacity, processing power or network
	connectivity);
	R2 Network or geography requirements in terms of the small-
	est scale shared by two devices (e.g., the two considered
	devices are required to be in the same local area network,
	or in the same city);
	R3 Deployment requirements concerning the network, geog-
	raphy, user and administration scales to which the deploy-
	ment devices should belong (e.g., deploy a component on
	the smartphones that arrive in the city);
	R4 Deployment requirements to specify ratios of components
	(e.g., deploy one component A for every four components
	B).
	MuScADeL
	Multiscale characterization			Deployment properties
	(MuScA)	Work Product
		MuScA
		Speci c
		Model
	Deployment Designer
				Work Product
		Generation of Multiscale Probes	Multiscale Probes	Work Product
	Work Product			Deployment properties expression	MuScADeL Deployment properties
	Basic
	Probes
	Deployment middleware
				Multiscale
				Probes
				Basic
				Probes
	Deployment domain
	1	2	3
	Scale	Scale	Scale
	Fig. 1. Overview of the MuScADeL process

http://www.civitas.eu/content/public-transport-control-and-guidance-system

http://anr-income.fr

http://www.eclipse.org/modeling/emf/

http://www.eclipse.org/acceleo/

The full grammar is available at http://www.anr-income.fr/T5/ muscadel-ebnf.html

www.eclipse.org/Xtext

ACKNOWLEDGMENT

This work is part of the French National Research Agency (ANR) project INCOME [5] (ANR-11-INFR-009, 2012-2015). The authors thank all the members of the project that contributed directly or indirectly to this paper.


Rejane Dalce
email: dalce@irit.fr

Adrien Van Den Bossche

Thierry Val
email: val@irit.fr

An experimental performance study of an original ranging protocol based on an IEEE 802.15.4a UWB testbed

In this article, we study the behaviour of an Ultra-Wide Band (UWB) physical layer when executing our protocol Parallel Symmetric Double-Sided Two-Way Ranging. We compare it to the reference protocol introduced in IEEE 802.15.4a, Symmetric Double-Sided Two-Way Ranging, in terms of precision of the obtained estimates and to other existing protocols such as SDS-TWR-MA and D-TWR in terms of overhead. These samples were obtained using a testbed made of IEEE 802.15.4a UWB nodes. From these first experiments, we derive a simple correction mechanism which reduces the localisation error compared to the case where no dynamic correction takes place. The location error reduction varies between 41 and 60% while the algorithm manages to estimate the position 99.9% of the time with the addition of the correction.

I. INTRODUCTION

It has been many years since the scientific community has started studying the issue of localisation in the context of the Internet of Things (IoT). Many propositions have targeted Wireless Sensor Networks (WSNs). Although rangefree solutions are usually simple enough to be implemented directly on the sensor nodes, many researchers focus on rangebased methods as they offer better performance. Unfortunately, this performance comes at a certain cost: in order to remove error from real-time measurements, sophisticated algorithms are used which often require a central server. This may yield very good results but this additional cost cannot be overlooked when planning a real-life deployment.

Our objective is to enable fast and cost-effective deployment of indoor WSN-based localisation solutions. We achieve this by integrating our ranging protocol in the existing protocol stack and developing simple algorithms which are suitable for the targeted platforms. In this article, we study the impact of our proposed protocol on the ranging performance of an Ultra-Wide Band (UWB) physical layer. We identify the need for an adjustment of the range measurements by the mobile node, despite the common belief that UWB would be the Graal of localisation.

Following this introduction, we briefly present in section II relevant protocols for TOF-based ranging. Then, we describe the challenge of integrating localisation in a real WSN and our proposed protocol in section III. We show the results obtained using a real UWB testbed in section IV and we finally conclude and present future work in section V.

II. RELATED WORK

In 2007, IEEE proposed two PHY layers for low rate, low power WSNs. The first one, CSS, was included as it supported long distance links at high speed. The second one, UWB, was supposed to bring localisation capability to the WSN. As a matter of fact, the research community did not wait for these two technologies to design solutions for wireless network. In [START_REF] Bahl | RADAR : An In-Building RF-Based User Location and Tracking System , Infocom, mars[END_REF], signal power and SNR are used to calculate position through a fingerprinting approach. The work described in [START_REF] Lanzisera | RF Time of Flight Ranging for Wireless Sensor Network Localization[END_REF] consists of Time Of Flight estimation using cross-correlation between two nodes modified in order to use the complete IEEE 802.15.4 band. In both [START_REF] Liu | Sensor Localization with Ring Overlapping Based on Comparison of RSSI, Mobile Ad-Hoc and Sensor Systems[END_REF] and [START_REF] Wang | High Accuracy Geometric Localization Scheme for Wireless Sensor Networks[END_REF], the concept of rings is used to localise mobile nodes. The rings facilitate the computation of the position but they are often built using unreliable sources such as the received signal strength indication (RSSI).

The particularity of UWB is the expected ranging precision. This word refers to the relative proximity of the range estimates to one another while accuracy is used to describe the distance between the estimate and the truth. UWB uses very short pulses to measure the Time Of Flight (TOF). The uncertainty is therefore small which results in precise measurements. But unfortunately, this does not necessarily imply high accuracy. Accuracy is a matter of clock granularity mixed with first path recognition and environmental influences. In order to reduce the influence of clock drift, Symmetric Double-Sided Two-Way Ranging (SDS-TWR) was introduced in [START_REF]Specific requirements Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs) Amendment 1: Add Alternate PHYs, IEEE Standard for Information technology Telecommunications and information exchange between systems[END_REF]. SDS-TWR calls for the execution of Two-Way Ranging twice: the first TWR is led by the mobile and the second by the anchor on figure 1. One last message is necessary in order to share the timestamps collected by the anchor with the mobile. The existence of a PHY layer suitable for both WSNs and localisation encouraged the study of alternative ranging protocols such as [START_REF] Kwak | A new Double Two-Way Ranging algorithm for ranging system[END_REF], [START_REF] Baba | Burst mode symmetric double sided two way ranging[END_REF] and [START_REF] Kim | Double-Sided Two-Way Ranging Algorithm to Reduce Ranging Time[END_REF]. These protocols have a common goal which is to improve precision by multiplying the measurements. In Double TWR (D-TWR) [START_REF] Kwak | A new Double Two-Way Ranging algorithm for ranging system[END_REF], the mobile sends the start message twice while the anchor replies once. In [START_REF] Baba | Burst mode symmetric double sided two way ranging[END_REF] (Burst), the mobile sends the first message k times. The anchor also replies k times and finally the mobile acknowledges each message. In [START_REF] Kim | Double-Sided Two-Way Ranging Algorithm to Reduce Ranging Time[END_REF], the anchor replies k times to the mobile thus the name SDS-TWR Multiple Acknowledgement (SDS-TWR-MA).

Our aim is to design a protocol suite and algorithms which will take advantage of the ranging capability of the PHY layer. Instead of modifying the radio transceiver, we characterize its functions and allow the upper layers to make the best decisions based on this knowledge. We strive to keep this information to a minimal size as our objective is autonomous localisation, that is the mobile node will compute its own position based on real-time measurements. In [START_REF] Dalce | Localization methods using the communication signal in indoor wireless sensor networks[END_REF], we proposed a protocol called Parallel Double-Sided Two-Way Ranging (PDS-TWR) that lowers the cost of ranging in terms of overhead and energy consumption. The protocols introduced in [START_REF] Maman | An Intuitive Prioritised Medium Access Scheme for Tracking Applications in UWB LDR-LT Networks, Personal, Indoor and Mobile Radio Communications[END_REF] share common goals with our solution, specifically, reusing frames to reduce the overhead. Aside from this, the structure is completely different: The network is dedicated to tracking: the anchors periodically broadcast ranging requests during tg. In the Broadcasted Requests and Responses -Immediate ACK (BRR-IA) scheme, each neighbouring mobile node replies in a separate slot and immediately receives the acknowledgements from all the anchors. In the Broadcasted Requests and Responses -Broadcasted ACK (BRR-BA) scheme, the acknowledgements are only sent once at the end of the process. In [START_REF] Maman | Synergetic MAC and Higher Layers Functionalities for UWB LDR-T Wireless NEtworks[END_REF], the authors introduce a time structure for the network but all operations are scheduled by the PicoNet Coordinator (PNC). Specifically, the PNC is in charge of allocating Guaranteed Time Slots for localisation between a mobile and its neighbouring anchors. This goes against our approach which is to only involve a limited number of nodes in the localisation process by only relying on local communications to arrange a meeting between the mobile and the anchors.

We designed a ring-based algorithm named inter-Ring Localisation Algorithm (iRingLA) since this approach leads to simpler computations which can be supported by sensor nodes, even the more constrained ones. Once PDS-TWR ended, iRingLA was applied to the collected data and we noticed a need for further data correction. In this paper, we study the behaviour of our ranging tool and propose a strategy to cope with the errors.

We will now introduce our protocols and the preliminary results which will be the building blocks of our solution. In [START_REF] Dalce | Indoor Self-Localization in a WSN, based on Time Of Flight: Propositions and Demonstrator, International Conference on Indoor Positionning and Indoor Navigation[END_REF], we studied Sequential SDS-TWR (SSDS-TWR) using the Chirp Spread Spectrum (CSS) technology [START_REF]Specific requirements Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs) Amendment 1: Add Alternate PHYs, IEEE Standard for Information technology Telecommunications and information exchange between systems[END_REF]. The idea is to execute SDS-TWR once between the mobile and each participating anchor. Figure 2 illustrates the execution of SSDS-TWR with anchors A, B and C. We proposed a new ranging protocol named Parallel DS-TWR (PDS-TWR) in order to reduce the overhead associated with localisation by replacing 2n messages from the mobile to n anchors with two broadcasted frames. Figure 3(a) illustrates the frame exchanges taking place in PDS-TWR. The mobile broadcasts a Location-Start message containing the list of anchors with which it wishes to perform ranging. The anchors reply one at the time according to their position in the list. Once the last Reply1 has been received or a timer has expired, the mobile sends the Data-Request: upon reception of this message, the anchors send the collected timestamps to the mobile in an orderly fashion. In [START_REF] Dalce | Localization methods using the communication signal in indoor wireless sensor networks[END_REF], a theoretical study of the advantages of PDS-TWR was presented: by reducing the time spent listening for incoming frames and also sending messages, PDS-TWR reduces the energy consumption of the localisation process. The protocol specification reduces both the number and size of the messages. The expected downside is related to the precision: since PDS-TWR reuses the timestamps of the Reply1 frame for both estimations of TWR, it is more sensitive to multipath. Figure 3(b) shows the timestamps collected for a single anchor: the mobile collects t 0 , t 3 and t 4 while the anchor stores t 1 , t 2 and t 5 . By specifying the order of the replies, we avoid using a carrier sense scheme and do not need to execute the ranging process again to accommodate anchors which were unable to get a hold of a slot. As a matter of fact, we also defined in [START_REF] Dalce | Indoor Self-Localization in a WSN, based on Time Of Flight: Propositions and Demonstrator, International Conference on Indoor Positionning and Indoor Navigation[END_REF] the concept of star interval: it is a time slot similar to an IEEE 802.15.4 GTS but allowing communication between a mobile and n selected anchors, forming a star topology. This star interval is created on demand and takes place during the sleep period of the network. This way, we avoid interference from the other nodes.

Although the ranging capability is very useful, from a WSN point of view, bandwidth usage is also a key aspect of every additional service. The localisation service is no exception: the induced overhead must be minimised. This aspect has been taken into account when designing PDS-TWR. Figure 4 illustrates the relationship between the overhead associated with PDS-TWR, SDS-TWR-MA, Burst and D-TWR. It becomes clear that the minimal overhead is obtained with PDS-TWR. This reduction in medium access will lead to a cut in the consumed energy and therefore augment the lifetime of the network. Our concern is the impact of this change in the protocol on the ranging results. In this article, we will introduce the data collected from our UWB-based testbed and, through this data, study the relationship between the protocol and the ranging performance.

IV. MEASUREMENTS AND RESULTS

Our experiments were conducted using UWB-based nodes from [12]. These nodes operate in the 5GHz band with a bandwidth of 500MHz. In our study, the microcontroller is used to control the transceiver instead of a remote computer through a Cheetah [13]. We used the following configuration in our ranging experiments: the two anchors are placed side by side and the mobile moves away from both along the line that can be drawn between the two. At predefined positions, ranging is performed. As triangle A 1 A 2 P k becomes more acute, the sides can be considered as equal to the height. In our setting (figure 5), the closest position of the mobile is P0 and the height is then 30cm. The base of the triangle, A 1 A 2 , is 5cm wide therefore the real distance from antenna to antenna is 30.1cm. The height h can be written as equation 1:

h = s 2 -p 2 (1)
where s is a side of the triangle and the real distance between the mobile and an anchor and p is one half of the distance between the two anchors. Since p is constant, when s¿¿p, h converges towards s. The inherent placement error will therefore be under a millimetre.

We will use the following definitions in our work: accuracy will refer to the distance between the samples and the value to be estimated. Precision will describe the scattering of the samples.

A. SSDS-TWR in open space

For the first experiment, the mobile executed SDS-TWR sequentially with two anchors, A1 and A2. As shown on figure 6, using this protocol, the results are the same regardless of the anchor node. The mean error over this interval is 38.5 cm with a standard deviation of 68 cm for node A1. The mean error for node A2 is 45.6cm and the standard deviation is 33cm. It is interesting to note that the slope of the resulting line is close to the slope of the real distance. This suggests that rotating the results' curve could significantly reduce the error. We also observed that from time to time, the devices may generate an estimate which is very far from the expected values, even though SDS-TWR is used. Nevertheless, this occurs usually once for thirty samples so calculating a mean of two consecutive measurements would solve this issue.

Based on these results, we can see that SDS-TWR delivers a correct estimated distance in an indoor environment.

B. Study of the impact of PDS-TWR

We will now investigate the behaviour of our ranging tool when using PDS-TWR. The experiment will take place in two environments. The first one is the same open space which was used for the study of SDS-TWR. The second environment is an anechoic room. This is a specially assembled room where the walls and ceiling are covered with radiation absorbent material. This product absorbs radio signals and thus shields the devices from external radiations while also eliminating multipath.

1) PDS-TWR in open space:

Figure 7 shows the result of PDS-TWR using two anchors in an indoor office environment. This time, the two curves are separated by a mean distance of 45 cm, which results in different mean ranging errors for the two anchors. The mean error associated with A1 is 94.7cm while the mean error for A2 is 49.6cm. In this configuration, A1 is the first node to reply to the mobile. UWB being known to be robust to multipath, this difference in the behaviour should not be related to the environment but to the use of our protocol. The following section analyses the effect of a drastic environment modification on the results.

2) PDS-TWR in anechoic chamber:

In order to verify the immunity of UWB to multipath, we conducted the same experiment in our anechoic chamber. The results are shown on figure 8. A similar behaviour can be observed for the two anchors. The mean ranging error for A1 is 97 cm and 42cm for A2.

3) Impact of a change in the reply order: When evaluating the expected precision of a TOF-based ranging protocol, one key factor is the clock difference between the mobile and the anchor. Since our protocol introduced an order in the replies, we will investigate the impact of this order on the ranging error. A2 was configured to reply before A1. The experiment was conducted in the previous open space. The results are shown on figure 9. Although the slope is still the same, the relative positions of the curves have changed. This suggests that the order of the replies also influences the nodes.

Table I summarizes the results of the experiments. The use of PDS-TWR introduces a significant ranging error, compared to SDS-TWR. We consider that both the order of the replies and clock characteristics influence the results. The distance estimates must therefore be adjusted before being submitted to the localisation algorithm. In the following section, we will study a calibration-based correction method.

C. Proposed correction scheme

At first, we planned on using a simple subtraction to remove the error since the slope obtained through SSDS-TWR was mostly the same over the measurement interval. We then came to realise that not only did PDS-TWR have an impact on the range measurements, but the order in which the anchors were set to reply affected the results. Based on this, we decided to study a simple correction scheme. We defined a calibration position P in our topology. At initialisation time, the mobile is placed on this spot and it performs PDS-TWR k times. Based on these measurements and the knowledge of the distance between the calibration point and the anchors, the mobile determines the error and uses the appropriate value to correct the future distance estimates.

In this experiment, we set k to 6. The topology is illustrated on figure 10. The number of nodes being limited, the measurements were performed using only 2 anchors. Our mobile node generates a list of range measurements for each point and indicates the correction value used. To evaluate the gain, we produced a copy of the data obtained from the mobile and removed the correction. Both files were processed using the same algorithm. The results in terms of localisation error are shown on figure 11. The error reduction varies from 41% to 60% depending on the width of the rings, which is a parameter of iRingLA. Another interesting result is the reduction of cases where the position could not be computed. We often encountered the case represented on figure 12 when using the raw measurements. A ring is centred on an anchor and represents the area in which the mobile excepts to be located, based on the ranging results. The overlapping region of two or more rings corresponds to the search area of our algorithm. In this case illustrated on figure 12, an intersection cannot be found between the rings. When applying the correction scheme, the rings are shrunk using different correction factors which leads to the creation of an intersection. This reduction mostly happens for thin rings which are between 10cm and 30cm. Out of our 6048 samples and using only two anchors, our solution can compute the position 99.9% of the time with a mean location error under 1m (less than 1m in 74% of the cases) in a real indoor environment. This situation corresponds to the case where a mobile reaches the border of the network coverage. Even when only two anchors are available, by using the negative information (for instance, progressive loss of radio links to other anchors), the mobile can still compute its position.

V. CONCLUSION

Designing an efficient localisation solution for WSNs is a real challenge today as appropriate physical layers are becoming available. The challenge is not only related to localisation performance but also to the integration of the solution in the network. We studied in this article the effect of using a ranging Fig. 12. Typical case which is solved using the correction protocol which is very interesting from a network point of view on range estimation. PDS-TWR interweaves the ranging processes between a mobile and n anchors. We noticed that it affects the accuracy of the estimation and proposed a correction scheme which reduces the localisation error. A more efficient correction method is currently under study and is based on the modelling of the ranging error in PDS-TWR, taking both the order of the anchors' replies and the clock characteristics into consideration. Finally, we will investigate the effect of the loss of symmetry in PDS-TWR, compared to SDS-TWR. Nevertheless, our contribution allows easy deployment of a localisation service as it is designed to fit in the IEEE 802.15.4 stack. Overhead could be further reduced through piggybacking which is taking advantage of existing frames such as beacons or routing protocol's Hello-messages to perform ranging. This will enable innovative applications in both WSNs and the IoT. The next step is the study of the scalability of this correction scheme. In a real deployment, frequent calibration might not be feasible. Therefore, a detailed study of the source of the error in detail is necessary in order to propose a decentralised correction scheme where the anchors will compute their contribution to the error and transmit it to the mobile node.

Fig. 1 .

 1 Fig. 1. Symmetric Double-Sided Two-Way Ranging

Fig. 2 .

 2 Fig. 2. Execution of Sequential SDS-TWR

Fig. 3 .Fig. 4 .

 34 Fig. 3. Execution of Parallel Double-Sided Two-Way Ranging

Fig. 6 .

 6 Fig. 5. Measurement settings

Fig. 7 .Fig. 8 .

 78 Fig. 7. Range measurements using PDS-TWR and two anchors in an open space

Fig. 9 .

 9 Fig. 9. Range measurements using PDS-TWR with reversed reply order

Fig. 11 .

 11 Fig. 10. Test topology

TABLE I

 I

	.	COMPARISON OF RANGING PRECISION OF SDS-TWR AND
			PDS-TWR
	Scenario	Mean error(cm) A1/A2	Standard deviation (cm) A1/A2
	SDS-TWR	0.33/0.38	0.45/0.67
	PDS-TWR open-space	94/49	11/25
	PDS-TWR anechoic	97/42	11/15
	PDS-TWR o-s reversed	16/-94	22/11

ACKNOWLEDGMENT

The authors would like to thank Decawave for the UWB nodes and their support, and IUT de Blagnac, France, for the access to the anechoic chamber.