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. The questionnaire was provided in English in most cases, apart from Italy, where it had been first translated to the local language. 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 170 schools that have been engaged in the project’s activities from seven out of eight countries. No schools are yet known from Germany. Some of the schools were already reported in Deliverables D7.1, D7.2, and D7.3.

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 40% of cases, it is possible to find eduroam access within walking distance from the school (less than 1 km). Most of the pilot schools (62%) 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 63.59 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 eduroams within distance of 20 km from the pilot school: 24.73
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.4.2.2 Hungary

Number of pilot schools: 10
Average number of eduroams within distance of 20 km from the pilot school: 50.70
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.4.2.3 Italy

Number of pilot schools: 41
Average number of eduroams within distance of 20 km from the pilot school: 21.85
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.4.2.4 Lithuania

Number of pilot schools: 71
Average number of eduroams within distance of 20 km from the pilot school: 46.97
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.4.2.5 Poland

Number of pilot schools: 22
Average number of eduroams within distance of 20 km from the pilot school: 63.59
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.4.2.6 Portugal

Number of pilot schools: 8
Average number of eduroams within distance of 20 km from the pilot school: 21.13
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.4.2.7 Spain

Number of pilot schools: 7
Average number of eduroams within distance of 20 km from the pilot school: 5.86
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. Overview of Internet Connectivity at Pilot Schools

To better analyse and assess the status of the initial pilot schools in terms of network connectivity and network policies, surveys were conducted. The surveys were carried out as a collaborative effort between Work Packages 3, 5 and 6 to collect, from the initially known pilot schools, the necessary information relevant to development planned in each of these Work Packages.

Please note that the goal of the general connectivity and policy questions was not to come to any conclusions that can be generalised to apply to all European schools. The results are provided 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.

Please note also that requesting information on network facilities and policies at the initial pilot schools, apart from the eduroam analysis, is a step beyond the scope of this deliverable as defined in the Description of Work. However, the survey was considered to be a good opportunity to learn about the context of the first schools planned to join project’s pilots.

This overview is based on the same surveying activity as described in Section 1.1. That survey also contained questions about network connectivity and policies. All the questions can be found in Appendix B.

The survey results obtained provide information about the environment of the schools that are most likely to be engaged in the Up2U ecosystem, and are summarised in the following sections.

2.1 Bandwidth and Connection

More than half (55%) of the schools who responded to the survey access the Internet thanks to NRENs. Bandwidth of at least 80 Mb/s is present in 41% of schools for downstream and 31% of schools for upstream.

2.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 to the survey have 100% coverage in classrooms. Finally, only 7% of schools declared that there is no WiFi at the school at all.

2.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 schools with a UTM device, the most important features, such as the spam filter, antivirus filter and content filter, were turned on. It is interesting to observe that only 1 of the 19 schools who responded to the question concerning a bring your own device (BYOD) policy does not allow students to use mobile devices at school, but it is willing to change the policy if there is a good reason.

3. Network Services Requirements

One of the purposes of this document is to analyse how the ecosystem services can be speeded up, or improved in terms of availability, with the GÉANT network services. To this end, in the following sections, we describe the characteristics of the network services in the GÉANT service portfolio, and outline the different types of services to be provided within the Up2U ecosystem, especially in relation to the Content Delivery Network concept, which strongly depends on underlying network connectivity. We then present suggestions on how to leverage the network services for the purposes of the ecosystem, and consider network peering requirements.

In the following paragraphs, by “ecosystem services” we mean the services and applications of the Up2U Application Toolbox to be delivered to users by the project, as described in Section 3.2, and by “network services” we mean the lower-level 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. The network services most relevant to the Up2U ecosystem are:

• GÉANT IP
• GÉANT Plus
• GÉANT Lambda
• GÉANT MD-VPN
• GÉANT L3-VPN
• GÉANT Bandwidth on Demand

Each of these is described below.

GÉANT IP is an IP backbone network providing high-bandwidth connectivity between millions of users through National Research and Education Networks (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 GÉANT IP if the hosts are connected by an NREN or other such R&E provider.

More specialised 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 Points of Presence (PoPs). GÉANT Plus is built on a common infrastructure, but appears to its private users to be dedicated to that user’s 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 based 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 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 bandwidth between the end points to be reserved on demand. 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 follows the “minimum viable product” approach to development, i.e. quickly delivering prototypes to end users, evaluating them, and deciding on further development directions. Thus, the service ecosystem will evolve during the lifetime of the project. However, at this stage we can indicate some of the services or types of services that are planned for the initial iterations of the continuous service improvement process. This is based on plans provided by the relevant teams of WP4, WP5, and other tasks of WP3 in terms of the tools and services they expect to integrate into Up2U.

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 such as WebRTC-protocol-based one-to-one tutoring application
• recording and 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 of the project partners: GRNET (Greece), PSNC (Poland), GWGD (Germany) and CERN (Switzerland). Up2U is also going to develop business plans and investigate appropriate business models to ensure the ecosystem is sustainable after the end of the project and can be easily deployed at another, possibly commercial, infrastructure.

3.3. Content Delivery Network

3.3.1. The Concept

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

One of the possible implementations is based on a 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 original server is needed. Otherwise, the edge server first fetches the content from the original server, and the first user requesting this particular piece of data waits for the response a little bit longer.

Using a CDN offers various benefits. From the end-user perspective, it provides an improved quality of experience: data download time and latency are reduced, and availability of the service is improved (if the desired data is available in an edge server, then any downtime of the original server does not prevent users from accessing the data). From the network perspective, a CDN provides better network performance: the number of hops during the data transfers is reduced, the possibility of bandwidth saturation is lowered, and traffic in the backbone network is also reduced. From the content provider perspective, a CDN results in lower costs, as there is less network load and a reduced possibility of service downtime.

3.3.2. Implementation for the Project

As part of the Up2U ecosystem, 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 gathered an initial set of content provider repositories, which are physically based on some infrastructures in the pilot countries but also in other European countries and even in America. The physical locations of the origin content repository and of the 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 the 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 beneficial to build a CDN that handles users’ requests for content from content repositories. Accessing large multimedia objects physically located in one country by a user in another country far away will result in the drawbacks outlined above, for instance, longer download times, larger latencies, greater network load, and increased 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 video file must be transferred through the backbone network 20 times – the same data is sent across Europe 20 times and all 20 users have to 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 19 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 video would be handled by a small content provider’s server from the other end of Europe. The overall technical architecture of the eduOER and CDN integration is presented in the Figure below.

We are currently investigating a prototype CDN with edge servers located in London, Poznan and Athens. The preliminary tests confirm that the physical locations of a client and a server strongly influence the data transfer times and, as a result, the network load too. More tests will be conducted with the first content repositories federated with eduOER. We will also analyse how to implement the CDN to ensure it is easy to add new edge servers and new repositories in the future.

3.4. Conclusions on Network Services

First of all, it must be noted that the GÉANT network services can support data transfers that are sent over 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 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 2, 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 will also consider usage of the ecosystem services from students’ homes or by mobile networks. In such cases, GÉANT IP will not be used for transit. In addition, we cannot focus only on NREN-connected users because of the sustainability perspective, 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 end points taking part in communication will dynamically change. However, the point-to-point 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 physical 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 a sync and 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 then be 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 the 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 low cost to quickly manage changes: adding or removing edge servers or repositories. In this case, data isolation across 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 manually using GÉANT BoD when larger data transfers between certain 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 others: 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.

The 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, decisions can be made about whether to change GÉANT’s network peering policy to extend peering with commercial providers.

Appendix A: eduroam near Schools

Appendix: eduroam near Schools – Details

Appendix B: Survey Questions

1. How is your school connected to the Internet?
   1. via NREN
   2. via a commercial provider
   3. other (please specify)
2. Please indicate the total internet bandwidth in your school for downloading
   1. Less than 5 Mb / s
   2. Up to 10 Mb / s
   3. Up to 20 Mb / s
   4. Up to 40 Mb / s
   5. Up to 80 Mb / s
   6. Up to 160 Mb / s
   7. Over 160 Mb / s
3. Please indicate the total internet bandwidth in your school for uploading
   1. Less than 5 Mb / s
   2. Up to 10 Mb / s
   3. Up to 20 Mb / s
   4. Up to 40 Mb / s
   5. Up to 80 Mb / s
   6. Up to 160 Mb / s
   7. Above 160 Mb / s
4. What is the arrangement of the internal cable network (Ethernet) in your school
   1. The school does not have a cable network
   2. The school has a link cable only in some rooms are not being used in the classroom
   3. The school has a link cable in some classrooms
   4. The school has a cable connection in all classrooms
5. Do you have WiFi network at your school?
   1. Yes, and it's freely accesible for students in all classes
   2. Yes, but it isn't freely accesible for students in all classes
   3. No
6. What is the coverage of the WiFi network in your school?
   1. 100% of the school
   2. 100% of the classrooms, but not 100% of the school
   3. other (please specify)
7. Is eduroam available at your school?
   1. Yes
   2. No
8. Is eduroam available at other locations, either near your school or that are usually visited by your students?
   1. Yes
   2. No
9. Which are these locations?
   1. Public library
   2. Private library
   3. Youth centers
   4. other (please specify)
10. Are your students able to authenticate to eduroam?
    1. Yes
    2. No
11. How? (please specify)
12. Can students connect their private devices to the Internet at school:
    1. During the lessons in the manner specified by the teacher
    2. Besides school classes to a limited extent (eg. Only to have access to local educational materials)
    3. Besides school classes in any way
13. Is your school using an hardware firewall?
    1. Yes
    2. No
    3. I don’t know
14. Is your school using a UTM device (Unified threat management) - a multi-firewall?
    1. Yes
    2. No
    3. I don’t know
15. Which are the functions of your UTM?
    1. spam filter: Yes – No – I don’t know
    2. anti-virus filter: Yes – No – I don’t know
    3. intrusion detection: Yes – No – I don’t know
    4. content filtering: Yes – No – I don’t know
    5. other (please specify)

Glossary

BoD            Bandwidth on Demand

BYOD        Bring Your Own Device

CDN           Content Delivery Network

CERN        Conseil Européen pour la Recherche Nucléaire / European Organisation for Nuclear Research

DNS           Domain Name System

DoW           Description of Work

eduroam     education roaming

EMBL         European Molecular Biology Laboratory

ESA           European Space Agency

IP               Internet Protocol

ISP             Internet Service Provider

L3-VPN      Layer 3 Virtual Private Network

LMS           Learning Management System

MD-VPN    Multi-Domain Virtual Private Network

NREN        National Research and Education Network

OER           Open Educational Resources

PoP            Point of Presence

R&E           Research and Education

SKA           Square Kilometre Array

T                 Task

T3.1            Task 3.1, Network Services and Access

UTM           Unified Threat Management

VPN           Virtual Private Network

WebRTC    Web-based Real-Time Communication

WP             Work Package

WP3           Work Package 3, Cloud-Based Infrastructure Services

WP4           Work Package 4, Integrated Application Toolbox

WP5           Work Package 5, Learning Community Management and Skills Training

WP6           Work Package 6, Roadmap for Security and Trust

WP7           Work Package 7, Pilot Coordination and Continuous Risk Assessment