Benoît Combemale

Laurent Broto

Xavier Crégut

Michel Daydé

Daniel Hagimont

Autonomic Management Policy Specification: from UML to DSML

Autonomic computing is recognized as one of the most promizing solutions to address the increasingly complex task of distributed environments' administration. In this context, many projects relied on software components and architectures to provide autonomic management frameworks. We designed such a component-based autonomic management framework, but observed that the interfaces of a component model are too low-level and difficult to use. Therefore, we introduced UML diagrams for the modeling of deployment and management policies. However, we had to adapt/twist the UML semantics in order to meet our requirements, which led us to define DSMLs. In this paper, we present our experience in designing the Tune system and its support for management policy specification, relying on UML diagrams and on DSMLs. We analyse these two approaches, pinpointing the benefits of DSMLs over UML.

Introduction

Today's computing environments are becoming increasingly sophisticated. They involve numerous complex software that cooperate in potentially large scale distributed environments. These software are developed with very heterogeneous programming models which rely on their own specific configuration facilities. Moreover, software environments integrate components from different providers with proprietary management interfaces. Therefore, the management1 of these software (installation, configuration, repair, etc.) is a much complex task which consumes a lot of human ressources.

A very promising approach consists in implementing administration features as an autonomic software. Such a software can be used to deploy and configure applications in a distributed environment. It can also monitor the environment and react to events such as failures or overloads and reconfigure applications accordingly and autonomously. Many works in this area have relied on a component model to provide such an autonomic system support [START_REF] Garlan | Rainbow: Architecture-based self adaptation with reusable Infrastructure[END_REF][START_REF] Hagimont | Autonomic Management of Clustered Applications[END_REF][START_REF] Oriezy | An Architecture-Based Approach to Self-Adaptive Software[END_REF]. The basic idea is to encapsulate the managed elements (legacy software) in software components (called wrappers) and to administrate the environment as a component architecture. We designed and implemented such P r e l i m i n a r y V e r s i o n a component-based autonomic management system (called Tune) and used it for the management of complex legacy software infrastructures. However, we rapidly observed that the interfaces of a component model are too low-level and difficult to use. This led us to explore the introduction of higher level formalisms for all the administration tasks (wrapping, configuration, deployment, reconfiguration). Our main motivation was to hide the details of the component model we rely on and to provide a more abstract and intuitive specification interface (such specifications are called management policies). We mainly relied on UML diagrams for the modeling of management policies, but as we were not experts in modeling languages and were more focussed on middleware issues, we made use of UML diagrams which are very pragmatic and close to our needs, and we had to adapt/twist the UML semantics in order to meet our requirements. This naturally led us to define Domain Specific Modeling Languages (DSMLs) and their associated metamodels.

In this paper, we report on this experience which consisted in three steps: [START_REF] Garlan | Rainbow: Architecture-based self adaptation with reusable Infrastructure[END_REF] designing a component-based autonomic system, (2) introducing management policy specification formalisms based on UML diagram and (3) defining several DSMLs for policy specification. And we motivate the transition between each step.

The rest of the paper is structured as follows. Section 2 describes the design and implementation of Tune, which provides a framework for component-based autonomic administration. Section 3 presents our experience in providing UML diagram based support for management policy specification. The DSML support introduced for policy specification is presented in Section 4. After an overview of related works in Section 6, we overview the lessons learned from these experiments in Section 5 and we conclude in Section 7.

An Autonomic Management System 2.1 J2EE Use Case

The Java 2 Platform, Enterprise Edition (J2EE) defines a model for developing web applications [START_REF] Microsystems | Java 2 Platform Enterprise Edition (J2EE)[END_REF] in a multi-tiered architecture. Such applications are typically composed of a web server (e.g. Apache), an application server (e.g. Tomcat) and a database server (e.g. MySQL). Upon an HTTP client request, either the request targets a static web document, in which case the web server directly returns that document to the client; or the request refers to a dynamically generated document, in which case the web server forwards that request to the application server. When the application server receives a request, it runs one or more software components (e.g. Servlets, EJBs) that query a database through a JDBC (Java DataBase Connection) driver. Finally, the resulting information is used to generate a web document that is returned to the web client.

In this context, the increasing number of Internet users has led to the need of highly scalable and highly available services. To face high loads and provide higher scalability of Internet services, a commonly used approach is the replication of servers in clusters. Such an approach (Figure 1, legacy layer) usually defines a particular software component in front of each set of replicated servers, which dynamically balances the load among the replicas. Here, different load balancing algorithms may be used, e.g. Random, Round-Robin, etc.

P r e l i m i n a r y V e r s i o n

This example is characteristic of the management of a distributed software infrastructure where very heterogeneous servers are distributely deployed, configured and interconnected in order to provide a global service. The management of the whole infrastructure can be very complex and requires a lot of expertise. Many files have to be edited and configured consistently. Also, failures or load peaks (when the chosen degree of replication is too low) must be treated manually.

Component-Based Autonomic Computing

Component-based management aims at providing a uniform view of a software environment composed of different types of servers. Each managed server is encapsulated into a component and the software environment is abstracted as a component architecture. Therefore, deploying, configuring and reconfiguring the software environment is achieved by using the tools associated with the used component-based middleware.

The component model we used in Tune is the Fractal model [START_REF] Bruneton | The Fractal Component Model and its in Java. In: Software -Practice and Experience, special issue on Experiences with Auto-adaptive and Reconfigurable Systems[END_REF]. A Fractal component is a runtime entity that is encapsulated and has one or several interfaces (access points to a component that supports a finite set of methods). The signatures of interface can be described by a standard Java interface declaration. Components can be assembled to form a component architecture by binding components interfaces (different types of bindings exists, including local bindings and distributed RMI-like bindings). An (XML based) Architecture Description Language (ADL) allows describing an architecture and an ADL launcher can be used to deploy such an architecture. Finally, Fractal provides a rich set of control interfaces for introspecting (observing) and reconfiguring a deployed architecture, i.e. controlling components' attributes and bindings.

Any software managed with Tune is wrapped into a Fractal component which interfaces its administration procedures. Therefore, the Fractal component model is used to implement a management layer (Figure 1) on top of the legacy layer (composed of the actual managed software). In the management layer, all components provide a management interface for the encapsulated software, and the corresponding implementation (the wrapper) is specific to each software (e.g. the Apache web server in the case of J2EE). Fractal's control interfaces allow managing the element's attributes and bindings with other elements, and the management interface of each component allows controlling its internal configuration state. Relying on this management layer, sophisticated administration programs can be implemented, without having to deal with complex, proprietary configuration interfaces (generally configuration files), which are hidden in the wrappers. Here, we distinguish two important roles: (1) the role of the management and control interfaces is to provide a means for configuring components and bindings between components. It includes methods for navigating in the componentbased management layer or modifying it to implement reconfigurations. (2) the role of the wrappers is to reflect changes in the management layer onto the legacy layer. The implementation of a wrapper for a specific software may also have to navigate in the component management layer, to access key attributes of the components and generate legacy software configuration files2 .

P r e l i m i n a r y V e r s i o n

Management Policy Specification

In a first prototype (Jade [START_REF] Hagimont | Autonomic Management of Clustered Applications[END_REF], a predecessor of Tune), the implementation of management policies was directly relying on the interfaces of the Fractal component model:

-A wrapper was implemented as a Fractal component, developed in Java, which main role is to reflect management/control operations onto the legacy software. For instance, if we consider the wrapper of the Apache software, the assignment of the port attribute of the wrapper is reflected in the httpd.conf file in which the port attribute is defined. Similarly, setting up a binding between an Apache wrapper and a Tomcat wrapper is reflected at the legacy layer in the worker.properties file. -The description of a software architecture to be deployed was described in a Fractal ADL file. This ADL file describes in an XML syntax the set of components (wrappers) to instanciate (which will in turn deploy the associated legacy software components), their bindings and their configuration attributes. -Reconfigurations were developed in Java, relying on Fractal APIs. These APIs allow invoking components' management interfaces or Fractal control interfaces for assigning components' attributes, adding/removing components and updating bindings between components.

Component-based autonomic computing has proved to be a very convenient approach. The experiments we conducted with this first prototype for managing J2EE infrastructures [START_REF] Hagimont | Autonomic Management of Clustered Applications[END_REF] (but also other distributed infrastructures such as Diet grid middleware [START_REF] Toure | Autonomic Management for Grid Applications[END_REF]) validated this design choice. Figure 2 illustrates an experiment which consisted in automatically repairing (restarting) a failing Tomcat server (in the J2EE architecture of Figure 1). Initially, the load is balanced between the two replicas. When the failure occurs, all the load is addressed to the second replica. After repair, the load is again balanced between the two replicas.

UML-Based Autonomic Computing Policies Specification

As our system was used by external users (external to our group), we rapidly observed that the interfaces of a component model are too low-level and difficult to use. In order P r e l i m i n a r y V e r s i o n wrapping components is difficult to implement. The developper needs to have a good understanding of the component model we use (Fractal). Regarding wrapping, our approach is to introduce a Wrapping Description Language which is used to specify the behavior of wrappers. A WDL specification is interpreted by a generic wrapper Fractal component, the specification and the interpreter implementing an equivalent wrapper. Therefore, an administrator doesn't have to program any implementation of Fractal component. architectures are not very easy to describe. ADLs are generally very verbose and still require a good understanding of the underlying component model. Moreover, if we consider large scale software infrastructure such as those deployed over a grid, describing an architecture composed of a thousand of servers requires an ADL description file of several thousands of lines. Our approach is to reuse UML formalisms for graphically describing architecture schemas. First, a UML based graphical description of such an architecture is much more intuitive than an ADL specification, as it doesn't require expertise of the underlying component model. Second, the introduced architecture schema is more abstract than the previous ADL specification, as it describes the general organisation of the application to deploy (types of software, interconnection pattern) in intension, instead of describing in extension all the software instances that may compose the architecture. This is particularly interesting for grid applications where thousands of servers have to be deployed. autonomic managers (reconfiguration policies) are difficult to implement as they have to be programmed using the management and control interfaces of the management layer. This also requires a strong expertise regarding the used component model. Our approach is to reuse UML State Diagrams to define workflows of operations that have to be performed for reconfiguring the managed environment. One of the main advantage of this approach, besides simplicity, is that state diagrams manipulate the entities described in the deployment schema and reconfigurations can only produce a concrete architecture which comforms to the abstract schema, thus enforcing reconfiguration correctness.

We detail these three aspects in the next sub-sections.

P r e l i m i n a r y V e r s i o n We adapted the UML class diagram formalism in order to allow specification of architecture schemas, as illustrated in Figure 3 where such a schema is defined for a J2EE organization. An architecture schema describes the overall organization of a software infrastructure to be deployed. At deployment time, the schema is interpreted to deploy a component architecture. Each element (the boxes) corresponds to a software which can be instantiated in several component replicas. A link between two elements generates bindings between the components instanciated from these elements. Each binding between two components is bi-directional (actually implemented by 2 bindings in opposite directions), which allows navigation in the component architecture in order to fetch any configuration attribute of the software infrastructure. An element includes a set of configuration attributes for the software. Most of these attributes are specific to the software, but few attributes are predefined by Tune and used for deployment: wrapper gives the name of the WDL description of the wrapper, legacyFile gives the archive which contains the legacy software, hostFamily gives a hint regarding the dynamic allocation of the nodes where the software should be deployed, initial gives the number of instances which should be deployed.

The schema in Figure 3 describes a J2EE organization where one Load-Balancer, two Apaches, two Tomcats and one MySQL should be deployed. A probe is linked with each software, which monitors the liveness of the server in order to trigger a repair procedure. In this schema, a cardinality is associated with each link. It which constrains the interconnection of the deployed components. An intensional schema may be ambiguous, i.e. the actual deployed component architecture (bindings between components) will depend on the implemented deployment runtime. However, the user may describe a more extensional schema which will better fit his requirements.

The schema in Figure 3 deploys a component architecture as illustrated in Figure 1.

A Wrapping Description Language

Upon deployment, the above schema is parsed and for each element, a number of Fractal components are created. These components implement the wrappers for the deployed software, which provide control over the software. Each wrapper component is an instance of a generic wrapper which is actually an interpreter of a WDL specification.

A WDL description defines a set of methods that can be invoked to configure or reconfigure the wrapped software. The workflow of methods that have to be invoked in P r e l i m i n a r y V e r s i o n order to configure and reconfigure the overall software environment is defined thanks to a formalism introduced in Section 3.3. Generally, a WDL specification (illustrated in Figure 7) provides start and stop operations for controlling the activity of the and a configure operation for reflecting the values of the attributes (defined in the UML architecture schema) in the configuration files of the software. Notice that the values of these attributes can be modified dynamically. Other operations can be defined according to the specific management requirements of the wrapped software, these methods being implemented in Java.

The main motivation for the introduction of WDL are (i) to hide the complexity of the underlying component model (Fractal) and (ii) that most of the needs should be met with a finite set of generic Java methods implementations (that can be therefore reused). We covered the needs of our usecases with very few methods, plaintext and XML file accessors and a shell command launcher. A method definition includes the description of the parameters that should be passed when the method is invoked. These parameters may be String constants, attribute values or combinaison of both (String expressions). All the attributes defined in the architecture schema can be used to pass the configured attributes as parameters of the method invocations.

It is sometimes necessary to navigate in the deployed component architecture in order to configure the software. For instance, in a J2EE architecture, an Apache may be bound to several Tomcats. At the legacy layer level, the worker.properties configuration file of Apache must include the list of the nodes where the Tomcats have been launched. Therefore in Figure 7, the addWorkers method in the Apache wrapper must receive this list of nodes in order to configure the worker.properties file. The syntax of the method parameters in the wrapper allows navigating in the management layer in order to access the component attributes (in this case the nodeName attribute of each Tomcat), following the bindings between the Apache component and the Tomcat components. Tomcat.nodeName returns the list of nodeName attributes of the Tomcat components which are bound with the current Apache component.

UML-based formalism for (re)configuration procedures

Reconfigurations are triggered by events. An event can be generated by a specific monitoring component (e.g. probes in the architecture schema) or by a wrapped legacy software which already includes its own monitoring functions.

P r e l i m i n a r y V e r s i o n Whenever a wrapper component is instanciated, a communication pipe is created (typically a Unix pipe) that can be used by the wrapped legacy software to generate an event, following a specified syntax which allows for parameter passing. Notice that the use of pipes allows any software (implemented in any language environment such as Java or C++) to generate events. An event generated in the pipe associated with the wrapper is transmitted to the administration node where it can trigger the execution of reconfiguration programs (in our current prototype, the administration code, which initiates deployment and reconfiguration, is executed on one administration node, while the administrated software is managed on distributed hosts). An event is defined as an event type, the name of the component which generated the event and eventually an argument (all of type String).

For the definition of reactions to events, we reused the UML state diagrams formalism which allows specifying reconfiguration. Such a state diagram defines the workflow of operations that must be applied in reaction to an event. An operation in a state diagram can assign an attribute or a set of attributes of components, or invokes a method or a set of methods of components. To designate the components on which the operations should be performed, the syntax of the operations in the state diagrams allows navigation in the component architecture, similarly to the wrapping language.

For example, let's consider the diagram in Figure 5 (on the top) which is the reaction to a Tomcat (software) failure. The event (fixTomcat) is generated by a probeTomcat component instance, therefore the this variable references this probeTomcat component instance. Then:

this.stop will invoke the stop method on the probing component (to prevent the generation of multiple events), this.Tomcat.start will invoke the start method on the Tomcat component instance linked with the probe. This is the actual repair of the faulting Tomcat server, this.start will restart the probe associated with the Tomcat.

Notice that state diagram's operations are expressed using the elements defined in the architecture schema, and are applied on the actually deployed component architecture. The current version of Tune also provides operations which re-deploy components (change location or add component instances) while enforcing the defined abstract architecture schema.

A particular diagram is used to start the deployed J2EE environment, as illustrated in Figure 5 (on the bottom). In this diagram, when an expression starts with the name of P r e l i m i n a r y V e r s i o n an element in the architecture schema (Apache, Tomcat...), the semantics is to consider all the instances of the element, which may result in multiple method invocations. The starting diagram ensures that (1) configuration files must be generated, then (2) the servers must be started following the order Tomcat, Apache and LB (no constraint on MySQL). For each type of server, the server is started before its probe.

DSML-Based Autonomic Computing Policies Specification

Our first experiments with Tune focussed on the use of XML and UML to take advantage of well-known paradigms and of many existing open source tools. We used the UML2.0 graphical editors provided by the TOPCASED Eclipse-based toolkit [7] for the description of architectures and reconfiguration diagrams. However, the use of this unified language led us to specialize (pragmatically but sometimes awkwardly) its initial semantics in order to adapt it according to our needs. Because it is difficult to take into account this semantics specialization at the tools level, the user is let with all the freedom offered by UML.

For this reason, we are currently studying the possibility to define a dedicated metamodel for management policies definition. This allows us to define a constrained abstract syntax and a dedicated concrete syntax, relying on generic or generative tools, such as TCS [START_REF] Jouault | TCS: a DSL for the specification of textual concrete syntaxes in model engineering[END_REF] or Syntaks [START_REF] Muller | Model-driven analysis and synthesis of concrete syntax[END_REF] for textual formalisms and TOPCASED [7] or GMF [START_REF]GMF: Graphical Modeling Framework[END_REF] for graphical formalisms. For each point of view that we have taken into account in Tune, we present the corresponding metamodel, offering a constrained, domain-specific and user-friendly languages.

The Configuration Description Language

The first language is the homogeneous definition of the application architecture. The UML-based formalism introduced in Section 3.1 was very close to the UML class diagram (rather than the UML component diagram, which can be quite confusing), reusing the concepts of classes, attributes and associations with multiplicities. However, the objective was mainly to reuse the expressiveness of the graphical notation, but with a domain specific semantic. The DSML we introduce here proposes a simple intentional architecture description language which allows to reify the heterogenous structural architecture of the legacy level. We call this language the Configuration Description Language (CDL). The main subset of the metamodel is depicted in Figure 6, also with an illustration with the model of the J2EE example of Section 3.

The main concept of this view is the SoftwareElement describing a particular type of software with its own configuration, management, and life cycle procedures. Each Soft-wareElement is described by a set of properties (ownedAttributes), with an initial value (defaultValue), which are used by the administrator to reify the configurable attributes of the legacy software that the SoftwareElement represents. Note that a particular software can be reified by different SoftwareElements with different configuration properties.

The configuration language allows to describe an architecture in intension. This means here that each described SoftwareElement can be deployed into several instances. The architecture of the legacy level is intentionally reified through the definition of P r e l i m i n a r y V e r s i o n

Probe MySQL

(distributedprobe.tgz)

1 1 1 1 1 1 1 1
sourceElement Fig. 6. The Configuration Description Language bindings (IntentionalLink), allowing to connect a SoftwareElement to another, and expressing a multiplicity (lower & upper) and a role (name). The multiplicity expresses the range of instances of the target SoftwareElement for each one of the source Softwa-reElement. The role allows navigation with a query language relying on OCL [START_REF]Object Management Group: UML Object Constraint Language (OCL)[END_REF]. It is also possible to define bi-directional bindings by defining an opposite bindings.

The Wrapping Description Language

The second language allows the definition of a wrapper and its relation with Softwa-reElements. In the Wrapping Description Language introduced in Section 3.2, a wrapper was described in an XML dialect, only enabling runtime checks by the Tune machinery. With this DSML, it becomes possible to introduce static consistency checks regarding the architecture schema it may reference, especially for the navigation clauses included in method parameters.

The corresponding metamodel is presented in Figure 7, also with an illustration with a model defined with a specialized textual editor. A Wrapper describes methods which define actions that can be applied on the encapsulated software component. A wrapper may be referenced by different SoftwareElements (with different properties). A Method can be parametrized (ownedParameter) with any property (of the SoftwareElement) of the configuration description in which the wrapper is used, the OCL-based navigation language allowing to fetch the effective parameter values. The method implementations (imp) are given in the form of a reference to a program (currently a string referring to a Java class).

Note that this view must be consistent with the architectural view described with the CDL. We have thus defined OCL constraints to verify that the wrapper associated with a software element defines at least the methods provided by the interface.

The Deployment Description Language

The third language is used to define by intention or by extension, the real deployment of instances of each software component on system's nodes. In the UML-based formalisms described in Section 3.1, deployment policies were specified thanks to the initial and host-family attributes in the Architecture schema.

The introduced deployment DSML is described by the metamodel presented in Figure 8, also with the illustration with the J2EE example. For this, we define for each SoftwareElement a set of Deployments, describing a real number of instances (initial) to be deployed on a node (AbtractNode). Nodes are known as "abstract" because they define a deployment policy (policy). Abstract nodes include the deployment information required to implement a deployment strategy, e.g. the physical address of a (single) real node on which instances should be deployed, or a list of physical addresses and an allocation function (for a cluster).

Note that this view must be consistent with the view described with the CDL. For instance, the number of deployed instances must be compatible with the multiplicities described in the configuration.

The clear separation of the deployment and architecture concerns allows to define several deployment orders for the same SoftwareElement (i.e. on different nodes), and to define different deployment models for the same architecture model. Finally, we clearly identify the concept of node.

The Reconfiguration Description Language

The last DSML allows the definition of reconfiguration policies. In the UML-based formalism introduced in Section 3.3, reconfiguration actions were expressed in terms of P r e l i m i n a r y V e r s i o n state diagrams, where we awkwardly inserted elementary actions as the state name. In accordance with the UML semantics, we decided to represent reconfiguration actions as activity diagrams in this DSML. Moreover, we introduced support in the DSML for the life cycle definition, allowing a clear description of links between events and reconfiguration actions, similarly to ECA (Event/Condition/Action) rules which typically used. This life cycle is expressed as a state diagram, where transitions are trigerred by events and execute reconfiguration actions defined as activity diagram.

We are inspired by the UML metamodel to express state diagrams (i.e. life cycles) and activity diagrams (i.e. reconfiguration policies). We don't reproduce this DSML metamodel since it is very similar to that of UML (with useless elements withdrawn).

5 Lessons Learned

Users'viewpoint

Dealing with autonomic management policies, we have experienced the definition of higher level formalisms than the one used by the underlying Fractal components. The main motivation is to provide a formalism easier to understand and facilitating the definition of the views describing an application. These views are parsed by the Tune runtime in order to configure a Fractal component architecture. The first main benefit of this approach is to ease the learning and the adoption of the tool, for new users but also for experienced users. As an example, one student with no preliminary knowledge has been able to deploy his first application within two hours after a one hour seminar whereas several days were previously required

In a first step, we have built our views by using UML diagrams, thus being close to a well-known and largely-adopted notation. Furthermore, it was possible to use the numerous available UML tools, providing the users with high level tools. Nevertheless, reusing the UML notation had one important drawback: we had to tailor the semantics of the diagrams we reused (the class and statemachine diagrams). Thus, we deviated from a standard UML model. For example, we used the name of a state to describe a method call rather that the UML behavior concept.

One solution, would have been to define a real UML profile rather than only reusing the graphical notation and tools but we would have also inherited the complexity of the UML metamodel. So, we investigated the use of DSMLs. It allows focussing on only the domain specific concepts and to define adapted views (as an example, the UML architecture schema has been split into two views, the configuration description language and the deployment description language). The semantics of the notation is well-founded because it is defined by a (MOF) metamodel completed by a set of OCL constraints to express constraints that are not captured by the metamodel itself.

Obviously, UML tools are not usable with our newly-defined DSMLs. So we had to develop new editors. The TOPCASED tool [7] has been used to generate the graphical editors. When sticking at the possibilities of this editor generator, some hours are sufficient to have a functional editor. If additional functionalities are required, the generated code has to be manually adapted. These adaptations may be time consuming but the base editor is really usable as is. We have also used TCS [START_REF] Jouault | TCS: a DSL for the specification of textual concrete syntaxes in model engineering[END_REF], a tool that permits P r e l i m i n a r y V e r s i o n to define a concrete syntax and the associated Eclipse editor (including colour, folding, name completion, etc). So we have been able to provide in a couple of hours a textual syntax for WDL that is easier to use that the XML like syntax. Finally, the graphical and textual generated editors provide better user assistance than the UML editors because they enforce the construction of coherent models conforming to the DSML definition, including OCL constraints. So, users can see their mistakes before the Tune runtime reports them.

Correctness

The adopted approach favors correctness of managed applications for 3 main reasons:

the definition of the management layer. Thanks to the management layer (composed of wrappers), the administrator of a software infrastructure does not have to manipulate complex configuration files, as in a J2EE clustered architecture. All the configurable entities (attributes, bindings, etc.) are reified in the management layer and can be homogeneously manipulated. the definition of an application pattern and its enforcement. The deployed application architecture is generated from the definition of a pattern (the architecture schema). Any reconfiguration described with the Reconfiguration Description Language can only result in an architecture which complies with this pattern. the definition of a user-friendly notation that favors the understanding of the users on their models is another step in the right direction. Indeed, the users are enforced to build coherent models, especially in the DSML approach, or are informed of possible mistakes without having to wait until their models are parsed by the Tune runtime. The application is then automatically generated.

Related Works

Autonomic computing is an appealing approach that aims at simplifying the hard task of system management, thus building self-healing, self-tuning, and self-configuring systems [START_REF] Kephart | The Vision of Autonomic Computing[END_REF]. Management solutions for legacy systems are usually proposed as ad-hoc solutions that are tied to particular legacy system implementations (e.g. [START_REF] Urgaonkar | Dynamic Provisiong of Multi-Tier Internet Applications[END_REF] for selftuning cluster environments). This unfortunately reduces reusability and requires autonomic management procedures to be reimplemented each time a legacy system is taken into account in a particular context. Moreover, the architecture of managed systems is often very complex (e.g. multi-tier architectures), which requires advanced support for its management.

Relying on a component model for managing legacy software infrastructure has been investigated by several projects [START_REF] Garlan | Rainbow: Architecture-based self adaptation with reusable Infrastructure[END_REF][START_REF] Hagimont | Autonomic Management of Clustered Applications[END_REF][START_REF] Oriezy | An Architecture-Based Approach to Self-Adaptive Software[END_REF] and has proved to be a very convenient approach, but in most cases, the autonomic policies have to be programmed using the programming interface of the underlying component model (a framework for implementing wrappers, configuration APIs or deployment ADLs) which is too low level and still error prone.

P r e l i m i n a r y V e r s i o n

Therefore, many projects explored model-driven approaches for designing autonomic management policies. Some of them proposed frameworks for modeling autonomic systems, e.g. a self-healing [START_REF] Jiang | A Modeling Framework for Self-Healing Software Systems[END_REF], a self-protecting [START_REF] Pena | A model-driven architecture approach for modeling, specifying and deploying policies in autonomous and autonomic systems[END_REF], or a resource management system [START_REF] Barrett | A model based approach for policy tool generation and policy analysis[END_REF], the management system implementation being generated from the described management model. The modeling of such a system can still be quite complex and the integration within a legacy software organisation tricky. Some other projects proposed frameworks and runtimes for modeling the managed system and maintaining consistency between the managed system and its model at runtime [START_REF] Sriplakich | Enabling Dynamic Co-Evolution of Models and Runtime Applications[END_REF][START_REF] Rohr | Model-driven Development of Selfmanaging Software Systems[END_REF]. The main advantage is well defined representation of the managed system, on which management policies can be applied. The tune system falls into this category, even if our management layer relies on the Fractal component model. Tune relies on DSML for the specification of a software architecture, its deployment and reconfiguration. These languages ensure that only consistent system states can result from deployment and reconfiguration.

Finally, some projects considered interactions between policies, mainly in order to deal with conflicts [START_REF] Agrawal | Policy-based management of networked computing systems[END_REF][START_REF] Davy | Policy Interactions and Management of Traffic Engineering Services Based on Ontologies[END_REF]. We are currently working on a DSML which should allow such coordinating between reconfiguration policies.

Conclusion and Perspectives

We are investigating the design and implementation of an autonomic system called Tune. Tune relies on a component model in order to administrate a legacy software infrastructure as a component architecture. Tune provides support for encapsulating (wrapping) software, describing the software architecture to manage and its deployment in a physical environment, and describing the dynamic reconfiguration policies to be applied autonomously. Our experiments with Tune led us to the conclusion that higherlevel support was required for assisting administrators in policy description tasks.

For this purpose, our first experiments focused on the use of UML-based formalisms. These experiments confirmed the interest of raising up the abstraction level but we had to specialize the UML semantics according to the requirements of the considered field. It was difficult to take into account this specialization in the tools we reused. In a second step, we worked on the definition of a dedicated metamodel. The expected benefits are two-fold: to provide a formal definition of Tune's languages, and to statically and dynamically validate the policies described by administrators with customized editors.

This work opens many perspectives on which we are currently working. Although we already prototyped few specialized editors, we plan to provide editing tools for all the administration points of view considered by Tune. Also, the Tune developpers are currently extending the reconfiguration capabilities of Tune and the metamodel and the associated editing tools will evolve accordingly. In the longer term, we plan to revisit the design of the Tune system, considering that the management layer (illustrated in Figure 1) should be managed as a model (instead of a component architecture at the middleware level). This means that models would not only be used to describe policies, but would further be used to maintain the internal state of the Tune system. We refer to this new MDE field as Model-Driven System Administration. We are convinced that it is now essential to increase the abstraction level of software management, not only during the design but also during their development and administration.

P r e l i m i n a r y V e r s i o n

Fig. 1 .

 1 Fig. 1. Management layer for the J2EE application

Fig. 2 .

 2 Fig. 2. Automatic restart of a Tomcat server on software fault to implement wrappers (to encapsulate existing software), to describe deployed architectures and to implement reconfiguration programs, the administrator of the environment has to learn (yet) another framework, the Fractal component model in our case. More precisely, our previous experiments showed us that:

1 LB 1 Fig. 3 .

 113 Fig. 3. Architecture schema for J2EE 3.1 UML-based formalism for architecture schemas

Fig. 4 .

 4 Fig. 4. A WDL specification

Fig. 5 .

 5 Fig. 5. State diagrams for repair and start

Fig. 8 .

 8 Fig. 7. The Wrapping Description Language Software Element filename: String

This work is supported by the SCORWARE RNTL project (contract ANR-06-TLOG-017).

we also use the term administration to refer to management operations.

e.g. for configuring an Apache, we need to access attributes from both the Apache component and the Tomcat components it is bound with.


Mostafa Rizk
email: mostafa.rizk@imt-atlantique.fr

A Baghdadi

J-Ph Diguet

Real-Time Human Detection in Marine Environment Using Deep Learning on Edge Devices

Keywords: Deep learning, YOLO, Maritime, Human detection, Edge devices

Artificial intelligence (AI) techniques based on deep learning provide robust solutions to detect and locate objects. The achieved performance prove the relevance of convolution neural networks (CNNs) in circumventing existing computer vision challenges. The goal of this work is to exploit the advantages of AI-based methods in detection of floating humans in open water to aid marine search and rescue missions. This has the potential to save lives while simultaneously saving efforts and expenses. In this work, we explore the use of You Only Look Once (YOLO) in detecting humans in maritime environment. A custom dataset is used to train the available YOLOv4 models. The trained models are assessed using recognized evaluation metrics. In addition, the inference speed is targeted towards embedded low-power hardware edge devices. The obtained results reveal that YOLOv4 can identify persons in a marine environment in real time with acceptable accuracy and precision.

I. INTRODUCTION

Deep learning algorithms have recently revealed effective methods for detecting, classifying, and localizing multiple objects in pictures and videos. The development of neural networks has improved performance to the point that it is regarded on par with human performance. However, the improved detection performance comes at the cost of greater system resources and power consumption, particularly in reallife applications that demand real-time processing and high precision and accuracy.

You Only Look Once (YOLO) [START_REF] Redmon | You Only Look Once: Unified, real-time object detection[END_REF] was recently developed as an efficient CNN-based model for real-time object identification. YOLO outperforms two-stage models which classify objects based on pre-selected regions such as regionconvolutional neural network (R-CNN) [START_REF] Girshick | Rich feature hierarchies for accurate object detection and semantic segmentation[END_REF]- [START_REF] Ren | Faster R-CNN: Towards realtime object detection with region proposal networks[END_REF]. YOLO approach eliminates the required post-processing operations in order to reduce the complexity and enhance the detection speed. Several versions of YOLO have been introduced with different neural network architectures [START_REF] Redmon | YOLO9000: Better, faster, stronger[END_REF], [START_REF]YOLOv3: An incremental improvement[END_REF]. The most recent architecture of YOLO, known as YOLOv4 [START_REF] Bochkovskiy | YOLOv4: Optimal speed and accuracy of object detection[END_REF], has been proven to identify objects in real time with great precision. It is shown that YOLOv4 exceeds in terms of speed and accuracy other real-time neural networks such as EfficientDet [START_REF] Tan | Efficientdet: Scalable and efficient object detection[END_REF] and RetinaNet [START_REF] Lin | Focal loss for dense object detection[END_REF].

In this work, we aim to exploit the advancements in AI to rapid the direction of rescuers and medical teams to lost individuals during directing of rescuers and medical teams which greatly impacts in saving human lives and in lowering the missions' cost. The use of YOLOv4 model is explored in detecting individuals in maritime environments.

II. METHOD

We create a dataset of images showing humans in maritime environment. The dataset includes 6462 images with 16795 bounding boxes. The number of humans in the scene varies between the images. The images are split randomly by 70% as training dataset, 10% as validation dataset and 20% as testing dataset.

Several YOLOv4 models exist in the literature with different architecture specifications and detection performance in terms of accuracy and precision, detection speed and required energy budget. We examine three different YOLOv4 networks: YOLOv4 Large, YOLOv4 Tiny and YOLOv4 Tiny-3l. The original YOLOv4 network consists of 162 layers and uses mish activation functions. YOLOv4 Tiny is the compressed version of YOLOv4. It uses the simplified network structure of CSPDarknet53-tiny. It compromise 38 layers with LeakyRelu activation functions and only two detector heads. YOLOv4 Tiny-3l architecture is similar to YOLOv4 Tiny, but with three detector heads.

The training is conducted using the Darknet framework [10] using Quadro RTX 4000 from Nvidia. Transfer learning is adopted in order to maintain the generalization. We make use of the weights generated in previous training processes of networks with similar architecture specifications targeting COCO dataset. Note that the imported weights of the feature extraction layers are kept; whereas, the weights of the neck and the detector layers are eliminated. The networks' general architectures have not been altered. Only the depth size of the three convolution layers allocated before the YOLO detector layers are adjusted. The number of filters in these three convolution layers are modified considering our case where only one class (Person) is targeted.

The number of images per batch is set to 64. The total number of iterations is set to 2000. The initial learning rate for training is set to 0.001 and it scales down two times by 0.1 at iteration 1600 and 1800. The input images are down sampled into 416 × 416 or 608 × 608. While training the models, data augmentation is activated. Mosaic data augmentation type is used where 4 images are merged into one. When activated, Cutmix data augmentation type is applied for the classifier only. The saturation of input images and their exposure (brightness) are randomly changed as well as the rotation.

A. Results

The trained models are evaluated using the test dataset. Table I shows the obtained mean average precision considering VOC07 and VOC12 performance metrics [START_REF] Padilla | A comparative analysis of object detection metrics with a companion open-source toolkit[END_REF]. In addition, the table shows the obtained values of precession, recall, F1-score and average intersection over union (IOU) considering 0.5 IOU threshold. Furthermore, the inference speed of the trained models is evaluated using several captured videos targeting embedded platforms. Table I shows the obtained speed of the trained models in frames per second (FPS) when applied to the captured videos on Jetson Xavier NX development kit while operating on different power modes. The obtained results show that applying DA enhances the detection performance (mAP, precision, recall, F1-score and average IOU). The use of cutmix DA increases the enhancement ratio in most of the cases. The use of higher image resolution enhances the mAP performance but at the cost of reduced inference speed and longer training time.

III. CONCLUSION

In this paper, the use of YOLOv4 in detection of humans in maritime environments is investigated. Available YOLOv4 architectures are trained on a custom dataset. The trained models are evaluated in terms of mAP, precession, recall and average IOU. Also, the performances of the models are examined on embedded platforms using our own videos showing humans in open water. The obtained results show that YOLOv4 can achieve real-time detection of humans in maritime environment with acceptable accuracy and precession. For example, YOLOv4 Tiny achieves an inference speed of 45.6 FPS with mAP of 63.10 when running on Jetson Xavier NX considering 608×608 resolution. Future work will include applying optimization techniques such as quantization and pruning to increase the inference speed and study their impact on the detection performance.

TABLE I EVALUATION

 I RESULTS OF THE TRAINED YOLOV4 MODELS

	Target Image Training Model Resolution time (h) AugmentationVOC07VOC12 Data mAP mAP PrecessionRecall	F1 avg score IOU Mode0Mode1Mode2Mode3Mode4Mode5 Average FPS on Jetson Xavier NX
		-	60.46 58.78	61.61 70.80 65.8862.14
	416×416 03:22	mosaic	64.27 65.66	62.57 75.48 68.42 63.8	10.1 10.7 10.8 8.8	9.4	6.5
	YOLOv4	mosaic+cutmix 65.63 69.04	61.95 78.03 69.0764.83
	Large	-	55.16 59.15	66.15 69.98 68.0163.13
	608×608 06:00	mosaic	64.64 64.91	66.74 73.45 69.9364.92	5.6	5.7	5.7	5.0	4.9	3.7
		mosaic+cutmix 65.82 69.37	63.96 78.28 70.4 65.39
		-	57.00 56.53	49.03 73.39 58.7961.34
	416×416 00:24	mosaic	56.34 56.10	48.25 73.95 58.4061.75	58.4 80.6 72.0 54.3 67.4 53.0
	YOLOv4	mosaic+cutmix 56.90 56.90	47.40 73.85 57.7461.85
	Tiny	-	59.29 60.07	53.98 74.91 62.7562.08
	608×608 00:35	mosaic	60.91 63.10	52.83 77.00 62.6662.58	35.3 44.3 45.6 31.3 39.4 30.3
		mosaic+cutmix 60.59 62.47	53.04 76.57 62.6762.66
		-	54.89 53.31	53.78 72.32 61.6960.97
	416×416 00:25	mosaic	55.28 54.17	53.16 73.04 61.5361.57	50.1 60.0 69.9 43.6 58.6 48.0
	YOLOv4	mosaic+cutmix 55.80 55.41	53.09 73.95 61.8161.88
	Tiny-3l	-	59.12 57.46	59.27 70.92 64.5761.81
	608×608 00:47	mosaic	59.54 59.43	56.63 73.26 63.8862.35	32.6 39.7 40.3 35.1 35.7 26.8
		mosaic+cutmix 60.08 59.92	57.60 73.17 64.4662.21


Kassem Saied
email: kassem.saied@univ-ubs.fr

Ali Al Ghouwayel
email: ali.ghouwayel@efrei.fr

Ali Chamas

Al Ghouwayel

Emmanuel Boutillon
email: emmanuel.boutillon@univ-ubs.fr

Phase Synchronization for Non-Binary Coded CCSK Short Frames

Keywords: Phase synchronization, ML estimator, CCSK score ratio, NB-code properties

published or not. The documents may come

I. INTRODUCTION

The design of an efficient signaling scheme for the Internet of Things (IoT) systems constitutes nowadays an active research domain [START_REF] Shafique | Internet of Things (IoT) for Next-Generation Smart Systems: A Review of Current Challenges, Future Trends and Prospects for Emerging 5G-IoT Scenarios[END_REF]. Being the center of interest for both academic and industrial sectors, the infrastructure of IoT systems is needed to be adapted to support massive connections induced by the overgrowing number of users [START_REF] Lee | Packet structure and receiver design for low latency wireless communications with ultra-short packets[END_REF]. In this context, the frame structure of an IoT Packet constitutes one of the aspects to be appropriately designed. The target is to shorten this frame as long as the communication quality predefined by the standard is maintained at the required level [START_REF] Rahbari | Exploiting Frame Preamble Waveforms to Support New Physical-Layer Functions in OFDM-Based 802[END_REF]. This frame shortening strategy is motivated by the work of Polyanski [START_REF] Polyanskiy | Asynchronous Communication: Exact Synchronization, Universality, and Dispersion[END_REF] where it was demonstrated that the capacity of the wireless channel is not affected by the asynchronous transmission, even when short packets are used. In the context of IoT communications, the challenge is to propose techniques able to maintain good performance at very low Signal to Noise Ratio (SNR) levels.

Time, phase, and frequency synchronizations for a short frame are topics widely investigated in the literature. They can be splitted into two areas: data-assisted synchronization (thanks to the preamble and/or pilot symbols) and blind synchronization. The literature for the latter case is rather sparse. Most of the proposed methods work only for a rather high signal-to-noise (SNR) ratio [START_REF] Azari | Grant-Free Radio Access for Short-Packet Communications over 5G Networks[END_REF]- [START_REF] Walk | MOCZ for Blind Short-Packet Communication: Practical Aspects[END_REF]. In [START_REF] Rahamim | Methods for carrier synchronization of short packet turbo coded signals[END_REF], a phase synchronization method has been proposed based on the use of turbo decoder information to improve the carrier phase and offset synchronization for short packets. This method showed good performance at an SNR greater than -0.5 dB.

In [START_REF] Saied | Short frame transmission at very low snr by associating ccsk modulation with nb-code[END_REF], a Quasi Cyclic Short Packet (QCSP) frame structure has been proposed based on the combinations of Cyclic Code Shift Keying (CCSK) [START_REF] Dillard | Cyclic code shift keying: a low probability of intercept communication technique[END_REF] of length q chips and a Non-Binary (NB) error control code [START_REF] Abassi | Nonbinary coded CCSK and Frequency-Domain Equalization with simplified LLR generation[END_REF] over GF(q). The key idea is to design a preamble-less frame, where the whole payload is used to perform both detection and timing synchronization processes from the first side, and Forward Error Correction (FEC) decoding process to recover the conveyed data from the other side. The detection and time-synchronization techniques are successfully and efficiently performed thanks to the inherent cyclic property of the CCSK modulation, allowing practical transmission at very low SNR (-10 dB for example). In [START_REF] Monière | Time sliding window for the detection of CCSK frames[END_REF], a robust detection method to assess the arrival of a QCSP frame is presented. This method called "time sliding method", provides only a rough estimate of the time of arrival of the frame as well as a rough estimate of its frequency offset. In [START_REF] Saied | Blind Time-Synchronization of CCSK Short Frames[END_REF], an efficient time synchronization technique is described. The method uses the structural properties of the QCSP frame to detect the exact time of arrival of the frame. In the continuity of the workflow initiated in [START_REF] Saied | Short frame transmission at very low snr by associating ccsk modulation with nb-code[END_REF], [START_REF] Monière | Time sliding window for the detection of CCSK frames[END_REF] and [START_REF] Saied | Blind Time-Synchronization of CCSK Short Frames[END_REF], this paper presents the final step of the synchronization process, i.e., the suppression of the remaining residual frequency and initial phase offsets. Once the frame fully synchronized, coherent demodulation can be performed to generate the symbol Log-Likelihood Ratio required by the non-binary decoder.

In this paper, two methods are proposed to perform phase/frequency synchronization. The first method, called Direct Method (DM), assumes that all the CCSK symbols are demodulated correctly. In that case, the frequency and phase estimation task resumes to an estimation problem of a pure complex sinusoidal signal affected by Gaussian noise. It is a well-known problem and a near Maximum Likelihood (ML) estimator can be obtained at low cost using the Fast Fourier Transform (FFT) [START_REF] Fitz | Further results in the fast estimation of a single frequency[END_REF]. Nevertheless, at low SNR (-10 dB typically), detection errors appear. Those errors alleviate the quality of the DM and generate up to 0.5 dB of degradation on the overall performance. The second method is called Parametric Method (PM). It is based on the ML estimation using a parametric Probability Density Function (PDF) of each phase error. The two parameters of the proposed PDF model are computed using information coming from the non-coherent CCSK demodulation process and information coming from one decoding iteration of the NB-Low Density Parity Check (NB-LDPC) decoder. The PM method is simple to process and gives a result close to the Genius Aided (GA) method, i.e., the DM method when all the transmitted symbols are considered to be known.

The rest of this article is organized in the following manner. In section II, the general context of our study including the system model and the problem statement of the phase synchronization are discussed. In section III, the direct phase synchronization method is described. The proposed PM phase synchronization aided by the CCSK and NB-LDPC association is described in Section IV. Discussion and result analysis are given in section IV. Finally, section V concludes and gives some insights on future work.

II. GENERAL CONTEXT OF THE STUDY

This section sums up briefly the overall communication chain of the QCSP system model. Then, it states the problem of phase synchronization and formulates the context of the proposed phase-synchronization algorithm.

A. Overall Communication Chain

Fig. 1 shows the system model of the communication link being considered, where the phase-synchronization and LLR computation block constituting the core contribution of this work is highlighted. Consider a NB code defined over the Galois Field with q elements, denoted by GF(q), i.e., q = 2 p . A message M consists of K GF(q) information symbols, each symbol of size p bits. It is encoded by the NB-LDPC code of Parity Check Matrix (PCM) H and code rate R c = K/N , where N is the length of the generated codeword C, i.e. C = [c 0 , c 1 , . . . , c N -1 ]. Thus, the codeword C verifies HC T = 0, where C T is the transpose of C. The CCSK modulation uses a pseudo-random binary sequence P 0 = {P 0 (i)} i=0,...,q-1 of length q, where P 0 (i) ∈ {-1, 1}, to map an element c k of GF(q) (c k can also be considered as an integer between 0 and q -1) to the sequence P c k defined as the circular right shift of P 0 by c k positions, i.e., P c k = {P 0 (i -c k mod q)} i=0,...,q-1 for k ∈ [0, N -1]. The CCSK sequence P 0 is selected so that the scalar product < P a , P b > is close to 0 when a = b and equal to q otherwise (see [START_REF] Boutillon | PN Sequence Generation in QCSP systems[END_REF] for the definition of the sequences P 0 for several values of q). So the QCSP frame F can be defined as: F = [P c0 , P c1 , . . . , P c N -1 ]. Before transmission, the generated frame F is composed of N × q BPSK symbols, which are then shaped by a half raised cosine filter with a roll-off factor equal to 0.35.

The QCSP frame passes through an asynchronous Additive White Gaussian Noise (AWGN) channel with a standard deviation σ. Since an unslotted ALOHA protocol is assumed, the receiver has no knowledge about the time of arrival of the frame, its potential residual frequency offset, and finally, its initial phase offset. In [START_REF] Monière | Time sliding window for the detection of CCSK frames[END_REF], a detection technique named "time sliding windows" allows determining the arrival of a frame with high probability. Then, in [START_REF] Saied | Blind Time-Synchronization of CCSK Short Frames[END_REF], a time-synchronization method is proposed to mitigate the time ambiguity and to suppress most of the frequency offset. The output of the detection and time-synchronization processes (see Fig. 1) is thus the received frame affected by a small residual frequency offset f r upper bounded by 10 -3 , i.e. the absolute phase offset between two chips is lower than 2π × 10 -3 radian [START_REF] Saied | Blind Time-Synchronization of CCSK Short Frames[END_REF]. The model of the frame sent to the phase synchronization block is thus defined as Y = [y 0 , y 1 , ..., y N -1 ], where y k = (y(kq), y(kq + 1), . . . , y(kq + q -1)), corresponds to the transmission of the sequence P c k affected by phase rotation and corrupted by additive Gaussian noise, i.e. for k = 0, 1, ..., N -1, and ∈ 0, 1, ..., q -1.

y k ( ) = e j(2πfr(kq+ )+φ0) P c k ( ) + z(qk + ). (1)
The contribution of the paper is to explain how the phase synchronization blocks mitigates both f r and φ 0 .

B. Problem statement

Assuming perfect frequency synchronization, the generation of the Log Likelihood vectors required by the NB-LDPC decoder is based on computation that uses the real part of the output correlation vector L (see [START_REF] Abassi | Non-Binary Low-Density Parity-Check coded Cyclic Code-Shift Keying[END_REF] for details). Let us assume that a residual phase error ξ affects the correlation vector L. The real part of L will have an amplitude reduced by a factor cos(ξ) compared to the magnitude |L| due to the rotation by the angle ξ. This amplitude degradation translates directly in 10 log 10 (cos(ξ) 2 ) dB loss of signal energy, and thus, the SNR. To set the idea, ξ = 0, π/64, π/16, π/9.3 and π/4 generates an SNR degradation of 0 dB, 0.01 dB, 0.16 dB, 0.5 dB and 3 dB, respectively. When ξ = π/2, no more signal is received. The frequency synchronization task should thus maintain the residual phase error close to zero not to impact significantly the receiver performance.

C. Demodulation of the received symbol

The first step is to demodulate each symbol. Let us define L k = {L k (i)} i=0,1,...,q-1 as the correlation vector between the vector y k and the q possible CCSK sequences P i for i = 0, 1, ..., q -1, i.e.

L k (i) = q-1 =0 y k ( )P i ( ).
(2)

By definition of ( 2) and ( 1), we have

L k (c k ) = e j(2πfr kq+φ 0 ) q-1 =0 e j2πfr Pc k ( ) 2 + q-1 =0 z(qk + )Pc k ( ) = e j(2πfr kq+φ 0 ) 1 -e j2πfr q
1 -e j2πfr + Z k , = e j(ωk+θ) sin(πfrq) sin(πfr)

+ Z k , (3)
where ω = 2πf r q, θ = φ 0 +πf r (q -1) and Z k the summation of q independent samples of an AWGN noise of standard deviation equal to σ, i.e., Z q is Gaussian noise with zero mean and standard deviation √ qσ. In the absence of noise

(i.e. Z k = 0), the phase of L k (c k ) is equal to Θ k = ω k + θ.
Note that Θ k is the equation of a straight line in the phase domain, as shown in the black solid line of Fig. 2. Let d k be the symbol hard decision of the non-coherent demodulation process, so d k is defined as

d k = argmax i=0,1,...,q-1 {|L k (i)|}. (4)
From d k , the corresponding correlation value can be defined as

γ k = L k (d k ). (5)
Thus, in case of correct decision, i.e., when [START_REF] Rahbari | Exploiting Frame Preamble Waveforms to Support New Physical-Layer Functions in OFDM-Based 802[END_REF]. In case of wrong decision, we have

d k = c k , γ k is equal to L k (c k ) given in
γ k = e j(ωk+φ0) q-1 =0 e j2πfr P c k ( )P d k ( ) + Z k . (6)
Since by construction, < P d k , P c k > is close to zero and considering also that |qf r | 1 (a reasonable assumption for q = 64 and |f r | < 10 -3 ), then the first term of ( 6) can be considered as negligible. In that case, γ k has a random phase given by the phase of the noise term Z k of [START_REF] Bloessl | mSync: Physical Layer Frame Synchronization Without Preamble Symbols[END_REF].

Let Γ denotes the vector containing the γ k values found in (5), i.e., Γ = (γ k ) k=0,1,...,N -1 . Let us define Ψ = (Ψ k ) k=0,1,...,N -1 , where Ψ k is the phase of γ k for k ∈ 0, 1, . . . , N -1. We can notice from (3) that Ψ k is modeled as

Ψ k = Θ k + ξ k , (7)
with ξ k is the phase error between the exact phase Θ k of L k (c k ) in the absence of noise and the measured phase In case of wrong decision, the PDF f ξ of the phase error ξ can be modeled as the PDF of the uniform distribution over the interval [-π, π], i.e. f ξw (x) =1 2π for x ∈ [-π, π] and 0 otherwise (see Fig. 3.a, .b).

Ψ k of L k (d k ).
In case of correct decision, the PDF can be closely modeled as the PDF of the normal distribution N (0, ρ); see Fig. 3 (blue curves), where the variance ρ can be numerically calculated. Thus, f ξc (x) = (1/ρ √ 2π) exp (-x 2 2ρ 2 ) 1 . Let us assume that P 0 is the probability of error in the CCSK demodulation. Thus, f ξ (x) is equal to f ξc (x) with a probability of 1 -P 0 , and it is equal to f ξw (x) with a probability P 0 , thus, in average,

f ξ (x) = (1 -P 0 )f ξc + P 0 f ξw = 1 -P 0 ρ √ 2π exp (- x 2 2ρ 2 ) + P 0 2π , (8)
when x ∈ [-π, π], and 0 otherwise. This distribution is shown in Fig. 3-b.

As an empirical verification of the previous theoretical analysis, a Monte Carlo (MC) simulation of 10 6 CCSK symbols c k at SNR = -10 dB has been considered. Fig. 3-a illustrates the experimental phase distribution f ξ (x) (black curve) as well as its components (1 -P 0 )f ξc (blue curve) and P 0 f ξw (red curve). Fig. 3-b illustrates the theoretical counterparts.

III. PHASE SYNCHRONIZATION WITH DIRECT METHOD

This section discusses the DM to estimate the phase offset of the received frame. According to (3), the vector Γ is a pure sinusoidal vector of length N , with unknown frequency ω/(2π) and an unknown initial phase θ that is corrupted by an AWGN. The estimation of ω and θ is a classical problem of signal processing. First, ω is estimated as ω thanks to the near ML estimator using FFT given in [START_REF] Fitz | Further results in the fast estimation of a single frequency[END_REF]. Then, from the estimated value ω, the estimation of the initial phase θ is given as

θ = Phase N -1 k=0 γ k e -j ωk . (9)
From ω and θ, the phase of the k th symbol is estimated as Θk = ωk + θ. The values of Θk , k = 0, 1, . . . , N -1 are shown by the red dashed line in Fig. 2. One can note that, by construction, the difference between the estimated phase Θk and the real phase Θ k is maximized for k = 0 and/or k = N -1.

The GA of the frequency and initial phase estimation is similar to the DM, except that Γ = (L k (d k )) k=0,1,...,N -1 is replaced by the vector (L k (c k )) k=0,1,...,N -1 , i.e., all decisions are assumed to be correct. The GA method gives the optimal estimation ω and θ of ω and θ respectively. The corresponding phase for the k th symbol is thus Θk = ωk + θ.

To compare the performance of the DM with the GA method, 10 4 QCSP frames of length N = 60 over GF(64) have been transmitted at an SNR of -10 dB, with each frame affected by a random frequency offset between [-10 -3 , 10 -3 ] and a random phase offset. For each received frame, ω and θ are estimated based on DM and GA method. Fig. 4.a is a 2D plot where each point shows the phase estimation error corresponding to the final symbol in the received frame Θ N -1 -ΘN-1 as function of the phase estimation error in the first symbol Θ 0 -Θ0 of the same frame, calculated based on GA method. Fig. 4.b gives the same result but using the DM method. In both figures, the black circle is the boundary for phase error equals 0.336 radian, which corresponds to an SNR degradation equals to 0.5 dB (i.e. 10 log 10 (cos(0.336) 2 ) = -0.4998).

The gap in performance between the DM and GA methods is clear, where the former is not reliable and introduces a loss of 0.5 dB (and even more than 1 dB in some cases). The next section shows a novel approach that overcomes this problem and allows to get a performance close to the GA approach.

IV. PARAMETRIC METHOD (PM) FOR PHASE ESTIMATION

This section proposes a new method, named PM, for estimating the phase offset. This method is based on two steps. First, a model of the PDF of each phase error is derived. Then, a ML estimator is applied to find the parameters (ω, θ) that the observation "explains the best".

A. ML estimation method

In statistics, after some observed data is given, ML estimation is a method that estimates the parameters of an assumed probability distribution. This is achieved by maximizing a likelihood function so that, under the assumed statistical model, the observed data is the most probable. The point in the parameter space that maximizes the likelihood function is called the ML estimation. In QCSP system, ML estimator can be applied to estimate the frequency and phase parameters (ω, θ) of (ω, θ) in (3) as the following

(ω, θ) = arg max ω,θ N -1 k=0 f ξ k (Ψ k -ωk -θ) , (10)
where Ψ k = Phase(γ k ) as defined in [START_REF] Walk | MOCZ for Blind Short-Packet Communication: Practical Aspects[END_REF] and f ξ k the PDF associated to the phase error of the k th detected symbol.

In practice, ( 10) is evaluated on a discrete 2-dimensional grid, one dimension for Θ 0 = θ, another for ω. The grid resolution of Θ 0 = θ is π/32, which corresponds to a maximum error of quantization of ±π/64, i.e., a maximum of 10 log 10 (cos(π/64) 2 ) = 0.01 dB of SNR degradation. Since θ varies from -π to π, the associated grid contains 64 values.

For the grid of ω, it is more convenient to specify the final phase Θ N -1 , since ω = (Θ N -1 -Θ 0 )/N according to [START_REF] Saied | Short frame transmission at very low snr by associating ccsk modulation with nb-code[END_REF]. In the worst cases, θ = +π (respectively -π) and f r = +10 -3 (respectively, -10 -3 ), leading to the final phase

Θ N -1 inside the interval [-Θ m , Θ m ] with Θ m = π+2π(N -1)qf r = 8.5π.
With the same resolution as Θ 0 , the Θ N -1 grid contains (2 × 8.5) × 32 = 544 elements. Altogether, the 2-dimensional grid contains 64 × 544 = 3.5 × 10 4 elements. This very high number can be drastically reduced in practice. For example, it is possible to search the optimal solution with a greedy algorithm stating from the parameters given by the DM. The quality of the PM thus relies on the quality of the PDFs f ξ k , k = 0, 1, . . . , N -1 derived in [START_REF] Rahamim | Methods for carrier synchronization of short packet turbo coded signals[END_REF]. This PDF depends directly on the two parameters: the probability of detection error P 0 and the variance ρ of the phase error of the correct symbol. In the next two sections, we propose first a parametric estimation based on the CCSK decision process. Then the quality of the parameters' estimation is improved by taking the profit of the information computed thanks to the NB-LDPC code.

B. Dependency of f ξ on CCSK score ratio R Let s k be the index of the second-highest decision in (2), i.e.,

s k = argmax i=0,1,...,q-1,i =d k {|L k (i)|}, (11)
and k = L k (s k ) its corresponding value. According to [START_REF] Marchand | Nb-ldpc check node with pre-sorted input[END_REF], the value |γ k | -| k | is related to the reliability of the decision d k (the higher this value, the higher the reliability of the decision d k ). This difference is normalized by |gamma k | to make the algorithm insensitive to a scaling factor, thus leading to the relative ratio R k defined as

R k = |γ k |-| k | |γ k |
. For example, R k = 0 means that the decisions d k and s k have same reliability, thus d k is not a reliable decision. On the contrary, R k close to one indicates a very reliable decision since a high peak exists due to the matched correlation process. This is confirmed by a MC simulation done over 10 8 QCSP frames of length N = 60, q = 64 at SNR = -10 dB. The probability of error P 0 is estimated as a function of R. As shown in Fig. 5, P 0 decreases from 0.83 when R = 0 down to 10 -5 when R get closed to 0.62. The variance ρ has smaller variation effect when conditioned to R. It decreases from 0.31 when R = 0 down to 0.21 for R = 0.6. In the sequel, P 0/R (R) and ρ R (R) will denote the PDF parameters values of f ξ/R conditioned to the observed value of R.

C. Dependency of f ξ on the NB-LDPC code

The probability of error P 0/R can be further enhanced thanks to the information given by the NB-LDPC code, giving a new estimation denoted P 0/R-code .

Let us first describe some features of the NB-LDPC code defined by the PCM H of N -K rows and N columns. The code is assumed to be regular, with weights d v = 2 columns and d c = 3 rows (R c = 1 -2/3 = 1/3). Let M(j) be the set of d c = 3 variable nodes connected to the j th check node (i.e. the non-null positions of the j th row of H) and N (i) = {j 1 (i), j 2 (i)} the set of d v = 2 check nodes connected to the i th variable node (i.e. the non-null positions of the i th column of H). The j th Parity Check (PC) equation for a vector D = (d 0 , d 1 , . . . , d N -1 ) is defined as

i∈M(j) h(j, i)d i = 0, (12)
where h(j, i) is an element in matrix H at index (j, i).

In the absence of decoding error, D is a codeword and thus, all the PCs are fulfilled. On the other side, if decoding errors exist, some PCs will not be fulfilled. The idea here is to perform one decoding iteration of the code with the hard decision vector D. This decoding iteration generates d v = 2 check to variable messages for each variable node. Let M j1(i)→i and M j2(i)→i be the two messages sent by the checks j 1 (i) and j 2 (i) to the variable node i. Those two messages are defined, for x = 1, 2, as [START_REF] Zhang | Low-Complexity Reliability-Based Message-Passing Decoder Architectures for Non-Binary LDPC Codes[END_REF]:

M jx(i)→i = h(j x (i), i) -1 i ∈M(jx(i)),i =i h(j x (i), i )d i , (13
) where d i is the intrinsic decision to variable node i.

To lighten notation, index i is omitted, and (M 1 , M 2 ) denote the two check to variable node messages defined in [START_REF] Saied | Blind Time-Synchronization of CCSK Short Frames[END_REF]. The 3 equality tests (d = M 1 ), (d = M 2 ) and (M 1 = M 2 ) give in total 8 possibilities. This information is used to re-evaluate the reliability of the decision d, and thus, the estimation of the probability of error P 0/R-code . For example, when all the equalities are fulfilled, the local decision is consistent with the code structure and P 0/R-code becomes very low. On the contrary, when (d = M 1 ), (d = M 2 ) and (M 1 = M 2 ), the local decision is inconsistent with the code structure and P 0/R-code increases. The exact mathematical determination of P 0/R-code as a function of R and the equality test results are not presented due to the lack of space. Fig. 6 shows examples of PDF f ξ/R-code for several values of parameters R and equality test results. We can figure out that probability of having error close to zero is higher when R is increased and the equality tests are satisfied. This conditioned PDF f ξ/R-code is used to determine the parameters (ω, θ) in [START_REF] Dillard | Cyclic code shift keying: a low probability of intercept communication technique[END_REF]. Values of Θk , k = 0, 1, . . . , N -1 are shown as an example by the brown dotted line in Fig. 2. Also, Fig. 4-c shows the distribution of the phase offset errors ξk , using the PM phase estimator, for k = 0 and k = N -1 after transmitting 10 4 QCSP frames in an AWGN channel of SNR = -10 dB and random phase offsets. We can figure out that PM aided by the information of the QCSP frame approaches the GA method.

V. SIMULATION RESULTS

This section presents the simulation results of the FEC probability of error for a QCSP received frame, of N = 60 symbols, exposed to random phase offsets. This is implemented using the different phase synchronization scenarios (no phase synchronization, DM, PM) and the ideal case of FEC where the frame has no phase offset. The MC simulations are run over an AWGN channel with stopping criteria of 100 miss-corrected frames, NB-LDPC encoder with coding rate R c = 1/3, q = 64, initial phase offset randomly distributed in [-π, π], and frequency shifts considered to be uniform randomly-distributed in the boundary of ±10 -3 . Moreover, the GF(64)-LDPC decoder defined in [START_REF]Web site on Non-Binary LDPC[END_REF] is implemented using the Extended Mean Sum (EMS) algorithm with 30 decoding iterations and n m = 20 [START_REF] Boutillon | Design of a GF(64)-LDPC Decoder Based on the EMS Algorithm[END_REF]. We can see that a NB-LDPC decoder clearly looses its good performance when not caring about the phase offset, and looses up to 0.5 dB when using the DM. However, when using the proposed PM phase estimator (the blue curve) approximately maintains the same performance of the FEC P as when no phase offset does exist.

VI. CONCLUSION

The paper presented a phase synchronization algorithm for QCSP frames operating at very low SNR (-10 dB) that can help in maintaining the FEC performance as if phase offset is not existing. The proposed PM mitigates the phase ambiguity based on the ML method aided by two side information from the QCSP structure. The first information is from the CCSK demodulation score ratios, where the ML method used a weighted version by privileging the symbols received with high reliability. The second information is from the NB-LDPC code properties, thanks to the code structure. This work will be extended in several directions in the near future. First, a performance-complexity trade-off will be studied. Then, performance assessment at different frame lengths, code rates, and GF(q) will be addressed. Finally, the different scenarios of simulations considered over an AWGN channel will be run over the Rayleigh fading channel.

Fig. 1 .

 1 Fig. 1. Overall Communication Principle.

Fig. 2

 2 illustrates with an example the impact of the channel on the phase of N = 60 detected symbols of a QCSP frame. The channel is an AWGN with SNR of -10 dB, the residual frequency offset is f r = -3.8507 × 10 -5 and the initial phase is φ 0 = 0.5152. Two different sets of phases can be observed: 1) the phases Ψ k of wrongly detected CCSK symbols (d k = c k ) represented by the shaded red circles. According to[START_REF] Bloessl | mSync: Physical Layer Frame Synchronization Without Preamble Symbols[END_REF], those phases are independent with the real phase Θ k ; 2) the phase Ψ k of correctly detected CCSK symbols (d k = c k ) that are correlated with Θ k (see gray area in Fig.2).

Fig. 2 .

 2 Fig. 2. Phase offsets effect due to the channel Ψ k , real phase offsets Θ k , direct method estimation Θk and parametric method Θk .

Fig. 3 .

 3 Fig. 3. Distribution of ξ k at -10 dB where P 0 = 0.2375 and ρ = 0.32, (a): MC-simulation, (b): Theoretical.

Fig. 4 .

 4 Fig. 4. QCSP phase estimation errors distribution for different methods. The circle corresponds to the boundary of SNR degradation above 0.5 dB.

Fig. 5 .

 5 Fig. 5. P 0/R and ρ R as function of R, at SNR = -10 dB.

Fig. 6 .

 6 Fig.6. f ξ/R-code depending on the CCSK ratio R and Code-information, at SNR = -10 dB.

Fig. 7 .

 7 Fig. 7. FEC with different scenarios.

Formally, f ξc (x) should be defined over [-∞+∞]; since ρ < π, f ξc (x) will be given at 0 outside [-π, π] and the required normalization factor is approximated to 1.

This work has been partly funded by the French ANR under grant number ANR-19-CE25-0013-01 (QCSP Project: https://qcsp.univ-ubs.fr/).