Valter Balegas

Cheng Li

Mahsa Najafzadeh

Daniel Porto

Allen Clement

Srgio Duarte

Carla Ferreira

Johannes Gehrke

João Leitão

Nuno Preguia

Rodrigo Rodrigues

Marc Shapiro

Viktor Vafeiadis

Geo-Replication: Fast If Possible, Consistent If Necessary *

Geo-replicated storage systems are at the core of current Internet services. Unfortunately, there exists a fundamental tension between consistency and performance for offering scalable geo-replication. Weakening consistency semantics leads to less coordination and consequently a good user experience, but it may introduce anomalies such as state divergence and invariant violation. In contrast, maintaining stronger consistency precludes anomalies but requires more coordination. This paper discusses two main contributions to address this tension. First, RedBlue Consistency enables blue operations to be fast (and weakly consistent) while the remaining red operations are strongly consistent (and slow). We identify sufficient conditions for determining when operations can be blue or must be red. Second, Explicit Consistency further increases the space of operations that can be fast by restricting the concurrent execution of only the operations that can break application-defined invariants. We further show how to allow operations to complete locally in the common case, by relying on a reservation system that moves coordination off the critical path of operation execution.

Introduction

A geo-replicated system maintains copies of the service state across geographically dispersed locations. Georeplication is not only employed today by virtually all the providers of major Internet services, who typically manage several data centers spread across the globe, but is also accessible to anyone outsourcing their computational needs to cloud providers, since cloud services allow computations or VMs to be instantiated in different data centers.

There are two main reasons for deploying geo-replicated systems. The first reason is disaster tolerance, i.e., the ability to tolerate the unplanned outage of an entire data center, due to catastrophic events such as natural disasters [1]. The second reason is to reduce the latency between the users and the machines that provide the service. The importance of this aspect is demonstrated by several studies that point out an inverse correlation between response times and user satisfaction for important Internet services such as search [START_REF] Schurman | Performance related changes and their user impact[END_REF].

However, there is a fundamental tension between latency and consistency: intuitively, ensuring strong consistency requires coordination between replicas before returning a reply to the user, while, alternatively, a fast response can be given without replica coordination, but only ensuring weak consistency guarantees. This tension has led the providers of global-scale Internet services to choose, for some parts of their services, storage systems offering weak consistency guarantees such as eventual consistency [START_REF] Decandia | Dynamo: Amazon's Highly Available Key-value Store[END_REF], and, for other components, systems with strong consistency such as serializability [START_REF] Bernstein | Concurrency Control and Recovery in Database Systems[END_REF].

This paper revisits in a unified way two of our recent results in trying to achieve a balance between performance and consistency, by devising methods to build geo-replicated systems that introduce a small amount of coordination between replicas to achieve the desired semantics, i.e., systems that are fast when possible and consistent when necessary [START_REF] Li | Making Geo-replicated Systems Fast As Possible, Consistent when Necessary[END_REF][START_REF] Balegas | Putting consistency back into eventual consistency[END_REF]. In the first result, we improve the performance of geo-replicated systems by (1) allowing different operations to execute in either a weakly consistent (fast) or strongly consistent (slow) manner; and (2) identifying a set of principles for making safe use and increasing the space of fast operations. In the second result, we further increase the space of operations that can execute fast by (1) identifying the operations that can break application invariants when executing concurrently; and (2) deploying concurrency control mechanisms that remove coordination from the critical path of operation execution, while preserving invariants.

We start the presentation by laying out our terminology and system model in Section 2. We present an initial approach based on a coarse-grained classification into strong and weak consistency in Section 3. One key aspect of this approach is operation commutativity, and we explain how to achieve it using CRDTs in Section 4. Then we present an approach that makes use of fine-grained coordination between pairs of operations in Section 5. We discuss related work in section 6 and conclude in Section 7.

System model

Our system model is that of a fully replicated distributed system, where replicas are located in different data centers. Each replica follows a deterministic state machine: there is a set of operations U, which manipulate a set of reachable system states S. Each operation u is initially submitted at a given replica (preferably in the closest data center), which we call the origin replica of u. When the remaining replicas receive a request to replicate this operation, they will apply the operation against their local state.

Throughout our explanation we will highlight two important properties that the replicated system should obey. First, there is the state convergence property, which says that all the sites that have executed the same set of operations against the same initial state are in the same final state. This is important to prevent a situation where the system quiesces (no more updates are received) and read-only queries return different results depending on which sites the users are connected to. The second property is to preserve application-specific invariants, which comprise a specification for the behavior of the system. To define these, we introduce the primitive valid(S ) to be true if state S obeys these invariants and false otherwise.

Mixing consistency levels in RedBlue consistency

In this section, we present a hybrid consistency model called RedBlue consistency, where weakly consistent operations, labeled blue, can be executed at a single replica and propagated in the background, with mostly no coordination with concurrent actions at other replicas, while others, labeled red, require a stronger consistency level and thus require cross-replica coordination. RedBlue consistency is one of several systems that propose labeling operations according to their consistency levels [START_REF] Ladin | Providing high availability using lazy replication[END_REF][START_REF] Singh | Zeno: Eventually Consistent Byzantine-Fault Tolerance[END_REF][START_REF] Li | Making Geo-replicated Systems Fast As Possible, Consistent when Necessary[END_REF][START_REF] Terry | Consistency-based Service Level Agreements for Cloud Storage[END_REF], but improves on these systems by offering a precise method for labeling operations.

Defining RedBlue consistency

RedBlue consistency relies on three components: (1) a partitioning of operations into weakly consistent blue operations whose order of execution can vary from site to site, and red operations that must be executed in the same order at all sites, (2) a RedBlue order, which defines a partial order of operations where red operations have to be ordered with respect to each other, and (3) a set of site-specific serializations (i.e., total orders) in which the operations are locally applied. More precisely:

Definition 1 (RedBlue consistency): A replicated system is RedBlue consistent if each site i applies operations according to a linear extension of a RedBlue order O of the operations that were invoked, where O is a partial order among those operations with the requirement that red operations are totally ordered in O.

Figure 1 shows a RedBlue order and two serializations, i.e., the linear extensions of that order in which operations are applied at two different sites. In systems where every operation is labeled red, RedBlue consistency is equivalent to serializability [START_REF] Bernstein | Concurrency Control and Recovery in Database Systems[END_REF]; in systems where every operation is labeled blue, RedBlue consistency becomes a form of causal consistency [START_REF] Terry | Managing Update Conflicts in Bayou, a Weakly Connected Replicated Storage System[END_REF][START_REF] Lloyd | Don't Settle for Eventual: Scalable Causal Consistency for Wide-area Storage with COPS[END_REF][START_REF] Mahajan | Depot: cloud storage with minimal trust[END_REF], since the partial order conveys the necessary causality between operations.

When applying RedBlue consistency to an application, we would like to label all operations blue to obtain best performance. However, this could lead to state divergence and invariant violation, when operations are not commutative. We describe a set of sufficient conditions to guide the classification of operations in order to safely use weak consistency when possible.

Ensuring state convergence

In the context of RedBlue consistency, we can formalize state convergence as follows: To find a correct labeling for maintaining state convergence while providing low latency access, we describe a simple banking example, in which users may share an account that is modified via three operations, namely deposit, withdraw and accrueinterest1 . Keeping in mind that one of the goals of RedBlue consistency is to make the target service as fast as possible, we tentatively label all these operations blue. According to this labeling result, we construct a RedBlue order of deposits and interest accruals made by two users Alice and Bob and two possible serializations applied at both branches of the bank, as shown in Figure 2. This example shows that the labeling of these operations as described is not state convergent. This is because RedBlue consistency allows the two sites to execute blue operations in a different order, but two of the blue operations in the example are non-commutative, namely deposit and accrueinterest. To prevent this situation, a sufficient condition to guarantee state convergence in a system supporting RedBlue consistency is that every blue operation commutes with all other operations, blue or red.

However, when applying this condition to the banking example, it implies that we need to label all three operations red (deposit, withdraw and accrueinterest). This is equivalent to running the system under serializability, which requires coordination across replicas for executing all these operations. To address the problem that it is difficult to find operations that commute with all other operations in the system, we observe that, in many cases, while operations may not be commutative, we can make the changes they induce on the system state to commute. In the banking example, we can engineer accrueinterest commute with the remaining two operations by first computing the amount of interested accrued at the primary replica and then treating that value as a deposit.

To exploit this observation and increase operation commutativity, we propose a change to our original system model, where we split each original application operation u into two components: a generator operation g u with no side-effects, which is executed only at the primary site against some system state S and produces a shadow operation h u (S ), which is executed at every site (including the primary site). The generator operation decides which state transitions should be made while the shadow operation applies the transitions in a state-independent manner.

Preserving invariants

Although the concept of shadow operation helps produce more commutative operations, labeling too many shadow operations as blue may introduce the problem of breaking application invariants. In the banking example, assuming that the shared bank account has an initial balance of 100, if both Alice and Bob withdraw 70 and 60 respectively, the final balance would be -30. This violates the invariant that a bank balance should never be negative. To determine which shadow operations can be safely labeled blue, we begin by defining that a shadow operation is invariant safe if, when applied to a valid state, it always transitions the system into another valid state. This allows us to define the following sufficient condition: a RedBlue consistent system preserves invariants (meaning that all its sites are always in valid states) if all shadow operations that are not invariant safe are labeled red (i.e., strongly consistent).

What can be blue? What must be red?

In summary, the two conditions above lead to the following procedure for deciding which shadow operations can be blue or must be red if a RedBlue consistent system is to provide both state convergence and invariant preservation:

1. For any pair of non-commutative shadow operations h u and h v , label both h u and h v red.

2. For any shadow operation h u that is not invariant safe, label h u red.

3. Label all remaining shadow operations blue.

State convergence

In the previous section we discussed how RedBlue consistency achieves state convergence by relying on shadow operations that commute with each other. With this approach, defining a new operation also implies writing one or more commutative shadow operations, each of which corresponds to a distinct side effect. The major challenge of doing this manual work is that, in an application with a large number of operations, this process may be complex and error-prone.

We now discuss an alternative principled approach to create commutative operations by design. Our approach builds on conflict-free replicated data types (CRDTs) [START_REF] Shapiro | Conflict-free Replicated Data Types[END_REF], which are specially-designed data structures that can be replicated and modified concurrently, and include mechanisms to merge concurrent updates in a deterministic way. Application operations consist of updates to these elementary data types, thus guaranteeing state convergence.

CRDTs

A CRDT is a data type that can be replicated at multiple replicas. As such, it defines an interface with a set of operations to read and to modify its state. A CRDT replica can be modified by locally executing an update operation. When different replicas of the same object are modified concurrently, they temporarily diverge. CRDTs have built-in support for achieving strong eventual consistency [START_REF] Shapiro | Conflict-free Replicated Data Types[END_REF], in which all replicas will eventually reach the same (equivalent) state after applying the same set of updates, without relying on a distributed conflict arbitration process.

Two main flavors of CRDTs have been studied in the literature: operation-based CRDTs and state-based CRDTs. For each of these, sufficient conditions for achieving strong eventual consistency have been established.

In operation-based CRDTs (or commutative replicated data types), updates are propagated by broadcasting operations to every replica in causal order. Interestingly, this proposal matches the operation execution decomposition presented in RedBlue consistency (Section 3), where operations are divided in two components, a generator operation that executes in the local replica, has no side effect and produces a shadow operation, which is propagated and executed in all replicas. The two types of operations are analogous to prepare and downstream operations in the context of operation-based CRDTs, respectively, with the main difference that shadow operations are assigned a consistency level in RedBlue consistency. Similarly to the consequence of commutative shadow operations, the replicas of an operation-based CRDT converge to the same state after executing the same set of updates (in any order that respects causality) if the execution of any two concurrent downstream operations commutes [START_REF] Shapiro | Conflict-free Replicated Data Types[END_REF]. A state-based CRDT (or convergent replicated data type) defines, in addition to the operations to read and update its state, an operation to merge the state of two replicas. Replicas synchronize by exchanging the full replica states: when a new state is received, the new updates are incorporated in the local replica by executing the merge function. It has been shown that the replicas of a state-based CRDT converge to the same state after all replicas synchronize (directly or indirectly) if: (1) all the possible states of an object are partially ordered, forming a join-semilattice; (2) the merge operation between two states is the semilattice join; and (3) an update monotonically increases the state according to the defined partial order [START_REF] Shapiro | Conflict-free Replicated Data Types[END_REF].

Examples

CRDTs have been used in a number of research systems, such as Walter [START_REF] Sovran | Transactional Storage for Geo-replicated Systems[END_REF] and SwiftCloud [START_REF] Zawirski | Write fast, read in the past: Causal consistency for client-side applications[END_REF], and commercial systems, such as Riak [START_REF]Using data types -riak documentation[END_REF] and SoundCloud [START_REF]Consistency without Consensus: CRDTs in Production at SoundCloud[END_REF]. These systems include CRDTs that implement several data types, such as registers, counters, sets, maps, and flags. For each such data type, it is possible to define and implement different semantics to handle concurrent updates, leading to different CRDTs. These semantics define which is the final state of a CRDT when concurrent updates occur. For example, for sets, it is possible to define an add-wins semantics, where, in the presence of a concurrent add and remove of some element e, the final state will contain e (or, more precisely, there exists an add of e that does not happen before a remove of e). It is also possible to define a remove-wins semantics, where the remove will win over a concurrent add. Other semantics can also be implemented, such as a last-writer-wins strategy where an element will belong to the set or not depending on which was the last operation executed, according to the order among operations.

When creating an application, an application developer must select the CRDT with the most appropriate semantics for its goal. For example, in the bank account example, the balance of an account can be modeled as a counter and the set of accounts of a client can be maintained in an add-win set or map CRDT.

In general, an application operation will manipulate multiple data objects. When using CRDTs, it is possible to maintain replicas of these objects in multiple nodes. An operation can execute by accessing a single replica of each object it accesses. These updates can later be propagated to other nodes, with CRDT rules guaranteeing that the replicas of each object will converge to the same state. By propagating the updates to all objects modified in an operation atomically, it is possible to guarantee that all effects of an operation are observed at the same time.

CRDTs for relational databases

In relational databases, it is also possible to model data using CRDTs. Table 1 presents the mapping proposed in SIEVE [START_REF] Li | Automating the choice of consistency levels in replicated systems[END_REF]. Regarding table fields, we defined only two CRDTs. The LWW CRDT can be used with any field type and implements a last-writer-wins strategy for defining the final value of a field. The NUMDELTA CRDT can be used with numeric fields, and transforms each update operation in a downstream operation that adds or subtracts a constant to the value of the field. This can be used to support account balances, counters, etc.

A database table can be seen as a set of tuples. In the general case, and following the semantics of the ARSET CRDT, when concurrent insert, update and delete operations occur, the following rules can be used:

(1) concurrent inserts of tuples with the same key are treated as an insert followed by a sequence of updates;

(2) for concurrent updates, the rules defined for fields are used to deterministically define the final value; (3) a delete will only take effect if no concurrent update or insert was executed.

While using CRDTs guarantees that all replicas converge to the same state, it does not guarantee that the convergence rules executed independently by different CRDTs maintain application invariants. Next, we show how we can address this problem by restricting the concurrent execution of operations that can break application invariants.

Preserving invariants with minimal coordination

As mentioned before, in the banking example, the withdraw operation, despite being commutative, cannot execute under weak consistency, as the concurrent execution of multiple withdrawals can break the invariant that the account balance cannot be negative. To avoid the possibility of breaking the invariant, RedBlue consistency would label all withdrawals as red, requiring replicas to coordinate the execution of every withdraw operation. In practice, however, only in a few cases the cumulative effects of all concurrent withdrawals will surpass the actual balance of the account.

To relieve the strong constraint imposed by RedBlue consistency, we propose a more efficient coordination plan: given some account balance, replicas can coordinate beforehand to split the balance among them. Until a replica consumes its allocated share of the balance, it can execute operations locally, without coordination with other replicas, with the guarantee that the balance will not become negative, i.e., the application invariant will not be broken.

The above idea has been previously explored in the context of escrow transactions [START_REF] Barbará-Millá | The demarcation protocol: A technique for maintaining constraints in distributed database systems[END_REF][START_REF] O'neil | The escrow transactional method[END_REF]. We revisit and generalize the concept of escrow transactions, to allow replicas to assess the safety of operations without coordination when executing operations. In our generalization, when replicas cannot ensure an operation is safe by reading local state, they contact remote peers to update their vision of the database to decide the fate of the operation. In addition, we discuss how we avoid the coordination across sites for all red operations, which is required for totally ordering them. Instead, we identify a small set of coordination requirements between operations, and show how to enforce those rules at runtime.

Explicit Consistency in a nutshell

We present a new consistency model, called Explicit Consistency, that extends RedBlue consistency to avoid the coordination of red operations when possible. The idea is that instead of labeling shadow operations as red or blue, programmers specify the application invariants. The system must execute operations while guaranteeing that these invariants are not broken.

To this end, we propose the following methodology for creating applications that adhere to Explicit Consistency. First, programmers must specify the application invariants and operation effects. Second, we provide a tool to analyze the specification of the application and identify the pairs of conflicting shadow operations. Non-conflicting shadow operations execute without any restrictions, as blue operations. We include a library of CRDTs to help programmers define commutative operations. Third, for each pair of conflicting shadow operations, the programmer can use a specialized concurrency control mechanism that restricts the concurrent execution of these operations. This mechanism executes coordination outside of the critical path of operation execution, allowing these operations to execute locally without the need to coordinate with other replicas.

The following sections provide additional details on these steps to use the Explicit Consistency model.

Application specification

Programmers specify application invariants and the post-conditions of shadow operations as first order logic expressions. Invariants must be written as universally quantified formulas in prenex normal form, while the grammar for specifying applications post-conditions is restricted to predicate assignments, that assert the truth value of some predicate, and function clauses, which define the relation between the value of some predicate before and after the execution of the operation. The code snippet in figure 3(a) shows the specification of the banking application. We extended this example to illustrate different invariant violations. In the extended version, clients must have a valid contract with the bank to be able to access an account. Clients might have multiple accounts and must close all of them before finishing the contract. In Line 2, the invariant guarantees that an account balance is never negative. In line 3, the invariant states that, for every open account, the account holder must be registered with the bank.

Analysis

The analysis checks which are the shadow operations whose concurrent execution might produce a database state that is invalid with respect to the declared invariants. Conceptually, for each pair of operations and for every valid state where these operation can execute, the algorithm verifies if the execution of both operations will lead to a state that is not valid according to the invariants of the application. Obviously, checking every pair of operations in every valid state exhaustively is unfeasible. Instead, our algorithm relies in the Z3 satisfiability modulo theory (SMT) solver to perform this verification efficiently. A full description of the algorithm is given in our prior publication [START_REF] Balegas | Putting consistency back into eventual consistency[END_REF].

Figure 3(b) summarizes the conflicts in the example of Figure 3(a): two concurrent successful withdrawals might make the balance negative (non-idempotence); assigning and removing an account concurrently for the same user might leave the system in an inconsistent state, because each shadow operation writes different values for the predicate userAccount(cId, aId) (opposing post-conditions); and finally, the pair createAccount(cId, aId) and endContract(cId) might violate the integrity constraint of line 3, because a new account is being added to a user that is ending a contract with the bank.

Code instrumentation

After identifying which operations can lead to conflicts, the programmer must instrument the application to avoid them. Some conflicts can be handled by simply relying on CRDTs to automatically solve them. For example, our analysis can report that operations have opposing post-conditions: e.g., operations assignAccout and remAccount assign the value true and false to predicate userAccount(cId, aId). In this situation, the programmer can choose a preferred value for the predicate and use a CRDT that automatically implements the selected decision 2 . Other conflicts must be handled by restricting the concurrent execution of operations that can cause invariants to be broken. To this end, we provide a set of specialized reservation-based concurrency control mechanisms.

For conflicts on numeric invariants, like the one that withdraw causes, we support an escrow reservation for allowing some decrements of numeric values to execute without coordination. In an escrow reservation, each replica is assigned a budget of decrements, based on the initial value of the data. In our example, when a replica receives a withdraw request, if the local budget is sufficient, the generator operation executes immediately without coordination, generating a shadow operation that decrements the balance. This local execution is safe, guaranteeing that the invariant still holds after executing all concurrent operations, because the sum of the budgets of all replicas is equal to the value of the initial value. If the local budget is not enough to satisfy the request, the replica needs to contact remote replicas to increase its budget, until it can satisfy the request. If that is not possible, because there are not enough resources globally, then the generator operation fails, generating no shadow operation.

For conflicts on generic invariants, we include a multi-value lock reservation. This lock can be in one of the following three states: (1) shared forbid, giving the shared right to forbid some action to occur; (2) shared allow, giving the shared right to allow some action to occur; (3) exclusive allow, giving the exclusive right to execute some action. The idea is that, for a conflicting pair of operations, (o 1 , o 2 ), the lock will be associated with the execution of one of the operations, say o 1 . To execute o 1 , a replica must hold the lock in the shared allow mode. This right can be shared by multiple replicas. To execute o 2 , a replica must hold the lock in the shared forbid mode. As before, when executing the generator operation, if the replica already holds the necessary locks (in the required mode to execute the operation), it can execute locally and generate the corresponding shadow operation. If not, it must contact other replicas to obtain the necessary locks.

Besides these two locks, we also proposed other locks that can efficiently restrict the concurrent execution of operations that conflict in other types of invariants, including conditions on the number of elements that satisfy a given condition and disjunctions. In a related work, Gotsman et. al. [START_REF] Gotsman | cause i'm strong enough: Reasoning about consistency choices in distributed systems[END_REF] have shown how to prove that a given set of locks is sufficient for maintaining invariants.

Related work

Many cloud storage systems supporting geo-replication have emerged in recent years. Some of these systems offer variants of eventual consistency, where operations produce responses right after being executed in a single data center (usually the closest one) and are replicated in the background, so that user observed latency is improved [START_REF] Decandia | Dynamo: Amazon's Highly Available Key-value Store[END_REF][START_REF] Lloyd | Don't Settle for Eventual: Scalable Causal Consistency for Wide-area Storage with COPS[END_REF][START_REF] Lloyd | Stronger Semantics for Low-latency Geo-replicated Storage[END_REF][START_REF] Almeida | ChainReaction: A Causal+ Consistent Datastore Based on Chain Replication[END_REF][START_REF] Lakshman | Cassandra: A Decentralized Structured Storage System[END_REF]. These variants target different requirements, such as: reading a causally consistent view of the database (causal consistency) [START_REF] Lloyd | Don't Settle for Eventual: Scalable Causal Consistency for Wide-area Storage with COPS[END_REF][START_REF] Almeida | ChainReaction: A Causal+ Consistent Datastore Based on Chain Replication[END_REF][START_REF] Du | Orbe: Scalable Causal Consistency Using Dependency Matrices and Physical Clocks[END_REF][START_REF] Bailis | Bolt-on Causal Consistency[END_REF]; supporting limited transactions where a set of updates are made visible atomically [START_REF] Lloyd | Stronger Semantics for Low-latency Geo-replicated Storage[END_REF][START_REF] Bailis | Scalable Atomic Visibility with RAMP Transactions[END_REF]; supporting application-specific or type-specific reconciliation with no lost updates [START_REF] Decandia | Dynamo: Amazon's Highly Available Key-value Store[END_REF][START_REF] Lloyd | Don't Settle for Eventual: Scalable Causal Consistency for Wide-area Storage with COPS[END_REF][START_REF] Sovran | Transactional Storage for Geo-replicated Systems[END_REF][START_REF]Using data types -riak documentation[END_REF], etc.

While some systems implement eventual consistency by relying on a simple last-writer-wins strategy, others have explored the semantics of applications (and data types). Semantic types [START_REF] Garcia-Molina | Using semantic knowledge for transaction processing in a distributed database[END_REF] have been used for building non-serializable schedules that preserve consistency in distributed databases. Conflict-free replicated data types [START_REF] Shapiro | Conflict-free Replicated Data Types[END_REF] explore commutativity for enabling the automatic merge of concurrent updates to the same data types.

Eventual consistency is insufficient for some applications that require some operations to execute under strong consistency for correctness. To this end, several systems support strong consistency. Spanner provides strong consistency for the whole database, at the cost of incurring coordination overhead for all updates [START_REF] Corbett | Spanner: Google's Globallydistributed Database[END_REF]. Transaction chains support transaction serializability with latency proportional to the latency to the first replica that the corresponding transaction accesses [START_REF] Zhang | Transaction Chains: Achieving Serializability with Low Latency in Geo-distributed Storage Systems[END_REF]. MDCC [START_REF] Kraska | MDCC: Multi-data Center Consistency[END_REF] and Replicated Commit [START_REF] Mahmoud | Low-latency Multi-datacenter Databases Using Replicated Commit[END_REF] propose optimized approaches for executing transactions but still incur inter-data center latency for committing transactions. Some systems combine the benefits of weak and strong consistency models by allowing both levels to coexist. In Walter [START_REF] Sovran | Transactional Storage for Geo-replicated Systems[END_REF], transactions that can execute under weak consistency run fast, without needing to coordinate with other datacenters. Bayou [START_REF] Terry | Managing Update Conflicts in Bayou, a Weakly Connected Replicated Storage System[END_REF] and Pileus [START_REF] Terry | Consistency-based Service Level Agreements for Cloud Storage[END_REF] allow operations to read data with different consistency levels, from strong to eventual consistency. PNUTS [START_REF] Cooper | PNUTS: Yahoo!'s Hosted Data Serving Platform[END_REF] and DynamoDB [START_REF] Sivasubramanian | Amazon DynamoDB: A Seamlessly Scalable Non-relational Database Service[END_REF] also combine weak consistency with per-object strong consistency relying on conditional writes, where a write fails in the presence of concurrent writes. RedBlue consistency also combines weak and strong consistency in the same system. Unlike other systems, RedBlue consistency splits operations into generator and shadow parts to allow more operations to commute, and define a procedure to help programmers labeling shadow operations as weak or strong.

Escrow transactions [START_REF] O'neil | The escrow transactional method[END_REF] offer a mechanism for enforcing numeric invariants under concurrent execution of transactions. By enforcing local invariants in each transaction, they can guarantee that a global invariant is not broken. This idea can be applied to other data types, and it has been explored for supporting disconnected operation in mobile computing [START_REF] Walborn | Supporting Semantics-based Transaction Processing in Mobile Database Applications[END_REF][START_REF] Preguic ¸a | Reservations for Conflict Avoidance in a Mobile Database System[END_REF][START_REF] Shrira | Exo-leasing: Escrow Synchronization for Mobile Clients of Commodity Storage Servers[END_REF]. Balegas et al. [START_REF] Balegas | Extending eventually consistent cloud databases for enforcing numeric invariants[END_REF] proposed the bounded counter CRDT that can be used to enforce numeric invariants in weakly consistent cloud databases. The demarcation protocol [START_REF] Barbará-Millá | The demarcation protocol: A technique for maintaining constraints in distributed database systems[END_REF] aims at maintaining invariants in distributed databases. Although its underlying protocols are similar to escrow-based approaches, it focuses on maintaining invariants across different objects. Warranties [START_REF] Liu | Warranties for faster strong consistency[END_REF] provide time-limited assertions over the database state, which can improve latency of read operations in cloud storages. Indigo builds on similar ideas for enforcing application invariants, but it is the first piece of work to provide an approach that, starting from application invariants expressed in first-order logic, leads to the deployment of the appropriate techniques for enforcing such invariants in a geo-replicated weakly consistent data store. Gotsman et. al. [START_REF] Gotsman | cause i'm strong enough: Reasoning about consistency choices in distributed systems[END_REF] propose a proof rule for establishing that the use of a given set of techniques is sufficient to ensure the preservation of invariants.

The static analysis of code is a standard technique used extensively for various purposes, including in a context similar to ours. SIEVE [START_REF] Li | Automating the choice of consistency levels in replicated systems[END_REF] combines static and dynamic analysis to infer which operations should use strong consistency and which operations should use weak consistency in a RedBlue system [START_REF] Li | Making Geo-replicated Systems Fast As Possible, Consistent when Necessary[END_REF]. Roy et al. [START_REF] Roy | The homeostasis protocol: Avoiding transaction coordination through program analysis[END_REF] present an analysis algorithm that describes the semantics of transactions. These works are complementary to ours, since the proposed techniques could be used to automatically infer application side effects.

Conclusion

In this paper we summarized two of our recent results in addressing the fundamental tension between latency and consistency in geo-replicated systems. First, RedBlue consistency [START_REF] Li | Making Geo-replicated Systems Fast As Possible, Consistent when Necessary[END_REF] offers fast geo-replication by presenting sufficient conditions that allow programmers to safely separate weakly consistent (fast) operations from strongly consistent (slow) ones in a coarse-grained manner. To increase the space of potential fast operations and simplify the programmer's task of defining commutative operations, we propose the use of conflict-free replicated data types. Second, Explicit Consistency [START_REF] Balegas | Putting consistency back into eventual consistency[END_REF] enables programmers to make fine-grained decisions on consistency level assignments by connecting application invariants to ordering conflicts between pairs of operations, and explores efficient reservation techniques for coordinating conflicting operations with low cost.

Figure 1 :

 1 Figure 1: RedBlue order and serializations for a system spanning two sites. Operations marked with ⋆ are red, and operations marked with △ are blue. Dotted arrows in (a) indicate the partial ordering of operations.

Figure 2 :

 2 Figure 2: A RedBlue consistent account with initial balance of 100 and final diverged state .

  writer-wins to solve concurrent updates NUMDELTA Add a delta to the numeric value

Figure 3 :

 3 Figure 3: Bank application specification and analysis results.

in EU Bob in US accrueinterest() deposit(20) (a) RedBlue order O of operations issued by Alice and Bob deposit(20) accrueinterest() ¹ deposit(20) balance:100 accrueinterest() Alice in EU Bob in US balance:100 balance:120 balance:105 balance:126 balance:125

  Definition 2 (State convergence): A RedBlue consistent system is state convergent if all serializations of the underlying RedBlue order O reach the same state S w.r.t. any initial state S 0 .

	Alice (b) Serializations of O leading to diverged state

TABLE AOSET ,

 AOSET UOSET, Sets with restricted operations (add, update, and/or remove). AUSET, ARSET Conflicting operations are logically executed by timestamp order.

Table 1 :

 1 Commutative replicated data types (CRDTs) for relational data. * FIELD covers primitive types such as integer, float, double, datetime and string.

accrueinterest computes a new balance by multiplying the old balance value and (1 + interest rate).

In our experience, boolean predicates can be implemented using Set CRDTs with add-wins and remove-wins policies to enforce that the corresponding predicate becomes true or false respectively.

Acknowledgments

The research of Rodrigo Rodrigues is supported by the European Research Council under an ERC Starting Grant. This research was also supported in part by EU FP7 SyncFree project (609551), FCT/MCT SFRH/BD/87540/2012, PEst-OE/ EEI/ UI0527/ 2014, NOVA LINCS (UID/CEC/04516/2013), and INESC-ID (UID/CEC/50021/2013).


Alejandro Z Tomsic
email: alejandro.tomsic@lip6.fr

Tyler Crain
email: tyler.crain@lip6.fr

Marc Shapiro
email: marc.shapiro@acm.org

PhysiCS-NMSI: efficient consistent snapshots for scalable snapshot isolation

Non-Monotonic Snapshot Isolation (NMSI), a variant of the widely deployed Snapshot Isolation (SI), aims at improving scalability by relaxing snapshots. In contrast to SI, NMSI snapshots are causally consistent, which allows for more parallelism and a reduced abort rate.

This work documents the design of PhysiCS-NMSI, a transactional protocol implementing NMSI in a partitioned data store. It is the first protocol to rely on a single scalar taken from a physical clock for tracking causal dependencies and building causally consistent snapshots. Its commit protocol ensures atomicity and the absence of write-write conflicts.

We argue that PhysiCS-NMSI approach increases concurrency and reduces abort rate and metadata overhead as compared to state-of-art systems.

INTRODUCTION

Snapshot Isolation (SI) [START_REF] Berenson | A critique of ANSI SQL isolation levels[END_REF] is a popular isolation level provided by commercial databases such as Oracle and SQL Server. Under SI, when a transaction starts, it takes a snapshot, the view of the database that it can read from. When an update transaction commits, its effects are applied atomically, creating a new snapshot. SI forbids write-write conflicts; if two transactions attempt to update the same item(s) concurrently, one must abort. In contrast to serialisability, it ignores read-write conflicts.

SI requires strictly consistent snapshots (SCS), which are statically defined at a transaction's starting point. SCSs disallow reading the effects of updates committed past that point, which increases the probability of write-write conflicts and, hence, of aborts [START_REF] Ardekani | On the scalability of snapshot isolation[END_REF]. Moreover, SCSs must include all updates committed up to that point, which may cause reads wait to include currently committing updates [START_REF] Du | Clock-SI: Snapshot isolation for partitioned data stores using loosely synchronized clocks[END_REF].

Non-Monotonic Snapshot Isolation (NMSI) is a variant of SI that still provides a strong model for programmers by preventing write conflicts. It allows more scalable implementations by weakening snapshots [START_REF] Ardekani | Non-monotonic snapshot isolation: Scalable and strong consistency for geo-replicated transactional systems[END_REF]. Under NMSI, a transaction reads from a causally-consistent snapshot (CCS)

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org.

PaPOC '16 [START_REF] Lloyd | Don't settle for eventual: Scalable causal consistency for wide-area storage with COPS[END_REF], which can include versions committed after its starting point. Specifically, a transaction can read any version that is causally compatible with its previously-read items. This flexibility provides more implementation freedom, as reduces the amount of blocking reads and aborts compared to SI. However, existing implementations of NMSI incur large metadata for tracking causal dependencies [START_REF] Ardekani | Non-monotonic snapshot isolation: Scalable and strong consistency for geo-replicated transactional systems[END_REF]. This translates into storage, communication and processing overhead proportional to the number of servers in the system.

In this paper, we present PhysiCS-NMSI, a transactional system ensuring NMSI over a partitioned data store. It is the first protocol to rely on loosely synchronised physical clocks for encoding causality metadata in a single scalar. It provides causally consistent snapshots where the snapshot can be moved forward throughout its duration, and a two-phase commit (2PC) protocol for ensuring that a transaction atomically commits at multiple partitions with no write-write conflicts.

The contributions of this paper are:

• A novel approach to implement NMSI based on loosely synchronised physical clocks, relying on single-scalar metadata, that tackles the scalability limitations of existing implementations.

• A comparison and discussion of the implications of the proposed approach when compared to state-of-art solutions.

The rest of the paper is organised as follows. Section 2 presents an overview and the transactional protocol of PhysiCS-NMSI. Section 3 discusses its potential advantages when compared to the state of the art. We conclude our work and point future work directions in section 4.

PhysiCS-NMSI

Overview

We consider a single site, partitioned data store. The system is comprised of a number of servers, each storing a discrete subset of data items, called a database partition. Servers are equipped with a physical clock, used to timestamp events. Clocks are loosely synchronized by a time synchronization protocol such as NTP [START_REF]The network time protocol[END_REF]. The precision of such protocol does not affect our system's correctness. Large clock skew between servers might impact performance.

A data item is assigned to a partition based on the hash of its object identifier (oid). The data store keeps multiple versions of each object, identified by a scalar timestamp. A version contains the value of the object and a timestamp that encodes its causal dependencies. Both the commit and dependency timestamps are assigned by the commit protocol.

PhysiCS-NMSI provides a transactional interface. A transaction consists of a sequence of reads and writes, surrounded by a begin and a commit marker.

Protocol

Each partition runs a data node (DN ), a sequential process responsible for handling operations issued to its stored objects. When a client starts a transaction, the server receiving the request creates a transaction coordinator (T C) process, that handles client operations and communicates with DN s. A T C executes client operations sequentially. We introduce the protocol in terms of steps executed by a T C and DN (s) to execute a transaction.

Reading from a CCS. requires all item versions a transaction reads to be causally compatible among each other. Namely, versions Xi and Yj of items x and y are causally compatible if there does not exist X k , another version of x, such that X k is created after Xi, and Yj causally depends on X k [START_REF] Du | GentleRain: Cheap and scalable causal consistency with physical clocks[END_REF][START_REF] Lloyd | Don't settle for eventual: Scalable causal consistency for wide-area storage with COPS[END_REF], where a causal dependency is defined by the happens before relation [START_REF] Ahamad | Causal memory[END_REF][START_REF] Lamport | Time, clocks, and the ordering of events in a distributed system[END_REF].

A T C keeps two variables to determine the causally compatible versions that a transaction can read from: • tr : the lower bound of the read timestamp of a version a transaction can read. It is used to prevent reading a value that could be later overwritten with a version timestamp bigger than a previously seen dependency time, thus violating the causal snapshot. It is initialized to the dependency time of the first object read by the transaction. As new objects are read, the value of tr is updated to the maximum dependency timestamp observed.

When performing a read request, a T C sends to a DN the oid of the requested object along with the transaction's d and tr . A DN receiving such request uses this information to retrieve the most recent causally compatible version stored. In PhysiCS-NMSI, a given version is causally compatible if (i) it has dependency timestamp not higher than d and (ii) read timestamp no-smaller than tr . The DN replies to the T C including the version's value along with its version, dependency and read timestamps. A T C uses this information to update, if necessary, the transaction's d and tr .

Figure 1 shows a T C executing a transaction that reads four objects (identified by their oids a, b, c and d), each stored at a different DN . We depict object versions as segments delimited by their version and dependency timestamps. The grey area shows how d and tr evolve over When a compatible version is being committed by the 2PC protocol, a DN can choose to wait for it to finish committing and include it the snapshot, or to return an older compatible version. The latter choice avoids blocking, which might improve response time and parallelism. Nevertheless, if the pending commit succeeds and the transaction later updates the object, it will abort due to a conflict. Another special case presents when a DN receives a read request and its read time is smaller than tr . Here, the server advances its local clock to tr and returns the latest available version. This avoids blocking and reducing the transaction's grey area. If this situation arises simultaneously with a a version committing with timestamp smaller than the DN 's new clock, the DN must wait until it commits and include it in the snapshot.

As a transaction progresses, the grey area becomes smaller. This can continue until d = tr . This case still allows for freshness (reading versions committed after the transaction's starting point), as long as new read values have a version timestamp bigger and dependency timestamp smaller than d = tr . Even in this case, there is always a version compatible with the snapshot.

Updating an item. When a client issues a write operation to a given object, a T C buffers the update locally. If the transaction did not read the object up to that point, the coordinator issues a special read request to the appropriate DN , which returns its current version and dependency timestamp. The update is buffered along with the version timestamp the T C is aware of. This is used at commit time for certifying the absence of write-write conflicts.

Committing a transaction. PhysiCS-NMSI commits readonly transactions without further checks, even when they read from multiple partitions. When an update transaction starts to commit, if it updates data items stored at a single DN , the new version timestamp is assigned the value of the clock at its server, where it commits in a single round-trip to the T C after locally certifying the absence of write-write conflicts. The certification is successful at a DN if, for every updated object, no transaction has created a newer version than the version timestamp read by the transaction.

When a transaction updates multiple DN s, the T C coordinates a two-phase commit protocol (2PC) that decides on the outcome (commit or abort) of the transaction and defines the version (commit) timestamp of its updated objects. In both DN cases, the new dependency timestamp is set to the maximum version timestamp of the items accessed by the transaction.

2PC protocol. When a transaction updated multiple partitions, the T C sends a prepare message to each updated DN that includes its updates and their read versions. Upon receiving prepare message, a DN certifies its updates do not write-conflict with other concurrently committing transactions. A successful DN replies to the T C with its current clock timestamp. A DN detecting a conflict sends an abort message to the T C, which aborts the transaction at other DN s. After receiving all prepare responses, the T C computes the transaction's commit time as the maximum timestamp received from a DN . It sends back a commit message to DN s including it. Upon receiving such message, a DN applies its updates along with their commit and dependency timestamps, making them visible to further transactions.

COMPARISON TO OTHER SYSTEMS

SCS and physical clocks. Existing systems that rely on loosely synchronised physical clocks to determine database snapshots implement the stronger SCS [START_REF] Du | Clock-SI: Snapshot isolation for partitioned data stores using loosely synchronized clocks[END_REF], even when they implement causal consistency [START_REF] Akkoorath | Cure: Strong semantics meets high availability and low latency[END_REF][START_REF] Du | Orbe: Scalable causal consistency using dependency matrices and physical clocks[END_REF][START_REF] Du | GentleRain: Cheap and scalable causal consistency with physical clocks[END_REF]. Such systems have to wait in two cases: (i)a committing version that needs to be included in the snapshot, and (ii) clocks to catch up with the snapshot timestamp in the presence of clock skew between servers [START_REF] Du | Clock-SI: Snapshot isolation for partitioned data stores using loosely synchronized clocks[END_REF]. In contrast, PhysiCS-NMSI must only wait in case of a clock be behind by a significant amount, i.e., behind tr set by the dependency timestamp of an object previously read by the transaction, occurring simultaneously with a pending commit with version timestamp expected between its current clock and tr . We believe this situation is rare in a partitioned data store expected to be deployed at a single DC, where the clock skew allowed by NTP is small. Indeed, a recent experiment at Facebook showed 99.9th percentile clock skew across all web servers in a data centre was 35 ms [START_REF] Lu | Existential consistency: Measuring and understanding consistency at facebook[END_REF].

Clock-SI is a transactional protocol that implements SI relying on physical clocks to totally order snapshots [START_REF] Du | Clock-SI: Snapshot isolation for partitioned data stores using loosely synchronized clocks[END_REF]. Under Clock-SI, a snapshot is frozen at the transaction's start point. When committing an update transaction, the commit protocol certifies conflicts against that point. Under PhysiCS-NMSI, a transaction is allowed to read values committed after it started. The commit protocol checks each updated object for conflicts against its own read version. This may reduce its abort rate. CCS in strong consistency. Strong consistency models that are compatible with CCS include NMSI, Parallel Snapshot Isolation (PSI) [START_REF] Sovran | Transactional storage for geo-replicated systems[END_REF] and update serialisability (US) [START_REF] Hansdah | Update serializability in locking[END_REF]. Existing implementations unnecessarily limit a snapshot's freshness; they freeze a snapshot globally at the beginning of a transaction [START_REF] Sovran | Transactional storage for geo-replicated systems[END_REF], or at a partition when reading from it [START_REF] Ardekani | Non-monotonic snapshot isolation: Scalable and strong consistency for geo-replicated transactional systems[END_REF][START_REF] Peluso | When scalability meets consistency: Genuine multiversion update-serializable partial data replication[END_REF]. This can cause reading old versions even when newer causally compatible ones are available. In contrast, PhysiCS-NMSI allows a snapshot to include the most recent causally compatible version of an object, which may improve freshness and reduce aborts under certain workloads. Causal dependency metadata. CCS implementations often rely on vector clocks sized with the number of servers [START_REF] Ardekani | Non-monotonic snapshot isolation: Scalable and strong consistency for geo-replicated transactional systems[END_REF][START_REF] Peluso | When scalability meets consistency: Genuine multiversion update-serializable partial data replication[END_REF][START_REF] Sovran | Transactional storage for geo-replicated systems[END_REF], or metadata that grows with the number of objects [START_REF] Lloyd | Don't settle for eventual: Scalable causal consistency for wide-area storage with COPS[END_REF]. This incurs storage, communication, and processing overhead that increases as these systems scale. PhysiCS-NMSI reduces this overhead by compacting causal dependencies in a single scalar. The drawback of this approach is that it generates false dependencies, which may lead to read versions conservatively for not violating causality, and unnecessarily aborting transactions. Multi-versioning. A CCS allows a transaction to choose between multiple versions of the same object. When compared to a SCS (where there is a single compatible version of any given object), this may (i) reduce the processing cost of retrieving a compatible version, as potentially fewer versions would need to be checked for compatibility, (ii) reduce the storage overhead of maintaining old versions, as a transaction can read versions committed past its starting point, and (iii) weaken the properties of the replication mechanism [START_REF] Zhang | Building consistent transactions with inconsistent replication[END_REF], as an outdated replica may still be able to provide causally compatible versions to a transaction. To the best of our knowledge, SCS and CCS have not been compared in terms of these three aspects.

CONCLUSIONS AND FUTURE WORK

We have presented the outline of PhysiCS-NMSI, a scalable approach to implementing strong consistency with causally consistent snapshots based on loosely synchronised physical clocks to encode causal dependencies in a single-scalar. PhysiCS-NMSI's design is aimed at addressing the scalability issues of state of the art implementations of SI and NMSI, and causally consistent snapshots in general.

Our next step is to support our assumptions through experimental results. Future research includes adapting our protocols to support geo-replication.

•

  d : the upper bound of the dependency timestamp of a version a transaction can read. It is used to prevent reading a version that causally depends on an overwritten version of an object already in the snapshot. After the transaction's first read, d is set to the read timestamp of the returned version. The read timestamp of a given version is the latest time at which a given version has not been overwritten. As new objects are read, the value of d is updated to the minimum read timestamp observed.

8 A

 8 T C builds a CCS by reading elements a, b, c and d from four different DN s. d, v and tr represent an object's dependency, version and read timestamp, respectively.

Figure 1 :

 1 Figure 1: Building a CCS in PhysiCS-NMSI


Martin Rosalie

Grégoire Danoy

Serge Chaumette

Pascal Bouvry

UAV Multilevel Swarms for Situation Management

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

though the technology for operating a single UAV is now mature, additional efforts are still necessary for using UAVs in fleets (or swarms). Therefore the ASIMUT project (Aid to SItuation Management based on MUltimodal, MUltiUAVs, MUltilevel acquisition Techniques). The major challenge of this project consists in handling several fleets of UAVs including communication, networking and positioning aspects. This motivates the development of novel multilevel cooperation algo-rithms which have not been widely explored, especially when autonomy is an additional challenge. Techniques to optimize communications for multilevel swarms are also required. Finally, distributed and localized mobility management algorithms that cope with conflicting objectives such as connectivity maintenance and geographical area coverage must be provided.

ASIMUT Project

The main goal of the ASIMUT project is to address scenarios where a mission is to be achieved based on data fusion coming from different sensors in a number of UAVs that constitute a swarm. Developing innovative algorithms based on learning techniques dedicated to fusion of data provided by airborne sensors embedded in a swarm of UAVs. From early warning process where data are provided by the UAV swarm payload, the target localization, monitoring and classification processing are performed using these techniques. Swarms are composed of fixed-wing and multi-rotor UAVs. The role of the HLCS is to manage the tasks assigned by the GCS or autonomously created by the HLCS in reaction to an event occurring in the environment. Finally the LLS role is to collect data and track vehicles in specific areas of this environment.

GCS HLCS

Swarm decisional autonomy and mobility management

• Swarm decisional autonomy: The CARUS project [START_REF] Chaumette | Carus, an operational retasking application for a swarm of autonomous uavs: First return on experience[END_REF] went a step further than the state-of-the-art on autonomous swarms of UAVs. The authors achieved a theoretical and experimental study of a swarm of UAVs with autonomous decision, which purpose was to monitor and solve issues on specified interest points

• Mobility management: Some promising approaches are inspired by nature, and more precisely by ant colonies. Ant Colony Optimization (ACO) is a set of probabilistic techniques for solving computational problems, which can be reduced to finding good paths through graphs. Initially proposed by Marco Dorigo in 1992 in his PhD thesis [START_REF] Dorigo | Optimization, Learning and Natural Algorithms[END_REF], ACO has found applications in many domains. The main idea is that ants use the environment to exchange information via pheromone deposit which concentration influences their behavior. This process is called stigmergy. UAVs deposit repulsive pheromones in visited geographical areas so as to prevent other UAVs from revisiting the same places too early [START_REF] Kuiper | Mobility models for UAV group reconnaissance applications[END_REF]. Additional objectives are considered such as network connectivity as recently proposed by Schleich et al. for surveillance scenarios [START_REF] Schleich | UAV Fleet Area Coverage with Network Connectivity Constraint[END_REF].

Mission decision and execution

ASIMUT will focus on online and decentralized mobility management techniques. More precisely it will rely on bio-inspired techniques to ensure the optimization of the autonomous UAV swarms movements.

Activity Diagram describing the communication process of a UAV

The UAVs mobility should be as hard to predict as possible to prevent possible attacks. Two approaches are considered, either using stochastic or deterministic processes. For the surveillance movement, we plan to compare the usage of randomness to a behavior obtained from chaotic dynamical systems inspired by the domain of mobile robots [START_REF] Fallahi | A cooperative mobile robot task assignment and coverage planning based on chaos synchronization[END_REF].

Conclusions

The ASIMUT project requires:

• Intra-level and inter-level cooperation the latter being without doubt an area that has not been widely explored, especially when autonomy is also a challenge • Management and the optimization of the interactions between the swarms that participate in the mission and how their local decisions and work impact the behavior of the other swarms • Development of distributed and online mobility management algorithms. The latter deal with potentially conflicting objectives such as coverage, connectivity preservation and bandwidth efficiency These innovations will be combined as a global framework for the ASIMUT project and evaluated via state-of-the-art simulations; a preliminary step before its real-world deployment.

Acknowledgements

The authors acknowledge the support of the ASIMUT project A-1341-RT-GP, which is coordinated by the European Defence Agency (EDA) and partially funded by 8 contributing Members (Austria, France, Germany, Italy, Luxembourg, The Netherlands, Poland and Sweden) in the framework of the Joint Investment Programme on Innovative Concepts and Emerging Technologies 2. The ASIMUT project consortium is composed of Thales, Fraunhofer IOSB, Fly-n-Sense, University of Bordeaux and University of Luxembourg.

Contact Information

Martin ROSALIE Campus Kirchberg, E008 martin.rosalie@uni.lu T +352 46 66 44 5751 6, rue Coudenhove Kalergi L-1359 Luxembourg