Richard Combes

Zwi Altman

Eitan Altman

Coordination of Autonomic Functionalities in Communications Networks

Keywords: Self-Organizing Networks, Self-Organization, Self-Optimization, Self-configuration, Stochastic approximation, Stability, Coordination, Dynamical Systems

Future communication networks are expected to feature autonomic (or self-organizing) mechanisms to ease deployment, tune parameters automatically and repair the network. Self-organizing mechanisms are designed as stand-alone entities, even though multiple mechanisms run in parallel in operational networks. An efficient coordination mechanism will be the major enabler for large scale deployment of self-organizing networks. We model self-organizing mechanisms as control loops, and study the conditions for stability when running control loops in parallel. Based on control theory, we propose a distributed coordination mechanism to stabilize the system. In certain cases, coordination can be achieved without any exchange of information between control loops. The mechanism remains valid in the presence of noise via stochastic approximation. Instability and coordination in the context of wireless networks are illustrated with two examples. We are essentially concerned with linear systems, and the applicability of our results for non-linear systems is discussed.

( 1 , 2 )

I. INTRODUCTION

Deployment, optimization and maintenance of communication networks are complex tasks which occupy many network engineers everyday. In order to ease this burden and reduce costs of operations, researchers and industrials have proposed to include autonomic functionalities in future networks. Networks with autonomic entities are often called Selforganizing networks (SON). Self-organization should enable at least partial automation of the configuration of newly deployed network nodes (self-configuration), of parameter tuning (selfoptimization) and of reparation of faulty network nodes (selfhealing).

In wireless networks, SON functionalities such as Inter-Cell Interference Coordination (ICIC), load balancing, management of Base Station (BS) sleep mode, mobility management and drive test automation have been identified as important use cases ( [START_REF] Gpp | Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Self-configuring and self-optimizing network (SON) use cases and solutions[END_REF]). Future standards for wireless networks such as Long Term Evolution (LTE) feature SON functionalities. In previous contributions, SON functionalities have been designed as stand-alone entities ( [START_REF] Stolyar | Self-organizing dynamic fractional frequency reuse for best-effort traffic through distributed inter-cell coordination[END_REF], [START_REF] Combes | Scheduling gain for frequencyselective rayleigh-fading channels with application to self-organizing packet scheduling[END_REF], [START_REF]Self-organization in wireless networks: a flow-level perspective[END_REF], [START_REF] Elayoubi | Optimal control for base station sleep mode in energy efficient radio access networks[END_REF], [START_REF] Combes | Self-organizing relays in LTE networks: Queuing analysis and algorithms[END_REF]). Such contributions did not take into account the interaction between different SON functionalities operating simultaneously. Since SON functionalities are numerous, a large number of SON entities might operate simultaneously in the network. This poses a fundamental stability issue, if we cannot guarantee stable interaction of multiple SON entities. The solution for robust coordination of SON functionalities is probably the most important problem in the domain of SON, and a key enabler for large scale deployment of this technology.

Our contribution:

The main contribution of this paper is to propose a mathematical model for the interaction of multiple SON mechanisms running in parallel, along with a practically implementable coordination mechanism. We model SON mechanisms as control loops, so that the system can be described by an Ordinary Differential Equation (ODE). Stability is studied using the Lyapunov approach used by control theorists. In particular, stability conditions can be stated in terms of linear matrix inequalities ( [START_REF] Boyd | Linear Matrix Inequalities in System and Control Theory[END_REF]). When stability does not hold naturally, we propose a coordination mechanism which forces stability. The design of a coordination mechanism corresponds, in the context of control theory, to the concepts of controllability and state-feedback synthesis. We propose a generic coordination mechanism which can be implemented in a distributed way. When the network is controlled using measurements corrupted by additive noise, the results remain valid using stochastic approximation theorems ( [START_REF] Kushner | Stochastic Approximation and Recursive Algorithms and Applications 2nd edition[END_REF]).

To the best of our knowledge, no previous contribution has studied the problem of SON coordination using this control theory/stochastic approximation-based framework and provided a generic coordination mechanism which is practically implementable (distributed or based on local information).

The rest of the paper is organized as follows: in Section II we state the proposed model for interaction of SON mechanisms running in parallel and the coordination problem to be solved. In Section III we examine the case where performance indicators are linear functions of the parameters, and propose a practically implementable coordination mechanism. In Section IV we study fully distributed coordination when no exchange of information between SONs is needed. In Section V we illustrate the application of our model to traffic management in wireless networks with two examples. Section VI concludes the paper. In appendices A and B we recall the basic notions of stability for ODEs and linear ODEs respectively.

II. SON COORDINATION AS PARALLEL CONTROL LOOPS

A. The model

A SON mechanism is an entity which monitors a given performance indicator and controls a scalar parameter. The current value of the performance indicator is observed, and the parameter is modified accordingly to attain some objective. We consider I > 1 SON mechanisms operating simultaneously. We define θ i the parameter controlled by the i-th SON mechanism and θ = (θ 1 , . . . , θ I ) the vector of parameters. The i-th SON mechanism monitors a performance indicator F i (θ) and updates its parameter θ i proportionally to it. F (θ) = (F 1 (θ), . . . , F I (θ)) is the direction of update of θ.

We say that the i-th SON mechanism operates in standalone mode if all parameters but θ i are kept constant. Namely all the other mechanisms are shut down. The i-th SON mechanism operating in stand-alone is described by the ODE:

θi = F i (θ) , θj = 0, j = i. (1)
We say that the SON mechanisms operate in parallel mode if all parameters are modified simultaneously, which is described by the ODE:

θ = F (θ). (2)
We say that the i-th SON mechanism is stable in stand-alone mode if there exists θ * ,i i which is asymptotically stable for (1). The definition of asymptotic stability is recalled in appendix A. It is noted that θ * ,i i can depend on θ j , j = i. We say that the SON mechanisms are stable in parallel mode if there exists θ * which is asymptotically stable for [START_REF] Stolyar | Self-organizing dynamic fractional frequency reuse for best-effort traffic through distributed inter-cell coordination[END_REF]. Typically, the SON mechanisms are designed and studied in a stand-alone manner, so that stand-alone stability is verified.

However, stand-alone stability does not imply parallel stability. First consider a case where F i (θ) does not depend on θ j , for all pairs (i, j) , j = i. Then (2) is a set of I parallel independent ODEs, so that stand-alone stability implies parallel stability. On the other hand, if there exists i = j such that F i (θ) depends on θ j , then the situation is not so clear-cut. We say that SON i and j interact. Namely, interaction potentially introduces instablity.

In the remainder of this article we will be concerned with conditions for parallel stability, and designing coordination mechanisms to force stability whenever possible.

B. Examples of parallel mechanisms

Two particular cases of parallel mechanisms will be of interest. The first case is what we will call zero-finding algorithms. Each SON mechanism monitors the value of a performance indicator and tries to achieve a fixed target value for this performance indicator. Namely:

F i (θ) = f i (θ) -f i , (3)
where f i is the performance indicator monitored by SON i and f i -a target level for this performance indicator. The goal of the i-th SON mechanism is to find

θ * i such that f i (θ * ) = f i . If θ i → f i (θ 1 , .
. . , θ i , . . . , θ I ) is strictly decreasing 1 ≤ i ≤ I then stand-alone stability is assured. Another case of interest is maximization algorithms. Each SON mechanism tries to maximize a given performance indicator. There exists a continuously differentiable function g i such that:

F i (θ) = ∇ θi g i (θ). (4)
In stand-alone mode, SON i indeed converges to a local maximum of g i . If we restrict θ to a closed, convex and bounded set and if θ i → g i (θ 1 , . . . , θ i , . . . , θ I ) is concave 1 ≤ i ≤ I , we fall within the framework of concave games considered in [START_REF] Rosen | Existence and Uniqueness of Equilibrium Points for Concave N-Person Games[END_REF]. An important result of [START_REF] Rosen | Existence and Uniqueness of Equilibrium Points for Concave N-Person Games[END_REF] is that if we add an assumption called diagonal strict convexity, then parallel stability occurs. However, diagonal strict convexity is fairly restrictive, and without it there is no guarantee that parallel stability occurs, and coordination is needed.

C. Discrete time algorithms

Our model is based on ODEs, which are both deterministic and continuous-time objects. In a practical system, the parameters evolve in discrete time. Furthermore, the parameters evolve stochastically because they are updated based on noisy feedback, due to measurement noise. Denote by

θ[t] = (θ 1 [t], . . . , θ I [t]
) the value of parameters at time t ∈ N. At each parameter update, performance indicators are estimated based on measurements so that SON i obtains the quantity

F i (θ[t]) + M i [t], with E [M i [t]] = 0.
The additive noise {M [t]} t∈N is introduced by the measurements. The parameters are updated using the noisy feedback:

θ[t + 1] = θ[t] + ǫ(F (θ[t]) + M [t]).
(

) 5
where ǫ > 0 is a small constant. Stochastic approximation ([8], [START_REF] Borkar | Stochastic Approximation: A Dynamical Systems Viewpoint[END_REF]) gives a strong link between the noisy, discrete-time [START_REF] Elayoubi | Optimal control for base station sleep mode in energy efficient radio access networks[END_REF] and the ODE studied in our model [START_REF] Stolyar | Self-organizing dynamic fractional frequency reuse for best-effort traffic through distributed inter-cell coordination[END_REF]. In particular it can be shown that (under some technical conditions) {θ[t]} t∈N converges to asymptotically stable sets of the ODE when ǫ → 0 + . Studying ODEs is sufficient to study the stability of the discrete-time, noisy algorithms used in practical systems where ǫ does not vanish, but is a small constant.

III. COORDINATION FOR LINEAR SYSTEMS

A. Linear systems

In the remainder of this paper, we study the case where F is affine:

F (θ) = Aθ + b, (6)
with b a vector of size I and A a matrix of size I × I. We assume that A is invertible and we define θ * = -A -1 b. The SON mechanisms running in parallel are described by the linear ODE:

θ = Aθ + b = A(θ -θ * ). (7)
It is noted that in the linear case, we always fall within the scope of zero-finding algorithms described previously, by defining:

f i (θ) = 1≤j≤I A i,j θ j , f i = -b i , (8)
θi = f i (θ) -f i . (9)
Assumptions 1. A is invertible and

A i,i < 0 , 1 ≤ i ≤ I.
Stand-alone stability occurs if and only if (iff) A i,i < 0 , 1 ≤ i ≤ I, i.e all the diagonal terms of A are strictly negative. Basic results on linear ODEs are recalled in appendix B. Namely, parallel stability holds iff all the eigenvalues of A have a strictly negative real part. We say that A is a Hurwitz matrix. We use assumptions 1 for the rest of this article.

B. Coordination 1) Coordination mechanism:

If A has at least one eigenvalue with positive or null real part, convergence to θ * does not occur, and a coordination mechanism is needed. We consider a linear coordination mechanism, where A is replaced by CA with C a I × I real matrix. The ODE for the coordinated system is:

θ = CA(θ -θ * ). (10)
The coordination mechanism can be interpreted as transforming the performance indicator monitored by SON i from f i to a linear combination of the performance indicators monitored by all the SON mechanisms. For X, X ′ symmetric matrices, we write X ≺ X ′ if X ′ -X is positive definite. As explained in appendix B, stability is achieved if there exists a symmetric matrix X such that:

(CA) T X + XCA ≺ 0 , 0 ≺ X. (11)
In particular,

V (θ) = (θ -θ * ) T X(θ -θ * ), (12)
acts as a Lyapunov function.

2) Distributed implementation: It is noted that the choice for the coordination matrix C is not unique. For instance C = -A -1 ensures stability. For the coordination mechanism to be scalable with respect to the number of SONs, C should be chosen to allow distributed implementation. We say that SON j is a neighbor of SON i if ∂fj ∂θi = 0. We define I i the set of neighbors of i. The coordination mechanism is distributed if each SON needs only to exchange information with its neighbors.

We give an example of a coordination mechanism which can always be distributed. The mechanism is based on a separable Lyapunov function. Define the weighted square error:

V (θ) = I i=1 w i (f i (θ) -f i ) 2 = (θ -θ * ) T A T W A(θ -θ * ), (13)
with w = {w i } 1≤i≤I strictly positive weights and W = diag(w) i.e the diagonal matrix with diagonal elements {w i } 1≤i≤I . Coordination is achieved by following the gradient of -V so that V is a Lyapunov function:

θ = -∇ θ V (θ) = -A T W A(θ -θ * ). (14)
Namely, we choose C = -A T W . We can verify that the mechanism is distributed:

θi = I j=1 2w i ∂f j ∂θ i (f j (θ) -f j ) = j∈Ii 2w j ∂f j ∂θ i (f j (θ) -f j ).
(15) Indeed, the update of θ i only requires knowledge of ∂fj ∂θi and f j (θ)f j , for j ∈ I i , and this information is available from the neighbors of i.

C. Applicability of the linear model and parameter estimation

For practical systems, performance indicators F (θ) are not linear functions of θ. However, as long as they are smooth, they can be approximated by linear functions using a Taylor expansion. Consider a point θ * with F (θ * ) = 0. If the values of θ are restricted to a small neighborhood of θ * :

F (θ) ≈ JF (θ * )(θ -θ * ), (16)
with JF (θ * ) the Jacobian of F evaluated at θ * . The Hartman-Grossman theorem ( [START_REF] Hartman | A lemma in the theory of structural stability of differential equations[END_REF]) states that on a neigbourhood of θ * , stability of the system with linear approximation implies stability of the original, non-linear system. Hence implementing the proposed coordination mechanism where A is replaced by JF ensures stability if we constrain θ to a small neighborhood of θ * . The matrix A might be unknown, and we can only observe noisy values of F (θ) for different values of θ. The crudest approach is to estimate A through finite differences:

a i,j ≈ f j (θ + e i δθ i ) -f j (θ -e i δθ i ) 2δθ i , (17)
with e i the i-th unit vector. The results are averaged over several successive measurements and additive noise is omitted for notation clarity. In general, the measurements of F are obtained by calculating the time average of some output of the network during a relatively long time, so that a form of the central limit theorem applies and the additive noise is Gaussian. In this case, a better method is to employ leastsquares regression. Least-squares regression is a well studied topic with very efficient numerical methods ( [START_REF] Björck | Numerical methods for least squares problems[END_REF]) even for large data sets so that estimation of A is not computationally difficult.

Finally, since practical systems do not remain stationary for an infinite amount of time, a database with values of A for each set of operating conditions must be maintained. In the context of wireless networks, the relationship between parameters and performance indicators changes when the traffic intensity changes because of daily traffic patterns. For instance, during the night traffic is very low, and traffic peaks are observed at the end of the day. If the network can be sampled for a few days, a database with estimated values of A at (for instance) each hour of the day can be constructed.

IV. FULLY DISTRIBUTED COORDINATION

In this section we study fully distributed coordination, where the coordination matrix C is diagonal. As said previously, if C i,j = 0, i = j then SON i and j need to exchange information. In fully distributed coordination, no information is exchanged. We say that the system can be coordinated in a fully distributed way iff there exists c ∈ R I such that diag(c)A is a Hurwitz matrix. The problem was introduced in [START_REF] Fisher | On the stabilization of matrices and the convergence of linear iterative processes[END_REF], to solve linear systems iteratively.

For I = 2 fully distributed coordination can always be achieved. For I = 3 it is also possible iff A -1 has at least one non-zero diagonal element. These results are attractive from a practical point of view: if there are 3 or less SONs to coordinate, it suffices to modify their feedback coefficient, without any exchange of information or interface between them.

Consider N and N ′ subsets of {1, • • • , I} of size q, then the determinant of (A i,j ) i∈N ,j∈N ′ is called a minor of order q. It is a principal minor if N = N ′ , and it is a first minor if q = I -1.

A sufficient and a necessary conditions were given for fully distributed coordination in terms of minors in [START_REF] Fisher | On the stabilization of matrices and the convergence of linear iterative processes[END_REF].

Theorem 1 ([13]). (i) If there exists a sequence of non-zero principal minors M q , q ∈ {1, • • • , I} such that M q-1 is a first principal minor of M q , there exists c ∈ R I such that diag(c)A is a Hurwitz matrix. (ii) If there exists q ∈ {1, • • • , I} such that all principal minors of A of order q are zero then for all c ∈ R I diag(c)A is not a Hurwitz matrix.

[14] gives a constructive result showing that in certain cases, a suitable c can be found by choosing some of its components to be arbitrarily close to 0. This is equivalent to separating the time scales on which certain groups of components of the corresponding ODE evolve.

Theorem 2 ([14]). Decompose A by blocks

A = A 1,1 A 1,2 A 2,1 A 2,2 (18)
with A 1,1 of size q×q and c(ǫ

) = (c 1 , • • • , c q , ǫc q+1 , • • • , ǫc I ). Assume that diag(c 1 , • • • , c q )A 1,1 is a Hurwitz matrix. Then there exists (c q+1 , • • • , c I ) such that diag(c(ǫ))A is a Hurwitz matrix if there exists c ′ such that diag(c ′ )(A 2,2 - A 2,1 (A 1,1 ) -1 A 1,2
) is a Hurwitz matrix.

For I = 2 and I = 3, theorems 1 and 2 give a clear cut solution. We recall a consequence of the Routh-Hurwitz theorem ( [START_REF] Gantmacher | Applications Of The Theory Of Matrices[END_REF]). ii) If (c 1 , c 2 ) = (1, sign det(A)ǫ), then diag(c)A is a Hurwitz matrix for small ǫ > 0.

Proof. i) det(A) = 0 and diagonal elements of A are nonzero. Hence all principal minors of A are non-zero, and theorem 1 proves the result.

ii) tr(diag(c)A) = A 1,1 + O(ǫ) and sign(det(diag(c)A)) = 1. Since A 1,1 < 0, lemma 1 proves that diag(c)A is a Hurwitz matrix for small all ǫ > 0.

Theorem 4. With assumptions 1, for I = 3:

i) If all diagonal entries of B = A -1 are zero, then the system cannot be coordinated in a fully distributed way.

ii) Otherwise, the system can be coordinated in a fully distributed way. Assume that B 2,2 = 0 without loss of generality. Define C(ǫ) = diag(1, ǫc 2 , ǫc 3 ) with:

B 2,2 c 2 + B 3,3 c 3 < 0 , c 2 c 3 det(A) < 0. ( 19
) A possible choice for (c 2 , c 3 ) is c 2 = -B 2,2 and c 3 = -2sign(det(A)c 2 )|B 3,3 | if B 3,3 = 0 and c 3 = -sign(det(A)c 2 ) otherwise. Then C(ǫ)
A is a Hurwitz matrix for all small ǫ > 0.

Proof. i) The diagonal entries of A -1 are proportional to the first principal minors of A by Cramer's rule. So by theorem 1 the system cannot be coordinated since all first principal minors are zero. ii) tr(C(ǫ)A) = A 1,1 + O(ǫ) and:

tr(C(ǫ)A)tr((C(ǫ)A) -1 ) = A 1,1 ǫ ( B 2,2 c 2 + B 3,3 c 3 ) + O(

1).

Since A 1,1 < 0, for small ǫ we have tr(C(ǫ)A) < 0 and tr(C(ǫ)A)tr((C(ǫ)A) -1 ) > 1. Using lemma 1, C(ǫ)A is a Hurwitz matrix for small ǫ > 0.

It is noted that for large I, theorems 1 and 2 are not sufficient since they require a non-polynomial number of operations to obtain a solution. Some search heuristics are given in [START_REF] Roy | Some new results on stabilization by scaling[END_REF]. However, to the best of our knowledge there exists no simple necessary and sufficient conditions on A for fully distributed coordination.

V. APPLICATION TO WIRELESS NETWORKS

In this section we illustrate instability and coordination in the context of wireless networks using two examples. We show that instability occurs even in simple models with as few as two SONs in parallel.

A. Admission control and resource allocation 1) Model:

We consider a BS in downlink, serving elastic traffic. Users enter the network according to a Poisson process with arrival rate λ, to download a file of exponential size σ, with E [σ] < +∞. The BS has x max parallel resources available, and we write x ∈ [0, x max ] the amount of resources used. We ignore the granularity of resources, either assuming that there are a large number of resources or using time sharing, using each resource a proportion x xmax of the time. Depending on the access technology, resources can be: codes in Code Division Multiple Access (CDMA), time slots in Time Division Multiple Access (TDMA), time-frequency blocks in Orthogonal Frequency-Division Multiple Access (OFDMA) etc. When a user is alone in the system, his data rate is Rx. Users are served in a processor sharing manner (for instance through Round Robin scheduling): if there are n active users, each user has a throughput of xR n . Admission control applies. We define β ≥ 0 a blocking threshold and the probability of accepting a new user when n users are already present in the system is φ(nβ) with φ : R → [0, 1] a smooth, strictly decreasing function and φ(n) → n→+∞ 0. We choose φ as a logistic function for numerical calculations:

φ(n) = 1 1 + e n . ( 20
)
Define n(t) the number of active users in the system at time t, then n(t) is a continuous time Markov chain. n(t) is ergodic because the probability of accepting a new user goes to 0 as n → ∞. We define the load:

ρ(x) = λE [σ] xR . ( 21
)
We write π the stationary distribution of n(t). n(t) is reversible, and π can be derived from the detailed balance conditions:

π(n, x, β) = ρ(x) n n-1 k=0 φ(k -β) n≥0 ρ(x) n n-1 k=0 φ(k -β) . ( 22
)
Using Little's law, the mean file transfer time is given by the average number of active users divided by the arrival rate:

T (x, β) = 1 λ n≥0 nπ(n, x, β). ( 23
)
Let R min a minimal data rate required to ensure good Quality of Service (QoS). We say that there is an outage in a state of the system if users have a throughput lower than R min . When there are n active users in the system, outage occurs iff:

n > xR R min . (24)
Denote by 1 . (.) the indicator function, the outage probability is:

O(x, β) = n≥0 π(n, x, β)1 (0,+∞) n - xR R min . ( 25
)
In this model, x → O(x, β) is not smooth, which is why we introduce the smoothed outage Õ:

Õ(x, β) = n≥0 π(n, x, β)ψ n - xR R min . ( 26
)
with ψ a smooth function approximating 1 (0,+∞) . We also choose ψ as a logistic function for numerical calculations. This queuing system is controlled by two mechanisms, and that control occurs on a time scale much slower than the arrivals and departures of the users, so that the mean file transfer time and outage probability are relevant performance metrics, and can be estimated from (noisy) measurements. The mechanisms are:

• Resource allocation: a mechanism adjusts the amount of used resources to reach a target outage rate. Such mechanisms have been considered in green networking when a BS can switch off part of its resources in order to save energy. Another application is interference coordination: using more resources will create inter-cell interference in other BSs and degrade their QoS. Hence BSs should use as little resources as possible, as long as their target QoS is met.

• Admission control: another mechanism adjusts the admission control threshold to reach a target file transfer time. In particular, it is noted that without admission control, the mean file transfer time becomes infinite in overload. It is noted that x → Õ(x, β) is strictly decreasing and β → T (x, β) is strictly increasing. Using the notations of Section II, we have I = 2 control loops,

θ 1 ≡ x, θ 2 ≡ β, f 1 ≡ Õ, f 2 ≡ -T . Consider θ * = (x * , β * ) an operating point.
The stability in the neighborhood of (x * , β * ) can be calculated. The system will fail to converge to the desired operating point as long as the Jacobian matrix has a negative determinant, so that there are two eigenvalues of opposite sign:

- ∂ Õ ∂x ∂T ∂β (x * , β * ) + ∂ Õ ∂β ∂T ∂x (x * , β * ) < 0 (27)
2) Results: We now evaluate the stability region of the system numerically by checking condition (27) for various operating points. We choose the following parameter values: λ = 0.5 users/s, E [σ] = 10 Mbits, R = 15 Mbits/s, R min = 2 Mbits/s, x max = 1. Figure 1 presents the results. In the white region the system is stable, and in the gray region it is unstable. Even in such a simple setting with 1 BS and 2 SON mechanisms, instability occurs for a large set of operating points.

B. Distributed interference control 1) Model:

We turn to a case in which the SONs are not co-located, and distributed coordination is required. We study a model in which each BS can choose its transmitted power in order to control the QoS in the network. We consider a dense network, and the objective of each BS is to make sure that other BSs achieve a target coverage probability, by not transmitting at too high power. We define the coverage probability as the proportion of users whom achieve a given minimum data rate. This is relevant to current wireless networks, where BSs are linked with an interface (called X2 interface in the LTE standard), so that a BS experiencing low data rates or congestion can send an alarm to force other BSs to transmit at lower power to reduce inter-cell interference, or to offload some of its traffic to reduce congestion. We consider N s BSs serving a bounded area A. The zone served by BS i is written A i . Interference from other BSs is treated as Gaussian noise. We denote by h i (r) the signal attenuation between BS i and location r. h i (r) includes both path-loss and shadowing. For numerical calculations, we use the classical model where the signal attenuation (in dB) is a linear function of the distance, and shadowing is (in dB) a centered Gaussian random variable. Fast-fading is ignored. BS i transmits at power P i . The Signal to Interference plus Noise Ratio (SINR) at location r ∈ A s is calculated by:

S i (r) = h i (r)P i N 0 + j =i h j (r)P j , (28)
with N 0 the thermal noise. We denote by R i (r) the data rate at location r when no other users are being served by BS i.

The data rate R i (r) is calculated using the Shannon formula:

R i (r) = w log 2 (1 + S i (r)), (29)
with w the system bandwidth. Consider a target data rate R min . We define K i the coverage probability for BS i, which is the probability that a user arrives in A i at a location r such that R i (r) ≥ R min . The coverage probability can be calculated by:

K i = 1 |A i | Ai 1 {Ri(r)≥Rmin} (r)dr. ( 30
)
Consider users arriving in the network according to a spacetime Poisson process of intensity λ, i.e the average number of users arriving during time dt in a region of size dr centered at location r is λdrdt. Then the number of users arriving during time interval [0, T ] in A i which have a data rate superior to R min , divided by |A i |λT is an unbiased estimate of K i . We define B i the set of BSs exchanging information with i. The relation can either come from geographical proximity, or from propagation conditions, so that BSs exchanging information are BSs which strongly interfere each other.

We define G i the coverage probability of the BSs exchanging information with i by:

G i = j∈Bi |A j |K j j∈Bi |A j | . ( 31
)
We study the case where each BS adjusts its transmitted power P i to avoid degrading the network QoS and make sure that other BSs reach a target coverage probability G i . BS i transmitting at higher power decreases the data rate of users in A j , j ∈ B i , so that P i → G i is strictly decreasing. It is noted that we work with P i in dBm (not in linear scale).

Using the notations of Section II, we have I = N s SONs, with θ i ≡ P i , and f i ≡ G i .

2) Results: For numerical calculations, the signal attenuation (in dB) at distance d (in km) is 128 + 36.4 log 10 (d).

The shadowing standard deviation is 6 dB. The thermal noise power spectral density is -174 dBm/Hz, the system bandwidth w is 20 MHz. The minimal data rate R min is 20 Mbits/s, corresponding to a minimal SINR of 0 dB.

We first consider an hexagonal network with 12 BSs and inter-site distance of 500 m, using a wrap-around to avoid border effects and ensure that all BSs are symmetric. Namely the BSs are placed on a torus. We are interested in stability of the operating point P * , P

* i = 46 dBm , 1 ≤ i ≤ I. The corresponding target value for G i is G i = 80%, 1 ≤ i ≤ I.
Without coordination, this operating point is unstable as shown by calculating the Jacobian of G at P * using finite differences and calculating its eigenvalues. Another illustration of instability is given by plotting trajectories of the corresponding (nonlinear) ODE starting in a neighbourhood of P * . On figures 2 and 3 we represent the transmitted powers and coverage probabilities respectively as a function of time obtained by discretization of the ODE. Only BSs 1, 2 and 3 are represented for clarity, where BSs 2 and 3 exchange information with BS 1. Clearly, P * is not stable and the plotted solution does not remain close to P * . On figures 4 and 5 we show the same quantities when the coordination mechanism is applied with C = -(JG(P * )) T as explained in the previous section. Indeed, the solution stays close to P * at all times.

Practical networks do not exactly follow an hexagonal model due to non-uniformity of traffic and scarcity of sites with good propagation characteristics. A popular model to take into account this irregularity is to assume that BSs locations follow a Poisson point process on the plane. Based on measurements from operational networks, results in [START_REF] Andrews | A tractable approach to coverage and rate in cellular networks[END_REF] suggest that from the point of view of coverage, the Poisson model is pessimistic while the hexagonal model is optimistic and reality lies somewhere in-between. We show that, like in the hexagonal case, instability occurs with a non-negligible probability. Hence instability is not an artifact of the hexagonal model.

We use the following procedure. For each snapshot we generate BS locations according to a Poisson process on a square area of 4 km 2 , and we find a point P * = {P * i } 1≤i≤I at which all BSs have the same coverage probability. To be consistent with the hexagonal model, each BS exchanges information with the 6 closest BSs (in terms of distance). We calculate the Jacobian matrix of G at P * to assess its stability. We simulate 100 snapshots to estimate the probability of observing an unstable network. Figure 6 shows the probability of instability for different values of the number of BSs per unit of surface. There is a non-negligible probability of instability, and this probability rapidly goes to 1 when the network becomes denser. An intuitive explanation is that when the network gets denser, BSs become closer to each other, so that the coupling between the corresponding SON mechanisms becomes stronger and causes instability. In this paper we have studied the problem of coordinating multiple SON entities operating in parallel. Using tools from control theory and Lyapunov stability, we have proposed a coordination mechanism to stabilize the system. The mechanism can be implemented in a distributed fashion so it is scalable with respect to the number of SONs. We have shown that the mechanism remains valid in the presence of measurement noise, using stochastic approximation. Instability and coordination in the context of wireless networks have been illustrated with two examples. We have shown that even for two control loops, instability can occur, and the influence of network geometry has been investigated. An interesting continuation

Lemma 1 .Theorem 3 .

 13 (Routh-Hurwitz) Consider M a I × I matrix. (i) (I = 2) M is a Hurwitz matrix iff det(M ) and -tr(M ) are strictly positive, (ii) (I = 3) M is a Hurwitz matrix iffdet(M ) and -tr(M ) and tr(M )tr(M -1 ) -1 are strictly positive. With assumptions 1, for I = 2: i) the system can always be coordinated in a fully distributed way.

Fig. 1 .

 1 Fig. 1. Stability region of the system

Fig. 2 .Fig. 3 .Fig. 4 .Fig. 5 .

 2345 Fig. 2. Hexagonal network, no coordination, transmitted powers as a function of time

Fig. 6 .

 6 Fig. 6. Probability of observing an unstable network as a function of the density of BSs

This work has been partially carried out in the framework of the FP7 UniverSelf project under EC Grant agreement

[START_REF] Stolyar | Self-organizing dynamic fractional frequency reuse for best-effort traffic through distributed inter-cell coordination[END_REF] The first author is now with KTH, major parts of this work were done while he was with Orange Labs

ACKNOWLEDGMENT

The authors are grateful to Abdoulaye Tall for pointing out the works of Fisher and Roy.

APPENDIX A ASYMPTOTIC BEHAVIOR OF ODES

Consider the ODE θ = F (θ), which we assume to have a unique solution for each initial condition defined on R + . We write Φ(t, θ(0)) the value at t of the solution for initial condition θ(0). We denote by d

the basin of attraction. A compact invariant set U is locally asymptotically stable if it is both Lyapunov stable and an attractor. If its basin of attraction A is equal to the whole space then U is globally asymptotically stable. Asymptotic stability is often characterized using Lyapunov functions. A positive, differentiable function V : R I → R, is said to be a Lyapunov function if t → V (Φ(t, θ(0))) is decreasing, and strictly decreasing whenever V (Φ(t, θ(0))) > 0. Then the set of zeros of V is locally asymptotically stable. If we add the condition V (θ) → θ →+∞

+∞, then we have global asymptotic stability.

APPENDIX B LINEAR ODES

Consider the ODE: θ = A(θ-θ * ). Its solution has the form:

θ * is asymptotically stable iff all the eigenvalues of A have a strictly negative real part. Alternatively, asymptotic stability applies iff there exists 0 ≺ X such that A T X + XA ≺ 0. In this case, V (θ) = (θθ * ) T X(θθ * ) is a Lyapunov function for the ODE. The reader can refer to [START_REF] Boyd | Linear Matrix Inequalities in System and Control Theory[END_REF] for the linear matrix inequality approach to stability.


David Méndez-Acuña

Rubby Casallas

Anne ④❞❢✳♠❡♥❞❡③✼✸✱r❝❛s❛••❛⑥❅✉♥✐❛♥❞❡s✳❡❞✉✳❝♦

Etien

❛ ♥♥❡✳❡t✐❡♥❅✉♥✐✈✲

On the customization of model management systems for file-centric IDEs

Keywords: D.2.2 [Software engineering]: Design Tools and Techniques -Computer-aided Software Engineering Model-driven software development, integrated development environment, model management, megamodeling

Model-based solutions are becoming more sophisticated because of the advent of new types of models, languages, and editors. To deal with this complexity, some of the current Integrated Development Environments (IDEs) offer Model Management Systems (MMSs) that provide functionalities to visualize, navigate, and search the modeling artifacts existing in a workspace. Each MMS defines the types of modeling artifacts that it supports and, commonly, furnish extensibility mechanisms for including new ones. However, the use of those mechanisms usually requires a big implementation effort. As a result, when an MMS does not support all the types of modeling artifacts that a model-driven engineer uses, he/she discards it and ends up manipulating his/her solution through file system views which is not appropriate when projects become larger. In this paper we present some of our preliminary results towards the construction of MoMS-DL, a domain-specific language to define (and automatically generate) customized Eclipse-based MMSs improving the daily work of model-driven engineers.

Introduction

The use of model-driven engineering (MDE) has increased in the last years. Nowadays, there is large variety of tools, languages, and editors that model-driven engineers can use during the construction of models-based solutions. In fact, they use not only models, metamodels and transformations but also weaving models, high-order transformations, UML profiles, grammars for domain-specific languages, among others modeling artifacts [START_REF] Kling | Moscript: A dsl for querying and manipulating model repositories[END_REF]. As a result, the process of building a model-based solution is becoming more and more complex.

In order to improve the productivity of model-driven engineers, it is desirable to have suitable IDEs that facilitate the manipulation 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. DSM '13, October 27, 2013, Indianapolis, Indiana, USA. Copyright c 2013 ACM 978-1-4503-2600-1/13/10. . . $15.00. http://dx.doi.org/10.1145/2541928.2541939 of modeling artifacts by offering facilities such as friendly visualization, navigation, and searching [START_REF] Lucrédio | Moogle: a metamodel-based model search engine[END_REF]. Such facilities can be easily found in IDEs designed from scratch for model-based techniques (e.g., MetaEdit+ [START_REF] Kelly | Metaedit+ a fully configurable multi-user and multi-tool case and came environment[END_REF]). However, the situation changes in the case of other IDEs initially conceived for code based paradigms that have been later adapted for supporting model-based technologies (e.g., Eclipse Modeling Framework [START_REF] Steinberg | EMF: Eclipse Modeling Framework 2.0[END_REF]). In this case, the IDEs are implemented based on the idea that a software solution is a set of code files written in some specific language that can be opened by using particular editors. Since models are also considered as files, models-based projects become folders containing several types of files and the semantics of each file has to be understood and memorized by the model-driven engineer.

The idea of enriching file-centric IDEs for providing modelcentric capabilities has been largely studied in the literature under the concept "model management". Because of this, one can find several model management systems (MMSs) built on the top of file-centric IDEs. In fact, three common elements can be identified among MMSs: (1) metadata repositories; (2) models-centric views; and (3) searching engines. A metadata repository is a software artifact where some relevant information about the modeling artifacts (such as their location) is stored. The model-centric views show the modeling artifacts organized in hierarchies defined by their role in the models-based solution instead of their location in the file system. The searching engine is composed of several queries over the metadata repository that facilitate the searching of modeling artifacts. One of the best known examples of this type of MMSs is the AMMA platform presented by Bézivin et al in [START_REF] Bézivin | Modeling in the large and modeling in the small[END_REF]. In that case, the metadata repository is a model that the authors term as megamodel; the models-centric views show the modeling artifacts classified by their types (e.g., metamodel, transformation, UML profile); and the searching engine is a set of OCL-based queries over the megamodel.

Commonly, the scope of an MMS is limited to a predefined set of modeling artifacts and, in order to increase their functionality, these tools offer extensibility mechanisms. The idea is that model-driven engineers can extend the MMS if they use types of modeling artifacts that are not initially included in the scope of the MMS. However, the use of those extensibility mechanisms requires a deep understanding of the software architecture and, in many cases, the code. From our point of view, this is one of the main shortcomings of the current approaches because, before extending a MMS, model-driven engineers prefer to manipulate their modeling artifacts by means of the classical file system views that IDEs like Eclipse offers by default. This is not appropriate when models-based solutions become large.

In this paper we present our preliminary results towards the construction of an approach that facilitates the customization of MMSs. To do so, we first motivate the problem by illustrating some of the shortcomings that model-driven engineers have to deal with when they do not use any MMS. Then, we introduce a tool that provides: ❶ a domain-specific language, called "MoMS-DL", that enables the definition of MMSs; and ❷ a generation process that, from a MoMS-DL script, automatically generates a customized MMS that overcomes the studied shortcomings. Each of our generated MMSs is composed of a metadata repository and a set of features for friendly visualization and searching of modeling artifacts within a models-based solution.

This remainder of this paper is structured as follows: Section 2 introduces a set of definitions we use along the rest of the paper. Specifically, it clarifies the vocabulary concerning to metadata registries and megamodeling. Section 3 presents a motivating example that we use in Section 4 for describing the shortcomings of code centric IDEs for MDE. Also, we use this example in Section 5 for illustrating the MoMS-DL language and explaining the generation process for MMSs. Section 6 discuses the related work and Section 7 concludes the paper and presents the future work.

Background

The use of the term "metadata" has become very popular to the point that it is difficult to find a definition that encompasses all the meanings that this term has received [START_REF] Laskey | Metadata concepts to support a net-centric data environment[END_REF]. Indeed, the abstract idea of metadata as "data about data" seems to be the only point where all these definitions agree. In this sense, it is important to identify: [START_REF] Bézivin | Modeling in the large and modeling in the small[END_REF] what are the data that need to be considered and ( 2) what are the data (about the data to be considered) that are relevant and that should be stored. From the implementation point of view, the "metadata repository" is the software artifact where the metadata is physically stored whereas the "metadata schema" is the definition of the structure that the metadata repository must conform to.

In the case of the MMSs for MDE, the data to be considered correspond to the set of modeling artifacts involved in a modeldriven solution whereas the data to be stored correspond to the location of the modeling artifacts and the relationships existing among each of them. Furthermore, metadata repositories can be implemented as a special type of models (termed "megamodels") whose structure is defined in metamodels [START_REF] Kling | Moscript: A dsl for querying and manipulating model repositories[END_REF][START_REF] Vignaga | Typing artifacts in megamodeling[END_REF].

Figure 1: A simple megamodel (metadata repository) Figure 1 illustrates the previous definitions by using a simple situation in an Eclipse workspace that contains a model-based solution composed of three modeling artifacts: a metamodel ▼▼❆, a metamodel ▼▼❇, and a model-to-model transformation ❆✷❇ that produces models conforming to ▼▼❇ from models conforming to ▼▼❆. These three modeling artifact correspond to the data to consider. The metadata repository (implemented as a megamodel) contains the information about their location and the relationships among them. In this case, the relationships are the dependencies between the transformation and the metamodels i.e., source and target. The megamodel conforms to a metamodel that defines the supported types of modeling artifacts i.e., metamodels and transformations, and the interesting relationships.

Motivating example: An MTC for prototyping maze-games

We propose, as motivating example, a software development scenario where a model-driven engineer builds a model-based solution for maze-games automatic prototyping [START_REF] Morales | Model-driven game development -case study. a mtc for maze-game s prototyping[END_REF]. Specifically, this solution is a model transformation chain (MTC) that, from a high-level game model, automatically produces the code of the game that can be deployed in the games engine Torque2D [START_REF] Garagegames | Torque2d: An engine to 2d games development[END_REF]. We chose this example because, although simple, its implementation requires more than models, metamodels, and transformations. Weaving models and domain-specific languages are also involved.

Maze-games

In general, a maze game consists of a playground where different objects can be placed. The game turns around a main character, usually controlled by the player, that has to develop a particular purpose during the game. Depending on the game, the main character must interact with other elements in order to achieve the goal. Depending on their behavior, these elements can be either dynamic or static depending. Dynamic elements develop some actions whereas static elements are either obstacles or boundary delimiters for the playground. Pacman is one of the most famous example of this type of games. In this case, the main character is the yellow smileyface that dies if touched by the ghosts (dynamic elements) and that feeds the intermittent strawberries (static elements) for increasing the score.

MTC for maze-games prototyping

The inputs of the generation process (shown at the top of Figure 2), are threefold: (i) a maze game model; (ii) an instances model; and (iii) a weaving model between (i) and (ii). The maze game model contains the definition of the game and includes a characterization of the elements existing in the game (dynamics and statics). These elements are defined in terms of their properties and the way in which they interact each other. The instances model specifies the amount of each type of element that should be instantiated for a particular level and their initial positions. Because the definition of the element types and the instances are defined in separate models, it is necessary to provide a weaving model for relating each element type with each instance type. These models are input of a modelto-model transformation that creates a platform specific model with the definition of the game in terms of the Torque2D concepts. Then, this model is transformed to TorqueScript code that can be finally deployed in the games engine.

Some shortcomings of file-centric IDEs adapted for MDE

In this section we use the motivating example presented above to illustrate some of the shortcomings of classical IDEs that modeldriven engineers have to deal with when they do not use any MMS.

Models visualization

The first shortcoming refers to the visualization and manipulation of a model-based solution where models have to be manipulated in code-centric views such as the package explorer or project navigator. In such views, models are treated as data files without any differentiation from code or documentation artifacts. As a result, a model-based solution looks like a set of projects and the semantics of each of them is only stored in the mind of the engineer. Figure 2 illustrates this fact. At the top there is an abstract representation of the MTC for generating maze-games code. This representation is very close to the way in which the model-driven engineer imagines the MTC. At the button, we show the way in which the model-driven engineer actually visualizes the MTC in a code-centric view. Notice that those images are not similar at all. Indeed, the model-driven engineer is responsible for understanding how the projects represent each of the artifacts that compose the model-based solution.

Models searching

The second shortcoming is related to the way in which modeldriven engineers search models. While java developers have enhanced searching mechanisms that allow to perform specialized searches in terms of classes, methods, attributes, and interfaces; model-driven engineers have to comply with the classical file search. Since this type of search is exclusively based on syntax matches, there is a large amount of non-relevant search results when the files are written in modeling languages such as UML, XMI, or ECORE. Suppose for example that the model-driven engineer needs to know the set of models conforming to a given metamodel. He/she would have to perform a file search with the URI of the metamodel. As a result, the model-driven engineer will obtain not only the models but also all the artifacts that contains that URI including java code and configuration files.

Our approach

As already said earlier, these limitations can be overcome by means of the construction of well-engineered MMSs. The problem arises when a model-driven engineer requires to use modeling artifacts that are not supported by the selected MMS and, hence, customization is required. Most of the MMSs that offer some type of customization provide strategies based on extensibility. In that sense, the software developer that wants to extend the MMS should: understand the extensibility strategy; build the extensions (probably writing code and/or models); re-compile the code of the platform; and re-install it. In this process, software developers need to understand some implementation issues of the MMS and, in most of cases, they are not necessary willing to deal with all this additional work. As a result, the use of MMSs is usually discarded when those does not fulfill by default all the initial requirements.

In order to avoid this limitation, we propose raising the level of abstraction in which customization is performed. Hence, we provide MoMS-DL (Model Management Systems Definition Language), a domain-specific language where the requirements of a specific model-driven engineer can be expressed and we offer a generation process that automatically produces the code of the MMS. In other words, we enable customization by automatic generation instead of customization by extensibility.

MoMS-DL: language concepts

We believe that the requirements that a model-driven engineer demands to a MMS can be expressed in terms of the types of modeling artifacts involved in a model-driven solution and the existing relationships among them. Our hypothesis is that, if we have that information, we can automatically produce a MMS that offer model-centric capabilities specialized in those artifacts. In that sense, MoMS-DL is a language intended to provide the expressiveness enough for defining a megamodel (i.e., a model that represents a set of modeling artifacts and the relationships among them).

Figure 3 shows the MoMS-DL metamodel. In that metamodel the central concept is the ▼❡t❛▼❡❣❛▼♦❞❡• that is composed by a set of modeling artifacts represented by the ❆rt✐❢❛❝t❚②♣❡ concept. Each artifact type has references and attributes. A reference represents a relationship between two types of modeling artifacts whereas an attribute refers to a typed characteristic i.e., string, integer, double, float. Both, references and attributes have a multiplicity definition. • A metamodel is an artifact type that has two attributes: the path and the URI. The path is a string representing the location of the file in the workspace whereas the URI is a string with an address that can be used for locating the metamodel in the web.

• A model is an artifact type that, besides its only attribute ✧♣❛t❤✧ referring to its location in the workspace, has a relationship called ✧❝♦♥❢♦r♠s❚♦✧ to the type Metamodel that represents the conformance relationship.

• A model-to-model transformation is an artifact type that, besides its only attribute ✧♣❛t❤✧ referring to its location in the workspace, has two references to metamodel referring to the ✧s♦✉r❝❡✧ and ✧t❛r❣❡t✧ metamodels of the transformation.

• A weaving model is an artifact type that has the ✧♣❛t❤✧

Tool implementation and model management systems generation process

We implemented MoMS-DL with EMFText [START_REF] Wende | Emftext. concrete syntax mapper[END_REF]. Consequently, we can offer a friendly editor with content assistance and syntax coloring. Meantime, the generation of model management systems from MoMS-DL scripts is a process composed by three different code generators. They produce the metadata repository; the models-centric views; and the models searching engine. Let us explain each of those generators.

Generation of the metadata repository

The result of this generation process is a metadata repository implemented as a megamodel. To achieve this, we need: (1) a metamodel for the megamodel; and (2) a mechanism for manipulating megamodels by creating, deleting and updating the references to the concrete files so the metadata repository can be synchronized with the file system.

• Construction of the metamodel for the megamodel: The metamodel of the megamodel can be built directly from the MoMS-DL script since it contains the types of modeling artifacts and the relationships among them. Hence, we just need to transform the MoMS-DL script to a metamodel. To do so, we first parse the MoMS-DL script and obtain a model that conforms to the MoMS-DL metamodel. Figure 4 shows the metamodel for the megamodel that would be generated for our motivating example expressed in Listing 1. Notice that it is just two different representations of the same thing. However, having this information expressed in a metamodel allows to have a model where the metadata is directly stored. Figure 5 illustrates this idea by presenting a segment of the megamodel (represented as an objects model) corresponding to the metadata of the model-to-model transformation from maze-games to Torque2D. In that model, each modeling artifact is represented by an object that is an instance of a particular artifact type of the metamodel. As a result, we can have a structured metadata that can be manipulated and consulted. • Manipulation of the megamodel: In order to maintain the megamodel synchronized with the file system, we automatically generate a set of CRUD operations that allow to manipulate the megamodel programmatically by creating, removing and updating megamodel elements (i.e., references to concrete files). Then, we offer a set of menu options that enable the invocation of such CRUD operations on the megamodel by including new artifact types. In that sense, the model-driven engineer is responsible for using those menu options in order to maintain the megamodel up to date.

Generation of the model-centric project views

As we said before, the classical file system views provided by code centric IDESs show the modeling artifacts by using a file system structure. From our point or view, a model-centric project view should give a global perspective of the modeling artifacts existing in the workspace classified them by their types and not by their location in a folder hierarchy. Hence, from each MoMS-DL script we generate a model-centric project view where, for each ❆rt✐❢❛❝t❚②♣❡ we include a modeling artifact category. This generation process is based on a model transformation chain that produces a model-centric view from the MoMS-DL script. Figure 6 illustrates the generated view for the case of our motivating example.

Figure 6: Code-centric view vs. models centric view

Generation of the searching engine

In order to improve the way in which the model-driven engineer searches modeling artifacts, we provide a model searching engine based on the relationships among modeling artifacts defined in the MoMS-DL script. For each relationship, we generate two OCL queries for bi-directional searching. Each query is implemented as an OCL statement that is executed over the instance of the megamodel for the current workspace. The results are manipulated and displayed in the corresponding searching results view.

Related work

Despite research in model management is not new, so far there is not a consensus about what that term exactly means. Indeed, there are (at least) two conceptions about how model management should be addressed. 1) operations-based model management systems: they intent to facilitate the definition and execution of diverse operations on models such as transformation, merging, or comparison; 2) indexation-based model management systems: they intent to facilitate manipulation of interdependent modeling artifacts by means of indexation (i.e., capability of maintaining metadata registries that store the references among models).

In the first case, the prime example would be the EPSILON suite [START_REF] Paige | The design of a conceptual framework and technical infrastructure for model management language engineering[END_REF] that aims at providing a family of interoperable languages. Those languages are "task-specific" what means that each of them is intended to support a special type of operation. Thus, the modeldriven engineer has a specific language to implement transformations, another for merging, matching, and so on. There are other approaches, such as [START_REF] Rose | Genericity for model management operations[END_REF], that offer customization mechanisms for operations-based MMSs. Thus, model-driven engineers can define generic-operations that can be applied to different types of modeling artifacts. For example, a merging operation that may be used on both models and metamodels.

In this paper we are more interested on indexation-based model management systems where one of the most famous example is the AMMA platform [START_REF] Bézivin | Modeling in the large and modeling in the small[END_REF]. AMMA provides a complete infrastructure for supporting indexation of modeling artifacts following the concepts of modeling in-the-large introduced by Jean Bézivin [START_REF] Bézivin | Modeling in the large and modeling in the small[END_REF]. This platform provides a megamodel, i.e., the metadata registry, and, based on it, a pool of functionalities for facilitating the tasks of model-driven engineers. Some of those functionalities are: Eclipse views for navigating modeling artifacts; and searching engines. The Eclipse views are intended to display modeling artifacts involved in a models-based solution classified by their types instead of the file system hierarchy where they are located. The models searching engine [START_REF] Kling | Moscript: A dsl for querying and manipulating model repositories[END_REF] is based on a domain-specific language that provides not only specialized searching for modeling artifacts but also programmatic execution of operations for models manipulation. Similarly to AMMA, it focuses on supporting the idea of "manipulating collections of related models" by offering Eclipse-based tool support for models metadata and operations execution. This approach offers also a graphical editor where the model-driven engineer manually indexes the modeling artifacts in a registry that, latter, serves to automate execution of the operators.

Conclusions and future work

The main contribution of our work is to provide mechanisms for helping to the model-driven engineers to create customizable model management systems (MMSs). With the MMSs the model-driven engineers can have a better user experience with the IDE to develop their model-driven solutions. To have these suitable MMSs is important because model-driven solutions have become more and more sophisticated in terms of the amount and divers types of modeling artifacts they use. The contribution is in concrete the MoMS-DL language that allows model-driven engineers to define arbitrary megamodels. These megamodels are used as metadata repositories that contain the relationships existing among modeling artifacts. Besides, from the scripts in MoMS-DL and using the metadata registry we generate automatically a pool of plugins to improve the productivity of the developer.

There is still a long path to follow. Our on-going work includes extensions to the functionalities our plugins can offer.We are working also on including the ideas of operations-based model management systems by providing a work-flow language to define new operations (simple and composite) to manipulate modeling artifacts and the generation of the corresponding tooling.

Figure 2 :

 2 Figure 2: Code-centric views for model-based projects

Figure 3 :

 3 Figure 3: MoMS-DL metamodel

  attribute and three references. The first reference is called ✧✇❡❛✈✐♥❣▼▼✧ and refers to the metamodel that contains the well-formedness constraints of the weaving. The other two references called ✧•❡❢t▼♦❞❡•✧ and ✧r✐❣❤▼♦❞❡•✧ refer to the left and right parts of the weaving. ▲✐st✐♥❣ ✶✿ ❉❡✜♥✐t✐♦♥ ♦❢ t❤❡ ▼❡t❛▼❡❣❛▼♦❞❡•

Figure 4 :Figure 5 :

 45 Figure 4: Metamodel of the metamodel for the maze-games example