Delivering Collaborative Web Labs as a Service for Engineering Education

—As Internet speed grows up and academic networks reach more users, engineering schools take interest in online laboratories as a mean to increase the spectrum of offered services and to reduce costs by sharing expensive lab equipments. In this perspective, online labs must comply both with the scientific and pedagogic requirements coming from the lab users (students, researchers, …) and with the requirements coming from the administrative and technical staff in charge to manage and deliver the lab services. In this paper we describe a system architecture based on both the classes of requirements and discuss the main results achieved implementing a prototype of the proposed architecture in a real academic scenario.


I. INTRODUCTION
Laboratories are essential to teach scientific disciplines in schools and universities. In laboratories, in fact, students can exemplify and validate analytical concepts dealing with the uncertainties involved in non-ideal situations as learners can be introduced to professional practices and develop social and teamwork skills in a technical environment.
On the other hand laboratory management implies non trivial logistic problems, security and safety issues, expensive equipments, continuous maintenance, dedicated spaces, a qualified staff, fees and a number of related administrative procedures.
To face these issues and to meet the increasing demand of lab activities, in the last 20 years the classic "laboratory" concept has been technologically extended according to four main dimensions: 1. Simulated vs. Real: real labs are essential to provide experimental data to students and researcher, but they are often expensive or not even available. Digital simulators based on mathematical models and large data collections have been created to reproduce the behavior of real lab equipments at a fraction of its cost. As simulations can't fully capture all nuances of hands-on experiments, students are not mentally engaged in the same way as they do with real apparatus. Anyway, in some specific cases (e.g. virtual protoboards for discrete electronic, training simulators etc.) they can be considered excellent companions of real lab equipments. 2. On-Site vs. Remote (space-mediated): Remote Laboratories (RL) are based on remotely operated lab equipments [2]. They offer the opportunity to "conduct" an experiment even being out of the lab ( [4], [5]). Today RLs are available in quite a large and growing number of educational and research institutions, in addition to Learning Management Systems, in the mainstream of educational tools and practices. In general, the effectiveness of RLs increases with the "degree of presence" of the remote operator. RLs based on Web technologies are called Web Labs. 3. Synchronous vs. Asynchronous (time-mediated): laboratories can be used for both real-time (short and interactive) and non-real-time (long-living) experiments. In both cases the involved physical resources (e.g. lab equipments, consumables etc.) must be reserved according to lab policies and to the user needs, often requiring tousebooking systems and other similar management tools. Roughly asynchronous labs are for batch and long-living experiments.
They are based on programmable devices able to automatically control the lab equipments (inputs, outputs, alarms, …) while collecting experimental data for further analysis. Synchronous labs are for short-and-interactive experiments (electronics, robotics, apticdevices, …). They are often based on live streaming and other QoS-aware communication technologies able to support satisfactory interaction level while preserving the equipment safety even in case of network failures. 4. Single User vs. Collaborative: in general the learning outcomes of lab classes are strictly related to social interaction [18]. Collaborative lab activities, in fact, are able to foster active learning, to guide interpretation and construction of concepts and to promote the comprehension construction by the student. For these reasons Collaborative Laboratories have been actively investigated and developed in recent years.
Among all possible combinations of these dimensions, we concentrate our research on real-remote-synchronouscollaborative labs, in short "Collaborative Web Labs"or "CWL", because they actually own promising potentials to extend traditional labs for both learning and research activities.While the above described considerations are oriented to teachers and students, CWLs are also interesting to engineering schools. In fact, even if there is no research data on remote lab cost comparisons, anecdotal evidence indicates that operating costs can be significantly reduced, more experimentation by students becomes possible, expensive equipments can be shared among institutions and lab activities can be fully integrated in the increasingly popular Learning Management Systems.On the other hand, this requires a new generation of CWLsthat should: PAPER DELIVERING COLLABORATIVE WEB LABS AS A SERVICE FOR ENGINEERING EDUCATION  offer a range of welldocumented lab services characterized by well defined quality levels;  scale-up with the number of laboratories and users;  implement recovery features in case of failures;  interoperate with other components of University Information System, with specific attention to Learning Management Systems;  monitor each activity relevant for system security, user assessment, lab operations and other significant events;  centralize the control of the system while preserving the autonomy of each controlled lab.
In this scenario the aim of the paper is to discuss the challenges facing the management of Collaborative Web Laboratories adopting the SaaS (Software as a Service)paradigm, and presents some preliminary results.
The paper is structured as follows. Section 2 sets up the background, section 3 discusses some supported scenarios, section 4 discusses the architecture and some preliminary results. Section 5 concludes the paper and sketches future developments.
II. BACKGROUND Remote laboratories target a large range of devices, from different scientific areas. This means that they are not restricted to a single educational topic, but they are used for several devices and experiences controlled using a computer ( [2], [11]).
Currently technology enabled labs include different kinds of experiments. We can distinguish among remote, hands-on and simulated laboratories ( [2]) and a large debate is still going on addressing the critical issue of whether remotely operated or simulation-based labs are as effective as the traditional hands-on lab format [21].
Co-construction of knowledge is also one of the basic goals of collaborative learning and the area of CSCL (Computer Supported Collaborative Learning) is expected to provide a remarkable support to the efficacy of this practice.
Remote labs indeed have the potential to provide affordable real experimental data by sharing laboratory equipments with a pool of institutions [3]. Also, they can extend the capability of a conventional laboratory by increasing the number of times and places a student can perform experiments ( [4], [5]) and extending its availability to several students ([6], [7]). For these reasons, since 1996 [8] remote laboratories have been increasingly popular. In the first years their development has been driven by technical aspects rather than by the need to design effective learning environments. More recently, thanks to the availability of better remote control techniques and faster networks, some researcher extended their attention also to the learning dimension and to the management aspects of remote laboratories. These aspect, in fact, are essential to the actual creation of effective Web Labs Facilities in the interested Universities.
In more details, the research on the learning dimension focuses on the integration of social presence in Web Laboratories and in learning management systems. This line of research starts from the observation that collaboration among students is a cornerstone of the local laboratories learning experience as it lets students exchange skills, results and knowledge, to form groups and to emulate other group members. Various contributions investigate the impact of tele-presence, social presence, immersive environments and group awareness on learning outcomes ( [18]- [22]). These aspects of collaboration are important in Engineering Education, particularly in laboratory settings, as by learning together, students also learn to work in a distributed group, which is otherwise difficult to learn during lectures. Distance working is also likely to be an important facet of their future life as engineers. We-ColLab approach ( [23], [24]) is a first answer to these issues. It both enables the remote control of a generic real laboratory equipment (like telescopes or microscopes, robotic arms and their related auxiliary devices) and lets groups of students share their lab experiences over the Web by means of a multi-videoconference platform which is integrated with the remote control of a laboratory equipment. Another approach to the development of collaborative Web Labs is discussed in [25], where an online learning framework is integrated with group awareness support. In this system, students connected into an online session are notified both on the effects of their intended action and on the possible interactions with the other users. Each online student is assigned a unique visual indicator (usually a color) for the duration of a session and this indicator is used to show the author of each action. A third approach to add collaborative features to Web Labs is based on the integration of Web Labs in Learning Management systems, which already own these features ( [26], [24]). This approach is valuable but it doesn't try to recreate online the hands-on environment as the other approaches do.
Moreover the integration of the laboratory with local information systems, especially Learning Management Systems, is part of the research area investigating the management of Web Labs as University facilities. This topic has become hot since the beginning of discussion about cloud computing and Web 2.0 communities and novel delivery models (Infrastructure as a Service, Platform as a Service, Software as a Service) based on Service Oriented Architectures (SOA). In the field of Web Labs, researchers have been investigating on how to transform applications in cloud services and their impacts on organizations and business models. REALabs platform [16] is one of few contributions discussing a reference model for Web Labs and related non-functional properties. Actually this reference model doesn't take into account research and contributions coming from IT Service Management (ITSM) and ITIL reference framework [27], which are the state of the art about the management and governance of IT services.
In order to cope with both the requirements of adding collaborative features and treating Web Labs as facility in a cloud scenario, we state that it is necessary to investigate challenges and opportunities to design Collaborative Web Lab as a Service.
To summarize, we state that WeColLab [23] and REALabs [16] are the most significant results towards the creation of effective Web Labs with collaborative features, but a major re-engineering effort is needed to answer to the challenge to deliver Collaborative Web Labs as a Service.
iJOE -Volume 8, Issue 2, May 2012 PAPER DELIVERING COLLABORATIVE WEB LABS AS A SERVICE FOR ENGINEERING EDUCATION III. COLLABORATIVE WEB LAB AS A SERVICE Sharing expensive and precious resources, like Lab equipments, among institutions employing Web technologies over different networks (i.e. public Internet, campuswide network, or high speed private network) may become very interesting for Universities and research institutions, which could follow this opportunity with the aim at extending their online offerings to external users and institutions, improving the Return on Investment (ROI) and splitting the Total Cost of Ownership (TCO) and management among several faculties and, eventually, other universities.
Traditionally lab equipments are managed by technical staff during their working hours to complement frontal lessons with laboratory activities (with or without tutor) and for research purposes. Usually technical staff (managing the equipment -i.e. the lab manager) is asked by the lecturer or the researcher to arrange specific experiments, to supervise students during their experiments, to maintain the equipment and optimize the lab utilization within the constraints of lab access policy. According to requests, priority policies and maintenance schedules, the lab manager assigns time slots to users (i.e. classes, researchers, etc.) and sets up the equipments accordingly.
Providing online laboratory services to virtual classes means extending the laboratory operating ours (e.g.for users in different time zones). However, this requires to modify the delivery process and the overall organization (including the contracts of the lab personnel) usually adopted by universities to manage lab services for local students. In other words it is necessary to revise laboratory activities such that they become on line facilities with all its implications.
We can envision different scenarios: 1. Hands-on (i.e. in presence): laboratory equipments are used by students in presence, according to a schedule managed by the technical staff; 2. Remote: any allowed remote user can schedule a lab session, even in collaboration with other users, on a virtual workbench including equipment distributed in the campus, even among federated universities. Different user types (researchers, university students, external users, …) must observe different management policies and scheduling rules, according to equipment features (e.g. the service can be free for local researcher but a fee can be applied to external user, the lab reservation can be managed by the teacher for university students or can be self arranged for external users, …) and lab manager requirements (lab manager's working time, scheduled maintenance, etc.). 3. Blended: local and remote users can collaborate to use the lab equipment (e.g. a local tutor can coach a remote student about a new lab technique).
Scenario 1 is typical of research activities, maintenance and of "hands-on experiences", scenario 2 reduces logistic problems, allows more balanced exploitation of valuable equipments and cuts costs, scenario 3 is very effective in collaborative research and in students coaching.
Moreover, in all scenarios, Web Collaborative Laboratory activities can be part of eLearning services provided by universities. In fact, besides performing remote experiments in a collaborative environment, CLaaS must interoperate with typical elearning services to deliver assignments, to publish laboratory reports, to evaluate and assess students' activities, to manage the on-line library (equipment handbooks, experiment descriptions, learning materials, etc.).
To approach the design of the CLaaS system and to correctly manage all the above mentioned issues, we adopted a goal/stakeholders approach based on scenarios for eliciting functional and information requirements. We added Key Performance Indicators modelling for nonfunctional requirements (i.e. availability, response time, security, etc.). Then we designed an information reference model for CLaaS and sketched the overall application architecture delivering the service.

A. Scenario Description
In the e-learning framework the Department of Engineering at the University of Salento is exploring the opportunity to extend the traditional hands-on laboratory classes on the Web, delivering Web Lab services to remote users. The Department owns several lab equipments (i.e. robots, very expensive electron microscopes, etc.) distributed in different locations over the campus.
In order to design a quality service, it is necessary to understand what the customer gets out and is willing to pay for (i.e. the value perceived by the customer), because it answers to his/her need and he/she perceive the value.
The scenarios described before show different customers: I. Local users: they are users (i.e. researchers, students and class lecturers), belonging to the Department, enabled for the local access at lab equipments, as described in scenario 1. They need to reserve a time slot for experiment, according to the policy they are subject to; II. University students: they are students, external to the Department, who can access lab equipments according to University policies (i.e. they own a time budget in a certain period, because they take classes). They can reserve and set up a Web Lab virtual session with other students either in blended or in presence classes, submit remote experiments results to teachers and tutors and get evaluation back, interact with technical staff in case of incidents and support requests during the experimental session. III. University teachers and tutors: they are assigned time slots according to policies. They need a remote laboratories' catalogue, functionalities to reserve a remote session for an experiment inside a elearning course or as additional activity, coaching students during the experiment, delivering material supporting the experiments to students IV. Users coming from peer systems (e.g. federated institutions), who can remotely access the University equipments. They need to book a WeColLab session, perform the experiment, interact with the technical staff for support requests.
In order to design and manage such services we must also consider the following stakeholders:  the WeColLab manager, responsible of the overall service delivered to customers and of its quality (i.e. agreed service levels, design of new services, etc.

B. Information model
The information reference model for CLaaS is modelled with UML (Unified Modelling Language) simplified class diagram. The aim of such a model is to identify the major functions that a Web lab with collaborative features adopting a service-oriented architecture must support ( Figure 1).
The model is neutral in terms of implementation technology and application domain.
The central entity of the model is the WebLab itself. This component operates a set of resources, both physical (equipments, devices, machines, etc.) and logical (software systems). Resources are manipulated by Infrastructure services, which hide the particular characteristics of a resource (i.e. the programming language and communication protocol employed to handle it) and expose an interface to handle it. The mapping between Infrastructure services and resources is arbitrary. Infrastructure Services may aggregate multiple resources into a single manipulation unit (e.g., a camera and a microphone as a communication resource), and multiple services can manipulate a single resource (e.g., each service offering a different mode of operation for the resource). In our approach the elementary granularity is the overall service provided by resources (as network cameras, robot or lab servers -i.e. the service provided by the computer connected to the lab equipment).An experiment is offered by a Web Lab and it is performed through a composition of services.This aggregation is specific for an experiment.
For instance, an electron microscopy Web Lab can offer the possibility (the service) to analyze one or more samples of material by means of an electronic beam and different image sensors, whit the options to interactively zoom-in (to enlarge images and see more details), to shoot pictures of the samples, to rotate the motorized carousel, etc. In the lab there are also: a Webcam, specifically equipped to prepare the samples and to place it on the carousel, and an environmental Webcam, used to follow the lab operator (if any) and to enforce the remote presence. In this context an experiment may consist of the comparison of measures on the same kind of sample with different Web electron microscopes. Such a virtual experiment can be prepared by composing the carousel of the microscope to allow the user to choose the sample and analyze it. In order to compare measures taken with different microscope, the same composition must be executed with another remote lab and at last it is necessary to compose the two Web Lab services in a single (at higher level) comparison service. Experiments may be part of e-learning classes, where users (i.e. teachers, tutors, students) belonging to University are enrolled according to their role.
WebLabs and experiments are Services delivered to internal or external users. They are arranged in a Service Catalogue, available to users and stakeholders according to credentials and policies. As part of a catalogue, each service is described by five information categories:  General information are related to the service name and description, service category, operations time and calendar, metrics of price  Technical features include the description of IT components the service is based on, the presence of disaster recovery and business continuity, the alerting procedures  Security consists of information about the data sensitivity and privacy, security manager and security contacts  Contact is the category including contact information Organizations can form federations in order to share the Web Labs they maintain. For example, through a policy an organization can offer a Web Lab it maintains to members of another organization, subject to restrictions and privileges, such as maximum reservation time, maximum number of accesses per day, and quality of service. Policies are operative through SLAs, which describe a set of usage policies expressed as a number of condition/action statements (rules) that establish how experiments and services behave according to the restrictions and privileges stated in the SLAs.
Organizations issue credentials to their registered users after the user is authenticated. Credentials are assertions (facts) about the user such as his/her identity, authentication method, and credential expiring date. Credentials are iJOE -Volume 8, Issue 2, May 2012 PAPER DELIVERING COLLABORATIVE WEB LABS AS A SERVICE FOR ENGINEERING EDUCATION usually digitally signed by the issuing organization in order to assure its origin and integrity. In a federation, credentials must be understood by all the federated organizations. In order to access a service, the user must establish an access session with the Web Lab. This process checks whether the credentials presented by the user suffice for granting him/her access to the experiment or service.
A group of users can access a Web Lab simultaneously. In this case, all group members are allowed to establish sessions at the same time, each user according to his/her role (i.e. tutor, students, teacher, lab manager). The Web Lab must allow reservations to be shared among group members. The Web Lab must also supply concurrency control mechanisms that prevent unsafe operations on resources under concurrent access.

C. Architecture
The CLaaS system is a domain-independent serviceoriented platform delivering collaborative Web laboratory services. It is based on the reference model displayed in Figure 1 and implements the scenarios described above. In order to manage the elements of the reference model, the system must offer centrally a set of functions such as those listed below (Figure 3), which are enclosed in the Lab-Facilities Manager:  Management of services in the catalogue  Management of SLA and policies  Management of resources  Management of users and groups  Management of security, user access, user authorization and equipment safety  Management of Collaboration services The management of services allows the organization to share the service description in order to compose a unique catalogue published by the institution to its users and to other institutions. It includes also policies and resources related to services.
The management of Service Level Agreements are related to services included in the catalogue and allows an organization to model the contracts it has established with its users or federated organizations 1 . Usually contracts are expressed by signed documents stating, for example, the parties to the agreement, services covered by the contract, QoS indicators, responsibilities, roles, pre/post conditions for service invocations, obligations, pre/post conditions and actions if obligations are not achieved or are underachieved.
SLAs management is one of the core processes in IT Service Management (ITSM) literature. It is usually based on ISO/IEC 20000 and modelled according to ITIL reference framework. In this scenario, to support SLA management, an IT system must provide periodic reporting functionalities about each SLA, management of obligations, actions and penalties. The management of policies allows an organization to establish and enforce access and usage policies for the Web Labs it maintains, both for its 1 Usually SLAs for the delivery of facility services between students and University are integral part of the enrollment at University. Facilities SLAs are not negotiated by each single students, but they are imposed by University and there is not a formal process to control and report the service level to students. SLAs are more formal in case of agreements among Universities or institutions to share facilities. The management of resources is a service provided to lab manager, who maintains and optimizes the use of a resource inside the lab, according to institution policies, lab equipments features, provided experiments and local policies. The resource manager must also provide a service for resource reservation subjected to the constraints listed above.
The management of users allows an organization to subscribe/unsubscribe users and group of users, and to assign attributes to users such as identities, credentials, and profiles (preferences). It is strictly related to security manager, which comprises identity management services (i.e. federated authentication and authorization) and equipment safety services. Federated authentication (i.e. the Single Sign On) allows users to be authenticated only once by their respective organizations in order to access services of any federated organization. It assures that information about the user is stored only in her/his home institution. Federated authorization is a service, by which identity and credentials of a user are recognized by all federated organizations when the user tries to access any service in the federation. The Collaboration Manager allows an organization to manage groups of users (students and teachers) to see/hear/talk to each other, supported by various collaboration tools (shared whiteboard, picture annotation, chat…), moreover they must see (all together) and remotely control (one at a time) the laboratory equipment.
In order to remotely access and manage lab resources, each local lab must provide video, audio and data streaming services to the Lab facilities Manager.
The Lab Facilities Manager exposes its components as services, which can be integrated with Learning Management Systems in order to add Collaborative Web Laboratories activities to elearning classes and exploit learning management services (like the management of assignments and students, the students enrollment in elearning courses, the management of teaching materials, etc.) already offered by such a systems. Details on how to integrate Web Labs and LMS are described in [24].

PAPER DELIVERING COLLABORATIVE WEB LABS AS A SERVICE FOR ENGINEERING EDUCATION
IV. TEST AND RESULTS To implement the above described CLaaS System, we have split it into two subsystems representing the "Lab Manager" (LM) component and the "Lab Facilities Manager" (LFM) component shown in Figure 3.
In a first phase the LM has been implemented and tested as a separate unit, then LFM has been implemented and integrated with the LM, and the whole CLaaS system has been tested. The implemented prototype is only a proof-of-concept, and test is only for preliminary and technical purposes, but it is relevant to grab this experience to set up the whole CLaaS project and implementation.

A. Lab Manager: Validation
Each new lab facility which participates to the project must own one or more lab equipments that must be compliant with the architecture described in Figure 3. To meet this requirement, starting from the experience gained in previous projects, we have developed a flexible and versatile remote control kit, named Collaborative Remote Control Kit (CRC-Kit), suitable for a number of different Lab Equipments (LE). The CRC-Kit permits to remotely control any computer-controlled lab equipments (i.e. an electron microscope, a telescope, a robotic arm) equipped with analog or digital video-output and with mouse/keyboard inputs.
The CRC-Kit is made by a portable computer, a multistandard frame grabber to capture, encode and transmit live audio/video streams, an I/O board able to manage analog and digital signals, 4 USB ports a, couple of webcams and a purposely developed software. For some computer-controlled lab equipments the CRC-Kit is not needed and the Collaborative Remote Control features can be achieved at lower cost, by means of standard software components.
The SaaS part of the LM we implemented includes the reservation services, the access control service, the experiment catalogue service and the glue-logic needed to support the collaboration among a local user and one or more remote users.
The test phase of both the CRC-Kit and the LM prototype has been performed by installing two CRC-Kits: one on the electron microscope at a metallurgy lab and the second on a small telescope at our university observatory. Then, for each lab, an LM instance has been configured and activated.
The installation of the two CRC-Kits was not complex, and permitted the rapid and almost complete telecontrol of the two equipments, with the exception of some non standard mouse gestures in the electron microscope. The two LM instances, customized according to the requests of the respective lab managers, were tested for two weeks by the same lab managers and by six lab students. The transition from the "manual" management system to the new Web-based one was quite simple and smooth, but all users asked for a longer and wider test before to express their opinion. Conversely the new features offered by the CRCkit, allowing the access of the lab equipments from the researcher's rooms or from the classrooms, even in collaboration with the remote lab owner, were immediately appreciated from teachers and researchers.
The transition from the manual authorization and reservation procedures to the Web-based ones was less appre-ciated, but it was accepted because of the increased quality and of the high "perceived value" offered from the "new" lab facilities.

B. Lab Facilities Manager: Validation
The LFM prototype implements a rough 50% of the features described in the previous section. For example, SLA monitoring features and payment services are not considered. Conversely, the following services are fully implemented:  The Lab Catalogue, to centrally describe and define the experiments and the lab services globally offered by the federated lab facilities on Web. This offer is not just the sum of the services exposed by each lab, because services can be composed to form new experiments, impossible to the single lab. Let's consider, for example, the possibility to operate at the same time with two different telescopes located in two different places or based on two different sensors, with the possibility to combine the two results in real time;  The reservation system, that extends the reservation features available in a single lab with the possibility, offered to teachers, to reserve remote lab sessions for classroom activities or for their student's workgroups;  The collaboration system, that permits small groups of remote users to share the control of a lab equipment according to given collaboration rules (supervised or unsupervised control, two peer controllers at time, etc.);  The security system, that interoperates with the University directory service to manage all user requests according to the official user credentials. The system is also able to deduce the dynamic status of each request from logic rules like this: "if a student is part of a group or of a class assigned to a given teacher AND this teacher reserved a remote lab session for the group THEN the student is authorized";  The interface, exposing the main LF services to external systems like Learning Management Systems or other peer LaaS instances;  The LFM system has been installed and tested at the Engineering Department of our university. The test was made by experts, including two administrative managers and two teachers of the same Department, who have simulated the attribution of a given amount of lab-hours to a class and to the corresponding teacher. In a further step the two teachers simulated the scheduling of:  a remote lab session to be held in the classroom, for training purposes,  a number of supervised lab sessions for small groups of students,  a final lab session, for assessment purposes.
The test permitted to validate the overall system design and the correct integration between the LM and the LFM. According to the teacher's requirements, the LMS we selected to interoperate with the LFM was Moodle, because it is open and because it is used in a number of universities to support a wide range of learning activities.
Teachers and administrative managers appreciated both the overall idea and the implementation details, and asked PAPER DELIVERING COLLABORATIVE WEB LABS AS A SERVICE FOR ENGINEERING EDUCATION for a more comprehensive test to be performed on real classes and real lab sessions.
V. CONCLUSONS AND FUTURE WORKS In the paper we described CLaaS, an approach and a system to offer Collaborative Web Lab as a Service. A CLaaS prototype has also been implemented and tested to validate the approach and to grab the experience needed to prepare a further and more detailed CLaaS project and implementation. Remote labs are relatively new in the learning scenario, and the absence of a reference model for the processes and services offered by universities make it difficult to define a single solution able to satisfy all situations, but after the CLaaS experience we feel that the SaaS approach can be very useful to evolve the concept of Remote Lab to a higher level of effectiveness.
In the next academic year we have already scheduled to complete the CLaaS implementation, to perform a more accurate test and to have a more stable CLaaS installation, with greater attention the standardization efforts coming from US and EU regions