Michel Albonico
email: michelalbonico@utfpr.edu.br

Jean-Marie Mottu
email: jean-marie.mottu@inria.fr

Gerson Sunyé
email: gerson.sunye@inria.fr

Frederico Alvares
email: frederico.alvares@inria.fr

Controlling Cloud-Based Systems for Elasticity Test Reproduction

Keywords: Cloud computing, Elasticity, Elasticity testing Test reproduction, Speediness

Systems deployed on elastic infrastructures deal with resource variations by adapting themselves, which is error-prone. Therefore, we must test Cloud-Based Systems (CBS) throughout elasticity. Such tests may be re-executed regularly to diagnose and fix CBS bugs, which requires to design tests to execute in a deterministic manner. In this paper, we identify three main challenges that testers face when reproducing elasticity tests: to control the elasticity behaviour, to select specific resources to be deallocated, and to coordinate events parallel to elasticity. Since elasticity tests can last long, we consider the test execution time as a secondary challenge. In this paper, we propose an approach that meets such challenges. Experimental results show that the proposed approach successfully reproduces elasticity-related bugs that face the listed challenges while reducing the execution time.

Introduction

Elasticity is one of the main reasons that make cloud computing an emerging trend. It allows to allocate or deallocate system resources according to demand [START_REF] Herbst | Elasticity in Cloud Computing: what it is, and what it is not[END_REF][START_REF] Bersani | Towards the formalization of properties of Cloud-based elastic systems[END_REF]. Therefore, Cloud-Based Systems (CBS) must adapt themselves according to resource variations. These adaptations are not trivial and may affect the CBS execution. According to Bersani et al. [START_REF] Bersani | Towards the formalization of properties of Cloud-based elastic systems[END_REF]: "Scaling resources may incur in non-trivial operations inside the system. Component synchronization, registration, and data migration and data replication are just the most widely known examples[. . . ], which may degrade system QoS." Therefore, to guarantee their quality, we must test CBSs in the presence of elasticity, i.e., elasticity testing.

During CBSs development, tests may be regularly re-executed [START_REF] Engstrom | A systematic review on regression test selection techniques[END_REF] to detect, diagnose, and correct bugs, where each execution must reproduce the same behaviour. This requires to design elasticity tests to be deterministic, which raises four challenges that we have identified: three functional and one nonfunctional. The first challenge (functional) is to repeat the CBS elastic behaviour by managing sequences of resource allocations and deallocations. In this case, the same elastic behaviour leads the CBS to repeat its adaptations over the multiple test executions. As a consequence, this reproduces the issues related to those adaptations, in case such issues have not been corrected. Looking into two CBSs bug tracking, i.e., MongoDB 1 and ZooKeeper2 , we measure that as soon as bugs are related to elasticity, all of them require to be able to repeat the CBS elastic behaviour.

By analysing further MongoDB and ZooKeeper bug tracking, we realize that other elasticity-related bug reproductions require to combine the elastic behaviour along with two further conditions, which we consider as second and third challenges. At least one of them is required 70% and 67% of the MongoDB and ZooKeeper bugs respectively.

The second challenge (functional) is to repeat time-based events, where elasticity tests may require to repeat an elastic behaviour, and to synchronize time-based events with specific CBS states. This is required when testing ≈40% of MongoDB and ≈33% of ZooKeeper elasticity-related bugs. An example is the MongoDB NoSQL database bug 7974 [START_REF]Suppress stack trace on replication errors[END_REF], where two time-based events are required to reproduce the bug: [START_REF] Herbst | Elasticity in Cloud Computing: what it is, and what it is not[END_REF] to create a unique index before one of the MongoDB nodes is removed by a resource deallocation, and (2) to upload a document after a new node is added by a resource allocation.

The third challenge (functional) is to repeat a specific CBS components variation, what we call selective elasticity. Elasticity tests may require repeat an elastic behaviour, and to remove a specific CBS component during a resource deallocation. This is the case when testing ≈44% of both MongoDB and ZooKeeper elasticity-related bugs. An example is the Apache ZooKeeper bug 2164 [START_REF]Zookeeper bug 2164: Fast leader election keeps failing[END_REF], which only occurs when the ZooKeeper leader component is removed by a resource deallocation.

Finally, reproducing elasticity tests has a fourth challenge (non-functional), to reduce elasticity test execution time. Reducing the execution time can also save money since in cloud computing the billing model is pay-as-you-go, where customers are charged by the time they use resources. One way to do this is to anticipate the reaction to resource demands. Indeed, driving CBSs is time consuming since elastic controllers take a while (at least 60 s) to react to a resource demand. This, summed to the time to allocate or deallocated a resource, result in test executions that last hours, or even days, depending on the length of the elasticity states sequence.

In this paper, we present an approach and a prototype to address the three functional listed challenges in reproducing elasticity tests: the reproduction of an elastic behaviour, the scheduling of time-based events, and the reproduction of CBS components variation. The approach also addresses the non-functional challenge by anticipating the reaction to resource demand, and as a consequence, accelerating the test reproduction.

To support our claims, we conduct five experiments with two different CBS case studies. The first two experiments aim at measuring the test execution time reduction when using the proposed approach. The other three experiments aim at reproducing three existing elasticity-related bugs by controlling the test reproduction with the proposed approach.

The remainder of this paper is organized as follows. In the next section, we remind the major aspects of cloud computing elasticity, and a previous work of part of the authors in driving CBSs throughout elasticity. Section 3 details the challenges in elasticity test reproduction and introduces the proposed approach. The experiments and their results are described in Sect. 4. Section 5 discusses the related work. Finally, Sect. 6 concludes.

Cloud Computing Elasticity

This section defines the main concepts related to Cloud Computing Elasticity, which will help the understanding of our approach.

Typical Elastic Behavior

Figure 1 presents the typical behavior of elastic cloud computing applications. In this figure, the resource demand (continuous line) varies over time, increasing from 0 to 1.5 then decreasing back to 0. A resource demand of 1.5 means that the application demands 50% more resources than the current allocated ones.

When the resource demand exceeds the scale-out threshold and remains higher during the scale-out reaction time, the cloud elasticity controller assigns a new resource. The new resource becomes available after a scale-out time, the time the cloud infrastructure spends to allocate it. Once the resource is available, the threshold values are updated accordingly. This behavior is similar when considering a resource scale-in, respectively. Except that, as soon as the scale-in begins, the threshold values are updated and the resource is becomes unavailable. Nonetheless, the infrastructure needs a scale-in time to release the resource.

Elasticity States

Workload fluctuations lead to resource variations (elasticity) that drive the CBS throughout elasticity-related states. Figure 2 At the beginning the CBS is at the ready state (ry), when the resource configuration is steady (ry s substate). Then, if the CBS is exposed for a certain time (scale-out reaction time, ry sor substate) to a pressure that breaches the scale-out threshold, the cloud elasticity controller starts adding a new resource. At this point, the CBS moves to the scaling-out state (so) and remains in this state while the resource is added. After a scaling-out, the CBS returns to the ready state, and can move either back to a scaling-out state or to a scaling-in state (si).

Elasticity Control

When testing CBSs throughout elasticity, testers should be able to drive the CBS in a deterministic way, controlling its elastic behaviour. Thus, they can be more specific and model situations they judge as critical. Furthermore, this can also reduce testing execution time since the elasticity behaviour is specific. In cloud computing, this also means reduction of cost since most of cloud providers use the policy of pay-as-you-go, where consumers pay for the time they use resources.

We can categorize CBS driving into two groups: (i) direct resource management, and (ii) generation of adequate workload. The first and simplest one (i) interacts directly with the cloud infrastructure, asking for resource allocation and deallocation. The second one (ii) consists in generating adequate workload variations that drive CBS throughout elasticity states, as previously explained in Sect. 1, which reproduces a realistic scenario. The second group is more complex since requires a preliminary step for profiling the CBS resource usage, and calculating the workload variations that trigger the elasticity states.

In a previous work [START_REF] Albonico | Controlling the elasticity of web applications on Cloud Computing[END_REF], we propose a CBS driving approach that fits in the second group. That approach is based in the assumption that elasticity state transitions occur due to workload variations that eventually breach the thresholds, as illustrated in Fig. 1. We provide further details about this approach in the following paragraphs.

An input workload has three characteristics [START_REF] Gambi | Testing elastic computing systems[END_REF]: workload type, request mix, and request intensity. The workload type is the type of requests sent to the CBS, such as read and write operations. The mix of requests is the set of requests associated to a workload type. Finally, the request intensity is the amount of requests sent to the CBS in a period. Then, given a workload type, the CBS driving approach calculates the requests intensity variation that should drive the CBS throughout a pre-set list of elasticity states.

Figure 3 depicts the approach workflow, which has three execution phases: workload profiling, workload calculation, and application leading. Fig. 3. CBS driving procedure workflow [START_REF] Albonico | Controlling the elasticity of web applications on Cloud Computing[END_REF].

The workload profiling phase has four parameters: the target CBS, the workload generator, the workload type, and the Profiling Intensity (PI). The target CBS is the CBS driven throughout elasticity. The workload generator is the tool that generates the workload. The workload type describes the type or set of requests sent to the CBS. Finally, the PI defines the number of requests per second sent to the CBS during the workload profiling phase.

To profile the effect of the workload on the CBS, the approach generates the workload according to the workload profiling parameters. Then, it calculates the Average Resource Usage (ARU) for the period, which is the input of the workload calculation phase.

In the workload calculation phase, the CBS driving approach calculates the request intensity(ies) that drive the CBS throughout the Required Elasticity States (RES), which we call workload intensity(ies).

Therefore, to drive a CBS throughout elasticity states we must know which are the workload intensities that breach the scale-out, and the scale-in thresholds, which we call multipliers. The scale-out multiplier, denoted by M so , is the workload intensity that breaches the scale-out threshold. The scale-in multiplier, denoted by M si , is the workload intensity that breaches the scale-in threshold.

After discovering the multipliers, the CBS driving approach calculates the workload intensities for each elasticity state in the RES. For scaling states, i.e., scaling-out and scaling-in, the workload intensity must breach a threshold, while for the ready state it must not breach any threshold. However, since scaling states change the amount of resources over time, the amount of allocated resource (AR) is a key parameter. The approach calculates the workload intensities by multiplying it by M so and M si . We call the product of this multiplication as current multiplier (CM ), where CM so = M so • AR and CM si = M si • AR. Such multipliers correspond to the workload intensities that drive the CBS through the scaling-out and the scaling-in states, denoted by W I so and W I si . The workload intensity for ready states (W I ry s ) is calculated as ι percent of CM so (W I ry s = ι 100 • CM so ), where ι is a configurable parameter. Such intensity must lead the resource usage to a level close to CM so , a significant amount of work, but without breaching any threshold.

In the application leading phase, we lead the CBS using the calculated workload intensities (W I), which is presented in Algorithm 1. We expose the CBS to each workload intensity until the related elasticity state ends. To identify the elasticity state transitions, the approach monitors the cloud infrastructure periodically.

Algorithm 1. Application Leading.

Data: workload intensities W I monitorElasticity(); foreach p < s, i > ∈ W I do while s.isU p do generateWorkload(i); end end

Elasticity Testing Approach

In this section, we first present the challenges in elasticity test reproduction, then we present the overall architecture of our approach and aspects of the prototype implementation.

Challenges in Elasticity Test Reproduction

Elasticity test reproduction consists in exposing the CBS to the same conditions as previous executions, which should stimulate it to repeat the same behaviour. Then, testers can find CBS bugs, correct them, and then check whether they have been fixed, requiring several runs of failed tests. Another use is to check if changes in the CBS, such as new features, affect its behaviour, or introduce bugs.

To discover which are the conditions that CBSs face, we analyse elasticityrelated bugs reported in the bug tracking of two popular CBSs: MongoDB and ZooKeeper. Bug reports have rich information since developers use them to implement tests reproducing bugs. Therefore, these reports reveal the conditions necessary to reproduce elasticity-related bugs, and as a consequence, elasticity tests. The search for elasticity-related bugs has two steps:

1. Select bug reports that contain in their description words that may refer to elasticity, such as: elasticity, scaling, adding, removing, node, sync (for synchronization), and replic (for replication). 2. Gather the bug reports whose description refers to resource changes, excluding bug reports where the resource changes do not reflect an elastic behaviour, such as the ones that restart a Virtual Machine (VM) rather than remove or add one.

The two CBS projects use JIRA3 issue tracking to report their bugs. Therefore, for the Step 1, we use the query in Listing 1 to select bug reports related to elasticity. In the query, we change $PROJECT by the project name that corresponds to the CBS, where for MongoDB the project name is SERVER, while for ZooKeeper, it is ZOOKEEPER. We exclude bug reports whose resolution is Cannot Reproduce or Duplicate. The first resolution refers to bugs that developers could not reproduce due to either wrong or insufficient information, while the second resolution refers to duplicate bug reports.

Listing 1. Query Used at Step 1.

p r o j e c t = "$PROJECT" AND i s s u e t y p e = Bug AND r e s o l u t i o n n o t i n ( " Cannot Reproduce " , " D u p l i c a t e " ) AND ( d e s c r i p t i o n ˜" e l a s t i c i t y " OR d e s c r i p t i o n ˜" s c a l i n g " OR d e s c r i p t i o n ˜" adding " OR d e s c r i p t i o n ˜" removing " OR d e s c r i p t i o n ˜" node " OR d e s c r i p t i o n ˜" sync " OR d e s c r i p t i o n ˜" r e p l i c ")

Table 1 lists the number of bugs selected at each searching step. MongoDB has 25,780 bugs reported on its bug tracking system, where we find 316 in the first step, and 43 in the second step. ZooKeeper has 2677 bugs reported, where we find 188 bugs in the first step, and 9 in the second step.

The selected bugs reveal three main challenges in reproducing elasticityrelated bug, which we consider as elasticity tests reproduction challenges: elasticity control, selective elasticity, and event scheduling. These challenges are functional since the tests cannot be reproduced and the bugs corrected without solving them. As usual non-functional challenge of the speediness is a concern. It is a requirement to be able to run the numerous tests of such systems. Moreover, since cloud computing's billing model is pay-as-you-go, speediness is a cost concern.

-Elasticity Control is the ability to reproduce a specific elastic behaviour. All the selected Elasticity-related bugs occur after a specific sequence of resource allocations and deallocations. Therefore, the challenge is to repeat the CBS elastic behaviour by managing sequences of resource allocations and deallocations. -Event Scheduling is the ability to synchronize events to elasticity states. An event is any interaction with or stimulus to CBS, such as forcing a data increment or to simulate infrastructure failures. The challenge is to identify elasticity states at CBS runtime, and to switch among events according to the elasticity state they are associated. -Selective Elasticity is the ability to remove a specific CBS component. The challenge is to identify and to deallocate the resource that hosts the CBS component that must be removed. -Speediness is the ability of reproducing elasticity tests faster than relying on native cloud computing elasticity controllers. The challenge is to repeat the CBS elastic behaviour anticipating the resource changes.

Table 2 shows the quantity of challenges faced by each CBS bug reproduction. As previously mentioned, all the selected bugs face the elasticity control, where 13 MongoDB (30%) and 3 ZooKeeper (33%) do not face the other challenges for their reproductions. Out of MongoDB bugs, 30 bugs (70%) also face challenges rather than elasticity control, within which 6 (14%) bugs face all the challenges. Out of ZooKeeper bugs, 6 bugs (66%) face further challenges, and 5 (55%) of them face all the challenges. The ECM simulates the behaviour of the cloud provider elasticity controller, allocating and deallocating determined resources, according to testing needs. It also asks the WG to generate the workload accordingly. The role of the ES is to schedule and execute a sequence of events in parallel with the other components. Finally, the CM monitors the cloud system, gathering information that helps orchestrating the behaviour of the three other components, ensuring the sequence of elasticity states, and their synchronization with the events.

Table 3 summarizes the challenges that each component meets, as we detail in this section.

Elasticity Controller Mock.

The ECM is designed to reproduce the elastic behavior. By default, ECM requires as input a sequence of elasticity changes, denoted by E = {ec 1 , ec 2 , ..., ec n }, where each ec is a pair that corresponds to an elasticity change. Elasticity change pairs are composed of a required elasticity state (s i ) and a workload (W i ), ec i = s i , W i where 1 ≤ i ≤ n. A workload is characterized by an intensity (i.e., amount of operations per second), and a workload type (i.e., set of transactions sent to the cloud system). ECM reads elasticity change pairs sequentially. For each pair, ECM requests resource changes to meet elasticity state s i and requests the Workload Generator to apply the workload W i . Indeed, we have to send the corresponding workload to prevent cloud infrastructure to provoke unexpected resource variations. In particular, it could deallocate a resource that ECM just allocated, because the workload has remained low and under the scale-in threshold.

Rather than waiting for the cloud computing infrastructures for elasticity changes, the ECM directly requests to change the resource allocation (elasticity control ). Based on both, required elasticity state and workload (elasticity change pair), ECM anticipates the resource changes. To be sure CBS enters the expected elasticity state, ECM queries the CM, which periodically monitors the cloud infrastructure.

The ECM may also lead to a precise resource deallocation (selective elasticity). Typically, elasticity changes are transparent to the tester, managed by the cloud provider. To set up the selective elasticity, ECM requires a secondary input, i.e., Selective Elasticity Requests (SER). SER is denoted by SER = {(ec 1 , ser 1 ), ..., (ec n , ser n )}, where ec i ∈ E, and ser i refers to a selective elasticity request. A selective elasticity request is a reference to an algorithm (freely written by tester) that gets a resource's ID. When ec i is performed by ECM, the algorithm referred by ser i is executed, and the resource with the returned ID is deallocated by ECM.

ECM helps in meeting all of elasticity testing challenges. As earlier explained in this section, it deterministically requests resource variations (elasticity control and selective elasticity), and helps in ensuring the event scheduling providing information of the current elasticity state to the Event Scheduler. As earlier explained in this section, the ECM deterministically requests resource variations (elasticity control and selective elasticity). In addition, the ECM helps in ensuring the event scheduling by providing information of the current elasticity state to the Event Scheduler, and in meeting the speediness by anticipating resource changes.

Workload Generator. The Workload Generator is responsible for generating the workload (W ). We base it on our previous work [START_REF] Albonico | Controlling the elasticity of web applications on Cloud Computing[END_REF], which takes into account a threshold-based elasticity (see Fig. 1), where resource change demand occurs when a threshold is breached for a while (reaction time). Therefore, a workload should result in either threshold breached (for scaling states) or not breached (for ready state), during the necessary time. To ensure this, the Workload Generator keeps the workload constant, either breaching a threshold or not, until a new request arrives.

Considering a scale-out threshold set at 60% of CPU usage, the workload should result in a CPU usage higher than 60% to request a scale-out. In that case, if 1 operation A hypothetically uses 1% of CPU, it would be necessary at least 61 operations A to request the scale-out. On the other hand, less than 61 operations would not breach the scale-out threshold, keeping the resource steady.

The Workload Generator contributes with the Elasticity Controller Mock to meet the elasticity control challenge.

Event Scheduler. The ES input is a map associating sets of events to elasticity changes (ec i ), i.e., the set of events that should be sent to the cloud system when a given elasticity change is managed by the ECM. Table 4 abstracts an input where four events are associated to two elasticity changes. Periodically, the ES polls the ECM for the current elasticity change, executing the events associated to it. For instance, when the ECM manages the elasticity change ec 1 , it executes the events e 1 , e 2 , and e 3 . Events have execution orders, which define priorities among events associated to the same state: event e 1 is executed before events e 2 and e 3 . Events with the same execution order are executed in parallel (e.g., e 2 and e 3 ). Events are also associated to a wait time, used to delay the beginning of an event. In Table 4, event e 2 has a wait time of 10 s (starting 10 s after e 3 , but nonetheless executed in parallel). This delay may be useful, for instance, to add a server to the server list a few seconds after the ready state begins, waiting for data synchronization to be finished. The ES meets the event scheduling challenge.

Cloud Monitor. The CM helps ECM to ensure elasticity control and selective elasticity. It periodically requests current elasticity state and stores it in order to respond to the ECM queries, necessary for elasticity control. It also executes the selective elasticity algorithm of SER, responding to ECM with the ID of the found resources.

Prototype Implementation

Each component of the testing approach architecture is implemented in Java and communicate with each other through Java RMI. Currently, we only support Amazon EC2 interactions, though one could adapt our prototype to interact with other cloud providers.

Elasticity Controller Mock. The elasticity changes are described in a property file. The entries are set as key, value pairs, as presented in Listing 2. The key corresponds to the elasticity change name, while the value corresponds to the elasticity change pair. The first part of the value is the elasticity state, and the second part is the workload, divided into intensity type.

Listing 2. Example of Elasticity Controller Mock Input File (Elasticity Changes).

ec1=ready , ( 1 0 0 0 , w r i t e ) ec2=s c a l i n g -out , ( 2 0 0 0 , read / w r i t e ) . . . ec4=s c a l i n g -in , ( 1 5 0 0 , read )

As previously explained, for each entry, the ECM sends the workload parameters to the Workload Generator and deterministically requests the specified resource change. Resource changes are requested through the cloud provider API, which enables resource allocation and deallocation, general infrastructure settings, and monitoring tasks. Before performing an elasticity change, the ECM asks the CM whether the previous elasticity state was reached. The CM uses the Selenium4 automated browser to gather pertinent information from cloud provider's dashboard Web page.

We use Java annotations to set up selective elasticity requests (SER), as illustrated in Listing 3. A Java method implements the code that identifies a specific resource and returns its identifier as a String type. This method is annotated with metadata that specifies its name and associated elasticity change.

Listing 3. Selective Elasticity Input File.

@ S e l e c t i o n {name=" s e r 1 " , e l a s t i c i t y c h a n g e=" ec4 "} public S t r i n g s e l e c t 1 ( ) { . .

. // code t o f i n d a r e s o u r c e ID return r e s o u r c e I D ; }

Workload Generator. The WG generates the workload according to the parameters received from the ECM (i.e., workload type and intensity), whereas the workload is cyclically generated until new parameters arrive. It uses existing benchmark tools, setting the workload parameters in the command line.

For instance, YCSB benchmark tool allows three parameters related to the workload: the preset workload profile, the number of operations, and the number of threads. The preset workload profile refers to the workload type, while the multiplication of the two last parameters results in the workload intensity.

Event Scheduler. Event schedules is set in a Java file, where each event is an annotated method, such as the example illustrated in Listing Java methods are annotated with the event identifier, the related elasticity change, the order, and the waiting time. EC periodically polls the ECM to obtain the current elasticity change. Then, it uses Java Reflection to execute the Java methods related to it. @Event{ i d=" e1 " , e l a s t i c i t y c h a n g e=" ec1 " , o r d e r="1" , wait="0"} public void e v e n t 1 ( ) { . . . }

Prototype Execution

Figure 5 illustrates the prototype execution sequence. This execution starts by the CM component, which interacts with the cloud infrastructure (Cloud) to get information that identifies the current elasticity state. Then, the prototype executes the ec ⊂ EC in parallel to the elasticity states identification. For each ec ⊂ EC, the ECM sends a message to WG, which generates the workload W i until the ECM sends a message to stop this process. The ECM sends this message when the CM identifies that the current elasticity state has ended. During the workload generation, if es i is different from ready, the ECM changes the resource. Otherwise, it only waits for a given time-frame before moving to the next ec.

When a new elasticity state begins, the ECM sends a message to the EVs, which leads the execution of all the events related to this state. The prototype repeats this process until the last ec ends.

Experiments

In this section, we present five experiments. The first two experiments aim at demonstrating the test execution time reduction when using the Elasticity Controller Mock (ECM). The other three experiments aim at controlling the test reproduction of three existing elasticity-related bugs. We conduct all the experiments in the environment described in the next section.

Experimental Environment

CBS Case Studies.

In the experiments, we use two CBS case studies, MongoDB 5 and Apache ZooKeeper6 (or simply ZooKeeper). MongoDB is a NoSQL document database. It has three different components: configuration server, MongoS, and MongoD. The configuration server stores meta-data and configuration settings. The MongoS instance is a query router, which ensures load balance, while MongoD instances store and process data.

ZooKeeper is a coordination service for distributed systems. ZooKeeper coordination is intended to be replicated over a set of nodes, called as an ensemble. Requests from ZooKeeper clients are forwarded to a single node, the leader (which is elected using a distributed algorithm). The leader works as a proxy, distributing the request among other nodes called as followers. The followers keep a local copy of the configuration data to respond to requests.

To generate the workload in the experiments with MongoDB, we use the Yahoo Cloud Serving Benchmark (YCSB) [START_REF] Cooper | Benchmarking Cloud serving systems with YCSB[END_REF], while in the experiments with ZooKeeper, we use an open-source benchmark tool [START_REF] Hunt | Zookeeper: wait-free coordination for internet-scale systems[END_REF].

Cloud Computing Infrastructure.

All the experiments are conducted on the commercial cloud provider Amazon Elastic Cloud Compute (EC2), where we set scale-out and scale-in thresholds as 60% and 30% of CPU usage, respectively. Since the threshold values are not critical for the experiment goals, we set them in an arbitrary manner. We choose a scale-out threshold value as 60% of CPU since it should not result in CBS stress. This threshold value also makes it possible to reduce the execution cost since the workload generation can be executed on a single medium machine (m3.medium7 , with a 2.6 GHz vCPU, 3.75 MB of memory, and 4 GB of disk). We set the scale-in threshold value as half of the scale-out threshold value.

In the experiment with MongoDB, the MongoS instance is deployed on a large machine (m3.large, with 2 vCPUs of 2.6 GHz, 7.5 MB of memory, and 32 GB of disk), while the other instances are deployed on medium machines. In the experiments with ZooKeeper, every node is deployed on a medium machine.

Speediness Experiment

In this second set of experiments, we verify whether the Elasticity Controller Mock (ECM) reduces test execution time. In the experiment we lead two CBS case studies, MongoDB and ZooKeeper, through an elasticity states sequence that covers all the possible elasticity state transitions. This is the elasticity states sequence: ready, scaling-out, ready, scaling-in, and ready. This leading is done in two ways, by using the Elasticity Controller Mock, and by using the Amazon EC2 elasticity controller. The workload pattern used in this experiment is only read operations, which keeps the data size unchanged along the experiment execution.

Speediness Considering ZooKeeper.

For the ZooKeeper, we consider the following elasticity changes sequence: E = ry sor, 5800, r , so, 5800, r , ry sir, 5000, r , si, 5000, r , ry, 5000, r

Aiming at accelerating the elasticity changes sequence execution, the first two ready states correspond to ry sor and ry sir sub-states (see Fig. 2), according to the next scaling state in the sequence. Thus, as soon as the CBS enters a ready state, there is a threshold breaching that triggers the next scaling state. The last ready state corresponds to a ry s sub-state, where none of thresholds is breached. When executing the sequence by using the native Amazon EC2 elasticity controller, we set the scale-out and scale-in reaction times (see Fig. 1) as the minimum allowed, i.e., 60 s. In the ECM, we set this as 30 s, half of the minimum allowed by the Amazon EC2 elasticity controller. In both cases, the last ready state lasts 30 s.

Figures 6(a) and (b) present ZooKeeper performance results when using Amazon EC2 and the ECM. The execution by using the ECM lasts ≈250 s, while with Amazon EC2 the execution lasts ≈310 s. This difference of (2 × 30) s is due to our shortest reaction time after the threshold breaching. Both executions show a similar performance variation (doted line), which corresponds to the applied workload (dashed line): it starts by ≈5800 ops and keeps at this level until the end of the scaling-out state, goes down to ≈5000 ops from the second ready state until the end of the execution. When using the ECM, the average performance varies less than 1% compared the execution by using the Amazon EC2 elasticity controller. This value is insignificant, and can be associated to external factors, such as network latencies.

Speediness Considering MongoDB.

For the MongoDB, we consider the following elasticity changes sequence: E = ry sor, 1500, r , so, 1500, r , ry sir, 1000, r , si, 1000, r , ry, 1000, r

The test sequence execution time is ≈330 s when using Amazon EC2 and ≈270 s when using the ECM. The difference corresponds to the (2 × 30) s shortest reaction time after the threshold breaching. We measured a performance difference of less than 2% comparing the use of our approach with the default Amazon EC2.

Test Reproduction Experiment

In this section, we describe the use of our approach to reproduce the three bugs, and compare the results to reproduction attempts without our approach. We do not explain in details the setup of reproductions without the proposed approach, though in such executions the elasticity control is managed. Indeed, reproducing elasticity is a native feature of cloud computing infrastructures, and we just drive CBS through required elastic behavior using our approach [START_REF] Albonico | Controlling the elasticity of web applications on Cloud Computing[END_REF].

Selected Bugs. Table 5 summarizes the challenges in the reproduction of the three selected bugs. The selected bugs cover all the possible combinations of challenges, constrained by the mandatory presence of elasticity control, and the need of at least one of the other challenges. We do not attempt to reproduce any bug that only faces elasticity control challenge since one could reproduce the required elastic behavior using our elastic control approach [START_REF] Albonico | Controlling the elasticity of web applications on Cloud Computing[END_REF].

MongoDB Bug 7974. This bug affects the MongoDB versions 2.2.0 and 2.2.2, when a secondary component of a MongoDB replica set8 is deallocated. Indeed, in a MongoDB replica set, one of the components is elected as primary member, which works as a coordinator, while the others remain as secondary members.

To reproduce this bug, we must follow a specific elastic behavior: initialization of a replica set with three members, deallocation of a secondary member, and allocation of a new secondary member. Therefore, the second step of the elastic behavior requires the deallocation of a precise resource, one of the secondary members. The bug reproduction also requires two events synchronized to elasticity changes. Right after the secondary member deallocation, we must create a unique index, and after the last step of the elastic behavior, we must add a document in the replica set.

In conclusion, the reproduction of this bug faces all the challenges that we consider in this paper: elasticity control, selective elasticity, and event scheduling.

ZooKeeper Bug . This bug is related to ZooKeeper version 3.4.5 and concerns the leader election. According to the bug report 9 , in an ensemble with three nodes, when the node running the leader shuts down, a new leader election starts and never ends.

The reproduction of this bug must follow a precise sequence: initialization (allocation of the first node), followed by the allocation of two nodes and the deallocation of the leader node. The main difficulty of reproducing this bug is that when ZooKeeper is deployed on three nodes, the deallocated node is not necessarily the leader. The problem is that during a scale-in, Amazon EC2 removes either the newest or the oldest node and cannot reproduce the bug straightforwardly. In conclusion, the reproduction of this bug faces two challenges: elasticity control and selective elasticity.

ZooKeeper Bug 2172. This bug is related to ZooKeeper version 3.5.0. According to the bug report 10 , when a third node is added to a ZooKeeper ensemble, the system enters an unstable state and cannot recover.

After a thorough analysis of the available logs, we understand that the bug occurs when a leader election starts right after the allocation of a third node. More precisely, when a new node joins the ensemble, there is a data synchronization with the leader. Then, if the data is not already synchronized at the moment of the leader election, the bug occurs.

The reproduction of this bug requires a simple elastic behaviour: the allocation of one initial node, and then the allocation of two more nodes. However, this sequence alone does not reproduce the bug: we need to be sure that the leader election starts before the end of the data synchronization process. We can force this by increasing the data amount through an event synchronized with the completion of the third node allocation.

The reproduction of this bug faces two challenges: elasticity control and event scheduling.

Bug Reproductions

MongoDB-7974 Bug Reproduction. This bug reproduction has been already described in our previous paper [START_REF] Albonico | Making Cloud-based systems elasticity testing reproducible[END_REF]. To reproduce MongoDB bug 7974 using our approach, we first manually create the MongoDB replica set, composed of three nodes. Then, we set up the following sequence of elasticity changes, which should drive MongoDB through the required elastic behavior: E = ry 1 , 4500, r , si 1 , 1500, r , ry 2 , 3000, r , so 1 , 4500, r , ry 3 , 4500, r Since we must deallocate a secondary member of MongoDB replica set at elasticity change ec 2 , it is associated to a selective elasticity request (SER). The SER queries MongoDB replica set's members, using MongoDB shell method db.isMaster, until finding a member that is secondary.

In parallel to the elasticity changes, we set up two events, e1 and e2, which respectively create a unique index, and insert a new document in the replica set. The e1 is associated to elasticity change ec 3 , a ready state that follows the scaling-in state where a secondary member is deallocated. The e2 is associated to elasticity change ec 5 , the last ready state. Both events are scheduled without waiting time (Table 6). We repeat the bug reproduction for three times. After each execution, we look for the expression "duplicate key error index" in the log files. If the expression is found, we consider the bug is reproduced.

Table 7 shows the result of all the three executions, either using our approach or not. All the attempts using our approach reproduce the bug, while none of the attempts without our approach do it. Table 7. MongoDB-7974 bug reproduction results [START_REF] Albonico | Making Cloud-based systems elasticity testing reproducible[END_REF].

Reproduction

Reproduced Not Reproduced With our approach 3 0

Without our approach 0 3

For the executions without our approach, we force MongoDB to elect the intermediate node (in the order of allocation) as primary member 11 , what can occur in a real situation. In this scenario, independent of scale-in settings, cloud computing elasticity controllers always deallocate a secondary member, since Amazon EC2 only allows to deallocated the oldest or newest nodes. This is because we want to see the effect of event synchronization. Therefore, we assure the elastic behaviour is the required to reproduce the bug. Even though we force the reproduction of the required elastic behaviour, this bug still needs the event executions, which must be correctly synchronized. This is the reason the bug is not reproduced without our approach.

ZooKeeper-2164 Bug Reproduction. To reproduce this bug, we translate and complete the scenario (Sect. 4.3) into the following sequence of elasticity changes: E = ry 1 , 3000, r , so 1 , 5000, r , ry 2 5000, r , so 2 , 10 000, r , ry 3 , 10 000, r , si 1 , 5000, r

The sequence of elasticity changes first initializes the cloud system with one node, then it requests two scale-out. Once the three nodes are running, the sequence requests a scale-in.

To discover the leader node, we write a SER that is associated to the last elasticity change e6 ( si 1 , 5000, r ). The SER method connects to every Zookeeper node and executes ZooKeeper command named stat. This command describes, among other information, the node execution mode: leader or follower.

The sequence of elasticity states, including a selective elasticity, is supposed to reproduce the bug. To verify whether the failure occurs, we write a test oracle, which is implemented in JUnit [START_REF] Gamma | Junit: a cook's tour[END_REF]. It is run after the last elasticity change ( si 1 , 5000, r ), and repetitively searches for a leader until it is found or the timeout is reached. In the first case, the verdict is pass, what means the bug is reproduced and observed. Otherwise, the verdict is fail.

As well as in the first experiment, we use two different setups to execute this experiment: with our approach, and without our approach. We repeat the experiment three times for each setup.

Since the selective elasticity is one of the challenges for this bug reproduction, when executing without our approach, we try to reproduce a real scenario, where every node can be elected as a leader. Therefore, we force ZooKeeper to elect a different node as the leader at each execution: the newest, the oldest, then the intermediate node. Then, we use Amazon EC2 to deallocate a node. Its policy is to deallocate either the newest or the oldest node, it is not possible to deallocate the intermediate node. Hence, during two executions we can ask Amazon EC2 to deallocate the leader, but not during the third one.

Table 8 summarizes the results. When using our approach, all the three test executions pass, demonstrating the ability of our testing approach to deterministically reproduce the bug. In contrast, only two executions without our approach pass, the ones where the leader is the newest or the oldest node. Therefore, without our approach the bug was not reproduced deterministically. ZooKeeper-2172 Bug Reproduction. We create the following sequence of elasticity changes to reproduce this bug (Sect. 4.3): E = ry 1 , 3000, r , so 1 , 5000, r , ry 2 , 5000, r , so 2 , 10 000, r , ry 3 , 10 000, r

According to the bug log files, the bug occurs the leader election starts before the end of the data synchronization between the third node and the previous leader. Thus, the test sequence must ensure that the data synchronization process is longer than the delay needed to start a new election, which is about 10 s according to the log files. Forcing the data synchronization to take long enough, we create an event schedule to associate an event e1 to the state so 2 , as described in Table 9. The e1 requests a data increasing to an amount that should take longer than 10 s to synchronize. Since this experiment uses Amazon m3.large machines, which have a bandwidth of 62.5 MB/s, the data amount must be ≈625 MB of data. We use the test oracle as for the bug 2164, which is associated to the last ready elasticity state which is not supposed to be able to elect a leader before the timeout. Table 10 summarizes the experiment execution. In all three executions, the test verdict is pass, meaning that the testing approach reproduces the bug successfully. Since Amazon EC2 cannot manage natively the scheduling of events synchronized with elasticity states, it cannot reproduce the bug deterministically.

Reproduction

Pass verdicts Fail verdicts With our approach 3 0

Without our approach 0

Related Work

Several research efforts are related to our approach in terms of elasticity control, selective elasticity, and events scheduling. The work of Gambi et al. [START_REF] Gambi | Testing elastic computing systems[END_REF][START_REF] Gambi | IEEE/ACM International Conference on Automated Software Engineering (ASE)[END_REF] addresses elasticity testing. The authors predict elasticity state transition based on workload variations and test whether cloud infrastructures react accordingly. However, they do not focus on controlling elasticity and cannot drive cloud application throughout different elasticity states. Banzai et al. [START_REF] Banzai | D-Cloud: design of a software testing environment for reliable distributed systems using cloud computing technology[END_REF] propose D-Cloud, a virtual machine environment specialized in fault injection. Like our approach, D-Cloud is able to control the test environment and allows testers to specify test scenarios. Test scenarios are specified in terms of fault injection and not on elasticity and events, as in our approach.

Yin et al. [START_REF] Yin | CTPV: a Cloud testing platform based on virtualization[END_REF] propose CTPV, a Cloud Testing Platform Based on Virtualization. The core of CTPV is the private virtualization resource pool. The resource pool mimics cloud infrastructures environments, which in part is similar to our elasticity controller. CTPV differs from our approach in two points: (i) it does not use real cloud infrastructures and (ii) it uses an elasticity controller that does not anticipate resource demand reaction.

Vasar et al. [START_REF] Vasar | Framework for monitoring and testing web application scalability on the Cloud[END_REF] propose a framework to monitor and test cloud computing web applications. Their framework replaces the cloud elasticity controller, predicting the resource demand based on past workload. Contrary to our approach, they do not allow to control a specific sequence of elasticity states or events.

Li et al. [START_REF] Li | ReproLite: a lightweight tool to quickly reproduce hard system bugs[END_REF] propose Reprolite, a tool that reproduces cloud system bugs quickly. Similarly to our approach, Reprolite allows the execution of parallel events on the cloud system and on the environment, but it does not focus on elasticity, one of our main contributions.

Conclusion

In this paper, we proposed an approach to reproduce elasticity tests in a deterministic manner. This approach meets four challenges: elasticity control, selective elasticity, event scheduling, and execution time reduction.

We used this approach to reduce the execution time when driving two CBSs, ZooKeeper and MongoDB, throughout an elasticity state sequence that covers all the elasticity state transitions. We compare these executions to the ones without the proposed approach by measuring the CBS performance throughout the executions. The performance in both executions does not present a significant variation, which indicates that the approach reduces the execution time without compromising the CBS behaviour.

We also used the approach to control the reproduction of three bugs of those two CBSs. Indeed, the bugs cannot be deterministically reproduced with stateof-the-art approaches. This also indicates that execution time reduction does not hamper such bug reproductions.

As testing is not only about reproducing existing bugs, but also diagnosing them. An evolution for the proposed approach is to generate different test scenarios combining elasticity state transitions, workload variations, selective elasticity, and event scheduling. Another perspective could be to further investigate the impacts of speediness. In fact, in this paper, we proposed a way to accelerate elasticity test executions, but it lacks a deeper investigation on how fast we can reproduce elasticity tests without compromising them.

Fig. 1 .

 1 Fig.1. Typical elastic behavior[START_REF] Albonico | Making Cloud-based systems elasticity testing reproducible[END_REF].

Fig. 2 .

 2 Fig. 2. Elasticity states[START_REF] Albonico | Making Cloud-based systems elasticity testing reproducible[END_REF].

Fig. 4 .

 4 Fig. 4. Overall architecture [6].

Listing 4 .

 4 Example of Event Scheduler Input File.

Fig. 5 .

 5 Fig. 5. Prototype execution sequence.

Fig. 6 .

 6 Fig. 6. ZooKeeper performance.

Table 1 .

 1 Selected bugs in the systematic search.Total of bugs Bugs at step 1 Bugs at step 2

	MongoDB 25.780	316	43
	ZooKeeper 2.677	188	9

Table 2 .

 2 Challenges in bug reproduction.Figure 4 depicts the overall architecture of our approach. The architecture has four main components, which aim at meeting the elasticity test reproduction challenges: Elasticity Controller Mock (ECM), Workload Generator (WG), Event Scheduler (ES), and Cloud Monitor (CM).

	Bugs	Elasticity	Selective	Event	All Only
	considered	control	elasticity	scheduling		elasticity
						control
	MongoDB 43	43	19	17	6	13
	ZooKeeper 9	9	4	3	5	3

Table 3 .

 3 Challenges met by the architecture components.

	Component Elasticity control Selective elasticity Event scheduling Speediness
	ECM	Yes	Yes

Table 4 .

 4 Events schedule.

	Elasticity change Event ID Execution order Wait time
	ec1	e1	1	0 s
		e2	2	10 s
		e3	2	0 s
	ec2	e2	1	0 s
		e4	2	0 s

Table 5 .

 5 Challenges in reproducing the three selected bugs.

	Bug	Feature
		Elasticity control Selective elasticity Event scheduling
	M ongoDB -7974 Yes	Yes	Yes
	ZooKeeper -2164 Yes	Yes	No
	ZooKeeper -2172 Yes	No	Yes

Table 6 .

 6 MongoDB-7974 event schedule[START_REF] Albonico | Making Cloud-based systems elasticity testing reproducible[END_REF].

	Elasticity change Event ID Execution sequence Wait time
	ec3	e1	1	0 s
	ec5	e2	1	0 s

Table 8 .

 8 ZooKeeper-2164 bug reproduction results.

	Reproduction	Pass verdicts Fail verdicts
	With our approach	3	0
	Without our approach 2	1

Table 9 .

 9 ZooKeeper-2172 event schedule.

	Elasticity change Event ID Execution sequence Wait time
	ec4	e1	1	0 s

Table 10 .

 10 ZooKeeper-2172 bug reproduction results.

https://www.mongodb.com/.

https://zookeeper.apache.org/.

https://jira.atlassian.com.

http://www.seleniumhq.org/.

https://www.mongodb.org/.

https://zookeeper.apache.org/.

https://aws.amazon.com/fr/ec2/itype/.

https://docs.mongodb.com/replica-set.

https://issues.apache.org/jira/ZK2164.

https://issues.apache.org/jira/ZK2172.


Marianne Jover

Christina Schmitz

Emmanuelle Bosdure

Brigitte Chabrol

Christine Assaiante
email: assaiant@dpm.cnrs-mrs.fr

Anticipatory postural adjustments in a bimanual load-lifting task in children with Duchenne Muscular Dystrophy

Keywords: Anticipatory postural adjustment, bimanual coordination, EMG, Duchenne muscular dystrophy, children

Anticipatory postural adjustments in a bimanual load-lifting task in children with Duchenne muscular dystrophy

Introduction

Anticipatory postural adjustments (APA) consist in muscular activities which occur before the onset of a voluntary movement. They usually occur in association with voluntary movements, but they can also be observed when imposed disturbance is recurrent. Their functions are to prevent a forthcoming disturbance of posture and to assist the movement during its execution [START_REF] Massion | Postural control system[END_REF]. The acquisition of APA relies on the transformation of a feedback postural correction into a feedforward control associated with the voluntary movement that causes the postural disturbance [START_REF] Massion | Movement, posture and equilibrium: Interaction and coordination[END_REF]. Thus, APA involve a nervous system that can efficiently monitor, integrate and store sensorimotor information into a representation used to parameterize and coordinate a movement and its associated APA. Yet, APA rely on an efficient system, from central to peripheral nervous and muscular structures [START_REF] Massion | Acquisition of anticipatory postural adjustments in a bimanual load-lifting task: normal and pathological aspects[END_REF].

During childhood, previous studies suggest that the feedforward control of posture does not appear consistently until 4-5 years of age [2; 12-14;17;24;28]. Schmitz and collaborators [START_REF] Schmitz | Building anticipatory postural adjustment during childhood: a kinematic and electromyographic analysis of unloading in children from 4 to 8 years of age[END_REF] studied the development of APA in a bimanual load-lifting task between 4 and 8 years.

They showed that the postural stabilization enabled by the use of APA gradually develops during childhood, and is not yet fully efficient at 8 years of age as seen by the lower stability performance as compared to adults still at this age. The developmental sequence in the acquisition of APA consists in first the selection of an efficient electromyographic (EMG) pattern underlying the forearm stabilization and second the mastering of the timing adjustment of the muscular activities.

Duchenne Muscular Dystrophy (DMD) is due to a genetic lack of dystrophin which induces an increasing muscular weakness [3;15;32]. DMD is characterized by a decrease in the number of muscle fibres which are progressively replaced by fibro-adipose tissue. The progression of these changes grows from the lower to the upper segments and in a proximal to distal direction [1;7]. Despite the existence of studies exploring the muscle and joint elastic properties [4;5], the consequences of the muscular weakness on postural and motor efficiency have rarely been explored in DMD patients [START_REF] Armand | A comparison of gait in spinal muscular atrophy, type II and Duchenne muscular dystrophy[END_REF], except for clinical evaluation [10;21]. Furthermore, since DMD induces an increasing muscle weakness at a time when the muscular patterns underlying the APA are normally selected, consolidated, and stabilized, the changes in the muscle properties might have an influence on the development of APA in DMD.

This study mainly focused on the expression of a feedforward control in children with DMD as compared to typically developing (TD) children during a bimanual load-lifting task.

Our hypothesis was that the developmental processes of the feed-forward mode of control would not be impaired but that the muscular weakness would hinder the function of APA, that is, the stabilization.

Materials and Methods

Eight right-handed boys with DMD with age ranged from 3 years 11 months to 10 years 11 months participated in this experiment (mean ± SD, 7,6 ± 2,4). All of them were contacted in the neurology care unit of Marseille's main hospital and were selected from those who had a progressive DMD. A clinical evaluation (ambulatory status, orthopedic evaluation, global and manual motor functions…) was conducted prior to their participation. Children participated only if their manual abilities were considered to be normal by a trained paediatrician. All children had normal growth and normal compulsory schooling, supposing no mental retardation. Eight right-handed age matched boys with age ranged from 3 years 9 months to 11 years 2 months and with a typical development constituted the control group (mean ± SD, 7,6 ± 2,4). All control children were at school and presented, at each age, a normal range of motor capacities for their upper extremities in their every day life. Parents, and also children when they were able to, gave their informed consent prior to the experiment, which obtained the approval of the local ethics committee (CCPPRB Marseille 1).

The experimental set up was the same as the one described in previous studies [START_REF] Schmitz | Developmental sequence in the acquisition of anticipation during a new co-ordination in a bimanual load-lifting task in children[END_REF][START_REF] Schmitz | Development of anticipatory postural adjustments in a bimanual load-lifting task in children[END_REF][START_REF] Schmitz | Building anticipatory postural adjustment during childhood: a kinematic and electromyographic analysis of unloading in children from 4 to 8 years of age[END_REF][START_REF] Schmitz | Motor control and children with autism: deficit of anticipatory function?[END_REF].

The subjects were seated on a hard-back chair. Their left forearm, placed in a support, was horizontal and semi-prone during the entire session. A bracelet, placed near the wrist, was equipped with a strain gauge and supported a platform on which a load could be placed either below or onto the forearm. The angular displacement of the forearm was measured by a potentiometer situated along the elbow joint axis. During the imposed unloading situation, the load suspended below the forearm was released by the experimenter switching off the electromagnet circuit. During the voluntary unloading situation, the subjects lifted with their right hand the load from a platform resting on the left forearm. As with previous studies in children [27;29] the weight of the load was chosen to maintain a constant ratio between the body weight and the load weight in each age group (0,7% of the body weight). The mean weight of TD and DMD children being similar for the ages studied [START_REF] Griffiths | A new chart for weight control in Duchenne muscular dystrophy[END_REF], in the two groups the 4 to 6 year-old children used a 300 g load, 7 to 8 year-old children a 350 g load and the 9 to 11 year-old children a 400 g load. The general procedure was as follows: first a session of 10 imposed unloadings, then a session of 15 voluntary unloadings. Five training trials were offered so that the experimenter was sure that the task was correctly performed. There was a 10 min rest period between each situation. Force and angular elbow displacement signals were recorded, digitised and stored on a computer disk (sampling rate: 500 Hz) along with EMG signals for analysis. Each trial was viewed offline on a monitor screen. The onset of unloading (t0) was given by the first visible deflection of the force signal given by the gauge (see Fig. 1). The upward movement of the postural forearm was quantified by means of the maximal angular amplitude (MA) and the maximal angular velocity (MV), calculated starting from the derivative of the postural forearm displacement. Their latencies were also measured.

During the session of voluntary unloading, MA and MV were expressed for each child in percentages of the mean value obtained in the imposed unloading. Bipolar surface electrodes (integration surfaces: 2.5 mm 2 ) were placed over the surface of two muscles implied in the forearm postural stabilisation: one flexor (Biceps brachii) and one extensor (Triceps brachii).

EMG were amplified, filtered (10 Hz -200 Hz band pass), rectified and integrated with a 10 ms time constant. During the imposed unloading situation, latency and duration of the unloading reflex were measured on the flexor by means of averaged trials for each subject.

During voluntary unloading, two main EMG patterns were previously identified in children [START_REF] Schmitz | Building anticipatory postural adjustment during childhood: a kinematic and electromyographic analysis of unloading in children from 4 to 8 years of age[END_REF]: a simultaneous increase of activity on the flexor and extensor muscles (co-contraction), and a reduction of activity on the flexor while the extensor stayed silent or shown an increase of activity (flexor inhibition). We calculated for each subject the rate of co-contraction pattern and the rate of inhibition pattern. However, in this study, we chose to focus on the flexor inhibition pattern. Thus, in each trial where a decreasing activity was defined on the flexor, the latency and the duration of the inhibition were determined. The latency was measured as the time-interval between the onset of unloading and the onset of the reduction of activity, and the duration was measured between the onset and the end of the reduction of activity. Non During imposed unloading, the kinematics data show that the sudden change in force was followed by an upward rotation of the postural forearm elbow. No difference was found between the two groups concerning the absolute values and latencies of MA and MV. The EMG activity measured on the postural forearm decreased in the Biceps Brachii after imposed unloading (table 1). The latency and duration of the EMG inhibition were not significantly different between the two groups of children.

INSERT TABLE 1 ABOUT HERE

In TD children, the elbow flexion following the voluntary unloading was reduced as compared to the one obtained during imposed unloading: the median value of MA (figure 2 a) and MV were notably reduced during voluntary unloading as compared to the median value obtained during the imposed unloading (MA : T=0, p<0.05; MV : T=0, p<0.05). This was also the case for children with DMD (MA : T=0, p<0.05; MV : T=0, p<0.05).

INSERT FIGURE 2 ABOUT HERE

Nevertheless, the forearm stabilization was impaired in the group of children with DMD.

During voluntary unloading, the median of the MA expressed in percentages was significantly larger in the group of children with DMD than in the group of TD children (figure 2 b; U=11, p<0.05). The same result was significant for MV expressed in percentage (U=13, p<0.05).

Concerning the MA latency, there was no difference between the two groups (figure 2 c).

However, the MV latency was markedly increased in the group of DMD children. The late appearance of the MV reflects a delayed intervention of the voluntary control aiming at stabilizing the forearm.

The EMG activity measured on the flexor decreased before the voluntary unloading in both groups of children (table 1). The latency and duration of the inhibitions did not differ between TD children and children with DMD during voluntary unloading. Finally, the preferential use of one or the other pattern of muscular activity did not significantly differ between the two groups of children: the inhibition pattern appeared with a higher rate in both group (96.1% in DMD children, and 93.1% in TD children).

Both kinematic and EMG data indicated that during imposed unloading, the reflex was the same in the two groups. Other studies using this paradigm found an integrity of the unloading reflex in Parkinson disease [START_REF] Massion | Acquisition of anticipatory postural adjustments in a bimanual load-lifting task: normal and pathological aspects[END_REF] and in autism [START_REF] Schmitz | Motor control and children with autism: deficit of anticipatory function?[END_REF] but not in a deafferented patient [START_REF] Forget | Anticipatory postural adjustment in the absence of normal peripheral feedback[END_REF]. In the group of children with DMD, the properties of the unloading reflex were not impaired by the progressive muscular dystrophy. Interestingly enough, a study of Lazzaro and colleagues using transcranial magnetic stimulation showed that the nervous conduction is not impaired in DMD children [START_REF] Di Lazzaro | Functional involvement of cerebral cortex in Duchenne muscular dystrophy[END_REF]. Taken together, these results suggest that the peripherical muscular disability characterizing the DMD disease does not impair the proprioceptive afference and the motor efference constituting the unloading reflex.

The decrease of the maximal amplitude of the elbow flexion during voluntary unloading assesses the intervention of a postural control in children with DMD [START_REF] Paulignan | Acquisition of co-ordination between posture and movement in a bimanual task[END_REF]. Furthermore, the latencies of the EMG inhibition measured on the flexor muscle belonged to a temporal window compatible with APA. These results indicate that our group of children with DMD used APA during this bimanual task.

However, despite a significant reduction of the elbow rotation during voluntary unloading, the kinematic data also indicated that the postural stabilization was less efficient in the group of children with DMD as compared to the group of control children. The latency of MV is an important landmark for the intervention of the control which slows down the elbow flexion until the forearm is stabilized [START_REF] Paulignan | Acquisition of co-ordination between posture and movement in a bimanual task[END_REF]. Our results indicate that despite the fact that the nervous commands were sent on time, as assessed by EMG latencies, this control was translated late in terms of changes in the forearm trajectory in the group of children with DMD. As we did not measure the children's muscle strength, one could argue that this difference might arise from the weight of the load, which could be relatively heavier for the children with DMD than for the TD children. However, Schmitz and Assaiante (personal communication) noted in a previous study that the stabilisation enabled by the use of APA does not depend on the load weight (being lighter or heavier, with a 200g difference) in TD children (4-6 and 7-8 years) and in adults. Thus, changes in muscle properties (weakness, increased elastic stiffness or increased joint stiffness) [5;8] might explain the fact that despite their correct use of APA, children with DMD still lack postural stability. Among these properties, the muscle weakness induces a muscular fatigue in children with DMD. Studies exploring the effect of muscle fatigue on motor efficiency showed that fatigue induces changes and small variations in the developed muscle force [16;25;31]. These fluctuations of force are known to impair the motor and postural output [22;26]. We think that the increased muscle fatigue in children with DMD could explain the discrepancy between a preserved temporal organization of the postural command and the poor forearm stabilisation.

Interestingly, as compared to the youngest TD children, the youngest children with DMD showed a marked preference for the inhibition muscular pattern (data not shown) classically used in older children and adults for the forearm stabilization during voluntary unloading [START_REF] Schmitz | Building anticipatory postural adjustment during childhood: a kinematic and electromyographic analysis of unloading in children from 4 to 8 years of age[END_REF]. This pattern is less expensive than a co-contraction in terms of energy and its predominant use in the youngest DMD children could reflect a plasticity of the selection process that enables an adaptation of the motor development to the muscular deficiency.

Further investigation focused on the youngest children with DMD (3-5 years of age) should help us to confirm this hypothesis.

Finally, we think that modifications of the efficiency of APA in the unloading task could bring some insights into the efficiency of other postural responses in DMD: APA used in other tasks involving a coordination between posture and movement (locomotion…) but also postural reactions (to a support displacement for instance…) might be altered as well. The muscular weakness and the changes it induce could yield to a general alteration of the postural function, which plays a crucial role in correcting for the consequences of external disturbances (postural reaction) or enables to anticipate the disturbances generated by a movement (APA), but also accompanies the movement to optimize its efficiency [START_REF] Massion | Postural control system[END_REF]. Thus, besides the alteration of motricity, it might be important to consider the functional aspects of a postural deterioration in DMD to get a more complete view of the neural control regression in DMD.

In conclusion, the building of APA, characterized by the fine tuning of EMG events, is protected from the muscle weakness in children with DMD. However, the muscle fatigue induced by muscle weakness impairs the efficiency of the muscle response to the motor command. Probably the alteration of at least one of the muscle properties in DMD is a restraint to the efficiency of APA with respect to TD children.

  parametric tests were used for inter group (Mann-Withney U-tests) and within subject (Wilcoxon signed-rank tests) comparisons. Comparisons between the rates of EMG patterns in the two groups were made by means of a Chi2 test. Differences with a P value < 0.05 were considered to be statistically significant. INSERT FIGURE 1 ABOUT HERE Examples of force, elbow rotation and EMG traces are shown in Fig. 1 on one trial obtained in a 8 year-old child with DMD during both an imposed and a voluntary unloading trial. The MA reached 16.9° in the imposed situation (left) and 2.1° in the voluntary situation (right), indicating an effective stabilization of the postural forearm in the last situation. During the imposed situation, the biceps brachii showed a decrease of EMG activity with a latency of 50 ms which corresponds to the unloading reflex. During the voluntary situation, a decrease of the biceps brachii activity was observable before the unloading onset (-18 ms).

Figure 1 :

 1 Figure 1: Raw trial recordings of a 8 year-old child with DMD during imposed unloading

Figure 2 :

 2 Figure 2: a) Comparison between the two unloading situations in TD children and in

Table 1 :

 1 Median and quartile values of the latency and the duration of the Biceps brachii inhibitions during the imposed and voluntary unloading situations, in TD children and in children with DMD.

Acknowledgments

The authors are grateful to the children who participated in this study and to their parents. This work was supported by grants from the French National Centre of Scientific Research (CNRS).


L Courthéoux

J Lao

J.-M Nedelec

E Jallot
email: jallot@clermont.in2p3.fr

Controlled Bioactivity in Zn-doped sol-gel derived SiO 2 -CaO bioactive glasses

Keywords: sol-gel glasses, bioactivity, Zn doped glasses, PIXE-RBS, biomaterials

Sol-gel derived glasses based on SiO 2 -CaO were studied with and without Zn as doping element. Investigations of their in vitro bioactivity were performed by soaking the glass powders in biological fluids for time periods up to 4 days. The surface reactions were characterized at the micrometer scale and with a high level of efficiency for both major and trace elements by using Particle Induced X-ray Emission (PIXE) associated to Rutherford Backscattering Spectroscopy (RBS). The evolution of the biological medium composition was followed by ICP-AES analyses. If the bioactivity of binary SiO 2 -CaO glasses is already known, this study shows the improvement of the early step of the bioactive process by using zinc as a doping element. Indeed, zinc improves the specific surface area and then the number of sites for the nucleation of calcium phosphate precipitates. In addition, Zn-doping slows the

Introduction

Since about forty years, bioactive glasses based on silica have been extensively studied for bone repair or replacement. 1,2 Indeed, in contact with living tissues, bioactive materials allow the formation at their surface of a Ca-P rich layer similar to the bone mineral phase and then an effective bonding with the bone. Glass composition and textural properties such as high surface area and porosity are key factors for the bioactive process. In a few words, the bioactive process consists of well known series of physico-chemical reactions between the glass and the biological solution leading to the formation of a hydroxyapatite layer at the surface of the glass. [START_REF] Hench | Introduction to bioceramics[END_REF][START_REF] Saravanapavan | [END_REF] The first step of the bioactive process is a rapid cations exchange between the glass and the solution, followed by silica dissolution and formation of silanols groups at the glass/solution interface. Then polycondensation reactions of surface silanols generate a silica-rich layer which provides favorable sites for the formation of Ca-P layer. The calcium phosphates progressively crystallize, by incorporation of anions from the solution, into a biologically reactive hydroxycarbonate apatite equivalent to the mineral phase of bone. 5,6 It can be noticed that the formation of stable apatite is closely dependent on the textural properties of the materials but also on its composition. 7 That is why the many advantages of sol-gel glasses over melt derived analogues have favored their development as bioactive materials. 8,9,10 In fact, the sol-gel procedure leads to very homogeneous and high specific surface area materials and its versatility allows reaching a large range of composition.

Among bioactive sol-gel materials, very simple compositions, as for example SiO 2 -CaO glasses, have shown interesting bioactive properties. 11,12 Moreover, the study of the Ca-P layer growth process is easier in such binary system, since the phosphate ions are only coming from the solution by comparison with the SiO 2 -CaO-P 2 O 5 ternary system. To improve the bioactivity of such glasses, additives can be easily introduced during the sol-gel synthesis.

The doping elements are generally chosen among human body trace elements and for their biological activity. Several authors have reported the influence of silver to improve the formation of hydroxyapatite 13 or for antibacterial properties. 14,15 Besides silver, other doping elements, like Mg or Sr for example, have been studied to promote the bioactivity of glasses. 16,17,18 Zinc is another essential trace element in human body which has shown a stimulatory effect on bone formation. 19,20 Namely very few paper deals with Zn influence on the bioactive process in sol-gel glasses and there is still a lack of quantitative information regarding the physico-chemical reactions occurring at the interface of such glasses.

The aim of this paper is, thus, to study the influence of Zn as a doping element on the bioactivity of SiO 2 -CaO glasses. For this purpose, Zn doped SiO 2 -CaO bioactive glasses were elaborated using the sol-gel method and tested by immersion in biological fluids for different time periods. Evolution of elemental distributions at the biomaterial/biological fluids interface were highlighted with the Particle Induced X-ray Emission (PIXE) technique associated to Rutherford Backscattering Spectroscopy (RBS). The evolution of the biological fluids composition was followed by ICP-AES (Inductively Coupled Plasma-Atomic Emission Spectroscopy) analyses.

Materials & methods

Preparation of the bioactive glass samples

The bioactive powder containing 75wt% SiO 2 -25wt% CaO was chosen as reference in order to study the influence of doping for different ZnO content: 1 wt% ZnO for Zn1 and 5 wt% ZnO for Zn5. The Zn-doped bioactive glasses based on silica were prepared by a classical sol-gel method as follows. Tetraethylorthosilicate (TEOS; Si(OC 2 H 5 ) 4 ), calcium nitrate (Ca(NO 3 ) 2 , 4H 2 O) and zinc nitrate (Zn(NO 3 ) 2 , 6 H 2 O) were mixed in ethanol in presence of water and hydrochloric acid as catalyst. The sol was then transferred to an oven at 60°C during four hours followed by a drying at 125°C for 24 hours for gelification and aging.

The xerogel was finally grinded to powder and calcined at 700°C for 24 hours.

Characterizations

The specific surface area of the samples was calculated with the BET method during nitrogen adsorption-desorption using a Quantachrome Porosimeter Autosorb-1. Prior to the experiments, the samples were outgassed at 120°C for 12h to remove physically adsorbed molecules such as moisture. The surface structure has also been observed with a ZEISS Supra 55VP scanning electron microscope. Inductively Coupled Plasma-Atomic Emission Spectroscopy (ICP-AES) was used to determine the chemical composition of the bioactive powder and to analyze the biological fluids during interactions with bioactive glasses.

In vitro assays

The interactions between the glasses and a biological medium have been carried out at 37°C for 1h, 6h, 1, 2, 3 and 4 days by immersing about 10 mg of powder in a standard Dulbecco's Modified Eagle Medium (DMEM), which composition is almost equal to human plasma. The specific surface area to DMEM volume ratio was fixed at 500 cm -1 . These in vitro assays were conducted under static conditions: biological fluids were not renewed and therefore contained only limited amount of P and Ca. Namely, this is a good approach for further development and to compare different doping elements and compositions. After interaction, the samples were removed from the fluid, air dried and embedded in resin (AGAR). Before characterization, the glass particles were cut into thin sections of 1 micrometer nominal thickness using a Leica EM UC6 Ultramicrotome, and laid out on 50 mesh copper grids. The grids were then placed on a Mylar film with a middle hole of 3 mm.

The analyses of the biomaterial/biological fluid interface were carried out using nuclear microprobes at the CENBG (Centre d'Études Nucléaires de Bordeaux-Gradignan, France). The device provides a micro-beam line employed for ion beam analytical measurements at the microscopic level. Particle Induced X-ray Emission (PIXE) coupled with Rutherford Backscattering Spectroscopy (RBS) were used to get chemical mapping at the glass/biological fluid interface both for major components and trace elements. 21 For PIXE-RBS analyses, we chose proton scanning micro-beam of 3 MeV energy and 50 pA in intensity. Such settings resulted in higher ionization cross-sections and an increased sensitivity for the micro-analysis. The beam diameter was 1 µm. An 80 mm 2 Si(Li) detector was used for X-ray detection, orientated at 135° with respect to the incident beam axis and equipped with a beryllium window 12 µm thick. An Al-filter with a tiny 2 mm hole drilled at its centre ("funny filter") was systematically placed in front of the Si(Li) detector; the funny filter allows the detection of heavy trace elements (Z≥25) whereas it avoids the saturation of the detector by major light (Z≤20) elements X-rays, since those latter are only detected through the small aperture. PIXE spectra were treated with the software package GUPIX.

Relating to RBS, a silicon particle detector was placed at 135° from the incident beam axis and allowed the determination of the number of protons that interacted with the sample. Data were treated with the SIMNRA code. This methodology finally allowed quantifying major and trace elements concentrations at the micrometer scale.

Results and discussion

Bioactive glass characterization

The experimental composition of each sample determined by ICP-AES analysis and their specific surface area are reported in Table 1. Thanks to the sol-gel synthesis, the final concentrations are very close to the nominal values and all the component are homogeneously distributed, as shown in the elemental maps of the 5% ZnO doped glass before immersion in biological fluids (Figure 1). All samples display a porous structure with significantly larger specific surface area for Zn doped glasses. The SEM images (Figure 2) reveal a homogeneous porosity in the range of 50 to 100 nm for low Zn content whereas higher doping leads to larger pore size distribution, between 50 and 400 nm. This can be due to a modification of the glass network because of the insertion of Zn atoms in the SiO 2 -CaO structure by Ca substitution. Zn-doping also induces an increase in the specific surface area. A high surface area can be very attractive for further interaction with biological medium by providing more nucleation sites for the formation of phosphocalcic precipitates.

In vitro tests for Zn doped and undoped SiO 2 -CaO glasses

PIXE-RBS multi-elemental maps of the surface of the glasses were recorded for each immersion time in DMEM: they provide quantitative and qualitative information about major and trace elements at the interface between the glasses and biological fluids. The observed distributions correspond to the intensity of X-rays locally emitted by the sample under proton irradiation. Each elemental map was divided in various regions of interest depending on the distribution of chemical elements in order to determine the elemental concentrations. The values calculated correspond to the mean of concentrations determined in several zones of interest. These regions of interest were defined over various samples in order to be ensured of measurements reproducibility.

Briefly, physico-chemical interactions between glasses and biological fluids induce two concomitant mechanisms: the dissolution of the glass silicate network, and the rapid formation of a surface layer at the material periphery. Concerning the in vitro behaviour of the undoped sample, all the results have been published in detail in a previous paper 21 . For the undoped sample, within 15 minutes, the incorporation of phosphorus coming from the biological medium and of Ca ions coming both from the glass matrix and DMEM, leads to the formation of a calcium phosphate enriched layer at the grains periphery. However multielemental maps have shown that the newly formed calcium phosphate layer is unstable and that it is quickly dissolved by biological fluids. After 2 days soaking, the calcium phosphate layer has been almost completely dissolved. These results suggest that the periphery of the undoped glass consists of amorphous calcium phosphates which composition significantly differs from that of hydroxyapatite (HA). The Si-rich core of the particle is finally the only region remaining since it is more resistant to dissolution. Indeed, after four days, the periphery of the SiO 2 -CaO glass is composed of 42.3% Si and only 3.8% Ca without any phosphorus.

The addition of zinc as doping element delays the breakdown of the glass silicate network from biological fluids. In fact, although the incorporation of phosphorus from the biological medium at the surface of the glass occurs during the first hours, the Ca diffusion from the core of the material to its periphery begins later on. Recent works investigating the structure of Zn-doped phosphosilicate glasses [START_REF] Linati | Qualitative and Quantitative Structure-Property Relationships Analysis of Multicomponent Potential Bioglasses[END_REF] may provide us with an explanation for this: it was found that Zn adopts a tetrahedral coordination in the glassy network and copolymerizes with [SiO 4 ] tetrahedra. That results in an overall complexation of the glass network that finally leads to an increase of its chemical durability.

After one day of interaction, the Ca-P rich peripheral layer is clearly noticeable for low Zn content (Figure 3), surrounding the core of the material from which Ca has migrated.

Higher doping concentration requires higher delay for Ca to migrate from the inner regions of the material to the periphery (Figure 4). After three days, all Zn-doped samples have formed a Ca-P rich peripheral layer. At that time the core of the grains is principally constituted of silicon and zinc oxides (Figure 5). The corresponding compositions for the glasses periphery are reported in Table 2. . Our results demonstrate that the higher the Zn content, the higher the calcium phosphates amount in the peripheral layer. After three days, the surface layer of Zn5 sample consists of 24.5% of Ca, 5.5% of P and only 19.7% of Si. By comparison, the undoped sample displays silicon rich grains (42.3%) with only a small amount of calcium (3.8%) and without any phosphorus. An essential observation is that the Ca-P peripheral layer is not dissolved after a few days of interaction for Zn-doped glasses, contrary to what was observed for the undoped glass. It is an important indication on the formation of a HA-like layer: indeed HA is the most stable and least soluble of all calcium phosphates [START_REF] Dorozhkin | Biological and Medical Significance of Calcium Phosphates[END_REF] .

To confirm these observations, we have calculated the Ca/P atomic ratio at the glass/biological fluids interface by creating thin regions of measurement 1 µm wide at the material surface. Results are shown in Figure 6. For the undoped sample, the Ca/P atomic ratio firstly decreases but after 6h the Ca-P surface layer is quickly dissolved: calcium and especially phosphate ions are progressively leached into the biological medium. This phenomenon induces a high increase in the Ca/P atomic ratio at the surface of the undoped sample. For Zn doped samples, the Ca/P atomic ratio continuously decrease, corresponding to the Ca-P layer formation and growth. The ratio then stabilizes between 1.2 and 2.5, close to the theoretical hydroxyapatite ratio: 1.67. Thus there is evidence that the initially amorphous phosphocalcic layer is progressively transformed into a more stable apatite layer.

Physico-chemical reactions between the biological fluids and the bioactive glass powders have also been monitored by measuring the DMEM composition as a function of interaction time. Figure 7 shows that Si, Ca and Zn concentrations in biological fluids increase during the first interaction delays, due to their dissolution from the glass. Logically, the amount of Zn dissolved increases with its concentration in the glass. It can be noticed that the Zn-doped samples exhibit no or low Ca precipitation coming from the biological fluids but after four days of interaction, they lead to larger calcium release, despite a lower CaO content. At the same time, a decrease in P concentration in solution is observed, due to the Ca-P layer formation. The stabilization of Ca and Si concentrations in the solution is reached after one day; concerning P, the equilibrium is reached after two days for the undoped sample and for Zn1. For Zn5, the P concentration still decreases after three days. Higher zinc content involves the incorporation of more phosphorus atoms within the surface layer. Nevertheless, longer interaction time should be used for 5% ZnO sample to be ensured of the system equilibrium.

To summarize, doping with zinc allows the early precipitation of phosphate ions from the biological fluids at the glass surface, as evidenced by Figure 3 and6. Zn-doping also delays the glass dissolution and slows the growth of the calcium phosphate layer. This facilitates the gradual crystallization of stable HA and would therefore provide a better bone bonding interface in vivo. But the most attracting characteristics of Zn-doped glasses may be their ability to release physiological concentrations of Zn into the surrounding fluids. In fact the stimulating effect of Zn doped bioactive glasses have already been shown with CaO-P 2 O 5 -SiO 2 samples for cell differentiation 24 and alkaline phosphatase production. 19 Our study shows that Zn -doping modifies the kinetics of the early first steps of the bioactive process, even for P 2 O 5 -free glasses.

Conclusion

The Zn doping effect can be resumed in two parts: a textural effect and bioactive properties. By improving the specific surface area of the glass, more nucleation sites for apatite formation are available. In addition, Zn-doping slows the glass dissolution and improves the phosphorus incorporation. The results of our study highlight the major role of Zn as doping element to enhance the calcium phosphate surface layer formation and growth, which is a prerequisite for bioactive glasses to bond to living bone.. It is important to notice that the Ca-P rich layer grows up in an acellular environment and therefore its spontaneous formation was only due to the ZnO-SiO 2 -CaO bioactive properties. Further experiments with different glass compositions and in a cellular medium could give more informations concerning the specific role of Zn ions. One of our future prospects is therefore to control the -18 -

Figure 1 .

 1 Figure 1. Elemental maps of SiO 2 -CaO-5%ZnO (Zn5) glass particle before immersion in biological

Figure 2 .

 2 Figure 2. SEM image of SiO 2 -CaO bioactive glasses doped with 1% (a) or 5% (b) ZnO.

Figure 3 .

 3 Figure 3. Elemental maps of SiO 2 -CaO-1%ZnO (Zn1) glass particle after one day of interaction with

Figure 4 .

 4 Figure 4. Elemental maps of SiO 2 -CaO-5%ZnO (Zn5) glass particle after one day of interaction with

Figure 5 .

 5 Figure 5. Elemental maps of SiO 2 -CaO-5%ZnO (Zn5) glass particle after three days of interaction with

Figure 6 .

 6 Figure 6. Ca (squares), Si (triangles), P (circles) and Zn (cross) concentrations in DMEM after

Figure 7 .

 7 Figure 7. Evolution of the Ca/P atomic ratio at the periphery of the glasses during the interaction with

FiguresFigure 1 .

 1 Figures

Figure 2 .Figure 3 .Figure 4 .

 234 Figure 2. SEM image of SiO 2 -CaO bioactive glasses doped with 1% (a) or 5% (b) ZnO.

Figure 6 .

 6 Figure 6. Evolution of the Ca/P atomic ratio at the periphery of the glasses during the interaction with

Figure 7 .Figure1.Figure3.Figure4.Figure 5 .

 75 Figure 7. Ca (squares), Si (triangles), P (circles) and Zn (cross) concentrations in DMEM after

Acknowledgement

This work was supported by ANR in the National Program of Nanosciences and Nanotechnologies PNANO2005 (project "BIOVERRES" n° ANR-05-NANO-040).

dissolution of the material along with the release of critical concentrations of biologically active ions at the rate needed for bone cell proliferation and differentiation.

. Elemental maps of a SiO 2 -CaO-5%ZnO (Zn5) glass particle after three days of interaction with the biological fluid.