d4.1 virtualization of satcom components analysis, design and … · 2020-06-08 · sat5g (761413)...

SaT5G (761413) D4.1 DEC 2019

of 75

D4.1

Virtualization of Satcom Components –

Analysis, Design and Proof of Concepts

Topic ICT-07-2017

Project Title Satellite and Terrestrial Network for 5G

Project Number 761413

Project Acronym SaT5G

Contractual Delivery Date Dec ’19 (M31)

Actual Delivery Date TBD

Contributing WP WP4.1

Project Start Date 01/06/2017

Project Duration 33 months

Dissemination Level PU

Editor iDR

Contributors TAS, UoS, SES, ADS, OA, GLT, i2CAT

Satellite and Terrestrial

Network for 5G

SaT5G (761413) D4.1 DEC 2019

of 75

Document History

Version Date Modifications Source

00.01 16/10/18 First draft created using project document template iDirect

00.02 18/10/18 Table of Contents and placeholder content added iDirect

00.03 23/10/18 Updated ToC with additional sections iDirect

00.04 24/10/18 Rework of document, following review on 23/10/18 iDirect

00.05 29/11/18 Interim Deliverable iDirect

1.0 09/10/19 Rework and update of Section 6 iDirect





1.5 5/12/19 Integration of ZII content ZII, iDirect

1.6 5/12/19 Rework following internal high-level review iDirect

1.7 06/12/19 Updates following high-level review by AVA iDirect

1.8 06/12/19 General clean-up iDirect

1.9 13/12/19 Rework and update of sections 1-9 iDirect

1.10 15/12/19 Section 8 added iDirect

1.11 16/12/19 Section 7.3 added ZII

1.12 16/12/19 Section 4.5.2 added ZII

1.13 16/12/19 Amendments to Execute Summary and Section 9 ZII

1.14 17/12/19 Pre-final review copy iDirect

1.15 18/12/19 Rework following reviews by UoS, AVA, SES, and additional clean up. First draft of Section 9.1. Draft MP QUIC content added to Section 3.2.3

iDirect

1.16 19/12/19 Additional rework following review. Final clean up. iDirect

1.17 20/12/19 Final version. iDirect

SaT5G (761413) D4.1 DEC 2019

of 75

Contributors

Name Organisation Contributions include

Mark Kavanagh iDR Co-editor, Executive Summary, Sections 1-7, 9, 10

Joe Cahill iDR Co-editor, Executive Summary, Sections 2, 3, 4, 6, 8, 9

Leonardo Goratti ZII Executive Summary, 3.3, 5.2

Menachem Dodge GLT 4.5.2

Satish Kumar UoS Figure 3-10

Alain-Pierre Brunel BPK Figure 3-11

Yann Begassat BPK Figure 3-11

Thierry Masson OA Figure 3-12

Mamoutou Diarra OA Figure 3-12

Prof. Mike Fitch UoS Document review

Dr. Konstantinos Liolis SES Document review

Simon Watts AVA Document review

Boris Tiomela Jou ADS Document review

Yogaratnam Rahulan UoS Document review

SaT5G (761413) D4.1 DEC 2019

of 75

Table of Contents

List of Figures ................................................................................................................................................... 6

List of Tables .................................................................................................................................................... 7

List of Abbreviations ......................................................................................................................................... 8

Executive Summary ........................................................................................................................................ 11

1 Introduction ........................................................................................................................................... 13

1.1 Document Context ......................................................................................................................... 13

1.2 Relationship to other Work Packages ............................................................................................. 13

1.3 Document Organisation ................................................................................................................. 14

2 Summary of Innovations and Achievements ............................................................................................ 16

3 Network Architectures ............................................................................................................................ 18

3.1 Overview ....................................................................................................................................... 18

3.2 Selected Architectures for 5GIC Testbed ........................................................................................ 20

3.2.1 Overview ................................................................................................................................... 20

3.2.2 Satellite Network Architecture ................................................................................................... 21

3.2.3 E2E Network Architecture.......................................................................................................... 24

3.3 Selected Architectures for ZII Testbed ............................................................................................ 27

3.3.1 Overview ................................................................................................................................... 27

3.3.2 Satellite Network Architecture ................................................................................................... 28

4 Virtualization of Satcom Elements ........................................................................................................... 30

4.1 Overview ....................................................................................................................................... 30

4.2 ETSI NFV Architectural Framework ................................................................................................. 30

4.3 Recap of Satcom Elements ............................................................................................................. 31

4.3.1 Satellite Remote ........................................................................................................................ 31

4.3.2 Satellite Teleport ....................................................................................................................... 32

4.3.3 Satellite Radio Access Network (SatRAN) ................................................................................... 32

4.4 Satcom Virtualization – what can be virtualized? ............................................................................ 32

4.5 Implementation of Satcom Virtualization ....................................................................................... 33

4.5.1 5GIC Testbed ............................................................................................................................. 33

4.5.2 ZII Testbed................................................................................................................................. 36

5 Implementation of Satellite SDN & Orchestration in Testbeds ................................................................. 38

5.1.1 Selected Virtual Infrastructure Manager - OpenStack ................................................................. 38

5.1.2 Evaluation of OpenStack as a VIM for Software-Defined Satellite Networks................................ 39

5.1.3 Selected Orchestrator - Open Source Mano (OSM)..................................................................... 42

5.1.4 Satellite Network Service, VNF and Infrastructure Description – OSM ........................................ 42

5.1.5 Summary of SDN & Orchestration in 5GIC Testbed ..................................................................... 43

5.2 ZII Testbed ..................................................................................................................................... 44

6 Model Driven Architecture and Satellite Service-Level API ....................................................................... 47

6.1 Evolution of the Data Model .......................................................................................................... 47

SaT5G (761413) D4.1 DEC 2019

of 75

6.2 Overview of Satellite Services ........................................................................................................ 47

6.3 Satellite Service API Architecture ................................................................................................... 48

6.4 Reference Implementations of Differentiated Satellite Services...................................................... 48

6.5 Reference invocations of Satellite Service API ................................................................................ 50

6.5.1 Query the details of the Gold-level Satellite Service ................................................................... 50

6.5.2 Activate the Gold-level Satellite Service ..................................................................................... 50

7 Proof of Concepts for WP5 Testbeds ....................................................................................................... 52

7.1 Overview ....................................................................................................................................... 52

7.2 5GIC Testbed ................................................................................................................................. 52

7.2.1 Prototype Integrated Satellite/3GPP Network ............................................................................ 53

7.2.2 EuCNC 2018 Demonstrations ..................................................................................................... 54

7.2.3 EuCNC 2019 Demonstrations ..................................................................................................... 57

7.2.4 SaT5G Industry Day ................................................................................................................... 59

7.2.5 Final Architecture ...................................................................................................................... 62

7.3 ZII Testbed ..................................................................................................................................... 63

8 Standards ............................................................................................................................................... 69

8.1 Standards Adoption ....................................................................................................................... 69

8.2 Key Issues for Standardisation........................................................................................................ 70

9 Conclusions ............................................................................................................................................ 71

9.1 Summary of Findings ..................................................................................................................... 71

9.2 Recommendations for Future Work ............................................................................................... 71

9.2.1 Enhanced 5G core network integration ...................................................................................... 71

9.2.2 Single 5G core network for the Satellite and Terrestrial networks .............................................. 71

9.2.3 Toward multi-constellation 5G satellite connectivity .................................................................. 72

9.2.4 Leveraging 3GPP eco-system ..................................................................................................... 72

9.2.5 Advancement of Satellite Service API ......................................................................................... 73

10 References......................................................................................................................................... 75

SaT5G (761413) D4.1 DEC 2019

of 75

List of Figures

Figure 1-1: Interaction between WP4.1 and other WPx ................................................................................... 14 Figure 3-1: Satellite positioning within 5G network ......................................................................................... 18 Figure 3-2: Implementation options considered in SaT5G................................................................................ 19 Figure 3-3: 5GIC Testbed ................................................................................................................................ 20 Figure 3-4: 5G access agnostic ........................................................................................................................ 21 Figure 3-5: Introduction of 5G core network to satellite network .................................................................... 22 Figure 3-6: Satellite network providing connection between 5G core and RAN ................................................ 23 Figure 3-7: Relay Node based on Trusted Non-3GPP Access ............................................................................ 23 Figure 3-8: Scenario A3 - Indirect mixed 3GPP NTN access with bent-pipe payload .......................................... 24 Figure 3-9: Satellite network providing connection between 5G core and RAN ................................................ 24 Figure 3-10: System Overview of satellite and terrestrial Network SaT5G ........................................................ 25 Figure 3-11: mABR Content Delivery via Satellite Multicast ............................................................................. 25 Figure 3-12: Standard 5G UE leveraging a 5G hybrid backhaul ......................................................................... 26 Figure 3-13: ZII test-bed physical infrastructure .............................................................................................. 28 Figure 4-1: ETSI NFV reference architectural framework ................................................................................ 30 Figure 4-2: High-Level Satellite Network Architecture ..................................................................................... 31 Figure 4-3: Satcom components deployed on dedicated hardware.................................................................. 34 Figure 4-4: Consolidation of sample virtualized Satcom functions on single physical server ............................. 35 Figure 4-5: Zodiac testbed ............................................................................................................................. 36 Figure 4-6: OpenStack overview page ............................................................................................................. 36 Figure 4-7: VNF Packages ............................................................................................................................... 37 Figure 4-8: TALENT packages .......................................................................................................................... 37 Figure 5-1: ETSI NFV reference architectural framework ................................................................................ 38 Figure 5-2: OpenStack logical architecture ..................................................................................................... 39 Figure 5-3: Horizon: OpenStack Web User Interface (WUI) .............................................................................. 41 Figure 5-4: lack of capability for port IP modification in Horizon ...................................................................... 41 Figure 5-5: port IP assignment and modification in OpenStack CLI ................................................................... 42 Figure 5-6: 5GIC Testbed Architecture pre-VM migration ................................................................................ 43 Figure 5-7: ZII test-bed virtualized infrastructure ............................................................................................ 44 Figure 5-8: TALENT, OSM dashboards ............................................................................................................. 45 Figure 6-1: Satellite Service API Draft Architecture .......................................................................................... 48 Figure 7-1: iDirect Prototype Integrated Satellite/3GPP Network .................................................................... 53 Figure 7-2: SaT5G EuCNC 2018 Demo Architecture ......................................................................................... 55 Figure 7-3: SaT5G EuCNC 2019 Demo Architecture ......................................................................................... 57 Figure 7-4: SaT5G Industry Day Demo Architecture ......................................................................................... 60 Figure 7-5: Satellite VNF positioning, prior to VM migration ............................................................................ 60 Figure 7-6: Satellite VNF positioning, post VM migration ................................................................................. 61 Figure 7-7: Aero 5G testbed based on GEO satellite connectivity ..................................................................... 64 Figure 7-8: Aero 5G testbed based on MEO satellite connectivity .................................................................... 66 Figure 8-1: Scenario A3 - Indirect mixed 3GPP NTN access .............................................................................. 69 Figure 9-1: Single core network for Satellite and Mobile networks .................................................................. 72 Figure 9-2: Snapshot of ZSM members ........................................................................................................... 73 Figure 9-3: LSO Reference Architecture .......................................................................................................... 74

SaT5G (761413) D4.1 DEC 2019

of 75

List of Tables

Table 2-1: Summary of innovations and achievements .................................................................................... 16 Table 4-1: Opportunities for Satcom virtualization .......................................................................................... 32 Table 5-1: Summary of 5GIC Testbed Satellite SDN and Orchestration ............................................................. 43 Table 6-1: Sample Implementation of Differentiated Satellite Services ............................................................ 49 Table 7-1: 5GIC Testbed Satellite Increments .................................................................................................. 52 Table 7-2: List of EuCNC 2018 Demo Elements ................................................................................................ 55 Table 7-3: List of EuCNC 2019 Demo Elements ................................................................................................ 58 Table 7-4: List of Industry Day Demo Elements ............................................................................................... 61 Table 7-5: List of Zodiac GEO Demo Elements ................................................................................................. 64 Table 7-6: List of Zodiac MEO Demo Elements ................................................................................................ 66

SaT5G (761413) D4.1 DEC 2019

of 75

List of Abbreviations

The following acronyms and abbreviations are relevant within the context of this document.

3GPP 3rd Generation Partnership Project

5GCN 5th Generation Core Network

5GIC 5th Generation Innovation Centre

ADS Airbus Defence and Space

AMF Access and Mobility Management Function

API Application Programming Interface

BSS Business Support System

Capex Capital Expenditure

CIR Committed Information Rate

CMAF Common Media Application Format

CN Core Network

COTS Commercial Off-The-Shelf

CTE Chunked Transfer Encoding

DASH Dynamic Adaptive Streaming over HTTP

E2E End-to-End

eMBB Enhanced Mobile Broadband

EMS Element Management System

eNB eNodeB

ETSI European Telecommunications Standards Institute

EuCNC European Conference on Networks and Communications

FCAPS Fault, Configuration, Accounting, Performance, Security

GLT Gilat Satellite Networks

gNB next generation NodeB

i2CAT Fundacio Privada i2CAT Internet I Innovacio Digital A Catalunya

iDR VT iDirect Solutions Ltd.

IaaS Infrastructure as a Service

IoT Internet of Things

KVM Kernel Virtual Machine

L2TP Layer 2 Tunnelling Protocol

LTE Long Term Evolution (i.e. 4G)

mABR multicast Adaptive Bit Rate

MANO Management and Orchestration

MEC Multi-access Edge Computing

MIR Maximum Information Rate

mMTC massive Machine Type Communications

SaT5G (761413) D4.1 DEC 2019

of 75

MNO Mobile Network Operator

NAS Non-Access Stratum

NFVI Network Function Virtualization Infrastructure

NMS Network Management System

NTN Non-Terrestrial Network

NFV Network Function Virtualization

NSD Network Service Descriptor

OA OneAccess

Opex Operational Expenditure

OSM Open Source MANO

OSS Operation Support System

OTA Over The Air

OTT Over The Top

PoC Proof of Concept

PoP Point-of-Presence

QoS Quality of Service

RAN Radio Access Network

RDO Red Hat Distribution of OpenStack

Satcom Satellite Communication

Satcore Satellite Core Network

SatRAN Satellite Radio Access Network

SDN Software-Defined Networking

SES Satellite Earth Stations and Systems (ETSI Technical Committee)

SLE Satellite Link Emulator

SMF Session Management Function

SNO Satellite Network Operator

SSI Satellite Service Identifier

SWP Sub-Work Package

TAS Thales Alenia Space France

UE User Equipment

UoS University of Surrey

UPF User Plane Function

URLLC Ultra-Reliable Low Latency Communication

VIM Virtual Infrastructure Manager

VNF Virtualized Network Function

VNFD Virtualized Network Function Descriptor

VSAT Very Small Aperture Terminal

WP Work Package

SaT5G (761413) D4.1 DEC 2019

of 75

YANG Yet Another Next Generation

ZSM Zero touch network & Service Management

SaT5G (761413) D4.1 DEC 2019

of 75

Executive Summary

The 5G network architecture holds at its core the dual concepts of Software Defined Networking (SDN) and Network Function Virtualization (NFV). A software-defined network that incorporates virtualized network functions (VNFs) in place of dedicated hardware resources supports dynamic reconfiguration and centralised management; consequently, multiple logical network topologies can be overlaid on an underlying set of physical resources, and subsequently reshaped in response to network or user demands. This paradigm enables 5G networks to be arranged or ‘sliced’ to accommodate disparate and very distinct use cases such as enhanced Mobile Broadband (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine Type Communications (mMTC). SDN and NFV are widely used in terrestrial networks, but their presence in satellite networks has been limited; virtualized satellite functions have typically consisted of auxiliary applications, such as proprietary satellite network management systems (NMS), which fall outside the scope of data and control planes. Given the viability of satellite for fulfilling 5G goals, such as ubiquitous access and eMBB it follows that in order to successfully integrate with 5G, relevant satellite components must be virtualized, SDN-enabled. This document details the work performed in WP4.1 in pursuit of those goals.

WP4.1 builds on the solid foundations laid by WP2 and WP3. For example, WP4.1 takes as input the reference architectures derived in D3.1, “Integrated SaT5G General Network Architecture”, which defines satellite’s position in an integrated terrestrial/satellite network. Of the various architectures defined therein, the WP4.1 partners selected the indirect use case (backhaul) as the end-to-end (E2E) network architecture. The indirect access architecture underpins four sample 5G use cases, as defined in WP2.1: 1) Edge delivery & offload for multimedia content and MEC VNF software; 2) 5G Fixed backhaul; 3) 5G to premises; 4) 5G moving platform backhaul. SDN and NFV capabilities in satellite components are researched in WP4.1, with a view to realising these four use cases, and the resultant proof-of-concepts are implemented across two primary test beds: the 5GIC 5G test bed, based in the University of Surrey, UK, and the Zodiac Aerospace test bed based in Munich, Germany. The 5GIC testbed implements 5G use cases 1-3, while the Zodiac testbed implements use case 4.

Promotion of satellite use in 5G systems is a primary SaT5G objective. One of the inherent challenges therein is the heterogeneity of terrestrial and satellite networks, which traditionally required highly bespoke implementations to support integration and even so, typically resulted in the satellite being treated as a “black box” from the terrestrial network perspective. One potential way to improve interoperability is to endow satellite networks with the capacity to present standard terrestrial network interfaces for control and user plane, which would allow the Mobile Network Operators (MNOs) to communicate directly with satellite components using standard 3GPP interfaces. Such integration could contribute dramatically to the uptake of satellite in 5G. Accordingly, in the 5GIC test bed, iDirect adopts the 3GPP architecture in the satellite network. This architecture includes a standard Commercial Off-The-Shelf (COTS) virtualized 5G core network (Satcore), complemented by both virtual and physical satellite devices, which are modified to support 5G control and data plane interfaces. In this context, the satellite network (as distinguished from the E2E network) implements a variant of the direct access use case, whereby the satellite remote terminal presents to the core as a 5G UE, and the satellite network presents as a gNB to the Satcore.

In addition to virtualizing the Satcore, iDirect also virtualize satellite functions that typically require dedicated hardware resources; they collocate and deploy all of the satellite VNFs on a single COTS general-purpose server, thus achieving a reduced hardware footprint by increasing compute density. A subset of the satellite VNFs are deployed directly using the OpenStack Virtual Infrastructure Manager (VIM), while others are packaged using ETSI-compliant YANG (Yet Another Next Generation) [1] model descriptors for onboarding and automated deployment as a network service with the Open Source Mano (OSM) Orchestrator.

In order to demonstrate plug n’ play for satellite services, iDirect present two separate approaches: the first enables third-party deployment of “gateway” satellite functions via OSM, while the second approach provides a prototype API that supports dynamic third-party activation and modification of satellite services.

Demonstration of 5G technology features anywhere and anytime is one crucial goal of the SaT5G project that is also reflected in Use Case 4. Zodiac Inflight Innovations (ZII) developed a 5G testbed for aircraft moving platform with the twofold objective to demonstrate a system based on GEO Satellite Link Emulator (SLE) and another system based on SES’s O3b MEO Ka-band High Throughput Satellite (HTS) constellation with 20 in-orbit satellites.

SaT5G (761413) D4.1 DEC 2019

of 75

The first set of demonstrations aim at testing the current de facto GEO satellite connectivity to aircrafts in an environment in which network service functionalities are abstracted from the underlying physical substrate, thus providing unprecedented flexibility to manage the end-to-end system and its network and compute resources. In cooperation with Gilat, Quortus, Broadpeak and i2CAT ZII relies on COTS hardware wherein virtualized satellite network (i.e. the Gilat’s SkyEdge II-c satellite hub) and mobile network services (i.e. the Quortus 4G core with control-user plane separation) are deployed in the OpenStack environment under the management of the single terrestrial-satellite resource coordinator TALENT, which ultimately coordinates both OpenStack and the OSM Orchestrator. Edge caching functionality and passengers’ Internet access through their personal devices were demonstrated for the sake of testing the end-to-end system. Complying with the same principle of virtualizing network services based on TALENT-OSM-OpenStack, for the MEO satellite connectivity the ZII testbed experimented the next generation of aircrafts connectivity based on the SES’s O3b MEO Ka-band HTS satellite constellation. The end-to-end O3b link relies on Gilat modems and MEO booster technology for the seamless satellite handover. In addition, the testbed demonstrated a virtualized 5G core network prototype, multicast over satellite, edge caching and passengers’ individual Internet access.

We conclude that virtualization of satellite resources is viable, and that Satcom components can support SDN and orchestration for improved integration with 5G networks. We also conclude that adoption of 3GPP network architecture in satellite networks presents extensive benefits, such as feature parity with terrestrial networks (for example, network roaming), simplified integration with terrestrial networks via implementation of standard terrestrial network interfaces, and reduced time to market via integration of third-party components (for example, terrestrial billing systems).

SaT5G (761413) D4.1 DEC 2019

of 75

1 Introduction

1.1 Document Context The SaT5G project aims to provide a “plug n’ play” solution for satellite networks with 5G. In order to accomplish this, the project addresses six research pillars, each of which focuses on a specific domain that poses technical challenges to integrating satellite communication (Satcom) with 5G. D4.1 falls under the research pillar “Implementing 5G SDN and NFV in Satellite Networks”, which centres on the virtualization of Satcom network functions to ensure compatibility with the Software-Defined Networking (SDN) and Network Functions Virtualization (NFV) aspects of the 5G network architecture.

One of key differences between 5G and its predecessor, LTE, is its service-based architecture, which supports deployment of heterogeneous, logical on-demand services on top of a homogenous underlying physical infrastructure. 5G represents a move away from the static, monolithic architecture of LTE, to a dynamic, on-demand network architecture, in which so-called “softwarisation” of the network, via Virtualized Network Functions (VNFs) and SDN plays a key part. This approach facilitates revenue-generating features for Mobile Network Operators (MNOs), such as Infrastructure as a Service (IAAS), and network slicing, but perhaps more importantly enable 5G networks to address a set of key use cases, each with a very different set of requirements. enhanced Mobile Broadband (eMBB) addresses data-driven use cases, which require high bandwidth with moderate latency; Ultra-Reliable Low Latency Communication (URLLC) use cases require extremely low E2E latency and demand reliability, for mission-critical services; massive Machine Type Communications (mMTC) use cases must support a high number of connections, with low bandwidth requirements.

In order to meet such 5G architecture requirements, Satellite Networks must be as amenable to dynamic configuration and remote deployment as their terrestrial counterparts. In essence, this requires Satcom elements to support virtualization and orchestration. WP4.1 examines potential solutions to meet these requirements, and provides inputs to testbed deployments containing SDN- and NFV-compatible Satcom functions, which ultimately demonstrate specific 5G KPIs.

This report, D4.1, examines the work performed in WP4.1 regarding the realisation of Satcom SDN and NFV, and the integration of Satcom with the 5G network architecture. It is the key deliverable for WP4.1.

1.2 Relationship to other Work Packages This paper builds on the “Satellite Reference Use Cases and Scenarios for eMBB”, as defined in WP2.1 and, more specifically, implements a single reference architecture (with respect to the positioning of a satellite in a 3GPP-integrated network) as defined in D3.1 [2]. Furthermore, the satellite and 3GPP network integration approach selected in WP4.1 is also documented in the ETSI paper “Seamless integration of satellite and/or HAPS (High Altitude Platform Station) systems into 5G system” [3].

The outputs of WP4.1 serve as inputs to WP4.2 (“Integrated network management and orchestration”), and Work Packages 5 and 6, which cover “Validation and Demonstration”, and “Dissemination, Standards, and Exploitation”, respectively. For WP4.2, the satellite VNFs and related prototypes developed as part of WP4.1 act as inputs for integration with an overall orchestration and management system (for example, OSM, TALENT by i2CAT). For WP5, WP4.1 provides a series of prototypes, Proof-of-Concepts (PoCs), technical advancements, and learnings, which serve as inputs towards individual 5G testbeds at University of Surrey, and the Zodiac Aerospace testbed in Munich, Germany, respectively. Furthermore, WP4.1 delivers additional value into WP6, specifically with respect to: the identification of Key Issues for standardisation of satellite network integration into 5G (targeting 5G Release 16); the contribution of white papers, marketing material, and conference demos to support dissemination of SaT5G work; the identification of opportunities for joint exploitation and future projects; and finally via the identification of WP4.1 results that may be strategically exploited by the SaT5G project.

Figure 1-1: Interaction between WP4.1 and other WPx illustrates the high-level relationships between WP4.1 and its associated WP’s.

SaT5G (761413) D4.1 DEC 2019

of 75

Figure 1-1: Interaction between WP4.1 and other WPx

1.3 Document Organisation A high-level overview of the overall document organisation follows.

Section 1 provides the general context for the work conducted as part of WP4.1, highlights the relationships between WP4.1 and related SaT5G WPs, and explains how the document is organised.

Section 2 of this document highlights the key innovations and achievements accomplished within WP4.1.

Section 3 details the various architecture options adopted within the context of the WP4.1 prototypes and their corresponding WP5 testbeds, to which WP4.1 provides input. This includes an examination of 3GPP architecture adoption within a satellite network in the 5GIC testbed.

Section 4 proceeds to address the virtualization of Satcom elements, exploring the research and development performed to enable same, and the resultant PoCs.

Section 5 focuses on the SDN aspects of Satcom virtualization, exploring how Open Source Orchestrators and Virtual Infrastructure Managers (VIMs), such as OpenStack, deploy a virtualized Satcom network.

Section 6 documents the work performed in WP4.1 to define a Model-Driven Architecture for vendor-neutral configuration and deployment of a satellite network. It also details how that work evolved from a low-level data model to a service-level API.

Section 7 provides a detailed breakdown of the PoCs developed as part of WP4.1 that act as prototypes for, and direct inputs to, the various WP5 testbeds at UoS and ZII.

SaT5G (761413) D4.1 DEC 2019

of 75

Section 8 highlights the contributions to the 5G standardisation of satellite integration, via the Key Issues identified for same as part of WP4.1.

Section 9 explores the conclusions regarding the implementation of SDN and NFV for satellite networks reached during the course of WP4.1.

Section 10 provides a list of documents referenced within D4.1.

SaT5G (761413) D4.1 DEC 2019

of 75

2 Summary of Innovations and Achievements

Table 2-1: Summary of innovations and achievements provides a high-level summary of the various technical innovations and achievements produced as part of WP4.1. For ease of navigation, the table cites the relevant document section for each line item.

Table 2-1: Summary of innovations and achievements

Innovation Business Value Section

Design and delivery of Satellite network integrated with 3GPP network architecture

Enables 3GPP-centric functionality in satellite networks (e.g. network roaming).

Promotes use of standard 3GPP-compatible systems (e.g. billing system) in satellite networks, ultimately improving quality of satellite network systems and reducing time to market.

3

Integration of 5G Core Network with satellite network

Demonstrates a first-of-its-kind integrated hybrid satellite/5G network.

3

Virtualization of Satellite Network Functions Reduced Capex and Opex for Network Operators.

Improved compute node density, and functional redundancy.

Fulfils a key requirement for 5G network components.

4

Flexible, on-demand deployment of Satellite Network Functions, via SDN

Reduced complexity of satellite network deployment.

Promotes centralised, automated deployment of virtualized satellite network functions.

5

Runtime configuration of satellite network functions, via service-level API

Enables network partners to activate and configure satellite network services on-demand, thus promoting satellite as a service.

6

OTA broadcast of IP multicast traffic Real-world demonstration of the benefits of satellite broadcast for delivery of rich content.

3

Demonstration of backhaul optimisation via prefetching and edge caching (MEC)

Real-world demonstration of the benefits of MEC in an integrated satellite/terrestrial network to achieve optimal 5G content delivery.

3

Demonstration of third-party activation of satellite services

Demonstration of “Plug n’ play” for satellite services, facilitated by OSM deployment of satellite network service in third-party network domain.

5

Deployment of live satellite network with SDN, MEC and NFV capabilities on SES’s live satellite network

(SES teleport, Betzdorf connecting Killarney and Ljubljana Remotes)

Underpins use case demos for EuCNC 2018

Demonstrates virtualization of satellite VNFs

Early demonstration of 3GPP network adoption (LTE Satcore)

Demonstrates integration of satellite and terrestrial 3GPP network (iDR/SES satellite network, 5GIC terrestrial network)

7

Deployment of live satellite network with SDN, MEC, and NFV capabilities on AVA’s live satellite network

Underpins use case demos for EuCNC 2019

Demonstrates virtualization of satellite VNFs and satellite orchestration via OSM

7

SaT5G (761413) D4.1 DEC 2019

of 75

Innovation Business Value Section

(Avanti teleport, Goonhilly connecting 5GIC Remote and Central nodes)

Demonstrates Plug n’ play for satellite service, via third-party satellite VNF deployment

Demonstrates adoption of 3GPP architecture in satellite with 5G Satcore

Demonstrates integration of satellite and terrestrial 5G network (iDR/AVA satellite network, 5GIC terrestrial 5G network)

SaT5G (761413) D4.1 DEC 2019

of 75

3 Network Architectures

3.1 Overview This section provides details on the various network architectures that WP4.1 selected for implementation in the individual SaT5G WP5 testbeds.

WP3 defines a set of reference architectures for an integrated satellite and terrestrial 5G networks with each of the testbeds (5GIC and Zodiac) adopting different architectures depending on the individual requirements. This section addresses each testbed separately, examining their selected network architecture, and analysing the rationale and selection criteria for the chosen architecture. Each testbed is presented in a dedicated sub-section:

Section 3.2 addresses the selected architecture for the 5GIC testbed in the University of Surrey, UK

Section 3.3 addresses the Zodiac Aerospace testbed in Munich, Germany.

Each sub-section of Section 3 follows a similar format, in which the testbed’s satellite architecture is first described before examining the overall E2E testbed architecture in-depth. A detailed description of the satellite and E2E architectures is provided in order to explain the rationale and selection criteria for the chosen architecture (from a list of prospective architectures identified in WP3.1).

The WP3 deliverable “D3.1 - Integrated SaT5G general network architecture” [2] contains a detailed analysis of the various architectures defined for an integrated satellite and terrestrial 5G network as part of the SaT5G project research. This includes an indebt analysis of characteristics and constraints of both satellite and terrestrial networks in order to define a reference 5G integrated satellite-terrestrial network architecture. The analysis led to the identification of two major classifications for satellite in future 5G network system architectures:

Direct access: satellite-capable UE has direct access to the 5G network through a satellite link;

Indirect access or backhaul: UE accesses to (R)AN via 3GPP or non-3GPP access technologies. (R)AN is connected to the 5G core through a satellite link.

The architectures differ, at a high level at least, by the position of the satellite link, connection, within the 5G system architecture as illustrated below in Figure 3-1: Satellite positioning within 5G network.

Figure 3-1: Satellite positioning within 5G network

Figure 3-2: Implementation options considered in SaT5G provides an overview of the different implementation options considered within SaT5G. The figure also represents the potential support of MEC in case of indirect access with the requirement of edge delivery and the support of multiple backhaul links (a satellite link and a non-satellite link in this case).

SaT5G (761413) D4.1 DEC 2019

of 75

Figure 3-2: Implementation options considered in SaT5G

As illustrated above and identified in “D3.2 – Integrated SaT5G detailed backhaul architectures” [4], the SaT5G end-to-end use cases focus on Indirect (backhaul) rather than Direct UE access which is understandable as this is what captures the services delivered to the end user applications. The Direct access architecture also plays an important role for the next generation satellite deployments and 3GPP integration perspective and is therefore also considered and discussed in this deliverable. Transforming the satellite network architecture to behave like a standard 3GPP network brings many benefits for the satellite industry who can take advantage of many years of innovation and market growth in telecoms industry.

As part of “D3.1 - Integrated SaT5G general network architecture” [2], the SaT5G Indirect backhaul implementation options were identified and categorised in two main areas:

Backhaul implementation options based on the relay node (RN): satellite-capable UE supporting a relay

functionality (i.e. multiplexer node role) which can serve other UEs and being backhauled to the ‘donor

RAN’ and 5G core network through a satellite link. This approach includes 3 implementations options,

differentiated by the type of access between the RN and the 5G core network:

o 3GPP access,

o Trusted non-3GPP access,

o Untrusted non-3GPP access;

Backhaul implementation options based on the transport network:

o Based on 3GPP system specifications (inherently 5G ready),

o Not based on 3GPP system specifications (requires adaptation layer to become 5G ready).

From the architectural analysis performed in WP3 is can be seen that there is no one-size-fits-all solution for Satellite and Terrestrial 5G integration. It greatly depends on the deployment, commercial, industry and possibly may other requirements to choose the right architecture to support a specific deployment. The spectrum of options for Satellite and Terrestrial 5G integration is wide, from the black-box satellite backhaul deployment, where there may be minimal integration with the 5G terrestrial network, to full integration with 3GPP using 5G New Radio over satellite, and everything in between. New Radio over satellite is currently under study in 3GPP and while it may be some time before deployments roll out, it will be a possibility in the coming generations of 3GPP and satellite network.

SaT5G (761413) D4.1 DEC 2019

of 75

Prior to full 3GPP integration, there are many different levels of integration that can take place at the management (SDN/NFV/MEC), control and user plane levels as the satellite network architecture evolves and converges with 3GPP. The SaT5G testbeds provided an excellent opportunity for partners to understand real deployment environment requirements for integrating Satellite and Terrestrial 3GPP networks.

The following sections describe the architectures selected for the two infrastructure testbeds in the SaT5G projects, namely the 5GIC testbed and the Zodiac testbed. It is important to differentiate the satellite and end-to-end networks, therefore for each testbed the satellite network architecture is first described followed by a description of the end-to-end architecture, which includes the satellite and end-to-end network. The end-to-end architecture facilitates the end-to-end 5G over satellite use cases defined by the project.

The architectures selected for the different testbeds considers the requirements of the testbed hosts, the equipment vendors involved and the technologies they support, and the end-to-end use cases and application requirements. Both Direct and indirect architectures are included: Direct architecture to build the satellite network that in-turn supports the Indirect architecture when integrated into an end-to-end system including a Mobile Network. It should also be noted that what is described and implemented in the individual testbeds should not be considered the only solutions for Satellite and Terrestrial 5G integration.

3.2 Selected Architectures for 5GIC Testbed

3.2.1 Overview Figure 3-3: 5GIC Testbed below provides an overview of the SaT5G 5GIC testbed system architecture, which consists of a remote and central node, located at 5GIC, connected live via the Avanti HYLAS-4 satellite and the Avanti Teleport in Goonhilly. The testbed architecture incorporates both the Direct and Indirect architectures. Firstly, the satellite network (referred to as Non Terrestrial Network (NTN) by 3GPP) partially adopts the 3GPP network architecture. The existing satellite network is modified to comply with the standard 3GPP architecture in order to allow a specialized NTN satellite terminal to presents itself as a standard UE within the NTN satellite network. This will enable support for 3GPP 5G services, such as authentication, billing, policy & charging, network slicing etc.

Figure 3-3: 5GIC Testbed

The NTN satellite network provides a backhaul connection between the RAN and 5G core network of a mobile network located at 5GIC. The remote and central nodes are located at the 5GIC testbed in University of Surrey

SaT5G (761413) D4.1 DEC 2019

of 75

with layer 2 VPN connection providing connectivity between Avanti’s Goonhilly Teleport and the central node at 5GIC. The mobile network in turn provides end-to-end connectivity to applications running on the remote and central nodes.

Details of the architectural approach and implementation are described in more detail in the following sections.

3.2.2 Satellite Network Architecture The satellite network deployed at the 5GIC testbed is built using ST Engineering iDirect’s 5G-enabled Velocity™ Intelligent Gateway (IGW) system and uses satellite capacity provided by Avanti’s HYLAS-4 Ka Band satellite. The satellite ground infrastructure architecture is based on the Direct access classification briefly described earlier and described in more detail in “D3.1 - Integrated SaT5G general network architecture” [2].

In order to understand the selected satellite architecture it will be helpful to consider the design approach of adopting 3GPP architecture concepts and functions within the satellite communications networks.

To date, the satellite communication industry has tended to build bespoke satellite networks with little standard interfaces internally or externally. This has resulted in satellite networks being deployed without consideration for interworking with other satellite networks. There are a number of reasons for this but the main reason relates to satellite being a smaller market compared the terrestrial counterparts in the wireless domain (e.g. 3GPP) where, in the past, the requirement for interoperability was not high priority for the satellite network operators.

However, the landscape is changing as mobile networks expand globally and become denser, ubiquitous connectivity is becoming a requirement to provide ever more tactile, reliable and differentiating services to mobile broadband users and also the new verticals like machine to machine and IoT services. Autonomous driving is a good example of a requirement for reliable, ubiquitous and seamless wireless coverage across multiple geographies and territorial boundaries as well as wireless domains.

3GPP and 5G have recognised that other technologies will be required to meet the market demand and therefore they opened the door to support non-3GPP access technologies. 5G is said to be access agnostic meaning that not just standard 3GPP access technologies can be supported by the 5G network. Figure 3-4: 5G access agnostic below provides a simple view of how various technologies could connect to the standard 5G core network.

Figure 3-4: 5G access agnostic

Three types of access architectures supported by the 5G access agnostic network are illustrated:

1. Standard 3GPP access using the standard gNB and 5G UEs 2. Non-3GPP access via Non-3GPP Interworking function (N3IWF)

SaT5G (761413) D4.1 DEC 2019

of 75

3. Non-terrestrial Network terminal and modified gNB using standard interfaces to the 5G core network while continue to use the satellite radio network

The architecture proposed for the satellite component of the 5GIC testbed takes advantage of option 3 above. Firstly, a standard 3GPP 5G core network function is integrated in order to operate the control and user-plane functions of the satellite network. Once this is in place, the hub-side of the existing satellite network is modified to comply with standard 3GPP interfaces, using N2 and N3 interfaces to communicate with the standard 5G core network. The NTN terminal is also modified to communicate with the 5G core network via the 5G standard N1 interface. This results in a 5G-enabled satellite/NTN terminal presenting itself as a 5G UE to the 5G core network and the satellite hub-side network presenting itself as a standard gNB. This new satellite RAN (SatRAN) gNB connects with the NTN 5G core network on the network side while continuing to use the existing satellite radio over the satellite. It is important to highlight the standard 3GPP 5G core network is unmodified and all modifications are incorporated in the 5G-enabled satellite network. Together, the modified NTN terminal, SatRAN and standard 3GPP 5G core network provide the NTN satellite network connectivity.

Figure 3-5: Introduction of 5G core network to satellite network below provides another look at this type of architecture.

Figure 3-5: Introduction of 5G core network to satellite network

Adopting 3GPP architecture concepts and transforming the satellite network architecture to behave more like a standard 3GPP network brings significant benefits to the satellite industry, who can take advantage of many years of innovation and market growth in the telecoms industry ecosystem, for example; support for 5G services, such as authentication, billing, and policy & charging, and network slicing.

The satellite architecture proposed is considered a variant of the Direct Access architecture whereby there is direct access between the NTN terminal and satellite RAN, using satellite radio physical layer, and the NTN terminal communicates with a standard 3GPP 5G core network for control and user plane operations. The architecture is not fully 3GPP compliant as the physical radio interface remains satellite orientated, i.e. non-3GPP, but otherwise the network can operator as a standard 5G network. This is especially important from the network management perspective as it allows the operator to use the standard 3GPP 5G features and leverage the 3GPP ecosystem at the management, OSS and BSS levels.

Now that we have established the architecture used for the satellite network, we will described how this fits into the end to end network for the 5GIC testbed, an overview of which will be provided here with more details available in section 3.3.3 “E2E Network Architecture”.

As with any network deployment, the system architecture largely depends on the onsite environment variables - in this case the 5GIC testbed at University of Surrey. The 5GIC testbed represents a standard terrestrial mobile

SaT5G (761413) D4.1 DEC 2019

of 75

telecoms network as deployed in any terrestrial Mobile Network Operator (MNO) e.g. BT. The 5GIC mobile 5G core network is virtualized and deployed using OSM at the 5GIC facility along with the 5G radio access network (RAN). For SaT5G, the satellite network is introduced between the 5G RAN (gNB in standalone mode) and the 5G core network as illustrated in Figure 3-6: Satellite network providing connection between 5G core and RAN below.

Figure 3-6: Satellite network providing connection between 5G core and RAN

The standard 3GPP 5G mobile network deployed at 5GIC uses the NTN satellite network, shaded in blue above, as a backhaul network for end-to-end service delivery. This results in a mix of both the Direct architecture, for the NTN network in isolation and the Indirect architecture where the NTN network provides a backhaul network for the end-to-end 5G mobile network deployment. In the initial deployment, the two networks operate independently as two distinct networks both using independent 5G core networks.

Further details of the end-to-end network topology and use cases are described in the later sections and in WP5 deliverables.

Finally, the network architecture outlined in this section is a variant of the “Relay Node based on Trusted Non-3GPP Access” defined in “D3.1 - Integrated SaT5G general network architecture” [2] and illustrated in Figure 3-7: Relay Node based on Trusted Non-3GPP Access below.

Figure 3-7: Relay Node based on Trusted Non-3GPP Access

This architecture scenario is also captured by ETSI SES in ETSI SES - "DTR/SES-00405 - TR 103 611: Satellite Earth Stations and Systems (SES); Seamless integration of satellite and/or HAPS (High Altitude Platform Station) systems into 5G systems", specifically “Scenario A3 - Indirect mixed 3GPP NTN access with bent-pipe payload” [3].

SaT5G (761413) D4.1 DEC 2019

of 75

Figure 3-8: Scenario A3 - Indirect mixed 3GPP NTN access with bent-pipe payload

3.2.3 E2E Network Architecture It is important to differentiate between a testbed’s satellite network architecture, and its end-to-end architecture. The satellite network constitutes the network elements that implement the direct access architecture, in which the satellite router acts as a UE, connecting to a 5G CN via satellite Radio Access Network. In this context, the 5GC is not necessarily the MNO core network, but may be a separate, self-contained 5GCN managed by the NTN operator, purely for operating the satellite Radio Access Network. The E2E network then, implements the indirect access architecture, and uses the satellite network purely as a transport network for backhaul. In this context, the MNO operates a 5GC that is typically separate from the satellite’s 5GC. The E2E network architecture ultimately delivers the 5G use cases identified in WP2.1; this section examines the E2E architectures implemented as part of WP4.1 and delivered in WP5.2.

In describing the position of the satellite network earlier, the end-to-end architecture selected for the 5GIC testbed was also briefly discussed. The related diagram is added here again for ease of reading, Figure 3-9: Satellite network providing connection between 5G core and RAN below.

Figure 3-9: Satellite network providing connection between 5G core and RAN

The 5GIC central and remote nodes, representing the 5G mobile RAN and core networks, connect using the live NTN satellite network, shaded in blue above, as a backhaul network for end-to-end service delivery. The end-to-end network is classified as an Indirect architecture where the NTN network provides a backhaul network for the end-to-end 5G mobile network deployment.

Physically, both the remote and central nodes are located in at 5GIC. The remote node is connected to satellite via an onsite VSAT installation, which connects over satellite to the Avanti Satellite Hub, installed at Goonhilly.

The use case descriptions below provide a very brief overview of the over the top use cases supported by the satellite and end-to-end networks described earlier and together make up the 5GIC testbed. Each of the use

SaT5G (761413) D4.1 DEC 2019

of 75

cases have dedicated deliverables describing them in detail. Please refer to the corresponding deliverable for more information.

Over-the-air MEC-based video streaming over a 5G multilink satellite and terrestrial network

Figure 3-10: System Overview of satellite and terrestrial Network SaT5G below provides an overview of the end-to-end setup for the 5GIC University of Surrey use case: Over-the-air MEC-based video streaming over a 5G multilink satellite and terrestrial network. The use case demonstrates a 5G Use case of ‘Media to the premises’ in which adaptive video is streamed by multi linking via a terrestrial path and a satellite path. A Video-segment Scheduling Network Function (VSNF) is developed to handle multiple UEs/players and select the pathways within a 5G environment, adapting the streams to optimise QoE fairness and system loading.

Figure 3-10: System Overview of satellite and terrestrial Network SaT5G

For more information on this use case, please refer to deliverable D4.6 Caching and Multicast Analysis, Design and Proof of Concepts.

Over-the-Air multicast over satellite video for caching and live content delivery The Broadpeak satellite multicast setup on the 5GIC testbed focused on using Satellite Multicast capabilities to deliver live video streams to a 5G Edge mobile network.

Some key points:

Improved video distribution efficiency using mABR over Satellite as contribution link

End-to-end latency minimised using CMAF-CTE Dash over mABR link

All screens addressed, thanks to transparent use of local cache server (Edge computing)

Synchronized video delivered to all screens

Figure 3-11: mABR Content Delivery via Satellite Multicast

SaT5G (761413) D4.1 DEC 2019

of 75

Figure 3-11: mABR Content Delivery via Satellite Multicast provides an overview of the end-to-end setup for this use case.

Further information on this setup can be found in deliverable D5.3 Demonstration of Fixed and Home Backhaul Scenarios Including Caching & Multicast.

Satellite and 5G Hybrid Backhaul extending 5G services This hybrid 5G backhaul solution provided by Ekinops focuses on integrating a satellite link into a multi-link 5G operation. Combining a high-bandwidth, high-delay satellite link with a low-delay, low-bandwidth (4G or 5G) terrestrial link provides both a good performance for interactive applications and a high throughput for the download/upload transfers. The overall QoE was significantly improved by using to this hybrid backhauling scenario. The 5G hybrid backhaul relies on state-of-the-art multipath protocols to validate the performance required by 5G services and successful demonstrated

Satellite is a viable link for 5G hybrid backhaul

5G low-latency and high bandwidth achieved

Multipath (MPTCP & MPQUIC) in action Figure 3-12: Standard 5G UE leveraging a 5G hybrid backhaul below provides an overview of the end-to-end setup.

Figure 3-12: Standard 5G UE leveraging a 5G hybrid backhaul

More information can be found in deliverable D4.3 Multi-link and Heterogeneous Transport Analysis, Design and Proof of Concepts.

SaT5G (761413) D4.1 DEC 2019

of 75

3.3 Selected Architectures for ZII Testbed

3.3.1 Overview SaT5G Use Case 4 (UC4) revolves around connectivity to moving platforms through the integration of the Satcom in the 5G technology stream. Specifically, the focus is on the aviation vertical with the 5G test-bed facility managed by Zodiac Inflight Innovations (ZII) that focuses on the next generation of aircraft connectivity. The progress of this test-bed with respect to the state of the art of aircrafts’ connectivity is manifold. At first, the ZII test-bed experimented MEO satellite connectivity to demonstrate that existing GEO-based connectivity can be complemented with very high throughput satellite constellations like SES O3b for Medium Earth Orbit (MEO) coverage. Second, the typical Wi-Fi only connectivity system was complemented with mobile network technology on-board by experimenting the new features of the 5G mobile core. Third, typical scenarios of interest for passengers were demonstrated using the ZII test-bed facility.

The testbed stakeholders are ZII (test-bed leader), Gilat (satellite systems vendor), SES (satellite operator), Quortus (mobile core network provider), Broadpeak (content delivery network) and i2CAT (network virtualization management).

The SaT5G UC4 demonstrations for the ZII test-bed are summarised below for convenience:

1. Update content for on-board systems and grouped media requests (scenario 4a): in this scenario, we proposed an improvement with respect to the typical situation in which media content is loaded into the central media server during the time aircrafts are grounded. SaT5G technology trialed the possibility to do multicast over satellite to upload content on-board multiple aircrafts that fall within the same satellite beam. Furthermore, besides the traditional media catalogue of content on-board, we envisaged to upload a second catalogue with cached content. The second catalogue may contain more volatile content that can be frequently updated with news, viral videoclips and additional information for travellers. Once stored on-board, passengers can play the content through their seat screen device or using their own personal device after downloading an App from the airline.

2. Broadband access for passengers and individual media requests (scenario 4b): in this scenario, we proposed to trial the next generation of connectivity both outside (to/from the ground) and inside (complementing the existing WiFi system) an aircraft. The main target was to enable passengers with an eMBB connectivity system that passengers could use to surf the Web or retrieve content on-board that in overall is superior to the existing system in terms of flexibility to deploy the technologies as well as in performance.

3. User mobility management in aircraft environment (additional scenario): in this scenario, we demonstrated service continuity for passengers from the moment they leave the gate and are connected to the airport infrastructure until the moment they enter the cabin. . The main challenge consisted in verifying the status of the connectivity service during the handover inside the mobile network and the satellite handover in the MEO constellation.

As already decided during the planning phase of the overall test-bed, we discarded the demonstration of the scenario 4c (business and technical data transfer for the moving platform company), which would have required creating an MTC network slice over the existing ZII test-bed infrastructure. Considering that aircraft connectivity to passengers is of prime interest to ZII as a company and that machine-type communications are still in standardization stage inside 3GPP, the ZII test-bed was mainly focused on demonstrating eMBB class services on-board aircrafts. Furthermore, multicast communications over Wi-Fi technology was de-prioritized to give more room to develop the 5G features that have been deployed over the test-bed.

Regarding the SaT5G Research Pillars, the ZII test-bed demonstrated the following:

Research Pillar I: Implementing 5G SDN and NFV in Satellite Networks,

Research Pillar II: Integrated Network Management and Orchestration,

Research Pillar VI: Caching & Multicast for Optimised Content & NFV Distribution.

The ZII test-bed specific technology enablers are listed here:

Satellite connectivity with emulated GEO and over-the-air (OTA) MEO satellite links,

Virtualization of both satellite and terrestrial systems,

Network management and orchestration compliant with the ETSI MANO model,

SaT5G (761413) D4.1 DEC 2019

of 75

Integration of satellite and terrestrial network segments under a single OSS layer to orchestrate and configure services,

4G and 5G mobile core network functionalities for control and user plane separation (CUPS),

Mobile network access on-board to off-the-shelf personal devices (smartphones and tablets),

Content caching on-board as an example application of Multi-access Edge Computing (MEC),

WiFi access for passengers through an aero certified access point. The following sections desribe the test-bed architecture and afterward the virtualized infrastructure and services.

3.3.2 Satellite Network Architecture The architecture of the ZII test-bed for demonstrating SaT5G UC4 scenarios is shown in Figure 3-13: ZII test-bed physical infrastructure below:

Figure 3-13: ZII test-bed physical infrastructure

The test-bed is composed of three different geographical locations and four main islands:

ZII ground datacentre in Wessling (Germany),

aircraft infrastructure in Wessling (Germany),

GEO satellite system in Tel Aviv (Israel) that avails a GEO satellite link emulator,

SES’s O3b teleport in Sintra (Portugal). Moreover, two different end-to-end systems can be identified:

the MEO path with the SES’s O3b OTA satellite connection and the Layer 2 VPN,

the GEO path with a satellite link emulator (SLE) and the Layer 3 VPN. The aircraft network represents the deployment that can be found on a typical A320 aircraft model enhanced in terms of connectivity with mobile network technology. This deployment is realised in the A320 cabin mock-up made available to the project by ZII. The aircraft network is meant to provide connectivity to passengers and cabin attendants. Thus, smartphones, tablets and end users’ terminals connect to the radio access on-board, as well as aero certified seat screens for basic performance tests. The seat screens have been enhanced with Wi-Fi connectivity (ZII manufactured access point) to fully embrace the concept of the wireless cabin, a feature that is currently not available on-board aircrafts. The central media server is an aero certified component manufactured by ZII where media content is stored. In a conventional aircraft, setting the central media server

SaT5G (761413) D4.1 DEC 2019

of 75

is involved in distributing content to the passengers. In order to demonstrate MEC scenarios on-board to reduce latency and satellite link bandwidth utilisation, additional servers that provide additional compute and storage have been deployed also. The radio access that has been deployed in the cabin mock-up for demonstration purpose relies on commercial eNB small cells provided by CASA Systems as part of a co-operation between the SaT5G project and another H2020 project 5G ESSENCE. The choice to use a commercial eNB is mainly due to the availability of gNB small cells and only the recent availability of 5G user equipment. It is worth mentioning also that the initial 5G deployment will be done through a non-standalone configuration, which is currently less appealing on aircrafts compared to a macro-cell radio environment. In addition, to the best of our knowledge, commercial 5G base stations currently target the market of macro-cell base stations. Finally, as shown in Figure 3-13: ZII test-bed physical infrastructure, mobile connectivity in the aircraft network can rely also on software-defined radio and open source software like srsLTE.

The ground datacentre is the computing facility in which mobile core network functionalities and satellite related functions are deployed. The ground datacentre and the aircraft network are connected together either by means of the OTA SES’s O3b satellite connection or the Geostationary satellite link that relies on the SLE. Specifically, as mentioned already, for the mobile core network, CUPS is used so that the data plane of the core network is deployed on-board the aircraft (edge component), whereas the remaining components reside in the ground datacentre.

The satellite connection is implemented and demonstrated in two different ways:

1. The OTA MEO connection is provided by SES (beam 622, channel 2) based on its O3b MEO HTS Ka-band satellite constellation and it relies on the SES’s O3b teleport located in Sintra, a 1.2m Ka-band transportable dual-antenna terminal provided also by SES, two Gilat modems and MEO booster components to enable the make-before-break MEO satellite handover,

2. The Geostationary path relies on the Gilat Sky Edge II-c satellite hub (a Gilat product that is designed for virtualization), which is connected to the Gilat satellite modem through the SLE. The SLE emulates not only the satellite signals but also the GEO satellite link delay.

For the OTA satellite connection traffic flows as follows

Uplink traffic of the end users reaches the satellite terminal on-board through the eNB and the edge component of the mobile core network. After reaching the satellite teleport in Sintra, the uplink request reaches the core network part on ground via a Layer 2 VPN connection.

Downink traffic to the end users will first reach the mobile core network available in the ground datacentre and it shall reach the Sintra teleport via the Layer 2 VPN. The loop is closed reaching the satellite terminal on-board.

A situation similar to the OTA satellite connection was designed for the Geostationary path:

In this case, instead of the Layer 2 VPN, the uplink traffic is sent over a Layer 3 tunnel to reach the test-bed island in Israel. Specifically, the communication, after reaching the edge component of the mobile core network in the aircraft infrastructure, is first addressed to a host in Tel Aviv that acts as a relay node for incoming and outgoing traffic using specific IPTables rules for the packets. From there, data packets go over an emulated GEO satellite link and then traverse back the Layer 3 connection until reaching the mobile core in the Wessling ground datacentre.

Downlink traffic simply follows the reverse direction.

There are two different VPN connections used in this test-bed 1. The Layer 2 connection, which is divided in two main segments. The first segment between Wessling

and the SES office in Unterföhring Munich and the second segment from Unterföhring until Sintra. ZII has purchased a leased symmetric line from Deutschland Telekom for the purpose with a throughput up to 50 Mbit/s. The VPN segment until Sintra is guaranteed by SES and the connection can be up to 1 Gbit/s. Hence, the limiting part is the connection between Wessling and Unterföhring, but the leasing costs and traffic to be supported over the VPN indicated the choice of the 50 Mbit/s connection.

2. The Layer 3 connection is a site-to-site VPN connection implemented between the ZII and the Gilat network routers. As such, a latency around 180 ms was measured since the two sites are connected over the public Internet.

SaT5G (761413) D4.1 DEC 2019

of 75

4 Virtualization of Satcom Elements

4.1 Overview One of the key advancements of the 5G architecture over its predecessors is the explicit inclusion of SDN and NFV at a specification level. In order to accommodate core service-based 5G features such as network slicing, in which multiple logical virtual networks exist on top of the same physical network, network elements must support virtualization and SDN, such that they can be deployed and reconfigured dynamically, according to network and user demands. Accordingly, for satellite networks to fully integrate with 5G, it follows that Satcom elements must also support virtualization.

A primary focus area of WP 4.1 is the research and implementation of Satcom element virtualization and enabling support for software-defined-networking within satellite networks; this section examines the work done within WP4.1 to meet the virtualization requirements. This section begins with an introduction to the ETSI NFV-MANO logical architecture, which defines the various elements contained within a virtualized and SDN-enabled network. The concepts introduced here will frame the discussion around satellite network function virtualization and the application of SDN to a virtualized satellite network, as covered in Section 5, Implementation of Satellite SDN & Orchestration in Testbeds.

In order to understand the nature of the satellite network functions that were virtualized, a high-level general overview of satellite network components is first presented before proceeding to examine whether virtualization is feasible for each. Later, the implementation of virtualization for Satcom elements within WP4.1 is explored, highlighting the research conducted to reach that point, and the virtualization technology adapted.

4.2 ETSI NFV Architectural Framework The ETSI document ETSI GS NFV 002: "Network Functions Virtualization (NFV); Architectural Framework" [5] provides a comprehensive description of the NFV-MANO architectural framework. However, in order to frame the discussion around WP4.1 satellite VNF and SDN, a brief recap of a subset of the framework’s elements follows.

Figure 4-1: ETSI NFV reference architectural framework 1

Figure 4-1: ETSI NFV reference architectural framework illustrates the various domains, elements, and reference interfaces defined by ETSI within the NFV architectural framework. Most relevant to the ensuing discussions are

1 Source: https://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.01.01_60/gs_NFV002v010101p.pdf

https://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.01.01_60/gs_NFV002v010101p.pdf

SaT5G (761413) D4.1 DEC 2019

of 75

the VNF, NFVI, Virtualization Layer, Orchestrator, Virtual Infrastructure Manager, and Service, VNF and Infrastructure Description elements. A brief overview of these components follows.

VNF: Virtual Network Function; a software implementation of a network function

NFVI: Network Function Virtualization Infrastructure; (physical) infrastructure that provides the resources that are abstracted by the virtualization layer and used by VNFs

Virtualization Layer: provides abstraction of physical resources for VNFs, and coordinates and arbitrates allocation of physical resources to VNFs. Also known as a hypervisor.

Orchestrator: software agent that coordinates virtual and physical resources for the provision of network services. Provides a northbound API for interaction with business and operation-level systems, and southbound APIs for communication with VNF manager(s) and/or VIM(s). In the case of the 5GIC testbed, the Orchestrator works directly with the VIM to arrange underlying resources for provision of a satellite network service.

Virtual Infrastructure Manager: manages Network Function Virtualization Infrastructure (NFVI), which may be physical and/or virtual. Exposes a northbound API for interaction with the Orchestrator, and a southbound API towards the underlying NFVI. VIM responsibilities include allocation and modification of VM resources, and provision of VM network connectivity.

Service, VNF and Infrastructure Description: text-based descriptor files consumed by the Orchestrator. Typically written in YANG [1] modelling language and encoded in JSON or XML, descriptors define VNF-specific resource requirements and the inter-VNF virtual forwarding graphs that define a network service.

Section 4 presents the WP4.1 virtualization activities, and consequently it discusses the VNF and Virtualization Layers of the NFV-MANO architecture; the remaining elements from the list above are presented within Section 5, Implementation of Satellite SDN & Orchestration in Testbeds as the conversation moves towards the implementation of SDN in virtualized satellite networks.

4.3 Recap of Satcom Elements Section 2 of D3.1 [2]provides a comprehensive overview of satellite systems; however, in order to frame the discussion regarding satellite element virtualization, a very brief summary follows.

Figure 4-2: High-Level Satellite Network Architecture illustrates, at a high level, the elements within a satellite network. The following sub-sections describe each element in this diagram.

Figure 4-2: High-Level Satellite Network Architecture

4.3.1 Satellite Remote The Satellite Remote is the section of a satellite network that sits on the subscriber’s side of the connection (subscriber in this context relates to the subscriber to the satellite service, and not a terrestrial mobile subscriber). Its primary element is a satellite router, which is connected directly to a Very Small Aperture

SaT5G (761413) D4.1 DEC 2019

of 75

Terminal (VSAT) and to one or more UE’s (either directly, or indirectly). The satellite router passes information to/from the satellite, converting it between RF and IP formats for the forward and return links, respectively.

4.3.2 Satellite Teleport The Satellite Teleport, as pictured on the right-hand side of the satellite link in Figure 4-2, refers to the satellite equipment that resides in a Satellite Network Operator or third party’s side of the network. This can also be referred to as the Hub or Ground Earth Station (GES). It consists of a satellite antenna and ground segment infrastructure (hub chassis, satellite line cards, SatRAN) that communicates with the satellite to pass data to/from a mobile and/or data network.

4.3.3 Satellite Radio Access Network (SatRAN) The SatRAN constitutes the RF sub-system from the Satellite Router in the remote that extends over the space segment and terminates at the ground segment in the Satellite Teleport. However, in the context of this document the term “SatRAN” holds a much more specific connotation. Traditionally implemented as a dedicated hardware element in the Satellite Teleport, the SatRAN is responsible (at least in part) for the termination of the return RF signal, and its subsequent processing and conversion to IP (and vice-versa on the outbound link).

4.4 Satcom Virtualization – what can be virtualized? Fundamentally, satellite communications include the same characteristics as other wireless technologies and therefore can adopt the paradigm of network function virtualization to a similar degree. There are physical functions, e.g. the satellite hub chassis, RF line cards, and satellite terminal, which will always run on dedicated hardware, albeit, in future it may be on COTS hardware. In addition, there are some lower layer functions in the satellite radio domain that are best suited to run as physical network functions as they are static high throughput compute functions. This applies to terrestrial wireless networks also.

However, the upper layers on the satellite radio and the network layers are all suitable for virtualization; analogous to the layer 2 and layer 3 layers of the 3GPP RAN architecture. The satellite network level control and user plane functions and management plane functions (e.g. network element management, OSS, BSS, etc.) are all suitable for virtualization. Many of the latter satellite functions, especially management, are already virtualized and have been for some time.

Beyond that, the over-the-top applications are fully virtualized in public clouds (e.g. Amazon AWS, Microsoft Azure, etc.)

The table below provides a comparative list of components suitable for virtualization.

Table 4-1: Opportunities for Satcom virtualization

Area

Element/Function

Terrestrial Can this

function be Virtualized?

Satellite

Management

Operations Support system (OSS) Yes Yes Operations Support system (OSS)

Business Support system (BSS) Yes Yes Business Support system (BSS)

Network management systems (NMS) Yes Yes Network management systems (NMS)

Element management system (EMS) Yes Yes Element management system (EMS)

Management and Orchestration Yes Yes Management and Orchestration

Lifecycle management Yes Yes Function lifecycle management

Applications End user applications Yes Yes End user applications

Mobile network operator applications Yes Yes Satellite network operator apps

IP traffic, N6 or SGi interface

Control and User plane

3GPP core network control plane Yes Yes 3GPP core network control plane (O)

3GPP core network user plane Yes Yes 3GPP core network user plane (O)

IP traffic, N2/N3 or S1 interface

SaT5G (761413) D4.1 DEC 2019

of 75

Area

Element/Function

Terrestrial Can this

function be Virtualized?

Satellite

Radio base station /

hub station

gNB network interface Satellite HUB network interface

Layer 3 Yes Yes Layer 3



gNB Radio interface Satellite HUB Radio interface


Layer 2 Yes No Layer 2

Layer 1 No No Layer 1

Radio interface

User equipment / VSAT

User Equipment (UE) NTN terminal

Radio interface No No Radio interface

NAS Yes Yes NAS (O)

End user application Yes Yes End user application

Between the two testbeds in the project all the functions listed above as capable of being virtualized were virtualized. This included the management and application layers, the control and user plane functions of the satellite network, the network stack of the satellite RAN and parts of the radio side stack of the satellite RAN. The lower layers of the RF stack and packet framing layers continued to run as physical network functions along with the remote terminal located onsite at remote node.

What differs between testbeds is the level of virtualization and the manner in which the virtual network functions interact to provide the satellite communications network. This is described in more detail in the following section for both testbeds.

4.5 Implementation of Satcom Virtualization

4.5.1 5GIC Testbed This section describes the implementation of virtualization for the Satcom components in the 5GIC testbed.

Pre-Virtualization Figure 4-3: Satcom components deployed on dedicated hardware illustrates a typical teleport configuration, in which dedicated rack-mounted servers host individual satellite functions. This was the starting point, from which virtualization activities began. Note that each server runs only a single, dedicated application; this is wasteful, since each application typically consumes only a fraction of the available hardware resources, which remain otherwise unused.

SaT5G (761413) D4.1 DEC 2019

of 75

Figure 4-3: Satcom components deployed on dedicated hardware

NFVI In order to consolidate and virtualize all of the aforementioned Satcom applications on a common physical system in the 5GIC testbed (i.e. the NFVI), it was first necessary to calculate the aggregate resource requirements of those applications. Thus, the CPU, RAM, disk space and network requirements of each application were determined, and a hardware platform with a higher specification than the sum of those individual requirements was procured.

Virtualization Layer The next system-level consideration was the selection of an appropriate hypervisor to manage and allocate the underlying physical resources for the satellite VNFs. In selecting a hypervisor, there were numerous factors to consider, for example

Should the solution be proprietary (e.g. VMware ESX/ ESXi, Microsoft Hyper-V), or an Open-Source alternative (e.g. Oracle VirtualBox, KVM)?

Should the solution use Type 1 (baremetal) hypervisor that runs natively on system hardware (e.g. Citrix Xen), or Type 2 (hosted) hypervisor which sits on top of a physical system’s operating system (e.g. VMware Server).

This decision came down to a number of factors: technical support, feature availability, performance, and of course, cost. In the context of SaT5G and the 5GIC & Goonhilly Teleport deployment, technical support was not required, advanced features such as live VM migration were not considered, and budget was constrained. Ultimately, these factors led to the selection of Kernel Virtual Machine (KVM) as the hypervisor for the teleport system. KVM is a kernel module, which enables the Linux Kernel to act as a performant hypervisor.

VNFs – Virtualization of Satellite Network Functions One of the fundamental goals of NFV is to reduce the hardware footprint of network equipment by “softwarising” (i.e. virtualizing) network services, and subsequently consolidating numerous virtualized network functions on a standard COTS platform. Examining the opportunities for virtualization of network functions in the satellite network as presented in Table 4-1: Opportunities for Satcom virtualization, the options that represented the highest return on investment were those that were amenable to a so-called “lift-and-shift” approach. Simply put, such a process involves transferring the execution environment of a satellite function from bare-metal or native OS, to a Virtual Machine (VM). For the 5GIC testbed, and the associated prototypes developed as part of WP4.1, the iDirect team performed a “lift-and-shift” on various physical satellite components that resided in the teleport.

The first element to undergo virtualization was the iDirect SatRAN. The SatRAN is typically deployed on dedicated servers in commercial teleports; however, the lab-like system deployed in the 5GIC teleport and the research nature of the project enabled the scaling down and migration of the iDirect SatRAN from a physical system to an OpenStack-deployed VM within the 5GIC testbed environment. Similar virtualization of the satellite 3GPP Core Network, L2oS, and Satellite Gateway VNFs enabled deployment of all four VMs on the same physical

SaT5G (761413) D4.1 DEC 2019

of 75

system, increasing dramatically the platform’s functional density, in comparison to its baremetal counterpart. A Virtual Infrastructure Manager (VIM) allocated underlying physical resources for all VNFs and instantiated them on the same system, as illustrated in Figure 4-4: Consolidation of sample virtualized Satcom functions on single physical server. OpenStack was the VIM utilised in the 5GIC testbed; Section 5, Implementation of Satellite SDN & Orchestration in Testbeds covers OpenStack in detail.

Figure 4-4: Consolidation of sample virtualized Satcom functions on single physical server

SaT5G (761413) D4.1 DEC 2019

of 75

4.5.2 ZII Testbed In the Zodiac Testbed, GEO Testbed Setup, two major satellite blocks were virtualized:

1. The NSC - Network Segment Control of the hub 2. The VxGW - establishes Layer 2 connectivity in the hub

Figure 4-5: Zodiac testbed

The virtualized VNF blocks are shown with a red rectangle around them and both play key functions in the operation of the satellite components.

The VNFs were deployed on standard server hardware running Ubuntu OS. The servers were setup as Open Stack compute nodes under the control of the Open Stack Controller in Wessling, and thus although placed in a different geographical location that was connected by a L3 VPN IPSEC tunnel over the public internet, these compute nodes were completely an integral part of the Testbed in Wessling.

Figure 4-6: OpenStack overview page

SaT5G (761413) D4.1 DEC 2019

of 75

The above diagram shows the OpenStack Controller overview page for the Satcom components. The virtual VxGW consists of two VNF instances, while the vNSC consists of a single component.

Once the Satcom VNFs were deployed, it was necessary to ensure that all the interfaces to the other Satcom blocks were still reachable and this entailed defining OpenStack provider networks to interface over VLANs to the other Satcom blocks. One provider network was needed for each VLAN. Once the provider networks were in place it was necessary to ensure that the VNFs could be deployed and could start-up automatically.

At this stage, we were ready to define the necessary descriptors so that the Satcom VNFs could be deployed from the OpenStack MANO OSM environment. The VNF packages and single NS package were defined and the Satcom VNFs could then be deployed from the OSM.

Figure 4-7: VNF Packages

Finally, integration was performed by i2Cat to allow the TALENT to control the Satcom VNF components. In addition, the TALENT was able to send configuration commands to the TotalNMS SDN MANO, which then commanded the Satellite components to open up a Layer-2 VLAN service through the Satellite network.

Figure 4-8: TALENT packages

Thus, it was successfully demonstrated that:

Key Satcom components could be virtualized and deployed on standard server hardware as VNFs.

Standard Opensource environments could be used to deploy the Satcom VNFs from a centralised location that was located remotely from the Satcom components and connected over the public internet.

All the virtual Satcom components could be deployed easily and together with a single click and the Satellite path was initialised and became up and running.

Satcom services could be established from an external Orchestrator system via SDN techniques.

SaT5G (761413) D4.1 DEC 2019

of 75

5 Implementation of Satellite SDN & Orchestration in Testbeds

Section 4, Virtualization of Satcom Elements, introduced the ETSI NFV-MANO architecture [5], and presented its NFVI, VNF, and Virtualization Layer elements within the context of satellite network function virtualization in WP4.1. This section builds on that initial discussion, exploring how satellite networks that incorporate the virtualized satellite network functions described in Section 4 leverage SDN and Orchestration technologies in the 5GIC and Zodiac testbeds, respectively.

Software defined networking (SDN) is a concept in which network components expose APIs that may be invoked by third parties to modify the component’s behaviour. Orchestration then is the coordination of SDN-enabled (virtualized) network functions to provide an end-to-end network service. The ensuing discussion around SDN and orchestration in satellite networks is presented once again through the lens of the ETSI NFV-MANO architecture, which, for readability, repeated in Figure 5-1: ETSI NFV reference architectural framework .

Figure 5-1: ETSI NFV reference architectural framework 2

5.1.1 Selected Virtual Infrastructure Manager - OpenStack Section 4 introduced the virtualization layer, which in the context of the 5GIC testbed is facilitated by KVM. While KVM performs virtualization of the underlying physical hardware, a higher-layer element known as the Virtual Infrastructure Manager (VIM) is required to support SDN Orchestration. The remit of the VIM incudes allocation and provision of H/W resources in response to user-defined criteria, management of VM lifecycle, and provision of a northbound API for integration with an SDN Orchestrator. For the 5GIC testbed, OpenStack was selected as the VIM.

OpenStack is an Open Source platform that enables users to deploy private and public clouds using virtualized elements. As one of the most prominent and widely deployed SDN frameworks (both commercially and non-commercially), OpenStack’s usability, stability, and performance have been proven industry-wide. Accordingly, iDirect selected OpenStack as the VIM for development of the WP4.1 prototypes on the 5GIC testbed. The selection of OpenStack as the VIM was also influenced by the existing deployment of OpenStack as the incumbent VIM in the 5GIC network. In later phases, iDirect would deploy some of the satellite virtual network functions on 5GIC testbed. With reference to the NFV reference architecture, OpenStack provides support for the NFVI layer by providing compute, storage, and network resources.

2 Source: https://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.01.01_60/gs_NFV002v010101p.pdf

https://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.01.01_60/gs_NFV002v010101p.pdf

SaT5G (761413) D4.1 DEC 2019

of 75

The resources provided by OpenStack are partitioned into a set of disparate projects, as illustrated in Figure 5-2: OpenStack logical architecture . Of the numerous available OpenStack services, those that iDirect availed of in the 5GIC testbed PoCs are as follows:

Nova: implements OpenStack’s compute service; enables users to create Virtual Machines, either directly via the Nova and/or OpenStack APIs, or via the OpenStack WUI (Horizon)

Neutron: implements OpenStack’s networking service; enables users to create and manage logical networks, subnets and virtual NICs

Glance: implements OpenStack’s image service; enables users to create template VM images, from which VMs are instantiated

Swift: OpenStack’s object storage service; iDirect don’t use Swift directly, however Glance stores its VM images using Swift

Horizon: OpenStack’s Web-User interface (WUI), from which users may create and configure clouds and their constituent parts

It is worth noting that while the various OpenStack nodes presented in Figure 5-2: OpenStack logical architecture are potentially distributable across multiple disparate nodes, iDirect consolidated all applicable nodes (Network, Compute, Dashboard and Cloud Controllers) on a single physical COTS server in the scaled down Goonhilly teleport deployment.

Figure 5-2: OpenStack logical architecture 3

5.1.2 Evaluation of OpenStack as a VIM for Software-Defined Satellite Networks Within the context of the 5GIC testbed, iDirect deployed OpenStack in two locations: initially, in the SES-based teleport as part of the initial prototype/EuCNC 2018 testbed architecture, and secondly in the Avanti teleport as part of all other testbed architectures. iDirect also integrated with the OpenStack deployment at the 5GIC

3 Source: https://docs.openstack.org/arch-design/design.html

https://docs.openstack.org/arch-design/design.html

SaT5G (761413) D4.1 DEC 2019

of 75

Central network node as part of the OSM orchestrated deployment. This section evaluates OpenStack’s suitability as a VIM for SDN satellite networks in this context.

Ease of installation As mentioned previously, iDirect selected the RDO flavour of OpenStack; this is a pre-packaged All-In-One (AIO) OpenStack installation package provided by Red Hat, which simplifies the OpenStack installation process on Red Hat Enterprise Linux (RHEL) and its derivatives. RDO enables users to quickly prototype single-node cloud deployments; “single-node” in this context refers to the colocation of all OpenStack node types on a single physical system.

The initial RDO installation, which included the Pike of OpenStack release, proved extremely problematic. The installation process, performed by the RDO packstack installer, frequently stalled (for hours in some cases), or failed with the vaguest of error messages; this lead to extended troubleshooting periods, and in some cases required reinstallation of the host system’s Operating System (as a result of a partially-completed installation, which could not be cleanly removed, thus preventing additional installation attempts). However, following upgrade to OpenStack Queens release, RDO installation was straightforward and completed promptly, enabling iDirect to deploy their satellite VNFs in the Avanti Teleport quickly.

VNF deployment OpenStack was used to provision virtual networks, virtual machines, and through a combination of both, virtual satellite services. iDirect deployed these virtual resources initially via a combination of local command-line OpenStack API invocations, and the OpenStack WUI, Horizon. This process was long, laborious, and frequently error-prone. However, OpenStack exposes a comprehensive, unified API for all of its services, which enabled iDirect to adapt and expand the individual command-line API calls (previously invoked as part of the initial prototype) into a comprehensive, configurable automated deployment framework. iDirect leveraged this automated framework for the third 5GIC testbed increment, which considerably expedited deployment of the Avanti teleport and its satellite VNFs. In addition to a local CLI, OpenStack also provides a RESTful API to remote clients in multi-node deployments.

OpenStack provides a range of useful utilities that simplify configuration of VNF instances. Chief among these is inbuilt support for cloud-init, which is a utility for initialisation of VMs. Cloud-init enables users to tailor generic cloud images as specific network functions, via installation of specific software packages and execution of VNF-specific configuration scripts. OpenStack also supports VNF version control, with its snapshot feature. Snapshots capture the state of an OpenStack VNF at a given point in time, enabling users to restore a VM to a known good state and/or create a new VM based on that state. This is useful in the event that a VNF becomes corrupt, and provides redundancy since multiple instances of a VNF may be run in parallel and interchanged in the event of failure.

Orchestrator Integration OpenStack exposes a Northbound API, enabling interoperation with Orchestrators. The VNFs that iDirect developed were deployed on a non-orchestrated OpenStack system initially; from that system, the OSM VNFDs and NSD for the satellite Gateway and L2oS functions were derived, enabling deployment of those VMs on the 5GIC OpenStack platform, via OSM. Given the ease of integration between OpenStack and OSM, and the simplified and automated deployment of the 5GIC Central node’s satellite network service segment via OSM, the installation of an Orchestrator such as OSM at the Teleport, and deployment of all satellite VNFs using descriptors is recommended over deployment using OpenStack only.

Usability The OpenStack WUI, Horizon, provides a user-friendly and intuitive user interface that enables users to provision cloud instances, as illustrated in Figure 5-3: Horizon: OpenStack Web User Interface (WUI).

SaT5G (761413) D4.1 DEC 2019

of 75

Figure 5-3: Horizon: OpenStack Web User Interface (WUI)

In the Horizon screen above, users can select from the various tabs and sub-tabs on the left of the screen the specific resources that they wish to deploy (i.e. Network, Compute, etc.). Most resource types provide a creation wizard that intuitively guides the user through the process, which is commendable. However, this user-friendliness comes at a price; Horizon only exposes a limited subset of the underlying OpenStack API, which can be restrictive. For example, once a static IP address is assigned to a port in Horizon, it is immutable; i.e. the user cannot assign a different IP to that port via Horizon, as illustrated in Figure 5-4: lack of capability for port IP modification in Horizon.

Figure 5-4: lack of capability for port IP modification in Horizon

In contrast, port IP assignation and modification are fully supported by the OpenStack CLI; by simply setting the ‘fixed-ip’ property of the port, the user has full control over a port’s IP address assignation, as demonstrated in Figure 5-5: port IP assignment and modification in OpenStack CLI. The port in question, dummy_test_port, initially has no fixed IP address; it is subsequently assigned the IP address 192.168.252.105 via the OpenStack CLI, which is subsequently modified to 192.168.252.104 in the final CLI. This example demonstrates both the versatility of the OpenStack CLI, and the inherent limitations of the Horizon WUI; the former is useful for novice users, but in order to get the most from a cloud deployment, experienced users will likely favour the latter.

SaT5G (761413) D4.1 DEC 2019

of 75

Figure 5-5: port IP assignment and modification in OpenStack CLI

Rounding off the discussion on usability it should be noted that the error messages provided by OpenStack seem vague and unhelpful in general and this is particularly obvious within the Horizon WUI. In order to diagnose and resolve an issue, it is usually necessary to delve into the underling Operating System logs and/or the specific OpenStack project’s logs; for novice OpenStack users, this may prove challenging.

Cost and Support RDO OpenStack is an OpenSource community-driven initiative, and as such, it is provided free-of-charge for both lab and commercial use. The RDO community provides best-effort support, but commercial support for RDO is unavailable. If commercial support is required, then Red Hat provide their own OpenStack distribution (Red Hat OpenStack Platform), specific cost details of which are unavailable publicly.

5.1.3 Selected Orchestrator - Open Source Mano (OSM) A key component of an SDN system is the Orchestrator, which manages and coordinates underlying network resources to provide end-to-end network services for end-users. Numerous Orchestrator and SDN Controllers (which implement Orchestration functionality) are available today, popular examples of which include OpenDaylight, Open Network Automation Platform (ONAP), Cloudify, and Open Source Mano (OSM). OSM Release 5 is the Orchestrator deployed in the 5GIC testbed for SaT5G.

Open Source MANO (Management and Orchestration) is an ETSI-driven initiative to implement an Open Source approach to Orchestration that is compliant with ETSI NFV. In order to deploy network services, OSM uses a set of descriptors that describe the underlying resources required to implement that service. OSM places descriptors in two distinct categories: those that describe the virtual resources required by the VNFs themselves (compute, memory, network, etc.), and those that describe the network topology and interconnections of VNFs that comprise the network service. These are referred to as Virtual Network Function descriptors (VNFD), and Network Service Descriptors (NSD), respectively, and are written in the YANG data modelling language. YANG is a human-readable data modelling language, which supports encoding of configuration data via XML and JSON. YANG typically goes hand-in-hand with the NETCONF protocol.

In order to integrate their satellite VNFs with the 5GIC-deployed OSM, iDirect developed a series of OSM Virtual Function Descriptors and a corresponding Network Service Descriptor for a subset of the satellite VNFs that were originally deployed at Avanti’s Goonhilly teleport. This effort would consequently support the migration of satellite VNFs from the teleport to the Central network node in 5GIC. The VM migration effort is covered in detail in Satellite VNF Migration, and introduction of Satellite Security VNFs.

5.1.4 Satellite Network Service, VNF and Infrastructure Description – OSM Figure 5-6: 5GIC Testbed Architecture pre-VM migration illustrates the position of certain satellite VNFs in the Avanti teleport at the time of the EuCNC 2019 demonstrations. iDirect identified two satellite VNFs for migration from the Goonhilly Teleport to the Central network node in 5GIC; specifically these VMs were the Satellite Gateway Function and the Layer 2 over Satellite (L2oS) Function.

SaT5G (761413) D4.1 DEC 2019

of 75

Figure 5-6: 5GIC Testbed Architecture pre-VM migration

The Satellite Gateway Function provides an entry point into the satellite datapath for end users within the Remote 5GIC network node; the end-users in this case comprise of use case VMs and 5GIC core network’s control plane elements. The Satellite Gateway Function provides routing functions for traffic between the end users and the satellite network. . The L2oS function, accepts traffic from the Satellite Gateway Function, encapsulates it within an Layer 2 Tunnelling Protocol (L2TP) tunnel, and forwards it towards the 3GPP core network function (located in the Goonhilly Teleport), via a Layer 2 VPN.

In order to integrate with OSM, iDirect, in conjunction with 5GIC, produced two VNFDs: one for the Satellite Gateway Function, and another for the L2oS Function. iDirect and 5GIC also collaborated to produce an NSD to describe the network service provided by both VNFs. The VNFDs were complemented by cloud-init scripts that performed first-boot instantiation of the satellite VNFs.

The virtual satellite network service and its constituent functions were packaged for the ETSI OSM Orchestrator using its YANG modelling framework, and the network service package was deployed by OSM on the 5GIC testbed using the 5GIC Exchange (5GICE) brokerage software. 5GICE is middleware that enables end-users to request deployment of their network services to run on one or multiple testbeds, where each testbed is controlled and orchestrated independently by potentially different authority domains.

5.1.5 Summary of SDN & Orchestration in 5GIC Testbed Table 5-1: Summary of 5GIC Testbed Satellite SDN and Orchestration details the implementation of satellite SDN and Orchestration within the various locations in the 5GIC testbed. The remote network node consists of two physical satellite appliances (specifically, the satellite router and a MEC server), and as such, no provision is made for either SDN or Orchestration. A VIM (OpenStack Queens) at the teleport provisions and deploys satellite VNFs, and while no formal Orchestrator is installed therein, satellite VNFs are nonetheless deployed automatically, via the scripted automated deployment framework developed by iDirect. Finally, the Central node incorporates a fully orchestrated satellite service, facilitated by OSM Network Service and VNF descriptors produced by iDirect.

Table 5-1: Summary of 5GIC Testbed Satellite SDN and Orchestration

Network Node

Location Orchestrator VIM Service, VNF and Infrastructure Description

Remote 5GIC N/A N/A N/A

Teleport Goonhilly OpenStack Queens

Central 5GIC OSM OpenStack Queens Satellite service descriptor, L2oS VNF descriptor,

Sat. Gateway Function descriptor

SaT5G (761413) D4.1 DEC 2019

of 75

5.2 ZII Testbed The virtualized infrastructure developed by the ZII test-bed for demonstrating SaT5G UC4 is shown in Figure 5-7: ZII test-bed virtualized infrastructure.

Figure 5-7: ZII test-bed virtualized infrastructure

From top-down, we can find the following layers:

1. The Orchestration Layer, 2. The Service Layer, 3. The NFVI Layer, 4. The Satcom Layer.

The Orchestration Layer is responsible for giving access to an operator or a third-party service provider to the virtualized infrastructure. The concept of operator in this context is enlarged to either a single business entity that owns both satellite and terrestrial networks as well as to the result of a negotiation agreement between one or more satellite operators and one or more mobile network operators, whose outcome is to lease resources to another operator. Specific variants of this model have been investigated in SaT5G WP2, which has introduced the concept of the Broker, a business layer that enables dynamic negotiation of resources over multiple network segments and between different entities. In the context of aviation, the role of an operator can be assigned to an airline or to an existing operator on-board aircrafts (e.g. OnAir). On the other hand, a third-party service provider can be any stakeholders that is willing to deploy aeronautically certified services on-board aircrafts. In the specific context of SaT5G UC4, the orchestration layer is divided in two different sub-layers:

From the network management standpoint, TALENT is the highest entry point to the virtualized system that allows deploying and configuring virtualized network services, thus taking the role of the Operational Support System (OSS) of an operator. The TALENT software is developed and maintained by the SaT5G partner i2CAT. Furthermore, in the northbound, TALENT is the management layer that can be interfaced with the Broker developed in WP2, although this step is not done in the ZII test-bed due to the fact that satellite integration activities were prioritized. Main features of TALENT consist in multi-orchestration, multi-domain management of the Network Functions Virtualization Infrastructure (NFVI). Besides command line operations, TALENT offers also a GUI from which network services are deployed. In the southbound, TALENT is integrated with the network service Orchestrator OSM by

SaT5G (761413) D4.1 DEC 2019

of 75

means of REST application programming interface (API). TALENT is not only the entity that onboards the network service packages and the descriptors for OSM, but it is also used to configure the satellite service passing configuration parameters to the Gilat Sky Edge II-c system.

The ETSI Open Source MANO (OSM) release 5 is one of the network service Orchestrators with the widest consensus and support in the open source community. OSM makes use of the Juju charms to provide lifecycle management of the network services. In the northbound, OSM receives instructions from TALENT through REST calls, while in the southbound communicates with OpenStack. The approach taken by the ZII test-bed consists of deploying network service descriptors that invoke the virtualized network function descriptors. It is this assumed that once a network service is deployed from the scratch, it will not be modified unless deleted and re-instantiated according to a new set of requirements through the corresponding descriptors.

The Cloud manager OpenStack release Queens, which effectively manages the NFVI through the two OpenStack projects NOVA and Neutron. The former is responsible to load and deploy the images of the virtual machines, while the latter takes care of the networking aspects between virtual and physical network interfaces.

The Satcom Layer and the NFVI Layer have been described already in the previous section.

TALENT, OSM and OpenStack provide separate dashboards (e.g. Horizon in OpenStack) that give a graphical interface to the system administrator to deploy the virtualized service instances. In any case, at runtime, the test-bed relies only on the TALENT dashboard. A view of both TALENT and OSM dashboards is provided for completeness in Figure 5-8: TALENT, OSM dashboards.

Figure 5-8: TALENT, OSM dashboards

The Virtualized services deployed in the ZII test-bed are the following:

Satellite core network virtualization,

Mobile core network virtualization,

Content delivery network virtualization.

Regarding the satellite core network virtualization, as mentioned already, there are two different implementations for MEO and GEO that, respectively, for the end-to-end system use either of the Layer 2 VPN or the Layer 3 VPN:

In case of the Layer 3 connection, the Gilat Sky Edge II-c system has been virtualized to be deployed in an OpenStack compute node in Tel Aviv from the TALENT manager in Wessling. Specifically, the satellite system is split in a physical network function (PNF) and some virtualized components. The PNF is the C-Hub-Chassis, which is responsible for the baseband processing of the satellite signal. The virtualized components are the VxGW for Layer 2 connectivity, the virtualized network segment control (vNSC) and a vFunction block to carry out packet aggregation and improve the satellite bandwidth utilisation efficiency. Furthermore, the satellite hub system configuration is done by the TotalNMS, which is the network management system. In addition, the TotalNMS must receive the necessary instructions to configure the hub. In the ZII test-bed, configuration instructions are sent by TALENT through the northbound REST API.

On the other hand, for the satellite system that relies on the Layer 2 VPN, only the vFunction is the virtualized component in the ZII test-bed. This is due to the innovative but complex approach of integrating the Gilat modem, the SES 1.2m dual-antenna terminal and the MEO booster for the make-before-break satellite handover. In addition, it is worth mentioning that the Gilat modem has been configured in Single Channel per Carrier (SCPC) mode, which further reduces the required virtualized components.

SaT5G (761413) D4.1 DEC 2019

of 75

Regarding the mobile core network, there are also two different implementations:

In one case, it uses the virtualized 4G system provided by the partner Quortus but implementing CUPS.

In the second case, the Open5GCore [6], a prototype of a virtualized 5G core network is used.

In both cases, the mobile core is deployed from TALENT. In the 4G case, the virtualized mobile core is split into a MEC component and EPC component. The MEC component implements the user plane functionality of the S-GW and is instantiated on an OpenStack compute node in the aircraft cabin mock-up. It is worth mentioning that MEC and EPC communicate through the satellite link. For the 5G core network, the UPF function has been deployed on-board while the remaining part of the mobile core that is instantiated in the ZII datacentre. TALENT deploys both. In either case, the mobile core abides the 5G principle of splitting mobile core network functionalities in a virtualized environment to offer a composite service. Particularly, the edge component (either MEC or UPF) is used to steer traffic either to the Internet or to a local data network.

The content delivery network virtualization is the system that is used to cache content in a secondary catalogue made available on-board aircrafts (i.e. local data network) embracing the paradigm of Multi-access Edge Computing. The solution is provided in the ZII test-bed by the partner Broadpeak. The secondary catalogue, unlike the primary one (available in the central media server), is meant to be updated frequently with types of media content other than the one already available in the primary catalogue. The system for caching content on-board is composed of physical components (the system PNF) and virtualized components that are deployed from TALENT. The physical component is the nanoCDN, which contains the Video on Demand (VoD) secondary catalogue of cached content on-board. The virtualized components are the BkS350 (origin server), the BkS400 (cache and streaming server), the BkM100 (mediator) and the BkA100 (analytics server). Another key component of the caching system is the BkE200 that is responsible to initiate the multicast session to the nanoCDN. As mentioned, the multicast session is crucial to upload content to multiple aircrafts that are located within the same satellite beam. In the test-bed anyway, we found restrictions in the way the Open Virtual Switch network component handles a multicast type of traffic. Specifically, the multicast traffic is blocked by the virtual switch. For this reason, the BkE200 component was moved in the O3b Sintra Teleport outside the NFVI, but still being able to start the multicast session over the O3b satellite link connection.

SaT5G (761413) D4.1 DEC 2019

of 75

6 Model Driven Architecture and Satellite Service-Level API

6.1 Evolution of the Data Model At the outset of SaT5G, one of the WP4.1 goals was to research and produce a model-driven approach for implementing satellite VNFs, and associated service/processing chains. The aim here was to leverage prevalent modelling technologies such as YANG and NETCONF to describe low-level interfaces between disparate virtualized network elements in a vendor-agnostic way, thus promoting interoperability between vendors’ VNF offerings and yielding a common object-model, which vendors could use to produce 5G-compatible VNFs.

However, as research into the data model within WP4.1 proceeded and discussions among stakeholders progressed, it became clear that granularity at an inter-VNF was much too fine-grained. Instead during the course of requirements elicitation and discussion among stakeholders regarding what exactly a satellite VNF data model would look like, it became clear that what would be more useful is a common service-level model. Such a model would present a consistent interface for satellite services to end-users, under which vendors would be free to implement the service in their own way. Service APIs are growing increasingly prevalent in industry, where implementations such as MEF LSO (Lifecycle Service Orchestration) APIs are popular.

A service-level model achieves the goals set out by the initial data-model approach, specifically:

Promotes SDN and Orchestration capabilities of satellite networks (assuming that resultant API is exposed north-bound to an Orchestrator)

Reduces complexity of satellite network configuration, as user may leverage a common interface, irrespective of vendor.

o Vendor-specific implementation of an API is still required, albeit abstracted via the common interface

o Vendor-neutrality promotes increased use of Satcom solutions/mitigates against fear of vendor lock-in from Third Party’s perspective

The remainder of this section describes a prototype service-level API, which enables third parties to dynamically activate and deactivate satellite services, on-demand. The API’s design promotes its use in a multi-provider network that conforms to a hybrid satellite/terrestrial network architecture. While Mobile Network Operators (MNOs), Service Providers, and/or similar third parties (collectively referred to henceforth as ‘Third Parties’) manage the mobile network, the Satellite Network Operator (SNO) manages the satellite network quite separately. 5G introduces the concept of network slicing, in which users may dynamically create E2E services on-demand. While this concept works well in purely terrestrial networks, questions arise when a satellite backhaul is introduced to bridge disparate terrestrial network segments. Can the backhaul link satisfy the network slice’s requirements? If so, how does the terrestrial network dynamically activate the satellite backhaul segment of a network slice? It stands to reason that in order to answer these questions, the satellite link must provide some level of visibility and/or control for Third Parties. What follows is a description of a first-pass satellite service API implementation that aims to address these concerns.

6.2 Overview of Satellite Services Within the context of the proposed satellite service-level API, a satellite service is comprised of the following:

One or more pre-existing SVNs (Satellite Virtual Networks). These are logical satellite links, which an

SNO configures and deploys via the satellite NMS. The SNO may configure each SVN with its own

specific link characteristics, such as QoS, Committed Information Rate (CIR), Maximum Information

Rate (MIR), etc. for differentiated Over the Air (OTA) services.

A Satellite Gateway. This is an endpoint, towards which the Third Party directs their IP traffic, for

transmission over a specific satellite service.

A Satellite Service Identifier (SSI). This is an alphanumeric string, which intuitively describes the

underlying level of service provided. The specific characteristics of each service type is defined may be

agreed upon at a business-level by the SNO and the Third Party, and subsequently deployed as SVNs by

SaT5G (761413) D4.1 DEC 2019

of 75

the SNO. The Third Party later uses the service identifier when invoking the Satellite Service API to query

and/or modify individual satellite services.

The satellite gateway API currently supports the following SSIs: o BEST_EFFORT (default service level – always active, immutable)

o GOLD (highest service level)

o SILVER (intermediate service level)

o BRONZE (lowest non-default service level)

NOTE: the service levels described in this section refer to enterprise-level services, agreed between the SNO and Third Party. These are aggregate service levels, implemented by the SNO, and made available to the Third Party via the Satellite Service APIs. It is subsequently the Third Party’s remit to enforce service levels for individual users.

6.3 Satellite Service API Architecture The Satellite Service API exposes a RESTful API for querying and modifying satellite services. As it conforms to REST conventions, the API exposes its functionality via standard HTTP GET/PUT requests, which lends itself to straightforward integration with management-level applications (for example, TALENT by i2CAT). A draft service-level architecture, incorporating TALENT integration is presented in Figure 6-1: Satellite Service API Draft Architecture.

Figure 6-1: Satellite Service API Draft Architecture

6.4 Reference Implementations of Differentiated Satellite Services Section 6.2 introduces the high-level Satellite Service Identifiers (SSIs) that intuitively describe the overall quality of service provided by individual satellite services. These identifiers are intentionally abstract, enabling the SNO to implement and tailor services based on a combination of link-specific parameters, as agreed with the third party service provider who will use the satellite service. Here we present two reference implementations of differentiated satellite services based on disparate link-specific parameters. It is worth reiterating at this point that the service levels considered here are aggregate-level services between an SNO and third party; it is the third party’s remit to enforce subscriber-level service on their end, subsequently.

The implementation of differentiated satellite services described in this section is relatively straightforward; in summary, an SNO statically divides their RF resources into distinct slices upfront and subsequently advertises them externally via a simple identifier. To slice the satellite link, the SNO first creates a number of disparate services at an RF level, via their proprietary Network Management System (NMS). The satellite NMS enables the

Satellite Network Operator Domain

Mobile Network Operator Domain

REST

Business Applications(OSS/BSS)

TALENTSAT Service API

SAT GW VNF MANO

SaT5G (761413) D4.1 DEC 2019

of 75

SNO to explicitly define various characteristics of the forward and return carriers, as per the knobs exposed by the NMS’ command line interface (CLI) or Web User Interface (WUI). For the purposes of this discussion, we refer to these SNO-created services as ‘Satellite Virtual Networks’ (SVNs). The SNO creates an SVN for every service that it intends to support (or that the third party wishes to avail of) based on a specific set of carrier-level characteristics exposed by the satellite NMS, and subsequently allocates an SSI for each. The total number of satellite services (i.e. SSIs) that the SNO must support dictates the number of required SVNs.

Taking a simplistic example, one link-level trait by which an SNO can differentiate the satellite services that it offers is bandwidth. In satellite parlance, the attributes that describe link bandwidth are the Committed Information Rate (CIR) and the Maximum Information Rate (MIR). The CIR is the minimum bandwidth guaranteed by the SNO under normal operating conditions; i.e. it is the minimum assured link bandwidth. Conversely, the MIR is the highest potentially achievable bandwidth that a link offers, i.e. maximum link bandwidth. In such a scheme, the Gold level service/SSI corresponds to the service with the highest available Committed and Maximum Information Rates (CIR, MIR) in both upstream and downstream links; the Silver level corresponds to the service with the second-highest CIR/MIR, and so on. The SNO may assign per-service CIR and MIR values unilaterally, or more likely, based on a commercial agreement with the third-party service provider.

While link bandwidth differentiates individual satellite services in the previous example, the SNO may allocate diverse services based on a range of alternate link characteristics, including for example Quality of Service (QoS). QoS refers to a set of mechanisms that support classification and prioritisation of traffic, such that higher priority traffic receives preferential treatment over its lower-priority counterparts. Scheduling policy is just one example of QoS characteristics supported by the iDirect NMS, enabling SNOs to define SVNs with distinctive service levels. A scheduling policy is a hierarchical classification scheme by which data packets/segments are arranged (typically in queues) for reception/ transmission in order of a pre-assigned priority. Packets/segments placed in queues with a higher priority ultimately pre-empt those that reside on lower-priority queues, with the net effect that the related link incurs a lower latency and higher throughput rates than its lower-priority counterparts. In this context, the Gold level service utilizes a priority queue scheduling type, which assigns its traffic to the highest-priority queue. In contrast, the Best Effort service is limited to a best effort scheduling type, which only processes its traffic once all priority queues are empty.

Table 6-1: Sample Implementation of Differentiated Satellite Services presents a comparison of sample implementations of the Gold and Best Effort level services, in which the aforementioned link bandwidth and scheduling policy attributes jointly define (and consequently differentiate) each service level.

Attribute Service Level

Gold Best Effort

Inbound CIR (Mbps) 40 5

Inbound MIR (Mbps) 60 10

Inbound Priority 1 4

Outbound CIR (Mbps) 100 20

Outbound MIR (Mbps) 150 30

Outbound Priority (lower is better) 1 4

Scheduling Type PriorityQueue BestEffort

Priority Queue (lower is better) 1 N/A

Service Gateway 192.168.50.10 192.168.0.10

Service Level Gold Best Effort

Service State Inactive Active

SVN 50 1

Table 6-1: Sample Implementation of Differentiated Satellite Services

SaT5G (761413) D4.1 DEC 2019

of 75

From a link bandwidth perspective, the Gold level service provides a minimum outbound rate of 100 Mbps, with a potential maximum rate of 150 Mbps. In comparison, the Best Effort level (i.e. the default service level) provides a significantly lower guaranteed outbound rate of 20 Mbps and a maximum rate of 30, representing a 5x bandwidth rate differential on the outbound link. One observes similar disparities when comparing the inbound link’s CIR and MIR values: whereas the Gold level service provides committed and maximum rates of 40 and 60 Mbps, respectively, the Best Effort level service can only support corresponding rates of 5 and 10 Mbps.

A preferential Priority Queue scheduling policy, in contrast to the Best Effort-level service’s Best Effort approach, complements the higher bandwidth capabilities of the Gold-level service. In the case of the former, packets are placed in the highest priority queue (queue 1 in this case) for transmission and reception; as such, packets in those queues need only contend with packets of the same priority, and also avoid pre-emption. The net effect of this is that high-priority packets incur less latency than packets in lower-priority queues (since congestion is minimal), and significantly less latency and/or drops than packets with a Best Effort scheduling policy.

It is worth noting that the SSIs and corresponding service level implementations covered in this section are purely for illustrative purposes, and can be amended or extended in line with the number of service levels required, and the specific characteristics of each service.

6.5 Reference invocations of Satellite Service API This section presents a subset of the currently implemented RESTful APIs exposed by the satellite network. Specifically, this section outlines how an end user might use the API to query the details and status of a particular service, and subsequently activate it.

6.5.1 Query the details of the Gold-level Satellite Service The end user invokes the API to retrieve the details and status of the Gold satellite service; ‘status’ in this context refers to whether the service is active or inactive. In this example, the satellite service resides on port 5001 of the system with IP address 10.175.129.78

curl http://10.175.129.78:5001/api/v1.0/services/GOLD

The server responds with the details and status of the Gold service, which is inactive.

[

{

"inbound_cir_mbps": "40",

"inbound_mir_mbps": "60",

"inbound_priority": "1",

"outbound_cir_mbps": "100",

"outbound_mir_mbps": "150",

"outbound_priority": "1",

"priority_queue_id": "1",

"scheduling_type": "priority queue",

"service_gateway": "192.168.50.10",

"service_level": "gold",

"service_state": "inactive",

"svn": 50

}

]

6.5.2 Activate the Gold-level Satellite Service The end-user wants to avail of the Gold-level service; in order to do so, they must request activation of the service via the API:

curl -kH -X PUT -H "Content-Type: application/json" \

-d '{"service_state":"active"}' \

http://10.175.129.78:5001/api/v1.0/services/GOLD



SaT5G (761413) D4.1 DEC 2019

of 75

The server responds with an HTTP return code of 200, indicating the API executed successfully. In addition, the server returns a copy of the updated Gold-level service object, in which the service_state attribute has now been changed to ‘active’.

[

{

"inbound_cir_mbps": "40",

"inbound_mir_mbps": "60",

"inbound_priority": "1",

"outbound_cir_mbps": "100",

"outbound_mir_mbps": "150",

"outbound_priority": "1",

"priority_queue_id": "1",

"scheduling_type": "priority queue",

"service_gateway": "192.168.50.10",

"service_level": "gold",

"service_state": "active",

"svn": 50

}

]

SaT5G (761413) D4.1 DEC 2019

of 75

7 Proof of Concepts for WP5 Testbeds

7.1 Overview This section covers the research and development performed in WP4.1 and the resultant Proof-of-Concepts that act as inputs to the WP5 testbeds. Each PoC exercises a subset of the 5G use cases identified in WP2.1. As in previous sections, dedicated sub-sections address each testbed, starting with the 5GIC testbed in sub-section 7.2, followed by the Zodiac testbed in sub-section 7.3.

7.2 5GIC Testbed Section 3.2, Selected Architectures for 5GIC Testbed covers the final 5GIC testbed composition and network architecture in detail. This section then, documents the prototype architectures and PoCs that ultimately lead to the implementation of final testbed architecture. Table 7-1: 5GIC Testbed Satellite Increments provides an overview of the prototype testbed deployments that iDirect produced during WP4.1; each increment is covered in a following subsection.

Table 7-1: 5GIC Testbed Satellite Increments

Testbed Increment ID

Remote Node

Teleport Central Node

Incremental Improvements to satellite network

Prototype Integrated Satellite/3GPP Network

iDirect, Killarney, Ireland



N/A – initial prototype

EuCNC 2018 EuCNC, Ljubljana, Slovenia

SES, Betzdorf, Luxembourg

5GIC, Surrey, UK

Remote, Teleport, and Central nodes migrated to target locations

Live satellite (ASTRA-2F) integrated

Support added for use case applications from central and remote nodes

Static multicast routing implemented for Broadpeak multicast use case

Dedicated Layer 2 VPN link from 5GIC central node integrated into teleport

EuCNC 2019 5GIC, Surrey, UK

Avanti, Goonhilly, UK

5GIC, Surrey, UK

Completely new logical satellite network constructed from scratch

Remote node migrated to 5GIC

New Teleport installed with physical ground equipment and satellite VNFs

Satcore upgraded from Release 11 to Release 15 (LTE)

SatRAN and satellite modem software versions upgraded to support Release 15 core

Support added for additional E2E use cases/applications

Dedicated Layer 2 VPN link from 5GIC central node integrated into teleport

Upgraded OpenStack from Pike to Queens release, in line with 5GIC

SaT5G Industry Day

5GIC, Surrey,

Avanti, Goonhilly,

5GIC, Surrey,

Subset of satellite VNFs migrated from teleport to 5GIC central node

SaT5G (761413) D4.1 DEC 2019

of 75

Testbed Increment ID

Remote Node

Teleport Central Node

Incremental Improvements to satellite network

UK UK UK YANG descriptors for OSM produced to facilitate deployment of 5GIC-resident satellite VNFs via OSM Orchestrator

Final 5GIC, Surrey, UK

Avanti, Goonhilly, UK

5GIC, Surrey, UK

Satcore upgraded to Release 15 5G core

SatRAN and satellite modem software versions upgraded to support 5G Satcore integration

It is worth noting that with respect to the 5G use cases identified in WP2.1, the 5GIC testbed demonstrates the following three:

Use Case 1: Edge delivery & offload for multimedia content and MEC VNF software

Use Case 2: 5G Fixed backhaul

Use Case 3: 5G to premises

7.2.1 Prototype Integrated Satellite/3GPP Network The first prototype network developed by iDirect was a lab-based system, constructed entirely within the confines of iDirect’s internal infrastructure. This system piloted virtualization of satellite network functions, use of OpenStack (Pike release) as a VIM for deployment of logical resources and Satellite VNFs, and integration of a COTS Release 11 3GPP LTE network into an E2E satellite network. iDirect configured a complete logical satellite network (as per a commercial satellite network) via their in-house satellite NMS, and utilised a noise generator for emulation of the satellite link. The final prototype, illustrated in Figure 7-1: iDirect Prototype Integrated Satellite/3GPP Network constituted a complete logical satellite network, including virtualized satellite network functions within an Intermediate Frequency (IF) Domain.

Figure 7-1: iDirect Prototype Integrated Satellite/3GPP Network

To expedite deployment of subsequent PoCs, iDirect developed a scripting framework to automatically install OpenStack on a virgin Operating System (OS), and subsequently invoke OpenStack APIs for automated deployment of the entire virtualized satellite network. The scripting framework, implemented in BASH, supported heterogeneous deployment configurations, underpinned by a user-populated centralised config file (i.e. the framework did not rely on testbed-specific hardcoded values).

The prototype integrated satellite/3GPP network was subsequently refined and expanded to include SES’ ASTRA-2F satellite for the EuCNC 2018 demonstrations.

SaT5G (761413) D4.1 DEC 2019

of 75

Inputs to 5GIC Testbed 1) Automated deployment framework: the BASH scripting framework that iDirect developed was re-used

to install OpenStack and satellite VNFs in the 5GIC teleport at Goonhilly 2) Virtualized satellite VNFs: Satellite VNF template images, including the integrated 3GPP core network,

were re-deployed at the 5GIC teleport and 5GIC central node in the final testbed implementation 3) 3GPP Satcore integration: the modifications made to the satellite appliances to integrate with a COTS

3GPP network were carried forward into the 5GIC teleport in Goonhilly 4) Learnings and solutions to technical issues: resolutions to problems that were encountered and

resolved during the course of the network deployment were carried forward, expediting implementation of the 5GIC teleport and 5GIC central node in subsequent testbed increments

7.2.2 EuCNC 2018 Demonstrations The first public demonstration for SaT5G took place at EuCNC 2018. European Conference on Networks and Communications (EuCNC) is a series of networking and telecoms-focused symposiums, funded by the IEEE Communications Society and the European Association for Signal Processing. The yearly conference has a specific focus on 5G, and aims to highlight bleeding-edge developments in, and present the latest results of, EC-sponsored 5G-centric R&D projects. The conference program contains, among other sessions, Keynotes, Workshops, and Demos. Given the advanced progress demonstrated with the initial iDirect lab PoC, SaT5G partners selected it as the basis for a SaT5G demo at the 2018 EuCNC conference.

Demo Overview The aim of the SaT5G demo for EuCNC 2018 was to highlight the key innovations and development ongoing within WP4 and WP5. At a high level, the demo displayed the work conducted in WP4, which enabled virtualization of Satcom elements, and demonstrated integration of a satellite network with a 3GPP counterpart. It further demonstrated how over-the-top (OTT) service providers could leverage the power of satellite broadcast to deliver 3GPP-originated multicast traffic to a remote UE via a live OTA satellite link. For WP5, the demo also showcased the efficient delivery of remote content over satellite, by prefetching and edge caching.

Demo Architecture The SaT5G EuCNC demo constitutes a multi-site architecture, which spans across numerous countries, as illustrated in Figure 7-2: SaT5G EuCNC 2018 Demo Architecture. On the far-left of the diagram, one observes the remote network node; this is the network segment containing the satellite antenna (VSAT), remote terminal, and user equipment that avails of the OTT services (such as the Broadpeak nanoCDN platform and video player application). While originally resident in Killarney during preparation of the demo, iDirect subsequently migrated the entire remote node to the EuCNC 2018 conference site in Ljubljana, Slovenia. This migration included the installation of an onsite VSAT to facilitate the demo. The remote node connects to the SES teleport via the SES ASTRA-2F satellite.

Moving to the central blue node in Figure 7-2, one can observe the physical satellite ground equipment (antenna, hub chassis, line cards, NFVI server), and virtual network functions that comprise the teleport. Installed in Killarney as part of the initial prototype, the entire set of physical and virtual appliances was migrated to the SES teleport in Betzdorf, Luxembourg ahead of the EuCNC conference.

SaT5G (761413) D4.1 DEC 2019

of 75

Figure 7-2: SaT5G EuCNC 2018 Demo Architecture

On the right of the diagram, one observes an early iteration of the testbed’s 5GIC central network node. The central network node is an integral component of all of the 5GIC testbed PoCs, and typically houses the 5GIC core network, NFVI, and application-level systems (such as the Broadpeak Content Data Network (CDN) in this case). One can consider applications running in the remote network node as clients of applications running in the central node. The 5GIC central node connects to the SES teleport via a dedicated Layer 2 VPN connection, provided by Jisc on their Janet network.

List of Demo Elements This section outlines the individual elements that comprised the demo. Table 7-2: List of EuCNC 2018 Demo Elements details the elements that were present at each location within the demo, highlighting the SaT5G partner that supplied the element, and providing a brief description of each element.

Table 7-2: List of EuCNC 2018 Demo Elements

Location Element Supply Partner

Description

EuCNC, Ljubljana, Slovenia

X7 Satellite Remote iDR Physical system that connects to an onsite VSAT to provide satellite access for end users

Acts as a relay node for the MNO UE

Presents as a standard 3GPP UE to the 3GPP Core

nanoCDN (MEC platform) BPK Physical system that hosts BPK nanoCDN application

Subscribes to multicast traffic streams distributed by the BPK CDN that is resident in 5GIC

Performs multicast-to-unicast conversion delivers content to UE (tablet/video player) via unicast

SaT5G (761413) D4.1 DEC 2019

of 75


Description

Tablet/Video player application BPK Physical tablet that hosts BPK video player application

Player retrieves content streams from nanoCDN (via HLS)

Space Segment GEO Satellite (ASTRA-2F) SES Provides geostationary Ku-band

capacity for OTA traffic

SES Satellite Teleport, Betzdorf, Luxembourg

Satellite RF Uplink/Downlink Facilities

SES RF uplink/downlink 9m Ku-band antenna stations located in SES Teleport, Betzdorf, Luxembourg

Satellite Hub Chassis iDR Houses satellite line cards

Satellite Line Cards x 2 (Rx, Tx) iDR Dedicated H/W resources that receive & transmit traffic over satellite

NFVI iDR COTS server that provides underlying physical resources to satellite NFVs

OpenStack iDR Virtual Infrastructure Manager that coordinates VM lifecycle

Pike release

Satellite RAN VNF iDR VNF that implements virtualized upper-layer satellite RAN functions

Satellite Core Network (VNF) iDR Standard COTS 3GPP Release 11 LTE Core VNF

Satellite L2oS VNF iDR VNF that facilitates Layer-2-over-Satellite datapath

Satellite Gateway VNF iDR VNF that routes application traffic to/from Satellite datapath

5GIC, University of Surrey, UK

NFVI UoS Physical server that houses VNFs

Supports orchestration and lifecycle management

OpenStack iDR Virtual Infrastructure Manager that coordinates VM lifecycle

Pike release

CDN BPK Content Origin Server and encoder

VPN

Layer 2 VPN SES Layer 2 VPN link between SES Teleport in Betzdorf, Luxembourg and SES Point-of-Presence (PoP) in Telehouse London, through SES terrestrial backbone access network

Layer 2 VPN UoS Layer 2 VPN link between SES PoP in Telehouse London and 5GIC through GEANT terrestrial backbone access network

SaT5G (761413) D4.1 DEC 2019

of 75

Results The EuCNC demo was highly successful, resulting in the following key wins for the SaT5G project:

Establishment of Layer 2 over Satellite (L2oS) datapath between geographically distributed satellite terminal and remote sites in a live hybrid terrestrial/satellite network

Demonstration of Release 11 3GPP LTE core network integration into satellite network

Integration of Broadpeak’s virtualized nano-CDN VNF into satellite terminal site

Achieved OTA streaming of 4K videos (via YouTube) to local conference site

Achieved OTA streaming of multicast streams from Broadpeak remote CDN to local nano-CDN

7.2.3 EuCNC 2019 Demonstrations

Demo Overview Following on from the success of EuCNC 2018, iDirect once again partook in the EuCNC conference in 2019. For the 2019 conference, iDirect provided the ground equipment and 5G-compatible satellite VNFs that, in concert with Avanti’s HYLAS-4 satellite, provided the OTA connectivity between the use case VMs resident on both remote and central network nodes. The use cases underpinned by the satellite connectivity and virtualized satellite network functions, demonstrated at the conference, were:

Multicast over satellite for edge caching and live content delivery

Over-the-air MEC-based layered video streaming via a 5G ‘multilink’ satellite and terrestrial network

Demonstration of local (MEC) content caching in 5G with hybrid backhaul network

Demonstration of Hybrid 5G Backhauling to extend services for rural markets and large-gathering

events

Demo Architecture The EuCNC 2019 demo architecture consisted of a multi-site network, spread across 5GIC in Surrey and Goonhilly Earth Station in Cornwall, as illustrated in Figure 7-3: SaT5G EuCNC 2019 Demo Architecture. Both central and remote network nodes resided in 5GIC, while a new teleport was deployed in Goonhilly.

Figure 7-3: SaT5G EuCNC 2019 Demo Architecture

SaT5G (761413) D4.1 DEC 2019

of 75

The remote and central nodes were equipped with the virtual and physical components that comprised the aforementioned 5G use cases. On the remote side, SWPs deployed their applications on a combination of VMs and physical servers, where each element connected to its counterpart on the central node via a satellite link (and via an additional restricted terrestrial connection in the case of multi-linking demos). A dedicated layer 2 VPN connected the 5GIC Central Node to the satellite VNFs in the Goonhilly teleport.

The teleport in Goonhilly hosted the satellite VNFs and physical hub & line cards that supplied OTA connectivity. The EuCNC 2018 demo infrastructure, in which the teleport, satellite VNFs and remote all resided in SES, Betzdorf had since been repurposed for the ESA-sponsored SATis5 project; consequently, iDirect needed to deploy an entirely new satellite network from first principles. This was a considerable undertaking, which required, among other things:

Installation of physical equipment in teleport, central, and remote network nodes

Deployment of NFVI server in teleport

Provision of Satellite VNFs via OpenStack in teleport

Configuration of the entire satellite logical network via iDirect’s in-house NMS

Configuration of L2 VPN connection from central node to teleport

Avanti provided satellite capacity via their high-throughput HYLAS-4 GEO satellite, and hosted the satellite hub and NFVI in their teleport at Goonhilly Earth Station. The satellite remote & antenna, along with the iDirect MEC server resided in the 5GIC remote node. The individual use case architectures are documented in Section 3.2.3, E2E Network Architecture.

List of Demo Elements Table 7-3: List of EuCNC 2019 Demo Elements


Description

EuCNC, Valencia

TeamViewer Application UoS Multilinking and MEC demos relayed to Valencia via TeamViewer connection.

Tablet BPK Broadpeak player that is installed on tablet retrieves content from the UoS-housed nanoCDN, via VPN connection.

Satellite Teleport, Goonhilly

Satellite Hub Chassis iDR Houses line cards

Satellite Line Cards x 2 (Rx, Tx) iDR Receive/transmit traffic over satellite

NFVI iDR COTS server running OpenStack (Queens release) that houses satellite VNFs

Satellite RAN VNF iDR Implements virtualized upper-layer satellite RAN functions

Satellite Core Network VNF iDR Standard COTS 3GPP Core Network VNF

Satellite L2oS VNF iDR Facilitates Layer-2-over-Satellite datapath

Satellite Gateway VNF iDR Routes application traffic to/from Satellite datapath

Space Segment Satellite (HYLAS-4) AVA Provides RF capacity for OTA traffic

Remote Node

5GIC, Surrey

iQ-DT Satellite Remote iDR Provides satellite access; acts as a relay node for the MNO UE. Presents as a UE to the 3GPP Core.

MEC Server iDR Routes application traffic to/from satellite modem

Test laptop UoS Relays BPK player screen to Valencia via TeamViewer

SaT5G (761413) D4.1 DEC 2019

of 75


Description

nanoCDN BPK Subscribes to multicast traffic streams; performs multicast-to-unicast conversion; delivers content to UE via unicast.

MEC Server UoS Performs local caching of UoS CDN content

NFVI UoS Houses VNFs; supports orchestration and lifecycle management

Central Node

5GIC Surrey

CDN Server UoS Provides video content for remote access

NFVI UoS Houses VNFs; supports orchestration and lifecycle management

Inputs to 5GIC Testbed The inputs to WP5.2 from the work performed by iDirect for EuCNC 2019 are significant. Chief among them is the establishment of a second live satellite network; a list of the primary technical contributions to WP5.2, itemised per location follows.

Teleport (Goonhilly)

Installation of ground equipment (hub chassis and line cards)

Installation of NFVI server and VIM (OpenStack, Queens release) on same

Deployment and configuration of satellite VNFs on NFVI (SatRAN, 3GPP Core, L2oS Function, Sat Gateway Function)

Configuration of entire logical satellite network via iDirect NMS

Configuration, testing, and verification of L2 Janet link to 5GIC

Deployment and configuration of multicast routing daemon to enable BPK multicast use case over satellite

Central Node (5GIC)

Remote configuration and integration of iDR MEC server into 5GIC network

Creation of IP-based routing rules to enable E2E application connectivity

Remote Node (5GIC)

Remote commissioning of iQ-DT modem

Remote configuration of iDR MEC server

Configuration, testing, and verification of L2 Janet link to Teleport

Creation of IP-based routing rules to enable E2E application connectivity

7.2.4 SaT5G Industry Day The SaT5G Industry Day demo, held on November 27th 2019 in 5GIC, constitutes a key landmark in the SaT5G project. It is the culmination of the work performed within WPs 4 and 5 within the original project timeline, and represents a near-final look at the 5G-capable satellite/terrestrial integrated network (with the final network implementation ultimately delivered within the extension period). The Industry Day demonstrations consist of a combination of the PoCs developed in WP4, and the E2E applications that reflect the Use Cases defined in D2.1. While these demos represent incremental improvements on those demonstrated at EuCNC 2019, iDirect implemented some significant technical advancements and architectural changes in the 5GIC testbed for the Industry Day. This section covers those changes and the overall testbed architecture in general.

SaT5G (761413) D4.1 DEC 2019

of 75

Demo Architecture As per the EuCNC 2019 demo, the overall demo architecture consists of two network nodes at 5GIC, connected on one side via a dedicated terrestrial L2 VPN link and on the other via a satellite link originating in the Goonhilly teleport. However, iDirect made significant changes in both the teleport and central nodes, specifically regarding the number, and nature, of VNFs deployed therein. In order to integrate satellite VNFs with the 5GIC Orchestrator (OSM), iDirect migrated two VNFs from the Goonhilly teleport to the 5GIC central node; one observes the migrated VNFs in Figure 7-4: SaT5G Industry Day Demo Architecture, circled in blue. iDirect also introduced two additional satellite security VNFs, which are observed in Figure 7-4, circled in green. Additional information on the migrated and newly introduced VNFs follows.

Figure 7-4: SaT5G Industry Day Demo Architecture

Satellite VNF Migration, and introduction of Satellite Security VNFs The rationale for migrating satellite VNFs from the teleport to a third-party premise is twofold. Firstly, it supports the demonstration of satellite network orchestration, which is achieved by deploying a subset of the satellite network service via the existing 5GIC Orchestrator (no Orchestrator is available in the teleport). Secondly, it demonstrates a novel paradigm in which thirty parties (in this case, 5GIC acting as an MNO) are granted control of certain aspects of access to the satellite network. We explore these concepts further in this section.

Prior to VM migration, all Satellite VNFs reside in Goonhilly Teleport; i.e. SatRAN, 3GPP Core Network, L2oS Function, and Satellite Gateway Function, as illustrated in Figure 7-5. Use case VMs/applications may only access the satellite network by directing IP traffic towards the Satellite Gateway Function in the Teleport.

Figure 7-5: Satellite VNF positioning, prior to VM migration

Post-migration, only the SatRAN and 3GPP Satcore VNFs reside in the teleport, with the L2oS and Satellite Gateway functions deployed in the 5GIC Central node. In this architecture, iDirect furnish 5GIC with a set of OSM

SaT5G (761413) D4.1 DEC 2019

of 75

descriptors and associated images with which they may orchestrate deployment of their segment of the satellite network service in their Central node. This is analogous to providing an MNO with satellite access VNFs and represents a plug n’ play approach to integrating satellite networks with 5G terrestrial networks. Figure 7-6: Satellite VNF positioning, post VM migration illustrates the post-migration architecture in the 5GIC testbed.

Figure 7-6: Satellite VNF positioning, post VM migration

In addition to migrating the L2oS and Satellite Gateway functions to 5GIC, iDirect introduced a pair of additional satellite VNFs into the SaT5G Industry Day architecture. VM migration to the 5GIC Central node split the satellite VNF chain across two locations; while the connection between the Teleport and Central node was facilitated by the testbed’s dedicated L2 VPN, it is likely that in a real-world deployment the connection would take the form of a standard terrestrial link over the Internet. In order to provide a layer of security for communication between geographically distributed VNFs, iDirect introduced a Satellite Security (SAT SEC) VNF at the edge of the Teleport and Central nodes. The SAT SEC VNFs encrypt traffic between the disparate nodes via an IPSEC tunnel, and route traffic to/from the Teleport’s 3GPP core VM and the Central node’s L2oS function.

List of Demo Elements Table 7-4: List of Industry Day Demo Elements


Description

Remote Node

5GIC Surrey

CPE UoS 5G Customer Premises Equipment

4G Radio Base Station UoS Provides access to dedicated LTE core for OA use case

5G Radio Base Station UoS Provides access to 5G core for BPK use case

NFVI (I) UoS Houses use case VNFs

NFVI (II) UoS Houses 5GIC 5G Core userplane network node (UPF)

nanoCDN BPK Subscribes to multicast traffic streams; performs multicast-to-unicast conversion; delivers content to UE via unicast.

MEC Server (I) UoS Performs local caching of UoS CDN content

Laptop OA Houses MPQUIC Client

Hybrid Terminal OA Multipath VNF/MPTCP Proxy

UPF UoS 5G User Plane Function

MEC Server (II) iDR Routes application traffic to/from satellite modem

iQ-DT Satellite Remote iDR Provides satellite access; acts as a relay node for the MNO UE. Presents as a UE to the 3GPP Core.

Space Segment Satellite (HYLAS-4) AVA Provides RF capacity for OTA traffic

Satellite Hub Chassis iDR Houses satellite line cards

Satellite Line Cards x 2 (Rx, Tx) iDR Receive/transmit traffic over satellite

SaT5G (761413) D4.1 DEC 2019

of 75


Description

Satellite Teleport, Avanti, Goonhilly

NFVI iDR COTS server running OpenStack that houses satellite VNFs

Satellite RAN VNF iDR Implements virtualized upper-layer satellite RAN functions

Satellite Core Network VNF iDR Standard COTS 3GPP Core Network VNFs

Release 15 LTE Core integrated into datapath

Release 15 5G Core integrated in lab

Satellite Security Function iDR Provides secure connectivity between geographically-distributed satellite VNFs across potentially unsecure link

VPN JANET L2 VPN JISC/AVA Provides a dedicated Layer-2 link between 5GIC central node and Goonhilly teleport

Central Node

5GIC Surrey

NFVI (I) UoS Houses satellite VNFs; supports orchestration and VNF lifecycle management via OSM and OpenStack

Satellite Security Function iDR Provides secure connectivity between geographically-distributed satellite VNFs across potentially unsecure link

Satellite L2oS VNF iDR Facilitates Layer-2-over-Satellite datapath

Satellite Gateway VNF iDR Routes application traffic to/from Satellite datapath

NFVI (II) UoS Houses use case VNFs

CDN Server UoS Use-case VM that provides video content for remote access

Origin Server/Encoder/CDN BPK Use-case VMs that provide video content for remote access via multicast

AMF/SMF UoS 5G Access & Mobility Management and Session Management Functions; implement 5G control plane

LTE Core UoS Dedicated core for OA use case demonstration at SaT5G Industry Day

Hybrid Gateway OA Multipath VNF/MPTCP Proxy

HTTP2 Server OA Web server for MP/TCP QUIC demonstrations

7.2.5 Final Architecture The final testbed architecture, delivered within the extension period is an incremental improvement to the satellite network architecture over its SaT5G Industry Day counterpart. The key difference therein is the substitution of the previously integrated Release 15 LTE Satcore with a Release 15 5G Satcore. The result is an all-5G E2E network, in which both the terrestrial and satellite core networks implement Release 15 5G.

SaT5G (761413) D4.1 DEC 2019

of 75

7.3 ZII Testbed The Aero testbed led by Zodiac Inflight innovations (ZII) tackles the challenges of SaT5G use case four explicitly addressing the case of an aircraft moving platform. The ZII testbed participated at the industry day (University of Surrey, Guilford) with a video summarizing the achievements of satellite-terrestrial integration in 5G regarding the case of future aircrafts connectivity and services. The choice of a video was the natural consequence of the testbed complexity that does not allow moving system components outside the respective locations. The video demonstration was divided in two parts: the first part focusing on demonstrating a 5G platform availing GEO satellite connectivity and a second part focused on a different platform that relies on MEO satellite connectivity. The demo that is explained in the next sections covers the activities carried out by the ZII testbed partners in WP2 for the use cases definition, in WP3 for the specific backhaul architecture, in WP4 with regard to the design of the system components and in WP5 for the actual development and integration activities.

It is worth reminding that the video demonstrations details and provides evidence of the testbed activities until the original SaT5G project timeline (end of Nov. 2019). The additional R&D activities that are undertaken during the extension period (end of Feb. 2020) granted to the project will be included in a further elaboration of the industry day video. Thus, an update of the video enriched with new footage and results will be presented at the final project review.

Demo Architecture As mentioned, the video demonstration provided by the ZII testbed at the industry day is divided in two parts that account for backhaul connectivity by means of GEO and MEO satellites, respectively. The demo that relies on the GEO satellite connectivity greatly extends that already provided at the SaT5G booth in EuCNC’19. Therefore, the overall architecture of the demonstration based on GEO provided hereinafter implicitly covers also the status and the testbed architecture for EuCNC.

5G testbed based on GEO satellite connectivity The overall architecture of the 5G testbed developed by ZII to demonstrate a 5G connectivity system that relies on a GEO satellite backhaul is provided in Figure 7-7. It is worth mentioning that GEO satellite is the de facto connectivity system for aircrafts worldwide. Anyway, several shortcomings like long delay and limited throughput were already identified. Typically, the connectivity package acquired by airlines is bound to a specific satellite operator and the system itself does not exhibit the necessary flexibility when timely upgrades are necessary. For such reasons, the ZII testbed put in place a 5G testbed that comprises a virtualized satellite hub alongside with a software-defined controller for the satellite system configuration (Gilat R&D), a virtualized mobile core network (Quortus R&D) that relies on Control and User Plane Separation (CUPS) as per 3GPP specifications and content caching on-board the aircraft network. Since in the project only MEO satellite connectivity was agreed for the ZII testbed, the GEO satellite path is based on a link emulator between the VSAT and the virtualized hub, which are configured in the same mode as an over-the-air connection. The testbed provides also demonstration of a virtualized caching solution (Broadpeak R&D) on-board the aircraft as a possible way of enlarging the offer of media contents to travellers.

Relying on the explanations already provided in Section 3.3 and in Section 5.2, Figure 7-7 provides visual explanation of the testbed islands that were developed to demonstrate the GEO based aircraft connectivity inside SaT5G. In addition, it is necessary to point out that the fully-fledged caching solution adopted in the testbed requires multicast connectivity over the satellite path. It was discovered that the multicast session is not supported inside the Open Virtual Switch and hence multicast over satellite is included as part of the over-the-air MEO demo.

In terms of use cases, passengers’ connectivity to the ground (e.g. Internet) and passengers’ access to cached content on board were both demonstrated using Personal Electronic Devices (PEDs), a rising trend clearly identified by airlines compared to the typical access to content whereby the embedded seat screens.

Overview of the testbed components, the respective supplier alongside with a brief description of the functionality is provided in the table below.

SaT5G (761413) D4.1 DEC 2019

of 75

Figure 7-7: Aero 5G testbed based on GEO satellite connectivity

List of Demo Elements Table 7-5: List of Zodiac GEO Demo Elements


Description

Remote node @ Gilat (Tel Aviv)

VSAT GLT Satellite modem that can be set in over-the-air configuration

SkyEdge II-c GLT Virtualized satellite hub that allows configuring the ground system as in an over-the-air demonstration; the product is part of Gilat offering adapted to the R&D purpose of SaT5G

Virtualized VXGW GLT It establishes Layer 2 connectivity in the virtualized hub

Virtualized NSC GLT Network Segment Control of the virtualized hub

C-Hub-Chassis GLT Combined Baseband and datacentre processing (satellite system physical network function)

Relay machine GLT One endpoint of the Layer 3 VPN and used to implement traffic forwarding rules between the mobile network components

OpenStack compute GLT Part of the NFVI and directly controlled from the ZII office

TotalNMS GLT Software-defined controller responsible to configure the satellite hub

Space Segment GEO satellite link emulator GLT Gilat satellite link emulator, including up and down converters as required by the RF frequency of the SLE.

Central node @ Zodiac Inflight Innovations

Ground servers’ infrastructure and networking

ZII Infrastructure where the main part of the NFVI resides; it hosts all virtualized components of services that are meant to be deployed on the ground both for satellite and terrestrial parts

Aircraft servers’ infrastructure and networking

ZII Network infrastructure reproducing and upgrading the network and compute resources available on-board

SaT5G (761413) D4.1 DEC 2019

of 75


Description

aircrafts; it is used to deploy virtualized services on-board, as well as for passengers’ connectivity

Layer 3 VPN ZII Set-up by ZII to connect the ZII main island in Germany to the remote island in Tel Aviv

OSM ZII Open source software for network service orchestration; the testbed relies on the release five

OpenStack ZII Cloud manager of the NFVI; the testbed relies on the Queens release

TALENT i2CAT Terrestrial satellite resource manager

Cached content BPK On-demand Video catalogue

Mobile core network QUO Virtualized 4G mobile core that implements CUPS for splitting the main body of the core from the MEC (multi-access Edge Computing)

Radio Access ZII Two 4G eNB supplied as in-kind by CASA System as part of the joint R&D activities with ZII in the H2020 5G PPP Phase 2 5G ESSENCE project

End users’ devices ZII Tablets and smartphones for Personal Electronic Devices (PEDs)

Overall playground and Aero certified products

ZII A320 cabin mock-up and media server

5G testbed based on MEO satellite connectivity

The 5G testbed architecture for MEO based satellite connectivity is shown in Figure 7-8: Aero 5G testbed based on MEO satellite connectivity. Comparing with the GEO based demo, the central node is still located in ZII while the remote node this time is located in Sintra (Portugal) where one SES teleport for O3b was made available to the ZII testbed. In terms of the NFVI, the central node in ZII relies on the same layered architecture explained for the GEO based demonstration (i.e. TALENT, OSM and OpenStack) but it greatly differs in the satellite network part. At first, the MEO based connectivity makes use of an over-the-air system in which O3b satellite capacity is provide by SES for the space segment. Two equal GLT modems have been connected in ZII and in the O3b teleport to two equal MEO boosters. The MEO booster technology allows using a single modem at both ends rather than two modems, and it represents quite a significant progress with respect to the dual transceiver chain currently in use. As shown during the SaT5G Industry Day video demonstration, the MEO booster is responsible for the ‘make-before-break’ handover, the fast switching between satellites when one satellite is setting and the other one is rising. The GLT modems are instead configured in SCPC mode (single channel per carrier). This specific configuration was deemed to carry a lower risk compared to the case of a full TDMA configuration considering that the MEO booster is an experimental technology still. The terrestrial connectivity between the central node in ZII and the O3b teleport is ensured by means of a Layer 2 VPN. Particularly, the segment of the Layer 2 connection between the O3b teleport and the SES point-of-presence in Munich belongs to SES, while the segment between the ZII central node and the SES point-of-presence in Munich was purchased by ZII to Deutschland Telekom to obtain a dedicated leased line with speed up to 50 Mbit/s. The antenna system deployed in ZII and directly injecting inside the central node is based on 1.2m dual antenna technology.

Initial Architecture For the SaT5G Industry Day, the capability to perform the satellite handover with the chain Dual antenna system-MEO booster-GLT modem was demonstrated alongside with basic iPerf indicator of the performance.

SaT5G (761413) D4.1 DEC 2019

of 75

Final Architecture The Aero testbed led by ZII as part of the SaT5G project has continued evolving after the SaT5G Industry Day. While the part of the 5G testbed that relies on GEO satellite backhaul was consolidated, the platform that relies on the MEO backhaul connectivity was completed. The radio access network currently being tested over O3b relies on the same eNB and personal electronic devices as in the GEO based demonstration. Anyway, two small cell base stations up to 3GPP release 13 are currently connected to a virtualized instance of the Open5GCore of Fraunhofer FOKUS. This core network was acquired by ZII in order to demonstrate selected 5G features. The two small cell base stations make use of different backhaul technologies to reproduce the case in which passengers move from the ground radio access network that uses terrestrial backhaul to the one on-board that makes use of the satellite link. All radio access network components were moved to the ZII mock-up of the cabin of an A320 aircraft for actual testing. In terms of use cases, passengers’ connectivity to the ground (e.g. Internet) and passengers’ access to cached content on board were both demonstrated using PEDs. Multicast over satellite for caching popular content was also successfully tested after the industry day.

An overview of the testbed components, the respective supplier alongside with a brief description of the functionality is provided in the table below.

Figure 7-8: Aero 5G testbed based on MEO satellite connectivity

List of Demo Elements Table 7-6: List of Zodiac MEO Demo Elements


Description

SES O3b Teleport Site @ Sintra,

Portugal

Satellite teleport SES O3b teleport in Sintra (Portugal) with RF uplink/downlink 7.3m Ka-band dual antenna facilities

MEO Booster SES Network element for managing the antenna handover configured in Diversity Combining mode;

GLT modem Gilat Gilat modem product for establishing a point to point link over the MEO satellite (maximum symbol rate of 30 MSps; CCM mode operation)

Management station Gilat Laptop for managing daily configurations and operations to control the MEO Booster and GLT Modem. Configured as NTP server for the MEO Booster to be synchronized to UTC time

Multicast/Push VoD Server BPK miniPC BkE Server

SES PoP

Zodiac Inflight Office (Munich)

SES O3b Teleport (Sintra)

MEO Booster

Gilat Modem

SES O3b MEO HTS(over the air)

Munich

AvL 1.2m Antenna

Make Before Break Handover

NFVI

RAN

MEO Booster

Gilat Modem

TranscasterMulticast

Make Before Break Handover

7.3m Antenna

L2 VPN L2 VPN

SaT5G (761413) D4.1 DEC 2019

of 75

Space Segment

O3b Ka-band MEO HTS satellite constellation system (20 in orbit MEO satellites)

O3b Beam: 622 (Channel 2)

SES Link Budget values:

FWD: CIR Data Rate under clear sky conditions (assuming 8PSK 2/3 and 30 MSps) = 59.1 Mbps

RTN: CIR Data Rate under clear sky conditions (assuming QPSK 5/6 and 30 MSps) = 49.5 Mbps

Actual values:

FWD: 30 Msps, 8PSK 3/4 , 64.407 Mbit/s,

RTN 30 Msps , QPSK 2/3 37.741 Mbit/s

ZII Site @ Wessling, Germany

Antenna terminal SES 1.2m Ka-band transportable dual-antenna terminal configured in dual antenna mode

Virtualized content delivery system

BPK Virtualized system for multicast over satellite and content caching on-board aircrafts

MEO Booster Gilat Network element for managing the antenna handover configured in Diversity Combining mode

GLT modem Gilat Gilat modem product for establishing a point to point link over the MEO satellite (maximum symbol rate of 30 MSps; CCM mode operation)

Management station Gilat Laptop for managing daily configurations and operations

Indoor rack for antenna terminal

SES Portable server rack and management point of the Antenna terminal; used to lodge the GLT modem and the MEO booster in Wessling

Ground servers’ infrastructure and networking

ZII Infrastructure where the main part of the NFVI resides; it hosts all virtualized components of services that are meant to be deployed on the ground both for satellite and terrestrial parts

Aircraft servers’ infrastructure and networking

ZII Network infrastructure reproducing and upgrading the network and compute resources available on-board aircrafts; it is used to deploy virtualized services on-board, as well as for passengers’ connectivity

OSM ZII Open source software for network service orchestration; the testbed relies on the release five

OpenStack ZII Cloud manager of the NFVI; the testbed relies on the Queens release

TALENT i2CAT Terrestrial satellite resource manager

Cached content BPK On-demand Video catalogue

Mobile core network ZII Open5GCore virtualized 5G mobile core

Radio Access ZII Two 4G eNB supplied as in-kind by CASA System as part of the joint R&D activities with ZII in the H2020 5G PPP Phase 2 5G ESSENCE project

End users’ devices ZII Tablets and smartphones for Personal Electronic Devices (PEDs)

Overall playground and Aero certified products

ZII A320 cabin mock-up and media server

SaT5G (761413) D4.1 DEC 2019

of 75

VPN

Layer 2 VPN SES Layer 2 VPN link between SES O3b Teleport in Sintra and SES PoP in Unterföhring/Munich, through SES terrestrial backbone access network

Layer 2 VPN ZII Layer 2 VPN link between SES PoP in Unterföhring/Munich and ZII premises in Wessling through DT terrestrial backbone access network

Comparison between the two cases of connectivity and performance of both systems (MEO OTA vs. GEO Simulated) are being tested extensively and will be reported in D5.6. Ultimately, useful comparison between aircraft connectivity systems that rely on GEO or MEO satellites will be carried out and results will be provided in D5.6.

SaT5G (761413) D4.1 DEC 2019

of 75

8 Standards

8.1 Standards Adoption 5G is defined by the 3GPP standards body and therefore the first step in trying to understand how to integrate with 5G is to understand the 3GPP standard [7, 8, 9]. This understanding is require in order to integrate and optimise the end to end use cases for the indirect architecture but also understanding the potential integration points for the Direct architectural approach outlined earlier in section 3.

As mentioned earlier, transforming the satellite network architecture to behave more like a standard 3GPP network brings significant benefits for SNOs, who can take advantage of many years of innovation and market growth in the telecoms industry.

To achieve this, in SaT5G 5GIC testbed, the architecture approach introduces a standard 3GPP core network function into the satellite network in order to operate and control the satellite network. The satellite network adopts the 3GPP network architecture where possible.

The existing satellite network is modified to comply with the standard 3GPP architecture, e.g. 5G core network functions. The concept of an NTN UE is introduced; this new, 3GPP-enabled satellite terminal presents itself as a 5G UE to the NTN, which allows it to connect to a NTN 5G core network in order to access network services. This will enable support for 5G services, such as authentication, billing, and policy & charging. Importantly, at this stage of the network transformation, the physical layer remains the same over the satellite for the NTN network.

The standard 3GPP 5G mobile network uses the NTN as a backhaul network for end-to-end service delivery (i.e. the indirect use case). Either the MNO or the NTN/SNO operator, depending on the business model, can operate the 5G core network; there may also be separate 5G core networks for the mobile and NTN networks.

This approach is illustrated in Figure 8-1: Scenario A3 - Indirect mixed 3GPP NTN access and is a variant of “Scenario A3 - Indirect mixed 3GPP NTN access” as defined in ETSI SCN DTR/SES-00405 “Integration of satellite and/or HAPS (High Altitude Platform Station) systems into 5G and related architecture options” - ETSI TR 103 611.

Figure 8-1: Scenario A3 - Indirect mixed 3GPP NTN access

This new satellite RAN (SatRAN) gNB interface’s with the NTN 5G core network on the network side while continuing to use the existing satellite radio over the satellite. The NTN terminal is also modified to behave like standard 3GPP 5G UE. Together the modified NTN terminal, the SatRAN and standard 3GPP 5G core network provide the NTN satellite network.

The SatRAN, behaving like a standard gNB, interfaces with the 5G core networking using standard 3GPP compliant N2 and N3 interfaces and the NTN terminal, behaving as a standard UE, interfaces with the 5G core networking using standard N1 interface.

This integration is an important foundation for further integration and adoption of the 3GPPP standards that are being developed today and furthermore it illustrates to the industry that satellite networks are evolving, adapting and aligning with the 3GPP vision of an agnostic access unified network.

UE gNB

NTN LT gNB

DNNTN

NT UEMixed 3GPP NTN Access

Network

Orchestrator / NMS

NTN Relay UE

RAN

5G CN

Classes of UE

SaT5G (761413) D4.1 DEC 2019

of 75

8.2 Key Issues for Standardisation In Section 6 the data model and service API researched during the project were discussed. The initial intention was to contribute the output of this research to ETSI SES work item ETSI SCN DTR/SES-00446 “Reference Virtualized Network Functions data model for satellite communication systems” [10]. The concept was to agree on a low-level data model so as virtual network functions from different satellite vendors could interact, however during the research, the SaT5G project partners realised that this level of integration was too low level for the satellite industry. The satellite industry is in the very early stages of supporting interoperability between vendors and different networks. Likewise, in the telecoms industry (3GPP) there is no agreement at this low level for interoperability i.e. typically wireless stacks are from one vendor only and not multiple. The research led the project to start looking at higher level integration, for example at the services level, which is more abstract but allows for more flexibility and therefore interoperability as the satellite vendors can implement the service as they wish. This service level integration is also aligned to the satellite network operator requirements.

From a standards support perspective, this resulted in little progress being made on ETSI SCN DTR/SES-00446 “Reference Virtualized Network Functions data model for satellite communication systems [10]. In recent meetings, a new work item, “DTR/SES-00411 (TR 103 522) TR - Protocol for Resource Management in HTS system between Service provider – satellite operator” [11], was introduced and it is proposed that this work item may be a better target for the output of the project activities in this area. At the time writing ETSI SCN were reviewing how to handle this going forward given the input from the SaT5G project.

SaT5G (761413) D4.1 DEC 2019

of 75

9 Conclusions

9.1 Summary of Findings At the outset of this document, it was stated that in order for satellite network components to integrate seamlessly within a 5G network architecture, they must support virtualization and possess SDN capabilities. We conclude now that the technical advancements described in this document have clearly demonstrated that satellite network functions can meet those objectives: that is, satellite network functions are as amenable to virtualization as terrestrial network functions, and as such are viable for integration into the SDN and NFV-rich 5G ecosystem.

Virtualization of satellite network functions, and their subsequent orchestration, was facilitated in this project by adherence to the industry-standard ETSI NFV-MANO framework [5]. Following the approach prescribed by the NFV-MANO architecture, it was illustrated that satellite networks can utilise NFV and SDN technologies at different architectural layers. At the Virtualization Layer, a hypervisor (such as KVM) provided abstraction and separation of physical and virtual resources, which enabled virtualization of satellite network functions within the host system (the NFVI). Once virtualized, satellite network functions that have traditionally been implemented on dedicated hardware platforms were collocated and deployed on COTS servers, as described in Section 4, Virtualization of Satcom Elements.

Introducing OpenStack as the VIM that deploys and manages satellite VNFs allowed SDN orchestration of satellite networks, via its northbound API. Accordingly, in Section 5, Implementation of Satellite SDN & Orchestration in Testbeds, it was demonstrated that automated deployment of virtualized satellite network services via SDN Orchestrators is possible. By developing ETSI-standardised YANG descriptors, which capture network functions’ resource requirements and the required network topology, satellite VNFs were onboarded to OSM and subsequently deployed as a satellite service.

Virtualization of satellite functions and integration with an SDN Orchestrator represents one important pillar of the project and also plays an important role in the implementation of a plug n’ play interface for satellite to 5G networks that was prototyped in WP4.1. A further advancement involved an SNO providing a third party or MNO with an OSM network service package. The MNO deployed this gateway satellite service via Orchestrator, which allowed them to access the satellite network via a standard terrestrial network interface. Another approach researched and prototyped consisted of a RESTful satellite-service API that an MNO or third party could use to monitor and modify a satellite service dynamically.

Another important innovation realised by the project was the adoption of the 3GPP network architecture within the satellite network. This was achieved by introducing a COTS virtualized 3GPP 5G core network (Satcore) into the satellite network architecture, and also modifying the satellite RAN VNF and satellite remote terminal such that they present to the Satcore as standard 5G gNodeBs and UEs, respectively. The adoption of standard network interfaces enables simplified integration of satellite with terrestrial networks via implementation of standard network interfaces. It also exposes satellite to the 3GPP ecosystem, opening the door for use of third-party applications, such as terrestrial billing systems.

9.2 Recommendations for Future Work

9.2.1 Enhanced 5G core network integration While early releases of the 5G core network specification were available in Jan 2019, many of the 5G core network providers waited until later releases of the standards, e.g. June, to baseline the first releases of their products. The resulted in the project partners not having access to commercial versions of 5G core networks and tools for testing and integration until later stages of the project. This limited the scope of the integration and while it allowed for initial integration with 5G architectures, further integration and exercising more features of 5G is possible given more time.

9.2.2 Single 5G core network for the Satellite and Terrestrial networks Following on from the earlier description of the adoption of 3GPP architecture in satellite networks, the next phase of satellite and mobile network integration is the possibility to use a single 5G core network to operate

SaT5G (761413) D4.1 DEC 2019

of 75

both the satellite and terrestrial networks. This is illustrated below in Figure 9-1: Single core network for Satellite and Mobile networks.

Figure 9-1: Single core network for Satellite and Mobile networks

In this setup the Satellite or Mobile Network Operators (MNO) can operate both the satellite NTN terminals and the end user mobile UEs using a single core network. The single 5G core network instance operates the control and user plane of the satellite and mobile networks allowing it to use a common management framework. This allows the Satellite Network Operator (SNO) to offer innovative new services to the MNO, e.g. in the form of a network slice to operate the satellite network. This level of integration was not reached during the project mainly due to availability of 5C core network components as outlined earlier, but the network architecture is well positioned for this level of integration with the 5GIC 5G core network.

9.2.3 Toward multi-constellation 5G satellite connectivity The satellite sector is going through an exciting period in which new opportunities appear at the horizon. The traditional GEO based satellite connectivity is currently on the way to being complemented with MEO and LEO satellite to deliver a new generation of services for both B2C and B2B. Hence, the availability of GEO, MEO and LEO constellations catalyses a new way of providing global connectivity to different customers. Anyway, each constellation has its own pros and cons that can be tackled only by the adoption of a harmonized and single operational and support system. In addition, the integration of the Satcom with the 5G core network will allow treating resources in a unified manner across different satellite segments. Overall, such scenarios outline the possibility to create on demand slices of satellite resources that span different constellations, and which can be used opportunistically, switching among them at locations in which the best possible connection is available.

9.2.4 Leveraging 3GPP eco-system Introducing 3GPP network architecture and concepts into the satellite network architecture offer great benefits to the satellite industry by allowing it to leverage the rich and mature eco system that is already in place in the Telecoms industry - which has grown exponentially generation-on-generation of 3GPP. By way of example, consider the recently formed Zero touch network & Service Management (ZSM) group in ETSI. ZSM is conceived as a next-generation management system that leverages the principles of Network Functions Virtualization (NFV) and Software Defined Networking (SDN) for telecommunications networks.

Figure 9-2: Snapshot of ZSM members below gives a snapshot of the members of the ETSI ZSM group. The diversity of the newly formed group highlights the potential of engaging with the 3GPP community.

SaT5G (761413) D4.1 DEC 2019

of 75

Figure 9-2: Snapshot of ZSM members 4

Therefore, introducing the standard 3GPP network elements allows integration of off-the-self solutions for 3GPP services and features, for example:

Policy and Control Function (PCRF) integration

Billing system integration

Lawful intercept

Content filtering management

Network slicing

Ultra Reliable low latency Communication (URLLC)

The project timeline limited the scope of integration however, the architecture selected allows for this off-the-shelf selection and integration.

9.2.5 Advancement of Satellite Service API Reaching a consensus between stakeholders with respect to a service-level view of satellite resources (as part of the satellite data model work item) was a significant development within WP4.1. While this common view was not achieved until late in the project, it nonetheless provided sufficient time for iDirect to implement a PoC API to demonstrate the key concepts of a satellite service API, and the key actors involved in such a system. A worthwhile follow-on activity would involve implementation of this satellite service API in a popular service-level API, such as the Open Lifecycle Service Orchestration (LSO) APIs defined by MEF [12].

MEF is an industry association comprised primarily of Service Providers and network equipment vendors that specialises in producing reference frameworks for orchestrated network services. As part of its MEF 3.0 Global Services Framework, MEF produced the LSO Reference Architecture, which defines a set of reference points and associated APIs for standardised orchestration of E2E network services. Figure 9-3: LSO Reference Architecture illustrates the reference points for inter domain communication between network service partners and the intra-domain communication between infrastructural layers.

Application of the LSO framework to the satellite services API would consist of an implementation of the API at the PRESTO reference point, and potentially exposure of it both laterally and northbound via the INTERLUDE and LEGATO APIs, respectively.

4 Source - https://www.etsi.org/technologies/zero-touch-network-service-management

https://www.etsi.org/technologies/zero-touch-network-service-management

SaT5G (761413) D4.1 DEC 2019

of 75

Figure 9-3: LSO Reference Architecture 5

As discussed in section 8.2, the ETSI SES SCN work item “DTR/SES-00411 (TR 103 522) TR - Protocol for Resource Management in HTS system between Service provider – satellite operator” [11] may also be a potential standardisation work item for this Service level API. At the time of writing ETSI SES are considering this given the findings outlined by the SaT5G project.

5 Source: https://wiki.mef.net/download/attachments/53154082/LSO%20Reference%20Architecture%20Diagram.png?version=3&modificationDate=1561213290000&api=v2

https://wiki.mef.net/download/attachments/53154082/LSO%20Reference%20Architecture%20Diagram.png?version=3&modificationDate=1561213290000&api=v2

SaT5G (761413) D4.1 DEC 2019

of 75

10 References

[1] IETF, “The YANG 1.1 Data Modeling Language,” 2016.

[2] SaT5G, “Integrated SaT5G General Network Architecture,” November 2019. [Online]. Available: https://sat5g-project.eu/wp-content/uploads/2019/04/SaT5G-D3.1-Integrated-SaT5G-general-network-architecture_ADS_v1.00_Inter....pdf.

[3] ETSI, “SESSCN(18)000020)/ETSI SCN TC-SES - DTR/SES-00405 Satellite Earth Stations and Systems (SES); Seamless integration of satellite and/or HAPS (High Altitude Platform Station) systems into 5G system,” 2019.

[4] SaT5G, “Integrated SaT5G Detail Network Architecture,” 2018.

[5] ETSI, “Network Functions Virtualisation (NFV); Architectural Framework,” 2013.

[6] Fraunhofer. [Online]. Available: https://www.open5gcore.org/.

[7] 3GPP, TS 23.501; System Architecture for the 5G System, 2018.

[8] ETSI, “TS 23.502; Procedures for the 5G System,” 2018.

[9] ETSI, “TR 22.822; Study on using satellite access in 5G,” 2018.

[10] ETSI, “Reference Virtualised Network Functions data model for satellite communication systems,” 2017.

[11] ETSI, “Protocol for Resource Management in HTS system between Service provider – satellite operator,” 2019.

[12] MEF, “Lifecycle Service Orchestration (LSO): Reference Architecture and Framework,” 2016.

d4.1 virtualization of satcom components analysis, design and … · 2020-06-08 · sat5g (761413)...

Documents