Network Architectures of Remote Laboratories Proposal of a New Solution and Comparative Analysis with Existing Ones

—Remote laboratories are being built upon different network architectures. This paper analyzes major classes of such network architectures from the point of view of network infrastructure, with examples of currently employed solutions. Pros and cons of each architecture are discussed. A new solution making network communications between laboratory servers and laboratory users to be more efficient is proposed. This solution is based on using high-performance computers such as IBM Mainframe as common layer for laboratory servers, simplifying and unifying software development of remote laboratories for their producers.


INTRODUCTION
Existing remote laboratories utilize Internet infrastructure for providing access to experimental or study equipment to the end user. Remote experiments are being conducted in a very broad range of STEM (Science, Technology, Education and Mathematics) subjects, but all of them are controlled by computers and are integrated in the existing data transmission networks. Thus, all network elements of remote laboratories are standard blocks that adhere to client-server architecture of computers and applications [1].
Client-server architecture is a basic architecture of remote laboratories because it allows a client (application and a computer of the end user) to control remote experiment [2]. Local control of the experiment is a task of control and automation that is not in the realm of the remote access, hence it is not discussed in this paper.
Remote laboratory client is an application that is running on the device of the end user conducting remote experiment. Such device (personal or tablet computer, smartphone etc.) is usually in the local network and behind network address translation (NAT) devices. This paper doesn't address issues of network address changes on the client side, because remote laboratory network architecture doesn't depend on it. Thus, we will treat clientserver communications as direct TCP/IP connections.
Network architecture is one of the most important parts to be taken into account when organizing communication between the end user and experimental setup, and it directly affects the overall quality of the remote laboratory.
All papers on remote laboratories (in particular [3]) propose to use separate computer in a role of laboratory server when functionalities of laboratory and web-server are delegated to different machines. This paper suggests new network infrastructure for remote laboratories. We propose to virtualize many laboratory servers on one highperformance computer of IBM Mainframe class. With big numbers of experimental setups it would give considerable economical and operational benefits, improving performance and security of laboratory servers at the same time.

II. EXISTING REMOTE LABORATORY ARCHITECTURES
Historically first remote labs were controlled by computers that served also as web-servers (figure 1). EPFL researchers were among the first ones who chose this path [4]. At present such architecture goes extinct (except when it is used in smart devices) but still exists due to the existence of embedded easy-to-use web-servers, such as Lab-VIEW Remote Panels allowing to upload LabVIEW application into user's browser with a help of ActiveX technology [5]. In a case of EPFL it was a conscious decision, while LabVIEW Remote Panels is usually a consequence of shortage of resources for development of more scalable and mature solution. Main drawback of such architecture is a dependency of embedded web-server on the software controlling equipment. Such architecture decreases performance and security of both servers, and also makes remote resource unavailable each time when controlling computer is switched off.
Division of labor between laboratory and web-servers allows increasing quality of services because in this case laboratory server doesn't waste resources on serving many users, while web-server is built on specialized professional solutions that provide load-balancing, SSL-certificates, great performance and throughput (figure 2). Moreover, PAPER NETWORK ARCHITECTURES OF REMOTE LABORATORIES  Another approach is to share one common web-server such as Labicom.net [6,7] by different remote laboratories. In this architecture (figure 3) remote laboratories obtain users of other remote labs, provide consistent user experience and cut web-server maintenance expenses because it is divided by all connected laboratories. Other synergy effects also take place when shared web-server architecture is used -it is simpler to find a given remote lab for the end user because all remote laboratories become accessible on one single web-site. This, in turn, increases value of remote labs for search algorithms.
Laboratory server is a computer that is connected directly to experimental equipment through different interfaces (USB, RS-232, GPIB, IP, Wi-Fi etc.). Such computer runs equipment control application that monitors its modes and condition and exchanges data with web-server. If some institution has more than one remote laboratory in its network, each of them must have its own laboratory server.

III. PROPOSED ARCHITECTURE
When many remote laboratories are planned in an institution, it becomes possible to virtualize all laboratory servers on one high-performance computer such as IBM Mainframe. If such virtualization is used, experimental equipment may be connected to the Mainframe via IP protocol, using internal IP-addresses ( figure 4).
If it is necessary to use real-time system for control or data acquisition, deterministic system can be seen as one separate equipment unit and be connected to Mainframe via IP protocol while containing many devices, its own control unit and algorithms. Thus, in the suggested configuration when real-time system is needed it is still possible to use together real-time equipment (e.g., PXI-based systems or FPGA) and all other not real-time equipment (e.g., cooling system, IP-camera, etc.).
Each laboratory server that was virtualized on the Mainframe continues to exchange data with a web-server in exactly the same way as when it was a separate machine. It means that from the point of view of external part of remote lab network (web-server) nothing has changed and it is not needed to make any changes in it.
However, high-performance computers such as IBM Mainframe might be used for connecting much more equipment than any educational institution has. It opens up opportunities for virtualization of all laboratory servers with a help of one high-performance machine (figure 5). As a result, it is enough to have only one computer such as IBM Mainframe of a shared use available globally that frees each institution from buying its own Mainframe separately.

IV. PROS AND CONS OF A VIRTUALIZED LABORATORY SERVERS
When laboratory servers are virtualized, Mainframe shows all advantages that it has in other application areas: improvements of system stability, scalability, maintainability, throughput, data integrity, support and an economy of scale. Moreover, due to utilizing IP protocol for data exchange it is not mandatory to continuously update drivers for all devices, and the risk of incompatible updates is fully eliminated. After virtualizing remote laboratory, its developer has an opportunity to develop and deploy the control program for laboratory server on any platform and to use development environments of any supplier and of any version that he or she finds suitable. Mainframe also gives an option of a "hot swap" of the whole system because it is running on virtual machine.
In [12] IBM showed that virtualization of one server gives economy of energy of 110 Wh. It means that virtualization of 100 remote laboratory servers can save up to 110 Wh x 24h x 365 days x 100 labs = 96360 kWh/year, which is equivalent to 48 tons of coal per year.
Another advantage of a virtualized lab-server is an increase in server-side program performance. Such acceleration takes place not only due to computational power of Mainframes, but also due to specialized hardware that accelerates symmetric and not symmetric encryption algorithms. Thus, HTTPS [RFC2818] connections could be speeded up when special co-processor (such as Crypto Express3) and SSL-handshake accelerator are used [13].  The drawback is a price of such high-performance computer as IBM Mainframe for educational institution, and also a necessity to buy devices for IP communication.

V. CONCLUSIONS
The architecture of a remote lab with virtualized layer of laboratory server proposed in this paper can decrease time, money and other expenses when a remote lab is deployed. Such architecture is a viable option to build remote lab networks because Bauman Moscow State Technical University (BMSTU) already possesses an IBM Mainframe z10EC (Enterprise Class) [14]. Engineering on-line education gains momentum and one can foresee that proposed architecture will be more and more in demand in the future when remote laboratories become more numerous, used in the STEM curriculum and the most efficient way of incorporating remote laboratories into the global network infrastructure will be required.