Ching Hsueh

Frédéric Doumenc

Béatrice Guerrier

Numerical Simulation of Complex Fluid Drying in a Hele-Shaw Cell

A 2D model is currently under development to describe the flow and concentration fields inside a Hele-Shaw cell with evaporation for a receding meniscus (dip-coating-like configuration). An original approach is proposed to address the difficult problem of the boundary conditions close to the contact line. The model is used to study the deposit thickness as a function of some process parameters.

Introduction

Dip-coating is a widely used industrial coating process, with complex coupling between hydrodynamics, mass transfer and evaporation, especially close to the contact line. Through various experimental and theoretical studies, it is now well established that different regimes appear depending on the Capillary number Ca ≡ µV /γ (µ being the dynamic viscosity, V the substrate velocity, and γ the surface tension) [1][2][3][4][5][6]. At small Capillary number, viscous forces are strong enough to drag a liquid film whose thickness increases as V 2/3 (classical Landau-Levich regime). For even smaller Capillary numbers, another regime dominated by evaporation at the meniscus is encountered, characterized by a deposit thickness proportional to V -1 . Our objective is to build a hydrodynamic model of a dip-coating-like experiment (see reference [4]), in order to investigate the relation between the flow and the concentration field in the meniscus on one hand, and the deposit thickness on the other hand. In the present study which is a first step towards a more complete model of the process, we only take into account the flow driven by the substrate movement and the solvent evaporation. The free convection induced by buoyancy and/or Marangoni effect, which has been observed in the experiments, is temporarily disregarded. We focus on the difficult problem of the boundary conditions close to the contact line. An original approach based on lubrication approximation is presented, which avoids addressing stress and evaporative flux singularities, but still allows the prediction of the deposit thickness. This model may be viewed as the definition of the basic state for a future study of hydrodynamic instabilities in dip-coating processes.

a e-mail: frederic.doumenc@upmc.fr 2 Model

Geometry and assumptions

The model is based on experiments performed in a dip-coating-like set-up [4]. The device is made of two parallel glass plates separated by a gap d which are vertically immersed in a reservoir filled with a solution of solute volume fraction φ p0 . Once the plates are immersed in the solution, there is a spontaneous capillary rise in the Hele-Shaw cell. The reservoir is then emptied at a constant pumping rate so that the position of the contact line decreases at velocity V . In our model, we consider the reverse equivalent configuration, i.e. the wall is moving upward with velocity V , while the meniscus is fixed. The mean evaporation velocity on the meniscus, v ev , is controlled by a vertical air flow blown between the two glass plates, at a given temperature and humidity. A 2D domain is used to simulate the experimental setup (figure 1). The total height H is large enough to get a fully developed flow at the bottom. The meniscus is assumed circular with radius R. Indeed, deformation induced by substrate motion or evaporation is located in the vicinity of the tip which is truncated in our model (cf. description below). For the complete wetting configuration considered in this study, R = d/2 = 0.5mm.

In the first step presented here, several simplifying assumptions have been made. Buoyancy, Marangoni effect and inertia are neglected. The solution density ρ is a constant (same specific partial volume for the solvent and solute, so that the solvent (or the solute) mass and volume fractions are identical). The problem is isothermal. To capture the basic characteristics of the local evaporation rate, i.e. a strong increase at the meniscus tip [6], the following expression is used: j(m/s) = J 0 / D tip , where D tip = H -y is the distance to the tip of the contact line along the vertical axis. Note that this expression for the local evaporation rate is an approximation valid at the tip vicinity of the relation first suggested by Deegan et al. [7] for a sessile droplet. In this work, it is extended to the entire free surface, as a first step. J 0 (m 3/2 s -1 ) is a constant deduced from the experimental value of v ev (m/s) 1 . v ev is obtained from preliminary experiments with pure water [4]. The dependence of the evaporation flux on the solute concentration is neglected.

Since the evaporation rate diverges at the tip, we define the truncated region shown in figure 1 by cutting off a small tip region whose height is α and width is δ. The flow is assumed to be incompressible and the fluid to be Newtonian. Under these assumptions mass conservation and Stokes equations read in vector form:

∇ • v = 0, -∇P + ∇ • (µ∇v + µ∇ t v) = 0, (1)
where v = ui + vj is the velocity field, µ is the viscosity (assumed constant in the following) and P is the pressure. The mass balance for the solute reads:

v • ∇φ p = D∇ 2 φ p , (2)
where φ p is the volume fraction of solute and D is the binary diffusion coefficient.

Boundary conditions

We assume no slip and impermeable boundary conditions at Boundary 1 and symmetry conditions at Boundary 3 (see figure 1). At y = 0 (Boundary 2) we consider a

1 vev = 1 R πR/2 0 J 0 √ H-y ds = J0 H H-R dy √ (H-y)(R-H+y)(R+H-y)
with ds being an element of the free surface. fully developed flow. The concentration is assumed to be the bulk concentration φ p0 for the inflow, and diffusion is neglected for the outflow:

u = 0, ∂v ∂y = 0, (3)
v • j > 0 =⇒ φ p = φ p0 (inflow), v • j < 0 =⇒ ∂φ p ∂y = 0 (outflow). (4)
Along the meniscus (Boundary 4), a first equation is the stress-free condition. Other equations are related to the evaporation flux (with a volatile solvent and a non-volatile solute). With the assumption of a constant density for the solution we obtain

∂u t ∂n + ∂u n ∂t = 0, J p • n = 0, u n = j, j = J 0 √ H -y , (5)
where v = u n n + u t t, t and n are the tangential and normal unit vectors along the meniscus, respectively. J p is the solute mass flux2 . The last boundary (Boundary 5 at y = H -α) is the most intricate. We truncate the meniscus at a small distance α from the contact line. The resulting boundary has a width δ (see figure 1). In this region the flow is quasi-parallel to the moving wall (small slope approximation) and the lubrication approximation applies. Moreover, δ is assumed small enough to neglect the variation of the solute volume fraction along the boundary. The simplified Stokes equations read

∂P ∂x = 0, ∂P ∂y = µ ∂ 2 v ∂x 2 . ( 6
)
Using the no-slip condition at x = 0, the zero shear stress condition at x = δ, and with Vtip the mean velocity y-component along the boundary B5 ( Vtip = 1/δ δ 0 v(x, y)dx), integration of the above equation leads to

v(x, y) = 3 δ ( Vtip -V )x(1 - x 2δ ) + V. (7)
Considering Eq. ( 1) and the local mass balance (with the assumption of a constant density ρ for the solution), we obtain

u(x, y) = [ Vtip dδ dy (3δ -2x) + V dδ dy (2x -3δ) + δ d Vtip dy (x -3δ)] x 2 2δ 3 (8) with δ(y) = (H -y) 2 2R , dδ dy = y -H R , d Vtip dy = - 1 δ j(y) + Vtip dδ dy . (9)
Equations ( 7) and (8) estimated at y = H -α yield the hydrodynamic boundary conditions. Finally, assuming that B5 is an outlet (v • j ≥ 0 over the whole boundary), we impose ∂φ p /∂y = 0 for the concentration field. This approximation is expected to induce an error only in a small region over a length of order D Vtip close to the boundary.

The value Vtip is unknown and is obtained by successive trials in the following way. For a given value of Vtip , the above model is used to obtain the concentration field in the entire computational domain and in particular, on the boundary B5. We first check that the concentration is nearly uniform on B5 (variations are typically less than 1%) and calculate φp , the average volume fraction of the solute along B5 boundary. Then a test on the solvent mass balance in the truncated part of the tip is performed. Assuming total drying in the tip (there is no more solvent for y > H), the solvent mass balance in the truncated tip reads

Vtip (1 -φp )δ = H H-α J 0 √ H -y dy = 2J 0 √ α. (10)
If the relative error is larger than about 1%, a new value of Vtip is tried. COMSOL software is used to solve the above equations. Preliminary tests were performed to determine the domain size consistent with the assumptions used in the model. For the following results, H = 5mm, α = 50µm, δ = 2.5µm and the viscosity and the diffusion coefficient are µ = 10 -3 P a.s and D = 2.10 -10 m 2 s -1 .

The thickness of the dried film is obtained from the numerical results by solving the solute mass balance in the truncated part. We assume that the deposit moves at the substrate velocity V . In the truncated region, the solute flux across boundary 5 (cross section δ) is given by the product φp Vtip δ, and the deposit flux on the moving substrate is equal to φ c V h d , where φ c is the compaction volume fraction of the deposit. For simplicity, we assume a completely dry deposit and φ c 1 which results in the expression

h d = φp Vtip δ V . ( 11
)
3 Results

Flow field and concentration distribution

Figure 2 shows the general behavior of the concentration and flow fields corresponding to the conditions V = 5µm/s, v ev = 0.78µm/s, φ p0 = 8%. The figure on the left is a zoom in the upper part of the domain near the meniscus free surface. The figure on the right is a zoom in the bottom part of the domain where fully developed flow is observed, as expected. For this configuration, we obtain at the boundary B5 Vtip = 51.6µm/s and φp = 26%. As can be seen, a small downward flow is observed in the bulk. We notice that it becomes more important for a larger substrate velocity V . It is only for lower velocities that the flow induced by evaporation overcomes that induced by the substrate movement, so that no downward flow is observed (not shown).

Dry thickness: comparison with a simplified model

As already said in the introduction, this model is a first step and takes into account the substrate motion and evaporation flux only. In the framework of these assumptions, it is interesting to analyze the effect of the downward flow on the deposit thickness at a high substrate velocity. To do so, the deposit thickness is compared to a simple model first proposed by Dimitrov and Nagayama [1] and based on global mass balances. This model assumes a uniform concentration in the cross section L y (y = constant). The total flux going through L y is then either evaporating through the meniscus (solvent) or depositing on the substrate at the tip part (solute). We then obtain (see [1,4] for more details)

h d d 2 v ev φ p0 V (12)
Figure 3 shows the ratio of the thicknesses obtained with numerical simulation to the thickness calculated with the simplified model (estimated with L y = B2), for different evaporation rates and solute concentrations. h d /h d is close to 1 at low velocities, but significantly decreases at velocities larger than 10µm/s. As already mentioned, Eq. 12 assumes a uniform solute volume fraction when computing the solute flux across the bottom boundary B2. The effect of this approximation on the estimation of the solute flux is small at V = 10µm/s (8%), while it is much larger at V = 100µm/s (138%), and thus the Dimitrov and Nagayama's model does not apply anymore. Indeed, in the case V = 100µm/s, the simulation shows a significant downward flow at a solute concentration higher than the bulk one which means that a significant volume of solute is carried back to the reservoir. Indeed the length needed to homogenize the concentration through diffusion across the cell is much larger than the total height of the Hele-Shaw cell. However, available experimental data obtained with a dip-coating-like set-up [3][4][5] do not show this departure from the Dimitrov and Nagayama's model. Several assumptions may be put forward to explain the discrepancy between the experiments and the above simulations. First, it could be due to an insufficient resolution in deposit thickness measurements. Second, this phenomenon takes place at rather high velocities, close to the transition between the evaporative regime and the Landau-Levich regime, and could be overridden by the resulting increase of the thickness. Finally, we also can expect that convection induced by density or surface tension gradients, observed in some experiments but not taken into account in the model, could improve the mixing and thus modify the concentration field, with an impact on the deposit thickness.

Conclusion

We proposed a hydrodynamic model of a receding and evaporating meniscus in a dip-coating-like experiment. The difficulties arising from the presence of a contact line are avoided by truncating a small region close to the contact line. The resulting boundary conditions are written using lubrication approximation and mass balances on the truncated domain. In the first step presented in this study, the substrate motion and evaporation are taken into account but buoyancy and Marangoni effect are disregarded. In the framework of these assumptions, large substrate velocities induce a downward flow that caries the solute back to the reservoir. As experimental results do not confirm this result, further investigations are needed to study how hydrodynamic instabilities may modify the concentration field. In a future work, this model will be used as the basic state for a study of the hydrodynamic instabilities in a dip-coating process.

Fig. 1 .

 1 Fig. 1. Sketch of the numerical domain and boundary conditions.

Fig. 2 .

 2 Fig. 2. Numerical results corresponding to V = 5µm/s, vev = 0.78µm/s, φp0 = 8%. Left: an upper part of the domain (4mm < y < 5mm). Right: a lower part of the domain (0mm < y < 1mm) with a fully developed flow. Grey levels (color levels online) show the solute volume fraction (0.08 for dark grey at the bottom of the domain (dark blue color online), 0.15 for light grey (yellow color online)). The streamlines and the arrows correspond to the velocity field (u, v).

Fig. 3 .

 3 Fig. 3. The ratio of the deposit thicknesses obtained with the 2D model and the simplified model (Eq. (12)).

with the assumption of a constant solution density, Jp = Φpρv -ρD∇Φp


Antoine Omond
email: antoine.s.omond@uit.no

Issam Rais
email: issam.rais@uit.no

Hélène Coullon
email: helene.coullon@imt-atlantique.fr

Evaluating the energy consumption of adaptation tasks for a CPS in the Arctic Tundra

Keywords: CPS, Deployment, Update, Coordination, Tundra, Energy Consumption

Cyber-Physical Systems deployed in scarce resource environments like the Arctic Tundra (AT) face extreme conditions. Nodes deployed in such environments have to carefully manage a limited energy budget, forcing them to alternate long sleeping and brief uptime periods. During uptimes, nodes can collaborate for data exchanges or computations by providing services to other nodes. Deploying or updating such services on nodes requires coordination to prevent failures (e.g., sending new/updated API, waiting for service activation/deactivation, etc.). In a CPS with short uptime periods, such coordination can be energy-consuming due to low opportunities for communications.

This paper evaluates and studies nodes' energy consumption during deploy or update tasks coordination according to different CPS configurations (i.e., number of nodes, uptime duration, radio technology, or relay node availability). Results show high energy consumption in scenarios where nodes wake up specifically to deploy/update. It is shown that it is beneficial to do adaptation tasks while overlapping with existing uptimes (i.e., reserved for observation activities). This paper also evaluates and studies how nodes' uptime duration and relay node availability influence energy consumption. Increasing uptime duration can reduce energy consumption, up to 12%. Using an available relay node for communication reduces the energy consumption by 47% to 99%.

I. INTRODUCTION

The Arctic Tundra (AT) is one of the most sensitive environments to climate change. Presently, much less than 1% of the AT is monitored. Therefore, to accurately study the impact of climate change on the AT, larger observations are needed.

The AT is a very large, hard-to-reach, and potentially dangerous ecosystem. The Distributed Arctic Observatory (DAO) 1 project proposes an observatory CPS mainly composed of Observation Nodes (ON) deployed in the AT. ONs are small devices monitoring the environment through physical instruments (e.g., sensors) and running small computations. ONs can also 1 https://site.uit.no/dao/ collaborate for observations when located close to each other through local or temporary network connections.

The AT environment imposes extreme constraints on ONs, notably due to its lack of infrastructure (e.g., power grid, network, and roads to physically access the area). ONs are most of the time isolated. Due to harsh weather and the absence of eligible harvesting mechanisms, providing a regular energy supply is not possible. Thus, ONs are on a limited energy budget, forcing them to sleep most of the time to extend their lifetimes. Each ON has its own uptime schedule and wake-up for activity for very short periods. Uptime schedules are not synchronized and rarely overlap, leaving few opportunities for communication.

In the DAO-CPS, ONs collaborate for observations by providing services to other ONs (e.g., analysis, data aggregation). During their lifetimes, ONs have to adapt their service configurations (e.g., deploying new services, updating existing ones) from scientists' requests, or from external events happening in the CPS or in the AT. Due to ONs relying on these services, coordination is required to prevent failures. However, in most cases, ONs cannot rely on a central authority to handle the coordination. Due to scarce connectivity between ONs, such coordination can be energyconsuming as coordination can take a long time to converge.

In the DAO, few CPS configurations may influence the coordination's energy consumption. ONs uptime duration, while being short, may vary [START_REF] Rais | Impact of loosely coupled data dissemination policies for resource challenged environments[END_REF]. Uptimes with a longer duration lead to potential larger overlaps between ONs, thus faster coordination. However, longer uptimes can also lead to larger energy consumption, leading to a trade-off. Few nodes in the DAO-CPS have larger energy budget than ONs. These nodes, called Relay Node (RN), could be leveraged to be synchronized with ONs from a specific neighborhood, to ease communications.

Considering non-synchronized sleeping ONs trying to deploy/update services, the contributions of the paper are an evaluation and a study of:

' the impact of ONs uptime duration on the energy consumption; ' the impact on energy consumption of using an available RN for communications; ' the energy consumed by communication for coordination when using two different radio technologies, LoRa or NB-IoT; The paper is structured as follows: Section II presents a description of the use-case, Section III describes the experimental setup, Section IV presents and discusses results, Section V presents the related work, and finally Section VI concludes this paper.

II. USE-CASE DESCRIPTION

Figure 1 is an overview of the DAO-CPS. ONs are equipped with small single-board computers (e.g, Raspberry Pi), network capabilities (e.g., LPWAN radio technologies such as LoRa or NB-IoT), and sensors (e.g optical and proximity cameras, temperature) [START_REF] Raïs | Trading data size and CNN confidence score for energy efficient CPS node communications[END_REF]. This allows advanced capabilities on ONs like computing, collaboration, and service deploy/update. While ONs are responsible for observations and computations, RNs are notably used to help ONs communicate. RNs are also under a limited energy budget but equipped with more powerful batteries, making them more likely to be reachable by ONs. However, realistically such nodes might not have a full availability or be present in all neighborhoods. This paper makes the most favorable assumption by having an available and reachable RN by all ONs in the studied neighborhood.

Our use-case is inspired by an existing CPS deployment in the AT [START_REF] Raïs | Trading data size and CNN confidence score for energy efficient CPS node communications[END_REF]. Our use-case considers n ONs hosting measurement services, sending observations to an ON hosting an aggregation service. The aggregation ON needs outputs from all measurement ONs to be functional. Thus, whenever changes happen either in the aggregation ON or measurement ONs (e.g., type of measurement changed, service has been interrupted), ONs need to share data and coordinate their changes. Two coordination cases are studied: [START_REF] Rais | Impact of loosely coupled data dissemination policies for resource challenged environments[END_REF] initially deploy all services on ONs and (2) update all services on ONs.

Deploy: It takes the form of two synchronization barriers. First, the aggregation ON fetches configurations from all measurement ONs, to do its calibration and installation. Second, it waits for confirmation that all measurement ONs are actively sensing and performing observations. It then starts to listen and process observations, shared by measurement ONs.

Update: The aggregation ON and each measurement ON notify each other of their interruption/restart. Before updating, measurement ONs wait for confirmation that the aggregation ON stopped listening for observations. Then, the aggregation ON waits for confirmation that each measurement ON has been updated before doing its own update. In the context of the DAO-CPS, we consider that updating a measurement ON In the DAO-CPS, deploy/update are usually lowpriority tasks, as the energy budget of ONs should be reserved for observations and computations. Thus, synchronizing the wake-up schedules of ONs to ease communications during deploy/update is not considered in this paper.

III. EXPERIMENTAL SETUP

Experiments were conducted on ESDS [START_REF] Guegan | Validation of esds using epidemic-based data dissemination algorithms[END_REF], a flowlevel network simulator validated and publicly available 2 . Simulation provides flexibility and saves time compared to setting-up and executing on a real infrastructure. The equivalent of several years of real execution time was reduced to a few hours of simulation. Simulation allows for easier reproducibility, as executions and results are not bound to a specific hardware platform.

In ESDS, an API is provided to simulate ONs' activity and to compute the energy consumption of each ON. The CPS is simulated as a network of ONs. For each ON, the sleeping and uptime periods, the execution of deploy/update tasks, and communications are simulated.

A. Use-case simulation

Each ON can go through 4 states: off, idle, stress and pull. In the off state, the ON sleeps. It cannot receive or send messages or execute deploy/update tasks. In the idle state, the ON is awake. It can receive messages but doesn't execute deploy/update tasks and is not sending messages. In the stress state, the ON is awake and executes deploy/update tasks. Finally, in the pull state, the ON is awake but requires coordination data for one or multiple deploy/update tasks.

In the pull state, ONs request data once per second. This high frequency is motivated by the uptime characteristics of our use-case. ONs wake-up once every hour for very short periods of time, leading to very few overlaps. Such high frequency minimizes the probability of missing an overlap. Here, coordination data is assumed to be a simple flag. Each request has a measured fixed size of 257 bytes, close to the lower bound of common request sizes 3 .

In the stress state, only the load generated on the ON to execute deploy/update tasks is considered. The load varies depending on the task. In the simulations, the worst-case is considered: each deploy/update task fully stresses the ON. Each task is assigned to a random duration, following a lognormal distribution bounded between 1s and 30s, where low values are more represented. This interval is chosen according to [START_REF] Rais | Impact of loosely coupled data dissemination policies for resource challenged environments[END_REF] where the minimum ON uptime duration is 1min.

To compute the ON states and deploy/update duration, a dependency graph is created. Each arc represents a task, directed either toward the next task on the same ON, or toward a task on a remote ON. Computing a graph traversal gives the ONs states and their duration for each individual ON. Computing the longest path gives the total deploy/update duration. The graph creation is inspired by [START_REF] Chardet | Toward safe and efficient reconfiguration with concerto[END_REF]. The ON states, their duration, and the deploy/update duration are given as input to ESDS. For each ON, ESDS simulates these states and gives the energy consumed.

The draw of tasks duration, uptime schedules, ONs states, and simulation results are available online 4 .

B. Simulation parameters

Table I summarises parameters used to conduct simulations. Deploy and update are simulated. During simulations, ONs uptime duration is set either at 1 min, 2 min or 3 min. [START_REF] Rais | Impact of loosely coupled data dissemination policies for resource challenged environments[END_REF]. For coordinations, two types of communication are considered: either direct (i.e., ONto-ON) or using an available RN, as an intermediary. In the DAO-CPS, ONs neighborhood sizes can vary up to 29 ONs [5]. To cover most cases, simulations are run using 1 aggregation ON and 5, 15, or 30 measurement ONs. Finally, two suitable radio technologies for the DAO-CPS [START_REF] Rais | Impact of loosely coupled data dissemination policies for resource challenged environments[END_REF] are simulated: LoRa and NB-IoT. The energy calibration is done from the energy consumption of a Raspberry Pi based ON, previously used in papers dealing with CPS deployment in the AT [5], [START_REF] Raïs | UAVs as a Leverage to Provide Energy and Network for Cyber-Physical Observation Units on the Arctic Tundra[END_REF]. The extreme values measured in [START_REF] Tofaily | Quantifying the variability of power and energy consumption for iot edge nodes[END_REF] are used (1.339W for P idle , and 2.697W for P stress ). When an ON is sleeping, its energy consumption is assumed to be null. Finally, the communication cost (send or receive) is calibrated from [START_REF] Rais | Impact of loosely coupled data dissemination policies for resource challenged environments[END_REF] (additional 0.16W for LoRa, 0.65W for NB-IoT).

C. Metrics

To get a representative set of results, 200 uptime schedules are generated. During each schedule, ONs wake-up randomly every hour. In our experiments, a scenario represents a combination of parameters. Each scenario is run on each uptime schedule, for a total of 200 runs per scenario.

The accumulated energy consumed by all ONs under each scenario and each uptime schedule is composed of static and dynamic energy consumption. The static energy consumption is the energy passively consumed by ONs during uptime. The dynamic energy consumption is the energy consumed for the execution and coordination of deploy/update tasks. For 200 runs, the means of the accumulated static, dynamic and total energy consumed by all ONs under a scenario s are denoted eStaticpsq, eDynamicpsq and epsq, respectively. epsq is given by epsq " eStaticpsq `eDynamicpsq

Distinguishing between e and eDynamic allows to consider when ONs wake-up specifically for deploy/update and when ONs take advantage of existing uptimes. When ONs wake-up specifically for deploy/update, e is considered. When ONs take advantage of existing uptimes, only eDynamic is considered. eCommspsq, included in eDynamic, represents the mean of the accumulated energy consumed by communications for 200 runs under a scenario s. This allows to compare the coordination's energy consumption when using LoRa or NB-IoT. Finally, tpsq represents the mean of the duration of deploy/update, for 200 runs under a scenario s.

For each metric m, the percentage of variation %∆mps 1 , s 2 q quantifies the variation of m from scenario s 1 to s 2 . %∆mps 1 , s 2 q " mps 1 q ´mps 2 q

mps 1 q ˚100, (2)
where m can be either e, eDynamic, eComms or t.

The percentage of variation is used to study the impact of varying simulation parameters on energy consumption and coordination duration.

IV. EVALUATION

This section presents the energy consumed by ONs for each scenario and compares results. Scenarios are created from the Cartesian product of simulation parameters, described in Table I: coordination name, communication type, number of measurement ONs, uptime duration, and simulated radio technology.

Results show that, under most scenarios, waking up ONs specifically for the deploy/update coordination implies non-realistic energy consumption. Enabling faster coordination convergence, by increasing ONs uptime duration, has a limited impact on energy consumption reduction. Having an RN is always favorable with regard to energy consumption. However, in the AT, the availability of an RN is not always guaranteed.

When ONs run deploy/update tasks along with their observation activities, only the dynamic energy used for adaptation tasks is taken into account. Increasing the uptime duration only increases energy consumption. Having an RN is also always favorable with regard to energy consumption. Finally, LoRa has a lower consumption than NB-IoT, in all scenarios.

Previous observations are detailed in following sections. Only the most relevant and significant elements are extracted and analyzed.

A. Energy consumed when ONs wake up specifically for deploy and update

Table II presents e for deploy and update according to the number of measurement ONs, the uptime duration and the type of communication (i.e., direct, rn). Note that eDynamic is also depicted in the tables but is analyzed in Section IV-B.

For the smallest cluster size (5 measurement ONs), 1 min uptime duration and using direct communications, e is equal to 63,82 kJ for deploy, and to 39,18 kJ for update. For the biggest cluster size (30 measurement ONs), e reaches 572,02 kJ for deploy, and 350,34 kJ for update. These high energy consumption are expected due to the characteristics of our use-case. Scarce connectivity between ONs leads to a significant amount of time required for coordination convergence. This is illustrated by Table III, where values for t are shown according to the number of measurement ONs, the uptime duration and the type of communication. For 5 measurement ONs, 1 min uptime duration and using direct communications, deploy and update take in average 143,19 hours and 87,61 hours respectively. For 30 measurement ONs, deploy and update take in average 248,65 hours and 152,02 hours respectively.

Uptime duration: Modifying uptime duration leads to a trade-off between energy saved from faster convergence and energy spent at each uptime. Its impact on e is shown in Table II. For deploy and the smallest cluster size, increasing uptime duration from 1 to 3 min decreases e by 6,33% (from 63,82 to 59,78 kJ). For the largest cluster size, increasing uptime duration from 1 to 2 min slightly decreases e by 1,04% (from 572,02 to 566,06 kJ). When increasing uptime duration from 1 to 3 min, e slightly increases by 1,11% (from 572,02 to 578,35 kJ). For update and the smallest cluster size, increasing uptime duration from 1 to 3 min decreases e by 11,97% (from 39,18 to 34,49 kJ). For the highest cluster size, e decreases by 12,25% (from 350,34 to 307,41 kJ).

Increasing uptime duration allows for a strong reduction in t. The reduction in coordination duration is shown in Table III. For deploy and the smallest cluster size, increasing uptime duration from 1 to 3 min decreases t by 68,78% (from 143,19 to 44,71 hours). For update, t decreases by 70,60% (from 87,61 to 25,76 hours). For deploy and the largest cluster size, t decreases by 66,31% (from 248,65 to 83,76 hours). For update, t decreases by 70,81% (from 152,02 to 44,38 hours).

Communications using an available RN: Table II shows results when using an available RN for communications. ONs energy consumption drastically decreases: for 1 min uptime duration and any cluster size, e decreases by more than 97% for deploy, and by more than 94% for update. These reductions are expected, as using an RN drastically reduces deploy/update duration: for 1 min uptime duration having an RN reduces t by more than 97% under any scenario (from Table III).

Finally, combining both uptime duration and RN leverages increases energy consumption under all scenarios (Table II). When using an RN for deploy, increasing uptime duration from 1 to 3 min for the smallest cluster size increases e from 1,39 to 3,40 kJ. For the largest cluster size, e increases from 6,91 to 16,50 kJ. Similar variations can be observed for update. For the smallest cluster size, increasing uptime duration also increases e from 2,12 to 5,87 kJ. For the largest cluster size, e increases from 11,11 to 26,98 kJ. These variations are explained by the full availability of the RN for ONs. In such conditions, the impact of increasing uptime duration on the deploy/update coordination duration is minimized.

B. Energy consumed when ONs take advantage of existing uptimes for deploy and update

In this section, only eDynamic is considered, as the deploy/update coordination is considered to be a task running among others, on ONs. The RN is also included in this assumption, as ONs use RN not only for deploy/update but also for any type of collaboration. Table II shows that, for 1 min uptime duration, eDynamic for deploy is 221,84 J for the smallest cluster size, and 1081,37 J for the highest cluster size. For update, eDynamic is 222,38 J for the smallest cluster size, and 1274,14 J for the highest cluster size.

Uptime duration: When uptime duration increases, under most scenarios eDynamic increases, especially for large cluster sizes (Table II). For deploy and the smallest cluster size, increasing uptime duration from 1 to 3 min slightly increases eDynamic by 0,98% (from 221,84 to 224,01 J). For the largest cluster size, eDynamic increases by 27,74% (from 1081,37 to 1381,37 J). For update and the smallest cluster size, increasing uptime duration from 1 to 3 min slightly decreases eDynamic by 1,20% (from 222,38 to 219,72 J). For the largest cluster size, eDynamic increases Communications using an available RN: Using an available RN for communications allows further decreases in energy consumption (Table II). For deploy, 1 min uptime duration and the smallest cluster size, using an RN decreases eDynamic by 53,01% (from 221,84 to 104,24 J). For the largest cluster size, eDynamic decreases by 58,35% (from 1081,37 to 450,39 J). For update, 1 min uptime duration and the smallest cluster size, using an RN decreases eDynamic by 50,03% (from 222,38 to 111,13 J). For the largest cluster size, eDynamic is reduced by 60,32% (from 1274,14 to 505,62 J). TABLE IV: eComms values for deploy/update according to the number of measurement ONs, the uptime duration, and the type of communication. Standard deviations are shown in parentheses. %∆eComms quantifies the variation of eComms from scenarios using LoRa to scenarios using NB-IoT.

As for Section IV-A, combining the utilization of an RN with longer uptime duration increases eDynamic in all scenarios. Table II shows that for the smallest cluster size, going from 1 to 3 min while using an RN increases eDynamic from 104,24 to 109,81 J for deploy, and from 111,13 to 136,31 J for update. For the largest cluster size, eDynamic increases from 450,39 to 483,82 J for deploy, and from 505,62 to 665,37 J for update.

Radio technology: Table IV presents eComms for deploy and update, according to the number of measurement ONs, the uptime duration and the simulated radio technology (i.e., LoRa, NB-IoT).

For deploy, the smallest cluster size and 1 min uptime duration, using NB-IoT instead of LoRa increases eComms by 17,19% (from 98,34 to 115,24 J). For the largest cluster size, eComms increases by 58,83% (from 513,75 to 815,97 J). For update, the smallest cluster size and 1 min uptime duration, using NB-IoT instead of LoRa increases eComms by 12,67% (from 121,43 to 136,81 J). For the largest cluster size, eComms increases by 26,81% (from 812,87 to 1030,84 J).

Results show that in our use-case NB-IoT has a higher consumption than LoRa under any scenario. Deploy/update duration using LoRa or NB-IoT are not shown in this paper, but NB-IoT's higher bandwidth implies in average a negligible reduction of deploy/update duration (less than 3% in few scenarios). This is due to the small size of coordination exchanges between ONs. Thus, for our use-case, LoRa's lower energy consumption is a better choice for communications.

V. STATE OF THE ART

Works regarding DTNs address challenges related to our use-case, such as systems where nodes have intermittent contacts between each other [START_REF] Verma | Routing Protocols in Delay Tolerant Networks: Comparative and Empirical Analysis[END_REF]- [START_REF] Su | A new node coordination scheme for data gathering in underwater acoustic sensor networks using autonomous underwater vehicle[END_REF]. Among these contributions, some of them specifically address the problem of communication between nodes at 1-hop with asynchronous (or random) wake-up schedules [START_REF] Zheng | Asynchronous wakeup for ad hoc networks[END_REF]. These works usually leverage wake-up schedules of nodes to find a time/energy trade-off for message exchanges. These contributions however do not specifically apply to our use-case, as non-synchronized and non-controllable uptime schedules are considered.

Among contributions dealing with observatory CPS [START_REF] Guo | The application of the internet of things to animal ecology[END_REF]- [15], very few environments impose hard constraints on the CPS such as the AT (i.e., combination of a lack of connectivity with the external world, limited infrastructure and energetic budget). Among contributions dealing with observatory CPS specifically in the AT, none specifically addresses the coordination of changes during adaptation. However, the following contributions are complementary with this paper, as they deal with the dissemination of data (e.g., update data) in CPS deployed in the AT.

In [5], authors conducted experiments for disseminating update data to ONs. The total ONs uptime duration required to complete the dissemination according to different uptime duration is presented. The studied usecase is similar to ours: one sender communicating with multiple receivers. However, ONs are either alwaysup or have synchronized wake-ups. In [START_REF] Rais | Impact of loosely coupled data dissemination policies for resource challenged environments[END_REF] authors studied different policies of data dissemination for the DAO-CPS. The use-case topology is also similar: one sender disseminates data to multiple non-synchronized receivers. Policies are: extending the uptime duration of both sender and receiver until the end of data transmission, or/and hinting to receivers of the next uptime of the sender, to facilitate future transmission. While the extended uptime policy is not relevant in our use-case because of the very small size of exchanged messages between ONs, the hint policy can be considered as a future work.

Our contribution aims at combining the extreme conditions of the AT with the coordination of adaptation tasks in a CPS deployed in such an environment. Understanding ONs energy consumption for different scenarios under plausible assumptions is crucial for better anticipation of ONs energy consumption in real deployments.

VI. CONCLUSION

CPSs deployed in environments like the AT for sensing and observation face extreme conditions. Nodes composing such CPSs are forced to sleep most of the time to save energy and increase their lifetimes. To enable collaboration, services hosted can be coupled between nodes. To prevent failure, the deployment or update of such services has to be safely coordinated. This paper aims at evaluating and studying the impact on energy consumption of nodes during coordination. Two coordination cases (deployment, update) and plausible scenarios (number of nodes, uptime duration, radio technology, relay node availability) are simulated.

Uptime schedules are generated to simulate nodes sleeping behaviors. To get a representative set of results, each scenario is run over 200 uptime schedules. For each scenario, an average of the energy consumption is given and discussed.

Results show that nodes waking-up specifically for coordination implies non-realistic energy consumption when a relay node is not available. Taking advantage of uptimes reserved for sensing or observations only adds the energy consumption overhead induced by the execution of deploy/update tasks and by communications. LoRa is the best choice for communications under any scenario due to the very small sizes of exchanged coordination data. Finally, having an available relay node is always favorable with regards to energy consumption.

Future works aim at identifying and studying leverages to optimize the energy consumption of coordination between sleeping ONs. More precise scenarios are considered: simulating weaker RNs with intermittent availability and calibrating future simulations on real deploy/update tasks.

  Fig.1: DAO-CPS system in the Arctic Tundra. ONs are most of the time isolated from external communications. RNs can be available to few ONs.

TABLE I :

 I Summary of simulation parameters

	Coordination name		{deploy, update}
	Communication type		{direct, rn}
	# of measurement ONs		{5, 10, 15, 20, 25, 30} [5]
	Upt duration		{1min, 2min, 3min} [1]
	Bandwidth (ltnc)	LoRa	50 kbps (0s) [1]
		NB-IoT	200 kbps (0s) [1]
	Energy values	P idle	1,339W [6]
		Pstress	2,697W [6]
		LoRa	+0.16W [1]
		NB-IoT	+0.65W [1]

TABLE II :

 II e and eDynamic values for deploy/update according to the number of measurement ONs, the uptime duration, and the type of communication. Standard deviations are shown in parentheses. %∆e and %∆eDynamic quantify the variation of e and eDynamic, from scenarios using direct communications and scenarios using an available RN.

				deploy
				5 measurement ONs
			e			eDynamic
		direct (kJ)	rn (kJ)	%∆e	direct (J)	rn (J)	%∆eDynamic
	1min uptime	63,82 (24,18)	1,39 (0,31)	97,82	221,84 (31,29)	104,24 (4,83)	53,01
	2min uptime	61,46 (24,68)	2,51 (0,62)	95,92	221,99 (32,49)	107,28 (6,90)	51,67
	3min uptime	59,78 (23,64)	3,40 (0,92)	94,31	224,01 (33,38)	109,81 (10,37)	50,98
				15 measurement ONs
			e			eDynamic
		direct (kJ)	rn (kJ)	%∆e	direct (J)	rn (J)	%∆eDynamic
	1min uptime	245,94 (61,29)	3,68 (0,73)	98,50	575,59 (44,23)	255,52 (6,27)	55,61
	2min uptime	248,08 (67,00)	6,61 (1,49)	97,34	623,47 (58,84)	265,23 (11,18)	57,46
	3min uptime	240,56 (62,96)	9,31 (2,09)	96,13	658,32 (67,97)	273,76 (17,69)	58,42
				30 measurement ONs
			e			eDynamic
		direct (kJ)	rn (kJ)	%∆e	direct (J)	rn (J)	%∆eDynamic
	1min uptime	572,02 (123,12)	6,91 (1,29)	98,79	1081,37 (66,98)	450,39 (10,66)	58,35
	2min uptime	566,06 (113,78)	11,82 (2,49)	97,91	1228,90 (80,45)	467,23 (18,88)	61,98
	3min uptime	578,35 (134,04)	16,50 (3,63)	97,15	1381,37 (104,40)	483,82 (28,54)	64,98
				update
				5 measurement ONs
			e			eDynamic
		direct (kJ)	rn (kJ)	%∆e	direct (J)	rn (J)	%∆eDynamic
	1min uptime	39,18 (17,67)	2,12 (0,46)	94,59	222,38 (47,24)	111,13 (3,47)	50,03
	2min uptime	35,29 (18,19)	3,90 (1,02)	88,95	222,48 (52,29)	121,88 (8,96)	45,22
	3min uptime	34,49 (17,75)	5,87 (1,40)	82,98	219,72 (47,56)	136,31 (11,57)	37,96
				15 measurement ONs
			e			eDynamic
		direct (kJ)	rn (kJ)	%∆e	direct (J)	rn (J)	%∆eDynamic
	1min uptime	150,81 (44,89)	5,94 (0,95)	96,06	620,27 (87,62)	269,24 (9,53)	56,59
	2min uptime	141,18 (43,27)	10,46 (2,20)	92,59	668,75 (92,83)	298,41 (26,61)	55,38
	3min uptime	126,80 (49,71)	15,13 (2,99)	88,07	690,84 (116,43)	343,76 (36,19)	50,24
				30 measurement ONs
			e			eDynamic
		direct (kJ)	rn (kJ)	%∆e	direct (J)	rn (J)	%∆eDynamic
	1min uptime	350,34 (107,06)	11,11 (1,66)	96,83	1274,14 (141,42)	505,62 (19,83)	60,32
	2min uptime	321,13 (83,48)	19,38 (3,66)	93,97	1476,30 (163,06)	568,08 (55,87)	61,52
	3min uptime	307,41 (88,20)	26,98 (4,59)	91,22	1664,77 (177,83)	665,37 (81,07)	60,03

TABLE III :

 III t values for deploy/update according to the number of measurement ONs, the uptime duration, and the type of communication. Standard deviations are shown in parentheses. %∆t quantifies the variation of t from scenarios using direct communications and scenarios using an available RN.

		deploy
		5 measurement ONs
		direct (hours)	rn (hours)	%∆t
	1min uptime	143,19 (54,37)	1,46 (0,34)	98,98
	2min uptime	68,96 (27,71)	1,42 (0,38)	97,94
	3min uptime	44,71 (17,70)	1,34 (0,41)	97,00
		15 measurement ONs
		direct (hours)	rn (hours)	%∆t
	1min uptime	207,05 (51,67)	1,51 (0,31)	99,27
	2min uptime	104,42 (28,25)	1,48 (0,33)	98,58
	3min uptime	67,49 (17,69)	1,50 (0,34)	97,78
		30 measurement ONs
		direct (hours)	rn (hours)	%∆t
	1min uptime	248,65 (53,60)	1,53 (0,30)	99,38
	2min uptime	122,98 (24,76)	1,49 (0,31)	98,79
	3min uptime	83,76 (19,46)	1,52 (0,34)	98,19
		update
		5 measurement ONs
		direct (hours)	rn (hours)	%∆t
	1min uptime	87,61 (39,68)	2,30 (0,55)	97,37
	2min uptime	39,47 (20,42)	2,24 (0,58)	94,32
	3min uptime	25,76 (13,31)	2,30 (0,54)	91,07
		15 measurement ONs
		direct (hours)	rn (hours)	%∆t
	1min uptime	126,70 (37,83)	2,50 (0,43)	98,03
	2min uptime	59,27 (18,24)	2,39 (0,52)	95,97
	3min uptime	35,44 (13,97)	2,43 (0,48)	93,14
		30 measurement ONs
		direct (hours)	rn (hours)	%∆t
	1min uptime	152,02 (46,58)	2,55 (0,40)	98,32
	2min uptime	69,58 (18,15)	2,49 (0,47)	96,42
	3min uptime	44,38 (12,78)	2,50 (0,42)	94,37
	by 30,66% (from 1274,14 to 1664,77 J). Increasing
	uptime duration leads to larger and more frequent
	overlaps between ONs. More overlaps leads to more
	ONs receiving communications, including non-intended
	transmissions. Receiving non-intended communications
	can add a significant overhead to eDynamic.

https://gitlab.com/manzerbredes/esds

https://www.chromium.org/spdy/spdy-whitepaper/

https://github.com/aomond-imt/reconfiguration-esds/releases/tag/ greencom 2023

ACKNOWLEDGMENT

The DAO project is supported by the Research Council of Norway (RCN) IKTPluss program, project number 270672.