SaT5G (761413) D5.2/D5.4 March 2020 Satellite and ... · Demonstration of Mobile Backhaul Scenario...

SaT5G (761413) D5.2/D5.4 March 2020

D5.2/D5.4

Testbed Data Centre Equipment Installed, Connected and Functionally Tested and Validated /

Demonstration of Mobile Backhaul Scenario

Including Caching & Multicast

Topic ICT-07-2017

Project Title Satellite and Terrestrial Network for 5G

Project Number 761413

Project Acronym SaT5G

Contractual Delivery Date N/A

Actual Delivery Date 05/03/2020

Contributing WP WP5.2 / WP5.4

Project Start Date 01/06/2017

Project Duration 33 months

Dissemination Level PU

Editor ZII

Contributors ZII, Gilat, SES, QUO, BPK, i2CAT

Satellite and Terrestrial

Network for 5G

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Document History

Version Date Modifications Source

0.1 22/01/20 ToC creation ZII

0.2 29/01/20 ToC update ZII

0.3 10/02/20 Inputs to Sections 4.3, 4.4, 4.5, 4.7 SES

0.4 04/02/20 Inputs to Section 8.4 BPK

0.5 10/02/2020 Inputs to TALENT in Sections 3.5 and 5 i2CAT

0.6 12/02/2020 Inputs to Section 4.9 and 5.7 BPK

0.7 14/02/2020 Inputs to Sections 5.6, 6.2.2, 7 QUO

0.8 18/02/2020 Inputs to Sections 4.6, 5.2, 5.4, 5.5, 6.1.1, 6.1.2, 6.1.4, 8.5.1, 8.5.2

GLT

0.8 19/02/2020 Input to Section 7 QUO

0.85 21/02/2020 Draft of Section 1 and Inputs and revision in all sections ZII

0.85 21/02/2020 Inputs to sections 4.9, 6.1.2 BPK

0.85 24/02/2020 Updates and contributions to Section 4 SES

0.85 24/02/2020 Inputs to Sections 5.6, 6.2.2 QUO

0.85 24/0272020 Inputs to Sections 5.2, 7, 8.5.1, 8.5.2 GLT

0.90 24/02/2020 Contributions, revision and inputs to Executive Summary, Section 1, Section 5, Section 8, Section 10

ZII

0.90 25/02/2020 Contribution to Section 3.5.1 i2CAT

0.91 25/02/2020 Document updates ZII

0.92 26/02/2020 Contribution to Sections 4.6, 4.10, 6, 7, 8.5.2 SES

0.93 26/02/2020 Contribution to Sections 4.6, 5.2, 5.4, 5.5, 5.5.1, 6.2.1, 8.5.3 GLT

0.95 27/02/2020 Contribution to Executive Summary, Section 4.6, Section 7, Section 9, Section 9.2

SES

0.96 27/02/2020 Contribution to 4.6.1 and 5.1 GLT

0.97 27/02/2020 QA document review SES

0.98 04/03/2020 QA document review AVA

0.99 04/03/2020 QA document review ADS

1.0 05/03/2020 Final editing ZII

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Contributors

Name Organisation Contributions include

Leonardo Goratti ZII

Document Editor.

ToC, document updates and integration,

Inputs to Executive Summary, Section 1, Section 2, Section 3, Section 4, Section 5, Section 6, Section 7, Section 8, Section 9, Section 9.2

Document revisions and editing

Konstantinos Liolis SES

Contributions and inputs to Sections 4, 4.3, 4.4, 4.5, 4.6, 4.7, 4.10, 6, 7, 8.5.2, Review of Executive Summary, Section 1, Section 7, Section 9, Section 9.2, QA Document Review

Duy-Kha Chau, Alain-Pierre Brunel, Yann Begassat

BPK Contributions and Inputs to Section 8.4, 4.9, Section 6.1.2

Hamzeh Khalili i2CAT Contributions and inputs to Sections 3.5, 5.5.1, 3.5.1

Srikant Ravuri QUO Contribution and inputs to Sections 5.6, 6.2.2, 7

Menachem Dodge GLT Contributions and inputs to Sections 4.6, 5.2, 5.4, 5.5, 6.1.1, 6.1.2, 6.2, 8.5.1, 8.5.2, 7, 5.5.1, 8.5.3, 4.6.1, 5.1

Simon Watts AVA QA Document Review

Boris Tiomela-Jou ADS QA Document Review

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Table of Contents

List of Figures .......................................................................................................................................... 7

List of Tables ......................................................................................................................................... 10

List of Acronyms .................................................................................................................................... 11

Executive Summary .............................................................................................................................. 13

1 Introduction .................................................................................................................................... 14

1.1 Scope .................................................................................................................................... 14

1.2 Context .................................................................................................................................. 15

1.3 Document structure ............................................................................................................... 15

2 SaT5G System Architecture for 5G Satellite Integrated Access ................................................... 16

3 Final ZII Test Bed Architecture ...................................................................................................... 17

3.1 Positioning the ZII Test bed System Architecture ................................................................. 19

3.2 Aircraft Radio Access Network Infrastructure ....................................................................... 20

3.3 Ground Datacentre ................................................................................................................ 22

3.4 Virtualization and SDN for Satellite Network Functions ........................................................ 22

3.5 TALENT Terrestrial – Satellite Resource Coordinator .......................................................... 23

3.5.1 Virtualised Services Descriptor Files through TALENT .................................................... 25

4 Aero Test Bed Based on Over-The-Air MEO Satellite Connectivity .............................................. 28

4.1 MEO Test Bed System Architecture ..................................................................................... 28

4.2 MEO Test Bed Network Architecture .................................................................................... 29

4.3 O3b Space Segment ............................................................................................................. 30

4.4 O3b Gateway Teleport .......................................................................................................... 34

4.5 O3b Remote User Terminal .................................................................................................. 37

4.6 Satellite Ground Segment Network Equipment .................................................................... 40

4.6.1 MEO Booster Configurations for OTA Satellite Tests ....................................................... 43

4.7 Layer 2 VPN Connectivity ..................................................................................................... 44

4.7.1 Layer 2 VPN Link between O3b GW at Sintra, Portugal and SES MX1 PoP at Unterföhring/Munich, Germany (Munich (MUN)) ........................................................................... 44

4.7.2 Layer 2 VPN Link between SES MX1 PoP at Munich, Germany (Munich (MUN)) and O3b Remote User Terminal Location at Wessling, Germany ............................................................... 45

4.8 5G Mobile Core Network Virtualised Service ........................................................................ 45

4.9 Virtualised Content Delivery Service ..................................................................................... 47

4.10 Summary of Test bed Components ...................................................................................... 48

5 Aero Test bed Based on Emulated GEO Satellite Connectivity .................................................... 51

5.1 GEO Test Bed System Architecture ..................................................................................... 51

5.2 GEO Test Bed Network Architecture .................................................................................... 52

5.3 Layer 3 VPN .......................................................................................................................... 55

5.4 Satellite Ground Segment Network Equipment .................................................................... 55

5.5 Virtualised Satellite Service ................................................................................................... 56

5.5.1 TALENT – TotalNMS Communications ............................................................................ 57

5.6 Virtualised Mobile Core Network Service .............................................................................. 57

SaT5G (761413) D5.2/D5.4 March 2020

of 108

5.7 Summary of Test bed Components ...................................................................................... 58

6 Description of Demos..................................................................................................................... 61

6.1 Aircraft Connectivity Based on MEO OTA Satellite Backhaul .............................................. 61

6.1.1 MEO OTA Satellite System Set-Up, Validation and Test Cases ...................................... 61

6.1.2 Content Loading on Aircraft with Multicast Traffic over Satellite ....................................... 63

6.1.3 Passengers’ Mobility Measurements with MEO Satellite Backhaul .................................. 64

6.2 Aircraft Connectivity Based on Emulated GEO Satellite Backhaul ....................................... 65

6.2.1 Emulated GEO Satellite System Set-Up, Validation and Test Cases ............................... 65

6.2.2 Passengers’ Mobility measurements with GEO Satellite Backhaul .................................. 66

6.3 Passengers’ Traffic Measurements....................................................................................... 66

7 Measurement KPIs ........................................................................................................................ 68

8 II Test Bed Measurement Results ................................................................................................. 70

8.1 Virtualised Services Creation Time ....................................................................................... 70

8.2 Measurements Results over OTA MEO Orbit Satellite ......................................................... 71

8.2.1 O3b Satellite Link Benchmark ........................................................................................... 71

8.2.2 End-to-End Link Benchmark ............................................................................................. 74

8.3 Mobile Network Measurements over OTA O3b satellite ....................................................... 82

8.3.1 Control Plane Measurements ............................................................................................ 82

8.3.2 User Plane Measurements ................................................................................................ 83

8.3.3 Ground Small Cell Connectivity ........................................................................................ 87

8.3.4 Aircraft Connectivity featuring Passengers’ Mobility ......................................................... 88

8.4 Virtualised Content Delivery Service ..................................................................................... 90

8.4.1 Data transmission metrics ................................................................................................. 90

8.4.2 Transmission rate between the BKS350 and the BKE200 ............................................... 91

8.4.3 Time to transfer content from BKE to nanoCDN in the Aircraft ........................................ 91

8.4.4 Bandwidth usage and time to transfer a catalogue of 20 popular HD VOD assets in multicast to 1 aircraft ...................................................................................................................... 92

8.4.5 Bandwidth usage and time to transfer a catalogue of 20 popular HD VOD assets in multicast to 100 aircraft .................................................................................................................. 92

8.4.6 Bandwidth usage and time to transfer in unicast pull mode a catalogue of 20 popular HD VOD assets to 1 aircraft ................................................................................................................. 92

8.4.7 Bandwidth usage and time to transfer in unicast pull mode a catalogue of 20 popular HD VOD assets to 100 aircraft ............................................................................................................. 93

8.4.8 Comparison between Multicast and Unicast file transfer for 20 popular HD VOD assets in unicast to 100 aircraft..................................................................................................................... 93

8.5 Measurement Results Over Emulated GEO Orbit Satellite .................................................. 94

8.5.1 SNR and EsN0 Measurements ......................................................................................... 94

8.5.2 GEO Satellite Backhaul Outbound and Inbound Throughput ........................................... 95

8.5.3 Round-Trip-Time Measurements Over the Emulated GEO Link ...................................... 98

8.5.4 Mobile Network Measurements with emulated GEO satellite backhaul ........................... 99

9 Summary and Conclusions .......................................................................................................... 106

9.1 Overall Evaluation and Lessons Learned ........................................................................... 106

9.2 Conclusions ......................................................................................................................... 107

9.3 Next Steps ........................................................................................................................... 107

SaT5G (761413) D5.2/D5.4 March 2020

of 108

10 References ............................................................................................................................... 108

SaT5G (761413) D5.2/D5.4 March 2020

of 108

List of Figures

Figure 1: SaT5G Research Pillars – Focus on the ones related to the ZII test bed ............................. 15 Figure 2: Satellite Positioning in 5G Direct and Indirect Access Architectures [1] ................................ 16 Figure 3: Main components of the ZII test bed describing the end-to-end configuration ..................... 17 Figure 4: Detailed ZII 5G test bed architecture ..................................................................................... 18 Figure 5: Mapping of the ETSI MANO reference architecture onto the ZII test bed virtualised infrastructure ......................................................................................................................................... 18 Figure 6: Scenario A4 – Indirect access via transparent transport network with bent-pipe payload [5] .............................................................................................................................................................. 19 Figure 7: Satellite Transport Network non-based on 3GPP specifications [1] ...................................... 19 Figure 8: Aircraft Network infrastructure available at the ZII office in Wessling (Germany) ................. 21 Figure 9: A320 cabin mock-up available at the ZII office in Wessling (Germany) ................................ 21 Figure 10 Integrated Terrestrial and Satellite Framework. ................................................................... 24 Figure 11 TALENT system architecture. ............................................................................................... 25 Figure 12 TALENT GUI; satellite and terrestrial project creation, package onboarding and service instantiation. .......................................................................................................................................... 27 Figure 13: OSM service orchestrator version five dashboard view as a result of the instantiation commands from TALENT ...................................................................................................................... 27 Figure 14: Geographical distribution of the ZII 5G test bed for MEO demonstration ............................ 28 Figure 15: ZII test bed system architecture for MEO orbit demonstrations with O3b satellite segment .............................................................................................................................................................. 29 Figure 16: ZII test bed for MEO orbit connectivity over O3b constellation ........................................... 30 Figure 17: O3b System Overview ......................................................................................................... 31 Figure 18: O3b MEO HTS Constellation Showing Customer and Gateway Spot Beams .................... 31 Figure 19: SES Network Map ............................................................................................................... 32 Figure 20: Line-Up Form - FWD Link: From Sintra to Wessling ........................................................... 33 Figure 21: Line-Up Form - RTN Link: From Wessling to Sintra ............................................................ 34 Figure 22: O3b Gateway Site ................................................................................................................ 35 Figure 23: SaT5G ZII Testbed Equipment Installed at O3b GW Teleport at Sintra, Portugal .............. 36 Figure 24: Rack unit in Sintra GW where the Gilat switch was connected ........................................... 37 Figure 25: O3b Customer Terminal - Tier 2 Terminal Equipment ......................................................... 38 Figure 26: O3b Customer Tier 2 Terminal: 1.2m AvL Ka-band transportable dual-antenna terminal .. 38 Figure 27: AvL terminal installation at Wessling (ZII Premises Rooftop) – Outdoor Equipment .......... 39 Figure 28: AvL terminal installation at Wessling (ZII Indoor Room) – Indoor Rack Equipment ............ 39 Figure 29: AvL terminal installation at Wessling (ZII Indoor Room) – View from AvL Laptop Control Station ................................................................................................................................................... 40 Figure 30: Block diagram of the Satellite equipment at the remote site (Wessling) ............................. 40 Figure 31: Block diagram of the satellite equipment at the Sintra teleport ........................................... 41 Figure 32: Gilat GLT-1000 modem (https://www.gilat.com/technology/glt1000/) ................................. 42 Figure 33: Gilat GLT modem parameters and values ........................................................................... 42 Figure 34: EMC Satcom Technologies GmbH - MEO BoosterTM ......................................................... 43 Figure 35: Optimal MEO Boosters configuration based on experimental evidence ............................. 44 Figure 36: Layer 2 VPN Link between Sintra GW and Wessling: CTN Switch Port used at Sintra GW .............................................................................................................................................................. 45 Figure 37: Open5GCore system architecture [13] ................................................................................ 46 Figure 38: 5G core deployment for illustrating user plane connectivity from an end-to-end perspective .............................................................................................................................................................. 47 Figure 39: Broadpeak virtualised content delivery service ................................................................... 48 Figure 40: ZII test bed system architecture for an emulated GEO orbit satellite backhaul .................. 52 Figure 41: SkyEdge II-c gateway architecture ...................................................................................... 53 Figure 42: Network architecture of deployment to demonstrate GEO satellite connectivity ................. 54 Figure 43: Rack equipment at Gilat’s office in Tel Aviv (Israel) for the Sky Edge II-c satellite hub ...... 55 Figure 44: Block diagram of the end-to-end connectivity in the emulated GEO satellite system ......... 56 Figure 45: End-to-end test bed components (virtualised and hardware) availing emulated GEO satellite connectivity............................................................................................................................................ 56 Figure 46: MEC-Core workflow for internet and local cached content access for a UE ....................... 58 Figure 47: Complete ZII test bed infrastructure for demonstrating MEO satellite backhaul ................. 61 Figure 48: Screen capture of the Gilat modem at the aircraft (remote) location in the ZII office, Wessling .............................................................................................................................................................. 62

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 49: Screen capture of the Gilat modem at the O3b teleport (central) location in Sintra ............ 62 Figure 50: MEO Booster settings .......................................................................................................... 63 Figure 51: Block diagram of the content delivery based on the BPK system components .................. 64 Figure 52: Flowchart for mobility management in the Open5GCore with APN-based UE association 65 Figure 53: Measured time durations of the different phases that are required to fully start the SkyEdge II-c satellite hub for GEO connectivity ................................................................................................... 70 Figure 54: Measured time durations of the different phases that are required to fully start the Quortus mobile core network with CUPS feature to enable end-to-end connectivity over GEO satellite .......... 70 Figure 55: Measured time durations of the different phases that are required to start the Broadpeak content delivery service ......................................................................................................................... 71 Figure 56: Measured service creation for the Open5GCore: one VM for the Aircraft UPF and one VM for the Ground UPF and control plane functions. ................................................................................. 71 Figure 57: Measured data rate over the O3b RTN link (from Wessling to Sintra only) during satellite handover – iperf with UDP traffic .......................................................................................................... 72 Figure 58: Measured jitter over the O3b RTN link (Wessling to Sintra only) during satellite handover – iperf with UDP traffic ............................................................................................................................. 72 Figure 59: Measured packet loss over the O3b RTN link (from Wessling to Sintra only) during satellite handover – iperf with UDP traffic .......................................................................................................... 72 Figure 60: Measured data rate over the O3b FWD link (Sintra to Wessling only) during satellite handover – iperf with UDP traffic .......................................................................................................................... 73 Figure 61: Measured jitter over the O3b FWD link (Sintra to Wessling only) during satellite handover – iperf with UDP traffic ............................................................................................................................. 73 Figure 62: Measured packet loss over the O3b FWD link (Sintra to Wessling only) during satellite handover – iperf with UDP traffic .......................................................................................................... 73 Figure 63: Measured round trip time over the O3b satellite link (from one Gilat modem to another) ... 74 Figure 64: Measured end-to-end data rate between the Aircraft network (Wessling) and the ZII datacentre (Wessling) including OTA O3b satellite link and Layer 2 VPN – no satellite handover ...... 74 Figure 65: Measured end-to-end jitter between the Aircraft network (Wessling) and the ZII datacentre (Wessling) including OTA O3b satellite link and Layer 2 VPN – no satellite handover ........................ 74 Figure 66: Measured end-to-end packet loss between the Aircraft network (Wessling) and the ZII datacentre (Wessling) including OTA O3b satellite link and Layer 2 VPN – no satellite handover ...... 75 Figure 67: Measured end-to-end data rate between the Aircraft network (Wessling) and the ZII datacentre (Wessling) including OTA O3b satellite link and Layer 2 VPN – during O3b satellite handover .............................................................................................................................................................. 75 Figure 68: Measured end-to-end jitter between the Aircraft network (Wessling) and the ZII datacentre (Wessling) including OTA O3b satellite link and Layer 2 VPN – during O3b satellite handover .......... 75 Figure 69: Measured end-to-end packet loss between the Aircraft network (Wessling) and the ZII datacentre (Wessling) including OTA O3b satellite link and Layer 2 VPN – during O3b satellite handover .............................................................................................................................................................. 76 Figure 70: Measured data rate between the ZII DC (Wessling) and the Aircraft Network (Wessling) including OTA O3b satellite link and Layer 2 VPN – no satellite handover .......................................... 76 Figure 71: Measured jitter between the ZII DC (Wessling) and the Aircraft Network (Wessling) including OTA O3b satellite link and Layer 2 VPN – no satellite handover ......................................................... 76 Figure 72: Measured packet loss between the ZII DC (Wessling) and the Aircraft Network (Wessling) including OTA O3b satellite link and Layer 2 VPN – no satellite handover .......................................... 77 Figure 73: Measured data rate between the ZII DC (Wessling) and the Aircraft Network (Wessling) including OTA O3b satellite link and Layer 2 VPN – during O3b satellite handover ............................ 77 Figure 74: Measured jitter between the ZII DC (Wessling) and the Aircraft network (Wessling) including OTA O3b satellite link and Layer 2 VPN – during O3b satellite handover ........................................... 77 Figure 75: Measured packet loss between the ZII DC (Wessling) and the Aircraft network (Wessling) including OTA O3b satellite link and Layer 2 VPN – during O3b satellite handover ............................ 77 Figure 76: Observed file downloading speed before the occurrence of a satellite handover ............... 78 Figure 77: Observed file downloading speed during the occurrence of the satellite handover ............ 79 Figure 78: Observed file downloading speed after the satellite handover completion ......................... 79 Figure 79: Measurement of the physical layer throughput during the occurrence of a satellite handover .............................................................................................................................................................. 80 Figure 80: Gilat modem interface: measured SNR for reception in Sintra and transmission in Wessling .............................................................................................................................................................. 80 Figure 81: MEO Booster panel (left) and Gilat modem interface (right): observed throughout behaviour during smooth O3b satellite handover .................................................................................................. 81

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 82: MEO Booster panel (left) and Gilat modem interface (right): observed SNR behaviour during smooth O3b satellite handover ............................................................................................................. 81 Figure 83: Gilat modem interface: observed SNR reduction at the receiver in Wessling (top) and SNR increase at the transmission in Sintra (bottom)..................................................................................... 82 Figure 84: Measured transfer rate between Aircraft-UPF and small cell radio on-board the aircraft ... 83 Figure 85: Measured Round Trip Time between a connected UE and the Aircraft-UPF ..................... 83 Figure 86: Measured Round Trip Time between the Aircraft small cell and the Internet ..................... 83 Figure 87: Measured DL traffic at the mobile core – one UE accessing youtube ................................. 84 Figure 88: Measured DL/UL traffic at the aircraft small cell – three UEs youtube, one UE cached content .............................................................................................................................................................. 84 Figure 89: Measured DL/ traffic at the aircraft small cell – two UE live video streaming, one youtube, one cached ............................................................................................................................................ 85 Figure 90: Measured DL traffic at the mobile core – two UE live video streaming, one youtube, one cached ................................................................................................................................................... 85 Figure 91: Measured DL traffic at the aircraft small cell – one UE live video streaming, one UE youtube, one UE cached content ......................................................................................................................... 86 Figure 92: Measured DL/UL traffic during satellite handover – two UE live video streaming, one UE youtube, one UE cached content .......................................................................................................... 86 Figure 93: Measured Round-Trip-Time between the ground small cell access network and the Internet .............................................................................................................................................................. 87 Figure 94: Measured DL/UL data traffic at the ground small cell – two UE live video streaming, two UE youtube.................................................................................................................................................. 88 Figure 95: DL traffic comparison measured at the ground and aircraft small cells ............................... 88 Figure 96: Small Cell Radio Access – Casa Systems [6] ..................................................................... 88 Figure 97: Screenshot of a UE with Network Cell Info Lite App: left shows the UE attached to cell with PCI 422; right shows the UE after cell reselection to the small cell with PCI 425 ................................ 89 Figure 98: Measured round-trip-time to access the Internet (e.g. Google) with the superimposition of satellite handover and mobile network handover ................................................................................. 90 Figure 99: Measured Es/N0 by the VSAT terminal ................................................................................ 94 Figure 100: SNR measured at the SkyEdge II-c satellite hub .............................................................. 95 Figure 101: Benchmark of the inbound GEO satellite link: outcome of an FTP file transfer ................ 95 Figure 102: Benchmark of the outbound GEO satellite link: outcome of an FTP file transfer .............. 96 Figure 103: Measured traffic over the outbound emulated GEO satellite backhaul: one UE browse, one UE cached content and two UEs youtube ............................................................................................ 96 Figure 104: Measured traffic over the inbound emulated GEO satellite backhaul: one UE browse, one UE cached content and two UEs youtube ............................................................................................ 97 Figure 105: Measured traffic in the outbound of the emulated GEO satellite backhaul ....................... 98 Figure 106: Measured traffic in the outbound of the emulated GEO satellite backhaul ....................... 98 Figure 107: Measured round trip time across the emulated GEO satellite path not including the Layer 3 VPN ....................................................................................................................................................... 99 Figure 108: End-to-end GEO satellite link connection – measured traffic with iperf UDP server on the mobile core .......................................................................................................................................... 100 Figure 109: End-to-end GEO satellite link connection – measured jitter with iperf UDP server on the mobile core .......................................................................................................................................... 100 Figure 110: End-to-end GEO satellite link connection – measured packet loss with iperf UDP server on the mobile core .................................................................................................................................... 101 Figure 111: Measured RTT form the aircraft network to Google over the GEO satellite .................... 101 Figure 112: Measured UE latency to access cached content through the MEC server ..................... 102 Figure 113: Measured traffic at the small cell access – one UE connected in Idle mode .................. 102 Figure 114: Measured DL/UL data rate at the small cell – one UE browsing, one UE cached content, one UE youtube, 1 UE live video stream ............................................................................................ 103 Figure 115: Measured DL/UL data rate at the small cell – one UE cached content, one UE browsing, two UEs live video traffic ..................................................................................................................... 103 Figure 116: Measured DL/UL data rate at the small cell – one UE cached content, one UE browsing, two UEs youtube traffic ....................................................................................................................... 104 Figure 117: Measured Round-Trip-Time to access Google while moving from the service small cell coverage to the neighbour small cell on -board the aircraft ................................................................ 105 Figure 118: Measured Round-Trip-Time to access cached content through the MEC server while moving from the service small cell coverage to the neighbour small cell ........................................... 105

SaT5G (761413) D5.2/D5.4 March 2020

of 108

List of Tables

Table 1: ETSI NFV-MANO elements implemented in ZII Test bed ...................................................... 22 Table 2: SaT5G ZII Testbed Equipment Installed at O3b GW Teleport at Sintra, Portugal ................. 35 Table 3: Equipment for O3b connectivity deployed at the remote site (Wessling) ............................... 41 Table 4: Equipment deployed at the O3b teleport ................................................................................ 41 Table 5: Summary of BPK CDN components ....................................................................................... 48 Table 6: List of Final Integrated Satellite/Terrestrial 5G Network Architecture Elements (Over-The-Air MEO Satellite Connectivity) .................................................................................................................. 49 Table 7: List of Physical and virtualised components for GEO satellite connectivity emulation ........... 54 Table 8 : List of final integrated satellite/terrestrial 5G network architecture elements (emulated GEO satellite connectivity) ............................................................................................................................. 58 Table 9: Test cases for MEO satellite ................................................................................................... 63 Table 10: Test cases for GEO satellite ................................................................................................. 65 Table 11: Test cases for the mobile network control/user plane .......................................................... 66 Table 12: Satcom specific KPIs measured over the ZII test bed .......................................................... 68 Table 13: KPIs measured over the ZII test bed and radio access network .......................................... 69 Table 18: Comparison between ground radio access network and Aircraft access network based on GEO satellite backhaul. ......................................................................................................................... 82 Table 15: SD Profile .............................................................................................................................. 90 Table 16: HD Profile .............................................................................................................................. 90 Table 17: UHD Profile ........................................................................................................................... 90 Table 18: Measured and estimated transfer rate internal to CDN components ................................... 91 Table 19: Measured and estimated transfer rate to the nanoCDN ....................................................... 92 Table 20: Time require to cache a catalogue of 20 popular HD VOD assets ....................................... 92 Table 21: Comparison between multicast and unicast injection of assets if the VOD .......................... 93 Table 22: Summary of the benefits of using multicast over satellite ..................................................... 93 Table 23: Control plane measurements ................................................................................................ 99 Table 24: Speed test carried out at a PED connected to the Aircraft Network ..................................... 99

SaT5G (761413) D5.2/D5.4 March 2020

of 108

List of Acronyms

3GPP 3rd Generation Partnership Project ABR Adaptive Bit Rate APN Access Point Name BPK Broadpeak BYOD Bring Your Own Device BUC Block Up Converter CDN Content Delivery Network COTS Commercial Off The Shelf CUPS Control, User Plane Separation DL Downlink E2E End-to-End eMBB Enhanced Mobile Broadband ETSI European Telecommunication Standards Institute FTP File Transfer Protocol GEO Geostationary Orbit GLT Gilat GW Gateway IB In-bound IFE Inflight Entertainment IFEC Inflight Entertainment and Connectivity LTE Long Term Evolution MANO Management and Orchestration MEC Multi-access Edge Computing MEO Medium Earth Orbit mMTC Massive Machine Type Communications MODCOD Modulation and Coding NAS Non Access Stratum NFV Network Functions Virtualisation NFVI Network Functions Virtualisation Infrastructure NMS Network Management System NSD Network Service Descriptor NTN Non-Terrestrial Network NTP Network Time Protocol O3b Other 3 billion (people) OB Out-Bound OSM Open Source Mano OSS Operational Support System OTA Over The Air PED Personal Electronic Device PEP Performance Enhancing Proxy QUO Quortus RAN Radio Access Network RTT Round Trip Time SaT5G Satellite and Terrestrial Network for 5G SCPC Single Channel Per Carrier SDB System Data Broadcast SDN Software Defined Networking SNR Signal to Noise Ratio UE User Equipment UPF User Plane Function UL Uplink URLLC Ultra-Reliable and low latency Communications VIM Virtual Infrastructure Manager VNF Virtual Network Function VNFD Virtual Network Function Descriptor

SaT5G (761413) D5.2/D5.4 March 2020

of 108

VOD Video on Demand VPN Virtual Private Network ZII Zodiac Inflight Innovations

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Executive Summary

This deliverable describes the validation and demonstration activities of the 5G test bed led by Zodiac Inflight Innovations (ZII) with regard to the SaT5G Use Case 4 “5G Moving Platform backhaul” [1]. It combines two deliverables in one (D5.2 and D5.4), because in practise it turned out that D5.4 required D5.2 as an integral step, and it made sense to combine them. Two companion deliverables (D5.2/D5.3 and D5.2/D5.5) describe the partner WP5 test beds at the University of Surrey and the University of Oulu, which showcased Fixed and Home Backhaul Scenarios Including Caching & Multicast, and NR air interface over satellite, respectively. All three of these deliverables feed into D5.6 that presents the testbed results and gives recommendations.

The ZII test bed targets satellite – terrestrial integration into 5G focusing on the aviation vertical sector in partnership with the GEO/MEO satellite operator SES, the satellite ground segment vendor Gilat, the mobile core network provider Quortus, the content delivery service Broadpeak and the research centre i2CAT. The ZII test bed developed a prototype Inflight Entertainment and Connectivity (IFEC) system that avails 5G technology for delivering the next generation of enhanced Mobile Broadband (eMBB) services to aircraft end-to-end. The uptake of wireless communication systems in the aviation sector is rapidly growing and 5G is at the forefront of this change. In this context, satellite links, both in the Medium Earth Orbit (MEO) and Geostationary Orbit (GEO), are crucial for connecting aircraft to a ground data network such as the Internet, as well as the wireless connectivity system on-board that, amongst others, can enable content caching leveraging on the Multi-access Edge Computing (MEC) paradigm. The end-to-end 5G connectivity system targets airline passengers mainly, but also flight personnel can benefit from it. While the existing connectivity solutions for aircraft are purely hardware based with limited penetration of mobile technology, which is limited to voice services, the next generation of systems will be based on virtualisation technology.

The ZII test bed trials rely on an Over-the-Air (OTA) MEO satellite backhaul system that is based upon the SES’s O3b satellite constellation in which Gilat used the MEO Booster technology, an innovative approach to simplify and reduce the complexity of the satellite handover process. In addition, the ZII test bed trials rely on GEO satellite emulation setup where Gilat used virtualisation technology to deploy the virtualised SkyEdge II-C satellite hub. In the O3b MEO OTA satellite backhaul test bed setup, multicast transmissions were used to create an on-demand catalogue of media content relying on the Broadpeak content delivery service. In addition, a 4G mobile core network implementing Control and User Plane Separation (CUPS), as well as a prototype 5G mobile core network were used in the trials, which also made use of a small cell radio access and commercial off-the-shelf (COTS) User Equipment (UEs) such as smartphones and tablets. In view of the next generation of aircraft connectivity enabled by means of 5G, this is aligned with the current market trends in which passengers’ Personal Electronic Devices (PEDs) are increasingly more important, thus embracing the concept of Bring-Your-Own-Device (BYOD) on-board.

Concluding, the ZII test bed achievement is manifold: 1) we implemented network virtualisation on both satellite and terrestrial segments, 2) we achieved an integrated resource management and orchestration, 3) we experimented MEO and GEO satellite technologies allowing us to assess and compare both, 4) we experimented different generation of mobile core (5G and 4G), 5) we experimented for the first time ever caching on-board the aircraft infrastructure and multicast for content upload, 6) we demonstrated the feasibility of the 5G technology developed within SaT5G to fulfil the actual demand of passengers.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

1 Introduction

This deliverable describes the test bed led by Zodiac Inflight Innovations (ZII), the validation and demonstration activities underwent to achieve 5G satellite – terrestrial integration for GEO and MEO based satellite connectivity. It combines two deliverables in one (D5.2 and D5.4), because in practise it turned out that D5.4 required D5.2 as an integral step, and it made sense to combine them. Although D5.2 was originally listed as a ‘Confidential’ deliverable, upon review we decided that no sensitive material was involved, and so the combined document is categorised as ‘Public’.

1.1 Scope The ZII test bed within the SaT5G project [2] revolves around the demonstration of 5G targeting the aviation vertical sector. The test bed was developed in collaboration with the satellite operator SES, the satellite ground segment vendor Gilat (GLT), the mobile core network provider Quortus (QUO), the content delivery service Broadpeak (BPK) and the research centre i2CAT for resource management and coordination. While planning of the related validation activities were reported in the companion deliverable D5.1 [3], the current project deliverable is devoted to report on the execution of the validation plan, its implementation and overall test results and achievements. Specifically, the SaT5G Use Case 4 “5G Moving Platform backhaul” included the following scenarios in the demonstrations:

1) Scenario 4a (Updating content for on-board systems and grouped media requests): the IFE catalogues on-board aircraft are updated with media content such as movies, TV series and music. The content can be a whole media catalogue (hundreds of gigabytes of data) or a smaller asset of volatile popular content that can be consumed by passengers on a time scale some events can last (sports events, popular shows, etc). The catalogue can be simultaneously updated to multiple airplanes exploiting multicast transmissions over the satellite connection.

2) Scenario 4b (Broadband access for passengers and individual media requests): Passengers connect to the end-to-end 5G system and with simple operations like downloading an App on their PEDs they can access the content stored either in the media server or at any convenient storage place in the aircraft. In this case passengers make use of the on-board mobile network connection to consume content cached at the edge. Relying on the same network connection, passengers can also access a data network on the ground like the Internet.

3) Mobility Management of passengers’ personal devices: passengers before entering the aircraft can be connected to the airport mobile network (home or visiting) on ground which relies on the typical terrestrial backhaul connectivity (e.g. optical fibre) and switch to the on-board system as soon as they enter the aircraft in one case. In another case, passengers can move from the coverage of a small cell on-board to the cell coverage of another one. This is the typical situation in a two-aisle aircraft for long haul routes that can have multiple small cells on-board. In both situations the end-to-end connection can be sustained only whereby the satellite connection to the mobile core on the ground.

From the planning phase of the test bed, the ZII test bed partners embraced a continuous monitoring and revision process while implementing the decisions made at the design stage. As a result, the ZII test bed was developed integrating the ETSI Management and Orchestration (MANO) framework for Network Functions Virtualisation (NFV) since its inception [4]. Thus, the ZII test bed stands as a Network Functions Virtualisation Infrastructure (NFVI) managed by the OpenStack cloud controller (Queens release) in which virtualised services are deployed through the release 5 of the ETSI Open Source Mano (OSM) orchestrator and the satellite – terrestrial resource coordinator TALENT, with the latter acting as the unified Operational Support System (OSS) for both the satellite and terrestrial networks.

Following the continuous revision process already mentioned, the ZII test bed partners decided to carry on with two core demonstrations:

1) An over-the-air (OTA) satellite relying on the SES’s O3b MEO satellite constellation, and

2) An emulated GEO satellite connection.

On the one hand, the OTA demonstration was implemented whereby the innovative MEO Booster technology, which allows managing the O3b satellites handover with one single modem both at the Gateway (GW) teleport side in Sintra (Portugal) and at the ZII premises in Wessling (Germany). On the other hand, the emulated GEO satellite connection was carried out virtualising the GLT’s SkyEdge II-c hub. Moreover, the aircraft connectivity tackled by the ZII test bed while implementing MEO satcom equipment relied also on a prototype 5G mobile core network, whereas instead the GEO path made

SaT5G (761413) D5.2/D5.4 March 2020

of 108

use of the QUO 4G mobile core with CUPS. The content delivery network (CDN) provided by BPK was used for both demonstrations to deliver a typical IFE service on aircraft through Multi-access Edge Computing (MEC). Furthermore, typical bare metal services were instead developed as virtualised network services that comprise a different number of virtualised network functions (VNFs) depending on the solution that is tackled.

1.2 Context The ZII test bed demonstrated the following SaT5G Research Pillars;

1) Research Pillar I: Implementing 5G SDN and NFV in Satellite Networks. 2) Research Pillar II: Integrated Network Management and Orchestration. 3) Research Pillar VI: Caching & Multicast for Optimised Content & NFV Distribution.

Figure 1: SaT5G Research Pillars – Focus on the ones related to the ZII test bed

1.3 Document structure The remainder of this technical document is as follows. Section 2 briefly reviews the architecture devised within SaT5G. Section 3 provides description of the ZII test bed used for conducting the test measurements. Section 4 focuses on the test bed components for the over-the-air MEO satellite backhaul connectivity. Section 5 focuses on the test bed components for the emulated GEO satellite backhaul connectivity. Section 6 provides description of the measurement activities carried out over the ZII test bed. Section 7 shows the measured Key Performance Indicators (KPIs), whereas Section 8 is completely devoted on presenting the actual measurement results. Section 9 is used for inspecting the main findings obtained out of the test bed measurements and Section 9.2 provides the overall conclusions of the ZII test bed activities.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

2 SaT5G System Architecture for 5G Satellite Integrated

Access

At the outset of this section, it is crucial to distinguish the satellite, or Non-Terrestrial Network (NTN) architecture, from the end-to-end (E2E) network architecture as captured in the SaT5G deliverable D3.1: Integrated SaT5G General Network Architecture [1]. The architectures are distinguished, among other things, by the position of the satellite within the network, as illustrated in Figure 2. We highlight that the figure overlaps the 5G system architecture with the core in point-to-point reference architecture defined by 3GPP with the SaT5G architectural choices. Therefore, in the Direct Access architecture, a satellite-capable UE may access the satellite link directly; in the Indirect Access architecture however, the UE does not possess satellite capabilities, and as such relies on a Donor or Relay Node through which it connects to the satellite network. This is also known as the backhaul architecture. The E2E network, which is comprised of both the terrestrial 5G network and the satellite network, implements the indirect access use case, utilising the satellite network purely for backhaul.

Remark: The ZII test bed tackles the specific choice of a backhaul architecture.

Figure 2: Satellite Positioning in 5G Direct and Indirect Access Architectures [1]

SaT5G (761413) D5.2/D5.4 March 2020

of 108

3 Final ZII Test Bed Architecture

The ZII test bed relies on three main locations as shown in Figure 3. Namely the central ZII 5G Infrastructure in Wessling that controls also the other two remote sites, the SES O3b satellite teleport in Sintra and the Gilat node in Tel Aviv. The central infrastructure is connected to the O3b teleport whereby a Virtual Private Network (VPN) that operates at the Layer 2 of the OSI model, whereas it is connected to the remote node in Tel Aviv whereby a VPN that operates at the Layer 3.

Figure 3: Main components of the ZII test bed describing the end-to-end configuration

Bearing in mind the high-level organization of the ZII test bed shown in Figure 3, the detailed view of the test bed that was used for demonstrating satellite – terrestrial integration in 5G is provided in Figure 4. The figure describes the type of overall infrastructure built to carry on the trials both for OTA satellite connection in the MEO orbit and the emulated GEO satellite connectivity. We can recognize in the central ZII infrastructure the Ground Datacentre (DC) and the Aircraft Network already discussed in [3]. In the very first place, we highlight that the ZII infrastructure is composed of Commercial Off The Shelf (COTS) hardware (HW) with specialised software (SW) running on it, thus decoupling the software from the underlying hardware as per the parading of Software-Defined Networking (SDN) and NFV. While in-depth description of each test be component is provided in the following sections, we want to highlight few facts hereinbelow.

We remark from Figure 4 that partners of the ZII test bed (GLT, QUO, BPK, i2CAT and SES) had the opportunity to connect to the test bed whereby the CISCO AnyConnect client VPN, with each partner using own private test bed access credentials.

First, the overall demonstrations of the SaT5G project took place in the A320 cabin mock-up located in the ZII office as planned in [3], which is a loyal reproduction of the interior of a cabin aircraft. In this environment, we allow passengers to trial mobile network access using their PEDs. Second, the ZII test bed in overall is a cloud infrastructure (i.e. NFVI) managed by the cloud controller OpenStack release Queens. The cloud controller with the associated compute nodes are located in the ZII office in Wessling, while additional OpenStack compute nodes located in the Gilat office in Tel Aviv that are managed by the cloud controller in Wessling, thus extending the ground DC over different geographical locations. Throughut the project, the bare metal services that were virtualised are deployed relying on the OSM orchestrator version five. Anyway, in order to manage both the terrestrial and the satellite segments, the OSS layer TALENT is used to instruct OSM about the services to deploy. Apposite network service descriptor (NSD) files were developed resorting to a YANG data model. Specifically, the NSD invokes VNF descriptors to spin up the virtual machines (VMs) in the OpenStack compute nodes at the specified test bed location (Aircraft network of Ground DC). We remark in Figure 5 the way the ZII test bed implements the ETSI MANO reference architecture defined in [4]. In the remainder of this document, we assume basic knowledge of OpenStack, OSM and the way both inter-communicate.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 4: Detailed ZII 5G test bed architecture

Figure 5: Mapping of the ETSI MANO reference architecture onto the ZII test bed virtualised infrastructure

SaT5G (761413) D5.2/D5.4 March 2020

of 108

3.1 Positioning the ZII Test bed System Architecture The ZII testbed’s E2E network implements a variant of the Indirect Access architecture (backhaul), as defined in the SaT5G deliverable D3.1: Integrated SaT5G General Network Architecture [1]. This architecture is also presented in the ETSI SES document 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" [5]. With regard to the latter, the architecture option that was implemented in the ZII testbed is “Indirect Access via Transparent Transport Network with Bent-Pipe payload”.

Figure 6: Scenario A4 – Indirect access via transparent transport network with bent-pipe payload [5]

With reference to Figure 6, two disparate network levels are observed: coloured in blue, the elements of the standard terrestrial/mobile network are visible, while the elements of a self-contained satellite network are presented in grey. It is worth mentioning also that a variant of the scenario reproduced in Figure 6 includes the presence of an additional block function called Non 3GPP Inter-Working Function (N3IWF) that stands for the case in which the backhaul satellite network is considered untrusted. This latter case, which may happen in reality, is not considered by the ZII test bed for several reasons: 1) the presence of a single OSS sub-system for both the satellite and terrestrial network segments, 2) the assumption of an adequate level of security mechanisms end-to-end and 3) commercial and technical agreements are assumed to be in place in a real deployment so that no untrusted entity is present.

Figure 7: Satellite Transport Network non-based on 3GPP specifications [1]

UE

gNB

UE DN

5G CN

VSATTrusted NTN Transparent

Transport Network

Orchestrator / NMS

RAN

SaT5G (761413) D5.2/D5.4 March 2020

of 108

3.2 Aircraft Radio Access Network Infrastructure The Aircraft Network shown in Figure 8 is a resource constrained network composed of three Intel NUC small servers endowed with Intel i7-6770HQ processor that has 4 physical CPU cores, CPU frequency 2.60 GHz, 16 GB RAM and 512 GB SSD internal storage. We also included two Raspberry Pi Three for the sake of populating the video on-demand catalogue of popular assets for demonstrating MEC caching service. This choice was motivated by the fact that a typical aircraft infrastructure for IFE is an embedded system in which hardware and software resources are optimized but purposely limited to comply with hardware form factors and power consumption constraints specified by aviation standards such as ARINC 429 and ARINC 628.

The servers mentioned above are part of the OpenStack infrastructure of compute nodes that is accessible from ground only through the satellite backhaul connection, either GEO based on MEO based. The servers on-board mount Linux Operating System (OS) Ubuntu distribution version 16.04 and are used to deploy virtualised network functions such as for the mobile core network or the content delivery network. The specific mobile core functions include the 5G User Plane Function (UPF) and the MEC component of the 4G core with CUPS. A network switch on board connects the server elements so as to create a single Layer 2 multicast domain with IP address range 172.24.0.x.

The radio access network on-board the A320 cabin mock-up shown in Figure 9 is composed of software defined radio cards based on National Instruments B210 devices, which were used for the purpose of initial tests whereby the open source software srsLTE. For more professional use, the testing environment relied on small cell radios supplied by CASA Systems as part of a collaboration between the ZII test bed and another 5G PPP Phase II project 5G ESSENCE [6]. The small cell access is implemented with features of 3GPP Releases 13 and 14, as well as with self-organizing network (SON) features such as Automatic Neighbour Relation (ANR) that can be used for mobility management of UEs.

The UEs we used in the Aircraft Network are COTS devices and include OnePlus 5T smartphones and Samsung Galaxy that use Android OS.

Remark 1: throughout the time we developed the ZII test bed we found out limited market availability of 5G enabled UEs, although we noticed a change in the market during the later stage of the test bed in which trials were already ongoing. Moreover, to the best of our knowledge, we found out that the market of gNBs was mainly based on protypes and anyway targeting macrocell outdoor installations and not small cells.

Remark 2: The aero certified Wi-Fi system comprising are seat screens and Access Point manufactured by ZII was finally not used in the demonstration although the screens are enabled with Wi-Fi connectivity as mentioned [3]. Throughout the test bed development, we found the following fact and barrier: as a matter of fact, the BYOD concept is gaining increasing momentum and airlines are demanding a wireless IFE system for connecting passengers’ personal devices; we also found out that the N3IWF for connecting an untrusted non 3GPP access to the 5G core was not yet available at the time the trials were carried out, additionally an Evolved Packet Data Gateway (EPDG) for the 4G core was not available.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 8: Aircraft Network infrastructure available at the ZII office in Wessling (Germany)

Figure 9: A320 cabin mock-up available at the ZII office in Wessling (Germany)

SaT5G (761413) D5.2/D5.4 March 2020

of 108

3.3 Ground Datacentre The Ground Datacentre infrastructure located at the ZII office in Wessling that was created for developing the 5G system comprises five Fujitsu Primergy servers with different functionalities located in a server rack: two servers mounting Intel Xeon X650 processor with 12 virtual CPU cores, CPU frequency 2.67 GHz, 32 GB RAM and 1 TB HD internal storage; three servers mounting Intel Xeon E3-1230 V2 processor that has 8 virtual CPU cores, CPU frequency 3.30 GHz, 32 GB RAM and 1 TB HD internal storage. On the remote site in Tel Aviv one server with Intel Xeon E5620 mounting Linux Ubuntu distribution 18.04 and another one with Ubuntu 16.04 were used. All servers in the ZII DC rely on Linux OS Ubuntu distribution 16.04. As already discussed, the ZII Ground DC extends also over the GLT servers, which act as OpenStack compute nodes that are controlled by the OpenStack Controller in the ZII office in Wessling.

The ZII Ground DC was conceived to host the ETSI MANO management framework and the main part of the NFVI. In the ZII ground DC, including the remote OpenStack compute nodes at the GLT’s office in Tel Aviv, we used DevStack as an installer of OpenStack, particularly the HORIZON project for the GUI, the NOVA project for storing the Virtual Machine (VM) images and the NEUTRON project for the networking part. The OpenStack installation includes the private internal network and the public network with the two that are connecting using the virtual OpenStack router. On the internal network, the VMs make use of the Open Virtual Switch (OVS) utility for connectivity and on an internal IP address range. As well-known, the external network allows SSH sessions to the VMs that can be reached from an external network through Floating IP in the range of 172.24.10.y. Moreover, as mentioned, partners of the ZII test bed were able to connect to the test bed whereby the CISCO AnyConnect client VPN utility.

Referring to the ETSI MANO reference architecture shown in Figure 5, the VNF manager, the entity responsible to handle the lifecycle of the VNFs, is based on Juju Charms directly in OSM. The Ground ZII DC hosted also the OSS TALENT layer for satellite – terrestrial resource management. In overall, the traditional bare metal services are abstracted from the type of hardware and converted into virtual services. Specifically, those deployed in the ZII DC include

The GLT SkyEdge II-C virtualised satelite hub

The QUO 4G mobile Core with CUPS

The 5G mobile core

The BPK content delivery service.

Remark 1: in the context of the ZII test bed, we realised that SDN component was sufficient to remain at the level of the open virtual switch with OpenFlow rules managed by the OpenStack NEUTRON. Thus, we decided to avoid connecting a specific SDN controller to the OpenStack Controller Queens.

3.4 Virtualization and SDN for Satellite Network Functions The SaT5G deliverable, D4.1: Virtualization of Satcom Components – Analysis, Design and Proof of Concepts [7], describes in detail the virtualisation of satellite network functions for satellite networks, the outputs of which act as inputs to the WP5 testbeds. For context, an overview of relevant concepts described in that document follows.

One of the primary goals of SaT5G WP4.1 was production of a set of virtualized and SDN-capable satellite network functions, for deployment within the WP5 testbeds. In pursuit of this objective, the ZII test bed partners made a joint effort to achieve such goal in the satellite and terrestrial network architectures, introducing additional elements from the industry-standard ETSI NFV-MANO (NFV-Management and Orchestration) framework [8], as well as the aforementioned 3GPP network architecture [9]. The NFV-MANO framework describes a standardised set of elements and interfaces that comprise an SDN-NFV system. The NFV-MANO elements introduced into the virtualised satellite – terrestrial network architecture, are described in Table 1.

Table 1: ETSI NFV-MANO elements implemented in ZII Test bed

NFV-MANO Element

Description SaT5G Instance

Virtualisation Layer (Hypervisor)

Provides abstraction and logical separation of physical and virtual resources, enabling deployment of

Kernel Virtual Machine (KVM) Linux kernel module

SaT5G (761413) D5.2/D5.4 March 2020

of 108

multiple virtual machines on shared physical hardware

Network Functions Virtualisation Infrastructure (NFVI)

Provides the underlying resources and execution environment for Virtual Network Functions (VNFs)

COTS x86 general purpose servers

Virtual Infrastructure Manager/Cloud Controller

Manages the NFVI, and controls VNF lifecycle. Exposes a northbound API for integration with SDN orchestrators

OpenStack (Queens) VNF images

Orchestrator Coordinates and deploys VNFs as a network service (via an underlying VIM)

Open Source MANO (OSM) Version Five

Satellite - terrestrial resource coordinator

Unified OSS layer TALENT

Service, VNF and Infrastructure Description

Provides the required descriptors and resources that enable an Orchestrator to deploy a network service

OSM Virtual Network Function Descriptors (VNFDs) OSM Network Service Descriptor (NSD)

3.5 TALENT Terrestrial – Satellite Resource Coordinator Standardization bodies as 3GPP and ETSI recognize and promote terrestrial and satellite interworking. The complete integration can be achieved with the combination of radio networks, including core and access, and the satellite systems, with computational resources expanded from the core to the network’s edge. A coordination framework is an essential enabler to realize 5G vision to combine management of different resources through a MANO-like framework.

TALENT is a coordination tool, which supports end-to-end services over satellite domain, radio access, cloud and Mobile Edge Computing (MEC) resources. It provides a single and easy to use point of interaction for all stakeholders involved in the ecosystem, such as terrestrial and satellite operators as well as different 5G verticals. TALENT is completely in-line with 3GPP and ETSI definition of hierarchical and distributed orchestration [10], where an overarching orchestrator is able to manage and coordinate several independent domains (satellite, radio and cloud). We assume at each domain, there exist a domain manager (DM) able to work with resources of the domains coming from various vendors.

Having these objectives in mind and based on the frameworks suggested by ETSI MANO [4] and 3GPP SA5 [11], this framework proposes an extension towards satellite integration at the management and orchestration level, to build a multi-tier orchestration stack over a heterogeneous environment. Figure 10 illustrates the framework. The idea of having satellite connectivity along with radio and cloud/edge capacity is not new. However, in the traditional way, the actual process of launching and managing such a complex service demands huge amount of manual operations and processes at the cloud/edge and satellite domains. The local ETSI MANO is used to provision cloud/edge network services, and satellite domain admin used to set up satellite service and connection. Such a complicated and manual process hinders the end-to-end service provisioning and lifecycle management, increase the risk of human errors and reduce the satellite terrestrial services business desirability. TALENT is a solution proposed to tackle this problem. It is an over top management layer with holistic view over all available services and resources. TALENT helps building a multi-tier orchestration stack over a heterogeneous environments, featuring a single point of interaction for all stakeholders engaged in the ecosystem (satellite, terrestrial and cloud operators as well as 5G vertical sectors) enabling them to automatically launch and manage end-to-end satellite terrestrial services. It is completely in line with the 5G high level KPIs such as reducing service-provisioning time from 90 hours to 90 minutes [12].

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 10 Integrated Terrestrial and Satellite Framework.

As shown in Figure 11, current release of TALENT (i.e. release 1) supports satellite and cloud/edge domains (interworking with each other to deliver end-to-end services), and composes of following modules and components:

Northbound REST API: This is the main entry point for different actors such as operators and

verticals. It also provides an abstraction layer, which exposes a well-defined set of functions serving different needs of operators and verticals (e.g. service instantiation, check service status, QoS, monitoring, etc.). TALENT API is a REST-based API, which feed the TALENT graphical user interface – GUI.

MANO Selector Plugin: this module is a reference point where all the required information such as IP address, data model format, vendor and interaction procedures of the supported NFVOs (OSM, ONAP, etc.) and VIMs (OpenStack, OpenVIM, etc.) are kept. MANO Selector Plugin is responsible to register all supported NFVOs and VIMs at the bootstrapping phase. This release supports OSM release 4, 5 and 6, and OpenStack Queen.

Multi-MANO Lifecycle Manager: it is responsible to support NFVO and VIM clients, including their actual service and lifecycle management at the run-time phase. It uses a template file to produce request with required attributes to the cloud/edge domains that registered to system. To manage all received requests, Multi-MANO Lifecycle Manager synchronizes with MANO Selector Plugin to load required and proper dependencies and interact with underlying NFVO and VIM solutions.

Domain Component Plugin: It is a reference point to keep all the required information such as IP address, data model format and configuration settings of the supported satellite components. Domain Component Plugin is responsible to register all supported satellite components at the bootstrapping phase. TALENT will be loaded required dependencies and libraries to establish communication with underlying satellite solutions. Currently, TALENT supports TotalNMS of Gilat.

Domain Configuration Module: This module is responsible to support satellite clients including configuration and lifecycle management of supported solution at the run-time phase. Similar to Multi-MANO Lifecycle Manager, it uses a template file to produce request with required attributes to the satellite domains that registered to the system. To manage received requests, Domain Configuration Module synchronize with the Domain Component Plugin in order to load the required dependencies and interact with underlying satellite solution, which in this work is TotalNMS.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 11 TALENT system architecture.

As TALENT supports auto-deployment practices, user do not need to go through complex process to install TALENT, thus the following procedure is followed:

1. System deployment: TALENT supports auto-deployment using container (docker-based). An ordinary container management tool for running multi-container applications can easily start-up the system and its components;

2. System check: each component will register itself to an internal “Discovery” service, which control activity status of each component and TALENT overall. This process runs when a TALENT freshly installed in a new system. Upon deployment of TALENT components from the docker container, all of them register themselves automatically to the “Discovery” service. The “Discovery” service creates a table with the name of components and its status [READY, UNKNOWN]. If the status of all components changes to READY and they are correctly link together, then TALENT endpoints becomes available (API and GUI).

TALENT has two main operational phases: bootstrapping and run-time. Bootstrapping consist of setting up the TALENT system to be ready for the proper operation over and infrastructure. It is a one-time process (every time the system starts from the fresh). The MANO Selector Plugin and Domain Component Plugin as loaded with proper inputs for the supported MANO and satellite solutions. These inputs later on will be used at the run-time phase. Run-time phase is responsible for execution of operational commands coming from different stakeholders. In principle, TALENT supports two categories of operational commands.

Network service-related commands: these are commands for lifecycle management of end-to-end connectivity and computational resources. TALENT ease the provisioning and termination of end-to-end services over satellite and terrestrial resources,

5G application-related commands: over the provision network services, TALENT is able to run and manage different 5G application.

3.5.1 Virtualised Services Descriptor Files through TALENT As illustrated in Figure 12, user trigger the operation by browsing to the bootstrapping page to define new project for provisioning network service on satellite and cloud/edge domains. For this, user must provide information such vendor (e.g. OSM for cloud part and Gilat for satellite side) and API information (e.g. IP address and port number) of MANO Cloud Manager and Satellite Domain Manager to the system. Once the project is created, the bootstrapping phase is over.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

The first step on the run-time phase is to upload TALENT’s package, which includes TALENT index file, Networks Service Descriptors (NSDs), Virtual Network Function Descriptors (VNFDs) and satellite configuration file. TALENT performs a set of action on the uploaded package based on the package definition as follows:

1. Open received TALENT package file to analyse and categorize the information; 2. Check if the index file is included; 3. Parsing the index file to check which files are included in the package (cloud and satellite

domains); 4. Retrieve Network Service (NS) and Virtual Network Function (VNFs) information, together with

the satellite elements; 5. Verify if the indicated descriptors are found in the TALENT package file.

Following that, TALENT onboards the descriptor files to the OSM via northbound API, then a request corresponding to the MANO is forward to the OSM and another request corresponding to the satellite domain forward to the TotalNMS (see Section 5.5.1), which start the service instantiation process. In the generic way, the MANO fetch the NSD, including VNFD from its catalogue, considering that the descriptor was already available in the catalogue and it sends the request to the VIM to deploy the new NS instances. Once the operation is complete from the VIM side, the MANO receives a confirmation message and it sends a reply to the operation module, which will forward the message to TALENT.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 12 TALENT GUI; satellite and terrestrial project creation, package onboarding and service instantiation.

Figure 13: OSM service orchestrator version five dashboard view as a result of the instantiation commands from TALENT

SaT5G (761413) D5.2/D5.4 March 2020

of 108

4 Aero Test Bed Based on Over-The-Air MEO Satellite

Connectivity

The geographical distribution of the ZII test bed for demonstrating aircraft backhaul connectivity in the MEO orbit with O3b satellites is shown in Figure 14. As anticipated in Section 1, the two main locations are the ZII office in Wessling (Germany) and the O3b teleport of SES in Sintra (Portugal). The two sites are connected over the O3b space segment and, on ground whereby the Layer 2 connection with an intermediate switching point at the SES office in Munich Unterföhring (Germany). With respect to the map illustrated above, the key sites of interest are:

A) O3b GW Teleport at Sintra, Portugal

B) O3b Ka-band MEO HTS Space Segment

C) SES MX1 PoP at Munich, Germany (Munich (MUN))

D) ZII Premises: Location of O3b Remote User Terminal at Wessling, Germany

Figure 14: Geographical distribution of the ZII 5G test bed for MEO demonstration

4.1 MEO Test Bed System Architecture The specific implementation of the ZII test bed components for demonstrating satellite – terrestrial integration in 5G is shown in Figure 15 (see next page). The satellite backhaul in the MEO orbit with SES O3b satellites is used to connect the Aircraft Network and the ZII DC. As mentioned, the space segment connects the cabin mock-up aircraft with the ground passing through the O3b teleport, the SES Point of Presence (PoP) in Munich until the ZII Ground DC. The backhaul service is an end-to-end Layer 2 connection without any network router in between. As shown in the figure, the terrestrial connection is divided in the segment between the SES teleport and the SES PoP, which is implemented over the SES backbone access network, and the segment between the SES PoP and the ZII office

SaT5G (761413) D5.2/D5.4 March 2020

of 108

which fell under the responsibility of ZII that for the purpose purchased a leased line from Deutschland Telekom.

Referring to Figure 15, the O3b satellite handover occurs every 24 minutes so that while one O3b satellite is setting another one is rising. In such a scenario, satellite handover is crucial to ensure continuity of the communications without disruption, which is also referred to as break-before-make satellite handoff. The specific the test bed installation in Wessling consists of:

The Aircraft Network made of Intel NUCs, Raspberry PI and network switch;

The Ground Datacentre with Fujitsu Primergy rack servers;

The NFVI that spans across the Aircraft Network and the ZII DC to deploy the BPK content delivery service and the 5G mobile core;

The OSS TALENT and the MANO layers OSM version five and Openstack Queens;

The dual antenna system, 1.2m AvL technology;

The MEO Booster equipment supplied by Gilat;

The Gilat GLT-1000 modem with linked management laptop and network switch;

The radio access network installed in the mock-up aircraft with one eNB small cell backhauled through the O3b satellite and one eNB small cell backhauled through standard Ethernet based terrestrial network;

The PEDs of passengers that include OnePlus 5T smartphones and Samsung Galaxy tablets for the UEs.

On the other hand, the Sintra installation includes the following components:

Use of the O3b satellite teleport ;

The MEO Booster supplied by SES;

The Gilat GLT-1000 modem with connected management laptop;

The Gilat network switch;

The BPK server with the BkE200 transcaster on it to deliver multicast transmissions to the Aircraft Network(s).

The sections that follow are devoted to presenting in detail the ZII test bed put in place to carry out the trials within the satellite – terrestrial integration in 5G with focus on aircraft connectivity and backhaul connectivity in the MEO orbit.

Figure 15: ZII test bed system architecture for MEO orbit demonstrations with O3b satellite segment

4.2 MEO Test Bed Network Architecture Figure 15 depicts the ZII test bed system architecture for demonstrating backhaul connection between the Aircraft Network and the ZII DC whereby the O3b satellite system. Referring to this figure, we may notice that in the receive direction the Radio Frequency (RF) signal from the two antennas passed through the MEO Booster equipment which handled changing doppler and delay effects and provided a combined RF signal to the GLT-1000 modem. In the transmit direction instead the RF signal passed through a splitter and was then connected to the two Block Up Converters (BUCs). Moreover, the

SaT5G (761413) D5.2/D5.4 March 2020

of 108

management laptop at each site was used to store the System Data Broadcast (SDB) files for the MEO Booster at the local site. The MEO Booster accessed the files via FTP, the laptop acted as the FTP server for the MEO Booster. In addition, the laptop in ZII premises at Wessling acted as the NTP server for both MEO Boosters, providing each with the same clock.

SaT5G MEO Testbed – Satellite Network Diagram

L2 Dedicated Connection

TO/FROM: 5G UE

GLT Modem-2

Switch

TO/FROM: 5G Core

Control/Management

Data Path To/From eNB

Data Path To/From EPC

Satellite Link

MEO Booster-2 ZII Test Bed Munich

Talent

Openstack Controller

eNB

EPC

Management Laptop

WESSLINGSINTRA

GLT Modem-1

MEO Booster-1

Management Laptop

Switch

Switch

Splitter

RF Receive Direction

RF Transmit Direction

Splitter

MEO SATELLITE

BPK200/Transcaster

Figure 16: ZII test bed for MEO orbit connectivity over O3b constellation

4.3 O3b Space Segment For the over-the-air demo, SES brought in its O3b Medium Earth Orbit (MEO) space segment.

The O3b constellation delivers fibre-like performance and has massive geographic reach, enabling the delivery of high-performance data networks and solutions – including cloud services and applications – across the globe.

Positioned at altitude of 8,062 km away from the Earth, the O3b MEO satellites are approximately ¼ of the distance from the Earth than traditional geostationary (GEO) satellites. The Ka-band MEO HTS constellation enables SES to continue the drive towards digital equality and generate social and economic development by delivering high performance communications anywhere, even in the most remote areas. Currently, SES owns and operates 20 in-orbit O3b MEO HTS satellites each providing 10 user beams up to 1.2 Gbps of throughput (600Mbps up and 600Mbps down). By scaling the O3b MEO constellation efficiently, SES will be able to offer more capacity, enhanced coverage, increased efficiencies and greater flexibility. The next generation O3b MEO HTS constellation, termed “O3b mPOWER”, will launch in 2021 with start of service in 2022. O3b mPOWER will increase both throughput and flexibility by providing more beams at higher throughputs able to connect to more users.

An overview of the O3b MEO HTS system is illustrated below (see Figure 17 and Figure 18):

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 17: O3b System Overview

Figure 18: O3b MEO HTS Constellation Showing Customer and Gateway Spot Beams

The O3b MEO constellation delivers low-latency broadband to any area within 50° north or south of the equator (see Figure 19). O3b “fibre-equivalent” connectivity enables the delivery of carrier-grade, cloud-ready services, including MEF Carrier Ethernet certified services. This enables mobile network operators (MNOs), fixed-line service providers, and enterprises to expand their footprint into regions that are difficult or impossible to serve via terrestrial networks. For government and mobility customers, the O3b MEO constellation meets the growing demand for broadband connectivity to power high-capacity, low-latency applications.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 19: SES Network Map

O3b satellites orbit the earth on the equatorial plane (0 degrees latitude). It takes 6 hours for an O3b satellite to orbit the earth, taking into account the rotation of the Earth (1/15th deg Lon/min). The active satellites are evenly spaced around 360 degrees. Customer traffic must be seamlessly handed over from one satellite to another, without interruption. Multiple customers share a common RF path through the Satellite Payload thus follow the same schedule. Any given satellite is responsible for providing coverage to a given customer for about 30 minutes. The overlap between adjacent satellites to perform handover lasts 30 seconds.

A satellite will be overhead in each region for about 30 min, after which it moves on to the next region in the East. Meanwhile, the next satellite in the constellation rises in the West to take its place in the region. Maintaining a seamless communications link requires a handover from the setting satellite to the next rising satellite. The handover from one satellite to the next in each region cannot take place instantaneously and the handover in the next region cannot take place until the handover in the previous region has completed and the satellite antennas have moved to point at the gateway and customer locations in the new region. The system allows for a small amount of overlap time, the “handover interval”, to accomplish this.

Each O3b satellite has 10 user spot beams with five beams in each subregion. A spot beam has a diameter of about 700 km and corresponds to a transponder (channel) which is 216 MHz in bandwidth. The transmissions are circularly polarized with the beams in one subregion being on the opposite polarity as the beams in the other subregion. In contrast to most GEO Ka-band satellites where the uplink and downlink are opposite in polarity, the O3b satellites use the same polarity for uplink and downlink. Each beam is steerable since it has to be focused on the same area of the Earth while the satellite is moving with respect to the Earth.

In particular, for the referred over-the-air demo, SES brought in its O3b MEO HTS space segment to provide connectivity between the O3b GW teleport at Sintra, Portugal (see Section 4.4 below) and the O3b Remote User Terminal located at Wessling, Germany (see Section 4.5 below).

Details on the O3b beam allocated for the referred over-the-air demo are as follows:

O3b Beam: 622 (Channel 2), Subregion 6b, out of Sintra GW;

Period: 11 November – 15 December 2019.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

For the given Gilat GLT-1000 modems employed in the referred over-the-air demo, which supports symbol rates of up to 30 MSps, 36 MHz bandwidth was allocated in the FWD link (from Sintra GW to AvL terminal in Wessling) and 36 MHz bandwidth was allocated in the RTN link (from AvL terminal in Wessling to Sintra GW). In this context, the Committed Information Rate (CIR) under clear-sky conditions for the given MODCOD and given locations was:

CIR Data Rate (Clear-Sky): o FWD Link: 59.41 Mbps (8PSK 2/3, 30 Mbps); o RTN Link: 49.50 Mbps (QPSK 5/6, 30 Mbps).

Further details for the actual demo setup are provided in the Line-Up forms below (see Figure 20 and Figure 21).

Figure 20: Line-Up Form - FWD Link: From Sintra to Wessling

Prepared by:

Peer Review:

Satellite & Carrier Characteristics

1. Satellite Characteristics 2. Carrier Parameters

1a. Satellite Name O3b C1 2a. Link Direction FWD

1b. Number of spacecraft 15 2b. Symbol Rate [Msps] 30.0

1c. Center of Subregion [deg] 9.50 E 2c. Rolloff Factor/Spacing Factor 0.20

1d. Subregion R06B 2d. Required Bandwidth [MHz] 36.00

1e. Uplink/Downlink Beam GW2-L/TELCO-R 2e. Required Power Equivalent BW (PEB) [MHz] 36.01

1f. Transponder Id R06-GW2/TL22 2f. Carrier Modem Technology GLT-1000

1g. Transponder Mode ALC 2g. CIR Modulation Scheme 8PSK

1h. Transponder OBO [dB] -3.80 2h. CIR Inner Code Rate 2/3

1i. Transponder S.F.D. [dBW/m2] N.A. 2i. CIR Data Rate clear sky [Mbps] 59.41

1j. ULK Beam Polarization L 2j. MIR Modulation Scheme 8PSK

1k. DLK Beam Polarization R 2k. MIR Inner Code Rate 5/6

1l. Transponder Operating Point Multi Carrier LD>>CXR_XPDR_IS_SINGLE_CXR2l. MIR Data Rate clear sky [Mbps] 74.26

1m. Transponder HPA C/Im [dB] 200.0000 2m. MIR EsN0 [dB] 10.4

Terminal Characteristics

3. Transmitting Terminal Tx 4. Receiving Terminal Rx

3a. Location Name SINTRA/Portugal 4a. Location Name Wessling/Germany

3b. Terminal Id (Name/Number) SIN_LH/SIN_LH 4b. Terminal Id (Name/Number) UND_AVL_007_03

3c. Uplink RF Frequency [GHz] 27.9480000 4c. Downlink RF Frequency [GHz] 18.1480000

3d. Uplink IF Frequency [MHz] 1298.0000 4d. Downlink IF Frequency [MHz] 1348.0000

3e. Latitude [deg] 38.72 N 4e. Latitude [deg] 48.08 N

3f. Longitude [deg] 9.13 W 4f. Longitude [deg] 11.27 E

3g. Elevation Angle [deg] 24.1 4g. Elevation Angle [deg] 17.2

3h. Tx Dish Size [m] 7.30 4h. Rx Dish Size [m] 1.20

3i. Uplink Tx EIRP@ Tx [dBW] 72.3 4i. G/T of Rx [dB/K] 22.0

3j. Satellite Footprint G/T @ Tx [dB/K] 5.8 4j. Satellite Footprint EIRP @ Rx [dBW] 49.0

3k: Beam pointing Latitude [deg] 38.72 N 4k: Beam pointing Latitude [deg] 49.50 N

3l: Beam pointing Longitude [deg] 9.13 W 4l: Beam pointing Longitude [deg] 13.00 E

3m: Distance to beam centre [km] 0.0 4m: Distance to beam centre [km] 202.6

3n. Frequency Converter ID Gateway Stnd Up 4N. Frequency Converter ID Low Down

3o. HPA Power [dBW] 27.0

3p. HPA OBO Limit [dB] -4.0

3q. Dynamic Range [dB] 9.0

3r. Output Backoff [dB] -11.6

SLA Characteristics8. SLA characteristics

8a. Customer Name

8b. Start Date (Month/Day/Year) 11/15/2019

8c. End Date (Month/Day/Year) 12/15/2019

8d. CIR Data Rate [Mbps]

8e. MIR Data Rate [Mbps]

8f. Network Uptime [%] N/A

Carrier Plot

User Terminal Elevation Profile

UND_AVL_007_03_FWD

Line Up Form: SINTRA/Portugal - Wessling/Germany

15

16

16

16

16

16

17

17

17

17

17

0 5 10 15 20 25 30

1 User Terminal Elevation Profile

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 21: Line-Up Form - RTN Link: From Wessling to Sintra

Note that in the original demo setup, 120 MHz bandwidth was allocated in the FWD link (QPSK 3/4, 100 MSps) and 48 MHz bandwidth was allocated in the RTN link (QPSK 5/6, 40 MSps), which resulted in CIR Data Rate (Clear-Sky) of 148.51 Mbps and 66.01 Mbps for FWD and RTN links, respectively. However, as these data rates could not be supported by the given Gilat GLT-1000 modems employed in the referred over-the-air demo (supporting symbol rates of up to 30 MSps), the bandwidths allocated in the FWD and RTN links had to be re-visited in the actual demo solution deployed.

Moreover, note that another limitation to the data rate in the actual demo solution deployed corresponds to the Layer 2 VPN link between SES MX1 PoP at Munich, Germany (Munich (MUN)) and the O3b Remote User Terminal Location at Wessling, Germany (see Section 4.7.2 below). In fact, due to budget constraints, the DT VPN option of 50 Mbps bandwidth in each direction was procured by ZII for a one-year duration for this link. Thus, even though higher data rates could be accommodated over the space segment, there would be a bottleneck of 50 Mbps in the terrestrial backbone network. Further details on the Layer 2 VPN link connectivity are provided in Section 4.7 below.

4.4 O3b Gateway Teleport Each of the O3b service regions is anchored by a gateway that provides connections to the terrestrial fibre infrastructure. The two gateway beams on each satellite can be independently pointed to two different gateway locations within the service area for greater flexibility. Each of the service regions is split into two subregions which are slightly offset from each other in space and in handover time so as to allow for higher elevation angles through the pass. The gateway provides the anchor point in the region for initiating handover of all of the customer terminals in the subregion from one satellite (the descending satellite) to the next (the ascending satellite).

O3b gateways are spread across the globe to service specific regions. The specific location is mainly driven by rainfall averages, internet connectivity and regulatory reasons. Each O3b gateway site has three or four 7.3m tracking antennas and associated modems and RF electronics.

Prepared by:

Peer Review:

Satellite & Carrier Characteristics

1. Satellite Characteristics 2. Carrier Parameters

1a. Satellite Name O3b C1 2a. Link Direction RTN

1b. Number of spacecraft 15 2b. Symbol Rate [Msps] 30.0

1c. Center of Subregion [deg] 9.50 E 2c. Rolloff Factor/Spacing Factor 0.20

1d. Subregion R06B 2d. Required Bandwidth [MHz] 36.00

1e. Uplink/Downlink Beam TELCO-R/GW2-L 2e. Required Power Equivalent BW (PEB) [MHz] 36.01

1f. Transponder Id R06-TL22/GW2 2f. Carrier Modem Technology GLT-1000

1g. Transponder Mode FGM 2g. CIR Modulation Scheme QPSK

1h. Transponder OBO [dB] -12.80 2h. CIR Inner Code Rate 5/6

1i. Transponder S.F.D. [dBW/m2] -70.10 2i. CIR Data Rate clear sky [Mbps] 49.50

1j. ULK Beam Polarization R 2j. MIR Modulation Scheme 8PSK

1k. DLK Beam Polarization L 2k. MIR Inner Code Rate 5/6

1l. Transponder Operating Point Multi Carrier LD>>CXR_XPDR_IS_SINGLE_CXR2l. MIR Data Rate clear sky [Mbps] 74.26

1m. Transponder HPA C/Im [dB] 25.0009 2m. MIR EsN0 [dB] 10.4

Terminal Characteristics

3. Transmitting Terminal Tx 4. Receiving Terminal Rx

3a. Location Name Wessling/Germany 4a. Location Name SINTRA/Portugal

3b. Terminal Id (Name/Number) UND_AVL_007_03 4b. Terminal Id (Name/Number) SIN_LH / SIN_LH

3c. Uplink RF Frequency [GHz] 28.1240000 4c. Downlink RF Frequency [GHz] 18.3240000

3d. Uplink IF Frequency [MHz] 1524.0000 4d. Downlink IF Frequency [MHz] 1474.0000

3e. Latitude [deg] 48.08 N 4e. Latitude [deg] 38.72 N

3f. Longitude [deg] 11.27 E 4f. Longitude [deg] 9.13 W

3g. Elevation Angle [deg] 17.2 4g. Elevation Angle [deg] 24.1

3h. Tx Dish Size [m] 1.20 4h. Rx Dish Size [m] 7.30

3i. Uplink Tx EIRP@ Tx [dBW] 58.9 4i. G/T of Rx [dB/K] 39.8

3j. Satellite Footprint G/T @ Tx [dB/K] 5.6 4j. Satellite Footprint EIRP @ Rx [dBW] 48.8

3k: Beam pointing Latitude [deg] 49.50 N 4k: Beam pointing Latitude [deg] 38.72 N

3l: Beam pointing Longitude [deg] 13.00 E 4l: Beam pointing Longitude [deg] 9.13 W

3m: Distance to beam centre [km] 202.6 4m: Distance to beam centre [km] 0.0

3n. Frequency Converter ID Low Up 4N. Frequency Converter ID Gateway Stbd Dn

3o. HPA Power [dBW] 13.0

3p. HPA OBO Limit [dB] -2.0

3q. Dynamic Range [dB] 0.0

3r. Output Backoff [dB] -20.6

SLA Characteristics8. SLA characteristics

8a. Customer Name

8b. Start Date (Month/Day/Year) 11/15/2019

8c. End Date (Month/Day/Year) 12/15/2019

8d. CIR Data Rate [Mbps]

8e. MIR Data Rate [Mbps]

8f. Network Uptime [%] 99.841%

Carrier Plot

User Terminal Elevation Profile

UND_AVL_007_03_RTN

Line Up Form: Wessling/Germany - SINTRA/Portugal

15

16

16

16

16

16

17

17

17

17

17

0 5 10 15 20 25 30

1 User Terminal Elevation Profile

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 22: O3b Gateway Site

For the referred over-the-air demo, the O3b gateway located at Sintra, Portugal was employed which controls the given O3b beam allocated for this demo (O3b Beam: 622 (Channel 2), Subregion 6b).

At the O3b GW Teleport at Sintra, Portugal, SES provided hosting of the SaT5G ZII testbed equipment, which was installed and integrated with the O3b Ka-band RF Uplink through the L-band Matrix Switch for the period of November 2019 – December 2019. The standard COTS modem equipment offered with O3b services in the RF shelter were replaced by the Gilat GLT-1000 modem and MEO Booster for this demo. In particular, Table 2 below provides the SaT5G ZII testbed equipment installed at O3b GW teleport at Sintra, Portugal:

Table 2: SaT5G ZII Testbed Equipment Installed at O3b GW Teleport at Sintra, Portugal

Equipment Installation By

Remark

1x Attenuator SES To allow SES service monitoring capability, an attenuator

was added to the GLT modem so that the output dB of the

modem is not exceeded

1x GLT-1000 Modem

Gilat CCM mode operation

Note that this modem is different from the standard COTS

modem equipment offered with O3b services

1x MEO Booster

Gilat SES-owned MEO Booster loaned to Gilat for temporary

use in this demo

1x Lenovo Laptop (configured as NTP Server)

Gilat To control the MEO Booster and GLT Modem

For information security purposes, Gilat laptop had been

scanned prior to on-site installation and certificate issued to

SES certifying it has been found clean from viruses and

malware.

1x Switch Gilat 24 port Switch Cisco Catalyst 2960G Series

Connected to the SES switch in Sintra where the Layer-2

VPN link to SES Munich PoP terminated

1x miniPC BkE Server for Multicast/Push VoD

Gilat (for

Broadpeak)

Broadpeak equipment connected with the rest of the Gilat

equipment setup by plugging in through Ethernet cable to

the Switch and eventually modify one IP address

SaT5G (761413) D5.2/D5.4 March 2020

of 108

The following figure illustrates the SaT5G ZII testbed equipment above.

(a) Front Rack View

(b) Rear Rack View

Figure 23: SaT5G ZII Testbed Equipment Installed at O3b GW Teleport at Sintra, Portugal

In addition, for the referred over-the-air demo, SES set up remote access for SaT5G ZII testbed equipment installed in its O3b GW at Sintra through the Layer 2 VPN link between Sintra and Wessling. The following figure illustrates the rack unit in Sintra GW where the Layer 2 VPN Link between Sintra-Wessling was terminated and the Gilat switch was connected to the given CTN switch port. Further details on the SES network connectivity solution for the Layer 2 VPN link between Sintra and Wessling are given in Section 4.7.1.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 24: Rack unit in Sintra GW where the Gilat switch was connected

4.5 O3b Remote User Terminal The O3b customer terminals (or else referred to as O3b remote user terminals) enable a wide range of communications services for customers. In most cases, customer terminals communicate over the satellite to a common gateway site in their service region. Customer terminals can also communicate directly with each other over satellite within the same customer beam (a so-called loopback beam). Three tiers of customer terminals have been defined for the O3b system. Tier-1 terminals have 4.5 m diameter antennas with very HPAs and are capable of transmitting and receiving at gigabit speeds. These terminals typically support hundreds of thousands of end users since the statistical multiplexing gains are large with such high-bandwidth links. Tier-2 terminals have 0.8 / 1.2 / 2.4 m diameter antennas, support tens of thousands of end users, and can sustain rates of 500 Mbps or higher depending on their location within a beam, the elevation angle, and weather conditions. Tier-3 terminals have diameters of 2.2 m and smaller and are capable of hundreds of Megabits of throughput and are intended for sites with fewer users (thousands of users or less).

The capabilities of a customer terminal depend on the size of the antenna, wattage of the power amplifier, and the type of modem deployed. Many of the large sites are configured for point-to-point links and the modems are configured for the classical single channel per carrier (SCPC) mode of operation. On the other hand, if there are multiple sites for a customer in a beam, then a common configuration is to use point-to-multipoint (PMP) connectivity in the gateway to terminal direction (forward direction) and point-to-point SCPC mode for the reverse direction. The PMP configuration allows the customer sites in a beam to share the available bandwidth, burst instantaneously to the maximum bandwidth, and provides statistical multiplexing gains. In the return direction, SCPC mode is preferred for sites with a lot of users. For sites with fewer users, time division multiple access (TDMA) can offer benefits; however, the movement of the satellites introduces a time variation in the path length and time-varying Doppler shift, both of which need to be accounted for in the TDMA burst demodulator at the hub.

Each O3b customer terminal includes both indoor equipment (such as, COTS modems, Antenna Control Unit (ACU), Antenna Interface Unit (AIU), Router, etc) and outdoor equipment (such as, Tracking Antennas, Low Noise Block (LNB), Block Up-Converter (BUC), etc).

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 25: O3b Customer Terminal - Tier 2 Terminal Equipment

Figure 26: O3b Customer Tier 2 Terminal: 1.2m AvL Ka-band transportable dual-antenna terminal

For the SaT5G over-the-air demo, SES brought in a Tier-2 O3b Customer Terminal. In particular, the SES owned 1.2m AvL Ka-band transportable dual-antenna terminal was used which is designed for rapid deployment and includes dual tracking antennas with seamless MEO make-before-break handover (see Figure 26).

This 1.2m AvL Ka-band transportable dual-antenna terminal was installed at the ZII premises in Wessling, Germany. In particular, SES provided the following services related to the AvL terminal:

Site Survey at Wessling (completed on 07 October 2019);

Equipment Shipment from Luxembourg to Wessling (delivery on-site on 06 November 2019)

Installation & Commissioning at Wessling (during week 11-15 November 2019);

Tx Regulatory License from German regulatory body BNetzA (granted for period 11 November – 15 December 2019);

Dismantling at Wessling (completed on 19 December 2019);

Return Shipment from Wessling back to Luxembourg (arranged on 09 January 2020).

The SES owned 1.2m AvL Ka-band transportable dual-antenna terminal was integrated with Gilat GLT-1000 modem and MEO Booster, as well as with the rest of the 5G prototype network (i.e., ZII 5G Aircraft RAN and Virtualized 5G Data Centre residing in Wessling.

At this point, note again, that the Gilat GLT-1000 modem is different from the standard COTS modem equipment offered with O3b services. In fact, the AvL terminal was shipped to Wessling as a “standard” O3b package, incl. the standard COTS modem equipment offered with O3b services. The latter were removed from the AvL terminal indoor rack. This removal freed up space on the AvL terminal indoor rack which was used to host Gilat’s GLT-10000 modem and MEO Booster installed at Wessling for this

SaT5G (761413) D5.2/D5.4 March 2020

of 108

demo. The following figures illustrate the actual AvL terminal installation at ZII premises in Wessling, where the AvL terminal was integrated with Gilat’s GLT-1000 Modem and MEO Booster.

Figure 27: AvL terminal installation at Wessling (ZII Premises Rooftop) – Outdoor Equipment

(a) Original installation with standard COTS modem

equipment offered with O3b services

(b) Installation with Gilat’s GLT-1000 and MEO

Booster integrated

Figure 28: AvL terminal installation at Wessling (ZII Indoor Room) – Indoor Rack Equipment

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 29: AvL terminal installation at Wessling (ZII Indoor Room) – View from AvL Laptop Control Station

4.6 Satellite Ground Segment Network Equipment Figure 30 shows a block diagram of the satellite ground equipment setup at the ZII Premises in Wessling. As shown this equipment could only be accessed from remote when the satellite link was up and working.

Figure 30: Block diagram of the Satellite equipment at the remote site (Wessling)

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Table 3: Equipment for O3b connectivity deployed at the remote site (Wessling)

Equipment Management Interface

IP Address Comments

Laptop Teamviewer / UltraVNC

172.24.0.91 Acted as the FTP server for the MEO Booster so that the MEO Booster could access the SDB files.

MEO Booster Management software exe – provided configuration and monitoring

172,24.0.92 MEO Booster worked in the RF Rx path, combining 2 signals and providing a single RF connection to the modem.

Modem Web Interface 172.24.0.93 Sent/received Layer 2 ethernet traffic over the MEO satellite.

Hub/Switch None None Connected the equipment together, at the Layer-2 Ethernet level.

Figure 31 shows a block diagram of the satellite ground equipment setup at the Sintra Teleport Premises in Portugal. As shown this equipment could always be accessed from remote, via the L2 VPN, whether or not the satellite link was up and working. All equipment was configured to be in the same subnet 172.24.0.x.

Figure 31: Block diagram of the satellite equipment at the Sintra teleport

Table 4: Equipment deployed at the O3b teleport


IP Address Comments

Laptop Teamviewer / UltraVNC

172.24.0.95 Acted as the FTP server for the MEO Booster so that the MEO Booster could access the SDB files.

SaT5G (761413) D5.2/D5.4 March 2020

of 108


IP Address Comments

MEO Booster Management software exe – provided configuration and monitoring

172,24.0.96 MEO Booster worked in the RF Rx path, combining 2 signals and providing a single RF connection to the modem.

Modem Web Interface 172.24.0.97 Sent/received Layer 2 ethernet traffic over the MEO satellite.

Switch Cisco CLI Interface 172.24.0.94 Connected the equipment and the L2 VPN tunnel together, at the Layer-2 Ethernet level.

The Gilat modem used in the SaT5G O3b demo is the GLT-1000, which has not been part of the “standard” O3b product/service offering. Apart from the in-lab validation through satellite link emulator and over-the-air validation with SES O3b MEO in-orbit satellites in the SaT5G project, it had been previously successfully tested over-the-air with LEO in-orbit satellite. Its features can be summarized as follows:

Supports comms-on-the-move (COTM), point-to-point (SCPC) or point-to-multipoint (MCPC) operations;

Supports patent-pending adaptive spreading code and modulation (ASCM) waveform in MCPC mode for low SNR threshold, reduced space segment costs and increased availability.

Figure 32: Gilat GLT-1000 modem (https://www.gilat.com/technology/glt1000/)

Figure 33: Gilat GLT modem parameters and values

The following parameters were actually used in the SaT5G O3b Demo:

CCM operation in SCPC mode;

FWD: 8PSK 3/4, 30 MSps;

RTN: QPSK 2/3, 30 MSps.;

https://www.gilat.com/technology/glt1000/

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 34: EMC Satcom Technologies GmbH - MEO BoosterTM

The MEO Booster is a product designed and produced by EMC Satcom Technologies GmbH, one of O3b’s development partners. It receives the streams from both satellites and aligns the two streams so that the handover is seamless. It also reduces the number of modems required in the customer design minimising investment and reducing complexity. MEO Booster improves performance by increasing throughput, leading to a lower cost per bit for the customer and making O3b truly fibre competitive. MEO Booster in conjunction with standard O3b ground equipment enhances link efficiency, increasing link throughput by up to 50%. The use of state-of-the-art modulation techniques translates to availability improvements and world leading spectral efficiency under all conditions. Its benefits are as follows:

Seamless switching between the two signals from the two satellites at handover time;

Increase link throughput by up to 50%;

Reduce the delay variations and Doppler variations to minimal during the satellite pass from rising to setting satellite;

Single modulator/demodulator; at each end, thus minimising investment and reducing complexity

No need for the demodulator to receive ACU switchover status protocol transmission.

The SaT5G O3b demo was the first over-the-air validation using MEO Booster and this corresponds to a SaT5G major innovation.

4.6.1 MEO Booster Configurations for OTA Satellite Tests The MEO Booster is configured by various means:

1. The MEO Booster accesses its SDB files via a configured FTP server, allowing the SDB files to be updated from time to time. The MEO Booster then periodically reads these files from the FTP server;

2. The MEO Booster is synchronized to the current date and time via a configured NTP server; 3. The MEO Booster is configured and monitored by its MBMonitor exe program.

In order to achieve smooth handover or as close to smooth handover as possible, all the MEO Booster settings had to be configured carefully and fine-tuned.

1. SDB Files

The MEO Booster used the SDB files to decide when to switch between antenna but the antenna themselves were switching between the satellites with a short period of two minutes in which both the setting satellite and rising satellite were both transmitting and receiving by one of the antennas. The switchover time was in the middle of this two-minute period. It was found that for the MEO Booster, the SDB files should be identical at both sites – Sintra and Wessling. It was also found that by delaying the switchover time in the MEO Booster files by 5 seconds the best results were achieved.

2. NTP time It was found that the same NTP server needed to be used by both MEO Boosters so that they could run on the same clock time.

3. MEO Booster configurations

The key parameters that were fine tuned in the MEO Booster MBMonitor were:

a. Data Combining (DC) - On or Off b. Timing Control – Automatic or Manual c. DC Start Offset d. DC Stop Offset e. RDT Offset

See the diagram (Figure 35) below:

SaT5G (761413) D5.2/D5.4 March 2020

of 108

The best results were achieved by having slightly different configurations at Sintra (left side) and at Wessling (right side):

Figure 35: Optimal MEO Boosters configuration based on experimental evidence

4.7 Layer 2 VPN Connectivity This Layer 2 link employed for the referred over-the-air demo between the O3b GW at Sintra, Portugal and the O3b remote user terminal location at Wessling, Germany was used to carry the backbone traffic between the two sites, as well as to enable remote access capability of the SaT5G ZII testbed equipment installed in the O3b GW at Sintra. The Layer 2 connectivity solution comprises of the following two parts, which are described further hereinafter:

Layer 2 VPN Link between O3b GW at Sintra, Portugal and SES MX1 PoP at Unterföhring/Munich, Germany (Munich (MUN));

Layer 2 VPN Link between SES MX1 PoP at Unterföhring/Munich, Germany (Munich (MUN)) and O3b Remote User Terminal Location at Wessling, Germany.

4.7.1 Layer 2 VPN Link between O3b GW at Sintra, Portugal and SES MX1 PoP at Unterföhring/Munich, Germany (Munich (MUN))

For the referred over-the-air demo, SES provided the Layer-2 VPN Link between O3b GW Teleport at Sintra, Portugal and SES MX1 PoP in Unterföhring/Munich, Germany (MUN) through its terrestrial backbone access network (see Figure 19).

The requirements for such Layer 2 VPN Link are summarized as follows:

Carry backbone traffic between the two sites (Sintra and Wessling);

Remote access capability of the ZII testbed equipment installed in the O3b GW at Sintra;

Termination in a switch port;

Round-Trip-Time (RTT) ≤ 55-60ms;

Jitter-less: ≤ 10ms;

Packet loss < 10-6;

Bandwidth ≥ 100 Mbps;

Period: at least for October 2019 – December 2019.

The SES network connectivity solution employed in the the referred over-the-air demo to address these requirements is described hereinafter.

With reference to Figure 19, SES operates and manages a terrestrial backbone access network that consists of several owned and partner teleports, a comprehensive fibre-based terrestrial network and numerous points of presence. Based on secure MPLS technology, SES’ extensive fibre-based network is designed to transport content from virtually any city in the world to one of the several SES-owned teleports or numerous partner teleports via the numerous SES points of presence (PoPs). SES network is secure, redundant and reliable. Based on the SES terrestrial backbone access network, the Layer 2 VPN link between the O3b GW at Sintra, Portugal and the SES MX1 PoP at Unterföhring/Munich, Germany (Munich (MUN)) provided a connection of 1000 Mbps, Full-duplex.

At the Sintra O3b GW side, this connection was restricted to the CTN part only as it simplified the setup and met the demo requirements (see Figure 36). The Gilat switch was connected to the following CTN switch port, which is the same to the one used in the E2E tests:

o rtr-dpe01.sin TenGig0/0/3.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Note that the device rtr-dpe01.sin is installed in the following rack unit in Sintra GW (see Figure 24):

o GWSIN, Rack14, RU3 – rtr-dpe01.sin.

Figure 36: Layer 2 VPN Link between Sintra GW and Wessling: CTN Switch Port used at Sintra GW

4.7.2 Layer 2 VPN Link between SES MX1 PoP at Munich, Germany (Munich (MUN)) and O3b Remote User Terminal Location at Wessling, Germany

The Layer 2 VPN between the ZII office in Wessling and SES MX1 PoP in Munich Unterföhring was set up by ZII purchasing a dedicated leased line from Deutschland Telekom. The leasing period mandated by contract was minimum one year and relied on the EthernetConnect package, a solution offered by Deutschland Telekom. The choice to proceed in this way was matured during the planning phase of the ZII test bed during which specific requirements arose in terms of the end-to-end layer 2 service that had to be created to operate the O3b satellite backhaul in the MEO orbit between the Aircraft Network and the ZII Ground Datacentre. As already discussed previously, the requirements were in terms of guaranteed throughput, predictable packet latency and reduced jitter. To contain costs, after a traffic budget estimation, the ZII test bed partners agreed upon a leased line up to guaranteed 50 Mbit/s. The EthernetConnect settings mandated to disable the Auto Negotiation setting to 100 Mbit/s Full-duplex.

4.8 5G Mobile Core Network Virtualised Service In the demonstration of end-to-end connectivity to airplanes whereby satellite backhaul in the MEO orbit, the ZII test bed made use of the 5G mobile core network prototype shown in Figure 37. Specifically, the 5G core network was acquired by ZII during the course of the project from Fraunhofer FOKUS. The figure shows the actual architecture of the Open5GCore Release Four. As visible from the figure, the Open5GCore implements all needed functionalities (mobile core components with associated 3GPP defined interfaces) of the 5G mobile core that was defined in 3GPP Release 15. Further, the Open5GCore not only implements the components already shown in Figure 2 but it is fully virtualized, and it can be deployed either in one single VM or up to 17 VM components making sue of the Packet Forwarding Control protocol (PFCP) also defined in 3GPP Release 15 specifications.

The 5G mobile core in the Open5GCore implementation includes:

SaT5G (761413) D5.2/D5.4 March 2020

of 108

User Plane Function (UPF)

Access and Mobility Management Function (AMF)

Session Management Function (SMF)

Authentication Server Function / Unified data Management (AUSF/UDM)

Network Exposure Function (NEF)

Network Repository Function (NRF)

Policy Control Function (PCF)

In addition, the Open5GCore includes the possibility to connect emulated and real gNB cells accompanied by real and emulated 5G enabled UEs, as well as with a benchmarking tool for network performance monitoring.

Figure 37: Open5GCore system architecture [13]

The Open5GCore implementation that was used by the ZII test bed is shown in Figure 38. In this case we chose an implementation with two VMs: one Aircraft UPF and one Ground UPF with associated control plane functions that are both instantiated from the TALENT OSS layer through the OSM orchestrator in the NFVI/cloud infrastructure managed by the OpenStack VIM/Cloud Controller. Regarding this latter aspect, as already mentioned in Section 3.2, during the planning phase as well as during the development stage of the test bed, we noticed that the market of gNB was mainly limited to macro-cell installations, which is out of scope of the ZII test bed mains cope, while 5G enabled UEs started to be available only at a later stage of the project (end of 2019) from major brands. Therefore, to mitigate the risk of unavailability of gNB small cells and 5G enabled UEs we took the decision to use the Open5GCore in such a way to use the 5G user plane, while retaining backward compatibility with the 4G control plane. This approach, which is essentially similar to the 5G non-standalone implementation option allows to connect eNB small cells and off-the-shelf UEs. In addition, if in the terrestrial mobile network the non-standalone option will be the first roll out of the 5G system done by mobile operators, the possibility to retain eNB small cell radio access with features that span across 3GPP Release 13 and 14 gives still an ample and up-to-date set of features to be used in a realistic environment with existing passengers’ PEDs.

For the trials we conducted in the ZII test bed we can notice from Figure 38 that the Aircraft UPF is used by PEDs to access the cached content in the VOD catalogue (i.e. BPK content delivery service), while the Ground UPF connects the PEDs to a ground data network like the Internet. We further highlight that in the current implementation of the Opn5GCore, the association of UEs to one UPF takes place by setting the Access Point name (APN) in the UE settings. The implications from the standpoint of mobility management are discussed in Section 6.1.3.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Remark: we highlight that in the ZII test bed one small cell makes use of the over-the-air MEO satellite backhaul to reach a ground data network, whereas another small cell makes use of a typical terrestrial backhaul. This situation is crucial not only to make a comparison between the two access cases, but also to model mobility of passengers’ PEDs when they move from the ground small cell coverage to the aircraft small cell coverage.

Figure 38: 5G core deployment for illustrating user plane connectivity from an end-to-end perspective

4.9 Virtualised Content Delivery Service BPK’s role within ZII test bed was to provide the Content Delivery Service as a CDN provider, delivering video streams from the origin servers located at the head-end in the ZII office to the passengers’ PEDs located in the Aircraft cabin mock-up. BPK solution that was deployed in the ZII test bed include the components summarised in Table 5 and reviewed below:

The role of the BkS350 is to ingest the VOD assets, store them, and deliver them to the streamers and to the transcasters;

The BkS400 is the BPK system component responsible to stream in unicast the non-popular video contents to the players;

The BkE200 is responsible of streaming popular content and converting the unicast streams coming from the Origin server to multicast streams over the satellite link toward the nanoCDN;

The BkM100 is the CDN mediator and it superintends several tasks, including; o The management of the assets ingest from the CMS, o The pre-cache of the managed assets in the CDN, o The management of the VOD carrousel, o The management of the audience of the managed assets;

The nanoCDN is the agent located inside the aircraft and whose role is to convert multicast streams abck to unicast streams. The nanoCDN listens to the multicast carrousel and stores the assets on its local storage;

The BkA100 collects the session reports from the nanoCDN and computes the sessions analytics/audience of the managed assets in order to establish the VOD assets popularity.

During the project execution, we evaluated the possibility to deploy the BkE200 component directly in at the Sintra teleport to overcome the inherent limitation of the OpenStack Open Virtual Switch that is natively not designed to support multicast transmissions. Indeed, this is the approach taken by the ZII test bed to mitigate the complexity of an action such as modifying the virtual witch database that was not in scope of the test bed activities.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Remark: since the Broadpeak solution is network agnostic, the CDN configuration just presented above repeats itself regardless of the satellite orbit (MEO/GEO).

Table 5: Summary of BPK CDN components

Broadpeak components

Function Host Location

BkS350 Packager & Origin server OpenStack VM ZII DC

BkS400 Cache & Streaming server OpenStack VM ZII DC

BkE200 Unicast to Multicast: Transcaster VMWare VM Sintra teleport site

BkM100 CDN Mediator OpenStack VM ZII DC

nanoCDN Multicast to Unicast Bare-metal/ Raspberry Pi

ZII Aircraft Network

BKA100 Analytics server OpenStack VM ZII DC

Figure 39: Broadpeak virtualised content delivery service

4.10 Summary of Test bed Components In is section, we summarize the ZII test bed components, both virtualised and bare metal, that were deployed to achieve the goals of conducting O3b satellite – mobile network integration.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Table 6: List of Final Integrated Satellite/Terrestrial 5G Network Architecture Elements (Over-The-Air MEO Satellite Connectivity)

Location Element Supply Partner Description

SES O3b Teleport Site @ Sintra, Portugal

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

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

GLT-1000 modem GLT

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

Management station GLT

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

miniPC BkE200 server BPK Transcaster (unicast to multicast) for multicast traffic over MEO satellite

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: 64.407 Mbps (8PSK 3/4, 30 MSps) RTN: 37.741 Mbps (QPSK 2/3, 30 MSps)

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 aircraft

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

GLT-1000 modem GLT

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 GLT 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

SaT5G (761413) D5.2/D5.4 March 2020

of 108


Aircraft servers’ infrastructure and networking

ZII

Network infrastructure reproducing and upgrading the network and compute resources available on-board aircraft; 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

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

SaT5G (761413) D5.2/D5.4 March 2020

of 108

5 Aero Test bed Based on Emulated GEO Satellite

Connectivity

This section details the system developed by the ZII test bed with regard to end-to-end connectivity to aircraft relying on a virtualised satellite backhaul in emulated GEO orbit.

5.1 GEO Test Bed System Architecture The ZII test bed specific deployment for enabling GEO backhaul connectivity between the Aircraft Network and the Ground ZII DC is shown in Figure 40. As previously discussed, we notice the TALENT layer that acts as the system OSS triggering the action of the MANO layers (OSM and OpenStack) on the end-to-end infrastructure. We recall that the end-to-end infrastructure spans across two sites, the ZII office and the remote nodes at the Gilat office in Tel Aviv. Unlike the MEO satellite backhaul, in this case, we make use of an emulated GEO satellite backhaul and the way of connecting the two sites is whereby a Layer 3 VPN. At the premises of ZII we have the Aircraft network, the aircraft cabin mock-up with the small cell radio access and the PEDs of passengers. As in the demonstration of MEO satellite backhaul, the Aircraft network is part of the OpenStack cloud environment that make use of the emulated GEO satellite backhaul link to reach the Ground DC. While the Ground DC hosts the virtualised mobile core, the aircraft infrastructure hosts the MEC component of the core and the BPK VOD catalogue of cached content. As mentioned, for this part of the trials conducted over the ZII test bed, a 4G mobile core network with CUPS was used. Similar to the MEO satellite backhaul demonstrations, the small cell radio access is made of eNBs.

In the Gilat site in Tel Aviv, the Capricorn VSAT terminal of Gilat, the virtualised SkyEdge IIc satellite hub that is deployed under the control of TALENT and the MANO layers in Wessling and the emulated GEO satellite link are available. At the entrance of the remote node in Tel Aviv there is a dedicated relay machine, which is used for the purpose of applying IPTables rules on both incoming and outgoing packets for the purpose of forcing any communication (i.e. control and user planes) between the Aircraft network and the Ground DC to take place only whereby the Layer 3 VPN.

Remark 1: in the trials of the emulated GEO satellite backhaul link we had to face the existing limitation of the OpenStack Open Virtual Switch that does not support natively multicast sessions, as well as we could not ensure that any multicast session traversing the Layer 3 VPN could reach successfully the recipients since the VPN included a portion of the public Internet on which the ZII test bed partners did not have control to make sure that IGMP protocol was supported by all routers in between the two sites. Due to these limitations, multicast transmission of the BPK VOD could not be repeated as in the MEO case.

Remark 2: we infer that the behaviour of the content delivery service would not be altered by the presence of either GEO or MEO satellite link backhaul. Even though the GEO link introduces a latency larger than MEO, the creation of the VOD catalogue is done one time and only when a new catalogue is created, and afterward only content updates shall follow. Hence, this initial operation has not impact on the consumption of media content by the passengers.

Remark 3: in the case of aircraft connectivity that relies on the GEO satellite backhaul, since the satellite link is done in an emulation environment, we could not repeat the same set-up as in the MEO satellite backhaul in which one small cell was located on-board the aircraft and another one on the ground infrastructure. For this specific case we assume that two small cells are both located on-board the aircraft like in a large aircraft. In this set-up, passengers can move from the top to the rear of the airplane, thus changing cells.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 40: ZII test bed system architecture for an emulated GEO orbit satellite backhaul

5.2 GEO Test Bed Network Architecture As shown in Figure 41, the satellite ground equipment is based on Gilat’s SkyEdge II-c system, which is a cutting-edge satellite ground segment equipment that provides a comprehensive solution for end-to-end services powered by Gilat’s innovative technology. For reference, we discuss below the architecture of the SkyEdge II-c gateway.

Baseband and network aggregation o SkyEdge II-c baseband and Data processing Chassis – the main gateway sub-system

that acts as the access platform to the satellite network. It contains a high-performance baseband chassis with modulation and demodulation for HTS satellites and a cloud based data centre that uses generic Intel-Based server blades within an efficient cloud based data centre architecture to provide the following network functions: IP Routing, Layer-2 forwarding, and Satellite Return link BW management, QoS, TCP/HTTP acceleration etc. The SkyEdge II-c baseband hub is a modular integrated chassis-based hub system that supports one or more slices of forward and return space segments. Each space segment slice is processed via an element called Network Segment (NS) and it includes all the necessary services to support one wide outbound carrier and a wide return channel spectrum. The Network Segment Controller (NSC) manages all components of the Network Segment. The NSC was virtualized and deployed on a separate server platform set up as an OpenStack compute node that was controlled by TALENT and the Openstack controller available at the ZII premises in Wessling.

o Data & Management aggregation – the aggregation layer comprised high-speed aggregation switches that aggregates and distributes data and manages traffic to/from the SkyEdge II-c baseband system. Aggregation layer LAN switches maintain complete separation between user data traffic and SkyEdge II-c management traffic.

o SkyEdge II-c TotalNMS – central management system that manages all baseband equipment at the gateway and remote terminals. The TotalNMS provides full FCAPS capabilities (Fault, Configuration, Accounting, Performance, and Security) and includes an enhanced Northbound Interface for external OSS systems (i.e. TALENT in this case). It is a central global NMS, supporting all baseband subsystems and VSATs. The NMS enables remote configuration, monitoring and software updates of network elements.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 41: SkyEdge II-c gateway architecture

The detailed network architecture of the ZII test bed for implementing the emulated GEO satellite backhaul is shown in Figure 42. The equipment at the two different sites include:

At ZII premises in Wessling, the TALENT resource coordinator, the network service orchestrator OSM and the OpenStack controller reside, as well as the access network of small cells and UE equipment in the aircraft cabin mock-up.

At Gilat’s premises in Petach Tikva the satellite ground equipment, VSAT and Hub were situated, as well as the virtualized components of the satellite ground equipment – the vNSC and vMx managed from Wessling through the different layers managing the virtualized infrastructure.

When Layer-2 networks are connected over the satellite equipment the Juniper MX5 switch/router is deployed at the hub side to provide the necessary Layer-2 connectivity by deploying vxLAN tunnels over the emulated satellite link to the VSAT LAN ports. In the test bed, the virtualized vMx was used and deployed as 2 VMs on a COTS server rather than using the physical unit. The 2 vMx VMs were deployed in the OpenStack compute nodes controlled by the OpenStack controller setup in ZII premises in Munich, but also the deployment of the vxLAN was an action initiated from TALENT.

Any uplink traffic initiated by a passenger’s PED reaches the Layer 3 connection going through the small cell access network and the MEC component of the mobile core in case of user plane traffic (i.e. control plane traffic does not require to pass through the MEC). Before entering the VPN, IPTables rules are applied to change the IP destination address in a way that the new destination is the relay machine in Gilat office. Going through the Layer 3 VPN between the ZII and Gilat routers, the incoming packets reach the relay machine where they are decapsulated and passed from the VSAT to the hub through the emulated GEO satellite link. Afterward, new IPTables rules are applied changing the IP destination address to the one of the mobile core and thus the data traffic is passed through the Layer 3 VPN.

In the downlink direction, traffic destined to passengers PEDs traverse the mobile core in the Ground DC where IPTables rules are applied to change the destination IP address (i.e. the MEC part of the core in case of user plane traffic) to the one of the relay machine. Traffic this passes from the hub to the VSAT terminal going through the emulated GEO satellite link until reaching the relay machine where IPTables rules are again applied setting the proper destination IP address (i.e. the MEC in case of user plane traffic). Data packets are injected afterward in the Layer 3 VPN until reaching the Aicraft network and the passenger PED.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Router

Baseband + Datacenter

SaT5G GEO Testbed – Gilat and ZII Premises

Switch

172.200.1.1172.200.1.129

vMx

172.200.1.241

172.200.1.121

TO/FROM EPC: 172.24.10.y

TO/FROM: MEC - 172.24.10.x

172.18.255.241

172.18.255.243

172.18.255.249

VSAT Terminal

IP Tables – Swap Headers

TotalNMS

TO/FROM EPC: 172.24.10.y

Talent / OSM/ Open Stack Management

Data Path To/From MEC

Data Path To/From EPC

vNSC

TotalNMS-MANO

RF Path

Low Fly

Internal Control / Management

ZII Test Bed Munich

Talent

Openstack Controller

MEC

EPC

ZIIGILAT

RouterIP-SEC Tunnel

over Public Internet

172.18.255.246

172.200.1.31FTP Server

172.200.1.30FTP Client

FTP transfer Path for testing Simulated Satellite Link

Down Converter SLE

Up Converter

Figure 42: Network architecture of deployment to demonstrate GEO satellite connectivity

Table 7: List of Physical and virtualised components for GEO satellite connectivity emulation

Component IP Address Description

PC 172.200.1.30 PC used to perform FTP transfers over the satellite path. The FTP client was on this machine.

PC 172.200.1.31 PC used to perform FTP transfers over the satellite path. The FTP server was on this machine.

VSAT Capricorn Pro Modem

Low Fly Low Fly unit

Down Converter Change the L-Band RF signal to 70 MHz for the SLE

SLE Added 239 milliseconds delay to the signal

Up Converter Changed the 70 MHz signal from the SLE back to the L-Band frequency range.

Baseband and Datacenter Hub equipment

The Gilat satellite Hub equipment, converts the RF signal to/from Ethernet packets. Controls and manages the traffic from the VSAT.

vMx 172.18.255.243 Server running the Openstack Compute Node that housed the vMx software that created the L2 connection with the VSAT. The vMx is a Juniper soft switch that can be deployed on the Openstack environment, see description above.

vNSC 172.18.255.246 Server running the Openstack Compute Node that housed the vNSC software that was a key component in the hub. This component was extracted and virtualized and run on the external server. As described above, the NSC is the Network Segment Controller that manages all components of a single Network Segment or slice.

PC (Relay) 172.200.1.1 / 172.200.1.129

PC with 2 interface cards. The interface card with address 172.200.1.1 was connected directly to the router. The interface with address 172.200.1.129 was connected to the VSAT and via the satellite path, hub and vMx to a different leg of the router. This computer was setup as a relay machine to accept packets from the MEC and forward them to the EPC core through the satellite path and vice versa.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Component IP Address Description

The IP tables were used to change the headers of the packets. The IP tables were configured automatically when the MEC and EPC virtual machines came online and there IP addresses were then known.

Switch Connected the components of the testbed together. Provided isolation via vlans, such that the management network was connected over vlan 18 while the data traffic flowed over vlan 30.

Router Connected the testbed in the Gilat office to the testbed in the ZII Wessling office using an IPSec tunnel.

5.3 Layer 3 VPN The VPN put in place for demonstrating the integrated 5G system that includes both satellite and terrestrial resources while using a GEO orbit satellite backhaul operates at the Layer 3 of the OSI protocol stack. Particularly, this connection stands for a Site-to-Site Layer 3 connection between the ZII office in Wessling and the Gilat office in Tel Aviv. Specifically, the Layer 3 VPN provides encapsulation mechanisms with IP Security (IPSec) enabled to connect the company router of ZII with that in Gilat and was set up by ZII IT personnel. Since the Layer 3 connection stands for a tunnel that traverses the public Internet larger jitter and less predictable latency was observed as expected compared to the Layer 2 VPN set up that consisted in a dedicated leased line. Anyway, we shall report that on average a one-way latency of 90 ms was measure dover the Layer 3 VPN.

5.4 Satellite Ground Segment Network Equipment The following diagram shows the equipment in the rack in Gilat’s lab in Petach Tikva, Israel. At the bottom of the rack is the Hub equipment. Situated in the middle of the rack is the Capricorn Pro VSAT.

Figure 43: Rack equipment at Gilat’s office in Tel Aviv (Israel) for the Sky Edge II-c satellite hub

SaT5G (761413) D5.2/D5.4 March 2020

of 108

The following is a simplified block diagram of the GEO Testbed, showing the Data Path:

Figure 44: Block diagram of the end-to-end connectivity in the emulated GEO satellite system

The traffic between the MEC and the 4G mobile core with CUPS was forced to go over the IPSec tunnel and through the satellite path. The machine implementing the relay node (see section 5.4) replaced the headers of the packets using IP Table rules that forced the packets back to the ZII premises in Wessling.

5.5 Virtualised Satellite Service The following is a block diagram of the management path for the Virtualized Services:

Figure 45: End-to-end test bed components (virtualised and hardware) availing emulated GEO satellite connectivity

SaT5G (761413) D5.2/D5.4 March 2020

of 108

As shown in the figure above, the NSC and Mx5 were implemented as virtual network functions, running in OpenStack compute nodes controlled via the OpenStack controller setup in the ZII premises in Wessling. Details regarding the effort to create single virtualised network functions are shown below.

vMx virtualised components: The two Juniper vMx software VMs (custom version for

OpenStack) were uploaded as images on the Openstack controller. The images were deployed on the machine 172.18.255.243 using CLI commands in order to define exactly in which physical machine the images should be deployed.

vNSC virtualised function: The NSC software team provided a special software version that

could be deployed under OpenStack. This software was uploaded as an image of the OpenStack controller (i.e. NOVA project). The image had to be modified a few times in order to make it open all its interfaces automatically to the other blocks and to ensure that the software started up automatically when the vNSC was deployed by the OpenStack Controller. In addition, the vNSC had to be connected to the same NTP server as the rest of the system in order to ensure that all components used the same clock time and hence were synchronized as far as their messages were concerned.

L2 Service Creation: Talent was able to create/delete a Layer-2 service by sending an XML configuration file to the TotalNMS. The TotalNMS then gave the necessary TotalNMS NBI commands to open the Vlan service at the SkyEdge II-c Capricorn Pro VSAT and through the SkyEdge II-c Hub and VxGW. Once the L2 Service was in place, traffic was then able to flow across the simulated GEO satellite path.

5.5.1 TALENT – TotalNMS Communications As discussed already in Section 3.5, in the same way as the MANO, TALENT consumes the northbound API of TotalNMS to send the configuration file in an XML format to the ground station of satellite system (i.e. TotalNMS). The configuration file includes satellite connectivity information such as:

ServiceID: An identitifier for the particular VLAN service that is used to refer to the service for example when deleting the service.

MgID: An identifier of the group to which the VSAT is a member.

Terminal: The VSAT identifier within its group.

TerminalPort: The physical LAN port of the VSAT that is connected to the customer’s network.

BW: The amount of bandwidth that should be allocated for this VLAN.

CVlanID: The C-Vlan Identifier.

SVlanID: The S-Vlan Identifier.

vxgwID: The identifier of the vMx associated with this service.

With this information, TALENT can set up vLAN and complete the provisioning of satellite connectivity from the ground to the airplane cabin mock-up. Once the configuration applied, the TotalNMS sends a verification response with 200 to the TALENT lyer. Apart from that, TALENT can terminate the satellite service and remove the satellite connection sending the proper command to the TotalNMS.

5.6 Virtualised Mobile Core Network Service The architecture of the test bed, as detailed in Section 3, represents two segments of the Mobile Core Network. It comprises of ground-based section hosting Core Network (CN) and Inflight segment hosting Edge Solution (MEC). The CN and MEC connect over satellite link- which is either MEO or GEO as described in other sections.

Any inflight UE connects to a small cell (i.e. eNB in this case) hosted in the onboard inflight segment. The signalling traffic is carried over the satellite link to the ground segment where the UE is authorised and authenticated. Post this for all the user plane connections, it is directed to the on board inflight MEC. The MEC acts as a first point for all data connections. MEC has break-out configured to enable connections to the nanoCDN server that hosts the onboard flight catalogue supplied by BPK, as described in other sections of this document.

Mobile core and MEC are started from TALENT as described earlier, as part of the single satellite – terrestrial resource coordination mechanism. The orchestration follows a pre-determined sequence of

SaT5G (761413) D5.2/D5.4 March 2020

of 108

spinning up the system, each subsystem at a time – Satellite subsystem, Mobile network subsystem, the CDN subsystem etc.

The mobile network subsystem instantiating includes bringing up both Core Network segment and MEC segment and enabling them to configure themselves and then advertising the service status.

Once the mobile network subsystem is up and running, the small cell radio access and subsequently UEs can be allowed to make connection with the mobile network on-board the aircraft cabin mock-up in ZII office in Wessling.

Call flow of a typical UE trying to access data from internet and inflight content through the MEC component of the mobile core is shown in Figure 46.

Figure 46: MEC-Core workflow for internet and local cached content access for a UE

5.7 Summary of Test bed Components In the Table 8 below, we report the overall virtualised and bare metal ZII test bed components that were used for demonstrating the SaT5G UC4 that avails GEO satellite backhaul.

Table 8 : List of final integrated satellite/terrestrial 5G network architecture elements (emulated GEO satellite connectivity)


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

SaT5G (761413) D5.2/D5.4 March 2020

of 108


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 aircraft; 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

SaT5G (761413) D5.2/D5.4 March 2020

of 108


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) D5.2/D5.4 March 2020

of 108

6 Description of Demos

This section is devoted to present the trials activity undertaken over the ZII test bed both for the MEO and GEO satellite backhaul connections. The related measured KPIs are captured in Section 7 of this document.

6.1 Aircraft Connectivity Based on MEO OTA Satellite Backhaul

The general set-up for demonstrating the satellite backhaul in the MEO orbit in 5G is recalled in Figure 47. The figure also highlights that the satellite handover took place every 24 minutes.

Figure 47: Complete ZII test bed infrastructure for demonstrating MEO satellite backhaul

6.1.1 MEO OTA Satellite System Set-Up, Validation and Test Cases The set-up of the MEO OTA satellite connectivity was achieved passing through the following phases:

Phase 1 – O3bTeleport (Sintra):

1. The equipment was first setup at the Sintra teleport. 2. Initially. the transmission was initially switched off. 3. Then the transmission level was set to the minimum -40 dB and the transmission was set on. 4. The Tx Power level was slowly raised while the satellite receive signal was monitored by the

satellite technicians. 5. The level of transmission was finally set at -29 dBm. 6. The transmission was set off again until the equipment was setup at the remote site in Wessling,

Phase 2 – ZII Premises (Wessling)

1. The equipment was setup with transmission switched off. 2. Initially only one of the antennas had locked onto the satellite. 3. Using the remote access via the L2 VPN link from Wessling to the Sintra the Tx Power was

switched on in Sintra. 4. The MEO Booster and modem received the Rx signal. 5. the transmission level was set to the minimum -40 dB and the transmission was set on. 6. The Tx Power level was slowly raised while the satellite receive signal was monitored by the

satellite technicians. 7. The level of transmission was finally set at -10 dBm.

Phase 3 - Validation of Physical link Connectivity

SaT5G (761413) D5.2/D5.4 March 2020

of 108

The physical link was validated in the following 2 ways:

1. The satellite technician reported that the satellite reception was at the correct levels. 2. The modem monitoring information showed the physical layer was up and running.

Phase 4 - Validation of Data Link Layer Connectivity

Once the physical layer was up and running, the laptop and Wessling was used to ping the equipment at Sintra. Initially, the data layer information of the two modems had to be adjusted in order to make the connection working. Configuration at Wessling was adjusted on the local modem via the connected laptop using the Web user interface. Configuration of the Sintra modem was performed by connecting at Wessling another laptop to the Sintra modem via the L2 VPN tunnel and using the web user interface of the modem.

The following two screenshots shows the monitoring information of the modem at Wessling:

Figure 48: Screen capture of the Gilat modem at the aircraft (remote) location in the ZII office, Wessling

The following two screen shots shows the monitoring information of the modem at Sintra

Figure 49: Screen capture of the Gilat modem at the O3b teleport (central) location in Sintra

SaT5G (761413) D5.2/D5.4 March 2020

of 108

The following shows the MEO Booster settings for which the handover was perfect with no ping loss.

Figure 50: MEO Booster settings

Table 9 shows the test cases for the backhaul based on the satellite link in the MEO orbit, which are conducted over the satellite link excluding the Layer 2 VPN, but that are also replicated to include in the measurements the effect of the VPN connection.

Table 9: Test cases for MEO satellite

Test Case Test Description Method of verification

#1 Satellite Throughput OB direction – Sintra to Wessling / ZII DC to Aircraft network

Measure the satellite throughput in the OB direction.

Modem Monitoring Graph and statistic values

Satellite Throughput IB direction – Wessling to Sintra / Aircraft Network to ZII DC

Check the satellite throughput in the IB direction.


#2 Satellite SNR OB direction –Sintra to Wessling

Measure and record the satellite SNR in the OB direction.


Satellite SNR IB direction – Wessling to Sintra

Measure and record the satellite SNR in the IB direction.


#3 Satellite Link Delay OB direction – Sintra to Wessling

Measure the satellite link delay in the OB direction.

Ping and iperf

Satellite Link Delay IB direction – Wessling to Sintra

Measure the satellite link delay in the IB direction.

Ping and iperf

#4 Satellite Link Jitter OB direction – Sintra to Wessling

Measure the satellite link jitter in the OB direction.

iperf

Satellite Link Jitter IB direction – Wessling to Sintra

Measure the satellite link jitter in the IB direction.

iperf

6.1.2 Content Loading on Aircraft with Multicast Traffic over Satellite The diagram in Figure 51shows the workflow of content loading on aircraft with multicast traffic over the Satellite backhaul. In particular, the workflow comprises the following steps:

1) The Service Provider controls and then updates the CDN Mediator (BkM100) with new assets.

2) The new assets are ingested and stored inside the origin server (BkS350).

SaT5G (761413) D5.2/D5.4 March 2020

of 108

3) The CDN Mediator generates also a file that lists all the assets. This list is sorted by audience and added in the carrousel. The CDN Mediator sends the carrousel to the Multicast Transcaster (BkE200).

4) The nanoCDN listens to the multicast carrousel and uses the list sorted by initial popularity and audience to know which assets must be deleted from the local cache and which ones must be stored according to the local cache size.

5) At the end of each session, the nanoCDN sends the session statistics to the analytics server.

Figure 51: Block diagram of the content delivery based on the BPK system components

6.1.3 Passengers’ Mobility Measurements with MEO Satellite Backhaul Figure 52 shows the sequence chart for passengers’ mobility when UE connectivity to the small cell access network is based on APN association relying on the Open5GCore and the link backhaul is based on MEO orbit satellite. As discussed in Section 4.8, a UE can communicate to a data network relying on selecting the proper APN (typically a manual operation). We remark that this option is a specific constraint arising from the current Open5GCore implementation. However, in this context, a UE that selects a specific APN will be able to communicate only through the serving UPF even though the serving small cell access is linked to another UPF. Access to the external Internet takes place through the linked Internet Gateway (IGW). In the example described in Figure 52, APN Default is associated to the UPF on the aircraft, while APN Internet is used for the Ground UPF

In the specific set-up of Figure 52 a UE (i.e. passenger’s PED) is located on ground and connected to the ground small cell (G-Small Cell) access network and can communicate to an external network by means of the Ground UPF. Since the passenger is about to enter the aircraft cabin, the APN was selected to be the APN Default, which implies communicating through the Aircraft UPF. Since the Ground UPF and the Aircraft are placed on different backhauls the sequence 1 – 6 is motivated only until the PED is on ground:

Uplink request UE –> G-Small Cell -> Ground UPF – Aircraft UPF; Aircraft UPF -> ground UPF -> G-IGW.

The reverse direction prescribes that G-IWG -> Ground UPF -> Aircraft UPF; Aircraft UPF –> Ground UPF -> G-Small Cell -> UE.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

In this context, we shall assess the continuity of the data session resorting to tools such as the ping utility, measure throughput or iperf.

Figure 52: Flowchart for mobility management in the Open5GCore with APN-based UE association

6.2 Aircraft Connectivity Based on Emulated GEO Satellite Backhaul

In this section, we provide description of test cases carried out in the ZII test bed for conducting the trials in the emulated GEO satellite backhaul.

6.2.1 Emulated GEO Satellite System Set-Up, Validation and Test Cases In this section we review the test cases for the trials conducted with the GEO satellite backhaul.

Table 10: Test cases for GEO satellite

Test Case Test Description Method of verification

#5 Satellite Throughput OB direction – Hub to VSAT/ ZII DC to Aircraft network

Measure the satellite throughput in the OB direction.


Satellite Throughput IB direction – VSAT to Hub/ Aircraft Network to ZII DC

Check the satellite throughput in the IB direction.


#6 Satellite SNR OB direction – Hub to VSAT

Measure and record the satellite SNR in the OB direction.


Satellite SNR IB direction – VSAT to Hub

Measure and record the satellite SNR in the IB direction.


#7 Satellite Link Delay OB direction – Hub to VSAT/ ZII DC to Aircraft network

Measure the satellite link delay in the OB direction.

Ping and iperf

Satellite Link Delay IB direction – VSAT to Hub/ Aircraft Network to ZII DC

Measure the satellite link delay in the IB direction.

Ping and iperf

#8 End to End Link Jitter OB direction – DC to Aircraft network

Measure the end to end link jitter in the OB direction.

iperf

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Satellite Link Jitter IB direction – Aircraft Network to ZII DC

Measure the end to end link jitter in the IB direction.

iperf

6.2.2 Passengers’ Mobility measurements with GEO Satellite Backhaul Passengers’ mobility is managed over the GEO satellite backhaul considering the 4G mobile core with CUPS (i.e. split between MEC component and main core component) when two small cells are assumed deployed on-board an aircraft, and both use the satellite backhaul. In this case, we investigate an X2 (Xn in case of a gNB) type of handover and we shall assess the continuity of the data session resorting to tools such as the ping utility.

6.3 Passengers’ Traffic Measurements In this section we provide the test cases that were executed over the ZII test bed including both the over-the-air MEO satellite backhaul and the Geo satellite backhaul. We consider indeed that traffic measurements for passengers on-board an aircraft will try to access the same type of services since they are oblivious to the specific backhaul technology used.

Table 11: Test cases for the mobile network control/user plane

Test Case Test Description

Method of verification

#9 Comparison of 4G control plane RAN backhauling over satellite vs. terrestrial transport network

Compare results for a single UE procedure over satellite and ground based backhaul.

Wireshark traces in both scenarios for UE Attach Process.

#10 Comparison of user plane 4G/5G RAN backhauling over satellite vs. terrestrial transport network

Compare results from a User Experience perspective while accessing a video from the Internet over satellite backhaul and terrestrial backhaul

Measure DL data rate/end-to-end latency/round-trip-time

#11 Time taken for small cell (eNB) to complete connection with CN

Once the mobile core is ready and in steady state, a small cell (eNB) is powered “ON” and traces captured.

Wireshark traces to show the timestamps at the small cell that show the full procedure.

#12 Round-Trip-Time from UE to a ground data network (e.g. Internet)

Measure time to reach an internet device from UE

Wireshark trace / screen logs of the application on UE

#13 Round-Trip-Time from UE to local content over breakout

From the UE, measure the round-trip-time to the server hosting video

Wireshark trace / screen logs of the application on UE

SaT5G (761413) D5.2/D5.4 March 2020

of 108

content on the inflight segment of the network

#14 Downlink rate from the local server over breakout to a UE

Measure the data loading profile of the nanoCDN server

Measure the downlink rate when one UE is connected and consuming caching / breakout content

#15 Aggregate downlink rate from a ground data network (e.g. the Internet) to different UEs that request different services

Measure the data going through the Ethernet interface at the small cell

Measure the Rx and Tx kbps at the small cell radio access

#16 Aggregate uplink rate to from different UEs that request different services (local MEC services and/or remote data network)

Analyse the data going through the Ethernet interface at the small cell

Measure the Rx and Tx kbps at the small cell radio access

#17 Service Creation time. This test case records the time taken for the whole test bed to come up and ready to provide service.

Time taken for each of the service component (from OSM perspective) is recorded based on certain events observed in the start-up process. Events are valid for the each of the service.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

7 Measurement KPIs

In this section, we provide the KPIs that were measured over the ZII test bed, considering both the OTA MEO satellite backhaul and the emulated GEO satellite backhaul. The list of KPIs is related to the test cases laid down in Section 6. The KPIs reported in this section shall be measured for the sake of the results shown in Section 8.

Table 12: Satcom specific KPIs measured over the ZII test bed

Test Case (Section

6) KPI Description

Measurement Unit

Why is this KPI relevant

Test Case #4

Measure the E2E jitter

milliseconds Shows the variation in latency of packets

carrying data over the E2E network

Test Case #4

Measure the jitter in both link directions (FWD

and RTN)

milliseconds Shows the variation in latency of packets

carrying data over the link

Test Case #3

Measure the E2E delay through the whole pass

milliseconds

Shows the delay induced in the E2E network (incl. satellite and terrestrial parts)

iperf to confirm latency

Test Case #3

Measure the RTT (Round Trip Time) over the

satellite

milliseconds

Shows the delay induced by the satellite link only

Helps to assess impact on eNB/gNB timer settings and on 4G/5G RAN synchronization

Test Case #2

Measure the Es/N0 (SNR)

levels in both link directions (FWD and RTN), during

/ not during handover

dB

Difference between the received signal and the noise floor

Ensures the satellite link quality, and influences the MODCOD choice which affects the physical bandwidth and number of errors

Test Case #1

Measure the satellite

throughput in both link

directions (FWD and RTN)

Mbit/sec Shows the traffic rate that can be

achieved

Test Case #1

Maximum data rate achieved based on the

GLT-1000 modem

capabilities

Mbit/s Shows the maximum traffic rate that can

be achieved with given modem technology

N/A Measure packet loss during / not during handover

%

Indicates the quality of the network. Helps to detect errors in data transmission or network congestion.

iperf running through the handover so that we can see if there is any packet loss. Pings frequency is only once per second so it cannot often catch the loss of packets due to handover.

N/A

Measure and record the

number of Good Frames received over the satellite

in both link

# of Frames Helps to calculate the frame error rate,

which is used to test the performance of the receiver

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Test Case (Section

6) KPI Description

Measurement Unit


directions (FWD and RTN)

N/A

Measure and record the

number of Bad Frames received over the satellite

in both link directions (FWD

and RTN)

# of Frames Helps to calculate the frame error rate,

which is used to test the performance of the receiver

Table 13: KPIs measured over the ZII test bed and radio access network

Test Case (Section

6) Description

Measurement Unit


Test Case #17

Time required for the test bed to become active

Minutes Shows the speed of deployment of a satellite and mobile network system ready to provide service to onboard UEs

Test Case #17

Time for CDN to become

operational Minutes

Test Case #17

Mobile core component start

up time

Measured in demo, it was

around 5 mins

This show much time is spent in bringing up mobile network.

Test Case #17

Time for CN / MEC to connect:

seconds It shows the time spent on satellite link to complete the Control Plane signalling.

Test Case #11

Time taken for eNB to complete connection with

CN

seconds Time taken for S1 Signalling from eNB to Core

Test Case #9

Time for UE to complete the

attach process seconds It verifies that 3GPP timers are not violated

Test Case #12

Round-Trip-Time from UE to

Internet seconds

It quantifies the time required to access an external data network

Test Case #13

Round-Trip-Time from UE to local

content over breakout

milliseconds It quantifies the time required to access media content cached on-board

Test Case #13

Time to accessing video from the VOD

milliseconds It shows the value add/ user experience of using Break-out over connecting over satelline link to internet

Test Case #12, #10

Accessing video via you tube

(Internet) seconds

It demonstrates that the User can still connect to internet for a variety of videos/news not available on local content cache

Test Case #15

Downlink data rate from the

Internet Mbit/s

It demonstrates the achievable end-to-end performace in realistic set-up

Test Case #16

Downlink data rate from the local breakout

server

Mbit/s It emonstrates the achievable performance from caching content on-board

SaT5G (761413) D5.2/D5.4 March 2020

of 108

8 II Test Bed Measurement Results

The following sections are devoted to show the measurement results that were obtained for the OTA O3b satellite backhaul and for the emulated GEO satellite backhaul. The former set of measurements was obtained during the one-month period in which the O3b satellite capacity was available between November and December 2019. The latter set of measurements took place in January 2020. Specifically, Section 8.1 reports on the service creation measurements when the starting point is the satellite – terrestrial resource manager TALENT (OSS layer). Section 8.2 revolves around the measurements for the O3b satellite link. Section 8.3 is instead devoted to the measurements conducted for the mobile network when the backhaul between the Aircraft Network and ZII DC is based on O3b satellite. Section 8.4 reports on the measurements done for the content delivery service to the aircraft. Section 8.5 provides the measurements for the emulated GEO satellite link and Section 8.5.4 the measurements obtained for the mobile network connectivity provided to passengers with backhaul based on GEO satellite.

8.1 Virtualised Services Creation Time Since the ZII test bed is a cloud infrastructure in which the services of interest were virtualised, we measured the time required to create them. In this case, we consider that the service creation time includes: 1) time to spin up the VMs from TALENT, 2) the additional time for a specific software solution to become operative and 3) the resulting service creation time.

Figure 53: Measured time durations of the different phases that are required to fully start the SkyEdge II-c satellite hub for GEO connectivity

Figure 54: Measured time durations of the different phases that are required to fully start the Quortus mobile core network with CUPS feature to enable end-to-end connectivity over GEO satellite

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 55: Measured time durations of the different phases that are required to start the Broadpeak content delivery service

Figure 56: Measured service creation for the Open5GCore: one VM for the Aircraft UPF and one VM for the Ground UPF and control plane functions.

8.2 Measurements Results over OTA MEO Orbit Satellite This section is devoted to report the measurements carried out for the OTA MEO orbit satellite in which we make use of the O3b constellation.

8.2.1 O3b Satellite Link Benchmark Figure 57 to Figure 59 show the results for the benchmark of the O3b satellite Return (RTN) link using the iperf utility, respectively in terms of measured data rate, jitter and packet loss. Figure 60 to Figure 62 report the same measurements on the Forward (FWD) link; Figure 63 shows the measured RTT over the O3b satellite link with ping utility between the two Gilat modems: Wessling and Sintra.

NOTE: Note that that the x-axis in the following figures stands for ‚Time‘: the distance between two consecutive points in the graph is in seconds. The time span includes several hundreds of seconds.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 57: Measured data rate over the O3b RTN link (from Wessling to Sintra only) during satellite handover – iperf with UDP traffic

Figure 58: Measured jitter over the O3b RTN link (Wessling to Sintra only) during satellite handover – iperf with UDP traffic

Figure 59: Measured packet loss over the O3b RTN link (from Wessling to Sintra only) during satellite handover – iperf with UDP traffic

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 60: Measured data rate over the O3b FWD link (Sintra to Wessling only) during satellite handover – iperf with UDP traffic

Figure 61: Measured jitter over the O3b FWD link (Sintra to Wessling only) during satellite handover – iperf with UDP traffic

Figure 62: Measured packet loss over the O3b FWD link (Sintra to Wessling only) during satellite handover – iperf with UDP traffic

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 63: Measured round trip time over the O3b satellite link (from one Gilat modem to another)

8.2.2 End-to-End Link Benchmark In the this set of measurements, we report on the end-to-end link benchmark performance including the O3b satellite path and the Layer 2 VPN between Wessling (ZII office where the Aircraft Network and the ground datacentre are located) and the O3b satellite teleport at Sintra. The results are shown first during the interval between two consecutive handover events and afterward for the case in which a satellite handover takes place; in all cases the iperf utility was used.

8.2.2.1 Measurements on the Link between the Aircraft Network and the ZII Datacentre

Figure 64 through Figure 66 show respectively the measured end-to-end data rate, packet jitter and the packet loss on the satellite link between the Aircraft Network and the ZII ground DC without satellite handover. In Figure 67 to Figure 69 we show the same type measurements but with handover.

Figure 64: Measured end-to-end data rate between the Aircraft network (Wessling) and the ZII datacentre (Wessling) including OTA O3b satellite link and Layer 2 VPN – no satellite handover

Figure 65: Measured end-to-end jitter between the Aircraft network (Wessling) and the ZII datacentre (Wessling) including OTA O3b satellite link and Layer 2 VPN – no satellite handover

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 66: Measured end-to-end packet loss between the Aircraft network (Wessling) and the ZII datacentre (Wessling) including OTA O3b satellite link and Layer 2 VPN – no satellite handover

Figure 67: Measured end-to-end data rate between the Aircraft network (Wessling) and the ZII datacentre (Wessling) including OTA O3b satellite link and Layer 2 VPN – during O3b satellite handover

Figure 68: Measured end-to-end jitter between the Aircraft network (Wessling) and the ZII datacentre (Wessling) including OTA O3b satellite link and Layer 2 VPN – during O3b satellite handover

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 69: Measured end-to-end packet loss between the Aircraft network (Wessling) and the ZII datacentre (Wessling) including OTA O3b satellite link and Layer 2 VPN – during O3b satellite handover

8.2.2.2 Measurements on the Link Between the ZII Datacentre and the Aircraft Network

In Figure 70 to Figure 72 we respectively show the measured data rate, packet jitter and packet loss between the ZII DC and the Aircraft Network in case of no satellite handover; in Figure 73 to Figure 75 we provide the same measurements during the O3b satellite handoff.

Figure 70: Measured data rate between the ZII DC (Wessling) and the Aircraft Network (Wessling) including OTA O3b satellite link and Layer 2 VPN – no satellite handover

Figure 71: Measured jitter between the ZII DC (Wessling) and the Aircraft Network (Wessling) including OTA O3b satellite link and Layer 2 VPN – no satellite handover

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 72: Measured packet loss between the ZII DC (Wessling) and the Aircraft Network (Wessling) including OTA O3b satellite link and Layer 2 VPN – no satellite handover

Figure 73: Measured data rate between the ZII DC (Wessling) and the Aircraft Network (Wessling) including OTA O3b satellite link and Layer 2 VPN – during O3b satellite handover

Figure 74: Measured jitter between the ZII DC (Wessling) and the Aircraft network (Wessling) including OTA O3b satellite link and Layer 2 VPN – during O3b satellite handover

Figure 75: Measured packet loss between the ZII DC (Wessling) and the Aircraft network (Wessling) including OTA O3b satellite link and Layer 2 VPN – during O3b satellite handover

SaT5G (761413) D5.2/D5.4 March 2020

of 108

8.2.2.3 Evaluation of Satellite Handover in O3b-based Constellation In this section we analyse more in detail the effect of the O3b satellite handover when a file is downloaded on the aircraft network, for example in the media server on-board, with the server located in the Internet (as shown in the figure, we are downloading an Ubuntu OS image). In Figure 76, we can see the download bandwidth before the handover, whilst Figure 77 shows the loss in the download bandwidth in correspondence of the satellite handover with the link still operational and Figure 78Figure 77 shows the download bandwidth recovery as soon as the handover event occurred; we also notice that the full recovery happens extremely fast. Figure 80 shows instead the throughput measured at the physical layer at the Gilat modem in Wessling during the file download and also from this figure we notice the momentary loss of download speed with the fast recovery. We remark again that the satellite link was always operational.

Figure 76: Observed file downloading speed before the occurrence of a satellite handover

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 77: Observed file downloading speed during the occurrence of the satellite handover

Figure 78: Observed file downloading speed after the satellite handover completion

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 79: Measurement of the physical layer throughput during the occurrence of a satellite handover

To investigate as thoroughly as possible the behaviour of the MEO Booster in steering the modems during the satellite handover, in a different moment we also carried out the following measurements at the physical layer with regard to SNR and throughput. The SNR levels are shown in Figure 80, measured assuming the receiver to be the modem in Sintra and the transmitter in Wessling. During the handover, there was a slight dip in the SNR at Sintra as shown in the Rx graph (top figure). At Wessling side (bottom), the SNR increased for the period of the handover, as shown in the graph labelled Tx.

Figure 80: Gilat modem interface: measured SNR for reception in Sintra and transmission in Wessling

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 81 shows the situation we measured in case of a perfect satellite handover. The handover was at time 6:20:39. The screenshot was captured at 06:25:14, nearly 5 minutes after the handover. A single loss of a ping was recorded during the whole handover time. The date and time can be seen in the MEO Booster screen on the left. TCP Traffic was sent from Sintra to Wessling direction and acknowledgement traffic is shown in the reverse direction. The screenshots were taken from the modem in Wessling.

Figure 81: MEO Booster panel (left) and Gilat modem interface (right): observed throughout behaviour during smooth O3b satellite handover

Figure 82 shows the measured SNR for the same switchover as shown in the physical layer above.

Figure 82: MEO Booster panel (left) and Gilat modem interface (right): observed SNR behaviour during smooth O3b satellite handover

We also noticed that not all the handovers, however, were as smooth as the previous one. Referring to Figure 83 in fact, many of them had a momentary loss in the physical layer, which was quickly recovered. Figure 83 shows the behaviour at the physical layer in the Rx side in Wessling. In Sintra the SNR increased following the switch to the rising satellite.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 83: Gilat modem interface: observed SNR reduction at the receiver in Wessling (top) and SNR increase at the transmission in Sintra (bottom)

8.3 Mobile Network Measurements over OTA O3b satellite In this section, we report the measurement activities carried out regarding connecting personal devices of the passengers through the mobile network deployed on-board and backhauled to the ground by means of the O3b satellite in the MEO orbit. Our aim in this case is to present applications as realistic as possible to reproduce trials representative of the passengers’ data traffic while they are on-board. We further recall that in the trials, one small cell is located on-board the airplane and another on ground so that the first makes use of the O3b satellite link, while the other of a typical terrestrial backhaul.

8.3.1 Control Plane Measurements Referring to the test bed architecture shown in Figure 4 and the system architecture in Figure 15 developed for the specific needs of the measurements conducted for the over-the-air MEO orbit; we noticed that the connection of the small cell radio access to the 5G core, the UEs that connect to small cells and the aircraft UPF were not affected by the O3b satellite backhaul. As shown in Table 14. Times were measured based on Wireshark traces considering Non-Access Stratum (NAS) messages.

Table 14: Comparison between ground radio access network and Aircraft access network based on GEO satellite backhaul.

Small cell connection time UE attach time

Terrestrial backhaul ~1.05 seconds ~0.74 seconds

Satellite backhaul over O3b Negligible impact compared to terrestrial

Negligible impact compared to terrestrial

SaT5G (761413) D5.2/D5.4 March 2020

of 108

8.3.2 User Plane Measurements In terms of data plane measurements, we shall refer to the end-to-end connectivity system shown in Figure 38 and we highlight that in the remainder of this section, the term PED and UE are used interchangeably. Downlink (DL) and Uplink (UL) traffic measurements are reported among others.

At first, we begin with the measurements obtained for the MEC case, in which passengers request content stored in the local cache relying on the BPK content delivery service. The measurement of the download rate and profile is provided in Figure 84. Figure 85 shows the RTT measured at a UE side to download content through the aircraft UPF, while Figure 86 the RTT measured at a UE side when contacting the Internet. Both measurements were made using the ping utility.

Figure 84: Measured transfer rate between Aircraft-UPF and small cell radio on-board the aircraft

Figure 85: Measured Round Trip Time between a connected UE and the Aircraft-UPF

Figure 86: Measured Round Trip Time between the Aircraft small cell and the Internet

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 87 shows the downlink traffic measured at the ground UPF with one UE (i.e. a PED) accessing youtube. On the other hand, Figure 88 extends this case to three UEs and one accessing content cached content in the VOD on-board the aircraft, measuring the received and transmitted traffic at the network interface of the small cell device for DL and UL traffic.

Figure 87: Measured DL traffic at the mobile core – one UE accessing youtube

Figure 88: Measured DL/UL traffic at the aircraft small cell – three UEs youtube, one UE cached content

SaT5G (761413) D5.2/D5.4 March 2020

of 108

In Figure 89, we measure the DL (top figure) and UL (bottom figure) traffic, or in other words the received and transmitted as measured at the network interface of the small cell device, when two UE (i.e. PEDs) consume live video feed from the Internet, one passenger requests youtube video and another UE accesses video content from the cache catalogue on-board. Figure 90 shows instead the traffic measured the Ground UPF (see Figure 38) with the same traffic requests.

Figure 89: Measured DL/ traffic at the aircraft small cell – two UE live video streaming, one youtube, one cached

Figure 90: Measured DL traffic at the mobile core – two UE live video streaming, one youtube, one cached

In the last measurements we report for the small cell on-board the aircraft, we consider different mix of traffic requests initiated by the passengers but we measure again the downlink and the uplink data rates

SaT5G (761413) D5.2/D5.4 March 2020

of 108

as shown in Figure 91 and Figure 92. We shall notice that the spikes of traffic measured at the small cell is the result of combining content requested from youtube and content from the VOD since both make use of a similar mechanism to load chunks of data.

Figure 91: Measured DL traffic at the aircraft small cell – one UE live video streaming, one UE youtube, one UE cached content

Figure 92: Measured DL/UL traffic during satellite handover – two UE live video streaming, one UE youtube, one UE cached content

SaT5G (761413) D5.2/D5.4 March 2020

of 108

8.3.3 Ground Small Cell Connectivity As mentioned already, while one small cell radio access was deployed in the cabin mock-up aircraft and backhauled whereby the MEO satellite backhaul, another small cell was deployed on ground and backhauled whereby terrestrial backhaul. The type of measurements done for the user plane are similar to those shown in the previous section and are mainly done for the sake of addressing a comparison between the two types of backhaul systems. Figure 93 shows the significantly lower RTT to access the Internet from the ground small cell for a UE when comparing with the same situation on-board the aircraft. Figure 94 shows the specific case in which some PED requests access to youtube while some other to a live video feed. Interestingly, in Figure 95 we compare the downlink traffic measured the aircraft and ground small cells. At the ground small cell two PEDs (i.e. UEs) request video content from youtube and two a live video stream. At the aircraft small cell instead two PEDs request youtube video content, one live video stream and one PED requests traffic from the VOD on-board, which is cached content. We can notice from this figure that the downlink traffic of the small cell on the ground is still higher than that on the aircraft and moreover, on average, the downlink traffic in the ground small cell amounts approximately 10 Mbps, while in the aircraft small cell to 6 Mbit/s. Anyway, we can conclude that they are comparable, and the satellite backhaul introduces a marginal penalty compared to the typical terrestrial case considering also that one PED on-board the aircraft consumes content from the VOD, which is not the case for the small cell on ground.

Figure 93: Measured Round-Trip-Time between the ground small cell access network and the Internet

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 94: Measured DL/UL data traffic at the ground small cell – two UE live video streaming, two UE youtube

Figure 95: DL traffic comparison measured at the ground and aircraft small cells

8.3.4 Aircraft Connectivity featuring Passengers’ Mobility In the last part of the measurements done in the Aircraft Network backhauled over the MEO satellite, we focused on managing passengers’ mobility when they move from the ground small cell to the aircraft small cell radio access. The 5G mobile core used is the Open5GCore prototype, which supports both X2 (Xn for a gNB) and S1 (N2 for a gNB) handover. The small cell radio access shown in Figure 96 was supplied by Casa Systems as part of a collaboration with the 5G PPP project 5G ESSENCE.

Figure 96: Small Cell Radio Access – Casa Systems [6]

As mentioned in Section 6.1.3 and described in Figure 52, due to the specific implementation of the Open5GCore, the UE association is based on APN selection. A passenger moves from the ground network to the one on-board the aircraft. The PED was set to APN Default (the one on-board referring

SaT5G (761413) D5.2/D5.4 March 2020

of 108

to Figure 52), but it is connected to the Internet meanwhile the passenger is changing backhaul from terrestrial to O3b. In this case, we used the ping utility executed on the UE itself. Looking at the database inside the small cells, we found that they are able to discover each other by means of Automatic Neighbour Relation (ANR) tables, which is a SON mechanism inside both cells. The small cell on ground carries Physical Cell ID (PCI) 422, while the one on the aircraft carries PCI 425.

Referring to the left hand side of Figure 97, which is obtained by means of the ‘Network Cell Info Lite’ App installed on the personal device, we notice that the UE is initially attached to the small cell with PCI 422, the one on ground, but while walking to the cabin mock-up aircraft also the signals of the other small cell with PCI 425 are measured. With mobility at some point the UE completely relocates to the aircraft small cell with PCI 425.

As a result of the whole procedure, we refer to the result shown in Figure 98, which is obtained with the ping utility measuring the RTT to the Internet, as mentioned already. Specifically, we conducted tests with and without the O3b satellite handover and we observed the behaviour in Figure 98 for both cases. Hence, the result of this trial shows that the UE undergoes to a cell reselection process. The measurement of the RTT is initially higher since the Aircraft UPF is used with the Ground UPF (see Figure 52). As soon as the UE is on-board the aircraft, the RTT is similar to the one shown in Figure 86. Anyway, we could not observe a handover but rather a cell reselection from the Wireshark traces as highlighted in Figure 98 by the interval without measurement results (i.e. ICMP packets are lost).

Remark: since the behaviour observed is the same with and without satellite handover, we ought to conclude that this is only due to the deployment choice of the ground small cell with respect to one in the cabin mock-up and the configuration parameters of the small cells like the power threshold for triggering the handover. Even though we tried to deploy the ground small cell in different locations, the behaviour persisted. Anyway, an optimization of the small cells handover parameters was out of scope of the ZII test bed work and we concluded that in a field deployment this problem can be overcome taking into account the geometry of the environment in which the ground small cell will be deployed.

Figure 97: Screenshot of a UE with Network Cell Info Lite App: left shows the UE attached to cell with PCI 422; right shows the UE after cell reselection to the small cell with PCI 425

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 98: Measured round-trip-time to access the Internet (e.g. Google) with the superimposition of satellite handover and mobile network handover

8.4 Virtualised Content Delivery Service The content delivery service provided by BPK was evaluated in terms of the service creation time in Figure 55. As soon as the whole service is deployed (BKM100, BKS350 & BKS400 virtual machines are spun up in the NFVI), and the license is enabled on each of the BPK components, the BKM100 (CDN Mediator) will consider that the system is up and running.

8.4.1 Data transmission metrics The system has been configured with three different encoding profiles to feed the Origin Servers:

- Standard Definition (SD) profile - High Definition (HD) profile - Ultra-High Definition (UHD) profile.

Each video profile is composed of several layers with different bit rates as described below.

Table 15: SD Profile

Layer Video Audio TOTAL (Mbps)

1 0,2 0,048 0,248

2 0,5 0,096 0,596

3 1,2 0,096 1,296

4 1,7 0,096 1,796

Table 16: HD Profile

Layer Video Audio TOTAL (Mbps)

1 0,2 0,048 0,248

2 0,5 0,096 0,596

3 1,2 0,096 1,296

4 2 0,096 2,096

5 6,1 0,128 6,228

Table 17: UHD Profile

Layer Video Audio TOTAL

1 0,5 0,096 0,596

SaT5G (761413) D5.2/D5.4 March 2020

of 108

2 1,2 0,096 1,296

3 2,5 0,096 2,596

4 4 0,128 4,128

5 8 0,128 8,128

6 14.5 0,128 14,628

Thanks to the multicast Adaptive Bit rate (mABR) technology, only the highest quality level needs to be broadcasted. Other layers are available on the CDN to manage unicast requests access.

Relying on Section 4.9 and Section 6.1.2, the VOD assets sent in multicast towards the airplanes have the following specifications:

SD Profiles for classic movies with an overall bitrate of 1,8 Mbps

HD Profiles for most of the movies with an overall bitrate of 6,3 Mbps

UHD Profiles for blockbusters with an overall bitrate of 15 Mbps

In the following measurements, we shall consider that the standard duration of a movie is 90 minutes.

8.4.2 Transmission rate between the BKS350 and the BKE200 The first step in the mABR Push VOD workflow is to transfer the VOD files from the origin server (BKS350) to the transcaster (BKE200).

As the BKS350 is acting as origin server for the unicast streamer (BKS400), the BKE200 should not use all the streaming capacity of the BKS350 to avoid disturbing the overall system. Due to this constraint, the BKS350 throughput to the BKE200 transcaster must be limited.

In Table 18, we are estimating the transfer of 3 Hours of SD content at 1.8 Mbps + 4h30 of HD content at 6.3 Mbps between the BKS350 (NFVI in the ZII infrastructure) and the BKE200 (satellite teleport). We are evaluating the time to do the file transfer depending on the available link capacity between the BKS350 and the BKE200.

Table 18: Measured and estimated transfer rate internal to CDN components

Parameter Unit Result

Ingestion Capacity link Mbps 50

Nb. Popular Hours SD hours 3

Bitrate SD Mbps 1,8

Nb. Popular Hours HD hours 4,5

Bitrate HD Mbps 6,3

TOTAL Storage required (BkE200) GB 15,19

Time required to Pull/Store Minutes 40,50

We would highlight that the time to transfer the VOD files between the BKS350 and the BKE200 does not impact the time to transfer the videos to the plane as the ingest on the BKE happens only during the initial stage of the streaming process and it involves only the BKE200. After the initial ingest, the BKE200 will continue to transfer the (video) content in carousel mode. Thus, the most important metric is the time required to transfer the VOD carousel from the BkE200 to the nanoCDN located in the aircraft.

8.4.3 Time to transfer content from BKE to nanoCDN in the Aircraft The values shown in the table below are measuring the time to send popular VOD assets over the air. We consider below that we are transmitting 3 hours of SD contents at 1.8 Mbps and 4.5 hours of HD contents at 6.3 Mbps. We are calculating the time to transfer the popular VOD assets in multicast ABR depending on the capacity of the satellite link. The column with green bold numbers highlights the case of measurements with the available O3b satellite link, while the remaining columns provide an estimation in case of reduced link capacity.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Table 19: Measured and estimated transfer rate to the nanoCDN

Parameter Unit Results

Transponder rate Mbps 10 20 30 40 50 60

Nb. Popular Hours SD

hours 3 3 3 3 3 3

Bitrate SD Mbps 1,8 1,8 1,8 1,8 1,8 1,8

Nb. Popular Hours HD

hours 4,5 4,5 4,5 4,5 4,5 4,5

Bitrate HD Mbps 6,3 6,3 6,3 6,3 6,3 6,3

TOTAL Storage required (BkE200)

GB 15,19 15,19 15,19 15,19 15,19 15,19

Time required to Stream

Minutes 202,50 101,25 67,50 50,63 40,50 33,75

Using a transponder at 60 Mbps, transferring 3 Hours of SD content and 4.5 hours of HD content requires a bit more than 30 minutes. The carousel is repeated continuously to serve all the airplanes.

8.4.4 Bandwidth usage and time to transfer a catalogue of 20 popular HD VOD assets in multicast to 1 aircraft

In the table below we are evaluating the bandwidth to transfer a catalogue of 20 popular HD VOD assets in multicast to 1 airplane. We consider each VOD is 90 minutes in length and has an average bitrate of 6.3 Mbps. Besides, we consider we are using a transponder with 60 Mbps of bandwidth.

Table 20: Time require to cache a catalogue of 20 popular HD VOD assets


Transponder rate Mbps 60

VSAT Capacity Output Mbps 60

Nb. Popular Hours HD hours 30

Bitrate HD Mbps 6,3

TOTAL Storage required (BkE200) GB 85,05

Time required to Stream Minutes 189,00

Sending 30 hours of popular VOD assets to 1 airplane is taking about 3 hours.

We note that in case the nanoCDN agent on board is missing some chunks of data, it will be able to retrieve the missing packets using unicast from the ground station. As most of the data will be retrieved from the mABR source, the unicast traffic with the ground will be limited.

8.4.5 Bandwidth usage and time to transfer a catalogue of 20 popular HD VOD assets in multicast to 100 aircraft

Multicast ABR streaming is a “Broadcast compatible” protocol, meaning the PUSH VOD will be available to all aircraft at the same time. Since the solution is scalable, the time required to stream to 100 aircraft will be the same as the time required to push VOD assets to one aircraft. Sending 30 hours of popular HD VOD assets to 1 airplane, 100 or 1000 airplanes is taking about the same 3 hours.

8.4.6 Bandwidth usage and time to transfer in unicast pull mode a catalogue of 20 popular HD VOD assets to 1 aircraft

Transferring a VOD catalogue in unicast to an airplane is challenging. We will suppose in the following that only one plane is using the satellite link and that users are requesting the videos equally in the airplane (20 VOD assets, 100 passengers, at least one passenger is requesting one of the 20 VOD assets).

SaT5G (761413) D5.2/D5.4 March 2020

of 108

In this scenario, we suppose passengers share a single satellite link of 60 Mbps and that the local cache server on the plane is initially empty. Each request goes to the local cache server (nanoCDN), meaning the 60 Mbps bandwidth must be shared between the 20 VOD assets, and nanoCDN is caching the content for the next similar request. With such a scenario, we can assume that an average bandwidth of 3 Mbps per VOD is available. Due to this constraint, the passengers will not be able to access the higher quality of the VOD assets. In our case we refer to the table of an HD profile previously provided.

When a VOD asset is requested for the first time, the video session will start with the layer 4 at 2 Mbps. Once the 2 Mbps layer will be cached on the plane, next viewers should be able to start downloading the higher quality levels directly. With the previous hypothesis, it is difficult to evaluate how long it can take in order to cache the content on the plane using unicast, however we can consider that the required time will be at the very best similar to the one required when using multicast ABR.

8.4.7 Bandwidth usage and time to transfer in unicast pull mode a catalogue of 20 popular HD VOD assets to 100 aircraft

The calculations below are based on the previous figures (unicast of 20 HD VOD assets to 1 airplane) and extended to 100 airplanes. We consider here that all the aircraft are using a unique transponder of 60 Mbps.

Table 21: Comparison between multicast and unicast injection of assets if the VOD


Transponder rate Mbps 60

VSAT Capacity Output Mbps 60

Nb. Popular Hours HD hours 30

Bitrate HD Mbps 6,3

Time required to Stream per plane minutes 189,00

Number of Planes NB 100,00

Time required to stream in unicast to All minutes 18900,00

According to these KPIs, we can see that feeding 100 aircraft in unicast with 20 new VOD assets using one unique transponder would take 18900 minutes, which is equivalent to more than 13 days to have all the contents loaded into all the aircraft. Loading a VOD Catalogue on airplanes requires to dedicate at least one transponder per plane, which really increases the cost of the solution.

8.4.8 Comparison between Multicast and Unicast file transfer for 20 popular HD VOD assets in unicast to 100 aircraft

We clearly see the benefit of Multicast ABR usage for Popular VOD caching. By design, mABR is scalable and use few resources. Usage of multicast ABR limits and fix the OPEX and the CAPEX of such a system, while usage of Unicast implies to scale the system accordingly to the number of aircraft, generating much higher costs.

Table 22: Summary of the benefits of using multicast over satellite

Parameter Units Unicast Multicast

VSAT Capacity Output

Mbps 60 60

NB Popular Hours HD hours 30 30

Bitrate HD Mbps 6,3 6,3

Time required to stream the VODs to the planes

minutes 18900,00 189,00

SaT5G (761413) D5.2/D5.4 March 2020

of 108

8.5 Measurement Results Over Emulated GEO Orbit Satellite

The following section is devoted to report on the measurements carried out over the emulated satellite connection in the GEO orbit. As mentioned previously the satellite technology is based on a virtualised SkyEdge II-c system provided by Gilat. The remainder of this section I organised as follows. In Section 8.5.1 we show the Outbound and Inbound Es/N0 and SNR measurements over the GEO satellite link. In section 8.5.2 we show the satellite link benchmark in terms of the measures throughput, while in Section 8.5.3 we provide the measurements regarding the round-trip-time. In Section 8.5.4 we show instead the measurements we took for the Aircraft Network.

8.5.1 SNR and EsN0 Measurements

8.5.1.1 Outbound Es/N0 The VSAT measured the following Es/N0 as shown in Figure 99, which makes evident that the emulated satellite link was very steady and on average the Es/N0 was 9.57 dB.

Figure 99: Measured Es/N0 by the VSAT terminal

8.5.1.2 Inbound SNR The MCR at the hub measured the SNR shown in Figure 100, which again confirms that the link was very steady the SNR was on average 17.93 dB.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 100: SNR measured at the SkyEdge II-c satellite hub

8.5.2 GEO Satellite Backhaul Outbound and Inbound Throughput The following figures show the traffic throughput on the emulated GEO satellite path, first doing the benchmark of the GEO satellite link only (i.e. excluding the Layer 3 VPN) and afterward while the end-to-end tests were ongoing. Specifically, we show the benchmark throughput of the emulated GEO satellite path for the inbound (IB or RTN) link and for the outbound (OB or FWD) link, respectively. While the end-to-end tests were ongoing, we measured the traffic over the backhaul. In both cases, results were captured at the VSAT.

8.5.2.1 Benchmark of Inbound Throughput in the Emulated GEO Satellite Link The inbound link throughput is benchmarked performing an FTP file transfer from the FTP client to the FTP server as shown in Figure 101. The graph shows that the peak inbound throughput reaches 12.8 Mbps. We remind that the inbound direction is from the VSAT (Aircraft Network) to the hub (ZII DC).

Figure 101: Benchmark of the inbound GEO satellite link: outcome of an FTP file transfer

SaT5G (761413) D5.2/D5.4 March 2020

of 108

8.5.2.2 Satellite Backhaul Outbound Throughput The outbound throughput is also benchmarked doing an FTP file transfer from the FTP server to the FTP client as shown in Figure 102. The graph shows that the peak outbound throughput reaches 61.8 Mbps. We remind that the outbound direction is to be considered from ground to the Aircraft Network.

Figure 102: Benchmark of the outbound GEO satellite link: outcome of an FTP file transfer

8.5.2.3 Traffic tests with 4 UEs attached The following graphs were taken during the end-to-end trials in which four UEs were attached to the mobile network deployed in the cabin mock-up. In the timeframe between 03:05 PM and 03:15 PM there was:

UE-1 was browsing internet content

UE-2 was connected to the ME

UE-3 was watching youTube

UE-4 was watching you Tube.

The first graph shows the FWD throughput in kbps versus time. As shown in Figure 103 the outbound direction reached peaks of more than 30 Mbps.

Figure 103: Measured traffic over the outbound emulated GEO satellite backhaul: one UE browse, one UE cached content and two UEs youtube

SaT5G (761413) D5.2/D5.4 March 2020

of 108

The next graph shows the inbound throughput in Kbps versus time. In the inbound direction the traffic reached a peak of 250 kbps. This inbound traffic mainly consisted of acknowledgement packets for the TCP traffic in the outbound direction.

Figure 104: Measured traffic over the inbound emulated GEO satellite backhaul: one UE browse, one UE cached content and two UEs youtube

In a different setting, passengers on-board the aircraft network consume different contents compared to Figure 103 and Figure 104, in the timeframe between 03:20 PM and 03:30 PM there was:


UE-2 was in breakout

UE-3 was watching Live TV

UE-4 was watching Live TV.

The graph in Figure 105, in the first part, shows the outbound throughput in kbps versus time. As shown the outbound direction reached peaks of 15 Mbps. The graph in Figure 106 shows the inbound throughput in Kbps versus time. In the inbound direction, the traffic reached peaks generally less than 100 Kbps, with one peak reaching 130 kbps. Again, the inbound traffic was mainly acknowledgement packets for the TCP traffic on the outbound link.

On the other hand, in the timeframe between 03:37 PM and 03:47 PM there was:


UE-2 was in breakout

UE-3 was watching a youTube

UE-4 was watching Live TV

The results are shown in Figure 105 and in Figure 106 for the outbound and inbound emulated GEO satellite backhaul, respectively. The second part of Figure 105 shows a throughput in Kbps versus time with measured peak values of 35 Mbps. The second part of the graph in Figure 106 refera to the inbound throughput in Kbps versus time. In the inbound direction the traffic reached peaks of 150 kbps since it carries mainly TCP acknowledgment traffic.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 105: Measured traffic in the outbound of the emulated GEO satellite backhaul

Figure 106: Measured traffic in the outbound of the emulated GEO satellite backhaul

8.5.3 Round-Trip-Time Measurements Over the Emulated GEO Link The round-trip-time shown in the screenshot in Figure 107 is the measured average RTT of 587 ms. This ping measurement was made from the Relay PC (172.200.1.129 in Figure 42) to the Router (172.200.1.241 in Figure 42) and the message transverses via the SkyEdge II-c Capricorn Pro VSAT, the RF path (Dynamic Low Fly, SLE, up/down converters and the SkyEdge II-c Hub equipment) via the vMx to the Router and back over the same path. The SLE added 239 milliseconds that counted twice leads to 478 milliseconds of delay. The various equipment along the path as mentioned above added the additional 54.5 milliseconds in each direction.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 107: Measured round trip time across the emulated GEO satellite path not including the Layer 3 VPN

8.5.4 Mobile Network Measurements with emulated GEO satellite backhaul

In this section, we provide the results for the control plane and the data plane (useful UEs traffic) that we obtained conducting different types of measurements using the emulated GEO satellite path as the backhaul between the access network on-board the aircraft and the ground data network.

Table 23 illustrates the control plane measurements with focus on the time required for the small cell on-board the aircraft to connect to the mobile core on the ground and for a UE to attach to the network. We noticed indeed that the GEO satellite backhaul has a non-negligible impact on the control plane of the mobile network. At first, during the trials, we noticed that the MEC component of the 4G core could not connect to the core on the ground since the high end-to-end link delay (i.e. satellite plus the Layer 3 VPN) caused a TCP timer to fire before completing the handshake between MEC and core. To overcome this problem Quortus updated their software to cope with the larger end-to-end latency. Comparing to Table 14, we noticed that the connection time of the small cell eNB is comparable to the terrestrial backhaul but the UE attach time amounted to more than 5 seconds, which is five times larger than what measured on the terrestrial backhaul.

Table 23: Control plane measurements

Parameter Time [ms]

Small cell connection time to the core 741

UE attach time 5,355

Table 24 shows instead the benchmark of the user plane performance from the point of view of a PED running a speed test on a UE.

Table 24: Speed test carried out at a PED connected to the Aircraft Network

Downlink [Mbit/s]

Uplink [Mbit/s] RTT [ms] Jitter [ms] Packet loss (%)

29.9 13.2 754 82 0.30

SaT5G (761413) D5.2/D5.4 March 2020

of 108

To benchmark the end-to-end link between the Aircraft Network and the ground ZII DC (i.e. including the Layer 3 VPN) we did a test at the mobile core resorting to the iperf utility and UDP traffic. Comparing Figure 108 to Figure 110 with Table 24, we can notice similarity of the downlink throughput but we also show that changing the point at which jitter and packet loss are measured, measured values can be affected accordingly. However, we can also consider that the values shown in Table 24 stand for the QoS parameters of the PED connection (i.e. passenger).

Figure 108: End-to-end GEO satellite link connection – measured traffic with iperf UDP server on the mobile core

Figure 109: End-to-end GEO satellite link connection – measured jitter with iperf UDP server on the mobile core

NOTE: Note that that the x-axis in the following figures stands for ‚Time‘: the distance between two consecutive points in the graph is in seconds. The time span includes several hundreds of seconds.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 110: End-to-end GEO satellite link connection – measured packet loss with iperf UDP server on the mobile core

Figure 111 shows the measured RTT to connect to the Internet from the Aircraft Network with the ping utility. Figure 112 shows the time required to access the VOD catalogue cached on-board the Aircraft from a PED perspective using again the ping utility, whereas Figure 113 the management and control traffic for a UE in idle mode measured at the ethernet interface of the small cell.

Figure 111: Measured RTT form the aircraft network to Google over the GEO satellite

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 112: Measured UE latency to access cached content through the MEC server

Figure 113: Measured traffic at the small cell access – one UE connected in Idle mode

The results shown in Figure 114, Figure 115 and Figure 116 report the traffic that was measured in the downlink (DL) and in the uplink (UL) directions from the perspective of the small cell radio access. Specifically, the measurements were obtained measuring the transmitted and received traffic over the network interface of the mall cell. Similar to the measurements obtained for the over-the-air MEO satellite backhaul, we consider different cases of traffic requested by the PED of the passengers as it can happen on a flight.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 114: Measured DL/UL data rate at the small cell – one UE browsing, one UE cached content, one UE youtube, 1 UE live video stream

Figure 115: Measured DL/UL data rate at the small cell – one UE cached content, one UE browsing, two UEs live video traffic

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 116: Measured DL/UL data rate at the small cell – one UE cached content, one UE browsing, two UEs youtube traffic

In the last set of measurements shown in Figure 117 and in Figure 118 we report the Round-Trip-Time measured with the ping utility to access the Internet from a UE perspective in a mobility scenario. As mentioned, we assume that two small cells are deployed on-board the aircraft and a passenger can walk from one small cell coverage to the other. Unlike for the MEO set-up in which one of the two small cells could rely on a typical terrestrial backhaul, in this case we assume that the backhaul is the GEO satellite link for both small cells that connects then to the 4G mobile core on the ground. In this case, we expected an X2 handover to take place but, similar to the case of the MEO, we noticed a tracking are change with the test UE detaching from one small cell and re-connecting to the next one. Similar to what described for the MEO satellite backhaul, the two small cells can discover each other by means of ANR tables and the UE can measure the signals of both cells during mobility. As shown in Figure 117, we notice a loss in the reception of the ICMP packets in correspondence of the transition from one cell to another. On the other hand, minimal impact was observed for the connection to the VOD catalogue of media contents cached on-board, as shown in Figure 118.

Analysing the cases of a MEO based satellite backhaul and of a GEO based satellite backhaul we observed a similar behaviour of the UE mobility. In addition, the overall behaviour was not even affected by the change of the mobile core (i.e. Open5GCore for the MEO satellite backhaul and the Quortus 4G core for GEO satellite backhaul). We thus conclude what already discussed for the MEO satellite backhaul since both types of core networks used in the trials could support X2 and S1 handovers. In other words, the settings in the small cells with regard for example to the power threshold for triggering the handover and the geometry of the environment affect the triggering of the handover event. Anyway, we remark that optimisation of the handover parameters for the small cells was not in scope of the ZII test bed. Moreover, we are confident that in the deployment on a large aircraft (e.g. A380) more extensive tests can easily overcome the problem of triggering the handover.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

Figure 117: Measured Round-Trip-Time to access Google while moving from the service small cell coverage to the neighbour small cell on -board the aircraft

Figure 118: Measured Round-Trip-Time to access cached content through the MEC server while moving from the service small cell coverage to the neighbour small cell

SaT5G (761413) D5.2/D5.4 March 2020

of 108

9 Summary and Conclusions

9.1 Overall Evaluation and Lessons Learned The design of the ZII test bed, the description of each individual test bed component and the trial results presented in the previous sections provide evidence to the significant team effort made by the partners to meet the SaT5G project objectives, as well as those set forth by the specific SaT5G UC4.

Overall, we looked at a new lean design of an end-to-end Inflight and Entertainment Connectivity (IFEC) system for aircraft. If we look at the existing IFEC systems, the design is purely hardware based which poses some limitations in delivering newer services. While we see an increasing demand from airlines and aircraft OEMs that demand a continuous development of technology for connectivity, Wi-Fi is the main radio access on-board and GEO based satellite backhaul is the only de facto technology in place. Currently, mobile network technology has limited penetration in the aviation sector and then mainly for voice communication. However, the exploding demand of data communications of people and the fact that this is increasingly supported by the handhelds, creates great potentials for 5G service outside and inside the cabin.

The innovation and progress brought by in the 5G test bed led by ZII is manifold. In the first instance, we note that a single OSS layer was used to manage the creation of satellite and mobile network connectivity and we managed to conduct trial activities with MEO satellite backhaul and take a new approach to GEO backhaul connectivity. The transformation toward virtualised network services that leverage on platform-as-a-service shows a significant evolution beyond the hardware based IFEC. If we consider the results, in approximately 12 minutes and half we are able to deploy both the satellite service and the mobile core, leaving to the cabin crew the only action to enable the small cell radio access on-board from the crew panel in the aircraft (referred to a system control unit).

For the MEO satellite backhaul system setup, the ZII test bed took the novel approach of the MEO Booster technology combined with the satellite modem. The MEO Booster is a cutting-edge solution that greatly simplifies the transmitter/receiver chain for managing the handover between rising and setting satellites in the MEO orbit. The technology is still prototype for an actual field deployment on commercial airlines, but the ZII test bed demonstrated the feasibility and correctness of the innovation approach as evident in the results that demonstrated the stability of the MEO satellite link. We would note that although in some cases the physical layer has a temporary loss the recovery is very fast and the connection to the ground segment is never lost. In some other cases instead, the handover exhibits zero loss. Overall, we proved the effectiveness of the MEO Booster based handover. This was observed at the application level where live TV streaming was playing uninterrupted. Over the emulated GEO satellite backhaul system setup, we first benchmarked the link, this was also very stable with the possibility to support passengers’ traffic of different types without any disruption.

In both cases of MEO and GEO satellite backhaul system setups, we also deployed a virtualised content delivery service, which is equivalent of content caching at the edge in alignment with the MEC approach. Content of caching is also a crucial change in the way of loading content to aircraft, both in terms of content volatility and efficient utilisation of the satellite bandwidth through multicast transmissions.

Overall, we learned that moving to service virtualisation we can detach from the hardware-based approach and deploy end-to-end services with near zero-touch orchestration effort very fast and with slimmer qualification process for aviation compliance. Mobile network connectivity can be rapidly deployed leaving to existing inflight operators, like SITAONAIR, to manage the spectrum on-board. If one satellite backhaul technology alone would not be enough to cater the demand of airlines, different constellations can be multiplexed in the future relying on the softwarization of the end-to-end system.

Concluding, the ZII test bed has received inputs from SaT5G WP3, WP4 (particularly D4.1 and D4.6) and provided inputs to WP2, showing also the synergy with all activities undertaken inside the project.

The ZII test bed has also contributed to raising awareness and expertise internal to the project partners but also externally by participating to various public events [14]:

Y. Rahulan, L. Goratti, H. Saarnisaari, B. Evans,"Demonstrating satellite integration in 5G networks – SaT5G’s eMBB use cases", European Conference on Networks and Communications (EuCNC), 2018, Special Session on “Satellite Solutions for the 5G Network of Networks”.

SaT5G (761413) D5.2/D5.4 March 2020

of 108

5G for Aircraft Connectivity and Service: Perspectives of the SaT5G Safran Passenger Innovations Test Bed Broadsky Workshop, co-located with the Ka band Conference, 30.09.2019, Sorrento (Italy);

Internet in Planes, 5G Satcom Seminar 30.09.2019, The Hague (The Netherlands)

Two lectures at the Technical University of Munich; o 5G Mobile Network Technology Meets the Satcom, Ph.D. School on 17.01.2020, o Mobile Network Technology Meets the Satcom, Broadband Communication Networks

Course for Master Thesis candidates;

The SaT5G Industry Day held at the University of Surrey, 27.11.2019; https://www.sat5g-project.eu/sat5g-industry-day-27-november/

5G Satellite-Terrestrial Integration for Aircraft Connectivity, Zodiac Inflight Innovations, Wessling (Germany), 06.02.2020, participated by SaT5G partners and external visitors; https://www.sat5g-project.eu/sat5g-industry-day-zii/

ZII cooperated with the 5G PPP project 5G ESSENCE [6] and the ESA project SATis5 [15];

L. Goratti et al., “Satellite Integration into 5G: Accent on Testbed Implementation and Demonstration Results for 5G Aero Platform Backhauling Use Case” extended abstract accepted, full paper under preparation for submission to Wiley’s IJSCN Special Issue on “Satellite Networks Integration with 5G”, 2020.

9.2 Conclusions The current document is the final SaT5G project deliverable reporting on the activities of the 5G test bed led by Zodiac Inflight Innovations for the SaT5G Use Case 4 “5G Moving Platform backhaul”, specifically implementing the SaT5G backhaul architecture option. Since ZII is a worldwide leading company that supplies Inflight Entertainment and Connectivity (IFEC) systems to airlines and aircraft manufacturers, the test bed focused on the aviation vertical sector and was participated by the world leading satellite operator SES offering unique combined GEO-MEO-Terrestrial service capabilities, the satellite ground segment vendor Gilat, the mobile core network provider Quortus, the content delivery service Broadpeak and the research centre i2CAT for satellite – terrestrial resource coordination.

The ZII test bed demonstrated a 5G prototype IFEC system that can leverage on the 5G technological features to evolve from the current Wi-Fi only approach available in the market. During the course of the SaT5G project, the partners of the ZII test bed went through the test bed design phase during which strategic decisions were made to lead the test bed to successful maturity. During the execution phase, the test bed partners worked as a team to deliver the test bed as the playground where virtualised services can be deployed. As such, the ZII test bed revisited the de facto GEO satellite backhaul connectivity that was implemented as a virtualised service, likewise the mobile core and caching service for content delivery.

The ZII test bed successfully validated the MEO satellite backhaul connectivity in which the complexity of the satellite handover process was tackled with the innovative MEO Booster technology. To complete the activities, the ZII test bed trials made use of the 5G mobile core as well as of a 4G mobile core with control and user plane separation. Since all services were managed through a single OSS layer, and their deployment is not only extremely fast (in the order of minutes in case the system is deployed from the scratch) but also the deployment is repeatable for different airlines, aircraft manufacturers and airplane models, we may conclude that the 5G ZII test bed stands for both an evolutionary and disruptive approach to airplanes connectivity as a whole.

9.3 Next Steps The prototype 5G technology developed for the ZII test bed lends itself to future developments and adaptations tailored to the market segment addressed by the test bed partners. In the aviation vertical market, a new generation of inflight connectivity can be developed inside the cabin and for ground connectivity relying on combining different satellite backhaul technologies. The expectation is to boost market competition, open to a faster time-to-market, enrich the services portfolio and ultimately lower the overall costs associated to this market segment. Such activities were reported already in the SaT5G deliverable “D6.7: Exploitation Activity Report” [16].

SaT5G (761413) D5.2/D5.4 March 2020

of 108

10 References

[1] 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.

[2] “SaT5G Project,” [Online]. Available: https://www.sat5g-project.eu/.

[3] B. Evans (Editor), “Plan for tes bed Architecture Designs, Test Specifications and Trials Scheduling,” SaT5G, 2018.

[4] ETSI, “ETSI GS NFV-MAN 001 V1.1.1,” 2014-12.

[5] 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.

[6] 5G PPP, “H2020 5G ESSENCE,” OTE, [Online]. Available: https://www.5g-essence-h2020.eu/Default.aspx.

[7] M. Kavanagh (Editor), “Virtualisation of Satcom Components - Analysis, Designa nd Proof of Concepts,” SaT5G, Januray 2020.

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

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

[10] J. S. Choi, ““Hierarchical distributed orchestration framework for multi-domain SDTNs”,” Journal of Optical Communication and Networking, vol. 9, pp. 1125 - 1135, 2017.

[11] “Telecommunication management; Management concept, architecture and requirements for mobile networks that include virtualized network functions, 3GPP specification 28.500, Release 14”.

[12] “H2020 Euro-5g, D2.4: “Intermediate report on programme progress and KPIs”.

[13] Fraunhofer Fokus, “Open5GCore,” Faunhofer Fokus, [Online]. Available: https://www.open5gcore.org/ .

[14] H. Saarnisari (Editor), “D6.5: Dissemination Activity report,” SaT5G, 2019.

[15] “SATis5,” [Online]. Available: https://satis5.eurescom.eu.

[16] S. Watts (Editor), “D6.7: Exploitation Activity Report,” SaT5G, 2019.

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

[18] K. Liolis (Editor), “Satellite Reference Use Cases and Scenarios for eMBB,” SaT5G, 2017.

SaT5G (761413) D5.2/D5.4 March 2020 Satellite and ... · Demonstration of Mobile Backhaul Scenario...

Documents

Transcript of SaT5G (761413) D5.2/D5.4 March 2020 Satellite and ... · Demonstration of Mobile Backhaul Scenario...