Remote lab setup - Telecominfraproject/oopt-gnpy GitHub Wiki

Written by Emanuele Virgillito.

This document serves as an introductory knowledge base to prepare the environment for experimental activities to be performed between Politecnico di Torino and whatever TIP affiliated.

Those activities involve the testing of open optical networking solutions, mainly exploiting GNPy capabilities for quality of transmission prediction and network management relying on optimization of an optical line system working point. Such test could potentially encompass a wide range of situation:

  • Green field: testing of open solutions in newly deployed hardware still not operative.
  • Brown field: testing of open solutions in already deployed and functional segments of optical network.
  • Laboratory setup: testing of open solutions in fully dedicated laboratory equipment, not involving deployed fibers and devices.

Note that these are just some examples of the potential situations one would want to perform a test on. Therefore, the setup phase of the framework may require further complexity with respect to what listed in the following lines depending on the complexity of the target test.

It is thus clear that performing the experimental activities in-field synergistically with the involved players would be best solution to achieve the targeted results, both for vendors/operators, academia and the TIP goals. However, these hard times of COVID-19 pandemic are pushing us towards a total or, at least, partial remotization of the experimental activities and the development of such procedures will come in handy to speed-up experimental activities even in the post-pandemic world.

In such context we can identify three main phases for the successful testing activity:

  • Identify the goal of the testing activity. Do we want to test mixed rate transceiver with open transponders? Do we want to optimize the working point of a network segment to exploit maximum capacity? Do we want to develop a model on GNPy to test network upgrades such as removal of regenerating sites or Raman amplification? …

  • Identify the available equipment in field or laboratory. Do we have enough transceivers to test that 100 zettabit per second transmission? Do we have waveshaper/noise sources to fill the spectrum? Do we have enough knowledge of the deployed fibers to carry on the test? What are the settable parameters in the amplifiers? …

  • Determine how to establish the communication channel for experimental activities remotization and automation. Is it possible for an external person to access the testing setup? What devices can be remotely operated and what requires manual in-field intervention? …

Relatively to the last point, the configuration of the remote setup should be defined case by case depending on the equipment available. However, since a figure is more effective than 100 words, let us refer to Fig.1 representing a typical use-case:

u14FSr

Basically, the smart PhD student from Politecnico di Torino needs to access the testing setup in order to:

  • Set the network elements parameters: for example, the transceiver modulation formats, the spectral allocation, gain of the amplifiers, etc.
  • Get performance metrics after propagation and/or for characterization of devices: BER, signal-to-noise ratio estimated by the transceiver, OSA traces for post processing.

To do this, a computer serving as an entry point to the setup facilities is needed. It can be from a simple computer to a fancier solution of a virtual machine running on a server. Even a simple Raspberry Pi board would be enough to the purpose. In any case, it should have the following characteristics:

  • Running Linux as OS (CentOS or ubuntu preferred).
  • At least two ethernet interfaces:
    • First is connected to the Internet for remote access, thus must have public IP address. (Blue arrow in Fig.1).
    • Second is connected to a local management network to reach the network elements management interface and the other devices as the OSA in the testing setup (green arrows in Fig.1).
  • Provides remote SSH access.
  • Configured with an externally accessible SAMBA share or local FTP server for measurements data retrieve.
  • Enabled to run Python software natively or with virtual environments (virtualenv or anaconda).

Some further comments on the requirements:

  • Setting up the management network depends on the specific possibilities of the devices. For those who have ethernet interface link them all together with a simple ethernet switch could be enough. Some OSA have these capabilities too. Some other devices, such as older VOAs, do not have ethernet but they still could be remotely used through other protocols such as GPIB interfaces connected to the entry point.
  • Some preliminary additional software writing could be needed to control the line or to correctly interface with some devices. We usually use write them in Python since in most of the cases libraries are available to the purpose.
  • As first test to check the status of the whole remote infrastructure, an external SSH access to the entry point from the WAN (i.e. outside the management network) must be successful.

Once everything is setup the experimental activity is usually carried out in three phases depending on the test target:

  • Characterization of devices performance: this mainly consist in the characterization of the BER vs OSNR performance of the transceiver, if needed. Other characterization, such as the noise figure of the optical amplifiers could be needed depending on the target.
  • Performing the measurements of interest: that are the target measurements for the testing activities.
  • Postprocessing of the obtained measurements: once more-or-less-remotely obtained, the characterization data and the target measurements results can be postprocessed and, if needed, compared to the modeling estimations such as in GNPy testing.