Carlos Flores

Vicente Milanés

Fawzi Nashashibi

Using Fractional Calculus for Cooperative Car-Following Control

The Cooperative Adaptive Cruise Control (CACC) is one of the most promising aiding systems to improve traffic flow in highways. When it comes to design a proper control algorithm, robustness against non-modeled dynamics and noise plays a key role not only for improving controller performance but also for increasing the ability of handling heterogeneous vehicle strings. This paper proposes a fractional order controller that is able to deal with non-modeled dynamics whereas keeping simplicity and a low computational cost. System robustness and string stability responses are analyzed for a string of six vehicles, showing a good performance.

I. INTRODUCTION

Traffic flow capacity in urban and peri-urban areas have significantly increased in recent years. The increment in the number of vehicles together with the infrastructure limitations are causing multiple traffic jams, affecting drivers' daily life 1 . Several solutions to this problem have been proposed, such as the employment of Vehicle Ad Hoc Networks [START_REF] Forster | Improving highway traffic through partial velocity synchronization[END_REF] to propagate traffic information among the vehicles and also traffic prediction algorithms with In-Car advice to the driver [START_REF] Schakel | Improving traffic flow efficiency by in-car advice on lane, speed, and headway[END_REF]. Both systems are mainly related to infrastructure adaptation by controlling traffic flow, being able to update intelligent traffic panels for a dynamic maximum vehicle speed in each road depending on the traffic flow.

From the vehicle control perspective, automated speed control systems are a suitable solution to deal with these traffic flow problems. For instance, cruise control system (CC) is a commercial feature whose main purpose is maintaining the vehicle speed in a more stable way than a common driver would. However, it losses its benefits in urban environments where continuous speed changes occur. Therefore, an improved version of the CC, the adaptive cruise control (ACC), proposes an approach to car-following systems which adapts the ego vehicle speed, maintaining a fixed headway time gap with the preceding car by measuring the relative distance between the two vehicles using a front range sensor.

In the recent years, the inclusion of the V2V and V2I communications in the transportation sector has allowed multiple applications to enhance the traffic and road safety [START_REF] Van Arem | The impact of cooperative adaptive cruise control on traffic-flow characteristics[END_REF]. For example, an improved version of the ACC system, the Cooperative Adaptive Cruise Control (CACC), has demonstrated that by adding communication links between ACC-equipped vehicles, shorter inter-distances can be achieved. This yields an increase in traffic throughput [START_REF] Ploeg | Connect & drive: design and evaluation of cooperative adaptive cruise control for congestion reduction[END_REF], and if the distances are short enough, the aerodynamic drag is significantly reduced (specially for heavy duty trucks [START_REF] Fritz | Chauffeur assistant a driver assistance system for commercial vehicles based on fusion of advanced acc and lane keeping[END_REF]). 1 http://ec.europa.eu/transport/road_safety/specialist/statistics/index_en.htm Different CACC implementations have been carried out in recent years. Most of the proposed approaches have been focused on different type of integer-order robust controllers [START_REF] Milanés | Cooperative adaptive cruise control in real traffic situations[END_REF]; but other techniques as MPC [START_REF] Geiger | Team annieway's entry to the 2011 grand cooperative driving challenge[END_REF] or even fuzzy logic [START_REF] Milanés | Low-speed cooperative car-following fuzzy controller for cybernetic transport systems[END_REF] have been proposed to provide stable CACC algorithms.

Focusing on robust controllers, it can be found that up to 95% of current control systems are based on PID controllers [START_REF] Åström | Advanced PID control[END_REF], providing robustness whereas keeping the tuning simplicity. Their main limitations arise by the fact that the controller design assumes integer order models that might be far from the real system response. To cope with this limitation, fractional order calculus has surged recently as a powerful control technique to deal with some of the limitations of PID controllers, whereas keeping the simplicity in terms of computational cost. Some recent examples for fractional order adaptive cruise control applications outperforming classical approaches, can be found in [START_REF] Hassan Hosseinnia | Experimental application of hybrid fractional-order adaptive cruise control at low speed[END_REF], [START_REF] Hosseinnia | Low speed control of an autonomous vehicle using a hybrid fractional order controller[END_REF].

This article presents a fractional order controller approach that allows a ACC-equipped vehicle, with V2V communication, to smoothly maintain the distance gap respect to the preceding vehicle. It will also be evaluated the performance of the proposed controller when implemented in a string of CACC-equipped vehicles.

The rest of this work is presented as follows. Section II reviews the mathematical tool fractional order calculus, its theory and applications. A description of the problem, including the spacing policy and the control structure for the CACC car-following is carried out in section III. Next, the controller design procedure is detailed in section IV. Later, the results for the developed controller with the string stability study are presented in section V; finally some concluding remarks are given in section VI.

II. FRACTIONAL ORDER CALCULUS THEORY

Integer order calculus (IOC) has always been the most used tool for representing models, systems and controllers in all applied sciences. Nevertheless, it is required to have a more accurate and close-to-reality representation/modeling of real processes to satisfy more strict requirements, and for doing so, a new calculus tool must be considered [START_REF] Monje | Fractional-order systems and controls: fundamentals and applications[END_REF].

Due to this exigency, and taking as a consideration that not all systems can be generalized to derivatives and integrals of integer order; in the 17th century Leibniz and L'Hôpital raised the question of having a non integer differential order. But it was in the 19th century when eminent scientists like Euler, Laplace, Fourier among others; discussed the possibility of extending the expression (1) for non integers orders "α". The first real application of the fractional order calculus was made by Abel in 1823, when he discovered that the solution for the integral equation for the tautochrone problem could be obtained through an integral in the form of derivative of order 1/2.

a D α t =    d α dt α = 1 → (α) > 0 1 → (α) = 0 t a (dτ ) -α → (α) < 0 (1)
It introduced the real order generalization of the integer order calculus, which after allowed to model the voltagecurrent relation of a semi-infinite lossy RC line, or the heat diffusion into a semi-infinite solid as well.

To implement the fractional order calculus, it is required to define an operator that allows non integer differentiation. The most widely known definition for this operator was proposed by Riemann-Liouville [START_REF] Oldham | The fractional calculus[END_REF], which can be appreciated in equation ( 2) for (n -1 < α < n). It can be appreciated that this expression is defined by the convolution operator, which refers to memory phenomena.

a D α t = 1 Γ(n -α) d n dt n t a f (τ ) (t -τ ) α-n+1 (dτ ), (2)
In this expression, the term Γ(n) corresponds to the Euler's gamma function. Even though this function has been widely accepted, the initial conditions have no simple physical interpretation. For this reason, the mathematician Caputo [START_REF] Caputo | Linear models of dissipation whose q is almost frequency independent[END_REF] proposed the fractional-order differential operator (see equation 3), where initial conditions like y(0) = y 0 , ẏ(0) = y 1 can be easily interpreted; and m is a natural number immediately superior to α, i.e. (m -1 < α < m).

a D α = 1 Γ(m -α) t 0 f (m) (τ ) (t -τ ) α-m+1 (dτ ), (3)
Most of all applied sciences fractional order implementations use the operator introduced by Caputo, due to the practicality of the initial conditions interpretations that it allows. This expression can also be interpreted in the frequency domain through the Laplace or Fourier transform as well, since several applications in system and process engineering are analyzed in this domain.

L { a D α t } = s α F (s) (4)
In the last decades, the employment of this mathematical tool has grown in the fields of feedback/feed-forward control, signal processing and systems theory; due to the accurate representation of nature process and the flexibility that it provides for designing systems.

A. Fractional Order Controllers Review

A literature review shows that multiple control techniques are based on integer order calculus, such as Proportional-Integral-Derivative calculation [START_REF] Åström | Advanced PID control[END_REF] or Linear Quadratic Regulation [START_REF] Shakouri | Adaptive cruise control system: Comparing gain-scheduling pi and lq controllers[END_REF] among others. They have provided robust solutions to industrial control problems, but the increasing technology and systems complexity, demands more exigent solutions relating to the ones most commonly used. Among the fractional order controllers, it can be found that several implementations have been developed with great results [START_REF] Xue | A comparative introduction of four fractional order controllers[END_REF], in this section it is presented a brief review of some non integer order control techniques.

1) CRONE: The idea of designing fractional order system to control a dynamic system, was introduced by A. Oustaloup [START_REF] Oustaloup | From the second generation crone control to the crone suspension[END_REF] with the CRONE (in french, Commande Robuste d'Ordre Non Entier). For the first generation of the CRONE strategy, its main purpose was to reduce the phase margin variations of the system open loop response.

On the other hand, the main objective of the second generation of the CRONE approach is to directly cancel the phase variations in the gaincross frequency, by ensuring the so-called fractal robustness. To satisfy this requirement, two conditions must be accomplished: a vertical template formed by the open loop Nichols chart, between -π/2 and -π for the nominal parameters of the plant; and the sliding of the template when the plant is re-parametrized.

The frequency template of the transmittance, i.e.sensitivity function, is given by the function [START_REF] Fritz | Chauffeur assistant a driver assistance system for commercial vehicles based on fusion of advanced acc and lane keeping[END_REF], where the arg(β(jω)) = -απ/2 with 1 < α < 2, which results in a Nichols chart with a vertical line that crosses the axis in -απ/2. This allows the sliding of the system in this straight line when the system parameters vary due to changes in the dynamic behavior, and increases the robustness against plant variations. This fact, explains the main objective of the control design proposed by the CRONE technique, which is to approximate the system open loop response to the frequency template of the transmittance function given by β(s).

β(s) = 1 τ s α = ω gc s α (5)
Finally, assuming that a negative feedback and cascade control architecture is employed, the transfer function for the controller C(s) is obtained from the expression [START_REF] Milanés | Cooperative adaptive cruise control in real traffic situations[END_REF], where G p (s) is the plant that is going to be controlled.

C(s) = β(s) G p (s) (6)
Numerous applications of this technique has been carried out, such as car suspension control, hydraulic actuators, among others; bringing great results due to the robustness that this technique provides against model uncertainties or variations.

2) TID Controller: The Tilt-Integral-Derivative Controller [START_REF] Lurie | Three-parameter tunable tilt-integral-derivative (tid) controller[END_REF] proposes a controller that is a modification of the classical Proportional Integral Derivative controller that has provided good results among the years. It has the advantages of the PID controller scheme, but the proportional term is substituted by a tilted compensator whose transfer function is s -1 n , (where n is a real number usually between 2 and 3) in order to get a response that is reasonably closer to the theoretically optimal Bode response. This compensator is referred as "Tilt", as it provides a feedback gain as a function of frequency which is tilted with respect to the gain/frequency of a conventional compensation unit; which is a consequence of having a fractional order integrator. This configuration allows to maintain the system stable under disturbances, even during parameter variations and it can be easily tuned as well.

3) P I λ D µ Controller: The PID controller has been widely used for industrial applications providing good results, and based on that, I. Podlubny [START_REF] Podlubny | Fractional-order systems and pi/sup/spl lambda//d/sup/spl mu//-controllers[END_REF] proposed to take advantage of the fractional order calculus to get a real order generalization of the PID controller. In the equation ( 7), it can be seen the transfer function of the controller in the frequency domain.

C(s) = E(s) U (s) = Kp + Kd • s µ + Ki • s -λ ; (λ, µ) > 0 (7)
The time domain interpretation of the P I λ D µ controller can be appreciated in the equation [START_REF] Milanés | Low-speed cooperative car-following fuzzy controller for cybernetic transport systems[END_REF], where D is the differential operator proposed by Caputo.

u(t) = K P • e(t) + K I • D -λ e(t) + K D • D µ e(t) (8)
The capability of modifying the order of the differential and integral operator, provides a more accurate time and frequency response since it has up to five tuning parameters [START_REF] Monje | Tuning and auto-tuning of fractional order controllers for industry applications[END_REF]. The variation of both orders gives as a result the complex plane showed in figure 1, where by setting both λ and µ as 1, a classical PID controller is obtained.

The P I λ D µ controller takes advantage of the following features to permit a more accurate frequency response based design:

1) The phase delays or phase variation rate per decade can be varied in the range [-π/2, π/2]. For the differential operator, it provides a positive phase increment rate of µπ 4 rad/sec; while the integral operator contributes with a negative phase delay rate of λπ 4 radians per decade. 2) Regarding the magnitude increment/decrement that the differential and integral operator introduce, with this generalization the controller is capable to modify the open loop gain among the range [-20, 20] dB/dec. These properties bring as a result an increment of the design flexibility as it increases the system robustness. This type of controller rises as a way to achieve more demanding control requirements [START_REF] Vinagre | Introducción al control fraccionario[END_REF], without losing simplicity and easy-to-tune capabilities. The P I λ D µ controller is one of the most used fractional order controllers in the literature for the good results it has provided [START_REF] Podlubny | Fractional-order systems and fractional-order controllers[END_REF]; consequently, this is the selected approach that will be further developed in this work.

III. PROBLEM DESCRIPTION

As it was previously stated, CACC systems deal with tighter car-following distance by adding V2V communications whereas a string stable response is obtained. A literature review shows different approaches when developing CACC algorithms, being the most used the robust integer order controllers. For instance, [START_REF] Naus | Cooperative adaptive cruise control, design and experiments[END_REF] presents a control structure with an integer order PD controller. This proposed structure is used in this paper as a basis for designing the CACC fractional order controller. Before explaining the controller design procedure, the spacing policy that the ego-vehicle will employ to generate the reference inter-distance is described.

A. Spacing Policy

Different approaches for spacing policies have been proposed in the literature [START_REF] Swaroop | Constant spacing strategies for platooning in automated highway systems[END_REF], depending on the application upon which it will be implemented e.g. platooning, ACC or CACC. Two main types of spacing policies can be distinguished, the first is the constant spacing policy. This approach has been mostly used for truck or vehicle platoons, where the relative speeds are not considerably high and it is possible to maintain really close inter-distances without any interaction with other lanes. The second type of spacing policy, provides a more flexible conception because it permits to have a variable inter-distance that is function of the headway time. A comparative between this techniques is presented in [START_REF] Swaroop | A review of constant time headway policy for automatic vehicle following[END_REF]. The latter approach is selected in this work.

Headway time spacing policy (see figure 2) proposes having a fixed distance d std added to a variable factor composed by a headway time gap h time multiplied by the ego-velocity v(t) (see equation 9).

d ref = d std + h time • v(t); h > 0 ( 9
)
e i = d real -d ref ; (10)

B. CACC Control Structure

The main objective of this paper is to propose a novel fractional CACC controller based on fractional calculus. The CACC control structure is adopted from [START_REF] Ploeg | Design and experimental evaluation of cooperative adaptive cruise control[END_REF] where a feed-forward control algorithm using an integer order PD controller in the feedback loop was proposed. Figure 3 shows a block diagram representation of the CACC system.

For our desing purposes, the vehicle model proposed in [START_REF] Ploeg | Design and experimental evaluation of cooperative adaptive cruise control[END_REF] was used. According to Fig. 3, Gp(s) refers to the Fig. 3. Control scheme for stability study [START_REF] Ploeg | Design and experimental evaluation of cooperative adaptive cruise control[END_REF] vehicle model that can be described by the transfer function [START_REF] Hosseinnia | Low speed control of an autonomous vehicle using a hybrid fractional order controller[END_REF]. It can be appreciated that its output is the vehicle position using an acceleration command as input. Vehicle dynamic is represented by the term τ .

Gp(s) = 1 s 2 (τ s + 1) (11)
The transfer function D(s) represents the transport delay due to the communication link between the ego-vehicle and its preceding, and it is defined by the expression D(s) = e -θs . In the feedback loop, the H(s) expression composes the spacing policy that is applied to obtain the spacing error, which is given to the controller C(s) to generate the control command.

IV. CONTROLLER DESIGN

Fractional controllers can provide better performance whereas keeping simplicity. Using the proposed control architecture, an integer order PD controller provided a robust solution with good results [START_REF] Ploeg | Design and experimental evaluation of cooperative adaptive cruise control[END_REF]. In spite of this results, one potential problem of the proposed approach is to deal with non-modeled dynamics. The vehicle dynamic plant is built using a simple transfer function that can be oversimplified, specially at low-speeds. Having this in mind, the novel fractional order proportional derivative longitudinal controller (FOPD) is designed paying special attention to increase the system robustness to oversimple vehicle model. This type of controller can benefit from an additional tuning parameter than the classical PD controller. It is the differential operator order which provides the possibility of vary how the controller reacts to the error. Then, the novel FOPD controller contributes to the system relative stability as well as it speeds up the system response to variation in the error incrementing also the robustness against non-modeled dynamics with respect to the integer order PD controllers.

The mathematical expression for this type of controller can be seen in the equation [START_REF] Monje | Fractional-order systems and controls: fundamentals and applications[END_REF], where K p and K d are the gain constants and α is the differentiation order.

C(s) = K p + K d • s α ; (K p , K d , α) > 0 (12)
The controller design procedure will be carried out by defining frequency domain requirements. For the sake of clarity, equation ( 13) can be expressed as:

C(s) = K p + K d ω α cos( απ 2 ) + jω α sin( απ 2 ) (13)
Controller specifications are defined as follows: 1) Phase margin fulfillment,

φ m ≈ π 4 ; arg(Gp(jω gc ) • C(jω gc )) = -π + φ m (14)
2) Open loop gaincross frequency, ω gc ≈ 1rad/sec;

|Gp(jω gc ) • C(jω gc )| dB = 0 (15)
3) Robustness to plant gain variations;

d(arg(Gp(jω) • C(jω))) dω ω=ωgc = 0 (16)
The first two specifications are set to guarantee the controller bandwidth and the phase margin. The third design specification, which aims on having a flat phase in the gaincross frequency, guarantees the good performance to non-modeled dynamics (i.e. model gain changes will not reduce the phase margin). For the first step in the controller design, the model gain and phase (see equation 11) can be described as presented in equations ( 17) and [START_REF] Lurie | Three-parameter tunable tilt-integral-derivative (tid) controller[END_REF].

|Gp(jω)| = 1 ω 2 √ τ 2 ω 2 + 1 (17) arg(Gp(jω)
) = -π + tan -1 (τ ω) (18)
On the other side, the controller gain can be determined through the equation [START_REF] Monje | Fractional-order systems and controls: fundamentals and applications[END_REF]. In the same line, the controller phase can be as well defined from the expression [START_REF] Oldham | The fractional calculus[END_REF].

|C(jω)| = K 2 p + 2K p K d cos(απ/2) + K 2 d ω 2α (19)
arg(C(jω)) = tan -1 K d ω α sin( απ 2 ) K p + K d ω α cos( απ 2 ) (20)
Therefore, to satisfy the first condition, the equations ( 18) and ( 20) are used to assure the phase margin.

-tan -1 (τ ω gc )+tan -1

K d ω α gc sin( απ 2 ) K p + K d ω α gc cos( απ 2 )
-φ m = 0;

(21) For the second condition, equations ( 19) and ( 17) are used to set the gaincross frequency.

K 2 p + 2K p K d cos( απ 2 ) + K 2 d ω 2α gc • 1 ω 2 gc τ 2 ω 2 gc + 1 = 1 (22)
For the third specification, that correspond to the phase derivative in ω gc , is analyzed from the controller and model phase in the gaincross frequency. By applying the design procedure described previously, a non-linear equation system is obtained. It can be solved by employing the MATLAB function f solve to find the optimal configuration for K p , K d and α that allows to satisfy the three requirements. Hence, from equations ( 21), ( 22) and ( 23) the controller parameters result: Kp = 0.455, Kd = 1.875 and α = 0.6849. The open loop response according to this parameter configuration is showed in Fig. 4.

K p K d αsin( απ 2 )ω α-1 gc K 2 p + 2K p K d cos( απ 2 )ω α gc + K 2 d ω 2α gc - τ 1 + τ 2 ω 2 gc = 0 (23)
From the Bode plot, it can be appreciated that the phase margin and gaincross frequency specifications are properly satisfied. It can also be seen that the flatness in the phase around the gaincross frequency, assures that the phase margin will be maintained around -π 4 if non-modeled dynamics are present over the vehicle, that would lead to modifications on the model gain.

V. RESULTS

The designed controller was validated using a 6 CACCequipped vehicles string. The leading vehicle followed a speed profile with several speed changes to simulate a real traffic scenario where continuous acceleration/braking maneuvers occur. This profile will allow to assess the whole vehicle string stability response. For the simulation, the V2V communication delays are set at θ = 0.2sec. The headway time gap applied in the spacing policy is 0.6sec according to previous studies [START_REF] Nowakowski | Cooperative adaptive cruise control: Driver acceptance of following gap settings less than one second[END_REF].

Figure 5 shows the vehicle responses to the speed profile using the FOPD CACC controller. The upper plot depicts vehicles' speed. The middle one represents vehicles' acceleration. The bottom plot shows the distance error with respect to the defined spacing policy.

Leader vehicle speed changes were defined within the range of 0 and 22.5 m/s. For each speed change, a different acceleration command was set to evaluate string response to both aggressive and gentle reference variations. Acceleration changes were limited up to a maximum of 4.5m/s 2 . Finally, the distance error graphically shows whether the string stability is maintained (i.e. the higher the vehicle position, the lower the distance error) or not.

It is important to remark that the leader speed oscillations are accurately tracked by the other vehicles without being amplified downstream, which means that the system is string stable. This fact is mostly appreciated in the second and third plot, where the distance errors accelerations are attenuated along the string, for each vehicle. Consequently, the string stability for the developed controller is demonstrated for a headway time gap of h=0.6sec.

A. String stability analysis

The system string stability is analyzed by using the control structure showed in Fig. 3. The string stability transfer function can be derived as [START_REF] Swaroop | Constant spacing strategies for platooning in automated highway systems[END_REF], which must be maintained as less than 1 to guarantee the systems' string stability. By replacing C(s) for the designed fractional controller and keeping the communication delay θ = 0.2sec, the string stability (Γ(jω)) limit in function of the time gap is studied in fig. 6.

Γ(jω) = D(s) + G p (s)C(s) H(s) (1 + G p (s)C(s)) (24)
One can appreciate how the theoretical minimal time gap to guarantee the string stability is h=0.55sec. Then, the string stability is no longer fulfilled, becoming string unstable and, in consequence, amplifying leader speed oscillations.

VI. CONCLUSIONS

This paper proposes a novel fractional control algorithms to deal with CACC systems. Firstly, a state-of-the-art review of fractional order calculus is included and a brief comparison with respect to integer order controllers (i.e. PID)

String Stability Limit Research

Frequency (rad/s) h = 0.75 sec h = 0.65 sec h = 0.55 sec h = 0.45sec h = 0.35sec Fig. 6. String stability limit for multiple time gaps, applying the designed controller is carried out. Then the control architecture, including the time gap policy chosen are detailed. Later, the controller is designed with robustness against non-modeled dynamics that is one of the major problems to deal with when controlling automated vehicles.

The system was tested in simulation using a 6 CACCequipped vehicles string. Vehicles exhibit a good response in terms of not only tracking the gap error regulation but also by keeping string stability. Finally, a string stability analysis to determine the controller boundaries is carried out, being able to provide stable responses up to a time gap equal to 0.55sec.

The future work will be mainly focused on two directions. On one hand, different control structures and configurations will be evaluated to figure out the one that provide better results in terms of stability. Then, real tests on INRIA experimental platforms will be developed to assess controller's performance on real traffic circumstances.

Fig. 1 .

 1 Fig. 1. Complex plane, for fractional order PID controller

Fig. 2 .

 2 Fig. 2. Representation of a car-following scenario

Fig. 4 .

 4 Fig. 4. Bode plot for the open loop response with the parameters obtained

Fig. 5 .

 5 Fig. 5. Performance evaluation for a string of 6 vehicles equipped with CACC

ACKNOWLEDGMENTS

Authors express their gratitude to the European project AutoNet2030, the french project VALET and the RITS Team for its support in the development of this work.


Wiebke Beckmann

Matthias Bonn
email: matthias.bonn@kit.edu

Tobias Kurze
email: kurze@kit.edu

Klaus Rechert

Saher Semaan

Dennis Wehrle

Project bwDataDiss: bwData for Dissertations

Keywords: dissertation, research-data, long-term storage, characterization, open access

Nowadays research relies more and more on data to achieve progress in various scientific domains. To understand and to be able to reproduce results, it is essential that the underlying research data is available to scientists -even after a relatively long time. bwDataDiss is an effort to provide infrastructure and services for a very specific group of researchers -namely PhD students -to enable them to store and archive their research data and also to make it available to other researchers.

I. INTRODUCTION

bwDataDiss is a three year project funded by the Ministry for Science and Art of Baden-Württemberg. Project partners are both the university libraries and computing centres of Freiburg and Karlsruhe.

In the context of their doctoral dissertation, PhD students often produce research data. As the scientific society becomes more and more aware of the importance of verification of research results, the general need to build up digital infrastructures to archive and enable access to research data arises. But currently libraries often lack the digital infrastructure to handle research data as they are often heterogeneous with regard to contents and filetypes.

Traditionally libraries have been involved and play an important role in the dissertation process. They have the respective workflows in place and know the procedures. However, those workflows differ from library to library and may sometimes be relatively complex. To capture some of this diversity the university libraries of Karlsruhe and Freiburg bring in their knowledge to bwDataDiss.

Libraries usually don't have the means to store nor to analyze or work with large amounts of data. The SCC1 provides the IT infrastructure and systems that permits bwDataDiss to store and archive research data, while the computing centre of the University of Freiburg performs -what we call -a characterization of the research data.

II. RELATED WORK

There is a number of projects working on the long-term preservation of research data and of course their results are continuous integrated into bwDataDiss. The following list has a strong focus on Germany:

The project RADAR2 or Research Data Repositorium, provides infrastructure for research data management and is a joint effort of the FIZ Karlsruhe, the Steinbuch Centre for Computing (SCC), the Ludwig-Maximilians-Universität Munich (LMU) and the German National Library of Science and Technology (TIB).

MO|REdata is another research data project with a very specific mission in the field of sports sciences. MO|REdata has built up an infrastructure to collect and provide motor skills data as well as normative data.

An extensive survey was undertaken in the project bwFDM3 by the nine universities in the state of Baden-Württemberg in order to get an idea of what researchers need and expect from institutional research data management.

FreiDok plus4 is the institutional repository of the University Library of Freiburg. During the past few years it has been developed into a current research information system in order to represent the complete landscape of research at the university. Since then, FreiDok plus also enables the publication and archiving of research data and provides clever workflows for its users.

III. CONCEPT AND INTEGRATION SCENARIOS

bwDataDiss enables university libraries in the State of Baden-Württemberg to archive research data together with the final dissertation. The main concept is that the associated libraries remain contact point for PhD students and potential users of bwDataDiss at all times, it has not been designed to work independent of libraries -quite the contrary: bwDataDiss relies on libraries to provide crucial services and counselling to PhD students and researchers who want to store and archive their research data. Also librarians are and will remain in charge of capturing and controlling the required metadata.

For sake of simplicity and without loss of generality, from now on we describe the systems, relations and interactions between bwDataDiss and just a single library.

A. Principles

The design of bwDataDiss follows the following principles:

• Keep it easy for our primary customers: the researchers and especially Ph.D. candidates • Ensure data integrity at all times • Allow for a flexible integration with library systems

B. Separation of duties

There is a strict separation of duties (also see figure 1) between bwDataDiss and the library: As libraries already play a crucial role in the dissertation process, it is consistent that the transfer of research data -being considered to be part of the dissertationis integrated in that same process. The workflow consists roughly of the following steps (order negligible):

• PhD candidate transfers dissertation script (library website) • PhD candidate provides metadata for dissertation script (library website)

• Library checks the provided data and contacts the PhD candidate if necessary When considering research data, at least two additional steps are needed:

• Transfer research data (to bwDataDiss or to the library) • Provide metadata for research data (to bwDataDiss or the library) C. Integration scenarios 1) Upload: This is where bwDataDiss comes in. bwDataDiss supports several possibilities to integrate its services with library systems in order to transfer the research data from the Ph.D. candidate to the long-term storage.

There are two basic models to transfer the data:

• Either the data is transferred directly from the PhD candidate to bwDataDiss or • The data is temporarily stored on library servers and then later on transferred from the library to bwDataDiss. Either way, it is entirely up to the library to check the provided metadata.

a) Details on direct data transfer: There are two possibilities to realize the direct data transfer from the Ph.D. candidate to bwDataDiss and it's up to the library to decide which solution to implement. For a more coherent presentation of the library website, the upload component, which actually realizes the data transfer to bwDataDiss can be integrated in the library website. Although the component is on the library website, it will upload the data directly to bwDataDiss.

Another less seamless integration would be, to forward a user to the uploader on the bwDataDiss website. The upload could then happen there, but it would be apparent to the user that he or she has left the library website. See section IV-C for more details on the uploader.

2) Metadata: bwDataDiss supports different models to input metadata. The first and easiest possibility consists of filling in a web form on the bwDataDiss website. This obviously requires a user to navigate to bwDataDiss and to leave the library website.

To keep bwDataDiss in the background, the metadata can either be pushed from the library or actively pulled by bwDataDiss from the library. More details can be found in section V-A and section IV-B.

IV. IMPLEMENTATION bwDataDiss is implemented using PHP and Symfony, a Web Application Framework. Also JavaScript is used to provide certain functions, such as a reliable upload of huge files. bwDataDiss distinguishes three types of basic user roles: library role, bwdd-admin role and regular user role. A user that possesses the bwdd-admin role can set roles respectively promote regular users to library users or to admin users.

A. Web-Frontend

In principle, bwDataDiss is designed as a self service portal, though a library can restrict its users to certain functions. It can be accessed at https://bwdatadiss.kit.edu. The entire portal is available in German as well as in English. Please note, that at the time of the writing the portal is still under development.

B. API and File Management

We have a state-of-the-art REST xml and json based API which uses key authentication. It provides functions to create datasets, edit their metadata, upload files using file chunks, query datasets by state and query file data, etc. It also provides functions to query archivation tasks and to report their successful execution. Almost all functionality that is provided on the bwDataDiss website can also be leveraged through the use of the API. The API can only be accessed over HTTPS and requires an authentication header (X-API-KEY) to be present and set to a correct API key. Every user has its own unique API key(s) and can thus be identified by it. An API key is generated upon first succesfull login of a user. If the API call returns values, they can either be obtained in JSON or XML format. The default is JSON, but by appending .xml to the URL the format can be set to XML.

Not only external users use the API, but also some internal (asynchronous) components of bwDataDiss use the API to query or set the status of entities.

Figure 2 illustrates the use of the API and the keys respectively.

C. Upload Component

bwDataDiss comes with a potent upload component. As outlined in section III, data integrity is crucial for bwDataDiss and has to be ensured by the uploader. The uploader transfers the data from the Ph.D. candidate to bwDataDiss. It is able to upload files of any size, allows to resume uploads and calculates checksums to ensure data integrity.

To upload a file, it is split into chunks of a certain size and the chunks are then treated separately: first, a checksum is calculated, then the data of the chunk, together with its checksum is transferred to bwDataDiss. An example is depicted in figure 3. To communicate details, such as chunk-size, file-size, checksums and the actual data the uploader talks to the bwDataDiss API. The uploader is written in JavaScript, able to utilize multiple threads and to handle files in parallel.

D. User Authentication and Access using bwIDM

To identify users, bwDataDiss relies on another service called Föderiertes Identitätsmanagement der baden-württembergischen Hochschulen (bwIDM)5 . bwIDM allows users at a BW-university -to be authenticated using Shibboleth6 (SAML-based Web-SingleSignOn). For alumni users with no access to such a federated account (or external PhD students, for example) we implemented an invitation mechanism to create local accounts. This invitation has to be triggered for every external student by the corresponding library.

The access to the archive itself is hidden from end users, the archive login is done using a single non-bwIDM LDAP system account with public key authentication, using a directory/file naming scheme to map datasets to end users (see section "Archive Integration" below). As a result, end user's ACLs cannot be enforced at archive, this must be done on web server level.

E. Authentication and Integration by/with foreign libraries

bwDataDiss provides a range of services that may be used by libraries. The most simple and basic integration scenario just involves the archivation of data and the harvesting of the corresponding metadata.

As mentioned in section III the associated libraries are the starting point of their PhD students, it means after authentication (as described below) the user submits the publication (PhD thesis), the research data and the related metadata according to the library workflow. The library can afterwards and in an asynchronous transmission push the data to bwDataDiss using the API described in section IV-B. Another advanced integration can adapt a distinguished bwDataDiss service in the library publication workflow, such as the characterization (chapter 4.5). After submission the complete data set (PhD thesis, corresponding research data and metadata for both) through the user, the library pushes the research data to bwDataDiss using the API for characterization and then querying the result from bwDataDiss again through the API to make local decisions according to the research data before the final push of the whole data set to bwDataDiss. To delegate authenticated user-contexts from a library frontend to the API-key based bwDataDiss backend, a library first authenticates a user with Shibboleth Web-SSO. Then it can authenticate itself using an HMAC-SHA256 based signature to pass the user's Shibboleth SAML token to bw-DataDiss and to query a bwDataDiss APIkey for the user. So asynchronous API calls can be done from the library frontend to the bwDataDiss backend without losing the initially established end users context.

Another scenario is described in figure 4. Users can be delegated for authentication to their home university Identity Provider (IdP) using the federated bwIDM infrastructure. In contrary to the previous scenario user-contexts will not be delegated from the library on behalf of users, but users will be delivered to home the Identity Provider (IdP). In our case Shibboleth IdPs, which are all in the same bwIDM federation.

F. Data Characterization

Content and data formats vary widely between different disciplines. Since the bwDataDiss service is planned as a university-wide, interdisciplinary service offer, the service provider needs to accept any domain-specific data format while still maintaining quality standards (e.g. completeness, usability and accessibility of stored data) as well as prepare for long-term preservation activities. In particular long-term preservation (in today's fast technical lifecycle, even the mandatory 10 years data redemption policy7 may become a major challenge) activities to maintain accessibility and ideally allow re-use (e.g. for reproduction of scientific results or comparison with recent research) of the data stored, risks posed by accepted data-sets and in particular risks of enclosed data formats need to be assessed and maintained. For this, a data format characterization service has been integrated into the bwDataDiss service model.

1) Towards a Data Risk Policy: The goal of the characterization service is to provide an overview on preservation risks w.r.t. access, re-use and verification of the data set's content. For this, the research data's logical and structural representation -the file formats -need to be assessed, in particular, if the format documentation is available and what kind of software is necessary to render or retrieve the file's information content. Based on this information predictions on (long-term) (re-)usability can be made, a risk register can be set up and, if appropriate, preservation tasks can be planned and prepared (e.g. preparations for file format migration).

The results of the characterization service can be used either as pre-ingest check, e.g. as a tool for feedback to an initial submission, i.e. flagging unsustainable, unknow or otherwise difficult file-formats. Based on this feedback, individual researchers can be advised to re-consider their file-format choices (if possible) and their awareness can be raised on the un-sustainability of their format choices. Furthermore, the characterization results may be used to guide a software collection, required to render certain data sets or to prepare an emulation or virtualization strategy.

2) Data Characterization: bwDataDiss provides a RESTful characterization service for analyzing data sets. We have chosen FITS 8 as a file characterization meta-tool, as it wraps various file characterization tools into a single and customizeable Java framework.

A characterization request is issued by POSTing a JSON object containing a reference (URL) to the data set and a reference to an optional policy file. For efficiency reasons we require to unpack data sets and wrap the resulting file-tree within an ISO9660 container (CD-ROM / DVD format). This way, a prior download of the data set for characterization is not necessary. Instead, the remote file is mounted to the local filesystem and data required for file format characterization is only transferred on request. For Urls we use range requests 9 for random access to files with a data set. Since user data is only cached in memory, parallel requests can be handled without considering temporary disk space constraints.

Example request: http://bwdatadiss.eaas.uni-freiburg.de:8080/bwdatadiss/FileFmtCheck/init { " o b j e c t U r l " : " h t t p : / / b w d a t a d i s s / m y s e t . i s o " , " p o l i c y U r l " : " h t t p : / / b w d a t a d i s s / b a s e -p o l i c y . t x t " } The service will immediately return a session id, which can be used for querying the status of the characterization request. Depending on the object size, the characterization may take some time to finish. By using the session id, the requesting client is able to retrieve the characterization result. If the characterization is not finished, the client is required to repeat the request later.

The bwDataDiss' characterization result is a file format distribution, i.e. the number of files found per file format (PRONOM ID 10 ).

Example request: http://132.230.3.211:8080/bwdatadiss/FileFmtCheck/getResultSummary?sessId=5 { " summary " : [ { " t y p e " : " x-f m t / 1 1 1 " , " v a l u e " : "GREEN" , " c o u n t " : " 2 4 2 " } , { " t y p e " : " f m t / 1 6 " , " v a l u e " : "GREEN" , " c o u n t " : " 2 " } , { " t y p e " : " x-f m t / 4 1 1 " , " v a l u e " : "RED" , " c o u n t " : " 1 " } } Also a detailed result can be requested, which contains a list of files (including their relative path) for each PRONOM ID. If also a policy file was provided, a "verdict" on for each format is added. In the example above, the policy file contains traffic-light coloring, assigning "x-fmt/111" (Plain Text) and "fmt/16" (PDF) the color "GREEN" 8 File Information Tool Set (FITS), http://projects.iq.harvard.edu/fits/home 9 Hypertext Transfer Protocol (HTTP/1.1): Range Requests, https://tools.ietf.org/html/rfc7233 10 PRONOM file format registry, http://www.nationalarchives.gov.uk/PRONOM/Default.aspx and "x-fmt/411" (Windows Executable COFF) the color "RED". In a future version, it will be possible to reference multiple policy files, published by different institutions. This way, it becomes possible to share the work maintaining a comprehensive file format policy and covering the great variety of file formats typically found in research data sets.

G. Archive Integration

The High Performance Storage System (HPSS11 ) based archive offers a standard hierarchical file system access by SFTP to its integrated large disk cache, which hides the underlying tape-based long term storage system. So the usage of the archive by the bwDataDiss (bwDD) system has to be done using remote access to the SFTP-Interface. This integration is done via an automated FUSE based SSHFS mount point in the bwDD host system, which hides the SFTP protocol and offers a standard local directory which can be accessed with any local file system tools or programming libraries; but with one essential constraint: Access to this mount point can be significantly slower than local filesystem or NFS/CIFS mounts, especially when remote files are stored on archive tape instead of archive disk cache (HPSS does both, depending on file size and access frequency/profile). As a result, writing new files to the archive normally is performed with sufficient speed, but reading a file which has already been moved from the disk cache to the tape system can be a long running task with unpredictive latencies. So we had to realize an asynchronous coupling of the archive to the web frontend.

The decoupling is done by detaching the archive integration/connection from the apache/php based web service. Because asynchronous background threads are not possible in php and provide the risk of blocking the web service request handling, we implemented a separate backend worker process. This backend service worker uses the bwDD REST API to query archivation tasks (insert, read) and maps the internal bwDD data model to remote SSHFS-mounted (potentially delayed and slower) filesystem (figure 5). There, it creates (uncompressed) BagIt12 directories where it copies uploaded files from local filesystem (see figure 6). Every metadata (bibliographical and technical) including transfer logs are also written to the archive, which leads to a self-describing archive file system structure (grouped by libraries), which is an essential point for a long term archive. In the naming scheme, [Library-Name] and [DataSet-ID] are unique within the bwDD system, [User-EPPN] is unique at least within the user's home-library.

To read an archived dataset, the complete BagIt is asynchronously copied back from remote SSHFS mount point to a fast local filesystem cache where the web server has direct access to serve the files for download, optionally as zip containing all files including the BagIt description and all other metadata files (but no transfer

Figure 1 .

 1 Figure 1. Separation of duties Library: • Help-desk and services for Ph.D. candidates: The place to go for Ph.D. candidates • Acquisition and control of metadata bwDataDiss: • Archivation of data • Provide archived research-data to scientific community • Perform characterization and provide its resultsAs libraries already play a crucial role in the dissertation process, it is consistent that the transfer of research data -being considered to be part of the dissertationis integrated in that same process. The workflow consists roughly of the following steps (order negligible):• PhD candidate transfers dissertation script (library website) • PhD candidate provides metadata for dissertation script (library website)

Figure 2 .

 2 Figure 2. API, keys and components

Figure 3 .

 3 Figure 3. Chunked upload of a a file to bwDataDiss

Figure 4 .

 4 Figure 4. Delegation to home IdP

Figure 5 .

 5 Figure 5. Archive Integration (HPSS System strongly simplified)

Figure 6 .

 6 Figure 6. Archive Directory and File Structure

Steinbuch Centre for Computing

https://www.radar-projekt.org/

https://bwfdm.scc.kit.edu/ -Baden-Württemberg Forschungsdatenmanagement = research data management

https://www.freidok.uni-freiburg.de/

https://www.bwidm.de/

http://shibboleth.net/

DFG Empfehlungen zur Sicherung guter wissenschaftlicher Praxis, http://www.dfg.de/download/pdf/dfg_im_profil/reden_stellungnahmen/ download/empfehlung_wiss_praxis_0198.pdf

http://www.hpss-collaboration.org/

https://tools.ietf.org/html/draft-kunze-bagit-13

https://www.radar-projekt.org/display/RE/2014/11/14/RADAR+Metadata+Kernel+v+0.2

https://www.openarchives.org/pmh/ Protocol for Metadata Harvesting

logs). All archivation tasks queried from the bwDD REST API are verified by comparing checksums. When a transfer is completely done and fully verified, the success is reported to the API, where the web server presents the results to the user. If an error occurs during an archivation task, the failure result is not reported to the API and the task is replayed after an increasing waiting period.

V. METADATA

bwDataDiss is open be be used by the university libraries in the State of Baden-Württemberg and bwDataDiss' metadata scheme pays tribute to this fact by being relatively generic. The scheme is partially inspired by the RADAR metadata kernel 13 . Some metadata has to be provided coercively, some not. Table I A few of the mentioned items might need some explanation: Readme: We believe, that especially for research data, it is important to explain how files are organized and how the data can and should be used. The text that is provided as readme will not just be stored in the database, but also be added as a file to the research data. This ensures, that potentially important information about the research data is always available as a text file besides the other files.

Classification: bwDataDiss uses a quite unusual classification from the DFG. This classification is more detailed concerning technical disciplines and therefore also suited for universities with a technical focus. Still it is generic enough to be used by any (non-technical) university as well.

Resource Type: Borrowed from the RADAR metadata kernel, it is one of the following items, specifying the type of the research data: audiovisual, collection, dataset, image, model, software, sound, text, workflow, other.

License: bwDataDiss promotes and is committed to Open Access and thus comes with CC-BY and CC-BY-SA licenses to be chosen from. However we understand that there might be circumstances when those licenses are not eligible and therefore allow libraries to add new licenses.

Embargo date: There are certain circumstances when it might be necessary to forbid access to research data, for example when a patent application is still pending. Thus, bwDataDiss allows to specify an embargo data, prohibiting the access to the research data until the given date.

A. Acquisition

As mentioned in section III, it is up to the library to collect and check the metadata. bwDataDiss keeps a copy of the metadata along with the corresponding research data. To obtain the metadata, bwDataDiss regularly queries the library repositories using OAI-PMH 14 . This way, even if changes should not happen very often, bwDataDiss always has the latest metadata.

If the library does not provide an adequate interface, it can push the metadata using the bwDataDiss API.

VI. OUTLOOK

bwDataDiss is still under development und currently not yet ready for production. The characterization component is not completely finished and needs some attention during the next few weeks. However we plan to go live before the end of the year. Currently we focus on the integration with the library systems at KIT and at the university of Freiburg -a crucial step for bwDataDiss to be put into service.


Lilian Bossuet

Nilanjan Datta

Cuauhtemoc Mancillas-López

Mridul Nandi

Hardware Performance of ELmD and ELmD(6,6)

Keywords: Authenticated Encryption, Pipelining, Hardware Performance

ELmD (Encrypt-Linear mix-Decrypt) is a blockcipher based efficient authenticated encryption scheme, which is nonce misuse resistant, fully pipeline implementable. ELmD is a candidate for CAESAR competition and it has been selected for the second round. In this document, we first consider two versions of ELmDv2.0 -(i) ELmD: full 10-round AES encryptiondecryption, no intermediate tag, fixed tag size and (ii) ELmD(6,6): 6-round AES encryption-decryption, no intermediate tag, fixed tag size. We provide the full specification for both the version and present hardware implementation of the combined encryptiondecryption for both these versions. We discuss and compare the hardware performance of these versions with other popular AE schemes like COPA and OCB.

I. INTRODUCTION

The common application of cryptography is to implement a secure channel between two or more users and then exchanging information over that channel. Once the users have a shared key, either through the initial key set-up or key-exchange, they use this key to authenticate and encrypt the transmitted information using efficient symmetric-key algorithms such as message authentication code M ac(•) and (symmetric-key) encryption Enc(•). The encryption provides privacy or confidentiality (hiding the sensitive data M , we call it plaintext or message) resulting a ciphertext C, whereas a message authentication code provides data-integrity (authenticating the transmitted message M or the ciphertext C) resulting a tag T . An authenticated encryption or AE is an integrated scheme which provides both privacy of plaintext and authenticity or data integrity of message or ciphertext. Now a days, cryptography community is putting a lot of effort of designing different authenticated encryptions. CAESAR [START_REF] Nandi | Competition for authenticated encryption: Security,applicability, and robustness[END_REF], a competition for Authenticated Encryption is going on, in order to identify a portfolio of authenticated ciphers that offer advantages over AES-GCM and are suitable for widespread adoption. In the first round of CAESAR, 57 AE schemes were submitted and 29 of them have been qualified for the second round.

A. Hardware Implementation of Authenticated Encryption

In the literature there are many works about the hardware implementations of authenticated encryption based on block ciphers mainly standardized ones, GCM and CCM. As CCM has a sequential component for authentication since it uses CBC-MAC its implementation spectrum is not wide some examples of its implementation on FPGAs are [START_REF] López-Trejo | An FPGA implementation of CCM mode using AES[END_REF] and [START_REF] Algredo-Badillo | Efficient hardware architecture for the AES-CCM protocol of the IEEE 802.11i standard[END_REF].

GCM offers many ways for parallel implementations as is explored in [START_REF] Lemsitzer | Multi-gigabit GCM-AES architecture optimized for fpgas[END_REF] for FPGAs and [START_REF] Satoh | High-performance hardware architectures for galois counter mode[END_REF] for ASIC.

For CAESAR submissions there are no much hardware implementations yet, some of the available implementations are ICEPOLE [START_REF] Morawiecki | ICEPOLE: high-speed, hardware-oriented authenticated encryption[END_REF], SPRING [START_REF] Brenner | FPGA implementations of SPRING -and their countermeasures against side-channel attacks[END_REF] in [START_REF]Authenticated encryption fpga ranking[END_REF] there are implementations results for Keyac, OCB, CLOC, PRIMATEs-GIBBON, PAEQ, PRIMATEsHANUMAN, POET, PRIMATEs-APE and AES-COPA. All the mentioned implementations are designed in sequential fashion, in this work we present pipelined implementations for ELmD and COPA. In general sequential implementations are small in terms of area but not too much as lightweight ones, also the throughput is better than lightweight but not enough for high speed applications. So we are trying to exploit the properties in this two modes to get a really fast implementation, able to process huge amount of data trying to keep the area reasonable.

B. Our Contribution

Here, we have considered ELmD, a CAESAR submission qualified for the 2nd round of the CAESAR competition. In this document, we first describe one of the 8 versions that have been submitted in CAESAR -ELmD with full 10 round AES encryption-decryption, no intermediate tag, fixed tag length (we call this version as ELmD) in section 2. Then in section 3, we describe a fast variant of this version -ELmD with 6 round AES encryption-decryption, no intermediate tag and fixed tag length. In section 5, we provide combined pipelined hardware implementation for both the versions and show that ELmD has good pipelined hardware performance. Moreover we compared the performance with COPA and make an important observation that ELmD requires only half of the area that COPA requires and yet offers higher throughput than COPA. We also make a comparative study of the hardware performance of ELmD with OCB-3, GCM, EME2 etc.

II. SPECIFICATION OF ELMD

ELmD is a block-cipher based authenticated encryption takes an associated data D ∈ {0, 1} * , a messages M ∈ {0, 1} * , a nonce N and generates a tagged-ciphertext C ∈ {0, 1} |M |+ltag in two steps, as described below. We compute L = E K (0) and use it to generate masks, during the tagged ciphertext generation. Here E K is the block-cipher and instantiated by full 10-round AES.

A. Initial Value Generation.

Suppose we have a nonce N and an associated data EMPTY ASSOCIATED DATA. If associated data is empty, we generate IV as follows:

D = (D[1], D[2], • • • , D[d -1], D[d]). We set, W [0] = 0 N 3.L ⊕ E K DD[0] Z[0] 0 ρ D[1] 3.2.L ⊕ E K DD[1] Z[1] ρ D[d] 3.2 d-1 .L ⊕ E K DD[d] Z[d] ρ • • • • • • IV
DD[i] = D[i] ⊕ 3 • 2 i • L for i = 0 to d Z[i] = E K (DD[i]) for i = 0 to d (Y [i], W [i + 1]) = ρ(Z[i], W [i]) for i = 0 to d IV = W [d + 1]
IV = E K (D[0] ⊕ 3 • L).

B. Tagged Ciphertext Generation.

The tagged ciphertext is generated using the message M and the IV , generated as described above using the nonce N and the associated data

D. Suppose M = (M [1], M [2], • • • , M [l -1], M * [l]). If the final message block (M * [l]
) is incomplete, then we make it complete by 10 * masking: M * [l] = M * [l] || 10 * .Now, the tagged ciphertext C is generated using the following equations :

W [0] = IV M [l] = ⊕ l-1 i=1 M [i] ⊕ M * [l] M [l + 1] = M [l] M M [i] = M [i] ⊕ 2 i-1 • L for i = 1 to (l + 1) X[i] = E K (M M [i]) for i = 1 to (l + 1) (Y [i], W [i]) = ρ(X[i], W [i -1]) for i = 1 to (l + 1) CC[i] = E -1 K (Y [i]) for i = 1 to l C[i] = CC[i] ⊕ 3 2 • 2 i-1 • L for i = 1 to l CC[l + 1] = E -1 K (Y [l + 1] ⊕ 1) C[l + 1] = CC[l + 1] ⊕ 3 2 • 2 l • L M [1] L ⊕ E K M M [1] X[1]
IV ρ The algorithm returns tagged ciphertext C

E -1 K 3 2 .L ⊕ Y [1] CC[1] C[1] M [2] 2.L ⊕ E K M M [2] X[2] ρ W [1] E -1 K 3 2 .2.L ⊕ Y [2] CC[2] C[2] M [l] 2 l-1 .L ⊕ E K M M [l] X[l] ρ • • • E -1 K 3 2 .2 l-1 .L ⊕ Y [l] CC[l] C[l] M [l + 1] 2 l .L ⊕ E K M M [l + 1] X[l + 1] ρ W [l] E -1 K 1 ⊕ 3 2 .2 l .L ⊕ Y [l + 1] CC[l + 1] C[l + 1]
= ( C[1..l], (C[l + 1]) |M * [l]| ). INCORPORATING INCOMPLETE FINAL BLOCK. If the final message block (M [l]
) is incomplete, then we make it complete by 10 * masking:

M [l] = M [l] || 10 * . The generation M M [0], • • • , M M [l -1]
is identical as above but we modify generation of M M [l] and M M [l + 1] as follows (to distinguish from complete block associated data):

M M [l] = M [l]⊕7•2 l-2 •L, M M [l+1] = M [l+1]⊕7•2 l-1 •L.

III. ELMD(6,6): A FASTER VARIANT OF ELMD.

ELmD [START_REF]Cryptographic Hardware and Embedded Systems -CHES 2014 -16th International Workshop[END_REF][START_REF]Cryptographic Hardware and Embedded Systems -CHES 2014 -16th International Workshop[END_REF] is a faster variant of ELmD where we instantiate 6 round AES encryption as block-cipher encryption E K and 6 round AES decryption as block-cipher decryption E -1 K .

From the structure of ELmD, we observe that, for some applications, even much lesser rounds of AES encryption or decryption is good enough to provide the desired security. Particularly we need to resist the collision in the upper layer encryption and want high randomness in the combined two layer encryption. Now, as 6 round AES gives good differential property (6-round AES is a good collision resistant hash) and the total of 12 (= 6 + 6) rounds of AES in the combined upper-lower layer provides the desired randomness, we believe that choosing 6 rounds in both the layers will provide the desired security. Hence, we opt for the round parameter 6 as one of our recommended choice. The masking value L is defined as L = E K (E K (0)). The two block-cipher calls are used to ensure the required randomness. In this context, we also note that AES-6 has many key-recovery attacks but all those attacks uses the property that the chosen plaintexts has certain differential characteristic. Here these attacks are not applicable due to the upper layer masking and the randomness of L.

To encrypt multiple messages under same associated data, one can have separate modules for AD processing and message-ciphertext processing. To ensure that AD processing module does not need any inverse, we define L to be E K (E K (0)) (instead of something like E K (E -1 K (0)+const) ) when 6-round of AES is used.

IV. HARDWARE IMPLEMENTATION

In this section we describe the implementation of ELmD and compare it with COPA, EME2 (standardized for disk encryption [START_REF]IEEE standard for wide-block encryption for shared storage media[END_REF]) which are algorithms with similar structure as ELmD and the standard for Authenticated Encryption with Associated Data GCM.

A. Design Decisions

Our implementation was realized to exploit the main features of ELmD. Below we list the design decisions:

1) Pipeline Implementation: ELmD is optimized for pipelined implementations, so we present a pipelined implementation of it. The size of data path is 128bit same as block size of AES. Our implementation is suitable for bulk on-line authenticated encryption when the amount of data is huge. Two versions of ELmD were implemented one with ten rounds of AES in each layer denoted as ELmD and other with only six rounds per layer denoted as ELmD(6, 6). 2) AES-cores: We use one AES-encryption core and one AES-decryption core. These cores were implemented in pipeline following the strategy in [START_REF] Chakraborty | Efficient hardware implementations of BRW polynomials and tweakable enciphering schemes[END_REF], it is an optimization of AES implementation for modern families of FPGAs with 6-inputs LUTs. Both encryption and decryption cores have ten pipeline stages, one per round as we are using 128-bit key. Only one key scheduling was implemented and it is shared between both cores. We add an additional pipeline stage for the multiplexer and necessary operations at the input of AES cores, in order to keep the frequency. So the initial latency for these cores is 11 clock cycles when the numbers of rounds is 10 and 7 clock cycles for 6 rounds. 3) Multiplications: ELmD needs many multiplications of a 128-bit string by a small constant such as 2, 3, 7, we implement dedicated multipliers for each of them. This multipliers are really simples, just some shifts (implement as wires) and some ⊕'s. The field GF (2 128 ) is defined using the irreducible polynomial P (x) =

x 128 + x 7 + x 2 + x + 1.

B. Proposed Architecture

In the Figure 3 we show the proposed architecture for ELmD. The main components are AES-Enc and AES-Dec cores, they represent almost the 90% of the total area for this design. Register L store the value L = E K (0). All the components represented using rectangle with round corners contains dedicated multipliers, ones labeled as x7, x3 and x3 2 multiply their input by 7, by 3 and by 3 2 respectively. The two components x2 i are used to generate masking values such as L, 2L, 4L, ..., internally they have a feedback to multiply each clock cycle the previous value by 2.

Block labeled with ρ computes the linear mixing function and its inverse. Mux4 provides the input to the block x i L-1, this generates mask values, the input can be 3L for associated, L data for encryption and 3 2 L for decryption. Using mux3 and mux4 AES-Enc receives the input, mux3 selects between associated data D i and message blocks M i to process them or checksum to compute the tag T . Mux1 selects input of AES-Enc between the masked value, masked value (mask multiplied by 7) when the block is incomplete or 0 128 to compute L. Mux2 is in charge to provide the input to AES-dec, it selects the output of ρ xored with 1 in the last block cipher call which computes the tag, in others cases the input of AES-Dec is the output of ρ. Mux5 is used to feed the block x i L-2, the input can be 3 2 L for encryption and L for decryption.

Computation of the tag is in similar fashion as cipher text generation, just mux2 selects the ⊕ between the output of ρ and 1. For verification the tag T is fed after cipher text, then a checksum of the decrypted message is computed and compared with the output AES-dec.

Block chksum computes and stores the plaintext checksum while block checksumD do the same with the message decrypted. Verification is just a 128-bit comparator.

The Control Unit provides all the necessary control signals to the components of the architecture, it is a finite state machine that follows the corresponding algorithms for tagged encryption and verified decryption.

ELmD [START_REF]Cryptographic Hardware and Embedded Systems -CHES 2014 -16th International Workshop[END_REF][START_REF]Cryptographic Hardware and Embedded Systems -CHES 2014 -16th International Workshop[END_REF]: Its implementation is very similar to the architecture for ELmD the only different is that there is an additional input in Mux1 in order to compute L = E K (E K (0)), this additional input represents a feedback of AES-Enc core. In this case AES-Enc and AES-Dec cores contain only six rounds.

C. Timing analysis

Using the notation in Specification of ELmD we represent in the diagram of Figure 5 how the operations are computed in the time for our architecture. First of all L is computed as L = E K (0 n ), this takes 11 clock cycles. Then the processing of the associated data starts (Z i ) and the block cipher encryption layer for message (X i ), using these values function ρ is computed and fed to the block cipher decryption layer and after 12 (11 from latency of the AES-dec core, 1 for the masking) clock cycles we can get a valid ciphertext in the output of the architecture. So the latency including the reset is computed as where d is the number of 128-bit block of associated data. Latency has to be understood as the number of clock cycles taken to output the first block of ciphertext. ELmD [START_REF]Cryptographic Hardware and Embedded Systems -CHES 2014 -16th International Workshop[END_REF][START_REF]Cryptographic Hardware and Embedded Systems -CHES 2014 -16th International Workshop[END_REF]: The time diagram for it is shown in Fig. 5, in this case the latency for AES-enc and AES-dec is 7 clock cycles. The computation of L takes 14 because it implies two calls to AES-Enc. The latency to is 30 + d taking into account the reset and synchronization of the output.

Latency = 35 + d
Before to analyze the results we give an overview of the implementation of COPA and OCB3.

Implementation of COPA:

We implemented COPA to compare it with ELmD. We follow the same design decisions, we use two AES-enc cores and two AES-dec cores. The rest of the operations are like in ELmD mainly multiplications by Fig. 5. Time diagram for ELmD [START_REF]Cryptographic Hardware and Embedded Systems -CHES 2014 -16th International Workshop[END_REF][START_REF]Cryptographic Hardware and Embedded Systems -CHES 2014 -16th International Workshop[END_REF] small constants. The architecture for COPA is shown in Figure 6.

Implementation of OCB: As for COPA we follow the same design decisions. In the case of OCB3 masking values are computed in a different way, it needs to do some precomputations of x i L values and store them, hence OCB3 uses additional RAM memories (Block memories in FPGAs). Masking is generated using the number of trailing zeros so and special module was designed to compute them. OCB3 is optimized to save one block cipher call when a counter is used as nonce but it needs some clock cycles for the set up process, it is denoted as Setup, this process is execute only one time for some messages (if only if the nonce is a counter). The way to compute the initial value for masking is using a shift register, this function depends of the first six bits of the nonce, so the time taken by it is variable, we identify this function as Stretch. For more details of OCB consult [START_REF] Krovetz | The software performance of authenticated-encryption modes[END_REF].

D. Results and Comparisons

In the Table I we show the results obtained after place and route using Xilinx ISE 13.4 and Virtex-6 (xc6vlx240t-2-ff1759) as a target device. Each Virtex-6 slice contains four 6-input-LUTs and eight flip flops (Virtex-5 slices used in [START_REF] Karim | Fpgabased high performance AES-GCM using efficient karatsuba ofman algorithm[END_REF] contain only four flip flops).

Our results show that the optimizations for area in ELmD design really save physical resources in comparison with COPA, basically the decision to use the second ECB layer always in decryption mode. Due to the fact that the changes between encryption and decryption algorithms of ELmD are really minimum and the block ciphers are always instantiated in the same mode, the first one is always encryption and the second is always decryption. For COPA the changes between encryption and decryption include also the block ciphers, when COPA is instantiated in decryption mode both block ciphers in the architecture have to be changed to decryption mode. This fact implies that while ELmD needs only one encryption core and one decryption core, COPA needs two of each one. So the logic resources used byt ELmD represents 50.28 % of the used by COPA.

Also the initial latency is less in ELmD, COPA needs 1.74 times more clock cycles to process the associated data in PMAC1 fashion since the computation of the last block needs to wait for all the encryptions of previous blocks.

The critical path for both designs is defined by AES-dec core which is significantly slower than AES-Enc core. About the throughput is almost the same for both since when the amount of data is huge the initial latency can be neglected, the throughput for ELmD is 30.03 Gbs while for COPA is 29.55 Gbs. So the real advantage of ELmD is that it offers a bit more throughput than COPA using half of the area.

In comparison with a similar implementation of GCM implemented in Virtex 5 FPGA, the difference in area between ELmD and GCM is almos 500 slices, GCM uses only one block cipher core and one 128-bit Karatsuba Ofman multiplier. In terms of area is much more expensive one AES-Dec core than a multiplier [START_REF] Chakraborty | Efficient hardware implementations of BRW polynomials and tweakable enciphering schemes[END_REF], this justify the difference in area. The speed for GCM is mainly defined by the critical path of AES-Enc core that's why GCM is faster than ELmD and COPA. Throughput is better for GCM but the security offers by ELmD and COPA is stronger than GCM security, ELmD and COPA can be used in nonce-misuse scenario as well where GCM is secure only in the nonce respecting mode. Finally the degradation in performance (not much) of ELmD and COPA in comparison with GCM can be compensated with the gains in security, since ELmD and COPA can be used in noncemisuse scenario as well where GCM is secure only in the nonce respecting mode.

Comparing with EME2 [START_REF] Chakraborty | Disk encryption: Do we need to preserve length?[END_REF] the design is more similar to COPA, they used the block cipher in the same mode (encryption or decryption) in two ECB layers, so the area for both are similar. The case of ELmD again the decision of used the two ECB layer in different mode, represent a good optimization against EME2. It is important to pointed out that EME2 needs intermediate storage, as large as the size of the input message since the masking between the two ECB layers depends of all the blocks in it. So EME2 can be implemented using only one AES-enc core and one AES-dec, since in EME2 both ECB layers are sequential in the sense that the second can be started only when the fist one has been finished. For ELmD and COPA it is possible to compute both ECB layers in a kind of pipeline using the output of the first as the input of the second, this is a characteristic of on-line modes of operation. We compared our implementations with EME2 only because the similarity of their structure but in fact the objective of EME2 is to provide a length-preserving strong pseudo random permutation suitable for disk encryption.

OCB3 uses almost the same amount of resources as ELmD, because they need one AES-enc and one AES-dec core. OCB3 require four block rams to store the precomputed values of x i L, in this case we store 31 values. ELmD(6, 6) is much more small in terms of area due to the reduction in the number of AES rounds, so if security is comparable it would be a better option. Also is important to remember that OCB3 is secure only in the nonce respecting mode like GCM.

V. CONCLUSION AND FUTURE WORKS. In this paper, we provide the hardware implementation of ELmD and ELmD [START_REF]Cryptographic Hardware and Embedded Systems -CHES 2014 -16th International Workshop[END_REF][START_REF]Cryptographic Hardware and Embedded Systems -CHES 2014 -16th International Workshop[END_REF] and compare it's performance with other existing constructions, with similar structure. As future work we can explore more range of parallelism for ELmD and try to achieve the requirements for the Ethernet standard IEEE 802.3ba, this specify a throughput of 100 Gbps [START_REF] Muehlberghuber | 100 gbit/s authenticated encryption based on quantum key distribution[END_REF]. This can be achieved using more AES-enc and AES-dec cores in parallel, each of them process different parts of the message.

Fig. 1 .

 1 Fig. 1. Processing of Associated data in ELmD Authenticated Encryption : For complete final data block

  INCORPORATING INCOMPLETE FINAL BLOCK. If the final associated data block (D[d]) is incomplete, then we make it complete by 10 * masking: D[d] = D[d] || 10 * . The generation DD[0], • • • , DD[d -1] is identical as above but we modify generation of DD[d] as follows (to distinguish from complete block associated data): DD[d] = D[d] ⊕ 3 • 7 • 2 d-1 • L.

Fig. 2 .

 2 Fig. 2. ELmD Authenticated Encryption : For complete final block

Fig. 3 .

 3 Fig. 3. Proposed architecture for ELmD.

Fig. 4 .

 4 Fig. 4. Time diagram for ELmD. To get the real latency for C i , two more clock cycles have to be added, one for the reset and other for final synchronization given a total time of 35 + d + l clock cycles. An additional clock cycle is used to give the tag T.

Fig. 6 .

 6 Fig. 6. Proposed architecture for COPA.

TABLE I PERFORMANCE

 I OF ELMD AND COPA . AREA AND FREQUENCY FOR AES CORES ARE SHOWN IN THE BOTTOM PART. d IS THE NUMBERS OF 128-BIT BLOCKS OF ASSOCIATED DATA.

	Mode		Area		Frequency	Lantency	Throughput
		Slices	LUTs	Flip Flops	(MHz)	clock cycles	Gbps
	ELmD	5225	16967	5578	234.64	35 + d	30.03
	COPA	10391	32845	8336	230.87	61 + d	29.55
	AES-GCM [4]	4770	-	-	311	-	36.92
	Virtex 5
	ELmD(6,6)	3150	10783	4018	238.68	30 + d	30.55
	OCB3	5180	16879	5846	234.87	11 + d + Setup + Stretch	30.06
	EME2[9]	10970	33350	9931	230.56	-	24.77
	AES-10 pipelined	2023	7301	2824	315.16	1	38.47
	encryption
	AES-10 pipelined	2360	9020	2693	239.34	1	30.63
	decryption
	AES-6 pipelined	1635	4523	2329	315.16	1	38.47
	encryption
	AES-6 pipelined	1639	5353	2400	239.34	1	30.63
	decryption