Time-Domain Analysis of Resonator Array Buffers Yannick Dumeige

Abstract-We present design and time-domain simulations of microresonator array optical delay lines. The proposed buffer consists of an microresonator array unidirectionally coupled via a straight bus waveguide. We show that the use of a two-dimensional arrangement of resonators can compensate for the high order of dispersion and more specifically the third-order dispersion. Numerical calculations confirm that pulses can be stored in microresonator arrays without appreciable distortion. Finally, we briefly describe the detrimental effects of optical losses and technological errors.

Index Terms-Coupled microresonators, optical delay lines. I NTEGRATED optical delay lines or buffers are key ele- ments for a more complex system of optical signal processing. Different schemes have been proposed; among them, microresonator-based devices seem to provide a potential photonic circuit platform for this purpose [START_REF] Xia | Ultracompact optical buffers on a silicon chip[END_REF]. The simplest and generic structure consists of a single lossless resonator used as an all-pass filter (APF) [START_REF] Lenz | Optical delay lines based on optical filters[END_REF]. In this configuration, the resonator introduces only a phase shift in the incident field, as sketched in Fig. 1. Near its resonance angular frequency , the APF is a very dispersive structure and strongly depends on the angular frequency . Consequently, the APF allows optical pulses to be delayed by an amount given by the frequency-dependent group delay (Fig. 1). The main limitation of this approach comes from the resonant feature of the delaying process [START_REF] Lenz | Optical delay lines based on optical filters[END_REF]. Higher orders of dispersion with , which are defined by , strongly limit the bandwidth of the pulses that can be delayed without distortion. To circumvent this drawback, it has been proposed to use multistage APF by forming side-coupled integrated space sequence of resonators (SCISSOR) [START_REF] Heebner | Slow' and 'fast' light in resonatorcoupled waveguides[END_REF]. By using identical resonators, the total delay is multiplied by and the fractional delay is increased. Alternatively, it has been proposed to cascade APF whose properties are gradually tuned in order to flatten the group delay [START_REF] Lenz | Optical delay lines based on optical filters[END_REF], [START_REF] Yang | Increasing the delay-time-bandwidth product for microring resonator structures by varying the optical ring resonances[END_REF]. Finally, Khurgin has suggested canceling high orders of dispersion by using arrays of coupled microresonators [START_REF] Khurgin | Expanding the bandwidth of slow-light photonic devices based on coupled resonators[END_REF]. In this letter, we present design and time-domain performances of arrays of coupled microresonators used as optical buffers. We would like to highlight the interest of arrays of resonators and the main limitations of their practical use.

The proposed structure consists of an array of identical columns of single-mode microrings of radius and effective index , as represented in Fig. 2

(a). Each column of the array

The author is with ENSSAT-FOTON (CNRS UMR 6082) Université de Rennes 1, 22300 Lannion, France (e-mail: yannick.dumeige@enssat.fr). , we obtain an SCISSOR [START_REF] Heebner | Slow' and 'fast' light in resonatorcoupled waveguides[END_REF], and the case of has been recently studied [START_REF] Mario | Optical buffer with higher delay-bandwidth product in a two-ring system[END_REF]. The coupling coefficients between resonators and for is . defined by is assumed real and positive. Similarly, the coupling coefficient between the bus waveguide and the first resonator is . The amplitude transfer function of the unit cell is where we calculate by the recursive relation [START_REF] Xia | Ultracompact optical buffers on a silicon chip[END_REF] where and are the roundtrip amplitude attenuation and the phase shift. We define the frequency detuning by . We will use a reference structure with , m, and . With the coupling coefficient given in Table I, we obtain a maximal group delay ps [see Fig. 3(a)]. As represented in Fig. 3(b), the third-order dispersion at resonance for is very strong and negative. This is the first limitation for pulse propagation since [START_REF] Khurgin | Expanding the bandwidth of slow-light photonic devices based on coupled resonators[END_REF], [START_REF] Melloni | Linear and nonlinear pulse propagation in coupled resonator slow-wave optical structures[END_REF]. It is possible to cancel by using resonators in the unit cell [START_REF] Madsen | Optical all-pass filters for phase response design with applications for dispersion compensation[END_REF]- [START_REF] Dumeige | Measurement of the dispersion induced by a slow-light system based on coupled active-resonator-induced transparency[END_REF]. For , the line Config. 1 in Table I gives the coupling coefficients used to cancel with a maximal delay at resonance ). Fig. 3(a) and (b) also represents the group delay and the third-order dispersion for . In our time-domain simulations, we will also use resonators. For , different ways can be adopted to cancel the third-order dispersion such as circuit-based methods [START_REF] Van | Circuit-based method for synthesizing serially-coupled microring filters[END_REF]; here we used numerical optimization to calculate the values of the coupling coefficients of the unit cell. The objective function is defined by [START_REF] Lenz | Optical delay lines based on optical filters[END_REF] where is the targeted delay over a bandwidth , then . By minimizing , we obtain a flat group delay for a bandwidth which also leads to the cancellation of . The set of coefficients for noted in Config. 1 has been calculated for GHz and ps. The corresponding group delay and are given in Fig. 3(a) and (b), respectively. Note that for each unit cell, we have chosen a maximal delay proportional to in order to compare different structures with the same number of resonators producing the same optical delay. We have simulated the performances of the different proposed structures in the time domain using the model described by Pereira et al. in [START_REF] Pereira | Gap-soliton switching in short microresonator structures[END_REF] by assuming that the material dispersion is much weaker than the structural one. The calculation consists of the propagation of an input Gaussian optical pulse of intensity profile with an amplitude , an angular frequency rad s , and a full-width at half-maximum by a one-dimensional finite-difference method. First, we have chosen a total delay of 1.920 ns corresponding to 1 320, 2 160, and 4 80 structures. For ps, the results are given in Fig. 3(c) and(d). The structure strongly distorts the impulsion due to its strong negative . On the other hand, for the and structures, where the third-order dispersion has been canceled, the pulses are delayed without distortion. To show the real interest of using the device, one has to use shorter pulses. With this in mind, we used pulses of temporal width ps. We used the same structures but for and ; we slightly changed the values of the coupling coefficients (keeping the same group delay) in order to increase their bandwidths. The corresponding coupling coefficients are given in Table I (see the line called "Config. 2"). For , the optimization procedure has been used with GHz and ps. Fig. 4(a) shows the group delay for the new unit cells for and ; we also recall the group delay dispersion for with the previous set of coupling coefficient (Config. 1). In the two cases, the bandwidth has been increased and ripples appear in the group delay dispersion. For the time-domain simulations, we have chosen an overall delay of 120 ps; thus we used the following structures: 1 20, 2 10, and 4 5. The thicker lines in Fig. 5(b)-(d) represent the simulation results. In the present example, the structure induces less distortion than the structure thanks to its larger bandwidth for the same delay per resonator. For , the pulse is still strongly distorted. In the lossless case, the simulations using the previous set of coefficients show a more pronounced distortion as represented in Fig. 5(c) and (d) in dashed-dotted lines. For structures compatible with short pulses ps , we have studied the impact of optical . This strongly limits in practice the use of high numbers of resonators. For insertion losses as high as 10 dB ( dB/cm, , and ), the pulses are not distorted using the same design. Note that for a given delay, the overall attenuation is the same for , , and when the number of resonators is chosen. Finally, we have studied the impact of both technological errors in and in the coupling coefficients on the temporal profile of the output pulse. Fig. 6(a) represents the output pulse after propagation in a 4 5 structure where we added random deviation from the nominal values in the coupling coefficients. The mean maximal amplitude relative error is noted . These simulations show that errors up to 10% in the intensity coupling coefficients do not introduce too much additional distortion. We carried out the same calculations by adding random deviation to the values of the ring radii with a maximal amplitude . The simulations presented in Fig. 6(b) show that errors about 4 nm in the radius size induce strong additional distortion in the output pulse profile. For our values of and , these errors give a resonance frequency mismatch around 50 GHz which is one order of magnitude larger than what is reported in [START_REF] Barwicz | Fabrication of add-drop filters based on frequencymatched microring resonators[END_REF].

We have performed time-domain simulations of microresonator array buffers. For a given resonator number and a given overall delay, two lines of resonators are sufficient to cancel the third-order dispersion and to avoid pulse distortion for sufficiently long pulses. For shorter pulses, an increase in the number of lines allows the Gaussian shape of the input pulses to be preserved. The main limitations of such a buffer from a practical point of view come from optical losses and resonator size fabrication tolerance (better than 4 nm for an interference order about 100). In the chosen example, the relative coupling coefficient accuracy must be about 10%.

Fig. 1 .

 1 Fig. 1. Microresonator APF side coupled to a bus waveguide. The APF induces a phase shift (!) in an input field E (!) and introduces a group delay on an optical pulse E (t) of duration T . The delayed pulse is noted E (t).

Fig. 2 .

 2 Fig. 2. (a) Microresonator array optical buffer and its bus waveguide. (b) Schematic representation of the unit cell.

Fig. 3 .

 3 Fig. 3. (a) Group delay dispersion and (b) third-order dispersion introduced by the unit cell. (c) A 30-ps-long input pulse and output pulse delayed by about 1920 ps for n =1. (d) Output pulses for the same input and the same delay as in (c) in the cases n = 2 and n =4. In all the present calculations, we do not consider losses ( =0).Forn =2and n =4, we used the sets of coupling coefficients referring to Config. 1.

Fig. 4 .

 4 Fig. 4. (a) Group delay introduced by the unit cell for n =2and n =4in the lossless case of Config. 2; we also recall the group delay for n =4in the case of Config. 1. (b) Transmission of the unit cell with =1dB/cm; for n =2 and n =4, we used the second configuration.

Fig. 5 .

 5 Fig. 5. (a) A 10-ps-long input pulse. Output pulses delayed by an amount of about 120 ps in the lossless case and for =1dB/cm: (b) n =1, (c) n =2, and (d) n =4.Forn =2and n =4, we have used the second configuration;we also add the output pulses obtained with Config. 1 in the lossless case.

Fig. 6 .

 6 Fig. 6. Output pulses in the second configuration for n =4and m =5 with losses =1dB/cm and technological errors: (a) considering errors of amplitude 1 jj in the intensity coupling coefficients; (b) considering errors of amplitude 1R in the ring radius.

TABLE I COUPLING

 I COEFFICIENTS USED IN THE CALCULATIONS.CONFIGURATION 1 IS USED FOR T =30ps AND CONFIGURATION 2 FOR T =10ps

of 12 ps (twice the delay for


Hervé Roussain

Frédéric Guidec

Cooperative Component-Based Software Deployment in Wireless Ad Hoc Networks

This paper presents a middleware platform we designed in order to allow the deployment of component-based software applications on mobile devices (such as laptops or personal digital assistants) capable of ad hoc communication. This platform makes it possible to disseminate components based on peer-to-peer interactions between neighboring devices, without relying on any kind of infrastructure network. It implements a cooperative deployment scheme. Each device runs a deployment manager, which maintains a local component repository, and which strives to fill this repository with software components it is missing in order to satisfy the deployment requests expressed by the user. To achieve this goal the deployment manager continuously interacts in the background with peer managers located on neighboring devices, providing its neighbors with copies of software components it owns locally, while obtaining itself from these neighbors copies of the components it is looking for.

Introduction

The number and variety of lightweight mobile devices capable of wireless communication is growing significantly. Such devices include laptops, tablet PCs, personal digital assistants (PDAs), many of which are now shipped with built-in IEEE 802.11 (a.k.a. Wi-Fi [START_REF]Information Technology, Telecommunications and Information Exchange between Systems, Local and Metropolitan Area Networks, Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications[END_REF]) network interfaces. With such interfaces, the devices can occasionally be connected to an infrastructure network, using so-called access points that play the role of gateways. But the 802.11 standard also makes it possible for mobile devices to communicate directly in ad hoc mode, that is, without relying on any kind of infrastructure network. An ad hoc network is thus a network that can appear and evolve spontaneously as mobile devices themselves appear, move and disappear dynamically in and from the network [START_REF] Perkins | Ad Hoc Networking[END_REF].

For the users of laptops or PDAs, the prospect of deploying software applications on these devices as and when needed obviously appears as an attractive one, no matter if these devices communicate in infrastructure or in ad hoc mode. Yet, solutions for component-based software deployment have been proposed mostly for infrastructurebased environments so far, while very little effort has been devoted to software deployment in purely ad hoc networks.

In this paper we describe a model we devised in order to allow the deployment of component-based software applications on mobile devices participating in an ad hoc network. In Section 2 we motivate our approach by showing how infrastructurebased networks and ad hoc networks constitute radically different environments as far as software deployment is concerned, and we show that solutions that prove efficient in infrastructure environments are hardly applicable in ad hoc environments. In Section 3 we present CODEWAN (COmponent DEployment in Wireless Ad hoc Networks), a middleware platform that implements our model. The main characteristics of this platform are discussed in Section 4, which also lists some directions we plan to work along in the future. In Section 5 we compare CODEWAN with other works that also address the problem of software deployment, either in infrastructure environments, or in ad hoc environments. Section 6 concludes the paper.

Motivations

In this section we show that deploying software components in an ad hoc network raises issues that usually do not appear in infrastructure networks. As a reminder, we first describe how software component provision and delivery are commonly performed in an infrastructure-based environment. We then show that an ad hoc network presents additional constraints that need to be addressed specifically.

Software deployment in an infrastructure network

Figure 1 illustrates a typical infrastructure network, including stable and mobile hoststypically, workstations and laptops-interconnected through gateways (such as routers and switches). In such an environment some of the stable hosts can be in charge of storing components in so-called component repositories, and of implementing server programs capable of delivering these components on demand. Other hosts in the network can then behave as simple clients with respect to these servers. Whenever the owner-or the administrator-of one of the client hosts initiates the deployment of a new component-based software application on this device, the problem mostly comes down to locating the server-or servers-capable of providing the components required by this application, and downloading these components so they can be installed locally. Consider the example shown in Figure 1, and assume that the owner of device A decides to initiate the installation on this device of an application that requires components c1, c2 and c3. The deployment middleware running on device A must first identify one or several servers capable of delivering these components. A component may actually be provided by several servers, for example in order to balance the workload in the network, or to allow fault tolerance. In any case, once a client has identified a server that can provide a component, obtaining this component simply requires its download between the server and the client. Note that in such a context the deployment of a component on a given host can usually be considered as a "real time" operation: once a user has ordered the deployment middleware to locate and download a component, this operation can usually be performed immediately. In the remaining of this section, we show that deploying components in an ad hoc environment can in contrast require a more lengthy process, which requires some middleware capable of enforcing a deployment strategy in the background on behalf of the user.

Software deployment in a dynamic ad hoc network

Figure 2 shows a typical dynamic ad hoc network, which consists of a collection of portable communicating devices. The devices in such a network are usually highly mobile and volatile. Device mobility results from the fact that each device is carried by a user, and users themselves move quite a lot. Device volatility is the consequence of the fact that, since the devices usually have a limited power-budget, they are frequently switched on and off by their owners. A major characteristic of wireless ad hoc networks is that communication interfaces have a limited transmission range. Consequently any device can only communicate directly with neighboring devices. Multi-hop transmissions can sometimes be obtained by implementing a dynamic routing algorithm on each device [START_REF] Poupyrev | Analysis of Wireless Message Broadcast in Large Ad Hoc Networks of PDAs[END_REF][START_REF] Royer | A Review of Current Routing Protocols for Ad-Hoc Mobile Wireless Networks[END_REF], but it is worth observing that even with dynamic routing, a realistic ad hoc network often presents itself as a fragmented network. Such a network appears as a-possibly changingcollection of so-called "islands" (also referred to as "clouds" or "cells" in the literature). Mobile devices that belong to the same island can communicate together, using either multi-hop or single-hop transmissions depending on whether dynamic routing is used or not in the network. However, devices that belong to distinct islands cannot communicate together, because no transmission is possible between islands.

In such a context, a traditional client-server deployment scheme such as that illustrated in Section 2.1 is hardly applicable, as no device is stable and accessible enough to play the role of a server of components, maintaining a component repository and allowing client devices to access this repository whenever needed.

In the remainder of this paper, we present a model we propose in order to allow for these constraints. Basically, instead of being able to access a server whenever needed, each device must maintain a local component repository. A peer-to-peer interaction model then makes it possible for a device to cooperate with its neighborhood, by allowing its neighbors to obtain copies of the software components available on its local repository, while itself benefiting from a similar service offered by its neighbors.

Consider the example shown in Figure 2, and assume again that the owner of device A wishes to install on this device an application that requires components c1, c2 and c3. In our example, A can obtain components c1 and c2 from device B. But as devices C and E-that both own a copy of component c3-are (possibly temporarily) unreachable, A cannot obtain a copy of component c3 from any of these devices. Yet A could obtain component c3 from device C if this device was switched on by its user. It could also obtain this component from device E if A's user happened to walk towards E, or if E's user happened to walk toward A. A roaming device such as D may even serve as a benevolent carrier between E and A, transporting component c3-and possibly other components as well-between separate islands, and thus contributing to the dissemination of software components and applications all over the network.

This example shows that when the owner of a mobile device participating in an ad hoc network requests the deployment of a component-based application on this device, there is no guarantee that this request can be satisfied immediately, as there is no guarantee that the components required for this deployment are readily accessible in the neighborhood. Yet, since the topology of an ad hoc network can change continuously and unpredictably as devices move and are switched on or off, the fact that a given component cannot be obtained at a given time does not involve that this component will remain inaccessible in the future. There is thus a need for some deployment middleware capable of ensuring the collection of missing components in the background in order to satisfy the user's needs.

Towards software component deployment on mobile devices

In this section, we present an overview of CODEWAN (COmponent DEployment in Wireless Ad hoc Networks), a platform we designed in order to support the deployment of component-based software applications on mobile devices communicating in ad hoc mode. CODEWAN implements a cooperative model, where neighboring devices interact in order to discover and exchange software components. Each device implements a local component repository, and a deployment manager is responsible for maintaining this repository on behalf of the user. Any component stored in the repository can be used to assemble and start an application locally. Copies of this component can also be sent on demand to neighboring devices.

Overview of the CODEWAN platform

The platform is built as a three-layer model, as shown in Figure 3. The upper and lower layers in this model have been described in details in [START_REF] Le | JAMUS: Java Accommodation of Mobile Untrusted Software[END_REF] and [START_REF] Guidec | Asynchronous Document Dissemination in Dynamic Ad Hoc Networks[END_REF] respectively. They are thus only described briefly below, and the paper then continues with a detailed description of the model's central layer, which implements the component repository and the deployment manager that maintains this repository. The upper layer in the platform is meant to provide a framework for assembling and running applications. Instead of defining its own component-model, CODEWAN was designed so as to rely on existing execution frameworks for component-oriented or service-oriented applications. In its current implementation it interfaces with JAMUS, a runtime framework that is primarily dedicated to hosting potentially malicious mobile applications [START_REF] Le | JAMUS: Java Accommodation of Mobile Untrusted Software[END_REF], as well as with JULIA, an execution framework for applications designed using the Fractal component model [START_REF] Bruneton | An Open Component Model and Its Support in Java[END_REF].

The lower layer in our model was designed in order to support the asynchronous dissemination of so-called transfer documents in an ad hoc network. A transfer document is an XML document whose external element's attributes specify the conditions required for disseminating the document in the network. These attributes thus play approximately the same role as header fields in IP packets or in UDP datagrams. They indicate typically the document's source and destination, the expected propagation scope for this document, etc.

The "payload" of a transfer document consists of the internal XML elements that are embedded in the document. Any kind of structured information can be transported in a transfer document. In CODEWAN, though, transfer documents are used to transport software package descriptors in the network.

Figure 4 shows a typical transfer document. Attributes in this document indicate that it was sent by device shiva, and that it was addressed to any device in the neighborhood (notice that the communication layer CODEWAN relies on supports the use of wildcard addresses). The payload in this transfer document consists of a package descriptor, whose role and structure are detailed in Section 3.3.

< t r a n s f e r -document document-i d = " fb54356fe468d9 " source = " d e v i c e : s h i v a " d e s t i n a t i o n= " d e v i c e : * " hops-to-l i v e = " 3 " l i f e t i m e = " 01 : 0 0 : 0 0 " s e r v i c e-t y pe = " package-adv ert i s ement " > <package-d e s c r i p t o r > <general-i n f o r m a t i o n t y pe = " a p p l i c a t i o n / j a v a " c at egory = " communication / messaging " name= " JMessager " v e r s i o n = " 1.

" p r o v i d e r = " L a b o r a t o i r e V a l o r i a "

summary= " JMessager i s a P2P messager " / > <java-a p p l i c a t i o n name= " masc . jmessager . JMessagerImpl " / > <dependencies > < r e q u i r e d-package name= " JMessengerUI " v e r s i o n = " 1. 2 " / > < r e q u i r e d-package name= " P2PAsyncDissemination" / > < o p t i o n a l-package name= " AddressBook " v e r s i o n = " 2. 0 " / > < / dependencies > < / package-d e s c r i p t o r > < / t r a n s f e r -document> The communication layer in CODEWAN provides services for encapsulating transfer documents in UDP datagrams. Large XML documents can be fragmented and then transported in distinct, smaller transfer documents that each can fit in a single UDP datagram. The communication layer of course supports the re-assembly of such fragments after they have been received from the network. Documents can be transferred either in unicast, broadcast, or multicast mode, and using either single-hop or multihop transmissions. In the latter case, all mobile devices in the network are expected to behave as routers, using algorithms for dynamic routing and flooding such as those described in [START_REF] Royer | A Review of Current Routing Protocols for Ad-Hoc Mobile Wireless Networks[END_REF][START_REF] Poupyrev | Analysis of Wireless Message Broadcast in Large Ad Hoc Networks of PDAs[END_REF][START_REF] Sasson | Probabilistic Broadcast for Flooding in Mobile Ad Hoc Networks[END_REF].

Further details about CODEWAN's communication layer can be found in [START_REF] Guidec | Asynchronous Document Dissemination in Dynamic Ad Hoc Networks[END_REF]. In the remainder of this paper we focus on the description of the central layer of the platform. The deployment manager is implemented in this layer, together with the component repository this manager is in charge of maintaining. The repository is a place where software components can be stored locally on a mobile device. Components stored in this repository are thus readily available for the execution framework that constitutes the upper layer of the platform. The deployment manager takes orders from the user, and interacts with peer managers that reside on neighboring devices in order to fill the local repository with components required by the user, while providing its peers with components they need in order to satisfy their own users.

Installation steps in CODEWAN

The deployment manager can provide the user with information about all the applications it knows about. At any time a given application is either:

-installed locally (meaning that this application is either already running in the local execution framework, or ready to be loaded and started in this framework); -installable (meaning that all the components required for running this application are available in the local repository, so the application could be installed immediately if the user requested it);

-not installable yet (meaning that some of the components required by this application are not present in the local repository).

Besides observing the status of each application, the user can modify this status, requesting for example that an application be started (which implies that this application be already installed locally), or that an application be uninstalled (and all its components removed from the repository). Additionally the user can initiate the deployment of an application, thus instructing the deployment manager to try to obtain any missing component for this application from neighboring devices. CODEWAN implements a basic user interface that can run in console mode. Additionally, graphical interfaces have been designed in order to facilitate the interaction between the user and the deployment manager running on a mobile device. For example Figure 3 shows an interface that was designed specifically for personal digital assistants.

Software components, applications, and packages

The deployment of component-based applications implies that components be transmitted in the network, and stored in local repositories. Before they can be loaded and executed in a runtime framework, software components are encapsulated in so-called software packages, that can be considered as storage and transfer envelopes for these components. Besides encapsulating the actual code of the components, software packages can additionally encapsulate some data required by a software component or application. They can also encapsulate documents describing the overall architecture of a component-based application (such as CCM component assemblies [START_REF] Omg | Corba components[END_REF], or architecture descriptors in the Fractal model [START_REF] Bruneton | An Open Component Model and Its Support in Java[END_REF]).

Package descriptors Each software package in CODEWAN is associated with a package descriptor. This descriptor provides information about the package's identity, its content, its category, etc. It can be embedded in the package itself, but it can also be processed separately. For example, the transfer document shown in Figure 4 encapsulates a package descriptor as its payload. In a typical scenario such a document could be broadcast by a device in order to inform its neighbors about a software package that is available in its local repository.

The package descriptor shown in Figure 4 actually describes the main component of a Java messaging application (as specified by attribute type in the descriptor). It provides general information about the application, such as its name, version number, provider, etc. It also indicates that in order to be assembled the application requires components that can themselves be found in three other software packages. Two of these packages are absolutely needed for assembling the application, while the third one can be used optionally in order to improve the functionality of the application. This example shows that when the components encapsulated in a particular package depend on components that are encapsulated in other packages, this information is mentioned explicitly in package descriptors. Dependencies between packages can also appear when a package contains only the description of the architecture of an application, while other packages encapsulate components that are required for assembling this application, or data that are needed for running this application.

Software packages As mentioned above, software packages can encapsulate software components, as well as plain data or application architecture descriptions. A software package usually encapsulates its own descriptor, but this descriptor can also be extracted from the package and processed separately whenever needed.

In the current implementation of the CODEWAN platform, application data and the code of software components are encoded using the Base64 standard. The result of this encoding is then encapsulated as CDATA information in an XML document.

Main functionalities of the deployment manager

The deployment manager running on a mobile device is notably responsible for maintaining a local component repository on this device, while interacting with peer managers located on neighboring devices. Among other things the deployment manager can:

decide what packages and package descriptors should be stored in the local repository and, if necessary, what packages and descriptors should be removed from this repository;

Notice that since mobile devices are usually resource-constrained, the deployment manager might sometimes have to reclaim the space occupied by unused, yet potentially interesting packages.

announce to its neighbors what packages are available locally, thus indicating that these packages can be delivered on demand;

Announcing the availability of a package is performed by broadcasting a transfer document that encapsulates the descriptor of this package, as shown in Figure 4. Such an announcement can be broadcast periodically, or when a new device appears in the neighborhood. It can also be broadcast after a request has been received from a neighbor, as described in the next three items.

search the neighborhood for specific packages, or for packages that satisfy precise criteria;

Package searching is performed by broadcasting a transfer document that encapsulates a "request for descriptors". Such a request compares with a standard package descriptor, except that each attribute in the request defines a regular expression. Any deployment manager receiving a request can thus match this request against the descriptors of the packages stored on its local repository. If one or several of these descriptors match the request, then the deployment manager answers this request by announcing the availability of the matching packages, as described in item 2.

discover what packages are available in the neighborhood;

This is performed by broadcasting a "request for descriptors" as explained in the former item, except that this request is not selective at all: it actually calls for the announcement of all the packages available in the neighborhood.

ask a neighbor for the transmission of one-or several-particular package(s);

This is performed by sending the targeted neighbor a "request for packages", which is similar to a "request for descriptors" except that the neighbor is expected to return the desired packages, rather than simply announce that it owns these packages. The actual transmission of software packages can be performed either in unicast, multicast, or broadcast mode, depending on the configuration of the sending deployment manager.

receive packages from a neighbor, and decide for each package if it should be stored on the local repository.

The deployment manager can be expected to accept and store packages it has itself requested before. But since packages can sometimes be broadcast-as explained above-the deployment manager may also receive packages it has never requested. In such a case the deployment manager can be configured so as to implement a hoarding policy, storing packages that may prove interesting in the future.

The basic operations mentioned in the above list make it possible to devise and implement a number of different strategies for cooperative component deployment. Actually, while designing the CODEWAN platform we intentionally defined a comprehensive set of functionalities so as to allow a large number of interaction patterns between neighboring deployment managers. Several alternative deployment strategies can thus be implemented based on these functionalities. Part of our current work is now devoted to devising such strategies, and observing how they perform in realistic conditions. Although a large number of deployment scenarios can be considered, the next section describes the major steps these scenarios can be based on.

Major steps in a deployment scenario

Learning about new applications At any time the deployment manager running on a mobile device maintains in the local repository a collection of application descriptors. As explained in Section 3.2 some of these descriptors correspond to applications that are not installable yet, meaning that some of the packages required for assembling these applications are not available locally. The deployment manager can thus "know" about the existence of an application (because it owns a descriptor of this application), even though this application is not yet installed locally.

A basic approach for a deployment manager to learn about new applications is simply to listen to the network in order to collect transfer documents that contain application descriptors, while broadcasting itself the descriptors of the applications stored in its repository. Neighboring deployment managers thus spontaneously inform each other about existing applications.

Initiation of a new application deployment

In order to initiate the deployment of a new application on a mobile device, the user can rely on the interface of the deployment manager, and select with this interface an application that is not installed yet. This scenario however implies that the local deployment manager must already know about the existence of this application.

Alternatively a user may know about an application the deployment manager itself has never heard about. In such a case the user can inform the deployment manager about the name of this application, and the deployment manager will then start looking for the corresponding descriptor in the neighborhood.

Identification of missing packages

Once the descriptor of the desired application is available, the deployment manager can examine the dependencies described in this descriptor in order to determine what other packages are needed for assembling this application.

Remember that several applications may be assembled out of the same set of components. The packages needed to assemble a new application may thus be already available locally, as they may have been collected before in order to assemble and start another application. Note also that the deployment manager may implement a hoarding policy, storing unused packages "just in case" in the local repository. Consequently, in the best circumstances, when determining what packages are needed for assembling an application the deployment manager may actually discover that all these packages are already present in the local repository. In such a case the deployment of the application can be considered as complete.

In most cases, though, when the user asks for the deployment of a new application the deployment manager is likely to discover that a number of required packages are missing in the local repository. For each application whose deployment is in progress the deployment manager maintains a list of desired packages (some kind of a "shopping list", actually). Once the packages required for a given application have been identified, their identity is appended to the corresponding "shopping list".

The deployment manager runs a background process that aims at collecting any package whose identity appears in at least one of the "shopping lists" it maintains.

Search for missing packages

Searching for packages is a proactive operation that consists in broadcasting "requests for descriptors". This operation can be performed either periodically, or it can be triggered by an event, such as the detection of a new device in the neighborhood.

A request is a transfer document that contains a list of desired packages. Neighboring devices that own some of these packages are expected to reply by announcing the availability of these packages.

Note that since announcements are broadcast in the network, a deployment manager can sometimes discover passively that a number of packages it is looking for are available in the neighborhood. Packages can thus be located simply by listening to broadcast announcements. CODEWAN makes it possible to combine both forms of package discovery (proactive and reactive) in a single deployment strategy.

Download of missing packages

Whenever the deployment manager discovers that some of the packages it is looking for are available on a neighbor device, it can react by sending a "request for packages", thus asking that the desired packages be transmitted in the network.

After receiving one of the packages it has requested, the deployment manager stores this package in the local repository, and removes its name from its "shopping lists". The descriptor of the package must also be analyzed in order to check if this package depends on other packages that are not available locally. If so, then these packages must also be considered as requested packages, and their names be appended to the deployment manager's "shopping lists".

Completion or termination of an application's deployment

The deployment of an application is complete when the corresponding "shopping list" is empty, which means that all the packages required for assembling this application have been collected and are now available in the local repository. The application can then be considered as installable, and be presented as such to the user through the user interface.

The user can also decide to cancel the deployment of a particular application at any time. In that case the "shopping list" maintained by the deployment manager for this application is discarded, and the packages that have already been collected and stored in the local repository are marked as unused (unless they are indeed used by another locally installed application, and unless their names appear in another local "shopping list"). Unused packages can be maintained by the deployment manager in the local repository as long as there remains enough space to receive and store other desired packages. Otherwise the deployment manager is entitled to remove unused packages whenever there is a need to free storage space in the repository.

Discussion and future work 4.1 Efficiency considerations

The model we propose for cooperative software deployment on mobile devices is inherently a probabilistic one. Indeed, when a user requests that a given application be deployed on a mobile device, there is no absolute guarantee that the deployment manager on this device will ever manage to collect the required packages. It is worth mentioning that this lack of guarantee is a consequence of the characteristics inherent to dynamic ad hoc networking, rather than a limitation of the model itself. However the model can be adapted in order to account for these constraints.

For example, in order to increase the chance that the requests of the user can be satisfied, the deployment manager in the CODEWAN platform was designed so as to exhibit a persistent behavior. Whenever it cannot obtain a number of packages from its current set of neighbors, the deployment manager simply persists and tries to obtain these packages later, after its neighborhood has changed. Device mobility and volatility thus become advantages in this process, as the neighborhood of a device is not limited to a fixed set of neighbors. Whenever a package cannot be found at a given time in the neighborhood, there is always a chance that it can be found in the future.

The actual efficiency of our model in realistic conditions depends on a large number of factors, such as the geographical distribution of mobile devices, their speed, the frequency at which devices are switched on and off by their users, data transmission rates, the amount of storage space available in each device's local repository, the size of software packages, the number of packages required to assemble an application, etc. Work is now in progress in order to evaluate the average efficiency of our model in different conditions, based on simulations, and based on actual experimentation with CODEWAN-enabled mobile devices.

Towards adaptive software deployment

In the current implementation of the CODEWAN platform, the deployment manager running on a mobile device must be configured manually by the user of this device. For example it can be configured so as to announce periodically the packages it owns locally, and to broadcast periodically a request indicating the packages it is looking for.

In both cases, though, the user is responsible for choosing the appropriate periodicity for these transmissions.

The user must likewise determine how much storage space must be assigned to the local repository (which can be implemented either in memory or in the filesystem), and whether the deployment manager should implement a hoarding policy (storing in its local repository any package it receives from the network, even if this package is not mentioned in a local "shopping list").

Future work will notably focus on the development of a strategy manager capable of adjusting the behavior of a deployment manager transparently and continuously on behalf of the user. For example the periodicity for announcing local packages and requesting desired packages could be adjusted dynamically based on the mobility of a device, on observations of its neighborhood, or on internal events (such as the local device being suspended or resumed). The hoarding policy implemented by a deployment manager may likewise be guided by statistics about the requests received from the neighborhood: a deployment manager that frequently receives requests for a package it does not own locally may decide to try to collect this package so as to help multiply its copies-and thus its overall availability-in the ad hoc network.

Security considerations

The approach we propose for deploying software applications on mobile devices relies on the assumption that the owners of these devices may find it convenient to share software components with each other using ad hoc communication. This approach obviously raises a number of legitimate concerns regarding security, as the owner of a mobile device may for example be reluctant to run on this device pieces of software obtained from unidentified sources. We believe that this problem may be solved satisfactorily by using digital signatures so as to ascertain the origin of a software component, as well as ciphering in order to limit the use of a given component to a particular community of users. These are directions we plan to investigate in the near future.

Compatibility with standard component models and frameworks

CODEWAN is not strongly dependent on a specific execution framework, or on a particular component model. Actually the focus in this platform is put on the dissemination of software components rather than on the assembly and execution of component-based applications per se. In our opinion CODEWAN should quite easily accommodate almost any component model and any execution framework. The only condition is that components in the model considered can be transmitted and stored in packages, and that the execution framework can be adapted so as to take components from the local repository maintained by the platform's deployment manager, rather than from a legacy repository.

CODEWAN currently interfaces with two execution frameworks called JAMUS and JULIA. JAMUS is a security-oriented execution framework we designed, which provides a resource-constrained environment for untrusted Java applications [START_REF] Le | JAMUS: Java Accommodation of Mobile Untrusted Software[END_REF]. JULIA is a framework that implements the Fractal component model [START_REF] Bruneton | An Open Component Model and Its Support in Java[END_REF]. Ongoing work aims at interfacing CODEWAN with OSCAR, a service-oriented framework for OSGi bundles [START_REF] Hall | An OSGi Implementation and Experience Report[END_REF]. Java Web Start [START_REF]Java Web Start 1.5.0 Documentation[END_REF] and Apache Maven [START_REF]The Apache Software Foundation[END_REF] both support the deployment and the update of Java-based application programs. They are primarily meant to be used on stable, fully connected, infrastructure networks, though. They rely on a client-server model: a server (or a collection of servers in Maven) maintains a repository where applications can be stored, and clients can download new applications-or new versions of applications they have already downloaded-from this server.

A number of papers have proposed to apply the client-server model for software deployment in ad hoc networks. For example, JDRUMS [START_REF] Andersson | A Deployment System for Pervasive Computing[END_REF] implements a content delivery system for software components. It relies on dedicated devices that host server programs called "JSTOREs". These server programs must register with a JINI lookup service in order to be located by the devices on which some software is to be deployed. Although mobile, pervasive devices are targeted in this work, the JSTOREs and the lookup service are assumed to be stable at any time, and available whenever needed.

As explained in Section 2 we believe that the traditional client-server model is hardly applicable for deploying and updating software in an autonomous ad hoc network, although it usually performs most satisfactorily in an infrastructure network. As an alternative to the client-server model we propose to rely on cooperative, peer-to-peer interactions between neighboring mobile devices. To our knowledge, this approach has not really been investigated so far, although cooperative software deployment has been considered in infrastructure-based environments, and proposals have been made to support code mobility or information dissemination in ad hoc networks.

SoftwareDock is a framework for distributed software deployment that uses mobile agents to support the transfer of software applications between so-called producers and consumers [START_REF] Hall | A Cooperative Approach to Support Software Deployment Using the Software Dock[END_REF]. This approach thus compares with the client-server model. Moreover SoftwareDock is primarily meant to be used in infrastructure networks, as the prime motivation in this work is to allow load balancing and fault tolerance between software producers. Tacoma [START_REF] Sudmann | Software Deployment Using Mobile Agents[END_REF] is another system that relies on mobile agents to deploy components. Like SoftwareDock, though, it does not specifically address the problem of component deployment in ad hoc networks.

CORBA-LC defines the notion of CORBA Lightweight Component, and a number of design and implementation requirements for deploying such components are identified in [START_REF] Sevilla | Design and Implementation Requirements for CORBA Lightweight Components[END_REF]. This paper notably suggests that components should be deployed using a "peer network" model, where the whole network acts as a repository for managing and assigning resources (including components). However, although [START_REF] Sevilla | Design and Implementation Requirements for CORBA Lightweight Components[END_REF] observes that spurious node failures and node disconnections should be supported, our understanding of this paper is that it too considers the deployment of components in a quasi-stable, infrastructure-based environment.

Component deployment in ad hoc networks is specifically addressed in [START_REF] Handorean | A Component Deployment Mechanism Supporting Service Oriented Computing in Ad Hoc Networks[END_REF], which describes a framework for service-oriented computing. The components considered in this framework are actually proxy components, which must be deployed locally in order to allow local clients to access remote services. Service directories and implementation repositories are constructed and maintained using a distributed approach that implies the opportunistic collaboration of neighboring hosts in the ad hoc network.

SATIN provides support for component-based, self organized systems on mobile devices [START_REF] Zachariadis | SATIN: A Component Model for Mobile Self Organisation[END_REF]. It supports the storage and the execution of components on a device, as well as component advertisement, discovery and transfer between devices. SATIN is meant to serve as a generic platform that offers self organization through logical mobility and componentization. As such it does not readily compare with CODEWAN, which addresses specifically the problem of software deployment on mobile devices. Yet we believe that SATIN could serve as a framework for developing a deployment system similar to CODEWAN. This system would be dedicated to SATIN components, though (as SATIN defines its own component model), just like CORBA-LC only considers the deployment of CORBA components. In contrast CODEWAN is somehow more versatile. It processes software packages (that can encapsulate any kind of components) rather than the components themselves, and it delegates the problems of locally assembling and running components to an associate execution framework.

Conclusion

In this paper we presented the CODEWAN platform, which is dedicated to the deployment of component-based software applications on mobile devices participating in an ad hoc network. CODEWAN implements a peer-to-peer, cooperative model for software deployment. With this model, each mobile device maintains a local repository that can host a number of software components. The components stored in this repository are available for the execution framework that constitutes the upper layer of the platform. Neighboring devices can also exchange copies of the software components they own based on a peer-to-peer interaction scheme. A deployment manager is responsible for maintaining the local repository on a device, for interacting with peer deployment managers that run on neighbor devices, and for collecting software components in order to satisfy the requests of the owner of the local device.

The CODEWAN platform was implemented in Java and is now fully operational. It currently interfaces with the execution frameworks JAMUS and JULIA, and it thus supports the deployment and the execution of untrusted Java applications [START_REF] Le | JAMUS: Java Accommodation of Mobile Untrusted Software[END_REF], as well as that of applications designed using the Fractal component model [START_REF] Bruneton | An Open Component Model and Its Support in Java[END_REF]. CODEWAN should also be able to support the deployment of OSGi bundles in the near future, using the service-oriented framework OSCAR [START_REF] Hall | An OSGi Implementation and Experience Report[END_REF].

Ongoing work implies using this platform in realistic conditions in order to assess its efficiency, and in order to compare the results obtained with alternative deployment scenarios. Future work should aim at augmenting the platform's functionality, for example by integrating support for digitally signed and encrypted software components.

Fig. 1 .

 1 Fig. 1. Illustration of software component deployment in an infrastructure network

Fig. 2 .

 2 Fig. 2. Illustration of software component deployment in a dynamic ad hoc network

Fig. 3 .

 3 Fig. 3. Overview of the CODEWAN platform and screenshot of its GUI on a PDA

Fig. 4 .

 4 Fig. 4. Example of an XML transfer document carrying a software package descriptor.

Acknowledgements

This work is supported by the "Conseil Régional de Bretagne" under contract B/1042/2002/012/MASC.


Hervé Roussain
email: herve.roussain@univ-ubs.fr

Nicolas Le Sommer
email: nicolas.le-sommer@univ-ubs.fr

Frédéric Guidec
email: frederic.guidec@univ-ubs.fr

Towards an Asynchronous Dissemination and a Safe Deployment of Lightweight Programs in Mobile Networks *

This paper presents the design and the implementation of a platform allowing owners of mobile devices to exchange software application programs using a peer-to-peer scheme in hybrid networks as well as in pure dynamic networks, such as those composed of volatile communicating devices (e.g. PDA, laptops). This platform provides means to disseminate announcements or discovery requests of application programs in networks, thus permitting owners of mobile devices to announce to their neighbours what applications they can provide, while discovering themselves what applications are available in their neighbourhood.

Introduction

Nowadays we observe an increasing proliferation of mobile devices (e.g. personal digital assistants, laptops) equipped with wireless communication interfaces (e.g. IEEE 802.11). The prospect of using these devices to provide people with ubiquitous application services appears as an attractive one. In mobile networks, especially in ad hoc networks, devices can be highly mobile and volatile because the owners of these devices themselves move quite a lot, and because these mobile devices usually have a limited power-budget and their owners tend to activate and disactivate them frequently. Moreover, the wireless interfaces of these devices have a limited transmission range. For the owners of mobiles devices it is thus difficult to have a permanent access to services provided by infrastructure networks. In order to provide people with a better access to services, application programs providing all (or a part of) these services are traditionally deployed on the own devices of people. However, in mobile network the client/server deployment scheme -that is commonly use in infrastructure network-is thus hardly applicable in wireless mobile net-works, since no device are stable and reachable enough to act as servers of application programs in these networks.

In this paper, we present the design and the implementation of the JASON (Java Ad hoc Services on ad hOc Networks) platform with which we investigate the deployment of application programs on wireless ad hoc networks. This platform allows owners of mobile devices to exchange software application programs dynamically in hybrid networks as well as in pure dynamic networks, such as those composed of volatile communicating devices. Seen from this point of view, it provides means to disseminate announcements or discovery requests of application programs in networks, thus permitting owners of mobile devices to announce to their neighbours what applications they can provide, while discovering themselves what applications are available in their neighbourhood. The JASON platform also offers functionalities to download the desired programs from remote devices, and provides a deployment environment supporting dynamic resource access contracting and dynamic application monitoring in order to run the programs thus obtained in a secure manner.

In the remainder of this paper we present briefly the different functionalities of the JASON platform, that is, a mechanism that supports the dissemination, the discovery and the delivery of software application, and a secure environment for the deployment of downloaded applications.

Overview of the JASON platform

Our platform allows the owners of mobile devices to exchange application programs, and to run the programs they thus obtain in a secure manner. The general architecture of the JASON platform is organised in three main elements : the graphical user interface, that is shown in figure 1, the context-aware and collaborative deployment manager, and the secure runtime environment.

Context-aware collaborative software deployment

In JASON, the discovery and the announcement of application programs relies on the dissemination of descriptors. A software package descriptor provides information about its identity, its content, its dependencies regarding other packages, etc. When the owner of a mobile device initiates the deployment of a given application, the deployment manager uses the dependencies described by the descriptor of the application to discover what packages are needed for that application, and decide which packages need to be obtained -if possible-from neighbouring devices.

Descriptors also include information about the resources required by application programs for running. This kind of information is meant to help deploy application programs in ad hoc networks including mobile devices with different hardware and software characteristics. Indeed, all application programs are not necessarily equivalent regarding resource access conditions: some applications can run perfectly with few resources and without any guarantee about the availability of these resources, whereas other programs require important amounts of resources and guarantees regarding their availability. This resource requirement description can typically be used by the deployment manager in order to evaluate whether a program can be deployed on the mobile device, as well as to monitor the program at runtime so as to check that this program behaves as expected.

When the owner of a mobile device initiates the deployment of an application on its device, the deployment manager examines the dependencies mentioned in the descriptor of this application. Based on this information the deploy-ment manager can decide if the application can be installed immediately (which is possible if all the required packages are already available in the local repository), in which case the installation request is passed directly to the runtime environment of the platform. However, If some packages are missing in the repository, the deployment manager initiates a background process that aims at collecting these packages from neighbouring devices. Since all devices are highly mobile and volatile in the kind of network we consider, the collecting process of missing packages can sometimes be a lengthy one. In order to account for the constraints presented by the network, a number of strategies can be used by the deployment manager. For example, each deployment manager can be configured so as to announce periodically to its neighbours the packages it owns locally. This is done by sending in the network the descriptors of these packages, rather than the packages themselves. When a device receives a such announcement, its deployment manager examines the descriptors contained in this announcement. For each descriptor that matches a desired package, the deployment manager can then send a request to the device that made the announcement, asking that the package mentioned in this descriptor be sent in the network.

Alternatively -or complementarily-to the abovementioned process, a deployment manager that misses some packages can periodically send a request for these packages in the network, thus inviting its neighbours to announceor send directly-packages that match the request. In order to take ad hoc networks characteristics into account, the JASON platform uses the peer-to-peer, asynchronous document dissemination scheme described in [START_REF] Guidec | Asynchronous Document Dissemination in Dynamic Ad Hoc Networks[END_REF].

By combining these two basic scenarios, and by adjusting for example the period for sending announcements and requests in the network; a number of deployment strategies can be devised and implemented. In the current implementation of the JASON platform, the owner of a device is responsible for setting parameters (such as transmission periods) in order to define how the deployment manager should behave. In the future we plan to define heuristics so that each device adjusts automatically to its environment. For example a device may announce spontaneously the packages it owns whenever other devices appear in its neighbourhood.

A secure deployment of programs

Contract-based approach of resource utilisation

In order to be deployed on the JASON platform, the downloaded application programs must contractualise their resource access conditions with the platform. Programs that neglect to do that are either simply rejected or run using a predefined set of resources. This contractualisation process aims a checking whether the resource access requirements exhibit by a program do not violate the resource access policy enforces by the platform, and also aims at working out if these requirements can be satisfied, and thus to decide if the program can be allowed to run. To perform this process, downloaded programs can be designed to define dynamically a contract object using the resource requirement information included in their descriptor, and can be developed to submit this contract to the platform. The platform makes it possible to submit several contracts before subscribing a specific one. In JASON, contract can pertain on qualitative access conditions (i.e. resource access permissions) as well as on quantitative access conditions (i.e. resource quotas).

In the JASON platform, contracts are evaluated by a broker implementing an admission control based on a resource reservation scheme. This admission control provides hosted programs with a certain level of quality of service regarding the availability of the resources that are necessary for their execution. A contract is declared acceptable by the broker if all of its clauses can be satisfied. If the contract can not be satisfied, this resource broker builds a report specifying which clauses are rejected. This report is expected to help the deployed program in the definition of its next contract submissions. When one of the contracts submitted is marked as acceptable, the program can initiate a contract subscription process with the platform. Since the platform may be carrying out several negotiations concurrently with many candidate programs, the status of resources may change between the time a submitted contract is declared acceptable by the resource broker, and the time this contract is subscribed. Consequently, whenever an application program subscribes a contract, the terms of this contract are examined again by the resource broker, if only to check that they are still valid. If so, then the resources for which the candidate program requires availability guarantees are reserved by the resource broker for this program. In JASON, contracts can be renegotiated as and when needed, by negotiating and subscribing amendments. Amendments specify the modifications that must be applied on a contract (addition, deletion, modification of clauses). The principles underlying the negotiation and the subscription of amendments are similar to those of contracts. The contractualisation process implemented in JASON is more detailed in [START_REF] Sommer | A Contract-Based Approach of Resource-Constrained Software Deployment[END_REF].

Monitoring of applications programs

Since programs obtained from mobile devices can be potentially untrusted, every program running on the JA-SON platform is pro-actively monitored in order to check whether it uses resources in accordance with the contract it subscribed with the platform.

The JASON platform provides a specific implementation of a resource monitor for each basic resource type (e.g. CPU, memory, file system, network). Each resource monitor can be configured dynamically. The role of a resource monitor is to supervise the utilisation of the resource -or collection of resources-considered in the directives it received, and to ensure that this utilisation remains in accordance with those directives. When a resource monitor detects a contract violation, it applies a pre-defined sanction. In the current implementation of the platform, several kinds of sanctions are actually applicable to faulty programs. These sanctions range from a simple warning addressed to a faulty program (using an event based model), up to the immediate termination of this program. This monitoring principle is plentifully detailed in [START_REF] Guidec | Towards resource consumption accounting and control in Java: a practical experience[END_REF].

Conclusion and future work

In this article, we have presented a platform called JA-SON which provides owners of mobile devices with means to discover application programs that are offered to them spontaneously by the other members of their network. It also provides them with a secure runtime environment to host application programs they download. The first experiments of spontaneous announcement, discovery and hosting of application programs we have made prove to be relevant and promising. It is our conviction that the development of JASON should be carried on. In this viewpoint, we plan to improve the discovery functionalities implemented in the JASON platform. Moreover, we intend to consider not only announcement and discovery of application programs but more generally of all kinds of documents (e.g. textual documents, images).

Figure 1 .

 1 Figure 1. Screenshots of Jason's GUI.

* This work is supported by the French Conseil Régional de Bretagne under contract B/1042/2002/012/MASC.


Manon Bouvier

Amélie Beaudet

Caroline Fonta

Muriel Mescam

Variation pattern of the imprints of the middle meningeal vessels in extant human endocasts

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Our knowledge of the endocranial vascular system in fossil hominin taxa partly relies on imprints of the middle meningeal artery and emissary veins on the inner surface of the braincase. Comparative analyses of the middle meningeal vessel pattern in Australopithecus and Paranthropus revealed substantial inter-and intra-specific variation [START_REF] Beaudet | The endocast of StW 573 ("Little Foot") and hominin brain evolution[END_REF]. For now, there is no consensus on the physiological implications of the organization of the middle meningeal vessels, even if the thermoregulation hypothesis has been favoured. In this context, the present study aims to characterize the variation pattern of the middle meningeal vessels in extant human endocasts (i.e., replicas of the inner surface of the braincase). This atlas will be used as a comparative platform for interpreting the diachronic and inter-taxic variation of the fossil hominin vascular system.

Material : We investigated a total of 10 extant human individuals from the Pretoria Bone Collection (South Africa); 4 individuals of African ancestry, and 6 of European ancestry, with equal proportions of males and females. The crania were from adults of known age, ranging from 30 to 60 years old. All of the specimens were detailed by X-ray microtomography at a spatial resolution ranging from 99 to 114 µm at the South African Nuclear Corporation in Pelindaba (South Africa) [START_REF] De Jager | Sulcal pattern variation in extant human endocasts[END_REF].

Methods : Vascular imprints were detected using a geometry-based method and manually corrected through a customized script written in MATLAB R2013a [START_REF] Beaudet | The endocast of StW 573 ("Little Foot") and hominin brain evolution[END_REF][START_REF] De Jager | Sulcal pattern variation in extant human endocasts[END_REF]. The detected imprints were first corrected manually by removing the non-vascular features, and then labelled by referring to available atlases and publications documenting variation in the extant human brain. Additionally, we applied the scoring system introduced by Adachi [START_REF] Adachi | Das Arteriensystem der Japaner[END_REF] for characterizing the branching pattern of the middle meningeal vessels. According to this classification, the middle branch can either derivate from the anterior branch (type I), from the posterior branch (type II), or from both (type III) [START_REF] Adachi | Das Arteriensystem der Japaner[END_REF][START_REF] Eisová | Normal craniovascular variation in two modern European adult populations[END_REF]. Besides challenging the use of the branching pattern of the middle meningeal vessels as a potential taxonomic diagnostic feature [START_REF] Bruner | Fractal dimension of the middle meningeal vessels : variation and evolution in Homo erectus, Neanderthals, and modern humans[END_REF], the relatively high degree of intra-specific variability revealed in our study raises critical questions on the significance of such variation in the human brain evolutionary history [START_REF] Adachi | Das Arteriensystem der Japaner[END_REF]. Interpreting those structural differences in the endocranial vascular system in the light of the sulcal variation pattern of the same sample will be of interest for developing physiological hypotheses and investigating the potential coevolution of the brain organization and the vascular network [START_REF] De Jager | Sulcal pattern variation in extant human endocasts[END_REF][START_REF] Adachi | Das Arteriensystem der Japaner[END_REF][START_REF] Eisová | Normal craniovascular variation in two modern European adult populations[END_REF]. Future quantitative analyses of the imprints of the middle meningeal vessels in extant human endocasts, such as fractal dimensions [START_REF] Bruner | Fractal dimension of the middle meningeal vessels : variation and evolution in Homo erectus, Neanderthals, and modern humans[END_REF], will be fundamental for characterizing further the degree of reticulation and organization of the branches.

Our results (Figures 2 and3) are consistent with previous studies on extant humans [4]: Adachi's type I prevails (55%), followed by type II (30%), and, lastly, type III (15%). In most of the specimens (70%), the branching pattern identified in the right and left hemispheres are similar, thus supporting a certain degree of symmetry in the endocranial vascular pattern.

Type I Type II Type III

Female > Male Female > Male Only Males

Left > Right Left=Right Right>Left The differences regarding the branching of the middle branch between left and right hemispheres and between males and females (Table 2) are not statistically significant (Fisher's exact test: p-values of 1 and 0.3141 respectively). Interestingly, within the limits of our sample, specimens showing asymmetry and/or a type III branching pattern are all males.

Figure 1 :Figure 2 :

 12 Figure 1 : Automatic extraction of endocast using Endex (A). Resulting endocast mesh (B). Application of crest line detection algorithm (C).Endocast after cleaning and labelling (D).[START_REF] De Jager | Sulcal pattern variation in extant human endocasts[END_REF]

Figure 3 :

 3 Figure 3 : Proportions of symmetric/asymmetric patterns within the sample (N = 10 specimens).

Table 1 :

 1

Four selected endocasts with labelled middle meningeal vessels impressions. ba= anterior branch; bm= middle branch; bp= posterior branch.

Table 2 :

 2 Proportions

	of

Acknowledgements: We thank L. Bam (Pelindaba), F. de Beer (Pelindaba), J. Hoffman (Pelindaba) and G. Krüger (Pretoria) for access to the collections and X-ray microCT acquisitions. AB is funded by the CoE in Palaeosciences, IFAS, NRF, PAST,Wits.

Manon Bouvier 1 , Amélie Beaudet 2,3,4, Caroline Fonta 1 , Muriel Mescam 1


Beatrice Negulescu

Jérôme Wolfman

Antoine Ruyter

Cécile Autret-Lambert

Salia Cherifi-Hertel

Controlling the magnetoelectric coupling in Ni/BiFe0.95Mn0.05O3 with a dielectric spacer

 Reversible and non-volatile magnetoelectric effect in bismuth ferrite based heterostructure.  Large modulation of the magnetic coercive field by electric field.  Strain-mediated magnetoelectric coupling mechanism.  Control of the depolarizing field by an interleaved dielectric spacer.

Introduction

The electric field control of the magnetic state in multiferroic heterostructures, such as ferromagnetic (FM) / ferroelectric (FE) bilayers, occurs through strain-mediated mechanisms and interface-related effects [1][2][3][4][5][6]. The strain-mediated magnetoelectric (ME) coupling is due to the converse piezoelectric effect and magneto-elastic interactions and may result in a strong electric field control of the magnetic anisotropy [7][8][9][10][11][12]. The interface-related ME coupling mechanisms can typically be either exchangerelated [13][14][15][16], triggered by the ionic mobility at the interface [17][18], or electronically-driven [19][20][21][22]. In spite of the efforts being made to achieve large ME coupling at interfaces [23][24][25][26], the overall coupling strength remains low. Alternatively, strain-mediated coupling involves a large volume fraction of the heterostructure, leading to a greater voltage-driven modulation of the magnetic state.

The strain-related mechanism typically induces a symmetric variation of the magnetization with respect to the applied electric field (i.e., a butterfly-like ME curve) that mimics the strain curve of the FE material [7], [10]. The FE polarization reversal results in the same strain-induced magnetic state at remanence for both the positive and negative voltage branches, which renders this effect unsuitable for non-volatile memory applications. Recent studies have shown that asymmetric polarization curves [27][28] and specific polarization reversal paths related to the FE domain structure [29][30][31][32] provide a possibility to break the symmetry of ME curves in strain coupled heterostructures.

Here we evidence a strain-mediated coupling in Ni/BiFe0.95Mn0.05O3 (BFMO) bilayers by combining magneto-optic and piezoelectric measurements. Interleaving a thin dielectric SrTiO3 (STO) film between Ni and BFMO shed light on the origin of the ME coupling in this system by disregarding direct interface effects. Furthermore, a controlled transition of the ME curve from a rectangular shape hysteresis loop with two non-volatile remanent states to a conventional butterfly-like hysteresis loop is obtained by tuning the thickness of the dielectric spacer. Piezo-response force microscopy (PFM) reveals that the dielectric STO layer modifies the domain structure of the BFMO films. Recent studies have shown that the control of bound charge screening is capable of stabilizing exotic topological structures such as polar vortices [33], skyrmions [34] and bubble domains [35] in FE/ dielectric heterostructures. We consider that the control of the FE state through the depolarizing field can represent a new degree of freedom for tuning the ME coupling in ferromagnetic/ dielectric/ ferroelectric heterostructures.

Materials end methods

Pulsed laser deposition was used to grow BiFe0.95Mn0.05O3 (60 nm)/ La0.8Sr0.2MnO3 (25 nm) epitaxial stack on (110)-oriented GdScO3 substrate. Mn doping of the BiFeO3 structure was used in order to reduce the high leakage currents generally observed in the BiFeO3 thin films [36][37][38]. The deposition conditions were 0.2 mbar oxygen pressure, 700 °C substrate temperature, and 1.72 Jˑcm -2 laser fluence. The films were cooled down at a rate of 3 °C/min in 500 mbar O2 atmosphere after deposition. In one sample a STO wedge was deposited on top of the BFMO film, with thickness varying from 0 to 7 nm, to evaluate the interface contribution to the ME coupling. The STO deposition conditions were 0.03 mbar oxygen pressure, 700 °C substrate temperature and 1.72 Jˑcm -2 laser fluence. 30 nm-thick Ni films were subsequently grown by e-beam evaporation using standard lithography and lift-off process. The magnetic film was capped with 10 nm Au to prevent from oxidation. Two additional samples with 5 nm and 10 nm Ni thicknesses were prepared to study the Ni/BFMO interface contribution to the ME coupling process. The La0.8Sr0.2MnO3 (LSMO) and BFMO films have a single crystalline structure while the Ni layers are polycrystalline. X-ray diffraction measurements and transmission electron microscopy images are provided as supplementary material (see supplementary figure S1). A detailed structural characterization of the heterostructure was presented elsewhere [39].

The magnetic properties were measured using magneto-optic Kerr effect (MOKE) in the longitudinal mode using a NanoMOKE system from Durham Magneto Optics. The Ni top electrodes used for the magnetic measurements have a circular geometry (20 µm diameter) while deported rectangular pads (50x50 µm 2 ) have been used for applying the electric voltage between the Ni film and the LSMO (bottom electrode) using a Keithley 2410 source/measure unit, as schematically represented in Figure 1a. The magnetic anisotropy was investigated after removing the DC bias (i.e., in the remanent FE state), by varying the azimuth angle of the sample with respect to the applied magnetic field. PFM with a commercial scanning probe microscope (Dimension 3100, Bruker) in contact mode was used to image the FE domain structure. The piezoelectric properties of the BFMO films were analyzed by double beam laser scanning vibrometry (LSV) using a MSA 500 laser Doppler vibrometer equipped with a VD-06 high precision velocity decoder from Polytech. The vibrometry method use an interferometric optical detection of the conversed piezoelectric effect generated by an AC voltage (0.5 V at 10 kHz for these measurements). The vertical displacement detected by the LSV is therefore proportional to the polarization. By means of a DC bias in parallel with the AC excitation signal, the FE polarization can be modulated. d33(VDC) loops obtained by LSV measurements were used to characterize the polarization reversal of the BFMO film, where the d33 piezoelectric tensor element values were calculated as the vertical displacement amplitude divided by the AC excitation amplitude. These loops are similar to the amplitude-voltage curves obtained by PFM measurements, with the main difference that PFM probes the kinetics of nanoscale domain switching, while LSV describes the FE switching averaged over the entire electrode area.

Results and discussions

Figure 1b displays the magnetic hysteresis loops measured in the as deposited state and after poling the system at 6 V (corresponding to an electric field of 1000 kV/cm). The electric remanent states of the heterostructure are referred to as positively or negatively poled state, depending on the sign of the applied voltage. A small coercive field Hc = 20 Oe is observed in the as-grown virgin state. The coercivity drastically increases to 120 Oe upon positive poling (500 % variation) and it remains unchanged after the voltage is switched-off. The negative poling reduces the coercivity to about 40 Oe, which is higher than the initial value, but represents 200 % variation with respect to the positively poled state. Small variations of the saturation magnetization (Ms) upon poling are also observed (see MOKE signal intensity in Figure 1b). These results are characteristic of a strong ME coupling in Ni/BFMO bilayers, in agreement with our previously reported results [40]. The magnetic anisotropy variation with the electric field was investigated by measuring the in-plane angular dependence of the magnetization curves for different poling states. The polar plots of the coercive field and of the normalized remanent magnetization (Mr/Ms) derived from these measurements are presented in Figure 1c andd, respectively. Unpoled bilayers exhibit a small uniaxial anisotropy (see elongated lobes in Figure 1c,d) that is lost at positive poling and recovered at negative poling.

To understand the role of interface effects on the studied ME coupling, we interleaved a dielectric STO spacer with variable thicknesses between Ni and BFMO layers. The magnetic coercivity modulation between the positively and the negatively poled states, Hc, is used in Figure 2 to analyze the influence of the STO spacer thickness on the ME effect. For the thinner part of the spacer, a linear decrease of Hc is observed as the STO thickness increases up to a threshold value of about 4 nm. Above 4 nm STO, the coercivity difference between the two poled states vanishes. It is worth mentioning that the coercivity in the as deposited state is independent of the STO thickness and that positive poling results in an increased coercivity in the whole STO thickness range (results presented in supplementary Figure S2).

The ME coupling and its origin is further investigated in the following by comparing the effect of the voltage cycling on the magnetic properties (Hc and Ms) to the piezoelectric response of Ni/STO/BFMO heterostructures (Figure 3). We observe a gradual change of the ME curves shape from a rectangular hysteresis loop to a butterfly-like loop, depending on the thickness of the STO spacer (see Figure 3a,b). In the absence of the STO spacer, the ME curves show a pure rectangular hysteresis shape, with two distinct remanent Hc and Ms values. Typical butterfly-like curves are obtained when 5.5 nm thick STO is interleaved. In this case, equivalent remanent Hc and Ms values are found for positive and negative voltage branches. At an intermediate STO spacer thickness of 2 nm, the ME curves present mixed rectangular and butterfly shapes, with two different remanent magnetic states.

Close similarity is observed between the magnetic Hc(V) and Ms(V) curves and the piezoelectric d33(V) response (presented in Figure 3c). The heterostructure without STO spacer is characterized by a sharp decrease of the piezoelectric response to zero in both positive and negative branches, associated to the FE polarization reversal. The bias voltage at which the BFMO polarization is reversed clearly corresponds to the transition between the high and low Hc (Ms) states presented in Figure 3a(b). However, some features of the d33(V) curve are difficult to explain just considering a typical FE polarization reversal process, such as the large increase of the d33 value when the DC voltage is reduced from +6 V (11 pm/V) to 0 V (25 pm/V). A large asymmetry can also be observed between the two branches of the d33(V) curve, showing two different piezoelectric remanent states. In fact, two distinct contributions have to be considered in the piezoelectric response of a FE material. One is related to the intrinsic piezoelectric effect (i.e. due to the lattice deformation) and the second one, also known as extrinsic response, is induced by the domain wall (DW) motion [41]. The large asymmetry observed between the two branches of the d33(V) curve indicates different strain states in the BFMO film that may result from dissimilar FE domain structures (i.e. difference between the DWs type and/or density). This asymmetry is likely at the origin of the rectangular shape ME response.

In the case of a 5.5 nm STO spacer, a conventional butterfly-like d33 loop shape is obtained, which is the typical strain response to electric field of a FE system. The butterfly-like shape of the ME response in the case of thick STO spacer (Figure 3a,b) reflects thus the d33 loop shape, as expected for a strainmediated coupling mechanism [7], [10], [42], [43]. At intermediate STO thicknesses (e.g., 2 nm), the d33 loop deviates from the butterfly-like shape and shows a gradual FE switching as d33 goes to zero and recovers slowly with the applied bias. This gradual FE switching affects the corresponding Hc and Ms loops that show a mixed butterfly and rectangular hysteresis shape. In conclusion, our results show a clear correlation between the piezoelectric and the ME responses, indicating the presence of strainmediated effect in the studied system.

Although the STO spacer revealed the effects of strain-mediated coupling, we need to consider the possibility of additional coupling mechanisms in the case of Ni/BFMO bilayers (i.e., without STO spacer). Besides, the STO thickness induced change of the ME curve shape from butterfly to rectangular could also suggest the coexistence of several coupling mechanisms [43]. Electronically driven charge effect can be discarded in the studied system, because the thickness of the Ni film (30 nm) is much larger than the Thomas-Fermi screening length (less than 1 nm). Previous reported X-ray photoemission spectroscopy and electron energy-loss spectroscopy analysis of the Ni/ BFMO interface did not reveal any electric field dependent redox effect in this system [39]. Therefore, ionic mobility under electric field can be excluded in the Ni/ BFMO bilayers. Furthermore, the investigation of the FM thickness influence on the ME coupling didn't show a monotonic variation of the ME properties as a function of the Ni thickness (see Supplementary Figure S3), as expected in interface-mediated coupling mechanisms such as exchange coupling [44]. We should mention here that exchange bias is not expected in the Ni/BFMO system as the Ni film is not deposited under magnetic field. Exchange coupling should therefore manifest through an increase of the Hc values, as observed in several other BFO based systems [15][16]. The magnetic coercivity modulation between the positively and the negatively poled states is not sensitive to the thickness of the Ni film, which does not sustain an exchange coupling origin of the studied ME effect. Moreover, in view of the rather thick Ni film used in this study, we consider that exchange coupling effect can be ignored in Ni (30 nm)/ BFMO bilayers. In summary, interface-related ME coupling mechanisms can be ruled out, which leaves strain transfer as the predominant ME coupling mechanism in the studied system.

The ME effect in strain-coupled structures generally modifies the magnetic anisotropy [8][9][10][11][12]. In the Ni/BFMO bilayers the ME coupling results in a huge variation of Hc. The coercive field is not a direct measurement of the magnetic anisotropy but characterizes the reversed magnetic domain nucleation process, as well as the motion of the magnetic DWs during the magnetization reversal. The strong variation of Hc with the applied voltage observed in the Ni/BFMO bilayers may thus result from a modification of the magnetic DWs pinning sites. This effect can be induced by local strains developed in the BFMO film after the FE switching. Three polarization switching paths have been reported in rhombohedral perovskite materials such as BFMO, namely 71°, 109°, and 180°. Only the 109° switching events create in plane distortions along the [110] and the [-110], which could locally modify the strain in the Ni film [29][30], [32].

Let us now discuss the possible microscopic origin of the transition from rectangular shape to butterflylike shape of the piezoelectric loops with the thickness of the dielectric spacer. The dielectric STO spacer may strongly affect both the FE domain configuration and the polarization switching process, as already reported in PbTiO3/ STO [45][46], Pb(Zr0.2Ti0.8)O3/ STO [47], and BiFeO3/ LaBiFeO3 [48] heterostructures. PFM was used to investigate the FE domain structure of the BFMO films with and without STO capping. Bare BFMO films do not show any contrast in the vertical PFM images, indicating a single polarization orientation respectively to the out of plane direction. During the PFM measurements the reversal of the BFMO polarization was achieved by applying a positive voltage on the tip (see supplementary Figure S4), which means that the polarization of the as deposited film is oriented towards the LSMO electrode. A multi-domain structure with up and down polarization is observed in STO capped BFMO films (see Figure 4). The transformation of the FE domain structure is controlled by the STO layer through the surface charge screening of the polarization (i.e., via the control of the depolarizing field). Different polarization reversal routes and piezoelectric characteristics are therefore expected, depending on the STO spacer thickness.

In order to understand how the FE domain configuration influences the shape of the ME loops, we should first note that the Ni film is unstrained in the as deposited state, independently of the BFMO domain structure (see figure S3 for the Hc variation with the STO thickness). The unstrained Ni film is characterized by a low Hc value of about 20 Oe. Without STO spacer, this initial state corresponds to a polarization orientation towards the LSMO bottom electrode. In positive bias the polarization reversal is associated with a certain amount of 109° switching events that generate local strained regions in the Ni film. Consequently, the magnetic coercive field increases to about 120 Oe (see figure 3a). The polarization reversal in negative bias brings the FE domain structure close to the initial one, thus reducing the strain state in the BFMO and Ni films. As a result, Hc decreases to 40 Oe. This behavior suppose that the initial FE domain structure is energetically favorable so that it is recovered after a switching cycle. Asymmetric FE states between the positive and the negative poling have been already reported for BFO thin films [49,50] and were associated to the existence of interfacial defects acting as pinning centers for the as deposited FE domains.

With a STO top layer, the polarization of the as-grown FE film is oriented both upward and downward. This FE domain structure corresponds to a low strain state for Ni in the as-deposited Ni/STO/BFMO trilayer. When a positive voltage is applied, only the FE regions oriented toward the LSMO electrode are reversed. Consequently, the amount of 109° switching events is smaller than in the case of the structure without STO spacer and a reduced strain is transferred to the Ni film. As a result of this FE switching process Hc increases to about 70 Oe for the structure with 5.5nm thick STO spacer, value that is lower than the one observed in the Ni/BFMO bilayers (see figure 3a). When the positive bias is decreased to zero, the initial FE multi-domain structure is gradually recovered thus the strain and, correspondingly, the Hc value are reduced. The reversal of the polarization toward the LSMO electrode in negative bias now switches the FE domains that were initially oriented upward. In consequence, the strain increases in the Ni film inducing an increased value of Hc. In this FE switching process, similar strain states are expected in positive and negative bias, thus inducing symmetric ME curves.

Let us now discuss the effect of the electric field on the magnetic anisotropy. The as deposited Ni film shows a small uniaxial anisotropy with the magnetic easy axis oriented along the [100] direction (see Figure 1c,d). In positive bias, the FE polarization reversal generates local in plane distortions along the [110] and the [-110] directions. Transferred to the adjacent Ni film, this strain should locally induce the magnetic easy axis reorientation. The lateral dimension of this strained regions correspond to that of the FE domains, which is on the order of 100 nm (see supplementary figure S4). In comparison, the MOKE is sensitive to a large area of the Ni film (laser spot focused at 5 µm). The magnetic response is therefore averaged over a large number of unstrained and locally strained regions, with different easy axis directions. This could explain the isotropic-like Mr/Ms and Hc polar plots observed in the positive poled state.

Conclusions

In summary, a non-volatile strain-mediated ME coupling was demonstrated in Ni/ BFMO bilayers. Interface-mediated coupling can be ruled out in this system and the non-volatility of the ME effect is correlated to bistable remanent strain state in BFMO. Interleaving a dielectric STO spacer between Ni and BFMO modifies the ferroelectric properties through the depolarizing field modulation. This directly impacts the piezoelectric curves and the related ME response. The thickness of the STO spacer controls the polarization charges screening and therefore tunes both the piezoelectric and the ME curves from the usual butterfly-like response to a rectangular shape loop with two non-volatile memory states. This result proves that the control of the ferroelectric properties through the depolarizing field is a promising route to fine-tune ME memory states in artificial multiferroics.

Figures caption

Figure 1 :

 1 Figure 1: a) Schematic representation of the ME device. b) Ni(30 nm)/ BFMO(60 nm) magnetic hysteresis loops measured in the as deposited state (blue triangles), in the positively poled state obtained by applying +6 V (black circles) and in the negatively poled state induced by -6 V (red squares). Polar plots of Hc (c) and Mr/Ms (d) presented for the three different electric states described in (b).

Figure 2 :

 2 Figure 2: Variation of the Hc difference between the positively and the negatively poled states in Ni(30 nm)/ STO/ BFMO(60 nm) heterostructures as a function of the STO spacer thickness. Lines are linear fits. The Hc value measured in Ni(30 nm)/ BFMO(60 nm) bilayer is also presented (star symbol).

Figure 3 :

 3 Figure 3: a) Hc (black circles), b) Ms normalized to the Ms value at +6 V (blue rectangles) and c) d33 (green triangles) variations with the DC voltage for three different STO spacer thicknesses: 0 nm, 2 nm, and 5.5 nm.

Figure 4 :

 4 Figure 4: Atomic Force Microscopy image showing the topography (a) and PFM images showing the out-of-plane amplitude contrast (b) and the out-of-plane phase contrast (c) in BFMO film with a STO top layer.

  Figure 1

Figure 4

 4 Figure 2

Acknowledgments

This work was funded by Région Centre in the frame of the project Comhet.

Data statement

The data used in this article are available from the corresponding author upon reasonable request.

Supplementary material

See supplementary material for further detailed structural and magnetoelectric characterization of the studied system.

Declaration of interests

☒ The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

☐The authors declare the following financial interests/personal relationships which may be considered as potential competing interests: