sat5g (761413) d3.3 december 2018 satellite and ... · sat5g (761413) d3.3 december 2018 d3.3...

SaT5G (761413) D3.3 December 2018

D3.3

Integral end-to-end service delivery architecture

Topic ICT-07-2017

Project Title Satellite and Terrestrial Network for 5G

Project Number 761413

Project Acronym SaT5G

Contractual Delivery Date M14

Actual Delivery Date 19 December 2018

Contributing WP WP3.4

Project Start Date 1 June 2017

Project Duration 30 months

Dissemination Level PU

Editor TNO

Contributors TNO, i2CAT, OULU

Satellite and Terrestrial

Network for 5G

SaT5G (761413) D3.3 December 2018

of 60

Document History

Version Date Modifications Source

00.01 30/10/2017 Document creation TNO

00.02 16/03/2018 Rewrite of table of content TNO

00.03 25/03/2018 Topics and comments added GILAT

00.04 28/03/2018 Moved Section 6.1 to 4.1 and added chapter champions TNO

00.05 27/05/2018 Added text to Section 4.1, added architecture options to Chapter 4, added text to new Section 4.2 and 4.3.

GILAT

00.06 08/06/2018 Restructuring Chapter 4 TNO

0.2 31/08/2018 Restructuring of document, new text in Section 1.1 on Document context, addition of framework for chapter 7 on Security,

TNO

0.7 11/10/2018 Restructuring of document (a.o. removal of old sections 4.1, 4.2. and 4.3), new text to Section 2.1, new text in Chapter 3

TNO

0.9 18/10/2018 New text in Chapter 6, new text in Chapter 7 TNO

0.10 18/10/2018 New text in Section 2.3, new text in Section 4.2 i2CAT

OULU

0.11 18/10/2018 New text in Chapter 5 TNO

0.12 23/10/2018 New text in Section 2.2 TNO



0.16 13/11/2018 Review Avanti

0.20 23/11/2018 Completion of Executive Summary, Completion of Chapter 1 (Introduction), Update of Chapter 3, Update of Section 6.1, Completion of Chapter 8 (Conclusions), Completion of Chapter 9 (References), Editorial updates (cross-references, captions, numbering, etc.)

TNO

0.21 26/11/2018 References added to Section 4.2 OULU

0.22 26/11/2018 Completion of Acronym List TNO

0.24 26/11/2018 Reference added to Section 2.3 and Section 4.2 i2CAT

0.26 27/11/2018 Document history completed, document presented for final review

TNO

0.31 17/12/2018 All review comments processed TNO

1.0 19/12/2018 Final version TNO

SaT5G (761413) D3.3 December 2018

of 60

Contributors

Name Organisation Contributions include

Iko Keesmaat TNO Editor

Floris Drijver TNO Section 2.1, Section 2.2, Section 2.4

Wieger IJntema TNO Section 4.1

Pouria Sayyad Khodashenas

i2CAT Section 2.3, Section 4.2 first part

Muhammad Arif OULU Section 4.2 second part

SaT5G (761413) D3.3 December 2018

of 60

Table of Contents

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

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

List of Acronyms ...................................................................................................................................... 8

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

1 Introduction .................................................................................................................................... 12

1.1 Document context ................................................................................................................. 12

1.2 Relation to other Work Packages.......................................................................................... 13

1.3 Document organization ......................................................................................................... 14

2 Slicing, virtualisation, SDN, and NVF ............................................................................................ 15

2.1 Network slicing in 3GPP ........................................................................................................ 15

2.1.1 Introduction to network slicing ........................................................................................... 15

2.1.2 Network slicing in 3GPP .................................................................................................... 15

2.1.3 Setting up and connecting to a network slice .................................................................... 17

2.1.4 Roaming ............................................................................................................................ 25

2.1.5 Summary ........................................................................................................................... 25

2.2 Network virtualisation ............................................................................................................ 25

2.2.1 Introduction to hardware virtualisation .............................................................................. 25

2.2.2 Network virtualisation ........................................................................................................ 25

2.3 ETSI Network Function Virtualization (NFV) ......................................................................... 27

2.4 Software-Defined Networking (SDN) .................................................................................... 30

2.4.1 Introduction to SDN ........................................................................................................... 30

2.4.2 SDN architecture ............................................................................................................... 30

2.4.3 SDN control plane ............................................................................................................. 31

2.4.4 The evolution of the SDN architecture .............................................................................. 32

3 Advanced networking in integrated satellite 5G networks ............................................................. 33

3.1 Advanced networking by satellite networks as transport network ........................................ 33

3.1.1 Support of MNO network slicing by basic IP technology .................................................. 33

3.1.2 Support of MNO network slicing by ‘pipes’ ....................................................................... 33

3.2 Implementation options for ‘pipes’......................................................................................... 34

3.2.1 Implementation of ‘pipes’ by basic IP technology ............................................................. 34

3.2.2 Implementation of ‘pipes’ by standard 5G slicing technique ............................................. 34

3.2.3 Implementation of ‘pipes’ by extended 5G slicing and SDN ............................................. 35

3.3 Advanced networking by satellite networks in other scenarios ............................................. 36

3.4 Application of other advanced networking concept in satellite networks .............................. 36

4 Management and orchestration ..................................................................................................... 38

4.1 Network slice management in 3GPP .................................................................................... 38

4.1.1 Management framework ................................................................................................... 39

4.1.2 Interaction with NFV-MANO .............................................................................................. 40

4.1.3 Interaction with a TN domain manager ............................................................................. 41

SaT5G (761413) D3.3 December 2018

of 60

4.2 ETSI MANO ........................................................................................................................... 42

5 Management and orchestration in integrated satellite 5G networks ............................................. 47

5.1 Management and orchestration in satellite networks as transport networks ........................ 47

5.2 Combined MNO and SNO management and orchestration ................................................. 47

5.3 Management and orchestration in other scenarios ............................................................... 48

6 End-to-end QoS ............................................................................................................................. 51

6.1 Backhaul QoS Awareness .................................................................................................... 51

6.2 Backhaul traffic management................................................................................................ 52

7 Security .......................................................................................................................................... 53

7.1 SaT5G network architectures and use cases ....................................................................... 53

7.2 Parties/domains and associated trust models ...................................................................... 53

7.3 Security aspects .................................................................................................................... 54

8 Conclusions ................................................................................................................................... 56

9 References ..................................................................................................................................... 58

SaT5G (761413) D3.3 December 2018

of 60

List of Figures

Figure 1-1: WP3 Strategy approach and SWP3.x interaction ............................................................... 13 Figure 2-1: A UE is connected to slice a and slice c. ............................................................................ 15 Figure 2-2: Requesting access to certain network slices ...................................................................... 18 Figure 2-3: AMF selection flow. ............................................................................................................ 19 Figure 2-4: Core network sub-chart describing the core network and slice selection procedure. ........ 21 Figure 2-5: UE context establishment. .................................................................................................. 22 Figure 2-6: PDU session establishment ................................................................................................ 23 Figure 2-7: NG handover. Source: TS 38.300 [3]. ................................................................................ 24 Figure 2-8: Xn handover. Source: TS 38.300 [3]. ................................................................................. 24 Figure 2-9: L3 tunnelling with GRE tunnel. ........................................................................................... 26 Figure 2-10: L2 tunnelling with VXLAN. ................................................................................................ 26 Figure 2-11: Three internal network virtualisation approaches using vNICs. Source: [5]. .................... 27 Figure 2-12: Mapping between 3GPP management reference model and ETSI NFV MANO ............. 29 Figure 2-13: The SDN architecture 1.0 from ONF. ............................................................................... 30 Figure 2-14: A distributed or horizontal SDN control architecture. ....................................................... 31 Figure 2-15: A hierarchical SDN control architecture. .......................................................................... 32 Figure 3-1: MNO network slicing supported by basic IP connectivity ................................................... 33 Figure 3-2: MNO network slicing supported by 'pipes' .......................................................................... 34 Figure 3-3: Slice as implementation of 'pipe' ........................................................................................ 35 Figure 3-4: Extended slice as implementation of 'pipe' ......................................................................... 36 Figure 4-1: Relation between Network Slice and Network Slice Instances (NSI). Source: TS 28.530 [25] .............................................................................................................................................................. 38 Figure 4-2: Relation between NSSIs and NSIs. Source: TS 28.530 [25] ............................................. 39 Figure 4-3: Management service with service interface. Source: TS 28.533 [26] ................................ 39 Figure 4-4: Relation of Management Services to Management Functions. Source: TS 28.533 [26] ... 40 Figure 4-5: Message flows between consumers and producers. Source: TS 28.533 [26] ................... 40 Figure 4-6: Example a way a 3GPP management system can be connected to an NFV-MANO system. Source: TS 28.533 [26] ......................................................................................................................... 41 Figure 4-7: A possible interaction with a TN manager. Source: TS 28.533 [26] ................................... 42 Figure 4-8: ETSI reference architecture for a NFV Management and Orchestrator system ................ 43 Figure 4-9: Example deployment of ETSI compliant MANO ................................................................. 44 Figure 4-10: Message exchange between the NFVO-VNFM and the EMS from deploying and launching the NSD to the execution of lifecycle events [48].................................................................................. 45 Figure 4-11: SOLOO3 APIs execution of the lifecycle events [50] ....................................................... 46 Figure 5-1: Hierarchical management and orchestration ...................................................................... 48 Figure 5-2: Independent management and orchestration ..................................................................... 49 Figure 5-3: Integrated management and orchestration ........................................................................ 49 Figure 6-1: QoS architecture. Source: 23.501 [2] ................................................................................. 51 Figure 7-1: Domains of the 5G security architecture from 5G-ENSURE. Source: [51] ........................ 54

SaT5G (761413) D3.3 December 2018

of 60

List of Tables

Table 2-1: Standardised SSTs. Source: 3GPP TS 23.501 [2]. ............................................................. 16

SaT5G (761413) D3.3 December 2018

of 60

List of Acronyms

3GPP 3rd Generation Partnership Project 3P 3rd Party 5GC 5G Core Network 5GCN 5G Core Network 5QI 5G QoS Identifier A-CPI Application-Controller Plane Interface AF Application Function AMF Access and Mobility Function API Application Programming Interface AS Access Stratum AT3S Access Traffic Steering, Switching, and Splitting AUSF Authentication Server Function BSS Business Support System BT3S Backhaul Traffic Steering, Switching, and Splitting CapEx Capital Expenditures CDPI Control-Data-Plane Interface CM Configuration Management CN Core Network CPU Central Processing Unit CS Communication Service CSC Communication Service Customer CSP Communication Service Provider D-CPI Control-Data-Plane Interface DL Down Link DN Data Network DRB Data Radio Bearers DRM Digital Rights Management DSL Digital Subscriber Line eMBB Enhanced Mobile Broadband EMS Elemental Management Systems EPC Evolved Packet Core ETSI European Telecommunications Standards

Institute FM Fault management gNB gNodeB GRE Generic Routing Encapsulation GUAMI Globally Unique AMF ID HPLMN Home Public Land Mobile Network HSS Home Subscriber Server IAB Integrated Access Backhaul IEEE Institute of Electrical and Electronics Engineers IFA Interfaces and Architecture IM Identity Module IP Internet Protocol IPS Internet Protocol Service ISG Industry Specification Group IWF Inter-Working Function L2 OSI layer 2 L2TP Layer 2 tunnelling protocol L3 OSI layer 3 LCM Life Cycle Management MANO Management and organization ME Mobile Equipment MEHW Mobile Equipment HardWare MF Management Function MIoT Massive IoT

SaT5G (761413) D3.3 December 2018

of 60

MME Mobility Management Entity MNO Mobile Network Operator N3IWF Non 3GPP Inter-Working Function NAS Non-Access Stratum NBI Northbound Interface NE Network Entity NF Network Function NFMF NF Management function NFV Network Function Virtualisation NFVI NFV Infrastructure NFVO NFV Orchestrator NG Next Generation NG-RAN Next Generation RAN NM Network Management NMS Network Management System NOP Network Operator NRF NF Repository Function NS Network Services NSD Network Service Descriptor NSI Network Slice Instance NSS Network Services NSSAI Network Slice Selection Assistance Information NSSF Network Slice Selection Function NSSI Network Slice Subnet Instance NSSMF Network Slice Subnet Management Functions NTN Non-terrestrial networks ONAP Open Networking Automation Platform ONF Open Networking Foundation OpEx Operating Expenses OSM Open Source MANO OSS Operations Support System PCF Policy Control Function PDR Packet Detection Rule PDU Protocol Data Unit PEP Performance Enhancing Proxy PLMN Public Land Mobile Network PM Performance Management PNF Physical Network Functions pNIC Physical Network Interface Card POP Point Of Presence pSwitch Physical Switch QFI QoS Flow ID QoS Quality of Service RAN Radio Access Network RAT Radio Access Technology REST Representational state transfer RRC Radio Resource Control SA Service and System Aspects SaT5G Satellite and Terrestrial Network for 5G SD Slice Differentiator SDN Software-Defined Networking SDNO SDN Orchestrator SeGW Security Gateway SLA Service Level Agreement SMF Session Management Function SNO Satellite Network Operator S-NSSAI Single Network Slice Selection Assistance

Information SOHO Small Home Office SOL ETSI Solutions Working Group

SaT5G (761413) D3.3 December 2018

of 60

SPGW Serving Gateway/PDN Gateway SST Slice Service Type TCP Transmission Control Protocol TMSI Temporary Mobile Subscriber Identity TN Transport Network TOSCA Topology and Orchestration Specification for

Cloud Applications TSG-SA 3GPP Service and System Aspects technical

Specifications UC Use Case UDM Unified Data Management UE User Equipment UICC Universal Integrated Circuit Card UL Uplink UPF User Plane Function URLLC Ultra-Reliable Low-Latency Communication USIM Universal Subscriber Identity Module VEPA Virtual Ethernet Port Aggregator VIM Virtualized Infrastructure Managers VL Virtual Links VLAN Virtual Local Area Network VLD Virtual Link Descriptor VM Virtual Machine VMM Virtual Machine Monitor VNF Virtual Network Function VNFM VNF Manager vNIC Virtual NIC VPLMN Visited Public Land Mobile Network VPN Virtual Private Network vSwitch Virtual Switch VXLAN Virtual Extensible LAN

SaT5G (761413) D3.3 December 2018

of 60

Executive Summary

In this document end-to-end service delivery in an integrated satellite 5G network has been investigated from the following perspectives:

Control perspective;

Management and orchestration perspective.

The control perspective of end-to-end service delivery concerns the behaviour of the (integrated satellite 5G) network that provides the actual connectivity end-to-end. It can be associated with the millisecond-to-second timescale. In the context of this document the following two topics have been investigated in this perspective:

The use of network slicing and virtualisation in an integrated satellite 5G network;

The handling of high latency satellite connections in an integrated satellite 5G network.

The management and orchestration perspective of end-to-end service delivery concerns the handling of network slicing as preparation for the actual connectivity end-to-end. It can be associated with the minute-to-hour timescale (orchestration), or the day-to-month timescale (management). In the context of this document the following topics have been investigated in this perspective:

The use of standardized method for management and orchestration as defined by 3GPP SA5 and by ETSI NVF, i.e. ETSI MANO;

The interaction between the management and orchestration of the Mobile Network Operator (MNO) and the Satellite Network Operator (SNO).

In addition to the above a high-level view on security in integrated satellite 5G networks has been presented.

Input for this deliverable has come from WP2 and WP3.1:

WP2 has provided information about use cases and security requirements as input for the investigations on security.

WP3.1 has provided the basic network architectures that have guided the majority of the work in this deliverable.

The major observations from this deliverable are the following:

Network slicing in satellite networks in integrated satellite 5G networks may be useful, but is not needed in all use cases, for instance in case the satellite network is used as transport network serving a single terrestrial mobile network operator. In this case IP routing functionality or tunnelling support may be the only required functionality in the satellite network.

The standardized concept of network slicing may have to be extended in order to have suitable support by satellite networks to mobile 5G networks. The extension required would be the inclusion of the satellite terminal in the extended slice functionality.

Management and orchestration can be based on standardized approaches (for example, from 3GPP and ETSI), but in general in the area much is left open for proprietary implementation. Depending on the underlying network architectures different interaction models between Mobile Network Operator management and orchestration and Satellite Network Operator management and orchestration are applicable: hierarchical for satellite network as transport networks for backhaul, independent for direct satellite access networks, and integrated for tightly integrated satellite 5G networks.

Mobile 5G networks must be made aware of the (potentially dynamically changing) Quality of Service limitations (in particular – but not only – the high latency) resulting from the use of satellite backhaul. This has been identified as a standardization gap and has resulted in appropriate actions towards standardization bodies (in particular towards 3GPP).

Some of the security mechanisms (such as encryption of backhaul connections) may hamper the effective use of satellite connections (for example, it may hamper acceleration techniques and the proper handling of Quality of Service).

SaT5G (761413) D3.3 December 2018

of 60

1 Introduction

1.1 Document context This deliverable will provide an Integral end-to-end service delivery architecture for integrated satellite 5G networks (where satellite networks are integrated with 5G terrestrial mobile networks) based on the architecture scenarios described in SaT5G deliverable D3.1.

Traditionally service delivery can be viewed from the following perspectives:

Control, and

Management.

Service delivery on control level comprises activities with short durations (in ms to s ranges), e.g. the setup and release of (on-demand) connections and the (self-healing) reorganization of networks in case of congestion and outages, e.g. by means of routing protocols, Software-Defined Networking (SDN), or other self-organization techniques.

Service delivery on management level comprises activities with longer duration (in day to month ranges), e.g. the deployment of new network elements, and the capacity extension of (physical) links.

With the advent of virtual networks and network slicing a third perspective on service delivery has come into existence:

Orchestration.

Service delivery on the orchestration level comprises activities with intermediate duration (in minute to hour ranges), e.g. the creation and activation of network slices and the instantiation/configuration of virtual machines and virtual network infrastructure1.

Within integrated satellite 5G networks end-to-end service delivery relates to service delivery over the whole network chain including both MNOs (mobile network operators) and SNOs (satellite network operators) from User Equipment (UE) via Radio Access Network (RAN) via terrestrial link or via satellite link (including satellite terminals, satellites and satellite ground stations), via Core Networks (CN) to Data Networks (DN).

On the control level service delivery is mostly governed by standardized interfaces and functions. In the context of integrated satellite 5G networks, however, the following aspects require attention:

Connection setup with 5G Quality of Service (QoS) requirements potentially making use of satellite links; special attention shall be given to mechanisms to provide QoS awareness from the lower layers (e.g. satellite layer) to the 3GPP network, e.g. in order to adapt the QoS indications for connections traversing high latency satellite links;

Traffic steering in case of a hybrid satellite and terrestrial backhaul network.

On the management and orchestration level service delivery is mostly concerned with the provisioning, deployment, and maintenance of networks and network slices. In the context of integrated satellite 5G networks, the following aspects require attention:

Within 3GPP, connectivity between 3GPP Network Functions and Network Nodes is considered as Transport Network (TN) but this is mostly out-of-scope of 3GPP. In integrated satellite 5G networks, however, some TN links are provided by satellite links, which may have properties that are considerably different from ordinary terrestrial TN links (e.g. with respect to latency, fluctuating QoS, etc). Moreover satellite TN links may be built using 5G 3GPP technology. In the light of this we need to investigate the options for incorporating satellite networks in 5G 3GPP networks that may make use of network slicing. Also the use of ETSI NFVs approach for virtualizing network functions needs to be taken into account.

Part of the aspects related to end-to-end service delivery is concerned with security. Security, however, is related to all three levels of service delivery:

1 In [51] one of the performance KPIs is the reduction of the average service creation time cycle from 90 hours to 90 minutes.

SaT5G (761413) D3.3 December 2018

of 60

Security on control level may be concerned with authentication, integrity protection, and encryption of connections.

Security on orchestration level may be concerned with security requirements put on network slicing, e.g. on the isolation of network slices, or on the slice-specific handling of security.

Security on management level may be concerned with secure access to network management, e.g. for 3rd party access.

1.2 Relation to other Work Packages The relation of the work in this deliverable to the work performed in other Work Packages is illustrated in the diagram depicted in Figure 1-1 below noting that this deliverable reports on the work undertaken in WP3.4 “End-to-end Service delivery”.

Figure 1-1: WP3 Strategy approach and SWP3.x interaction

As can be seen in Figure 1-1:

The reference satellite network architecture described in the WP3.1 deliverable D3.1 has been used as input for the work in this deliverable;

The use cases described in the WP2.1 deliverable D2.1 and the requirements described in the WP2.3 and WP2.4 deliverable D2.2 have been used in this document in Chapter 7 describing security aspects;

The work in this deliverable can be used as input for the work in WP4.1, WP4.2, WP4.3, and WP4.5, and potentially in WP4.4;

During the creation of this deliverable standardization gaps (related to 3GPP) have been identified and these have resulted in work done as part of WP6.2, i.e. writing of contributions and defending them in 3GPP meetings.

SaT5G (761413) D3.3 December 2018

of 60

1.3 Document organization Chapter 2 describes a number of advanced networking concepts such as Slicing, Virtualisation, Software-Defined Networking (SDN), and Network Function Virtualisation (NFV) that are useful for the end-to-end service delivery in integrated satellite 5G networks. In Chapter 3 the application of the above concepts to integrated satellite 5G networks is discussed, with a focus on the use of network slicing in satellite networks. Management and orchestration of networks and networks slicing is addressed in Chapter 3.4. It application to integrated satellite 5G network architectures is addressed in Chapter 5. End-to-end QoS handling in integrated satellite 5G networks is addressed in Chapter 6. High level security aspects of integrated satellite 5G networks are addressed in Chapter 7.

SaT5G (761413) D3.3 December 2018

of 60

2 Slicing, virtualisation, SDN, and NVF

In this chapter a number of advanced networking concepts are discussed without specifically referring to their application in the satellite domain or their application in an integrated satellite 5G architecture. This will be discussed in the next chapter.

2.1 Network slicing in 3GPP The network slicing concepts presented in [1] are defined and standardised in several 3GPP standardisation documents. The main goal of this section is to describe and explain these standardised concepts in detail. A first introduction to network slicing is provided in Section 2.1.1, followed by Section 2.1.2, where a high-level introduction is given to network slicing in a 3GPP context. Subsequently in Section 2.1.3, a detailed description is provided covering the main steps necessary to connect a UE to a certain (set of) network slice(s). Section 2.1.4 covers a roaming scenario where network slicing is used by a UE in foreign network. Finally, Section 2.1.5 summarises the most important concepts of network slicing in 3GPP.

2.1.1 Introduction to network slicing A 5G network may contain one or multiple network slices which allows the creation of multiple isolated virtual networks on top of the physical network infrastructure. A UE may request access to a network slice which is optimised for a specific traffic type or application. A slice may, for example, be optimised for ultra-reliable low latency communications, massive IoT or for high data rate traffic.

The use of multiple network slices requires the network to reserve sufficient resources for each specific slice instance. In the RAN this could be achieved by allocating physical radio resources to specific network slices, which thereby guarantees slice-specific RAN performance requirements. In the core network a network slice instance may use an isolated set of logical network functions which are provisioned for this specific network slice, combined with logical network functions which are shared between multiple network slice instances. The isolated slice-specific logical network functions should enforce the slice performance requirements defined for the core network, such as QoS, latency, security aspects, etc. This architecture is graphically illustrated in Figure 2-1, where a UE is shown that is connected to network slice ‘a’ and network slice ‘c’.

UE(S-NSSAI = a & c)

NSSF UDMAMF

NEF NRFAUSF

RAN

S-NSSAI = a

S-NSSAI = b

S-NSSAI = c

S-NSSAI = c

SMF

UPF

PCF

AFS-NSSAI = b

SMF

UPF

PCF

AFS-NSSAI = a

SMF

UPF

PCF

AF

CN

Figure 2-1: A UE is connected to slice a and slice c.

2.1.2 Network slicing in 3GPP Network slicing is addressed and defined in multiple 3GPP standards related to the 5G system architecture. In this section, the standardisation efforts on both the 5G core network, as well as on the 5G NG radio and NG RAN system design are introduced.

SaT5G (761413) D3.3 December 2018

of 60

2.1.2.1 Network slicing from a 3GPP core-network perspective 3GPP specification TS 23.501 [2] describes the main architecture for the 5G system and therefore also covers the network functions a 5G core network should support to allow the use of network slicing. According to this document, a network slice is only defined in a single PLMN, and every slice should contain the 5G core network user plane and control plane functions as described in clause 5.15 of [2].

Individual slice types are identified by the so-called ‘Single Network Slice Selection Assistance Information’ (S-NSSAI), which is composed out of two subparts, the Slice Service Type (SST) and Slice differentiator (SD). The SST identifies the specific slice type with its specific features and services, while the SD can be used to separate multiple slice instances with equal SST-identifiers. Network operators are free to create and use their own SSTs but may also choose to support one or multiple standardised SSTs shown in Table 2-1. Allowing the use of one of the standardised SSTs may help to simplify roaming scenarios, where users visit a foreign PLMN which may not support or recognise the S-NSSAIs from the user’s home PLMN.

Table 2-1: Standardised SSTs. Source: 3GPP TS 23.501 [2].

Slice/Service type SST value

Characteristics.

eMBB

1 Slice suitable for the handling of 5G-enhanced Mobile Broadband.

URLLC 2 Slice suitable for the handling of ultra-reliable low latency communications.

MIoT 3 Slice suitable for the handling of massive IoT.

The S-NSSAIs can be grouped into four main NSSAI-sets:

Subscribed NSSAI: The home PLMN keeps track of specific subscription information of the UE. In terms of network slicing, the home PLMN should store to which S-NSSAI(s) the user is subscribed. Moreover, this information should also include one or more default S-NSSAIs. When a UE does not specify any valid S-NSSAI(s) during the initial registration to the network, these default NSSAI(s) should be used.

Configured NSSAI: The set of Configured NSSAI comprises all the S-NSSAIs which are provisioned by the network to the UE. A Configured NSSAI is always related to a single PLMN, unless the Configured NSSAI only comprises the standardised SSTs from Table 2-1. The UE may request a connection to one or more S-NSSAIs from this set during a registration request. This set of configured S-NSSAI may change at any time.

Requested NSSAI: The UE could select one or multiple S-NSSAI(s) from the Configured NSSAI to compose a Requested NSSAI. This Requested NSSAI must be included in AS and NAS signalling. There could be up to eight S-NSSAIs included in these signalling messages.

Allowed NSSAI: The Allowed NSSAI are the S-NSSAI(s) to which the UE is allowed to connect to. This Allowed NSSAI is typically provided by the serving AMF and may be configured in the UE after issuing Requested NSSAI to the network. The UE can use the S-NSSAIs in the Allowed NSSAI for the current registration area and access medium type. These Allowed NSSAI must be stored locally at the UE and should still be available after a UE reboot.

The AMF may also deny a UE access to one or multiple S-NSSAI(s) for the current registration area or for the entire network. The UE must store these S-NSSAI(s) as Rejected NSSAI and may only request these S-NSSAIs again when the network provisions a new Configured NSSAI.

2.1.2.2 Network slicing from a 3GPP radio perspective From a 3GPP radio perspective, network slicing is realised by different scheduling and different L1/L2 configurations [3]. Every slice uses a different PDU session which is explicitly deployed with the specific network slice performance requirements in mind. The exact realisation of this differentiated traffic handling may be implementation-dependent and is not further specified. The specifications related to the radio part of slicing mainly focus on the establishment of these PDU sessions by defining slice selection mechanisms and control message exchanges.

SaT5G (761413) D3.3 December 2018

of 60

2.1.3 Setting up and connecting to a network slice In this section a detailed description is given of the operations required for a UE to connect to a certain (set of) network slice(s). The described procedures from [2] and [3] are combined in this section and based on these documents a number of flow charts have been created in order to visualize and clarify these procedures.

2.1.3.1 Requesting access to network slices After the UE has selected a PLMN, it may indicate its preference to connect to a certain specific network slice. It must be noted that in the current 3GPP specs, the PLMN selection process is not aware of network slices. So, a PLMN is selected first, after which the network slice selection procedure initiates for this specific PLMN. To connect to a network slice, the UE should first consult the Configured NSSAIs which are stored locally and which should be provisioned to the UE by the network. From this set of S-NSSAIs, the UE may select a (set of) network slice(s) to which it wants to connect.

The UE may already have Allowed NSSAI available. All S-NSSAIs in this set have already been authorised on the UE, and the UE may therefore continue with the PDU session establishment phase. If one or more of the S-NSSAIs are not part of this Allowed NSSSAI, they may be added to the Requested NSSAI. This Requested NSSAI should be included in AS and NAS signalling.

Furthermore, the Requested NSSAI should be used during the RRC connection establishment phase between UE and RAN or during the setup phase with the N3IWF (if an untrusted RAN is used). When the NG RAN (or N3IWF) processes the Requested NSSAI, it may be used to select a suitable AMF. An overview of the described process is pictured in Figure 2-2.

SaT5G (761413) D3.3 December 2018

of 60

(A) Requesting acces to network slices

RA

NU

EC

ore

Start (A) – UE wants to

connect to a 5G network

PDU session

establishment

(E)

Consults the

Configured NSSAI

Selects slices of

interest

Are slices in

Allowed NSSAI?

Combine S-NSSAIs

not yet allowed in

Requested NSSAI.

No

All clear. UE can

start using the

slice

Yes

Add Requested

NSSAI to AS and

NAS signaling

Use Requested NSSAI in

RRC connection

establishment

Use Requested NSSAI in

N3IWF (if applicable)

Trusted RAN?

Yes

No

AMF

selection

flow (B)

Verify UE

authorisation to

use a network

slice (C)

Figure 2-2: Requesting access to certain network slices

In Figure 2-2 the process related to ‘AMF selection flow’ is described in Section 2.1.3.2 and the process related to ‘Verify UE authorisation to use a network slice’ is described in Section 2.1.3.3.

2.1.3.2 Selecting an AMF The 5G RAN or N3IWF should now select a suitable AMF (instance) which is allowed to provide access to a certain network slice. When the NG RAN receives the Requested NSSAI, it should first check whether the UE is already associated to a specific AMF. This is done by checking whether the UE included a valid GUAMI/TMSI in the RRC connection establishment messages. When this is the case,

SaT5G (761413) D3.3 December 2018

of 60

the RAN should forward requests to this specific AMF corresponding to the GUAMI/TMSI, if it is reachable.

If no valid GUAMI/TMSI is included in the RRC connection establishment messages, a suitable AMF should be selected based on the included Requested NSSAI. If no Requested NSSAI is included or is invalid, the requests should be forwarded to a preconfigured default AMF. An overview of the AMF selection is included in Figure 2-3.

(B) AMF selection

RA

N

UE included

Requested NSSAI?

Start (B)

UE included GUAMI/TMSI?

Forward to default

AMF

AMF corresponding to

GUAMI/TMSI reachable by

5G-RAN?

Yes

No

Select AMF based on

this requested NSSAI.

Yes

Forward to AMF

corresponding to

GUAMI/TMSI.

Yes

No

No

Figure 2-3: AMF selection flow.

2.1.3.3 Verify UE authorisation to use a network slice instance When a suitable AMF is found, the next step is to verify that the UE is allowed to use the specific network slices it requested in the Requested NSSAI. The AMF accomplishes this by first querying the UDM for subscription information. This information can be used to check that the requested S-NSSAI(s) are in the Subscribed NSSAI from the specific user.

The AMF then queries the local UE context to find if the Allowed NSSAI yet includes the Requested NSSAI, the AMF may then continue to the PDU session establishment phase. If no authorisation is given for the specific requested S-NSSAI, then the AMF may provide the Requested NSSAI as Allowed NSSAI when the AMF is authorised to grant access to these S-NSSAIs. When an AMF is not allowed to perform these actions directly, it should first consult the Network Slice Selection Function (NSSF). The AMF then consults the NSSF by submitting: Requested NSSAI, Subscribed NSSAI, Allowed NSSAI for other access types, PLMN-ID from the SUPI and the current tracking area. The NSSF uses this information to check the subscription of the UE, to select a network slice instance and to create a set of target AMFs which are able to serve the UE with the requested slices. The NSSF then responds to the AMF with the Allowed NSSAI, the mapping of the Allowed NSSAI to the subscribed NSSAI, the target AMF set, the NSI IDs and the rejected NSSAIs (if applicable).

SaT5G (761413) D3.3 December 2018

of 60

The target AMF set is then used by the AMF to find the best AMF for this UE, by querying the NRF with the AMF set. If the NRF returns the current AMF, the AMF may issue the Allowed NSSAI to the UE and continue with the PDU session establishment phase. When the results of the NRF query indicate a different AMF than the current serving AMF, the initial registration request should be forwarded to the new AMF. A detailed overview of the network slice authorisation procedure described above is illustrated in Figure 2-4.

SaT5G (761413) D3.3 December 2018

of 60

(C) Verify that UE is authorized to use certain network slice(s).N

SSF

AM

F

Start (C)

Query UDM for

subscription

information

Verify that

requested NSSAI

in subscribed

NSSAI

Check UE context.

Already contains

allowed NSSAI?

No

Yes

Is AMF allowed to

decide to serve the UE?

Create NSSF query with: Requested NSSAI

Requested NSSAI to Configured NSAI in the

HPLMN mapping.

Subscibed NSSAI, default marked.

Allowed NSSAI for other acces types.

PLMN-ID of SUPI.

Current TA.

Check if AMF can serve

all req. slices.

Yes

Verify that S-NSSAIs are

available in all Tas of

registartion area.

Continue to UE

context

establishment (D)

Send Allowed

NSSAI to UE.

No

Check

subscription.

Select network

slice instance

Select target

AMFs, optionally

Querying the NRF.

Select the allowed

NSSAI for the

current acces type.

Mapping of

allowed S-NSSAI

to subscribed S-

NSSAI (optional)

Determine NRF to

be used to select

NF/serivces.

(optional)

Additional

processing and

mapping in

roaming scenarios.

Receives from NSSF Allowed NSSAI

Mapping of the allowed NSSAI to the

subscribed NSSAI.

Target AMF set.

NRFs to select slices/services in the selected

slice instance.

The NRF to be used to select the AMF from

the AMF set.

The NSI IDs of the specific slice instances

corresponding to specific S-NSSAIs.

The rejected S-NSSAIs.

The mapping of the confgured NSSAI to the

configured NSSAI of the HPLMN.

Send query to NRF

with AMF set, to

find suitable AMF

for UE

AMF from NRF equals

current AMF?Yes

Yes

Forward/reroute registration

request to new AMF. Via RAN or

direct signaling.

No

Figure 2-4: Core network sub-chart describing the core network and slice selection procedure.

SaT5G (761413) D3.3 December 2018

of 60

2.1.3.4 UE context establishment When the AMF is selected, and the UE is authorised to use certain Allowed NSSAIs, the AMF may initiate the UE context establishment in the NG RAN.

The AMF initiates the UE context establishment by sending an initial context setup request to the NG RAN, where a PDU session resource description is provided per S-NSSAI. When the NG RAN receives the request, it allocates PDU-resources to the relevant network slices and creates and sends an initial context response message to the AMF. This completes the UE context establishment procedure, which is illustrated in Figure 2-5.

(D) UE context establishment

RA

NA

MF

Start (D)

AMF sends Initial context

setup request to NG RAN,

with:

- Allowed NSSAI

- PDU session resource

description per S-NSSAI

NG RAN establishes UE

context.

NG RAN allocates PDU

resources to relevant

Network slices.

NG RAN sends initial context

response message to AMF.

To confirm successful

reception.

UE may

establish PDU

sessions (E)

UE context

established in AMF

Figure 2-5: UE context establishment.

2.1.3.5 PDU session establishment When the UE context is established, the UE may request the setup of PDU sessions. Every network slice or S-NSSAI should be associated to a separate PDU session. Thus, the process below should be applied for every requested S-NSSAI individually.

When the UE want to set-up a PDU session for a specific network slice, it must send a PDU session establishment request to the AMF. This message should include the S-NSSAI of the network slice where the PDU session should be established. The AMF will then query the NSSF to find a network slice instance and a suitable NRF. This information is then used to query the NRF to instantiate a user plane session with help of a UPF. A PDU session resource set-up request is then sent to the NG RAN, which on its turn issues an RRC reconfiguration request to the UE. The UE may now establish suitable DRBs and confirm the RRC reconfiguration with an RRC reconfiguration complete message. A PDU session request response message is transmitted from NG-RAN to the serving AMF to complete the PDU session establishment. User plane traffic can now be exchanged over the requested network slice. The PDU session establishment procedure can be seen in Figure 2-6.

SaT5G (761413) D3.3 December 2018

of 60

(E) PDU session establishmentR

AN

AM

FU

E

NG RAN sends PDU session

request response to AMF.

AMF receives response.

PDU session

established

(E) UE wants to

initiate a PDU

session

UE sends PDU session

establishment request with

S-NSSAI.

AMF queries NSSF to find:

- Network slice instance

- Suitable NRF

AMF queries NRF to find:

- Suitable SMF

AMF queries SMF to initate a

session with a UPF.

AMF Sends PDU session

resource set-up request

RAN creates RRC

reconfiguration message

UE establishes DRBs for PDU

session

UE sends RRC

reconfiguration complete

message

Figure 2-6: PDU session establishment

2.1.3.6 Mobility When a UE is mobile, handovers may be necessary to serve the UE with the most suitable gNB. Since the 5G network uses network slicing, handovers should also be slice aware. Two different types of slice-aware handovers are specified in TS 38.300 [3], the NG-handover and the Xn-handover.

The main functional difference between these handover types is that the Xn-handover is mostly executed in the NG-RAN over the available Xn interfaces, while the NG/5GC-handover uses the AMF in the 5G core to control the handover procedure.

2.1.3.6.1 In case of a NG/5GC-handover A UE continuously sends radio measurements reports to the serving gNB. A gNB may then conclude that a different gNB may provide better service to this UE, and that a handover may be required. In case the NG handover is used, this is signalled to the AMF, which then issues a handover request to the new target gNB. This message contains the S-NSSAIs and PDU sessions which are currently associated to the UE. The target gNB then responds with a handover request acknowledgement which includes a list of the accepted and rejected PDU-sessions and S-NSSAIs. The AMF then sends a handover command to the current gNB to start the actual execution of the handover. When the handover is complete, the UE and AMF may exchange information on the slice availability in the new registration area corresponding to the new gNB, by sending tracking area update information. The NG handover is graphically illustrated in Figure 2-7.

SaT5G (761413) D3.3 December 2018

of 60

gNB1 in Registration Area 1 AMFUE

Handover Required

UE in active mode with n slices configured at NAS-level and with m PDU Sessions active at AS level

gNB2 in Registration Area 2

Handover preparation from gNB1 to gNB2 triggered

Handover Command

Handover Request (PDU Session+ S-NSSAI List)

Handover Request Ack (list of accepted and failed PDU

Session+ S-NSSAI)

Tracking Area Update (alignment of slices supported in the new RA between UE and network)

Handover Execution

Figure 2-7: NG handover. Source: TS 38.300 [3].

2.1.3.6.2 In case of a Xn handover When a gNB initializes a Xn handover, the handover request is directly sent to the new target gNB which performs an admission control procedure to verify that it can serve the PDU sessions and S-NSSAIs. The new target AMF may then issue the handover request acknowledgement, with the accepted and rejected PDU-sessions and S-NSSAIs. The UE then performs the execution of the handover, after which the new gNB issues a path switch request to inform the AMF of the new gNB the UE is connected to. The AMF then may acknowledge this path switch message. Just as was the case for the NG handover, the UE and AMF may exchange registration area updates, to inform the AMF about slices available in the new registration area. An overview of the Xn handover procedure can be found in Figure 2-8.

gNB1 in Registration Area 1 AMFUE

1. Handover Request (PDU Session + S-NSSAI List)

UE in active mode with n slices configured at NAS-level and with m PDU Sessions active at AS level

gNB2 in Registration Area 2

Slice aware handover preparation from gNB1 to gNB2

triggered

7. Registration Area Update (alignment of slices supported in the new RA between UE and network)

4. Handover Execution

3. Handover Request Ack (List of accepted and rejected PDU Session + S-NSSAI)

5. Path Switch Request

6. Path Switch Request Ack

2. Admission Control

Figure 2-8: Xn handover. Source: TS 38.300 [3].

SaT5G (761413) D3.3 December 2018

of 60

2.1.4 Roaming Until now the discussion on network slicing in this Section 2.1 did not include roaming scenarios, where UEs want to connect to a network slice outside their home PLMN. In this subsection roaming support for network slicing is discussed.

The simplest case will be that a UE only requests access to network slices with standardised S-NSSAIs as discussed in Section 2.1.2.1. Both the home PLMN and the visiting PLMN may support these standardised network slices which reduces the complexity of having to translate S-NSSAI between operators.

When the UE also wants to access network slices which are not known in the visited PLMN, the S-NSSAIs need to be translated to S-NSSAIs which are known in the current network. This can be achieved by, for example, creating service level agreements (SLAs) between operators to support certain NSSAI in their networks. A UE may then also be able to map S-NSSAIs which are only available in the visiting PLMN to the configured NSSAI and subscribed NSSAI in the home PLMN.

2.1.5 Summary In this section a description is given on the main concepts of slicing from a 3GPP perspective by providing a detailed overview of the required steps for a UE to connect to a network slice.

Network slices can be identified by the S-NSSAI which combines a unique slice service type identifier (SST) and a slice differentiator to identify multiple slice instances with the same SST. To connect to a specific network slice, the UE should add the Requested NSSAI during the RRC connection establishment. The NG RAN then should use this information to find an initial AMF. This AMF should then verify whether it can serve the UE by optionally querying the NSSF. Afterwards, for every requested S-NSSAI a PDU session may be initiated by the NG RAN.

If the UE is mobile, a slice aware handover may be performed. Two types of handovers are allowed. The Xn handover is handled primarily in the NG RAN, while the NG handover required the AMF to take control in the handover procedure.

2.2 Network virtualisation

2.2.1 Introduction to hardware virtualisation Hardware virtualisation allows creating one or more virtual machine(s) (VMs) with custom hardware configuration running on real physical hardware. This creates the possibility to run software on specific dedicated virtual physical platforms or to deploy multiple (different) virtual machines on a single host machine.

The platform which is responsible for the management of the VMs running on a host is typically called a hypervisor or virtual machine monitor (VMM). The hypervisor can be used to create or remove virtual machine instances. Examples of hypervisor implementations are: VMware ESXi, Citrix XenServer 5, Microsoft Hyper-V and the popular VirtualBox.

A VM may be assigned to use a specific portion of the resources of the host machine, for example, a specific number of CPUs and a predefined amount of memory. The networking hardware could also be virtual in a VM and may provide connectivity to a physical network or virtual network. The hypervisor can be used for this resource assignment.

2.2.2 Network virtualisation A virtual network comprises multiple virtual nodes and virtual links, which together form a network. The use of network virtualisation has multiple advantages:

- Efficiency and cost reduction: Existing hardware can be used to deploy multiple virtual networks, resulting in a more efficient use of networking hardware. There is, for example, no need for extra hardware when a new network is configured.

- Flexibility: When a new network needs to be deployed, there is no need to move cables between physical ports or to deploy new routers and switches. This all can be accomplished by using software only.

SaT5G (761413) D3.3 December 2018

of 60

- Security: Multiple separated virtual networks can be deployed on top of one physical network. This isolation approach guarantees that only nodes in the same virtual network can exchange information, which may provide extra security.

Virtual networks can be created in many ways and several products exist which try to achieve this goal. These solutions can be divided into two groups, external network virtualisation solution and internal network virtualisation solutions.

2.2.2.1 External network virtualisation External network virtualisation solutions focus on combining or separating multiple physical networks into one or multiple virtual networks. Examples of external network virtualisation technologies are virtual private networking (VPN) and virtual LAN (VLAN).

VPN supports devices to connect to a private network via a public network, by creating a virtual private network. A VPN typically uses L2 or L3 tunnelling/encapsulation to transport traffic over a public network. A tunnel uses a carrier protocol to encapsulate the original packet and to transport it over a (public) transport network. An example L3 tunnelling protocol is GRE [4], which is pictured in Figure 2-9. During the encapsulation phase, the original (blue) packet is encapsulated in the GRE carrier protocol. Since GRE performs L3 tunnelling, the original L2 layer is not included in the encapsulation. The new packet is then tunnelled over a L3 transport network which requires the orange transport headers. When the packet is received, the packet is decapsulated by removing the GRE carrier protocols and transport headers. A new L2 header (black) is added to the original packet.

Figure 2-9: L3 tunnelling with GRE tunnel.

If a virtual network is needed with L2 connectivity, L2TP or VXLAN can be used. The main difference between L2 and L3 tunnelling is that the entire L2 packet is encapsulated in the carrier protocol. The operation of VXLAN can be seen in Figure 2-10 and clearly shows that the original Ethernet header is still present after the decapsulation phase.

Figure 2-10: L2 tunnelling with VXLAN.

In VLAN networks, multiple virtual L2 networks may be virtualised. A VLAN could use the IEEE 802.1Q standard to include a VLAN ID into ethernet frames to differentiate frames belonging to different VLANs. Certain ports on a VLAN enabled switch may be configured to tag all incoming frames with a VLAN tag, which carries the VLAN ID. So-called trunk ports may be used to transport VLAN tagged ethernet frames belonging to multiple VLANs across multiple switches.

2.2.2.2 Internal network virtualisation With internal network virtualisation it is possible to create a network between VMs which may run on the same physical hardware. This type of virtualisation thus supports the creation of a ‘network in a box’.

The main building blocks required are virtual network interface cards (vNICs) and virtual switches, to link multiple VMs together. A VM may be equipped with a vNIC which mimics the exact behaviour of a

SaT5G (761413) D3.3 December 2018

of 60

physical network card. A virtual network may then be built by interconnecting the vNICs. There are multiple ways to accomplish this, but three main approaches are visualised by [5] in Figure 2-11.

Figure 2-11: Three internal network virtualisation approaches using vNICs. Source: [5].

(a) Is the most common approach, where the vNICs are interconnected via a virtual switch (vSwitch). This vSwitch is then connected to the physical NIC (pNIC) of the physical machine (pM). It is typically not possible to directly connect the vNICs to the pNIC since this would require a physical switch to receive and send out the packet on the same interface. Most switches will not allow this, since this could prevent looping behaviour.

(b) The second approach makes use of a specialized pNIC which implements the vNIC and vSwitch functionality, this reduces the software overhead needed in approach (a), since this is offloaded to a pNIC.

(c) The last approach offloads all switching actions required to connect the VNICs to a pSwitch. This solution uses a Virtual Ethernet Port Aggregator (VEPA) which collects all L2 traffic originating from the VMs and forwards this to a specialized pSwitch. The pSwitch provides support for so-called ‘hairpin’ switching which actually does allow forwarding traffic over the incoming interface.

2.3 ETSI Network Function Virtualization (NFV) Currently, telecommunication networks consist on an array of different proprietary hardware devices [6]. In addition, terrestrial and satellite networks are managed by independent systems; where each segment holds its own Network Management System (NMS) and OSS/BSS systems. Launching a new service often means more devices and set-up effort, which involves finding the space and power to accommodate those appliances. However, this has become increasingly difficult [7]. Due to rapid innovation, hardware-based devices now have shorter life, thus making investment return much lower when deploying new services.

In order to address these issues, Network Function Virtualization (NFV) [8] implements network functions into software so that it can run on a range of industry-standard server hardware, which may easily be moved to different locations within the network as needed. NFV focus on reducing the need to install any new equipment. This results in shorter time-to-market deployment of network services, lower CapEx and OpEx, and higher return on investment. In addition, this enables more flexibility to scale up or scale down, and more opportunity to innovate, experiment, test and deploy new services with lower risk.

The virtualization of specific network functions provides a cloud-like view for the management system, adding both the traditional Network Management System (NMS) and the lifecycle service and orchestration functionalities associated to the original cloud-based system. Meanwhile, NFV

SaT5G (761413) D3.3 December 2018

of 60

orchestrators like ETSI Open Source MANO (OSM) [9] or Open Networking Automation Platform (ONAP) [10] provide a solution for management and orchestration of the network resources and services.

Both ETSI MANO and 3GPP standards [11] provide certain amount of specifications that define NFV capabilities by setting requirements and architecture details for hardware and software infrastructure needed to make sure virtualized functions are maintained. This enables features to virtualize and automatize the end-to-end network service platform across access, aggregation, and space segment network domains. Standardized open-source and commercial cloud technologies can be combined to address the following challenges in an integrated satellite 5G network:

Open interfaces to deliver automation, self-service operations and partner integration for high speed and agility. With adaptive automation, service usage drives on-demand resource requirements; triggering operational closed-loop feedback to adjust resources and services to real-time changes;

Intent and event-driven orchestration that guides service and system-wide performance and management;

Personalized services that are easily configured by the end-user at the service or network resource level to fit individual or organization’s requirements;

Dynamic SLA-based resource allocation and provisioning over multiple domains with flexible and dynamic deployable satellite resources;

Lifecycle management as devised in the ETSI MANO framework. Abstraction of the requirements for the provisioning of network services is achieved through resource modelling, in the form of the descriptors (TOSCA [12], ETSI [13]);

Flexible multi-domain management and operation of virtualized satellite and terrestrial functions;

Seamless service provisioning through the automated process and the integrated network management component.

Together these capabilities deliver automated lifecycle management of end-to-end network services from the 5G access network, across the space segment, and through cloud connectivity to on-net global wide cloud services.

To achieve this, ETSI industry Specification Group for NFV (ISG NFV) [14] focuses on several initiatives that include Information modelling, Security Analysis and Management, Reliability and Availability, Policy Management and more.

3GPP also develops a study focused on the NFV management functions and solutions for mobile core networks based on the architectural framework defined by the ETSI NFV ISG. The 3GPP Service and System Aspects technical Specifications Group (TSG-SA) [15] specifies the requirements, architecture and solutions for provisioning and management of the network. Figure 2-12 below showcases the mapping between 3GPP management reference model and ETSI NFV MANO. This model brings the potential of NFV MANO to the 3GPP management system.

SaT5G (761413) D3.3 December 2018

of 60

Figure 2-12: Mapping between 3GPP management reference model and ETSI NFV MANO

Beside network management, NFV enables virtualization of functions and services, mainly using Virtual Network Functions (VNF), Virtual Network Services (NS) and Virtual Links (VL). It virtualizes each single function in current network services. Once virtualized, the virtual network function can be hosted on an industry-standard server. Virtual network functions are the implementation (in software) of a network function (NF), e.g. AMF, UPF, SMF, etc, that can be deployed on a Network Function Virtualisation Infrastructure (NFVI). They are the functional blocks within a network infrastructure that have well-defined external interfaces and well-defined functional behaviour. For VNFs, life cycle operations such as initial deployment, configuration changes, upgrades, scale-in and scale-out are simply software steps that can be fully automated. VNFs can also be chained together and managed in a dynamic and automated fashion, thus resulting in agile on-demand services.

Network services are introduced in the NFV MANO framework in the form of descriptors following a specific data model. It describes the relationship between its network functions and the links that connect all the network functions implemented in the NFVI network. A network service descriptor consist of a template that describes the deployment of a Network Service including service topology (constituent VNFs and the relationships between them: Virtual Links, VNF Forwarding Graphs) as well as network service characteristics such as SLAs and any other artefacts necessary for the network service on-boarding and lifecycle management of its instances.

Virtual links represent a set of connection points along with the connectivity relationship between them and any associated target performance metrics (e.g. bandwidth, latency, QoS). A virtual link uses a virtual link descriptor (VLD) to describe the resource requirements needed for a link between VNFs and endpoint of network service, which can be mapped by various link options that are available in the NFVI. ETSI Open Source MANO defines two types of virtual links:

External virtual link, which defines the connections to the network service endpoints and external VNF interfaces.

Internal virtual link, which defines the connections to the external VNF interfaces and VNF components.

SaT5G (761413) D3.3 December 2018

of 60

2.4 Software-Defined Networking (SDN)

2.4.1 Introduction to SDN The main goal of Software-Defined Networking is to provide interfaces to applications, which allow them to take control over a set of network resources [16]. This is done by transferring the induvial control entities from physical network resources to a (centralised) programmable SDN controller. This allows for a separation of forwarding, traffic processing and control actions into three distinct planes, which are called the application plane, control plane and data plane.

The application plane contains the SDN applications which interface the SDN controller. Network owners can use the application plane to create, program and deploy their own custom network services. The SDN controller itself is part of the control plane and is responsible for translating network requirements, issued by SDN applications, to an actual network configuration. The physical network forwarding hardware itself resides in the data plane, where logical network elements (NEs) are under the authority of one or multiple SDN controllers.

2.4.2 SDN architecture The Open Networking Foundation (ONF) provides a high level SDN architecture [17] which can be seen in Figure 2-13. The architecture is made up out of several components and interfaces, which are grouped into the three main planes.

Figure 2-13: The SDN architecture 1.0 from ONF.

The application plane comprises one or multiple SDN applications defining and issuing certain traffic and service requirements to the network. The applications themselves are built out of custom application logic and should be equipped with a driver for the Northbound Interface (NBI) (also called Application-controller plane interface (A-CPI)), which maintains a connection to the NBI responsible for the communication between application and SDN controller. This NBI is a bidirectional interface and may also supply network state information, statistics and report events from the controller back to the SDN application.

SaT5G (761413) D3.3 December 2018

of 60

The central control plane contains one or more SDN controllers responsible for translating network requirements, issued by an SDN application, to a network configuration. A typical SDN controller therefore has an NBI agent to communicate with the SDN applications over the NBI. This information is then used by the SDN control logic to configure the underlying physical network via the SDN Control-Data-Plane Interface (CDPI/D-CPI). This CDPI is also bidirectional and allows the transmission of control commands to the NEs. The NEs in their turn may also use this interface to advertise their capabilities and to report events and statistics.

Multiple network elements may be managed by a single SDN controller in the SDN data plane. The NEs use a CDPI agent to communicate with the controller. Each NE may contain one or more SDN data paths, which is a logical network device encompassing all or a subpart of the actual physical resources [17].

Administrative and static tasks are part of the yellow Management & Admin block in Figure 2-13. This part handles, for example, the assignment of (fixed) resources to certain users/devices in the network. This block may also be responsible for statically configuring NEs with certain device configurations or initializations. The contracts and service level agreements (SLAs) between service provider and consumer are typically also issued by the Management & Admin functions in the application plane.

2.4.3 SDN control plane In the ideal case, a network should have one centralised SDN controller with network wide awareness and control, but this is typically not realistic due to implementation restrictions. A single centralised controller may, for example, reduce the robustness of the network since it can act as a single point of failure. Other reasons not use a single controller may be related to scalability issues or security constraints. A network may therefore contain several domains and multiple SDN controllers which in some way need to collaborate. Various architectures have been proposed to achieve this goal, such as the hierarchical and distributed control architectures.

2.4.3.1 Distributed or horizontal control architecture In a distributed or horizontal control architecture, multiple controllers share information in a peer-to-peer way to make sure that all controllers keep state of the entire network. This network information is typically shared via an east-west interface between SDN controllers. Numerous solutions exist which implement this distributed architecture such as ONIX [18], HyperFlow [19] and the popular ONOS [20] and OpenDaylight [21] SDN controllers. An example distributed or horizontal control architecture can be seen in Figure 2-14.

Figure 2-14: A distributed or horizontal SDN control architecture.

SaT5G (761413) D3.3 December 2018

of 60

The main advantage of this approach is that all SDN controllers have a network wide view, increasing robustness and improving scalability. A distributed approach suffers from overhead which is required to synchronise this information between SDN controllers to keep a consistent network view.

2.4.3.2 Hierarchical control architecture In a hierarchical approach, there are two types of SDN controllers: a single root controller and multiple local controllers. The root controller has a network wide view and is able to allocate resources in the entire network. An example hierarchical control architecture is depicted in Figure 2-15. The root controller may issue commands to local controllers which only keep track of their own (sub)-domain. Communication is done via a Northbound API defined between the root SDN controller and one or multiple local SDN controllers. The local controller in this case does not keep track of the state of the entire network and therefore should contact the root controller when network wide awareness is needed. This approach may therefore mainly be deployed to increase the scalability of the network. A popular SDN controller which follows this architecture is Kandoo [22].

Figure 2-15: A hierarchical SDN control architecture.

2.4.4 The evolution of the SDN architecture Most of the information in this section is based on the ONF SDN architecture 1.0, published in 2014 [17]. However, in 2016 the ONF published version 1.1 of the SDN architecture with some (minor) conceptual differences [23]. The goal of this document was not to replace the SDN architecture, but only to clarify and extend version 1.0.

In v1.1, for example, the Network Elements (NEs) are renamed to resource groups. This to prevent confusion and to conceptionally generalise the concept of network resources. Moreover, in v1.1 the design is slightly adapted to form a service-oriented architecture instead of a resource-oriented architecture. An exhaustive list of all changes can be found in Appendix C of [23].

SaT5G (761413) D3.3 December 2018

of 60

3 Advanced networking in integrated satellite 5G

networks

In this chapter the application to integrated satellite 5G networks is presented of the advanced network concepts discussed in the previous chapter.

3.1 Advanced networking by satellite networks as transport network

In the scenario where satellite networks are used as transport networks for the backhaul of mobile networks, advanced networking concepts (such as tunnelling, slicing, NFV, and SDN) can be used for supporting slicing used by these mobile networks. In this section the use of various advanced networking concepts are discussed and their applicability for various use cases. From this discussion the need for a (working) concept of ‘pipe’ arises, where a ‘pipe’ is defined as (mutually) isolated capacity controlled tunnel. In the next section a number of implementation options of a ‘pipe’ are discussed based on the more familiar concepts of tunnelling, network slicing and SDN.

3.1.1 Support of MNO network slicing by basic IP technology In case a satellite network is used to provide transport network connectivity for a single MNO, the MNO may be implementing its own slices by using IP tunnelling in its own network. The diagram depicted in Figure 3-1 shows this case, where the SNO network provides transport connectivity and the MNO provides slices to its 5G UEs (over its own 5G RAN and its own 5G CN).

NG-RAN

Sat Ground Station 5GCN

Sat Terminal Satellite

SNO MNO1MNO1

Figure 3-1: MNO network slicing supported by basic IP connectivity

In this case each of the MNO network slices may be using the same IP addresses for its network functions, so the slices need to make use of tunnels. In this implementation option it is assumed that the MNO provides its own IP tunnels and hence the SNO network is only required to provide basic IP connectivity. A more advanced implementation may make use of IP traffic management technology such as DSCP in order to give different priority to the traffic of different MNO slices. The setup and maintenance of the basic IP connectivity in the SNO network – needed for support of MNO slicing – can be controlled from the management and orchestration of the MNO network using the hierarchical MANO approach described in Section 5.2.

Hence, this use case does not require slicing functionality in the satellite network, but nevertheless the satellite network provides support – to some degree – to the MNO slices that are being transported. This slicing support could be based on the NFV virtual link concept and its associated target performance metrics (see Section 2.3) and the concept of QoS awareness (see Section 6.1).

3.1.2 Support of MNO network slicing by ‘pipes’ Network slicing by MNOs may also be supported by more advanced forms of networking. In this section we use the abstract term ‘pipe’ to denote a particular form of tunnelling provided by the SNO network. In addition to basic tunnelling (i.e. IP address isolation) a ‘pipe’ may also provide advanced capacity handling and QoS support if this is needed to support specific (types of) MNO network slicing. The diagram depicted in Figure 3-2 shows this case where the SNO network provides transport connectivity to multiple MNOs and for various (types of) slices used by MNOs. Note that – again – the setup and

SaT5G (761413) D3.3 December 2018

of 60

maintenance of the ‘pipes’ in the SNO network can be controlled by the MNO management and orchestration via the hierarchical MANO setup described in Section 5.2.

Sat Ground Station

SatelliteSat

Terminal

NG-RAN 5GCN

SNO

MNO1MNO1

NG-RAN

MNO2

5GCN

MNO2

SNO pipe

SNO pipe

SNO pipe

Figure 3-2: MNO network slicing supported by 'pipes'

An important reason for the use of ‘pipes’ is the fact that each of the MNO networks may (want to) use the same IP addresses over their transport networks used for backhaul, i.e. over the SNO network. Hence, there is a need to isolate the MNO networks in the SNO network with respect to IP addressing (through some form of tunnelling). Moreover, each MNO network may need specific support for their own slices from the SNO network, which may be provided by using separate SNO ‘pipes’ for certain (sets of) MNO slices. In Section 3.2 a number of possible implementations of ‘pipe’ in the context of satellite networks are discussed.

3.2 Implementation options for ‘pipes’ In this section advanced networking technologies for implementing ‘pipes’ are being discussed.

3.2.1 Implementation of ‘pipes’ by basic IP technology A first possible way of implementing ‘pipes’ is through the use of basic IP technology. In this case some form of IP tunnelling will be used in order to handle the IP address isolation.

In addition to basic tunnelling also IP traffic management techniques, such as DSCP can be used to handle difference in QoS requirements on the various ‘pipes’.

In this case the SNO network does not have to have network slicing functionality in its own network.

3.2.2 Implementation of ‘pipes’ by standard 5G slicing technique A second possible way of implementing ‘pipes’ is through the use of standard 5G slicing techniques.

In case a satellite network is created according to the 3GPP architecture, where the satellite terminal acts as a 5G UE and the satellite ground station acts as a 5G RAN combined with a 5G CN, then this

SaT5G (761413) D3.3 December 2018

of 60

satellite network can be used to provide network slicing according to the way 3GPP has defined this concept (see Section 0). The diagram depicted in Figure 3-3 show this situation.

Sat Ground Station:NG-RAN + 5GCN

Sat Terminal:

5G UE

Satellite

SNO

Sat Terminal:

5G UE

NG-RAN

MNO1

NG-RAN

MNO2

5GCN

MNO1

5GCN

MNO2

Figure 3-3: Slice as implementation of 'pipe'

In this case it is assumed that the SNO network is built in the form of a 5G 3GPP network, i.e. it implements a (physical or virtual) 5G UEs in (one or more) satellite terminals and it implements a 5G RAN and 5G CN in the satellite ground station. For simplicity, the satellite itself is considered to be a simple forwarding element, i.e. we assume a bent pipe architecture.

Traditional 5G slicing in the SNO will provide the SNO 5G UEs with access to SNO slices in the SNO 5G RAN and the SNO 5G CN based on their use of slice identifiers (S-NSSAIs, see Section 2.1). The SNO 5G CN will provide the SNO 5G UEs with IP addresses to be used to access the SNO network.

Based on the 3GPP standardized concept of network slicing as explained in Section 2.1.3, the SNO 5G UEs can access (one or more) network slices, but the SNO 5G UE itself is not extending this slice to its connecting networks. What is needed, however, for the ‘pipe’ functionality is a carrier for the MNO slices from the MNO side of the SNO 5G UE, through the SNO 5G UE, through the SNO 5G RAN and the SNO 5G CN to the MNO 5G CN. As can be seen in the diagram depicted in Figure 3-3 the standardized slice only provides for the part from the SNO side of the SNO 5G UE to the SNO 5G CN.

In this implementation option the solution for extending the slice to a ‘pipe’ is to use individual satellite terminals per SNO ‘pipe’. The individual satellite terminals can be physical ones or they can be virtual ones. The slice extension through the SNO 5G UEs (which in essence is a kind of routing table configuration) can be pre-configured at installation of the terminals or it can configured remotely from the SNO 5G CN by using the new 5G functionality of URSP (UE Route Selection Policy, see [24]) whereby routing policies are downloaded into the terminals.

3.2.3 Implementation of ‘pipes’ by extended 5G slicing and SDN A third possible way of implementing ‘pipes’ is through the use of extended 5G slicing techniques in combination with SDN. This implementation option is not based on 3GPP standards and it uses a different approach for extending the slice through the satellite terminal than in the previous case. The need for this extension has already been explained in Section 3.2.2.

The implementation option is illustrated in Figure 3-4 below. The focus of the implementation option is to control the slice extension through the UE from the core network through the technique of Software-Defined Networking.

SaT5G (761413) D3.3 December 2018

of 60

Sat Ground Station:SDN v_switches & SDN controller

Sat Terminal:

SDN v_switch

Satellite

SNO

Sat Terminal:

SDN v_switch

NG-RAN

MNO1

NG-RAN

MNO2

5GCN

MNO1

5GCN

MNO2

SDN v_switch

SDN v_switch

SDN controller

Figure 3-4: Extended slice as implementation of 'pipe'

SDN-based slice extension is based on the assumption that on the satellite terminal side (virtual or physical) SDN switches are present that are controlled by an SDN controller in the SNO ground station. In this way the flexibility offered by SDN can be used to create the appropriate implementation of the required ‘pipes’.

The realization of the architecture depicted in Figure 3-4 can be based on an ETSI NFV architecture, where each component is supported by an NFVI (Network Function Virtualisation Infrastructure). Note that – although the method is presented as a way to extend 5G slices – the implementation option does not require the implementation of a 5G network architecture in the SNO network. It is sufficient to implement an SDN architecture.

3.3 Advanced networking by satellite networks in other scenarios In the architecture scenarios that use satellite networks for Direct Access or in a Relay architecture (see [1], Section 4.3 and Section 4.4.2, respectively), the satellite network forms an integral part of the MNO (or SNO) network. In those cases the use of network slicing to the end-users need to be supported by the satellite networks in the obvious ways.

In case of Direct Access, the satellite network forms part of the 5G Radio Network (5G RAN). The 5G RAN in that case is therefore part of the complete 5G Network and it needs to support network slicing according to the specification of 3GPP for RAN slicing.

In case of a Relay architecture, again the satellite network forms part of the 5G Radio Network of the MNO and hence is required to support network slicing according the specification of 3GPP for RAN slicing.

3.4 Application of other advanced networking concept in satellite networks

As can be seen from the above analysis only (some form of) network slicing and perhaps (some form of) Software-Defined Networking in the satellite network may be needed to enable integration of satellite networks with 5G terrestrial mobile networks.

This, however, does not imply that other forms of virtualization (e.g. as expressed in the ETSI NFV concepts) are not useful for satellite networks. Virtualization and especially the application of ETSI NFV concepts would certainly be beneficial for satellite networks. They would make satellite networks more flexible and perhaps also lead to reduced costs (by being able to make use of non-specialized hardware). Moreover it would enable automatic management connections by using the hierarchical management and orchestration architecture as described in Section 5.2. The above support for 5G

SaT5G (761413) D3.3 December 2018

of 60

terrestrial networks by satellite networks, however, can also be realized without the full use of all advanced networking concepts. In this light it should be noted that, although not specified in 3GPP documents, the implementation of network slicing in 5G core networks usually is envisioned to be based on ETSI NFV principles.

SaT5G (761413) D3.3 December 2018

of 60

4 Management and orchestration

Management of networks slices will enable the end-to-end delivery of services via satellite-rich 5G networks. According to the slice Life Cycle described in TS 28.530 [25], end-to-end service delivery using network slices consists of:

preparation of network slice creation;

creation and activation of network slices;

fault and performance management of network slices;

supervision and reporting of network slices;

deactivation and deletion of network slices.

3GPP management of network slices may need to interact with management of transport networks (as described in TS 28.530 [25]). Management of transport networks may be based on ETSI’s Management and Orchestration (MANO).

4.1 Network slice management in 3GPP A key feature in 5G networks is the ability to have network slices. This new feature introduces more flexibility to use multiple isolated network slices on a common infrastructure. The management and orchestration of 3GPP networks with network slicing is standardized by the 3GPP SA5 group. This section elaborates on how this management of slices is defined by 3GPP.

The document TS 28.530 [25] from 3GPP explains the management concepts of networks and network slicing. For network slicing two views have been defined, a network view and a management view. In the network view a network slice consist of one or multiple Network Functions (NFs). A Network Slice is defined as: a logical network that provides specific network capabilities and network characteristics. From a management point of view this Network Slice is then seen as a Network Slice Instance (NSI). A NSI is defined as: A set of NF instances and the required resources (e.g. compute, storage and networking resources) which form a deployed Network Slice. The NFs can be Virtual Network Functions (VNFs) or Physical Network Functions (PNFs). The NSI is in the management domain of the Network Operator (NOP). The NOP is able to offer the NSI with or without exposure of internal NSI structures towards a customer.

Figure 4-1: Relation between Network Slice and Network Slice Instances (NSI). Source: TS 28.530 [25]

For management purposes 3GPP also defined a finer grouping of NFs into Network Slice Subnets. A Network Slice Subnet is a representation of the management aspects of a set of Managed Functions and the required resources (e.g. compute, storage and networking resources). An instance of a Network Slice Subnet is called a Network Slice Subnet Instance (NSSI). A NSI can consist of multiple NSSIs. A NSSI can also be shared by multiple NSIs. Note that, an NSSI is only a management concept and

SaT5G (761413) D3.3 December 2018

of 60

defined in the management domain and external parties or control plane view will never know about NSSIs.

Figure 4-2: Relation between NSSIs and NSIs. Source: TS 28.530 [25]

4.1.1 Management framework The 5G management system is adopting a service-based architecture. This architecture is described in detail in TS 28.533 [26]. A management service offers capabilities towards management service consumers. A management service communicates via a standardized service interface.

Figure 4-3: Management service with service interface. Source: TS 28.533 [26]

A management service can consist of three components, components A, B and C. The components of each type are grouped as the following:

A. (Operation/Notification) This is the set of operations related to this Management Service.

B. (Managed object) The management information represented by the information model. For

example: Network resource models.

C. (Managed data) Performance information and Fault information about the managed entity.

Management services can consume or produce service capabilities. Multiple management services can be grouped together in a Management Function (MF). And MFs can consume services from other MFs, MFs can also produces service capabilities towards other MFs.

SaT5G (761413) D3.3 December 2018

of 60

Figure 4-4: Relation of Management Services to Management Functions. Source: TS 28.533 [26]

The basic communication between a management service producer and consumer is based on a request response paradigm. A service consumer requests data and the producer responds to that request. Certain use cases, such as alarm notifications, require a way for notifications messages. A consumer is requesting a subscription from a producer. The producer responds positive if the subscription was successful and notifies the consumer if a certain condition is met.

Management

service consumer

Management

service producer

Subscription request

Subscription Response (positive)

Notification

The condition is met

Notification

The condition is met

Management

service consumer

Management

service producer

request

response

Figure 4-5: Message flows between consumers and producers. Source: TS 28.533 [26]

4.1.2 Interaction with NFV-MANO The 3GPP management system is capable to consume to NFV MANO Interface: Os-Ma-nfvo, Ve-Vnfm-em and Ve-Vnfm-vnf reference points. These interfaces are used for:

- Network Slice or Virtual Network Functions Life Cycle Management (NS/VNF LCM):

TS 28.525 [27], TS 28.526 [28], TS 28.527 [29], TS 28.528 [30]

- Configuration Management (CM): TS 28.510 [31], TS 28.511 [32], TS 28.512 [33], TS 28.513

[34]

- Fault Management (FM): TS 28.515 [35], TS 28.516 [36], TS 28.517 [37], TS 28.518 [38]

- Performance Management (PM): TS 28.520 [39], TS 28.521 [40], TS 28.522 [41], TS 28.523

[42]

SaT5G (761413) D3.3 December 2018

of 60

The operations and information models for each functionality are described in the respective 3GPP technical specification documents.

Figure 4-6: Example a way a 3GPP management system can be connected to an NFV-MANO system. Source: TS 28.533 [26]

4.1.3 Interaction with a TN domain manager If satellite connections are used for a transport network supporting the mobile network, the link limitations could have a big impact on the performance of the mobile network. TS 28.533 [26] has defined an example in the informative annex. In this example it is shown that there could be a TN Domain manager that communicates directly to the 3GPP management system. However the TN Domain manager itself is out of scope of 3GPP. The interface between 3GPP management systems and the TN Domain manager should be in scope of 3GPP, but currently this has not been addressed in 3GPP. This interface is particularly relevant for the SaT5G scenarios in which the satellite network is used as the transport network for backhaul (as described in [1], Section 4.4.1) where a close coordination between the satellite management system and the 3GPP management system is required to provide functionalities as described in [43].

NFV Orchestrator

(NFVO)

VNF Manager(VNFM)

Virtualised Infrastructure

Manager(VIM)

NSSMF

NFV-MANO

PNF VNF

Os-Ma-nfvo

Ve-Vnfm-em

Ve-Vnfm-vnf

Or-Vnfm

Vi-Vnfm

Or-ViNFMF

NSS Management service

NF provisioning service

NF provisioning

service

NF provisioning service

SaT5G (761413) D3.3 December 2018

of 60

Network and Network Slice Management Function

RAN Management Function A

CN Management Function A

RAN Management Function B

MS(s) for CN SubNetwork and NSSI

RAN Management

Function C

CN Management Function B

CN Management Function C

MS(s)For CN NF

TN Domain Manager (out of scope of 3GPP)

MS(s) for RAN SubNetwork and NSSI

MS(s) forCN NF

MS(s) for Network and NSI

Consumer

MS(s) forRAN NF

MS(s) forRAN NF

MS(s) for CN SubNetwork and NSSI

MS(s) for RAN SubNetwork and NSSI

Figure 4-7: A possible interaction with a TN manager. Source: TS 28.533 [26]

4.2 ETSI MANO NFV MANO (network functions virtualization management and orchestration) [13], also called MANO, is an architectural framework for managing and orchestrating virtualized network functions (VNFs) and other software components. The European Telecommunications Standards Institute (ETSI) [44] Industry Specification Group (ISG NFV) defined the MANO architecture to facilitate the deployment and connection of services as they are decoupled from dedicated physical devices and moved to virtual machines (VMs).The next generation management systems will incorporate the administration features of the network and its configuration, such as network slicing instances, subnet instances and so forth.

The next generation networks might be made out of virtualized and non-virtualized network elements and components, where the management of these systems could make use of the management capacities for the virtualized network functions [45]. The management and orchestration of network elements may incorporate the administration of network capacities and resources.

For the management of these virtualized network elements or components, the virtualized resource supporting the network component is orchestrated by the NFV-MANO. The 3GPP network functions are orchestrated by the 3GPP network management functions or system. However, for the management of the non-virtualized network elements, both network function and network resources are managed by 3GPP network management functions.

Because virtual network elements or components can be deployed much faster, mainly in hours rather than months in virtual environments, MANO can reduce time-to-market and confusion by managing and orchestrating resources that include compute, storage, networking, system analytic functions and virtual network functions like routing, firewalls and load balancing.

NFV MANO has three main functional blocks: NFV orchestrators, VNF-specific managers and virtualized infrastructure managers (VIMs) [46]. Together, these blocks are responsible for deploying and connecting functions and services when they are needed throughout the network.

NFV orchestrators basically consist of two layers – service orchestration and resource orchestration –which control the integration of new network services and VNFs into a virtual framework. NFV orchestrators also validate and authorize NFV infrastructure (NFVI) resource requests.

VNF managers oversee the lifecycle of VNF instances which contain specific functions. These managers can also enable other capacities to maintain the lifecycle of the VNF and other features such as scaling or migration.

VIMs control and manage NFV infrastructure, which mainly encompasses compute, storage, network resources.

SaT5G (761413) D3.3 December 2018

of 60

MANO works with templates or data models for standard virtual network functions so users can pick from existing network functions virtualization infrastructure (NFVI) resources to deploy their NFV platform. For NFV MANO to be effective, it must be integrated through application program interfaces (APIs) using existing systems in order to work with multivendor technologies across multiple network domains. Telecommunications providers' network management systems (NMS), including operations, billing and support systems (OSS/BSS) also need to interoperate with MANO. Both telecommunication providers and operators and MANO frameworks need a solid specification in order to map their multiple interfaces or reference points.

ETSI has detailed different NFV-MANO standards and extensions for architectural and functional requirements specifications in the NFV IFA and SOL specifications [13].

Figure 4-8 specifically presents the ETSI reference architecture for a NFV Management and Orchestrator system [13] with all the component interfaces. Each of the connecting interfaces inside and outside of the system follows their own ETSI interface specifications. The picture highlights each of these connections. For example, the orchestrator interface that connects with operators OSS/BSS, called Os-Ma-Nfvo reference point, is defined in the SOL005 API specifications. This specification elaborates the API conventions, requirements and all the RESTful protocol specifications and data models.

Figure 4-8: ETSI reference architecture for a NFV Management and Orchestrator system

One of the next steps needed in NFV MANO's evolution is to include SDN controllers in the MANO architecture. A MANO framework might integrate a SDN controller as an SDNO (SDN orchestrator) component, or as a VIM block component. This added functionality brings benefit when leveraging in SDN concepts to implement and manage an NFV infrastructure, managing and orchestrating VNFs in a multivendor ecosystem.

NFV MANO can be utilized to deploy an end to end management system on higher layers in cellular networks to manage the life cycle events of EPC and RAN VNFs. The MANO comprising of the NFVO and the VNFM can be used from a centralized location to instantiate, terminate and scale VNFs in

SaT5G (761413) D3.3 December 2018

of 60

different distributed locations, irrespective of their geographical and physical locations. [13] The creation of network services is performed dynamically where the NFVO serves the orchestration of NFVI resources across multiple VIMs and the lifecycle management of network services whereas the VNFM is responsible for the lifecycle management of VNF instances. [13] The or-vnfm reference point is for exchanges between the NFVO and the VNFM which takes care of the resource authorization, validation, reservation and release of VNFs [47]. Figure 4-9 below illustrates an example deployment of ETSI compliant MANO to manage the lifecycle events of EPC VNFs in a multi-VIM scenario in different POPs utilizing a single interface between NFV and VNFM. The NVFO and the VNFM message exchange is based on a Pub/Sub mechanism over RabbitMQ where the NFVO publishes a message to an exchange which is then bound to a queue relevant to the message and the VNFM then subscribes to the message [47]. The VNFM works along with an EMS which serves as an agent inside each VMs to ensure the execution of lifecycle of VNFs by executing the scripts in a VNF package [47].

Figure 4-9: Example deployment of ETSI compliant MANO

Based on the example deployment, the message exchange between the NFVO-VNFM and the EMS from deploying and launching the NSD to the execution of lifecycle events is depicted in Figure 4-10.

SaT5G (761413) D3.3 December 2018

of 60

Figure 4-10: Message exchange between the NFVO-VNFM and the EMS from deploying and launching the NSD to the execution of lifecycle events [47]

As a matter of fact, to leverage an end-to-end network service, the MANO framework interoperates with several stakeholders and vendors. For example, Openstack VIM, EPC VNF vendors, MANO provider etc. The cross-vendor interoperability is a critical factor to ensure smooth integration across each platform. ETSI is putting in much effort to gather all of them together to work on interoperability, keeping in view each reference point of the NFV framework in different Plugtests events [48]. As an example, the SOL003 APIs for the lifecycle management of VNFs from a centralized NFVO to VNFM in multiple distributed locations and the VNFM-VIM interface to ensure the interoperability between the MANO and the VIM frameworks. The Standard SOL003 interface [49] can be utilized for executing lifecycle events ensuring interoperability between NFVO and VNFM. In Figure 4-11 below is the SOLOO3 APIs execution of the lifecycle events in a nutshell.

SaT5G (761413) D3.3 December 2018

of 60

Figure 4-11: SOLOO3 APIs execution of the lifecycle events [49]

SaT5G (761413) D3.3 December 2018

of 60

5 Management and orchestration in integrated satellite

5G networks

In this chapter a high level view is presented about management and orchestration of integrated satellite 5G networks. Management and orchestration in general is not standardized in detail, so much of the details about this aspect can be left to vendors.

First a discussion about the management and orchestration of SNO networks in isolation is given. Next the relationship of management & orchestration between MNO and SNO networks is presented for the case where the SNO network is acting as a transport network. Lastly a number of cases are discussed where the SNO network is not acting as transport network, namely for the Direct Access case and for the Indirect Access case based on the Relay Architecture (see [1], Section 4.3, and Section 4.4.2, respectively).

5.1 Management and orchestration in satellite networks as transport networks

The management and orchestration architecture of SNO networks when used as transport networks for terrestrial (MNO) networks partly depends on the way the SNO networks are supporting the MNO networks and partly on the virtualization architecture underlying the SNO networks.

In case an SNO network is based on an ETSI VNF architecture and is used to support MNO network slicing by elementary IP network mechanisms (such as IP routing and IP tunnelling), the management and orchestration of the SNO network can be based on the ETSI MANO approach (see Section 4.2).

In case an SNO network is based on a 5G 3GPP architecture (e.g. consisting of a 5G NTN UE, and a 5G NTN CN, possibly combined with a 3GPP access or non-3GPP access network over the satellite radio connection) and is used to support one or more MNO networks by using SNO level network slicing, the management and orchestration of the SNO network can be based on the 3GPP SA5 management of network slicing approach (see Section 4.1). There is, however, one aspect that is not covered by 3GPP network management, and that is the management of the 5G NTN UE. In the case of satellite networks acting as transport networks the 5G NTN UE needs to be managed as an integral part of the complete satellite network. This is not the situation in standard 3GPP networks: in those networks the MNO management and orchestration does not include management of 5G UEs.

5.2 Combined MNO and SNO management and orchestration In case of an SNO network being used as a transport network by a terrestrial (MNO) network, in general there will be a loose relation between the two operators. The MNO most likely will consider the SNO network as (one of the) possible transport networks that it may use and it will see the transport network operator (in this case the SNO) as a provider of connectivity. It is therefore most likely that the MNO management and orchestration network will consider the SNO management and orchestration network as hierarchically lower, i.e. the management of the MNO will give orders to the management of the SNO and expect to get responses (e.g. in the form of connectivity) and reporting (e.g. on the status of the connectivity) from the SNO. The diagram depicted in Figure 5-1 below illustrates this hierarchical relationship.

SaT5G (761413) D3.3 December 2018

of 60

NG-RAN

Sat Ground Station 5GCN

Sat Terminal Satellite

SNO MNO1MNO1

MNO MANO

SNO MANO

Figure 5-1: Hierarchical management and orchestration

The (hierarchical) relationship between MNO management and SNO management can take the following forms:

Automatic: i.e. MNO management systems have network interfaces to SNO management systems and through these interfaces the MNO management systems can instruct SNO management systems to act and the SNO management systems can respond to the MNO management systems.

Manual: i.e. the MNO may give orders to the SNO through manual means (e.g. through MNO personnel ordering facilities from the SNO network, etc.) and the SNO may give ‘written’ reports and responses to the MNO about the status of the SNO network.

The first form of hierarchical management requires a high degree of interoperability and integration effort between the MNO and the SNO, but it provides a form of integration between SNO and MNO networks that will most likely lower the costs and is less error-prone. In fact, the automatic form of the MNO-SNO relationship corresponds to what has been described in Section 4.1.3 (i.e. the interaction with a TN Domain manager) and therefore it is considered of highly added value in SaT5G. The manual form would correspond to a more classical relationship between an MNO and an SNO when it comes to handle a satellite network-based backhaul connection and thus, it is considered of less added value in an integrated satellite 5G network.

5.3 Management and orchestration in other scenarios For the case of Direct Access the management and orchestration of the SNO network is largely independent of that of terrestrial (MNO) networks. The SNO network will have to manage its own access and core network and it may need to cooperate with MNO networks if roaming and interconnection between the SNO network and MNO networks are required. Note that in this case ‘roaming’ does not imply that the edge network and the central network are distinct MNO networks (VPLMN and HPLMN), but it implies that subscribers of the SNO network (with their ‘own’ 5G UEs with satellite access) can also make use of access through an MNO network based on roaming agreements between the SNO and the MNO. It may also apply to MNO subscribers roaming on SNO networks if the MNO 5G UEs have satellite access capabilities. The diagram depicted in Figure 5-2 below illustrates this situation (including the roaming of satellite-capable terminals to terrestrial networks).

SaT5G (761413) D3.3 December 2018

of 60

Satellite Terminal: 5G NTN

UE

NG-RAN

Sat Ground Station:RAN +5GCN

5GCN

Satellite

SNO

MNO

Roaming 5G NTN UE

5G UE

InterconnectionMNO MANO

SNO MANO

Figure 5-2: Independent management and orchestration

For the case of Indirect Access based on the Relay architecture, there is a need for close cooperation of the SNO and MNO as the SNO network is tightly integrated in the MNO network. In these architecture scenarios it is very much likely that only a single integrated management and orchestration network is needed. The diagram depicted in Figure 5-3 below illustrates a possible instance of the relay architecture and its management and orchestration.

NG-RAN with gNB

part of IAB node

Sat Ground Station

with IAB donor 5GCN

Sat Terminal with UE part of

IAB nodeSatellite

SNO MNOMNO

Integrated MNO & SNO MANO

Figure 5-3: Integrated management and orchestration

In Figure 5-3 it is assumed that the SNO network and the MNO network have separate network elements and that the SNO network acts as a 3GPP access network. Other network architectures realizing a relay scenario are also possible, for example:

the UE part and the gNB part of the IAB Node are integrated and owned by the MNO;

SaT5G (761413) D3.3 December 2018

of 60

the IAB Donor is owned by the MNO; or

the satellite network acts as a non-3GPP access network – and hence there is a need of an IWF between the satellite RAN node and the 5GCN.

All of these network architectures require a tight integration between the MNO and SNO management. Note that an implementation option of such a tightly integrated MNO and SNO MANO could be to have separate MNO and SNO MANOs that are controlled by a ‘higher’ layer integrating MANO.

SaT5G (761413) D3.3 December 2018

of 60

6 End-to-end QoS

Aspects that have to be addressed with respect to end-to-end QoS handling in SaT5G networks are:

Backhaul QoS Awareness, i.e. the mechanisms that may be used by 3GPP network elements to obtain awareness of satellite connections and their QoS and to react to the changes in QoS experienced over satellite connections;

Backhaul Traffic Management, i.e. traffic steering, switching, splitting of traffic carried by backhaul links depending on the QoS properties of the various (types of) backhaul connections.

In the following subsections both these topics are further elaborated.

6.1 Backhaul QoS Awareness In a 5G 3GPP network a UE will start to establish a PDU Session with the network and as a result of this establishment both for uplink (UL) traffic from the UE to the Data Network (DN) and for downlink (DL) traffic from the DN to the UE, functionality will be configured for the appropriate QoS treatment for these two types of traffic. The diagram from TS 23.501 depicted in Figure 6-1 illustrates this concept.

AN UPF UE

Data packets from applications

QoS rules (mapping UL packets to QoS flows

and apply QoS flow marking)

Mapping QoS flows to AN

Resources

QoS Flow (all packets marked with

the same QFI)

PDU Session

PDRs

(classify packets for QoS flow marking and other actions)

Application /Service Layer

AN Resources

Figure 6-1: QoS architecture. Source: 23.501 [2]

For the UL traffic, the UE will be provided with so-called QoS Rules (or these may be preconfigured in the UE). The QoS Rules describe which type of IP packet is mapped to which QoS Flow. A QoS Flow (which determines a so-called QoS Profile containing a number of QoS Parameters) is mapped by the UE on (Radio) Access Network ((R)AN) resources, e.g. radio data bearers, but this mapping is not further specified.

For the DL traffic, the SMF will provide the UPF with a so-called Packet Detection Rule (PDR). The PDR describes which type of IP packet is mapped to which QoS Flow as identified by its so-called QoS Flow ID (QFI). The QFI is then used to mark packets sent to the RAN so that the RAN can map these packets on the appropriate (R)AN resources.

As can be seen from the above, it is mainly the SMF (with the support of the PCF – for policies – and the UDM – for subscription information) that controls the QoS handling of packets for a given PDU Session between UE and DN.

For the case of SaT5G the above implies that it is the SMF that should be made aware of the fact that for a given PDU Session all or part of the traffic is traversing a satellite connection. The SMF should be made aware of this during PDU Session Establishment and during PDU Session Modification so that it may provide the appropriate 5QI (5G QoS Identifier) to the PDU Session in the QoS Parameters.

A method – currently proposed to 3GPP – to make the SMF aware of the presence of satellite connections and how this awareness can be used is described below:

SaT5G (761413) D3.3 December 2018

of 60

Each UPF is made aware of QoS limitations (e.g. lower bound for latency, etc.) of user plane connections attached to their end-points. For instance, a UPF may have a satellite connection to a gNB attached to its N3 interface. This connection could have a QoS limitation with respect to latency, i.e. the connection will have a minimum latency largely determined by the latency caused by the satellite connection. The awareness of the UPF may be pre-provisioned, or it may be dynamically determined, e.g. by monitoring the QoS properties of a connection. QoS limitations can sometimes change dynamically, e.g. because of fading of satellite connections.

The SMF will be informed about the QoS limitations known by the UPFs via the N4 interface before PDU Session Establishment or after PDU Session Establishment (e.g. through the use of QoS monitoring).

At PDU Session Establishment the SMF will use the information about QoS limitations of UPFs for its UPF selection and after the selection of one or more UPFs it may use this information to update (if necessary) the initial choice of QoS Profiles that are sent to the AMF and to the RAN.

At PDU Session Modification the SMF will use the information about the QoS limitations of the UPFs it controls for the adaption (if necessary) of UE requested QoS. It may also use update information provided by UPFs on dynamically changed QoS limitation as trigger to initiate an PDU Session Modification session.

Note that the above method applies to satellite connections between a gNB and a UPF (via the N3 reference point), and also to the satellite connection between a local UPF and a central UPF (via the N9 reference point). The latter case is applicable in cases where edge computing is used.

6.2 Backhaul traffic management There may be multiple (type of) connections between the edge network and the central network. For instance, a residential user or SOHO user may have a residential gateway acting as a local 5G network node (e.g. a Home gNB) which may be connected via a low-bandwidth DSL connection or a terrestrial cellular connection and in addition have the option to use a satellite connection for higher bandwidth connectivity.

In such a situation, it may be useful to apply traffic management over the multiple backhaul connections. Traffic management can be classified as:

Traffic steering, i.e. choosing the (type of) connection during establishment of a PDU session;

Traffic switching, i.e. changing the (type of) connection during an already established PDU session;

Traffic splitting, i.e. the splitting of traffic over multiple (types of) connection, e.g. splitting control plane and user plane traffic.

Traffic management over backhaul connectivity resembles the functionality currently studied in the 3GPP SA2 study item Access Traffic Steering, Switching, and Splitting (AT3S). An important difference, however, is that AT3S is focussed on the (signalling) communication between the 5G UE and the 5G Core Network (CN), and for that situation the so-called N1 signalling can be used and is accessible.

For Backhaul Traffic Steering, Switching, and Splitting (BT3S), the gNB or local UPF on the one hand and functions in the CN on the other hand should be made aware of the PDU Session that is being established or that is ongoing. Complicating factor in creating this awareness is that the PDU Session signalling may be largely encrypted between the UE and the CN. Moreover, as an operator option, the user plane data may also be encrypted (via the use of SeGW – Security Gateways).

Note that BT3S is being investigated elsewhere in the SaT5G project and this work will be reported in deliverable D4.3.

SaT5G (761413) D3.3 December 2018

of 60

7 Security

The analysis of security of current of future systems usually starts with:

Identifying the relevant network architecture(s) and the associated use cases;

Identifying the parties or domains playing a role in the architecture and identifying trust relationship(s) between the parties/domains.

Given this information next:

A threat and vulnerability analysis can take place identifying aspects where security is needed.

As a result of this analysis:

Security requirements will be identified.

Based on this, proposals can be made for:

Security mechanisms and their combination into a security architecture;

Security management.

In the rest of this section the above will be elaborated for the SaT5G situation.

7.1 SaT5G network architectures and use cases The relevant SaT5G network architectures are defined in D3.1. They comprise:

Direct access via satellite using 5G technologies;

Satellite connections as transport network for the backhaul between remote 5G radio networks and the central 5G core network; this architecture may or may not be combined with edge computing, i.e. local access to data networks in the remote locations;

Satellite connections as connectivity between a relay gNB and a donor gNB in a relay architecture; this architecture may or may not be combined with edge computing.

The scope of the SaT5G project is on the second and third type of architecture. Hence, integrated authentication using a single set of UE contained credentials over both satellite and terrestrial access networks is not in scope.

Another point of attention is the fact that the remote networks will not be considered to be visited networks, i.e. the architectures will not be structured in a VPLMN and a HPLMN part.

The use cases of SaT5G are defined in D2.1. They comprise:

UC1: edge delivery and offload of multimedia content and software;

UC2: 5G fixed backhaul;

UC3: 5G to the premises;

UC4: 5G moving platform backhaul.

The above use cases have been elaborated in D2.1 into multiple scenarios, but for the purposes of security this subdivision usually does not have much impact.

7.2 Parties/domains and associated trust models A trust model identifies the parties/domains that are relevant and whether or not certain parts of a network are in the same or in different trust domains. For SaT5G it is useful to start with the network model used by the 5G-ENSURE project in its document [50], see Figure 7-1 below.

SaT5G (761413) D3.3 December 2018

of 60

Figure 7-1: Domains of the 5G security architecture from 5G-ENSURE. Source: [50]

In Figure 7-1 the dashed lines H1, H2 and V1, V2 are used to mark logical of physical communication interfaces between domains. In addition to the abbreviations given in the legend: 3P = 3rd Party, IPS = Internet Protocol Service, ME = Mobile Equipment, MEHW = Mobile Equipment HardWare, IM = Identity Module, UICC = Universal Integrated Circuit Card, USIM = Universal Subscriber Identity Module, UE = User Equipment.

For the SaT5G project this network model results in the following relevant parties:

Mobile Network Operator (MNO);

Satellite Network Operator (SNO);

Content Delivery Provider.

The MNO can be seen as acting in

the USIM domain,

the Access network domain,

the Core network domain.

The SNO can be seen as acting in:

the Access Domain (as one of the RATs) in case of Direct Access scenarios,

the Access Domain (as one of the IP Domain providers) in case of Indirect Access scenario.

The Content Delivery Provider does not have a clear role in Figure 7-1, but it should be realized that content provided should be protected from unauthorized access. And since the Content Delivery Provider may be a different party from the MNO and SNO, there may be a need for additional security measures to be taken between the three roles.

7.3 Security aspects For SaT5G the following security aspects require attention:

Based on the trust relationships between MNO, SNO, and Content Delivery Provider, there may be a need to provide security mechanisms for the communication between these parties, e.g. with respect to logging, intrusion detections, etc.

Based on the trust relationship between MNO and SNO, the MNO may want to protect communication using satellite connections, e.g. via the use of IPsec. The use of IPsec or other encryption methods may provide difficulties for functionality offered by satellite connections

SaT5G (761413) D3.3 December 2018

of 60

such as TCP acceleration (e.g. based on inserting Performance Enhancing Proxies – PEPs), or for the appropriate handling of various QoS requirements.

Based on the trust relationship between Content Delivery Providers and MNOs and SNOs, the content provided by these providers may need to be protected, e.g. for illegal access to the content. Current methods of using DRM (Digital Rights Management) may be sufficient, but not necessarily in all scenarios.

The use of network slicing may require both sufficient trust in the isolation mechanism of slicing and it may require the use of slice specific security mechanisms. More details will be given in the output of WP4.5 of the SaT5G project.

SaT5G (761413) D3.3 December 2018

of 60

8 Conclusions

In this document end-to-end service delivery in a satellite 5G integrated network has been investigated in the following perspectives:

Control perspective;

Management and orchestration perspective.

The control perspective of end-to-end service delivery concerns the behaviour of the (satellite 5G integrated) network that provides the actual connectivity end-to-end. It can be associated with the millisecond-to-second timescale. In the context of this document the following two topics have been investigated in this perspective:

The use of network slicing and virtualisation in a satellite 5G integrated network;

The handling of high latency satellite connections in a satellite 5G integrated network.

The management and orchestration perspective of end-to-end service delivery concerns the handling of network slicing as preparation for the actual connectivity end-to-end. It can be associated with the minute-to-hour timescale (orchestration), or the day-to-month timescale (management). In the context of this document the following topics have been investigated in this perspective:

The use of standardized method for management and orchestration as defined by 3GPP SA5 and by ETSI NVF, i.e. ETSI MANO;

The interaction between the management and orchestration of the Mobile Network Operator (MNO) and the Satellite Network Operator (SNO).

In addition to the above also a high level view on security in satellite 5G integrated networks has been presented.

With respect to the use of network slicing in a satellite 5G integrated network the following observations have been made as a result of the investigations:

In case an SNO network is used as a transport network for backhaul of an MNO network, and in case the MNO wants to support network slicing to its end-users, then the SNO network does not have to support network slicing itself. It may be sufficient to support IP routing or perhaps some standard form of tunnelling.

In case an SNO network is used as a transport network for backhaul of multiple MNO networks, then the SNO network can use the concept of network slicing in order to support the MNOs.

There are at least two ways network slicing in the SNO network can be used to support multiple MNO networks:

o By using standard network slices (as defined by 3GPP) in combination with separate satellite terminals (one for each MNO). The use of separate satellite terminals per MNO is needed in this case, since standard network slices do not pass through the mobile devices.

o By using non-standard extended network slices in combination with a network controllable (single) satellite terminal. The network controllable satellite terminal provides the extension of the (standard) network slice through the terminal to the MNOs. One way of realizing the network controllable satellite terminal is by using Software-Defined Networking (SDN), where the network acts as the SDN controller and the terminal as the SDN switch.

With respect to the handling of high latency satellite connections in a satellite 5G integrated network the following observations have been made as a result of the investigations:

Satellite connections used as backhaul in MNO networks may exhibit higher than usual latencies. The (3GPP-based) MNO network needs to be made aware of this in order to be able to adapt the Quality of Service (QoS) assigned to connections. Currently this QoS awareness is not standardised. This gap has been identified and steps have been taken to try to fill this gap.

In case of a hybrid satellite terrestrial backhaul architecture, there may be a need to steer traffic of one of the backhaul connections depending on the type of the traffic. This type of (backhaul) traffic steering has not been standardized by 3GPP, and based on discussion with 3GPP this will most likely not be standardized as it seen as out-of-scope of 3GPP. It is viewed as a transport network only issue.

SaT5G (761413) D3.3 December 2018

of 60

With respect to management and orchestration in a satellite 5G integrated network the following observations have been made as a result of the investigations:

For the case where the SNO network is used as transport network for the backhaul of the MNO network, the most likely interaction between SNO management and orchestration (MANO) and MNO management and orchestration (MANO) is a hierarchical one: the MNO MANO can instruct the SNO MANO and get reports from the SNO MANO. A federated interaction where the SNO MANO instructs the MNO MANO is not needed in this case.

For the case where the SNO network and the MNO network are interacting as interconnect partners (e.g. where the SNO network is supporting direct satellite access and roaming between the SNO network and the MNO network needs to be supported), the SNO MANO and the MNO MANO do not have to interact directly.

For the case where the SNO network is tightly integrated in the MNO network (e.g. by using the so-called relay gNB architecture), there is a need to have a single integrated SNO/MNO MANO. Realization of such as tightly integrated management scenario may be very complicated and hence should not be foreseen in the short and medium term.

With respect to security in a satellite 5G integrated network the following observations have been made as a result of the investigations:

The need for security mechanisms in a in a satellite 5G integrated network strongly depends to the trust model and on the stakeholders that can be observed in such an integrated network. For instance there may be a need to have security mechanisms between the MNO and the SNO, but also perhaps between the MNO, SNO and the Content Delivery Provider.

The use of some security mechanism such as IPsec (i.e. encryption) over the satellite-based backhaul of an MNO may be hampering the use of performance enhancing techniques (such as the use of TCP acceleration) and the handling of QoS over the satellite connections.

The outcomes of this deliverable can be used in WP4.1, WP4.2, WP4.3 and WP4.5:

WP4.1 may make use of the observations made with respect to the use of virtualisation, SDN and NFV;

WP4.2 may make use of the observations made with respect to management and orchestration;

WP4.3 may make use of the observations with respect to backhaul traffic steering;

WP4.5 may make use of the observations with respect to security.

SaT5G (761413) D3.3 December 2018

of 60

9 References

[1] D3.1, “Integrated SaT5G General Network Architecture,” SaT5G, WP3.1, 2018.

[2] TS 23.501, “System Architecture for the 5G System; Stage 2,” 3GPP, 2018.

[3] TS 38.300, “NR; NR and NG-RAN Overall Description; Stage 2,” 3GPP, 2018.

[4] RFC 1701, “Generic Routing Encapsulation,” IETF, 1994.

[5] J. Rai and P. Subharthi, “Network Virtualization and Software Defined Networking for Cloud Computing: A Survey,” IEEE Communications Magazine, November 2013.

[6] R. Horvath, D. Nedbal and M. Stieninger, “A Literature Review on Challenges and Effects of Software Defined Networking,” Procedia Computer Science, vol. 64, pp. 552-561, 2015.

[7] C. Fei, B. Zhao, W. Yu, C. Wu and J. Bao, “A research platform for software defined satellite networks,” in 16th International Conference on Optical Communications and Networks (ICOCN), Wuzhen, China, 2017.

[8] ETSI white paper, “Network Functions Virtualisation: An Introduction, Benefits, Enablers, Challenges & Call for Action,” Issue 1, ETSI, 2012.

[9] [Online]. Available: https://osm.etsi.org/.

[10] [Online]. Available: https://www.onap.org/.

[11] [Online]. Available: http://www.3gpp.org/specifications-groups/sa-plenary/sa5-telecom-management.

[12] [Online]. Available: http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv-v1.0.html.

[13] GS NFV-MAN 001, “Network Functions Virtualization (NFV); Management and Orchestration,” V1.1.1 , ETSI, 2014.

[14] [Online]. Available: https://www.sdxcentral.com/nfv/definitions/etsi-isg-nfv/.

[15] [Online]. Available: http://www.3gpp.org/specifications-groups/25-sa.

[16] [Online]. Available: https://www.opennetworking.org/.

[17] ONF, “SDN Architecture Overview,” Version 1.0, December 12, 2013.

[18] T. Koponen, M. Casado, N. G. J. Stribling, L. Poutievski, M. Zhu, R. Ramanathan, Y. Iwata, H. Inoue, T. Hama and S. Shenker, “Onix: A Distributed Control Platform for Large-scale Production Networks,” OSDI 10, http://static.usenix.org/events/osdi10/tech/full_papers/Koponen.pdf, October 2010.

[19] A. Tootoonchian and Y. Ganjali, “HyperFlow: A Distributed Control Plane for OpenFlow,” INM/WREN'10, https://www.usenix.org/legacy/event/inmwren10/tech/full_papers/Tootoonchian.pdf, April 2010.

[20] P. Berde, M. Gerola, J. Hart, Y. Higuchi, M. Kobayashi, T. Koide, B. Lantz, B. O'Connor, P. Radoslavov, W. Snow and G. Parulkar, “ONOS: towards an open, distributed SDN OS,” in HotSDN'14: Proceedings of the third workshop on Hot topics in software defined networking, August 2014.

[21] J. Medved, R. Varga, A. Tkacik and K. Gray, “OpenDaylight: Towards a Model-Driven SDN Controller architecture,” in 2014 IEEE 15th International Symposium on A World of Wireless, Mobile and Multimedia Networks, June 2014.

SaT5G (761413) D3.3 December 2018

of 60

[22] S. H. Yeganeh and Y. Ganjali, “Kandoo: a framework for efficient and scalable offloading of control applications,” in HotSDN'12: Proceedings of the first workshop on Hot topics in software defined networks, August 2012.

[23] ONF TR-521, “SDN Architecture,” Issue 1.1, ONF, 2016.

[24] TS 24.526, “User Equipment policies for 5G System; Stage 3,” 3GPP, 2018.

[25] TS 28.530, “Management and orchestration; Concepts, use cases and requirements,” 3GPP, 2018.

[26] TS 28.533, “Management and Orchestration; Architecture framework,” 3GPP, 2018.

[27] TS 28.525, “Life Cycle Management (LCM) for mobile networks that include virtualized network functions; Requirements,” 3GPP, 2018.

[28] TS 28.526, “Life Cycle Management (LCM) for mobile networks that include virtualized network functions; Procedures,” 3GPP, 2018.

[29] TS 28.527, “Life Cycle Management (LCM) for mobile networks that include virtualized network functions; Stage 2,” 3GPP, 2018.

[30] TS 28.528, “Life Cycle Management (LCM) for mobile networks that include virtualized network functions; Stage 3,” 3GPP, 2018.

[31] TS 28.510, “Configuration Management (CM) for mobile networks that include virtualized network functions; Requirements,” 3GPP, 2018.

[32] TS 28.511, “Configuration Management (CM) for mobile networks that include virtualized network functions; Procedures,” 3GPP, 2018.

[33] TS 28.512, “Configuration Management (CM) for mobile networks that include virtualized network functions; Stage 2,” 3GPP, 2018.

[34] TS 28.513, “Configuration Management (CM) for mobile networks that include virtualized network functions; Stage 3,” 3GPP, 2018.

[35] TS 28.515, “Fault Management (FM) for mobile networks that include virtualized network functions; Requirements,” 3GPP, 2018.

[36] TS 28.516, “Fault Management (FM) for mobile networks that include virtualized network functions; Procedures,” 3GPP, 2018.

[37] TS 28.517, “Fault Management (FM) for mobile networks that include virtualized network functions; Stage 2,” 3GPP, 2018.

[38] TS 28.518, “Fault Management (FM) for mobile networks that include virtualized network functions; Stage 3,” 3GPP, 2018.

[39] TS 28.520, “Performance Management (PM) for mobile networks that include virtualized network functions; Requirements,” 3GPP, 2018.

[40] TS 28.521, “Performance Management (PM) for mobile networks that include virtualized network functions; Procedures,” 3GPP, 2018.

[41] TS 28.522, “Performance Management (PM) for mobile networks that include virtualized network functions; Stage 2,” 3GPP, 2017.

[42] TS 28.523, “Performance Management (PM) for mobile networks that include virtualized network functions; Stage 3,” 3GPP, 2018.

[43] D3.2 Part A, “Integrated SaT5G Detailed Network Architecture,” SaT5G, WP3.2, 2018.

[44] [Online]. Available: https://www.etsi.org/.

SaT5G (761413) D3.3 December 2018

of 60

[45] P. S. Khodashenas, J. Aznar, A. Legarrea, C. Ruiz, M. S. Siddiqui, E. Escalona and S. Figuerola, “5G network challenges and realization insights,” in 18th International Conference on Transparent Optical Networks (ICTON), Trento, Italy, 2016.

[46] B. Blanco et al., “Technology pillars in the architecture of future 5G mobile networks: NFV, MEC and SDN,” Computer Standards & Interfaces, vol. 54, pp. 216-228, 2017.

[47] Frauhofer FOKUS, “OpenBaton,” [Online]. Available: http://openbaton.github.io/documentation/.

[48] ETSI Plugtests Report, “2nd ETSI NFV Plugtests,” V1.0.0, Sophia Antipolis, France, January 2018.

[49] GS NFV-SOL 003, “Network Functions Virtualisation (NFV) Release 2; Protocols and Data Models; RESTful protocols specification for the or-vnfm Reference Point,” V2.3.1, ETSI, 2017.

[50] D2.7, “Security Architecture (final),” 5G-ENSURE, http://www.5gensure.eu/sites/default/files/5G-ENSURE_D2.7_SecurityArchitectureFinal.pdf, October 2017.

[51] D2.6, “Euro-5G - Supporting the European 5G Initiative,” 5G-PPP, 2017.

[52] GS NFV-MAN 001, “Network Functions Virtualisation (NFV) Management and Orchestration,” ETSI, V1.1.1, 2014.

sat5g (761413) d3.3 december 2018 satellite and ... · sat5g (761413) d3.3 december 2018 d3.3...

Documents