This document is now under reconstruction.

Up2U Deliverable D3.1

Table of Contents

Executive Summary

The scope of this deliverable is to provide a detailed analysis of the network services requirements of the Up2U project and the availability of eduroam at the initial pilot schools and other locations. Its main focus is to report on the work carried out in the first six months of the project by Task 3.1, Network Services and Access, of Work Package 3, Cloud-Based Infrastructure Services (WP3). However, as it is an online document, it also contains updates that reflect the subsequent progress of the project, especially in terms of newly identified pilot schools as well as updates on eduroam access related to eduroam network development.

To analyse the network services requirements of the project, the portfolio of GÉANT network services is first presented. An overview of the ecosystem services, i.e. the services expected to constitute the Up2U Application Toolbox, is then provided. This overview is based on plans provided by the relevant teams of WP3, Work Package 4, Integrated Application Toolbox (WP4), and Work Package 5, Learning Community Management and Skills Training (WP5), in terms of the tools and services they expect to integrate into Up2U. Suggestions are given on how services such as a Content Delivery Network (CDN), Virtual Private Network (VPN), and point-to-point network services could be leveraged by the project and Toolbox services. For the CDN, a prototype for the project is being investigated. The possible need to review GÉANT’s network peering policy, depending on the project’s future evolution, to extend peering with commercial providers, is also discussed. In the future, these outcomes are to be used by WP3, WP4, and Work Package 7, Pilot Coordination and Continuous Risk Assessment (WP7), for efficient usage of the underlying network when developing and hosting Toolbox services.

The availability of eduroam at the initial pilot schools has been studied by conducting a survey. Of the 53 initial pilot schools, 29 responded to the network survey. The eduroam network is available at three of them, all in Lithuania, but students of only one of these schools are able to authenticate and connect to eduroam networks. The status of eduroam accessibility at high schools based on data from outside of the project is studied and presented. Status and development in this area is highly country specific. No high school students are able to authenticate to eduroam in some countries, while more than one thousand schools provide this capability for students in Croatia and Hungary. Common country-specific problems are identified for further studies as part of the scope of Task 3.1. The main obstacles to implementation of eduroam in schools are proper incentives and sustainable funding schemes for schools or NRENs.

The availability of eduroam in other locations planned to be covered by the formal and informal learning scenarios is also studied. As information on the general availability of eduroam is publicly accessible, this deliverable reports on places located in the neighbourhood of the pilot schools. The high availability of eduroam near all the schools leads to the conclusion that the issue of providing eduroam access to students is still relevant to supporting “always-on” education. The continuously updated data on eduroam within this deliverable is designed to be useful for the pilot schools in the future, as Task 3.1 progresses. A study of selected categories of eduroam locations, based on public data, is also provided; it shows rather poor availability of eduroam at museums or public libraries.

In addition to the questions about eduroam, the initial pilot schools have been asked to provide feedback on other network facilities and policies at their locations, which is a step beyond the scope of this deliverable as defined in the Description of Work. The obtained results are provided only to enable the consortium to solve a chicken-egg problem, i.e. learn first about the context of the initial pilot schools and, based on that, create the first version of the Toolbox with first use cases, to update them later based on feedback from pilots.

The analysis of the availability of eduroam at the pilot schools and other locations is presented in Section 1. Section 2 provides an overview of Internet connectivity in the initially known pilot schools. Section 3 reports on the analysis of the network services requirements of the project. As all these are distinct topics, relevant conclusions and future steps are described separately, in the respective section, rather than at the end of the document.

1. eduroam at Pilot Schools and Other Locations

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 90 territories worldwide (https://www.eduroam.org/where/).

In a nutshell, 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 locations such as campuses, museums, libraries, labs and public places, as well as ease of use, make eduroam an ideal Internet access service supporting the concept of “always-on” education.

Information on all eduroam locations around the world is publicly available, and can be investigated at https://monitor.eduroam.org/map_service_loc.php.

One of the future objectives of WP3 is to investigate and test existing solutions that enable high school students without eduroam credentials to get access to the network in existing eduroam locations. To achieve this goal, we start with an analysis of the availability of eduroam at high schools and other locations, to learn about the current status and identify the best way for Up2U to contribute in the future. Please also note that the future goal of WP3 is not to deploy eduroam at any new locations but to identify solutions to provide access leveraging already-existing locations.

1.1. Survey Design

The availability of eduroam at the initially known pilot candidate schools has been investigated by conducting a survey of these schools. It should be emphasised that coming to any conclusions that can be generalised to apply to most European schools was not the goal of the survey. However, we have extended the analysis beyond the initially known schools by investigating existing data on eduroam from outside of the project, as reported in Section 1.3.

The population of interest in the survey, i.e. the set of schools we wanted to learn about, were only those schools that had confirmed their interest in joining the project’s activities, i.e. the pilot candidate schools, as this is the task described in the Description of Work (DoW). In June 2017, 53 schools were engaged for initial project activities. They were from six countries: Greece, Hungary, Italy, Lithuania, Poland, and Spain, and they are reported in Deliverable D7.1 Initial Pilot Architecture, Software Component Integration, and Deployment (50 schools are reported in D7.1, and three other schools were engaged by project partner KTU soon after the release of D7.1).

The survey was conducted in the form of a questionnaire. It was a joint questionnaire, based on questions prepared by WP3, WP5 and Work Package 6, Roadmap for Security and Trust (WP6). Information on WP5 and WP6 questions can be found in Deliverable D5.2 Interaction Model Design and Deliverable D6.1 Study of Security, Privacy, Identity Management and Legal Requirements in the Digital Schools’ Environment Using a Cloud-Based Approach.

The WP3 questions asked in the survey were about eduroam, which is considered in this Section 1, and also about network connectivity and policy at schools, which is discussed in Section 2. From February to April 2017, the WP3 questions were prepared and reviewed by project partners in several iterative cycles. The questionnaire was also tested by some of the high school teachers collaborating with project partners. The questions were straightforward but required some technical knowledge about the schools’ facilities. Most of the questions were closed-ended. All the WP3 questions asked in the survey are reported in Appendix B.

From May to June 2017, the survey was sent to all the 53 pilot candidate schools. 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 in person to join the surveys and future pilots. Those meetings are reported in Deliverable D2.2 Dissemination and Outreach Report Year 1, as part of the local dissemination activity undertaken in the first year of the project, but also in Section 3.2 of Deliverable D7.2 Report on the First Release and Demonstration of Scalable Pilot Services, which describes the development of country-specific approaches in the engagement of pilot schools.

Following these meetings, school representatives were contacted by email and provided with access to online questionnaires built using Google Forms. The WP3 questions were addressed to the schools’ principals or appointed technical managers, i.e. one person with appropriate technical knowledge per school.

Twenty-nine schools from all six countries responded to the eduroam, connectivity and policy questions. The numbers of responding schools per country are as follows:

The goal of this survey research was to be able to generalise the survey results obtained for a sample, i.e. eventually 29 schools, to describe the whole population, which is 53 initially known pilot schools. Results collected from the sample of more than half of the whole population, including roughly equal responsiveness from particular countries, are considered to be representative of the whole population of interest. Only a low level of responsiveness from Hungary, where one of seven schools responded to the survey, might be thought to potentially lead us to wrong conclusions. However, as presented in Section 1.3, Hungary is very well-advanced in terms of eduroam at schools.

The reason that some schools have not responded seems to be the lack of people with appropriate knowledge to answer the technical questions at that time and also bad time chosen for conducting the survey, as it was the end of a school year in most countries.

1.2. Data from Pilot Schools

According to the results of the survey, eduroam is not widespread at the project’s pilot schools. Only around 10%, i.e. 3 of the 29 pilot schools that responded to the survey, declared that there is eduroam access at their school, but only one school declared that its students are able to authenticate to eduroam networks. All the three schools are from Lithuania, and the one school whose students are able to authenticate reported that they do so based on solutions implemented by LITNET (Lithuanian NREN).

Only 10% of the pilot schools that responded declared that eduroam is available at other locations, either near the school or that are usually visited by the school’s students. According to analyses presented in Section 1.4.2, eduroam is available within 1 km from 43% of the pilot schools that responded, which clearly shows that students and teachers do not benefit from eduroam’s potential. The figure of 43% is based on an updated list of pilot schools and eduroam locations in the second half of 2018; the figure was 37% when it was based on schools and eduroam locations known in June 2017.

We are aware that these results cannot be generalised to all European schools but, as mentioned above, that was not the goal of the survey. However, in the next section, we compare these results with existing data from outside of the project.

This activity aimed at obtaining an overview of the initial pilot schools, and it can be considered successful, as the pilot countries are equally represented in the sample. As shown in the next section, the reported eduroam availability would probably have been higher if more Hungarian schools responded to the survey.

1.3. Existing Data on Schools

To provide an overview of eduroam accessibility at schools throughout Europe, this section provides an analysis based on existing data from outside of the project. The general availability of all eduroam locations in the world is publicly known; however, there is no simply available information that indicates how many of these locations are high schools.

For the existing data, we have relied on a GÉANT activity aimed at collecting such information through questionnaires sent to NRENs in 2017, as reported in the document “Connectivity in the School Sector: NREN Survey Results for Access and Connectivity of Schools in Europe”.

However, only 12 countries responded to the GÉANT survey. To provide a wider European overview, in 2018, we have investigated the statuses of other countries by contacting project partners and also through partnerships with institutions from other countries that are not taking part in the Up2U project. Eventually, 17 countries have been considered in this analysis.

The results of the collected information on the availability of eduroam in European schools and known problems in this field are presented below.

The leaders with regard to promoting and implementing eduroam at high schools are Croatia and Hungary, in which more than one thousand schools provide eduroam networks. The two countries also reported that implementations were possible because of funding received for building or renewing IT infrastructure at schools.

By contrast, 7 countries have no schools that provide eduroam networks. In many countries, tens of schools are reported as having eduroam, so the situation may relate to whether and how far the relevant NRENs promote eduroam to schools. In addition, GÉANT’s report indicates that all NRENs that already provide eduroam plan to increase the number of schools using eduroam over the next two years (starting in 2017). This is very promising regarding the future plans of Task 3.1.

This investigation enabled us also to learn about common problems encountered by NRENs in implementing eduroam at schools. First of all, eduroam originally started as a service for universities and research institutions, and there is no common agreement about whether to engage high schools in the same eduroam infrastructure. There is an opportunity for the Up2U project, as part of its scope, to facilitate agreement on such a general strategy.

Further major issues, as reported by NRENs, are the following:

• Incentives and funding – Additional effort is needed for schools and NRENs to implement eduroam, so proper incentives and funding for them are required. Funding was provided in the two most effective countries, i.e. Croatia and Hungary, so this issue should be considered as the main one.
• Network access policies and content filtering policies – In some countries, high schools are legally forced to provide content filtering mechanisms for students accessing the Internet, so eduroam policies should be somehow aligned with such measures.
• Building identity providers for students – This is an obstacle for many countries, in which no solutions or standards exist for authentication of high school students. Moreover, the General Data Protection Regulation does not make it easy to properly implement such solutions on a larger scale.

Comparing the Up2U survey results, reported in Section 1.2, with this data, it is clear that the status at Up2U pilot schools cannot be generalised to all European schools. The scale of the Up2U pilot schools is too small at this stage of the project. In addition, status and development in this area is highly country specific, dependent on each country’s particular needs and regulations, and only a few European countries are pilot countries for the Up2U project.

The low prevalence of eduroam in the high school environment seems to be related rather to funding, policies or legal issues rather than to infrastructure limitations. These issues, and also country-specific problems, should be further investigated as part of the scope of the Up2U project, within the activities of Task 3.1, to define and agree some general approaches that could be widely adopted to enable students to use eduroam at existing locations.

1.4. eduroam at Other Locations

The scope of this deliverable includes studying the availability of eduroam at locations other than schools, planned to be covered by the formal and informal learning scenarios. Easy network access for students in such places where learning happens would strongly support the concept of always-on education. This analysis is focused on all the pilot countries considered by the project (which are to be: Germany, Greece, Hungary, Italy, Lithuania, Poland, Portugal, Spain), because learning scenarios developed by the project, and also enabling students to use eduroam, are to be tested in these countries within the project’s lifetime.

Our contribution to this subject is two-fold. Section 1.4.1 provides an overview of selected types of eduroam locations available in the pilot countries. Section 1.4.2 provides detailed data on the nearest eduroam locations for the Up2U pilot schools; this data is continuously updated as the set of pilot schools increases and also the availability of eduroam changes.

1.4.1. Locations by Category

According to UNESCO’s International Standard Classification of Education, informal learning is forms of learning that are intentional or deliberate but are not institutionalised and are therefore less organised and structured than either formal or non-formal education. It may include learning activities that occur in the family, workplace, local community and daily life. Thus it can happen anywhere and at any time. There is no simple way to limit the categories of locations in which informal learning takes place. Moreover, WP5 has not identified any specific types of locations that are more important, from the perspective of learning scenarios, than others, at least until now. Because of that, it has not been crucial, in the analysis of eduroam, to divide eduroam locations into different categories.

eduroam locations can be of various types, including museums, libraries, labs and public places. Field trips to museums are particularly given as an example informal learning scenario in the DoW. Moreover, the survey described in Section 1.1 also asked schools about the availability of eduroam at other locations near the schools; the answers obtained reported only on libraries as such locations (three schools from Lithuania pointed them out). Such poor information on this is probably because of lack of knowledge, as in fact, many locations are available near most of the pilot schools (see the next section).

The central publicly available eduroam database contains lists of eduroam locations from all countries. There are more than 7,000 locations in total in the eight pilot countries. For each location, its name, either in English or in a national language, and address are provided. However, there is no categorisation of such locations, so it is not easy to provide a clear answer on how many locations of a particular type are available.

As no official categorisation is available, our contribution is analysis based on the names of eduroam locations available in the pilot countries. By checking the names of locations in the database, we have classified them as libraries or museums, as these are the two categories considered so far in the project. We are aware of accuracy issues with this approach, as in some cases this shallow analysis of particular locations may not provide enough information for such categorisation. Possible measurement error is, however, acceptable to get a general overview of the availability of such locations among the pilot countries.

The results of this analysis of existing eduroam locations is provided below.

This analysis shows rather poor general eduroam availability in the selected categories of locations. The cause of that is probably that eduroam originally started as a service for universities and research institutions, and there is still no common and international agreement about whether to engage other types of locations and, if so, which. However, we assume that the development of eduroam networks in other locations will advance, in parallel with the planned development in schools identified in the GÉANT survey.

Please also note that a location’s exact type is not of particular relevance to the scope of Task 3.1. The future work aimed at enabling students to use eduroam at existing locations can still proceed. Provided that high school students have an out-of-the-box authentication mechanism, to be investigated by WP3 and WP6, they would easily be able to join eduroam networks whenever and wherever they find them.

1.4.2. Locations near Pilot Schools

This section contains a summary of eduroam availability in the neighbourhood of the pilot schools taking part in the Up2U project. The summary is a result of comparing information in the eduroam service location database with the locations of the pilot schools.

As this deliverable is a Wiki page, the information it provides is continuously updated information in line with the growing number of pilot schools and the appearance of new eduroam locations. It can serve as a useful resource for project partners and, especially, Task 3.1 for their further investigations, but also directly for teachers at the pilot schools, whose students will be eduroam enabled within the project’s lifetime.

The current version of this deliverable includes all 68 schools that have been engaged in the project’s activities from six out of eight countries. No schools are yet known from Germany and Portugal. The schools are all reported in Deliverable D7.1 and Deliverable. D7.2. Please note that some schools appear in both the deliverables, and some appear in just one of them (see Section 3.2 of Deliverable D7.2 for information on the evolution of the lists of pilot schools). In this analysis, all such identified schools are considered.

Since network availability is the key to the always-on education concept, neither formal nor informal learning scenarios would benefit from the limitation of eduroam access to particular location types such as campuses, museums, libraries, labs or public places. Thus students and teachers should have the capability to use eduroam wherever it is available. This analysis therefore provides information on all available locations near the schools.

Analysis has shown 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.

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

Therefore, the objective of the project seems to be feasible, i.e. not to deploy eduroam at new locations, 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 then be covered by the formal and informal learning scenarios.

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

The pilot schools, as well as eduroam availability in their neighbourhood, are depicted in the interactive map below (click the map). Please note that it is focused on the currently known pilot schools only, as more general information on all eduroam locations is already publicly accessible.

The data by country is presented in the following sections.

1.4.2.1 Greece

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

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

1.4.2.2 Hungary

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

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

1.4.2.3 Italy

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

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

1.4.2.4 Lithuania

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

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

1.4.2.5 Poland

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

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

1.4.2.6 Spain

Number of pilot schools: 3
Average number of eduroam locations within distance of 20 km from the pilot school: 1.00
Table: Average number of eduroam locations 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