Sharing Remote Labs : A Case Study

The interest on educational remote laboratories has increased, as have the technologies involved in their development and deployment. These laboratories enable students to use real equipment located in the university from the Internet. This way, students can extend their personal learning experience by testing with real equipment what they are studying at home, or performing hands-onlab sessions at night, on weekends or whenever the traditional laboratories are physically closed. A unique feature of remote laboratories when compared to traditional laboratories is that the distance of the student is not an issue, so remote laboratories can be shared with other schools or universities. In this contribution, authors present and discuss a widely spread remote laboratory (VISIR, present in 6 european universities + 1 in India) shared among 3 institutions (2 universities + 1 high school).


I.
INTRODUCTION A unique feature of remote laboratories when compared to traditional laboratories is that the distance of the student is not an issue, so remote laboratories can be shared with other schools or universities.This sharing can be managed in a direct, simple way: the provider university (the one where a remote laboratory is located) creates accounts of users of the consumer university (the one interested in using the provider university's equipment for their students).Students of the consumer university directly access in the provider university and the provider university does all the work: it authenticates the user, authorizes him to use the laboratory and provides the laboratory.
There are multiple problems for this straightforward solution.First, the provider university must create and manage the user accounts of all the interested consumer universities.In a complex scenario, where a wide variety of consumers exist -such as foreign universities and even secondary schools that simply do not speak the provider university's language-, this idea does not scale.Second, the management of this approach is cumbersome: consumer universities would need to notify the providers every change, and they may not be able to access local databases using protocols such as LDAP (a standard protocol commonly used in universities to authenticate and authorize local students).Third, the consumer university cannot carry a proper accounting of the uses performed: it must trust the provider university.If both institutions come to an agreement where users of the consumer university can access up to 10,000 times, there will be no way for the consumer university to audit this if the provider university at some point says "you have achieved the limit".
In order to handle these and other problems, a two-side model is required, where both universities have the same software framework that manages this sharing.The consumer university can authenticate and authorize local students, and once authorized contact the provider university and request a slot for the remote laboratory.This way, the provider university does not need to manage students and courses of the consumer university, and the consumer university can track all the requests performed to the provider university, being able to track students and audit the overall use.
In this sense, MIT iLabs [1] have been effectively sharing remote laboratories around the world for years.Different universities can use the MIT iLabs framework to develop, maintain and share their remote laboratories with other universities.In the federation model defined by the iLabs Shared Architecture (ISA), there are two types of remote laboratories that can be shared: batch laboratories (using queues) and interactive laboratories (using a calendar-based booking system).
The architecture behind this mature system lacks of two features relevant for this contribution: 1) load balance among different copies of a remote laboratory and 2) transitive sharing.
The first feature refers to the fact that behind every remote laboratory there is a physical hardware, which is usually the bottleneck for many concurrent students using the same hardware.If the provider university replicated this hardware (for instance, having 4 copies of an electronics board instead of 1), the load of users could be balanced among all the copies.Furthermore, if two universities have two copies of this hardware, it could be possible to first use the local resources and only if all the local resources were busy.This could be called distributed load balance.
The second feature (transitive sharing) refers to the capability of re-sharing a remote laboratory to a third university.For instance, one university could share 10,000 accesses to other university, and this other university could split these 10,000 accesses on two: the first 7,000 are only for their students and the other 3,000 could be reshared to a third university interested in consuming that laboratory.This would work in the same way a real market works, with prices adapting to the offer, demand and requested quality of service.
In this contribution, the open source WebLab-Deusto1 framework, which supports both features, is presented and analyzed for a particular case of study: the VISIR remote laboratory.VISIR system located at ISEP II.CASE OF STUDY: SHARING VISIR The VISIR remote laboratory 2 [2] is an electronics remote laboratory, deployed in 7 different universities.One of the most interesting features of this laboratory is that it supports concurrent students using independent sessions.This means that, given that each access is very fast (tenths of second), the accesses are multiplexed with relays, so final users do not realize that other users are using the same equipment.

SPECIAL FOCUS PAPER SHARING REMOTE LABS: A CASE STUDY
In the University of Deusto, authors use it regularly with even 60 users through WebLab-Deusto [4] .If more students aimed to access, WebLab-Deusto would create a queue so they will enter whenever some current students log out or their assigned time passes.
Other VISIR 3 is deployed in Polytechnic Institute of Porto -School of Engineering (ISEP), and one WebLab-Deusto instance has been deployed in the University of 2 http://openlabs.bth.se/ 3 http://physicslabfarm.isep.ipp.pt/Deusto configured to access the VISIR at ISEP [3].This WebLab-Deusto instance could technically be deployed in ISEP.Finally, there is a high school (Colegio Urdaneta) has also deployed WebLab-Deusto4 , but they do not have any VISIR deployed, becoming a consumer-only institution.
Given the described features of WebLab-Deusto, the following schemes can be used: 1. Any student (of ISEP, Deusto or the high school) can access the VISIR at Deusto for a particular configuration only available in Deusto.2. Any student (of ISEP, Deusto or the high school) can access the VISIR at ISEP for a particular configuration only available in ISEP.ISEP does not need to know the high school thanks to the transitive sharing, since ISEP can share VISIR to Deusto and Deusto re-share it to the high school.3. Any student (of ISEP, Deusto or the high school) can access any of the two VISIR equipments for a particular configuration available in both VISIR equipments.For instance, if 90 students were attempting to use the system, 60 could be using one VISIR system and the other 30 the other VISIR system.

Figure 1 .
Figure 1.WebLab-Deusto shown in the Colegio Urdaneta accessing a VISIR system located at ISEP