Jonas H Osório
email: jhosorio@ifi.unicamp.br

Thiago D Cabral

Eric Fujiwara

Marcos A R Franco

Foued Amrani

Frédéric Delahaye

Frédéric Gérôme

Fetah Benabid

Cristiano M B Cordeiro

Displacement sensor based on a large-core hollow fiber and specklegram analysis

Keywords:

The research enterprise towards achieving high-performance hollow-core photonic crystal fibers has led to impressive advancements in the latest years. Indeed, using this family of fibers becomes nowadays an overarching strategy for building a multitude of optical systems ranging from beam delivery devices to optical sources and sensors. In most applications, an effective single-mode operation is desired and, as such, the fiber microstructure or the light launching setups are typically designed for achieving such a behavior. Alternatively, one can identify the use of large-core multimode hollow-core fibers as a promising avenue for the development of new photonic devices. Thus, in this manuscript, we propose and demonstrate the utilization of a large-core tubular-lattice fiber for accomplishing a speckle-based displacement sensor, which has been built up by inserting and suitably dislocating a single-mode fiber inside the void core of the hollow fiber. The work reported herein encompasses both simulation and experimental studies on the evolution of the multimode intensity distributions within the device as well as the demonstration of a displacement sensor with an estimated resolution of 0.7 μm.

We understand that this investigation identifies a new opportunity for the employment of large-core hollow fibers within the sensing framework hence widening the gamut of applications of this family of fibers.

Introduction

The recent endeavors by the hollow-core photonic crystal fiber (HCPCF) community have entailed noteworthy advancement and led to several breakthroughs in the performance of this family of optical fibers. Indeed, the current state-of-the-art HCPCFs stand out as the lowest loss fiber optics in the visible and ultraviolet ranges [START_REF] Osório | Hollow-core fibers with reduced surface roughness and ultralow loss in the shortwavelength range[END_REF], with attenuation figures remarkably lower than silica-core fibers, and their loss in the infrared range approaches the values corresponding to their solid-core counterparts [START_REF] Jasion | 0.174 dB/km hollow core double nested antiresonant nodeless fiber (DNANF)[END_REF]. Such a scenario grants a bright framework for HCPCF applications, which encompasses the development of optical sources [START_REF] Aghbolagh | Mid IR hollow core fiber gas laser emitting at 4.6 μm[END_REF][START_REF] Chafer | Near-and middleultraviolet reconfigurable Raman source using a record-low UV/visible transmission loss inhibited-coupling hollow-core fiber[END_REF], sensors [START_REF] Zhao | Modephase-difference photothermal spectroscopy for gas detection with an antiresonant hollow-core optical fiber[END_REF][START_REF] Miele | Hollow-core optical fibre sensors for operando Raman spectroscopy investigation in Li-ion battery liquid electrolytes[END_REF][START_REF] Guimarães | Angle-resolved hollow-core fiber curvature sensing approach[END_REF], and, more recently, power-over-fiber (PoF) platforms [START_REF] Osório | Hollow-core photonic crystal fibers for Power-over-Fiber systems[END_REF].

In most typical HCPCF applications, the fibers and the corresponding experimental setups are designed so that the transmission and delivery of light occur in an effective single-mode fashion. Strictly speaking, the ubiquitous presence of higher-order modes (HOM) in HCPCFs' modal content forbids these waveguides from displaying a true single-mode behavior. However, HCPCFs can be designed so that their microstructure can filter out selected families of HOMs that might be present in the fibers' modal content, hence allowing the development of fibers with very high HOM extinction ratios and capable of exhibiting effective single-mode operation from a practical outlook [START_REF] Uebel | Broadband robustly single-mode hollow-core PCF by resonant filtering of higher-order modes[END_REF][START_REF] Amrani | Low-loss single-mode hybrid-lattice hollow-core photoniccrystal fibre[END_REF]. Alternatively, HCPCFs can be designed to provide increased leakage of the core fundamental mode while keeping low loss for selected HOMs, which allows, for example, to attain fibers that favor the propagation of HOMs to the detriment of the core fundamental mode [START_REF] Osório | Tailoring modal properties of inhibited-coupling guiding fibers by cladding modification[END_REF].

In turn, large-core HCPCFs (herein referring to fibers with core diameters larger than 100 μm) emerge as great platforms for high-power beam handling [START_REF] Debord | Ultra-large core size hypocycloid-shape inhibited coupling kagome fibers for high-energy laser beam handling[END_REF] and plasma photonics applications [START_REF] Debord | Generation and confinement of microwave gas-plasma in photonic dielectric microstructure[END_REF][START_REF] Amrani | Gas mixture for deep-UV plasma emission in a hollow-core photonic crystal fiber[END_REF]. Habitually, in beam delivery applications, once again single-mode operation is typically preferred, and the multimode characteristics of the fiber are circumvented by designing a suitable light launching setup able to entail a fundamental mode-dominated modal content. In plasma photonics applications, large-core HCPCFs are used for facilitating the ignition of microwave plasmas, which enables the emission of visible and ultraviolet light and the development of HCPCF-based fluorescent light sources [START_REF] Debord | Generation and confinement of microwave gas-plasma in photonic dielectric microstructure[END_REF][START_REF] Amrani | Gas mixture for deep-UV plasma emission in a hollow-core photonic crystal fiber[END_REF].

In the above-mentioned large-core HCPCF applications, therefore, the multimode characteristics of the fibers are either avoided or not fully explored. Delving into the multimode characteristics of large-core HCPCFs, on the other hand, has the potential of unfolding a set of exciting application possibilities from nonlinear optics to sensing. Still, investigations on the use of the multimode behavior of large-core HCPCFs are somehow scarce in the literature, mostly represented by a small collection of theoretical and fiber fabrication reports [START_REF] Winter | Multimode hollow-core anti-resonant optical fibres[END_REF][START_REF] Goel | Multimode nested antiresonant hollow core fiber[END_REF][START_REF] Markos | Multi-mode guidance in enhanced inhibited coupling hollow-core antiresonant fibers Conference on Lasers and Electro-Optics paper[END_REF][START_REF] Shere | Understanding the impact of cladding modes in multi-mode hollow-core anti-resonant fibres[END_REF].

In this context, we here propose and demonstrate a new application of large-core HCPCFs within the sensing framework. Here, by exploring the speckled output intensity profile of a 140 μm-core diameter singlering tubular-lattice (SR-TL) HCPCF, we were able to demonstrate a displacement sensor displaying a 0.7 μm resolution. The sensing platform is built by inserting a solid-core single-mode fiber (SMF) inside the void center of the HCPCF and by assessing the speckled output profile of the latter while dislocating the SMF inside of it. In addition to the sensing results, we provide simulations and an experimental characterization of the evolution of the speckle profile along the HCPCF, as well as identify the salient features of the resulting intensity profiles. We believe that our work, by proposing and demonstrating a new application avenue for large-core HCPCFs, expands the range of HCPCF application possibilities and, especially, identifies a promising route for the exploration of the multimode behavior of HCPCFs within the sensing area.

Exploring the speckled output profile of a large-core SR-TL HCPCF

This paper investigates a displacement sensor based on the analysis of the speckled output of a large-core SR-TL HCPCF. Speckle patterns (specklegrams) appear from the interference of several modes in a multimode fiber (MMF) when excited by a coherent source. The spatial distribution of light speckles depends on parameters such as the fiber's numerical aperture and the laser wavelength. In turn, disturbances imposed by physical and chemical stimuli can modulate the output speckle profile through mode coupling and phase deviation effects [START_REF] Kajenski | Mode coupling and phase modulation in vibrating waveguides[END_REF]. Although such intensity fluctuations are undesirable in typical optical systems, the specklegrams retain detailed information on the optical fields traveling through the fiber [START_REF] Plöschner | Seeing through chaos in multimode fibers[END_REF]. Therefore, one may analyze the subtle changes in the speckle output images to retrieve the characteristics of a measured variable [START_REF] Yu | Submicrometer displacement sensing using inner-product multimode fiber speckle fields[END_REF].

Thus, fiber specklegram sensors (FSS) feature as feasible alternatives to the widespread intensity and FBG-based fiber sensors. Besides their high sensitivity and distributed measurement capability, FSS require a straightforward setup typically comprising a visible laser and camera instead of expensive spectrometers and optical interrogators [START_REF] Yu | Submicrometer displacement sensing using inner-product multimode fiber speckle fields[END_REF][START_REF] Rodriguez-Cobo | Fiber specklegram-multiplexed sensor[END_REF]. Typical FSS exploit the speckle patterns generated by conventional silica and polymer MMFs, which enables the assessment of strain [START_REF] Murray | Speckle-based strain sensing in multimode fiber[END_REF], pressure [START_REF] Bennett | Monitoring of vital bio-signs by analysis of speckle patterns in a fabricintegrated multimode optical fiber sensor[END_REF], temperature [START_REF] Garcia-Ruiz | Speckle analysis method for distributed detection of temperature gradients with ФOTDR[END_REF], and refractive index [START_REF] Fujiwara | Optical fiber specklegram chemical sensor based on a concatenated multimode fiber structure[END_REF] variations. Additionally, specialty fibers with holey structures provide further perspectives for modulating the output specklegram. Examples comprise exposed-core multimode fibers for temperature and chemical measurements [START_REF] Cabral | Multimode exposed core fiber specklegram sensor[END_REF][START_REF] Smith | Machine learning for sensing with a multimode exposed core fiber specklegram sensor[END_REF], and a biodegradable structured fiber made of agar suitable for biochemical and environmental assessments [START_REF] Fujiwara | Agarose-based structured optical fibre[END_REF]. To our knowledge, however, the speckled output profile of large-core SR-TL HCPCFs has not been explored for sensing purposes previously.

We start our analyses by presenting simulation results on the evolution of the speckle intensity profile in a large-core HCPCF. In the experiments to be described in the following, light is launched in the HCPCF by using a SMF placed inside the HCPCF. Thus, here we approach the realization of numerical simulations (based on the beam propagation method) using the BeamPROP software (RSoft Design) to study the evolution of the optical fields emanating from the SMF until a speckled intensity distribution is established in the HCPCF. Fig. 1a shows a diagram of the 12-tube SR-TL HCPCF we study herein. Its structure comprises a set of untouching 12 tubes that defines the fiber hollow core. In the simulations, we assume that the diameters of the fiber core and cladding tubes are D core = 140 μm and D tubes = 35 μm, respectively. The thickness of the cladding tubes has been set as t = 680 nm.

Fig. 1b presents a lateral view of the numerical setup we employ in our analysis. A SMF with a 4 μm core diameter launches a Gaussian beam (at the wavelength of 543 nm) in the HCPCF core, as represented by the green shadowed region in Fig. 1b. Such a numerical configuration allows assessing the intensity profiles on the HCPCF cross-section at selected positions along the fiber axis (vertical dashed lines along the zaxis) and, hence, study the dynamics of the formation of the speckled intensity distributions in the core of the HCPCF. Fig. 2 displays the simulated normalized intensity distributions (normalization taken at every image, assuming as unit its maximum intensity value) in the HCPCF core at selected positions along the z-axis. Here, we define z = 0 as the position of the SMF end-face, as represented in Fig. 1b. By observing the images in Fig. 2, one sees that the modefield-diameter of the Gaussian beam emanating from the SMF enlarges as it propagates inside the HCPCF (see the images corresponding to z = 100 μm, z = 200 μm, and z = 300 μm). Additionally, one observes that, as the beam propagates, coupling to several HOMs in the hollow core occurs and, as a result, a spatial distribution stemming from the interference of the latter is developed. After hundreds of micrometerspropagation length, a speckle intensity distribution is established in the HCPCF cross-section (see the image corresponding to z = 700 μm and the consecutive ones). As one will discuss in the following, evaluation of the correlation between the speckle profiles for different propagation distances allowed us to demonstrate the system depicted in Fig. 3a shows the cross-section of the SR-TL HCPCF we used in our experiments, which has been fabricated by following a typical stackand-draw procedure. The fiber displays the same values of D core , D tubes, and t as in the simulations. Fig. 3b presents the transmission spectrum of such a fiber, taken for a 4 m-long fiber piece. To account for the spectrum shown in Fig. 3b, light from a supercontinuum source has been coupled to the core of the HCPCF, and the transmitted power has been measured by an optical spectrum analyzer. Fig. 3b readily shows that the wavelength used in our characterization and sensing experiments, 543 nm, lies within the fiber second-order transmission band. The wavelength of 543 nm has been identified as a vertical dashed line in Fig. 3b.

To experimentally characterize the formation of the speckle intensity profile at the HCPCF output, we designed an experiment as represented in Fig. 4. By suitably using the alignment mirrors M1 and M2, and the coupling objective lens L1, light from a laser source emitting at 543 nm has been coupled to a commercial fiber displaying single-mode operation in the visible range (Newport F-SA, 125 μm outer diameter), which, in turn, had been previously and carefully inserted in the core of the HCPCF with a length of 5 cm. The SMF has been, in sequence, attached to a motorized stage (step resolution of 0.1 μm) so it could be displaced inside the HCPCF. We remark that to avoid damage to the SMF tip, we inserted the SMF into the HCPCF until it left the HCPCF end-face by a few millimeters. We sequentially cleaved the SMF and dragged it back into the HCPCF up to the desired position by using our motorized translation stage.

At the output of the HCPCF, one placed an objective lens (L2) for collimating the fiber output beam and projecting it onto a DSLR camera (Sony Alpha 100 DSLR). We remark that we removed the DSLR camera lens so that the output beam could directly impinge on the camera sensor. In the experiments, differently from the simulations, we redefined z = 0 at the output of the HCPCF and changed the orientation of the z-axis, as illustrated in Fig. 4. Such an alteration of the z = 0 definition and axis orientation with respect to the simulations allows us to directly correlate the simulated and measured output intensity distributions, as the comparisons rely on the propagation lengths of the Fig. 2. Simulated evolution of the intensity distribution profile on the HCPCF cross-section along the z-axis at 543 nm. The color bar stands for the normalized intensity calculated for every image. Here, we define z = 0 as the position of the SMF extremity, as depicted in Fig. 1b. Thus, with the aid of the motorized stage, the SMF could be controllably drawn from the HCPCF starting from the newly defined z = 0 position (HCPCF output end face, see Fig. 4). The initial positioning of the SMF has been set by the following procedure: initially, one tuned the focal plane of the objective lens L2 to be at the HCPCF end face (by taking the illuminated HCPCF core contour as a reference); sequentially, while keeping L2 fixed, one suitably moved the SMF inside the HCPCF by using the motorized stage up to the point that the SMF also reached the focal plane of L2; this allowed us to assume that both the SMF and HCPCF extremities were at the same plane and set this position as z = 0. While drawing the SMF from the HCPCF, images of the beam emerging from the HCPCF could be captured by using the DSLR camera at each translation step. It allowed us to qualitatively reproduce the simulated images shown in Fig. 2, as one will see in the following. Fig. 5 presents the images captured by the DSLR camera at representative positions of the SMF output along the z-axis (a schematic of the cladding tubes has been superposed to the images for eye guidance). As in Fig. 2, we observe the enlargement of the mode-field-diameter of the Gaussian beam emanating from the SMF as it propagates inside the HCPCF (as one can observe in the images corresponding to z = 100 μm, z = 200 μm, and z = 300 μm). Additionally, and consistently with the simulations shown in Fig. 2, one sees that coupling to HOMs in the HCPCF takes place after hundreds of micrometers of propagation length and that a multimode intensity distribution is attained in the hollow core. One notices that the intensity distributions in the images shown in Fig. 5, especially for the images corresponding to z ≤ 500 μm, are slightly shifted from the HCPCF geometrical center. While it is likely to be due to misalignment of the SMF inside the HCPCF, as the inner diameter of the HCPCF core (140 μm) is slightly greater than the outer diameter of the SMF (125 μm), it does not prevent us to conclude that our simulations and experiments are qualitatively consistent and, hence, that we could characterize the evolution of the gaussian beam emanating from the SMF up to the establishment of a multimode intensity profile in the HCPCF. In fact, we mention that we performed additional simulations for considering the effects of the lateral offsetting and tilting of the SMF inside the HCPCF and concluded that both can cause the intensity distributions to spatially shift from the HCPCF geometrical center (additional information can be found in the Supplemental Material). Also, we comment that such misalignment effects Fig. 4. Diagram of the experimental setup for characterization and sensing measurements. The SMF (in blue) is carefully inserted in the HCPCF void core and displaced towards + z direction during the measurements. M1 and M2: alignment mirrors. L1 and L2: objective lenses. The DSLR camera has been used in the characterization experiments (results shown in Fig. 5). In the displacement sensing measurements, alternatively, a low-cost commercial lensless webcam has been employed. (For interpretation of the references to color in this figure legend, the reader is referred to the web version of this article.) Fig. 5. Experimental observation of the evolution of the intensity distribution profile at 543 nm on the HCPCF cross-section as a function of the position of the SMF inside of it. The images have been taken by using a DSLR camera, as depicted in Fig. 4. The tubes' location on the fiber cross-section have been superposed to the captured images for eye guidance.

are not critical to our sensing setup, whose response has been characterized when the multimode intensity distribution was well developed inside the HCPCF, as we will describe in the following.

Fiber specklegram analysis and displacement sensing

The intensity distribution of an output speckle pattern I(x, y) projected on the xy-plane can be described by Eq. (1):

I(x, y) = ∑ M m=1 ∑ M n=1 a m a n exp[i(ϕ m -ϕ n ) ] (1)
where M is the number of modes, a(x, y) and ϕ(x, y) are the amplitude and phase distributions of the optical modes, and the subscripts denote the m-th and n-th fiber modes [START_REF] Yu | Submicrometer displacement sensing using inner-product multimode fiber speckle fields[END_REF]. Let I 0 (x, y) be the specklegram for the initial fiber state. Disturbances introduced by fiber bending, temperature changes, laser power fluctuations, and deviations in the launching conditions modulate the speckle pattern and result in another state I contrasting to I 0 . The zero-mean normalized cross-correlation (ZNCC) metric quantifies the differences between I and I 0 according to Eq. ( 2) [START_REF] Fujiwara | Evaluation of image matching techniques for optical fiber specklegram sensor analysis[END_REF]:

Z = ∫∫ (I -I)(I 0 -I 0 )dxdy [∫∫ (I -I) 2 dxdy ∫∫ (I 0 -I 0 ) 2 dxdy ] 1/2 (2)
where 0 ≤ Z ≤ 1 is the ZNCC coefficient and the overlines indicate the average values of I and I 0 . Therefore, one sees that Z = 1 identifies the situation in which the fiber state matches the reference condition (I = I 0 ) and that the Z value decreases as I departs from I 0 . Despite being sensitive and intrinsically robust to illumination changes, the ZNCC exhibits an impaired measurement range due to its saturation. Thus, one may compute the extended ZNCC (EZNCC) to overcome such limitation according to Eq. ( 3) [START_REF] Fujiwara | Polymer optical fiber specklegram strain sensor with extended dynamic range[END_REF]:

EZ = EZ 0 -[Z(I, I 0 , τ) -1 ] (3)
where EZ is the EZNCC coefficient, EZ 0 is a reference value, Z is the ZNCC between I and I 0 , and τ = 0.7 is an empiric threshold parameter.

The algorithm starts with EZ 0 = 1, i.e., EZ = 1 for the undisturbed condition (I = I 0 , Z = 1). The evaluation hence proceeds by decreasing EZ until Z reaches τ. This condition resets the reference I 0 to the current specklegram I and makes EZ 0 = EZ, preventing its saturation. Consequently, the EZNCC exhibits linear response for a virtually unlimited dynamic range [START_REF] Fujiwara | Polymer optical fiber specklegram strain sensor with extended dynamic range[END_REF]. Thus, here we have chosen the EZNCC as the metric for analyzing our sensing data. Additionally, we mention that, as the EZNCC metric operates on consecutive images disregarding the fiber geometry and, since it resets the reference image whenever the acquired speckle pattern crosses the threshold, it is also appropriate for providing a linear and non-saturating response in other speckle-based sensing configurations relying on different fiber designs.

By following the methods described above, and by using the setup depicted in Fig. 4, we could hence attain displacement sensing measurements via the assessment of the correlation values as a function of the position of the SMF inside the HCPCF. We remark that, during the displacement sensing measurements, the DSLR camera has been replaced by a low-cost commercial lensless webcam (800 × 600 pixels). Using a webcam instead of a DSLR camera allows us to attain a costeffective sensing platform and readily recover and analyze the recorded images with a computer using MATLAB (Mathworks) routines.

The sensing results are shown in Fig. 6, where the EZNCC values have been plotted as a function of the displacement of the SMF inside the HCPCF. We mention that, in the sensing measurements, the initial position of the SMF has been set to be 3 mm apart from the HCPCF extremity and that the SMF movement has been directed towards the positive direction of the z-axis (see Fig. 4). Such a choice of the departure position of the SMF in the sensing measurements considered that, according to our observations, it was the one at which the speckled profile at the HCPCF output was reasonably developed and adequate for sensing purposes. The insets in Fig. 6a show the experimental and simulated intensity distributions for z = 3 mm. Fig. 6a shows the results of the displacement sensing test taken for a measurement range of 200 μm. Each data point summarizes the average of 70 specklegram images and considers twice the standard deviation of the mean (2σ) as their error baras the 2σ value amounts to 0.03 at maximum, the error bars are not visible in the plots in Fig. 6. Observation of the data allows identifying a linear trend between the EZNCC and displacement values. Thus, by linear-fitting the data, we could estimate the device sensitivity as 14.27 ± 0.07 mm -1 (R 2 = 0.9996). To demonstrate that our sensing setup can have an extended measurement range, we performed additional measurements for displacements between 500 μm and 700 μm, 1000 μm and 1200 μm, and 1500 μm and 1700 μm. The results are shown in Fig. 6b, where one can observe that the linear behavior of the EZNCC as a function of the displacement is maintained. For the extended-range measurement shown in Fig. 6b, a sensitivity of 13.47 ± 0.02 mm -1 (R 2 = 0.9997) has been calculated. Additionally, given the maximum random uncertainty of 0.01 (in EZNCC units), one can estimate the system resolution as ΔEZ/Δz = 0.01/13.47 ≈ 0.7 μm. Such a resolution figure compares well with the ones estimated in other fiber optics platforms as fiber Bragg gratings and multicore fiber-based displacement sensors [START_REF] Li | A novel fiber Bragg grating displacement sensor with a submicrometer resolution[END_REF][START_REF] Alonso-Murias | Long-range multicore optical fiber displacement sensor[END_REF]. Furthermore, the EZNCC algorithm enlarges the measurement range beyond typical fiber speckle-based strain and displacement meters [START_REF] Murray | Speckle-based strain sensing in multimode fiber[END_REF][START_REF] Chen | Precision non-contact displacement sensor based on the near-field characteristics of fiber specklegrams[END_REF] by preserving its intrinsic high-sensitivity feature.

We indicate that our system, being based on a low-cost webcam accessed through a MATLAB routine, achieved a 15-fps sampling rate. We signal, however, that the sensing measurements reported herein, which have been performed by averaging speckle pattern images under steady-state conditions, did not rely on the system sampling rate. Also, we mention that future investigations may encompass the study of the impact of the laser wavelength and SMF misalignment on the system sensitivity and resolution. We clarify, however, that the measurement range is not expected to depend on the latter parameters, as the EZNCC metric automatically resets the reference condition whenever the correlation drops below the threshold, ensuring a continuous response over the full-scale range.

Finally, we consider that the platform we reported in this paper can disclose a set of other speckle-based sensing applications using largecore HCPCFs. Further studies could encompass, for example, the investigation of the temperature sensitivity of the devices since the lower thermo-optic coefficient of air compared to silica can entail lessened temperature cross-sensitivity and, thus, be beneficial to practical devices. Furthermore, we consider that our approach could be potentially useful in applications using liquid-filled HCPCFs, hence providing interesting avenues for chemical and biological sensing.

Conclusions

In this manuscript, we proposed and demonstrated a novel sensing application using a large-core HCPCF. Thus, by assessing the speckled output intensity distribution of a 140 μm-core diameter SR-TL HCPCF, we could demonstrate a displacement sensor displaying a 0.7 μm resolution. The sensing platform reported herein has been built by introducing a solid-core SMF in the void center of the HCPCF and evaluating the speckled output profile of the HCPCF while moving the SMF inside of it. Additionally, we provided simulations and an experimental characterization of the evolution of the intensity distributions inside the HCPCF starting from the Gaussian beam emanating from the SMF up to the establishment of the multimode intensity distribution in the HCPCF. We consider that our work, by proposing and demonstrating a new application of large-core HCPCFs, enlarges the range of HCPCF application opportunities and, particularly, discloses a promising path for the study of the multimode behavior of HCPCFs in sensing.

Fig. 1 .

 1 Fig. 1. (a) Diagram of the 12-tube SR-TL HCPCF; D core : diameter of the core; D tube : diameter of the cladding tubes. (b) Lateral view of the numerical setup. A SMF launches a gaussian beam in the core of the HCPCF (green shadowed region) and the intensity distributions on the HCPCF cross-section are assessed at selected positions along the fiber axis (vertical dashed lines along the z-axis). (For interpretation of the references to color in this figure legend, the reader is referred to the web version of this article.)

Fig. 3 .

 3 Fig. 3. (a) Cross-section of the 12-tube SR-TL HCPCF. (b) Transmission spectrum for a 4 m-long fiber. The vertical dashed line identifies the wavelength at which the experiments have been performed, 543 nm.

Fig. 6 .

 6 Fig. 6. Displacement sensing results. Plots of the EZNCC values as a function of the SMF displacement inside the HCPCF for a measurement range of (a) 200 μm and for an extended range of (b) 1.7 mm. The extended range of 1.7 mm consists of several displacements between 500 μm and 700 μm, 1000 μm and 1200 μm, and 1500 μm and 1700 μm. Inset images stand for simulated and measured intensity distribution profiles at z = 3 mm.

Acknowledgments

The authors acknowledge Fundação de Amparo à Pesquisa do Estado de São Paulo (FAPESP, grants 2021/13097-9 and 2017/25666-2), Conselho Nacional de Desenvolvimento Científico e Tecnológico (grants 403418/2021-6, 310650/2020-8 and 309989/2021-3).

Data availability

Data will be made available on request.

Declaration of Competing Interest

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

Appendix A. Supplementary data

Supplementary data to this article can be found online at https://doi. org/10.1016/j.yofte.2023.103335.


Romain Laborde
email: laborde@irit.fr

François Barrère
email: barrere@irit.fr

Abdelmalek Benzekri
email: benzekri@irit.fr

Toward Authorization as a Service A study of the XACML standard

Keywords: Authorization as a Service, XACML, Self-contained policy, OSGi

Cloud computing has promoted the notion of service as the leading way to deliver and consume computing resources. Today, security is going down that road and the term security as a service is emerging. Authorization that consists in managing permissions is one of the main classic security services. We propose in this article to study how authorization could be delivered/consumed as a Service. We focus on the XACML standard that has been adopted by the cloud security community because of its native flexibility and adaptability properties. Although XACML seems to fulfill the requirements of authorization as a Service in theory, it is very complex to realize it in practice. We propose a service oriented component architecture together with the concept self-contained policy to cope with this issue. This approach allows both the cloud consumers to adapt the authorization system to their authorization policies and the cloud providers to minimize the cost of providing a flexible authorization service.

INTRODUCTION

Cloud computing has promoted the notion of service as the leading way to deliver and consume computing resources. It is common to use applications supplied by a cloud provider, to store data out of our computer or to rent virtual machines for supporting our web site in our daily life now. Thereby, the number and nature of services provided are growing and become more diverse.

Today, security is going down that road. Security applications are migrating to the cloud. Existing examples are antiviruses that do no more run on local computers but on a cloud provider infrastructure. Identity service is another example. And more and more security applications are considered to turn out the same way. The Cloud Security Alliance summarizes it as Security as a Service (SecaaS) and provides the following definition: « Security as a Service refers to the provision of security applications and services via the cloud either to cloud-based infrastructure and software or from the cloud to the customers' on-premise systems » [START_REF] Benzekri | Defined categories of services 2011 version 1.0[END_REF]. SecaaS looks to secure systems and data in the cloud as well as hybrid and traditional enterprise networks via cloud-based services.

The Cloud Security Association has also proposed in [START_REF]Cloud Security Alliance[END_REF] a set of best cloud-related security practices divided into 14 domains. Domain 12, titled "Identity, Entilement and Access Management", recommend the use of XACML [START_REF]eXtensible Access Control Markup Language (XACML) version 2.0[END_REF] as the authorization technology because it provides a declarative access control language and a policy-based management architecture. Using XACML is not mandatory for authorization management. However, it is clearly a choice of the Cloud Security Association to promote it. In Domain 14 that focuses on SecaaS, it is suggested that identity-as-a-Service may comprise an eco-system such as Policy Enforcement Point as a Service, Policy Decision Point as a Service and Policy Administration Point as a Service.

We propose in this article a service-oriented component software architecture of XACML that could be employed to implement Authorization as a Service. Especially, our goal is to design an XACML-compliant system that could be used as a service. One of the main challenges is to build a system that could easily be adapted/extended to service customers' requirements and that minimizes the cost of maintenance for the service providers at the same time. Our solution consists in a generic core authorization engine that can be extended by reusable components. We also exploit the concept of self-contained policy. This architecture has been implemented along the OSGi specification.

The rest of this article is organized as follows. Section 2 presents XACML and the issues related to extending and adapting XACML solutions. Section 3 introduces the concept of self-contained policy and our XACML serviceoriented components architecture. Section 4 explains how to use this architecture to provide Authorization as a Service. Related works are listed in section 5. Finally, section 6 concludes the article and presents our future work.

OVERVIEW OF XACML 2.0

XACML (eXtensible Access Control Markup Language

) is an XML-based language for access control that has been standardized in OASIS [START_REF]eXtensible Access Control Markup Language (XACML) version 2.0[END_REF]. XACML describes both an attribute-Based access control policy language and a request/response language.

XACML Architecture

XACML provides a management architecture that describes the different entities and their roles related to the decision making process. A data-flow model describes this architecture. A simplified version of this model is depicted in Figure 2.

Access

XACML policy language

XACML policy language is used to describe general access control requirements in term of constraints on attributes. Specifically, attributes could be any characteristics of the subject, resource, action, or environment in which the access request is made. Attributes have an identifier, which is a Uniform Resource Name (URN), and a data type also identified by a URN. Considering attributes makes the language very flexible. Moreover, XACML language is natively extensible. As a consequence, this standard is a good candidate for cloud-based security services implementations.

XACML defines standard attributes of subjects (e.g., subject-id, subject-category), resources (resource-id and target-namespace), actions (action-id, implied-action, actionnamespace) and environment (current-time, current-date, and current-dateTime). However, non XACML standard attributes can be considered in an XACML policy by creating new URNs (see section 8 of [START_REF] Benzekri | Defined categories of services 2011 version 1.0[END_REF]). Attributes are attached to standard XACML data types (such as Boolean, integer, string, etc) or any other user-defined data types can be created (such as "urn:ogc:def:dataType:geoxacml:1.0:geometry" defined by the Open Geospatial Consortium [START_REF]Geospatial eXtensible Markup Language (GeoXACML)[END_REF]).

Finally, an authorization policy rule consists in a Boolean expression on attributes and an associated decision (called effect). Attributes are manipulated using functions according to their data types. Like attributes and data types, the XACML specification has defined standard functions (e.g., Boolean and, or, string-equals, integer-greater-than, etc). But, it is possible to add new functions to extend XACML policies. For example, the Open Geospatial Consortium has defined a set of functions to manipulate geospatial attributes such as" "urn:ogc:def:function:geoxacml:1.0:geometrycontains").

XACML in practice

In order to understand the gap that exists between theory and practice, we present a simple example. In this example, we focus on the PDP issue only. We refer the reader to [START_REF] Laborde | PEP=Point to Enhance Particularly[END_REF] for the PEPs issues.

Let consider a cloud provider that wants to develop Authorization as a Service for its customers. Respecting the CSA security guide, it provides an XACML authorization system. Now let consider a customer organization named MY-ORGANIZATION that wants a web service that provides maps. Maps include details on the organization's area. This organization wants to restrict the access of the organization's area details to its employees only. All the users' accounts are already stored in a MySQL database provided by the cloud provider. People who work for this organization can come from different companies (e.g., subcontractors). Thus, the users' account table contains a field, called organization-name, which value is the name of the users' origin. The MY-ORGANIZATION security administrator wants to make use of GEOXACML [START_REF]Geospatial eXtensible Markup Language (GeoXACML)[END_REF] that provides data types and operators to manipulate geo-data in XACML policies. The security policy is then: if organization-name of user is "my-organization" and requested-area is within MY-ORG-AREA then accept. Otherwise, reject the request. The security administrator writes this policy in XACML language (a sample is given in Figure 2). The execution process is the following (Figure 2): 1. The security administrator writes the policy in XACML 2. The policy is loaded in the PDP 3. When a user tries to access a map, the PEP catches the request and sends an XACML request to the PDP. This request includes the name of the user in subject attribute subject-id and the requested map in resource attribute requested-area. In this scenario, attribute organizationname is not provided by the PEP. We assume that the PEP sends attribute subject-id. The value of attribute organization-name, stored in a MySQL database, can be retrieved by using a request 4. When the PDP evaluates the policy, organization-name is missing in the request context because it hasn't been sent by the PEP. Thus, it has to call the PIP that retrieves this attribute from the MySQL database. It implies the XACML PDP of the cloud provider contains the PIP code that implements MySQL requests and the associated configuration (address of the MySQL server, login and password, the database schema) to get the attribute value.

5. Then, the PDP evaluates expression "geometrycontains" to check whether the requested map is within MY-ORG-AREA or not. This assumes the PDP of the cloud provider has the code that implements function "geometry-contains", and data type "geometry". 6. Finally, the PDP returns its decision to the PEP.

This simple example raises a deployment problem. The cloud provider must provide its customer non-XACML standard features: the PIP to get the value of attribute organization-name and the code to implement function "geometry-contains". The first issue is how to make these non-standard features reusable and configurable in order to allow 1) the cloud customers to adapt the authorization system according to their authorization policy and 2) the cloud providers to minimize the cost of providing such flexibility. The second issue is how to manage these reusable and configurable features efficiently? These features are mandatory because the authorization policy requires them. If the policy is changed to a new one that does not include any constraint on attribute organization-name nor function "geometry-contains", these two features are no more required. Thus, how to manage the relation between the policy and the required features?

SELF-CONTAINED POLICY

In a previous article [START_REF] Cheaito | A deployment framework for self-contained policies[END_REF], we have proposed the concept of self-contained policy to cope with this issue. The approach we have chosen consists in the policy includes all the information required by a PDP to execute the policy. This approach facilitates the management of the PDP implementation life cycle. When a policy is loaded, the required code and associated configurations are installed. When the policy is unloaded, the associated code and the configurations are removed from the PDP. We present here the concept of self-contained policy together with deployment architecture. This section improves the work presented in [START_REF] Cheaito | A deployment framework for self-contained policies[END_REF] in terms of adaptability.

Self-contained policy properties

In this section, we recall the properties of a self-contained policy.

Property of self-sufficiency: a self-contained policy should be self-sufficient.

A self-contained policy should contain all the required information to be executed by any self-contained policy compliant PDP. The policy should not implicitly require any external code or configuration to be executed by a PDP, except those in the standard.

Property of self-description: A self-contained policy should provide enough information for managing its life cycle.

When a self-contained policy is loaded, the selfcontained policy should indicate how to use its PIP code, function, etc. When the policy is unloaded, the self-contained policy should provide the set of associated implementation elements that must be uninstalled by the PDP.

Property of dynamicity: a self-contained policy should be dynamically loadable and unloadable.

The PDP should be able to load and unload a selfcontained policy without requiring to be stopped.

Service oriented component approach

We have chosen to follow the service oriented component [START_REF] Cervantes | Autonomous Adaptation to Dynamic Availability Using a Service-Oriented Component Model[END_REF] approach that takes advantages of integration and dynamicity from service-oriented architectures, and reusability and dependency management from componentoriented models.

Service-oriented architecture promotes modeling solutions in term of provided services described by contracts. It is based on the idea of composing applications by discovering and invoking available services to accomplish some tasks [START_REF] Papazoglou | Service-Oriented Computing: State of the Art and Research Challenges[END_REF]. The general pattern of service-oriented solutions consists in service provider, service consumer and service registry (Figure 3). Service providers publish services at run time and service consumers request services for a specific contract. Different service providers can offer the same service and the consumer can choose based on the contract. Since the framework allow service consumers to be dynamically notified of new registered services, and unregistered services.

Component oriented programming focuses on making reusable logical blocks of software that implements one or more interfaces. Component-oriented software is then an assembling of components. The notion of interface being very similar to the notion of service interfaces, componentoriented programming has been used to implement services. A service can be implemented by one or more components.

A service-oriented components based XACML architecture

Our objective being to provide a flexible and reusable authorization service, we have decomposed our architecture into independent entities that can be changed without impacting the whole system. Thus, it is composed of:

• A core authorization decision engine that represents the basic functionalities. It consists in the PAP component that controls the life cycle of the policy, the PDP component that provides decisions and the context handler component that handles the request context by providing two services for retrieving and modifying the request context. The core authorization decision is independent from the system to control or the policy to evaluate. • The interfaces to access the core authorization engine. The administrative console interface component allows policy administrators to access the PAP. We have implemented two different components to access the PAP via a local console, a web service. But other administration interfaces could be defined. We are working on a web interface. The second entity is the core authorization decision access point (CADAP) that allows PEP to send requests and get decisions from the PDP. Like administration consoles, different CADAPs can be proposed to adapt the authorization system to different system/network architectures. We have implemented two CADAPs components: one to access the PDP locally via a UNIX pipe and another via a web service. • The self-contained policy that contains the XACML policy with all non-standard functionalities. This architecture has been implemented using the OSGi service oriented component specification [START_REF]OSGi[END_REF] and more specifically the Apache Felix framework [START_REF] Felix | [END_REF]. The PDP component is a modification of the Sun's XACML PDP implementation [START_REF]Sun's XACML implementation[END_REF].

A self-contained policy includes three kinds of components: the policy access component, the PIP components and the data type components.

The policy access component provides only one service, called get-policy. The PDP invokes this service to get the policy rules from the self-contained policy. When the PAP activates the self-contained policy in the authorization engine, service get-policy is automatically registered. The PDP is then dynamically notified that it can load the policy file and start to use it for its decision-making process.

PIP components are logical blocks of software dedicated to retrieve attribute values from different sources, i.e. the attributes are not in the request context. They publish their service get-attribute that adds in the request context the value of the attribute. The PDP component or any data type or PIP component can invoke this service. One PIP component can be responsible for one or more attributes. However one attribute is handled by only one PIP component. As a consequence, PIP components should indicate the name(s) of the attribute(s) they are in charge of during the registration phase. If necessary, PIP components might have an associated configuration to perform their task (the ip address of the database server, the login and password, etc). The notion of reusability beside the component approach is important here because the same functionality can be shared by different policies like PIP component that implements the common access storage technologies such as MySQL database or LDAP repository. Finally, data type components implement all the functionalities related to data types elements manipulation. Each data type component provides service evaluateexpression to allow the PDP to evaluate non standard expressions in the policy. Service evaluate-expression takes as input an expression that uses functions the service handles and returns the result of the expression based on the request context. When a component, including the PDP, needs to evaluate an expression of the form <Apply FunctionId:"urn:XYZ"> … </Apply> its sends all the expression to the component responsible for function XYZ to evaluate it. This process can be recursive. If the data type component XYZ find a sub expression <Apply FunctionId:"urn:ABC"> … </Apply> it is not able to evaluate, it can ask the corresponding data type component to evaluate it, etc. In addition, data type components can invoke the get-attribute service of a PIP component if additional attributes are required. Thus data type components need to indicate the set of function names they handle. Finally, data type components may also require configuration when the policy writer specifies data type values (we refer the reader to [START_REF] Cheaito | Configurable Data Types in Policy Based Access Control Management: A Specification and Enforcement Framework[END_REF]).

Self-contained policies are more complex than XACML policy file only. Especially, managing their life cycle is not limited to uploading/removing an XML file only. All the PIP and data types components must be handled too (installing and/or removing from the authorization system when needed -see property of self-description). As a consequence, the PAP component provides the following functionalities: load a self-contained policy -the PAP loads all the components of a self-contained policy in the authorization engine environment. However, the services provided by the components are not published at this time. activate a self-contained policy -the PAP activates the components. They publish their services to the registry service. The last activated component is the policy access component. When service get-policy is published, the PDP is then notified that a new policy is ready to use and adds the XACML policy to the list of current policies. deactivate a self-contained policy -the self-contained policy is still in the environment, but the services are not accessible. When the PDP detects service get-policy of this self-contained policy is no more available, the PDP removes the policy from the list of policies it has to execute. unload a self-contained policy -the PAP removes all the components of the self-contained policy from the authorization engine.

TOWARD XACML AUTHORIZATION AS A SERVICE

Our goal is to propose a an authorization system that at the same time:

1) is flexible/adaptable enough to allow customers to control their resources considering their own specific security requirements and IT infrastructure that could be inside the cloud or elsewhere; 2) minimizes the cost of providing such flexibility to the cloud provider. We present in this section how to use our service oriented component architecture for achieving this goal.

The first step consists in the initialization of the authorization system (Figure 5. ). When the customer asks the provider for an authorization system, the provider grants him access to a generic core authorization engine. To customize this generic authorization system, the cloud provider must provide a list of reusable administration console interfaces (ACI) and core authorization decision access point (CADAP) components. The ACI components represent the interfaces that customers can use to manage policies. Our idea is the provider supplies different ACIs with different features. The basic functionalities of an ACI are load/unload, activate/deactivate a policy. Extra features such as can complete these basic functionalities: activate a policy at a given time, authentication mechanism, code of ACI certified or not, etc. Then the administrator can choose an interface that best fits its requirements. For example, we have developed two administration console interfaces. The first one is a set of commands added to the Felix framework shell [START_REF] Felix | [END_REF]. It has been defined to be used a human administrator. The second ACI is a web service that can be accessed a web service client program. Other administration console interfaces can be imagined. The CADAP components represent the connection between the PEP that controls the resource and the authorization system. Different technologies exist for this communication and PEPs might already exist on the customer technology (for example, the grid solution Globus toolkit includes a SAML PEP [START_REF] Chadwick | Using SAML to link the GLOBUS toolkit to the PERMIS authorisation infrastructure[END_REF]). Thus, the cloud provider must provide a list of CADAP with specific features like for ACIs. As an example, we have created a simple web service CADAP.

It should be noted that one customer can chose several ACI/CADAP components for the same decision engine. When the initialization phase is done, the customer can write its policies and deploy them on its authorization system.

As we have illustrated in the scenario, XACML policies might require non-standard functions/data types and PIPs. In our example, the administrator wanted to use the functions and data types for manipulating geospatial data defined in GEOXACML and a PIP that can retrieve attribute organization-name from his MySQL database.

Like ACIs or CADAPs, the cloud providers supply a set of PIP and data type components. PIP components can differ from the technology to access attributes (MySQL, LDAP, webservice, etc), the quality of the component (performance, code certification, etc). Data type components allow security administrators to take advantage of non-XACML data types and functions for writing complex security policies.

In order to facilitate the task of the administrator, we have implemented a self-contained policy editor based on Netbeans integrated development environment (Figure 6. ). Netbeans IDE [START_REF]Netbeans Platform Learning Trail[END_REF] can be extended by modules to create editors for new languages. Thus the process for editing and deploying a policy is the following:

1) The administrator creates a new project using our editor. 2) When the administrator is editing its policy, he can import PIP or Data Type components. Throughout two services provided by components, the editor can interact with them. The first service is auto-completion to minimize the typographical errors. The second service allows the administrator to graphically configure PIP and Data Type components (e.g. the server address, login/password and SQL statement for a basic MySQL PIP component).

3) When the administrator has finished to edit its policy, the editor creates the self-contained policy file. 4) Finally, the administrator loads its policy in the authorization system using the chosen ACI. At that point, the components in the self-contained policy are installed in the authorization environment. When the administrator activates the policy, all the components of the selfcontained policy are activated and the PDP is ready to evaluate the policy. y p y.

RELATED WORKS

Many implementations of XACML policy decision engine exist. Existing PDP implementations such as SUNXACML [START_REF]Sun's XACML implementation[END_REF], Enterprise java XACML [START_REF]Enterprise Java XACML[END_REF], XACMLight [START_REF]XACMLight[END_REF] are complaint to the standard XACML i.e. they support all the standard data types and functions. However, extending these implementations with new features like defining a new data type requires the modification of the source code of the PDP. Finally, HERASAF [START_REF] Herasaf | [END_REF] allows to add dynamically new data type through configuration files. However, this project doesn't define any methodology explaining how to structure data types efficiently. As a consequence, there is no guarantee a policy can be interpreted even if the implementation of the policy decision engine is dynamically extensible. In addition, there is no management of extension modules life cycle according to the policy, i.e. why and when external modules should be added to or taken away from the policy decision engine.

According to our knowledge, Ulrich Lang has employed the term "Authorization as a Service" in [START_REF] Lang | OpenPMF SCaaS: Authorization as a Service for Cloud & SOA Applications[END_REF] for the first time in a scientific publication. However, his idea of what the provided authorization service is differs from our point of view. He wants to provide model driven security as a cloud service to PaaS users (i.e., SOA application developers). The tool called OpenPMF can generate authorization rules in different format languages based on a policy specified in a domain specific language and the workflow of the SOA application. Thus people don't have to handle security when developing their application in the PaaS. Our goal is not to generate technology specific authorization rules; we want to build an extensible authorization system with reusable functionalities. Our approaches differ because our target users are not developers but security administrators.

CONCLUSION

Providing Security as a Service raises new engineering challenges. Security application will have to easily integrate heterogeneous systems (cloud, hybrid and/or classical networks). As a consequence, adaptability of security application is an important issue.

Following the idea of the Cloud Security Association, we have studied how to use XACML for implementing Authorization as a Service. Our solution is based on the service-oriented component programming paradigm. A core XACML decision engine (composed of a context handler, a PDP and a PAP) can be extended by reusable components (ACI, CADAP, PIP and Data Type). This extensibility allows the service provider to meet its customers' requirements and to minimize the cost of such adaptability. Finally, we have explained how to use this architecture for providing Authorization as a Service.

Our architecture has been implemented in OSGi to prove the feasibility. It also has permitted us to gain experience and to improve the architecture. We are following this work by implementing different components to augment the service we can provide. We are also improving our development tools to make the writing of components as well as the edition of policy easier. According to our model, multiple parties can develop components (not only the authorization service provider). We have to enhance our system to consider that components won't have the same quality level (in term of performance, assurance, trust, etc). We have to add mechanisms to prevent a component to impair the global authorization engine process.

  FunctionId: "urn:xacml:and"> <Apply FunctionId: "urn:xacml:string-equals"> <AttributeValue DataType:"string"> my-organization </AttributeValue> <SubjectAttributeDesignator AttributeId: "organization-name" DataType: "string"/> </Apply> <Apply FunctionId: "urn:geoxacml:geometry-contains"> <AttributeValue DataType:"geometry"> <gml:Polygon gid="MY-ORG-AREA"> ... </gml:Polygon> </AttributeValue> <ResourceAttributeDesignator AttributeId: "requested-area" DataType: "geometry"/writes the policy using a policy editor 2) policy is loaded 3) XACML request that includes values for attributes subject-id and requested-area 4) get organization-name attribute value 5) apply the code to evaluate function geometry-contains 6) return XACML decision

Figure 2 .

 2 Figure 2. Example of XACML in practice

Figure 3 .

 3 Figure 3. Service-oriented approach

Figure 4 .

 4 Figure 4. Self-contained policy

Figure 5 .

 5 Figure 5. Authorization decision engine initialization

Figure 6 .

 6 Figure 6. Authorization policy edition and deployment

ACKNOWLEDGMENT This work has been partially founded by ITEA2 European project PREDYKOT (Policy REfined DYnamically and Kept On Track -website http://www.itea2-predykot.org/).