This document is now under reconstruction.

Up2U Deliverable 3.1

This document is revised according to recommendations of the reviewers. All requested information regarding the recommendations are reported in the introduction in Section 1 (before Subsection 1.1).

Authors:

• Tomasz Kuczyński (PSNC)

• Michał Zimniewicz (PSNC)

• Krzysztof Kurowski (PSNC)

• Bogdan Ludwiczak (PSNC)

• Dariusz Stachecki (PSNC)

• Dawid Szejnfeld (PSNC)

• Ilias Hatzakis (GRNET)

• Peter Szegedi (GÉANT)

The scope of this document is to provide a detailed analysis of the network requirements of the project and the availability of eduroam at the initial pilot schools and other locations in the schools’ neighborhood. To this end, network connectivity at the schools is examined, and an impact of the Up2U ecosystem services on the underlying network is considered.

2. Eduroam

2.1. General overview of eduroam

Eduroam (education roaming) is the secure, world-wide roaming access service developed for the international research and education community.

Having started in Europe, eduroam has gained momentum throughout the research and education community and is now available in 89 territories worldwide (https://www.eduroam.org/where/).

Eduroam allows students, researchers and staff from participating institutions to obtain Internet connectivity across campus and when visiting other participating institutions by simply opening their laptop.

High quality, security, worldwide availability in numerous places like campuses, museums, libraries, labs, public places, as well as ease of use of eduroam make it an ideal internet access supporting Always-on education concept.

2.2. Eduroam at schools

According to the results of WP5 survey, currently eduroam is not widespread at schools - only 10% (3 of 29 pilot schools who responded to the survey) of school principals declares that there is eduroam access at their school, only 1 school declared that its students can authenticate to eduroam.

Only 10% pilot school declares that eduroam is available at other locations, either near the school or that are usually visited by students of the school. According to analyses presented in Section 2.3, eduroam is available within 1 km from the 37% of the pilot schools, which clearly shows that students and teachers do not benefit from eduroam's potential. The issue could be further investigated in the scope of the Up2U project. At the first glance, it seems to be related to the weak popularisation of eduroam in the educational world, eduroam policies or legal issues rather than to the infrastructure limitations.

Therefore, the objective of the project seems to be justifiable - not to deploy eduroam at new places, but to study the current availability of eduroam and to investigate solutions that enable students to get access to the network at existing locations, that can be then covered by the formal and informal learning scenarios.

2.3. Eduroam near schools

This section contains summary on eduroam availability in the neighbourhood of the pilot schools taking part in the Up2U project. The summary is a result of comparison of information accessible in the eduroam service location database (https://monitor.eduroam.org/map_service_loc.php) with information on localisations of Up2U pilot schools supplied by the pilot countries.

Verification of possibility to incorporate the selected eduroam locations into the formal and informal learning scenarios was conducted with the pilot countries taking part in the Up2U project. Since network availability is the key to the Always-on education concept, neither formal nor informal learning scenarios could benefit from the limitation of eduroam access to some particular location types such as campuses, museums, libraries, labs, public places. Thus students and teachers should have the capability of using eduroam wherever it is available.

Analysis has proven that availability of eduroam in the neighbourhood of the pilot schools is very high. In 43% of cases, it is possible to find eduroam access within walking distance from the school (less than 1 km). Most of the pilot schools (68%) are located less than 5 km from the closest eduroam location.

An average number of eduroam location available within 20 km from the pilot school varies from country to country and can reach up to 75.14 locations.

Detailed information on eduroam availability in the neighbourhood of the pilot schools can be found in Appendix: Eduroam near schools - details.

Pilot schools, as well as eduroam availability in their neighbourhood, are depicted in the interactive map below (click the map).

2.3.1 All Up2U pilot countries

Table: Number of pilot schools within given distance from any eduroam access.

2.3.2 Up2U pilot schools by country

2.3.2.1 Greece

Number of pilot schools: 11
Average number of eduroams within distance of 20 km from the pilot school: 25.64
Table: Average number of eduroams within given distance from the pilot school.

Table: Number of pilot schools within given distance from any eduroam access.

2.3.2.2 Hungary

Number of pilot schools: 10
Average number of eduroams within distance of 20 km from the pilot school: 50.60
Table: Average number of eduroams within given distance from the pilot school.

Table: Number of pilot schools within given distance from any eduroam access.

2.3.2.3 Italy

Number of pilot schools: 19
Average number of eduroams within distance of 20 km from the pilot school: 19.79
Table: Average number of eduroams within given distance from the pilot school.

Table: Number of pilot schools within given distance from any eduroam access.

2.3.2.4 Lithuania

Number of pilot schools: 7
Average number of eduroams within distance of 20 km from the pilot school: 75.14
Table: Average number of eduroams within given distance from the pilot school.

Table: Number of pilot schools within given distance from any eduroam access.

2.3.2.5 Poland

Number of pilot schools: 18
Average number of eduroams within distance of 20 km from the pilot school: 64.44
Table: Average number of eduroams within given distance from the pilot school.

Table: Number of pilot schools within given distance from any eduroam access.

2.3.2.6 Spain

Number of pilot schools: 3
Average number of eduroams within distance of 20 km from the pilot school: 1.00
Table: Average number of eduroams within given distance from the pilot school.

Table: Number of pilot schools within given distance from any eduroam access.

1. Schools - overview on Internet connectivity

To better analyse and assess the statuses of the initial pilot schools in terms of network connectivity, surveys were conducted targeted at the schools’ principals and technical managers. The surveys were carried out as a collaborative effort between Work Packages 3, 5, 6 and 7 to collect the necessary information relevant to actions undertaken by each of these from the chosen schools.

The population of interest were schools joining an initial phase of pilot activities. At that time, it was planned to involve about 30 schools for the initial actions, in line with the assumptions from the Description of Work. The goal of this research was to be able to generalise the survey results obtained for a sample to describe the whole population, i.e. initially participating schools. The sample consisted of the set of all schools known at that stage that had been invited to join future pilot activities. This sample may eventually prove to already include the whole population of interest or, more likely, represent a majority of the final population.

The survey was conducted in the form of a questionnaire. The list of questions was prepared and reviewed in a few cycles. The questions were simple but required some technical knowledge about schools’ facilities. Most of the questions were closed-ended. The questionnaire was first tested not only by project partners but also by some of the collaborating high school teachers.

Each surveyed school was contacted directly, and in some countries face-to-face meetings were organised with school representatives to present the project to them and invite them to join the surveys and future pilots. Following these meetings, the representatives were contacted by e-mail and provided access to online questionnaires built using Google Forms. The relevant connectivity and policy questions were addressed to the schools’ principals or appointed technical managers.

29 schools responded to the schools' connectivity and policies surveys (the questionnaires were answered by a single technical representative of each of these schools) from 6 different countries (Greece, Hungary, Italy, Lithuania, Poland, and Spain). Given the project’s assumptions on the number of schools joining initial pilots, these results were found to be representative of the whole population of initial pilot schools.

The results of the Up2U schools’ surveys are presented and summarised in this section.

The survey results provide information about the environment of the schools that are most likely to be engaged in the Up2U ecosystem. Before running with the planned MVP methodology (i.e. “Minimum Viable Product”, see Section 2.1 of Deliverable 4.1), it was necessary to learn how to fit the initial viable product, i.e. a first version of the Up2U toolbox, to its first users’ needs. Therefore, these results will inform the direction of further work within both WP3 and relevant tasks of WP4 and WP7 respectively in the areas of tools development and pilots setup preparation.

1.1 Bandwidth and connection

More than half (55%) of the schools who responded in the survey access internet thanks to NRENs. The bandwidth of at least 80 Mb/s is present in 40% of schools for downstream and 30% of schools for upstream.

1.2 Internal network arrangement

Most of the initial pilot schools have an internal wired network in all (52%) or some (28%) classrooms. WiFi coverage is very high - 65% of schools who responded in the survey has 100% coverage in classrooms. Only 7% of schools declare that there is no WiFi at school at all.

1.3 Security and policies

Hardware firewalls, as well as UTM (Unified Threat Management) devices, are present in many of the initial pilot schools, although in a significant amount of answers school principals were not sure about the availability of these solutions at their schools. In all the cases of presence of an UTM device at school, the most important features like the spam filter, antivirus filter, and content filter were turned on. Only 1 of 19 schools who responded to the question concerning BYOD (bring your own device) policy disallow to use students' mobile devices at school but is willing to change policy if there is a good reason.

3. Network services requirements

One of the purposes of this document is an analysis how the ecosystem services can be speed up, or improved in terms of the availability, with the GÉANT network services. To this end in the following sections, we provide the characteristics of the network services from the GÉANT service portfolio, and outline different kinds of services to be provided within the Up2U ecosystem, especially together with Content Delivery Network concept that strongly depends on an underlying network connectivity. Then, we present how to leverage the network services for the purposes of the ecosystem, and advice on network peering requirements.

In the following paragraphs, by ecosystem services we mean the services and applications to be delivered to users by the project, as described in Section 3.2, and by network services we mean the lower-levelled Internet connectivity services, outlined in Section 3.1.

3.1. GÉANT portfolio of network services

The GÉANT pan-European backbone network offers outstanding service availability and service quality for R&E projects and entities. GÉANT IP is an IP backbone network providing high bandwidth connectivity between millions of users through NRENs. The GÉANT IP service supports both IPv4 and IPv6 natively using a dual stack routing structure. By default, there is no bandwidth or performance guarantee between any communicating pair of addresses. It has been designed to provide general purpose IP transit services between participating NRENs and other approved research and education partners. Thus, the communication between two hosts is transited over the GÉANT IP if the hosts are connected by an NREN or other such R&E provider.

More specialized network services are provided by GÉANT and its partners over the base backbone network and NRENs.

GÉANT Plus allows NRENs to request point-to-point Ethernet circuits between end-points at GÉANT PoPs (Points of Presence). GÉANT Plus is built on a common infrastructure, but appears to its private users to be dedicated to that users’ needs. The capacity of these circuits can be between 100 Mbps and 10 Gbps and potentially up to tens of Gigabits per second.

GÉANT Lambda provides transparent 10 Gbps or 100 Gbps wavelengths between GÉANT PoPs. It improves a point-to-point communication basing on a new physical connection that must be first requested and installed.

GÉANT Multi-Domain Virtual Private Network (MD-VPN) is designed to increase privacy and control over data transfers. MD-VPN enables end-computers to collaborate via a common private network infrastructure. It offers fast setups of new VPNs to clients and so can be used in a variety of ways, from a long-term infrastructure with a high demand for intensive network usage to quick point-to-point connections for a conference demonstration.

GÉANT L3-VPN provides a VPN in which each party can have an allocated bandwidth from 155 Mbps to 100 Gbps, according to its own requirements. This service allocates unique virtual local area network identifiers to each L3-VPN to ensure data isolation across the GÉANT IP, giving not only assured performance but also security of the transferred data.

GÉANT Bandwidth on Demand (BoD) is a point-to-point connectivity service for data transport that allows to reserve bandwidth on demand between the end points. The data transport capacity dedicated to a connection can range from 1 Mbps up to 10 Gbps.

It is important to say that all these specialised network services are supported by a range of network monitoring, security and support services aimed at optimising the network performance. These services work to provide seamless access to the infrastructure and enhanced monitoring to identify and remedy any incidents that disrupt the data flow and to eliminate attempts to disrupt service by maintaining high levels of network security.

3.2. Overview of the ecosystem services

One of the aims of the Up2U project is to provide an innovative ecosystem of Internet services that support learning based on formal and informal learning scenarios. The project assumes to follow the minimum viable product concept, i.e. to quickly deliver prototypes to end-users, evaluate them, and decide on the further development directions. Thus, the service ecosystem is meant to evolve during the lifetime of the project. However, at this stage we can indicate some services or kinds of services that are planned for the initial iterations of the continuous service improvement process.

The ecosystem services we currently plan to provide are:

• file-based sync and share,

• open access to rich digital multimedia content from federated learning object repositories,

• real-time communication like WebRTC-protocol-based one-to-one tutoring application,

• recording & authoring apps,

• Learning Management System (LMS), group management,

• e-notebooks, collaborative work, social apps,

• assessment of interactive learning paths supported by learning analytics, learning record store.

During the project lifetime, all the ecosystem services are going to be hosted at the infrastructure provided by some project partners: GRNET (Greece), PSNC (Poland), GWGD (Germany), and CERN (Switzerland). Up2U is going also to develop business plans and investigate appropriate business models to ensure the ecosystem to be sustainable after the end of the project and to be easily deployed at another, possibly commercial, infrastructure.

3.3. Content Delivery Network

3.3.1. The concept

The idea of Content Delivery Network (CDN) is to distribute service spatially relative to end-users to provide high availability and high performance. CDN is a geographically distributed network of proxy servers. Its main goal is to deliver content more quickly and more reliably.

Image source: www.cdnreviews.com

One of possible implementations is based on geo-located Domain Name System (DNS) service that responds to a user’s domain lookup query indicating the IP address of the proxy (edge) server that is the “nearest” for the user. Then, the user communicates with the edge server and, if the edge server has the desired content (cache), no transfer to and from the origin server is needed. Otherwise, the edge server fetches first the content from the origin server, and the first user requesting this particular piece of data waits for the response a little bit longer.

Various benefits can come from using CDN. From end-user perspective, it is an increased Quality of Experience: data download time and latency are reduced, and availability of the service is improved (if a desired data is available in an edge server then a downtime of the origin server does not prevent users to access the data). From the network perspective, CDN provides better network performance: the number of hops during the data transfers is reduced, possibility of bandwidth saturation is lowered, and the traffic in backbone network is also reduced. From the content provider perspective CDN causes lower costs: less network load and reduced possibility of service downtime.

3.3.2. Implementation for the project

The project is going to provide the eduOER Metadata Repository, which is a platform for aggregating and providing a federation of learning object metadata. The metadata is gathered from various learning object providers (content repositories) or other metadata federations. The eduOER metadata repository will be the main learning object feeder to the Up2U LMS and other future Up2U services.

We have initially gathered a set of content provider repositories, which are physically based on some infrastructures in the pilot countries but also in other european countires and even in America. The physical location of the origin content repository and end-users have an impact on access time, latency, and availability of the data for the users. The metadata of learning objects is going to be read by other ecosystem services from eduOER repository, but the actual object content is going to be fetched from a particular federated object repository. The latter process is where the CDN concept could be leveraged.

It could be useful to build a CDN which handles users’ requests for content from content repositories. Accessing large multimedia objects physically located in one country by a user from another country far away will result with the drawbacks outlined before, for instance longer download times, larger latencies, larger network load, and greater possibility of service downtime. Consider the case, that 20 students from Portugal are running the same video, physically located in a content repository in Greece, during a class. The large movie must be transferred through the backbone network 20 times - the same data is sent 20 times across the Europe and all the users wait for the transfer. If there was a CDN with an edge server in Portugal, then the content would be sent once from Greece to Portugal, it would be cached at the edge server, and the rest of the students would be served more quickly with the cached copy. Note that the benefits scale with the number of students, classrooms, and pilot schools - without a CDN all requests for such a movie would be handled by a small content provider’s server from the other end of Europe.

We currently investigate a prototype of CDN with edge servers located in London, Poznan and Athens. The first tests confirms that the physical locations of a client and a server strongly influence times of data transfers and, as a result, the network load too. More tests will be conducted with first content repositories federated with eduOER. It must be also well analyzed how to implement the CDN in order to provide the ease of adding new edge servers and new repositories in the future.

3.4. Conclusion on network services

First of all, it must be noted that the GÉANT network services can support data transfers that are sent over the GÉANT IP, i.e. between end-points connected by NRENs or selected R&E partners. The whole communication between an ecosystem service hosted at an NREN and a school connected by another NREN will be transferred through the GÉANT IP by default, and no further work is needed. However, we cannot influence routing between a host connected, for instance, by a commercial Internet Service Provider (ISP), and thus we cannot do much to support such data communications.

As presented in Section 1, some schools invited to the Up2U pilot are connected by NRENs and some are not. Moreover, the Always-on education concept assumes that young users gain access to all the work or learning applications and data anywhere, at any time and from any device they choose. Thus, we shall consider usage of the ecosystem services also from students’ homes or by mobile networks. In such cases, the GÉANT IP will not be used for transit. Apart from that, we cannot focus on NREN-connected users only because of the sustainability perspecitve, i.e. because we need to engage commercial entities to support the ecosystem infrastructure after the lifetime of the project.

The point-to-point network services (GÉANT Plus and GÉANT Lambda) cannot support communication paths between end-users and the ecosystem services, and also between two end-users (e.g. for WebRTC tutoring sessions), because of the multiplicity of the end-points and because the set of the end-points taking part in communication will dynamically change. However, the network services can be applied for static connections between some end-points that host the ecosystem, and are physically distributed among different locations. Such end-points could be an end-user service hosted in one physcial location and its required back-end service hosted in another location, if they exchange large amounts of data. For instance, if we provided an LMS service from the infrastructure in Poland and sync&storage service, being a back-end for the LMS, from the infrastructure in Switzerland, and assuming they sent heavy content between each other, then it would be beneficial to support the communication between these services with GÉANT Plus (or GÉANT Lambda, depending on particular bandwidth needs or predictions).

A communication that we can definitely improve is end-users’ access to static data. Most of the static data we deal with in the project can be found in content repositories of multimedia objects. As shown in the previous section, this is where a CDN can be successfully implemented, and the effectiveness of the CDN can be improved by the underlying network. The point-to-point network services cannot be applied for this case, because it would be then difficult and expensive to add new edge servers and set up circuits between a new server and all existing repositories. However, the VPN solutions from GÉANT portfolio could be easily used to support the CDN. If we put all the content repositories (i.e. origin servers) and the edge servers in a common MD-VPN or L3-VPN, then it will be easy and costless to quickly manage changes: adding or removing edge servers or repositories. In this case, data isolation across the GÉANT IP and even an allocated bandwidth could be ensured.

If we choose MD-VPN, as the simpler VPN solution without bandwidth allocation, to support the CDN, we shall consider to manually use GÉANT BoD when larger data transfers between some points in the CDN are expected. Such a common case could be adding new edge servers or repositories to the CDN. A new “empty” edge server can be “warmed up”, i.e. forced to fill up the cache with large amounts of data from the origin servers, to improve quality of experience for users who first request the cache for particular multimedia objects.

3.5. Network peering requirements

Network peering is an interconnection of separate Internet networks that have a physical interconnection and freely exchange routing information in order to exchange traffic between the computers of each network. Peering is distinct from transit, in which an end user or network operator pays another, usually larger, network operator to carry all their traffic for them.

The main motivation for peering is reduced cost of data transport, but there are also other: increased redundancy on communication paths, increased capacity by distributing traffic across many networks, and increased control over traffic.

The physical infrastructure, which is underneath the Up2U ecosystem, consists of the pan-European GÉANT backbone network for research and education and the public and private cloud platforms. The GÉANT Peering service ensures the cost effective network traffic exchange between commercial clouds (Amazon, Microsoft, Google, etc.) and the R&E community. GÉANT also connects all NRENs and big research centres (CERN, ESA, EMBL, SKA, etc.) in Europe and their private cloud platforms. Via the NRENs and their regional and metropolitan network peers, about 15,000 primary and 10,000 secondary schools are connected to the same pan-European network infrastructure.

GÉANT backbone network obviously focuses on connections with the R&E networks more than on peering with commercial providers. Considering the Always-on education concept promoted by Up2U and the necessary accessibility of the ecosystem from any network and device, we should monitor users' types of Internet connections during the project lifetime. Depending on the future scale and the load generated by commercial ISP users, one could decide about required changes to GÉANT network peering policy to extend peering with commercial providers.

Appendix: Eduroam near schools - details

Appendix II: Connectivity in the School Sector - GÉANT Study