Embed Size (px)
Citation preview
SaT5G (761413) D3.1 December 2018
D3.1
Integrated SaT5G General Network Architecture
(Interim)
Topic H2020-ICT-07-2017
Project Title Satellite and Terrestrial Network for 5G
Project Number 761413
Project Acronym SaT5G
Contractual Delivery Date M12 Interim / M30 Final
Actual Delivery Date Interim: 21/12/2018
Contributing WP WP3.1
Project Start Date 01/06/2017
Project Duration 30 months
Dissemination Level CO
Editor ADS
Contributors TAS, SES, TNO, i2CAT, UOULU, QUO, AVA, BPK
Satellite and Terrestrial
Network for 5G
SaT5G (761413) D3.1 December 2018
Page 2 of 77
Contributors
Name Organisation Contributions include
Boris Tiomela Jou ADS Document co-editor
Oriol Vidal ADS Document co-editor
Paul Foulon ADS Chapters 2, 4 and 5
Duc Pham-Minh ADS Chapter 2
Iko Keesmaat TNO Chapter 3
Maël Boutin BPK Chapter 5, Edge Delivery
Simon Watts AVA Chapter 2
Christos Politis SES Chapter 2
Konstantinos Liolis SES Chapter 2
Ray Sperber SES Chapter 2
Pouria Sayyad Khodashenas i2Cat Chapter 5, Network management
Leonardo Goratti ZII Document review
Document History
Version Date Modifications Source
00.01 31/08/2017 Document creation and initial delivery to WP3 contributors ADS
00.03 01/10/2017 Template consolidation ADS
00.08 05/10/2017 Restructuring of Chapter 3 TNO
00.10 05/03/2017 Restructuring of Chapter 2, Template consolidation ADS
00.14 20/03/2018 Text about Edge Delivery BPK
0.2 02/05/2018 Generic architecture specification ADS
0.21 06/07/2018 Restructuring of Chapters 4&5, Template consolidation ADS
0.25 14/08/2018 Restructuring of Chapters 2,3,4&5 ADS
0.30 10/09/2018 Consolidation of the inputs for release of the interim version ADS
1.00 21/12/2018 Final review and release of the interim version ADS
SaT5G (761413) D3.1 December 2018
Page 3 of 77
Table of Contents
List of Figures .......................................................................................................................................... 5
List of Tables ........................................................................................................................................... 7
List of Acronyms ...................................................................................................................................... 8
Executive Summary .............................................................................................................................. 12
1 Introduction .................................................................................................................................... 15
1.1 Document context ................................................................................................................. 15
1.2 Document organisation ......................................................................................................... 16
2 Overview of satellite system .......................................................................................................... 17
2.1 Satellite system fundamentals .............................................................................................. 17
2.1.1 General satellite system architecture ................................................................................ 17
2.1.2 Satellite orbits .................................................................................................................... 17
2.1.3 Satellite missions............................................................................................................... 17
2.2 Telecom satellites characteristics ......................................................................................... 18
2.2.1 Satellite Network characteristics ....................................................................................... 18
2.2.2 Satellites technology ......................................................................................................... 24
2.3 Satellites network architectures ............................................................................................ 29
2.3.1 Point to point architecture ................................................................................................. 29
2.3.2 Star, Multi-Star, Meshed and dual architectures ............................................................... 29
2.4 Satellite network operation .................................................................................................... 31
2.4.1 Satellite System Roles and Function Elements ................................................................ 31
2.4.2 Satellite Services ............................................................................................................... 33
2.5 New trends in satellite communications ................................................................................ 34
2.5.1 Very High Throughput Satellites (VHTS) .......................................................................... 34
2.5.2 Software defined payload/satellites................................................................................... 36
2.5.3 Broadband mega-constellations ........................................................................................ 36
2.5.4 SDN/NFV .......................................................................................................................... 36
3 3GPP Reference architecture for 5G systems .............................................................................. 37
3.1 5G introduction ...................................................................................................................... 37
3.2 5G network architecture: core network perspective .............................................................. 38
3.2.1 Overview of 5G core network function and interfaces ...................................................... 39
3.2.2 Most relevant 5G network procedures .............................................................................. 40
3.3 5G radio access technologies ............................................................................................... 41
3.4 5G topics ............................................................................................................................... 43
3.4.1 Network slicing .................................................................................................................. 43
3.4.2 Control user plane separation ........................................................................................... 45
SaT5G (761413) D3.1 December 2018
Page 4 of 77
3.4.3 Edge computing ................................................................................................................ 46
3.4.4 Security mechanisms ........................................................................................................ 47
3.4.5 The concept of relay .......................................................................................................... 48
3.4.6 Traffic steering ................................................................................................................... 49
3.4.7 Management and orchestration of 5G networks and network slicing ............................... 50
4 Satellite positioning in 5G System and associated implementation options .................................. 57
4.1 Satellite positioning in 5G system architecture ..................................................................... 57
4.1.1 Direct 5G UE access ......................................................................................................... 57
4.1.2 Indirect 5G UE access or Backhaul .................................................................................. 57
4.1.3 Indirect interconnect in the roaming scenario ................................................................... 58
4.2 Implementation options and support of additional functions ................................................. 58
4.3 Implementation option for direct 5G UE Access ................................................................... 58
4.3.1 Direct 5G UE access with NR ........................................................................................... 58
4.3.2 Direct 5G UE access with non-3GPP access ................................................................... 60
4.3.3 Direct 5G UE access with higher 3GPP RAN layer mapped over a non-3GPP access ... 61
4.4 Implementation options for Backhaul .................................................................................... 61
4.4.1 Transport Network based implementation options ............................................................ 61
4.4.2 Relay Node based implementation options ...................................................................... 62
4.4.3 Preliminary analysis of implementation options ................................................................ 64
5 Reference SaT5G backhaul architecture and supported features ................................................ 66
5.1 Reference SaT5G backhaul .................................................................................................. 66
5.2 MEC Support ......................................................................................................................... 66
5.2.1 Function delocalization ...................................................................................................... 66
5.2.2 Edge delivery ..................................................................................................................... 67
5.3 Multilink Support .................................................................................................................... 68
5.4 Advanced Satcom functionalities to support ......................................................................... 68
5.5 Integrated network management .......................................................................................... 68
5.5.1 Resource abstraction and network functions virtualization ............................................... 68
5.5.2 3GPP management and Transport Network management ............................................... 70
5.5.3 Orchestration: Management plane representation ............................................................ 72
5.5.4 Slice management............................................................................................................. 73
6 Conclusion ..................................................................................................................................... 74
7 References ..................................................................................................................................... 77
SaT5G (761413) D3.1 December 2018
Page 5 of 77
List of Figures
Figure 1-1: WP3 Strategy approach and SWP3.x interaction ............................................................... 16
Figure 2-1: Typical system architecture for satellite communications .................................................. 17
Figure 2-2 : Satellite Global Coverage (source Inmarsat) .................................................................... 18
Figure 2-3 : OneWeb satellite constellation coverage .......................................................................... 19
Figure 2-4 : Satellite Regional Coverage (source SES/Monaco Sat) ................................................... 20
Figure 2-5 : HTS Ka band regional user beam coverage (Source Avanti HYLAS 2) ........................... 20
Figure 2-6 : Propagation Losses of a geostationary satellite located 19.2 East ................................... 21
Figure 2-7: Classic satellite in spot beam configuration ....................................................................... 26
Figure 2-8: HTS satellite showing gateway beam connecting with four user beams .......................... 26
Figure 2-9 : Multi-beam Coverage from KA-Sat (source Wikipedia) .................................................... 27
Figure 2-10: O3b MEO HTS Satellite System Overview (Source: SES) .............................................. 28
Figure 2-11 : Point to Point architecture ............................................................................................... 29
Figure 2-12 : Star, Meshed and dual architecture................................................................................. 30
Figure 2-13: Roles and functional elements of a satellite communications system ............................. 31
Figure 2-14 : Beam hopping principle ................................................................................................... 35
Figure 3-1: IMT2020 5G use cases ..................................................................................................... 37
Figure 3-2: Basic overall 5G network architecture ................................................................................ 38
Figure 3-3: 5G service based core network architecture ...................................................................... 39
Figure 3-4: Non-3GPP access with interworking functions ................................................................... 41
Figure 3-5: Interfaces and internal architecture of a gNB ..................................................................... 42
Figure 3-6: 5G relay architecture .......................................................................................................... 43
Figure 3-7: 5G relay architecture using split gNB ................................................................................. 43
Figure 3-8: 5G relay architecture using unsplit gNB ............................................................................. 43
Figure 3-9: Example of network slicing ................................................................................................. 44
Figure 3-10: Division of NFs over a single slice or shared between slices ........................................... 45
Figure 3-11: Role of AMF and RAN in slice selection ........................................................................... 45
Figure 3-12: Control plane and user plane separation in 5G ................................................................ 46
Figure 3-13: 5G edge computing architecture ...................................................................................... 46
Figure 3-14: Network functions and interfaces involved in 5G authentication ...................................... 47
Figure 3-15: Use of Security Gateways (SeGW) in case of untrusted transport networks ................... 47
Figure 3-16: Untrusted non-3GPP access using N3IWF ...................................................................... 48
Figure 3-17: Relay node architecture in LTE ........................................................................................ 48
Figure 3-18: Relay architecture with unsplit gNB (from 3GPP TR 38.874) .......................................... 49
Figure 3-19: Relay architecture with edge computing (NOT in 3GPP) ................................................. 49
Figure 3-20: UE based relay architecture ............................................................................................. 49
Figure 3-21: Solution 1 from TR 23.793: proposed architecture framework ......................................... 50
SaT5G (761413) D3.1 December 2018
Page 6 of 77
Figure 3-22: Multi-Access PDU Session proposed architecture ........................................................... 50
Figure 3-23: Role model for 5G management ...................................................................................... 51
Figure 3-24: Examples of communication services provided by network slice instances .................... 52
Figure 3-25: Example of a network slice instance and the relationship with transport networks ......... 52
Figure 3-26: Example of a Network Slice as a Service ......................................................................... 53
Figure 3-27: Example of a Network Slice as Network Operator internals ............................................ 53
Figure 3-28: Example of coordination between 3GPP and TN management systems ........................ 54
Figure 3-29: Life cycle of a Network Slice Instance .............................................................................. 54
Figure 3-30: Example of Management Services and component type A, B, and C ............................. 55
Figure 3-31: Example of deployment of an NSSI with interface to ETSI NFV MANO .......................... 55
Figure 3-32: Network management relationship between 3GPP and ETSI MANO.............................. 56
Figure 4-1: Architecture showing direct UE access via satellite ........................................................... 57
Figure 4-2: Architecture showing indirect UE access via satellite ........................................................ 58
Figure 4-3: Implementation options considered in SaT5G .................................................................. 58
Figure 4-4: Satellite transport network based on 3GPP system specifications .................................... 62
Figure 4-5: Satellite transport network non-based on 3GPP system specifications ............................. 62
Figure 4-6: Relay node concept for backhaul in 5G ............................................................................. 63
Figure 4-7: Satellite terminal acting as a untrusted non-3GPP relay node ........................................... 63
Figure 4-8: Satellite terminal acting as a trusted non-3GPP relay node .............................................. 64
Figure 4-9: Satellite terminal acting as a 3GPP relay node .................................................................. 64
Figure 5-1: Reference SaT5G backhaul architecture .......................................................................... 66
Figure 5-2: MEC caching high-level architecture .................................................................................. 67
Figure 5-3: Satellite core and interface functionalities for enhanced transport network ....................... 68
Figure 5-4: SDN and NFV concept applicability.................................................................................... 69
Figure 5-5: Resources abstraction and NFV in SaT5G ........................................................................ 70
Figure 5-6: 3GPP View on the Mobile Technology Ecosystem ............................................................ 71
Figure 5-7: Orchestration in SaT5G ...................................................................................................... 73
SaT5G (761413) D3.1 December 2018
Page 7 of 77
List of Tables
Table 0-1: Implementation options and key challenges for direct and indirect access........................ 14
Table 2-1: Illustrating increasing performance of HTS satellites ......................................................... 27
Table 4-1: Key challenges for the satellite implementation options in 5G ............................................ 65
Table 6-1: Implementation options and key challenges for direct and indirect access......................... 75
SaT5G (761413) D3.1 December 2018
Page 8 of 77
List of Acronyms
3GPP
5GCN
5GTN
ACM
ADSL
AF
AKA
AMF
API
ARPF
AUSF
BSS
CDN
CIR
CMF
CN
CoS
DASH
DC
DN
DNS
DTT
DVB-RCS/2
DVB-S/2
EMEA
eMBB
ETSI
FR
FSS
GEO
gNB
GSM
GUI
GW
3rd
Generation Partnership Project
5G Core Network
5G Transport Network
Adaptive Coding and Modulation
Asymmetric Digital Subscriber Line
Application Function
Authentication and Key Agreement
Access and Mobility Management function
Application Programming Interface
Authentication Credential Repository and Processing Function
Authentication Server Function
Business Support Systems
Content Delivery Network
Committed Information Rates
Control and Monitoring Functions
Core Network
Classes of Service
Dynamic Adaptive Streaming over HTTP platform
Data Centre
Data Network
Domain Name Service
Digital Terrestrial Television
Digital Video Broadcasting – Return Channel via Satellite/2nd
generation
Digital Video Broadcasting – Satellite/2nd
generation
Europe, Middle East and Africa
Enhanced Mobile Broadband
European Telecommunications Standards Institute
Frequency Re-use factor
Fixed Satellite Service
Geostationary Earth Orbit
5G Node B (Base Station)
Global System for Mobile
Graphical User Interface
Gateway (Satellite)
SaT5G (761413) D3.1 December 2018
Page 9 of 77
HTS
HTTP
ICT
IP
ISDN
ISL
KPI
L2S
LEO
LNA
LTE
MABR
MANO
MEC
MEO
MF-TDMA
MIMO
mMTC
MPLS
MVE
N3IWF
NAS
NAT
NCC
NEF
NF
NFV
NFVI
NFVO
NMC
NMS
NR
NRF
NS
High Throughput Satellite
HyperText Transfer Protocol
Information and Communications Technology
Internet Protocol
Integrated Services Digital Network
Inter-Satellite Link
Key Performance Indicator
Lower Layer Signalling
Low Earth Orbit
Low Noise Amplifier
Long Term Evolution
Multicast ABR
Management and Network Orchestration
Mobile Edge Computing
Medium Earth Orbit
Multi Frequency – Time Division Multiple Access
Multiple-Input, Multiple-Output
Massive Machine Type Communications
Multi-Protocol Label Switching
Mobile Virtualised Equipment
Non-3GPP Inter-Working Function
Network Attached Storage
Network Address Translation
Network Control Centre
Network Exposure Function
Network Function
Network Function Virtualisation
Network Function Virtualisation Instruction
NFV Orchestrator
Network Management Centre
Network Management System
New Radio(5G)
Network Repository Functions
Network Service
SaT5G (761413) D3.1 December 2018
Page 10 of 77
NSSAI
NSSF
NTN
OAI
OBP
ODU
ONID
OPEX
OSM
OSS
OVN
PCF
PDU
PED
PIR
PNF
POP
PTSN
QoS
QoE
RAN
RAT
RCST
REST
SaT5G
SCM
SDF
SDLC
SDN
SDR
SD-WAN
SEA
SLA
SM
SMF
SNO
SO
Network Slice Selection Assistance Information
Network Slice Selection Function
Non Terrestrial Network
Open air interface
On-Board Processing
Out-Door Unit
Original Network ID
Operational Expenditure
Open Source MANO
Operations Support Systems
Operator Virtual Networks
Policy Control Function
Protocol Data Unit
Personal Electronic Device
Peak Information Rates
Physical Network Functions
Point of Presence
Public Transport Switched Network
Quality of Service
Quality of Experience
Radio Access Network
Radio Access Technology
Return Channel Satellite Terminal
Representational State Transfer
Satellite and Terrestrial Network for 5G
Security Context Management
Service Data Flow
Synchronous Data Link Control
Software Defined Network
Software-Defined Radio
Software-Defined Wide Area Networking
Security Anchor Function
Service Level Agreement
Session Management
Session Management Function
Satellite Network Operator
Satellite Operator
SaT5G (761413) D3.1 December 2018
Page 11 of 77
SOAP
SON
SP
SSC
SSPA
SVN
SVNO
SWP
TCP
TG
TN
TWTA
UC
UDM
UDR
UE
UMTS
UPC
UPF
VIM
VM
VNF
VPN
VSAT
WAN
WP
Simple Object Access Protocol
Self-Optimizing Network
Service Provider
Session and Service Continuity
Solid State Power Amplifier
Satellite Virtual Network
Satellite Virtual Network Operator
Sub Work Package
Transmission Control Protocol
Traffic Gateway
Transport Network
Traveling Wave Tube Amplifier
User Control
Unified Data Management
User Data Repository
User Equipment
Universal Mobile Telephone System
User Plane Control
User Plane Function
Virtualised Infrastructure Manager
Virtual Machine
Virtual Network Function
Virtual Private Network
Very Small Aperture Terminal
Wide Area Network
Work Package
SaT5G (761413) D3.1 December 2018
Page 12 of 77
Executive Summary
SaT5G aims to deliver the seamless integration of satellite into 5G networks to ensure ubiquitous 5G
access everywhere.
This document provides the accomplishments of the WP3.1 – Reference Satellite Network
Architecture integrated into 5G whose purpose is to analyse the characteristics and constraints of
both satellite networks and terrestrial networks and come up with reference integrated satellite-
terrestrial network architecture as foreseen for 5G. The outcomes of this investigation will be
considered as initial direction for the analysis performed in the frame of the whole WP3 – Integrated
Network Architecture Design and taken as fundamental development axis in the frame of WP4 –
Research to prototype Development.
Analysis on on-going 5G specification have led to the identification of two positioning for satellite in
future 5G network system architecture:
Direct access: satellite-capable UE has a direct access to the 5G network through a satellite
link;
Indirect access or backhaul: UE accesses to (R)AN via 3GPP or non-3GPP access
technologies. (R)AN is connected to the 5G core through a satellite link.
The implementation options for direct access and indirect access and potential features are resumed
in the All the backhaul implementation options need to support Multi-access Edge Computing
(MEC) as a key 5G feature. This includes edge delivery and support of network function
delocalisation. Inherent broadcast and multicast capabilities of satellite systems will provide efficient
caching solutions which are investigated in SaT5G with the following approaches:
5G Multicast techniques within the 3GPP network: data flows from a CDN server go
through the 5G network which uses the satellite link to multicast flows towards MECs.
Multicast techniques out of the 3GPP network: data flows from a CDN server are directly
multicast towards MECs via satellite link.
In case of multilink support (satellite and non-satellite links), Hybrid Multiplay Functions are foreseen
in order to improve service Quality of Experience (QoE). Traffic steering will therefore typically be
performed at (R)AN level.
SaT5G (761413) D3.1 December 2018
Page 13 of 77
Table 0-1 below. The identified indirect access implementation options can be classified in 2 main
approaches:
Relay Node based implementation options (RN): satellite-capable UE endorsing a relay
functionality (i.e. multiplexer node role) which can serve other UEs and being backhauled to
the ‘donor RAN’ and 5G core network through a satellite link. This approach includes three
implementations options, differentiated by the type of access between the RN and the 5G
core network: 3GPP access, trusted non-3GPP access and untrusted non-3GPP access.
Transport Network (TN): the satellite network offers transport features to the 5G network
between the 5G core and the RAN. The TN interfaces provide enhanced management and
advanced satellite network functionalities (e.g. 5G QoS adaption to satellite class of service,
dynamic satellite resources management, etc.). The backhaul implementation based on TN
include two implementation options, mainly differentiated by the features provided by satellite
network at the interfaces with the terrestrial network. These interfaces can be natively 5G
ready (TN based on 3GPP system specifications) or would require a development of an
adaptation layer (TN not based on 3GPP system specifications).
All the backhaul implementation options need to support Multi-access Edge Computing (MEC) as a
key 5G feature. This includes edge delivery and support of network function delocalisation. Inherent
broadcast and multicast capabilities of satellite systems will provide efficient caching solutions which
are investigated in SaT5G with the following approaches:
5G Multicast techniques within the 3GPP network: data flows from a CDN server go
through the 5G network which uses the satellite link to multicast flows towards MECs.
Multicast techniques out of the 3GPP network: data flows from a CDN server are directly
multicast towards MECs via satellite link.
In case of multilink support (satellite and non-satellite links), Hybrid Multiplay Functions are foreseen
in order to improve service Quality of Experience (QoE). Traffic steering will therefore typically be
performed at (R)AN level.
SaT5G (761413) D3.1 December 2018
Page 14 of 77
Table 0-1: Implementation options and key challenges for direct and indirect access
Positioning Implementation
option Key challenges
Network
management
Potential additional
supported features
Direct Access
3GPP Access • NR over satellite
Single
integrated
NMS
• Satellite capable
UE
• Traffic steering at
UE level
Trusted non-
3GPP Access
• Make satellite access a trusted
non-3GPP access in standards
Untrusted non-
3GPP Access
• Implement untrusted access
mechanisms as requested by 5G
standards
Indirect
Access
(Backhaul)
Relay node
with 3GPP
Access
• NR over satellite
• Adaptation of relay node
mechanisms to satellite terminal
Single
integrated
NMS
• Edge delivery
• NF delocalisation
• Hybrid myltiplay
(traffic steering at
RAN level)
• Enhanced UP,
CP, MP
interfaces
between satellite
domain and
terrestrial domain
Relay node
with Trusted
non-3GPP
Access
• Make satellite access a trusted
non-3GPP access in standards
• Adaptation of relay node
mechanisms to satellite terminal
Relay node
with Untrusted
non-3GPP
Access
• Implement untrusted access
mechanisms as requested by 5G
standards
• Adaptation of relay node
mechanisms to satellite terminal
Transport
Network based
on 3GPP
System
specification
• Design a specific “5G ready”
satellite transport network
based on 5G system
specifications 3GPP NMS
and Sat NMS
working in
coordination
Transport
Network not
based on 3GPP
System
specification
• Design an adaptation layer for
existing satellite transport
network
For efficient 5G satellite and terrestrial integration, the support of network slicing by all the domains is
a key requirement. SDN/NFV paradigms applied to satellite communications have been identified as
key assets to provide appropriate tools and interfaces in order to ensure efficient support of end-to-
end network slicing.
Management approaches of the future integrated satellite-terrestrial 5G network have been analysed
and the two main approaches regarding the Network Management System (NMS) are:
Separated NMSs with coordination between the 3GPP NMS and the satellite NMS: in this
case, the 3GPP NMS only manages the terrestrial 3GPP components, while the satellite
components are entirely managed by a separate management system (satellite NMS).
Coordination between the two NMSs is therefore foreseen for an efficient resource usage and
to ensure appropriate responses to the requests (e.g. service, monitoring, etc.) from one
domain to another. This approach is typically applicable to backhaul implementation option
based on satellite system.
Single integrated network management: in this case, the 3GPP NMS ensure the
management of the whole satellite-terrestrial network, including the satellite terminal. This
approach is typically foreseen for relay node implementation cases in which the satellite
terminal acting as a relay node would be managed by the same entity managing the terrestrial
network i.e. the 3GPP NMS.
SaT5G (761413) D3.1 December 2018
Page 15 of 77
1 Introduction
1.1 Document context
This deliverable describes and defines a reference high level functional architecture integrating
satellite in 5G systems, considering the positioning of the satellite system in 3GPP system
architecture (as defined in 3GPP TS 23.501 [1]) and its associated implementation options. The
derived architecture will constitute the first steps of an integrated satellite and terrestrial network
design in order to meet Sat5G use cases and scenarios requirements as defined in D2.1 – Satellite
Reference Use Cases and Scenarios for eMBB [2].
The deliverable corresponds to the work carried out in WP3.1 – Reference Satellite network
architecture integrated in 5G. As illustrated in Figure 1-1, the work carried out in WP2 aims at defining
satellite reference use case and scenarios as well as the technical, operational and business
requirements and will provide fundamental inputs to WP3 in order to cope with the architecture
definition work in the frame of SaT5G.
In this deliverable, the different options of satellite positioning into the 5G system architecture are
introduced and the “how to” implement these different positions are identified as implementation
options and further investigated in “WP3.2 – Backhaul architectures”. The high-level reference
architecture is specified, highlighting the different possible options with respect to the implementation
of satellite indirect access or backhauling service within the 5G network. Edge delivery and Network
Functions Virtualisation (NFV), as well as multilink support are also introduced as important features
leveraged in the project which need to be integrated within the final architecture and analysed in
detail. A high level description of these capabilities is addressed in this deliverable and further
analysed in detail in “WP3.3 – Caching and Multicast Architectures” and WP4. Finally, the end-to-end
network management aspects are also discussed, describing the main principles which will enable the
support of network slicing within a satellite and terrestrial integrated architecture.
As observed in Figure 1-1, there’s a tight relation and interaction between all sub WPs (SWP) within
WP3 (both at planning and technical level) which will require great efforts of coordination to define a
converged and generic architecture which is representative of each SaT5G use case defined in WP2.
The figure also represents the interaction between the WP3.1, within which this deliverable is
elaborated, and other work packages and studies carried out inside and outside the SaT5G project.
Further analyses regarding Multi-access Edge Computing (MEC) are performed in deliverable D3.2
[3], as output of “WP3.3 – Caching and Multicast architectures”.
Detailed definition of backhaul architectures is provided in deliverable D3.2, as output of “WP3.2 –
Backhaul architectures”.
Network management, support of slicing and end-to-end delivery are addressed in deliverable D3.3
as output of “WP.3.4 – End-to-End Service Delivery”.
Task “WP3.5 – Satellite and 3GPP NextGen Reference Interface” and associated deliverable D3.4
addresses the definition of future interfaces between terrestrial and non-terrestrial networks.
The main outcomes of this deliverable will constitute relevant recommendations with respect to
specific technical blocks (or features) to be developed in the frame of other SWPs in WP3 and WP4.
These outcomes will contribute to the definition of the roadmap for 5G satellite technology. At the
same time, as part of one of the research pillars of SaT5G, relevant contributions to the
standardisation bodies (e.g. 3GPP, ETSI) are expected to promote satellite integration in 5G networks
and the topics discussed in this deliverable will lead to several contributions regarding the architecture
aspects of the future 5G system, as well as the interaction between networks at management level,
and at control/user plane level.
It should be noted that an interim version is foreseen for M12 and the final version will be ready by the
end of the project, updating the content if necessary with respect to the outcomes from WP4
regarding the different research pillars developments and the demonstrations carried out in WP5. The
SaT5G (761413) D3.1 December 2018
Page 16 of 77
idea is to capitalize on the development phase and the experience gained in the demonstrations to
consolidate the theoretical architecture work addressed in the first stage of the project.
Figure 1-1: WP3 Strategy approach and SWP3.x interaction
1.2 Document organisation
The documents starts with an overview of the satellite system in chapter 2 in order to introduce
satellite concepts and draw the history of satellite and terrestrial integration.
Chapter 3 provides an overview of the concepts related to 5G and 3GPP specifications for the 5G
system, and introduce the 5G system architecture as specified in 3GPP. This will be the reference
starting point from which the integrated architecture work done in WP3.1 will be based upon.
Chapter 4 provides possible positioning of the satellite link in the 5G system architecture in order to
clearly identify the scope of the study and the identified implementation options for direct User
Equipment (UE) access and indirect UE access through the satellite (i.e. backhauling).
The reference satellite network architecture integrated in 5G is addressed in chapter 5. A preliminary
analysis of the support of Multi-access Edge Computing (MEC) and multilink in the integrated
satellite-terrestrial network is presented, as well as the requirement for advanced SatCom
functionalities to support backhaul architectures, independently of the considered implementation
option. Key aspects related to integrated network management such as slice support, NFV adoption,
orchestration and security management are introduced and will be further studied in detail in SWP3.4
and WP4
Finally, chapter 6 concludes the document.
SaT5G (761413) D3.1 December 2018
Page 17 of 77
2 Overview of satellite system
2.1 Satellite system fundamentals
This chapter aims at detail the main characteristics of a satellite system.
2.1.1 General satellite system architecture
A satellite system is mainly composed of a space segment, a ground segment and a control segment.
The space segment consists of one or several satellites in orbit. The ground segment pools all the
traffic earth stations. It can be split in two groups: the gateway side and the user side. The control
segment is responsible for controlling, monitoring and managing the satellites and the associated
resources.
These three components are presented in the figure below.
Figure 2-1: Typical system architecture for satellite communications
2.1.2 Satellite orbits
The orbit is the trajectory of the satellite. The shape of this orbit can be circular or elliptical and
inclined with respect to the equatorial plane. Circular satellite orbits are commonly classed by altitude
in three ranges:
LEO (Low Earth Orbit) : up to 2000 km;
MEO (Medium Earth Orbit) : from 2000 km to geostationary orbit at 35786 km;
GEO (Geostationary Orbit) : 35786 km.
The selection a satellite system implies the choice of a suitable orbit to address the targeted services.
2.1.3 Satellite missions
SaT5G (761413) D3.1 December 2018
Page 18 of 77
The satellites can be used for a wide range of missions. These missions are usually distinguished in
the following way:
Scientific research satellites: lead various types of scientific missions (e.g. space/star/planet
exploration, space environment study, earth atmosphere monitoring, …);
Earth observation satellites: meteorological missions, earth resources monitoring …;
Telecommunication satellites: digital audio, video and data broadcasting, mobile
communications, multimedia services (e.g. distance learning, telemedicine, teleworking,
interactive television, …);
Navigation satellites: constellation of satellites which allows a ground receiver to determine its
exact location (e.g. GPS, GLONASS, Galileo, Compass).
2.2 Telecom satellites characteristics
2.2.1 Satellite Network characteristics
2.2.1.1 Coverage
Telecommunication Satellites, in particular GEO satellites, offer a large coverage of earth. Three
GEO satellites are enough to provide a near global coverage of the earth.
Figure 2-2 : Satellite Global Coverage (source Inmarsat)
Full constellations in LEO orbit cover the whole world, noting that to carry traffic they must either be
in reach of a gateway location or use inter-satellite links (ISLs) to reach the gateway.
SaT5G (761413) D3.1 December 2018
Page 19 of 77
Figure 2-3 : OneWeb satellite constellation coverage
Lower frequency bands (L-band) are well suited for mobile services (including, maritime, aviation and
land mobile communications) since they are less affected by the propagation losses. As example of
constellation is the Iridium NEXT system composed of 66 satellites plus additional spares in orbit, all
with Inter Satellite Links.
In order to improve the quality of service, the coverage is in most of the cases (e.g. for GEO and MEO
based systems) focused on a specific area and several satellites are used to provide the desired
service.
Today’s HTS also tend to offer regional coverage with multiple smaller (user) beams.
SaT5G (761413) D3.1 December 2018
Page 20 of 77
Satellite Regional Coverage
MENA Ku-Band beam
West Ku-Band beam
Figure 2-4 : Satellite Regional Coverage (source SES/Monaco Sat)
Figure 2-5 : HTS Ka band regional user beam coverage (Source Avanti HYLAS 2)
2.2.1.2 Capacity
In general, the capacity of a Satcom system is given in Mbps due to the importance of data services.
Capacity is a critical point of satellite networks. Indeed, due to the large coverage, limited power and
spectrum, capacity on-board a satellite is always (very) limited compared to terrestrial systems, which
benefit of better propagation conditions, less-restricted power supply and can reuse the spectrum
more easily.
Before HTS satellite generation:
SaT5G (761413) D3.1 December 2018
Page 21 of 77
Historically, in the context of broadcast service a typical carrier for a traditional satellite network is 36
MHz wide. Depending on the propagation conditions and thanks to the adaptive coding and
modulation (ACM) mechanisms (modulation and forward error correction), different modulations can
be used. For example the set of DVB-S2 modulation schemes can provide a raw throughput between
5.4 and 55 Mbps in a 36 MHz channel. In some systems, up to eight carriers can be managed
providing a bandwidth from 43.2 to 444 Mbps. ASTRA and other systems can also use different
physical channel bandwidths (for instance 26, 33 or 54 MHz), but the principles are the same.
Due to these capacity limits, most ground segment solutions use technologies to optimise the use of
satellite bandwidth for compressed voice, Ethernet header removal, pre-distortion and dynamic traffic
multiplexing based on priorities.
HTS new capacities:
On the other hand, HTS satellites reuse the frequency on different beams to increase the available
capacity of the system. An example of HTS satellite with frequency reuse is the KaSat satellite (see
Figure 2-9).These offer forward link beams typically of 250MHz or 500MHz and are often combined
with state of the art DVB-S2X carriers. In this context, the higher range of modcods can offer better
symbol efficiencies in most circumstances than the older DVB S2 standard allows.
A representative 250 MHz forward link can today offer around 700 Mbps to 800 Mbps to professional
sites with 1.2 m antennas. The exact figure will vary between satellites, depends on the Satellite
Terminal (ST) antenna size, the service availability requirements, carrier capabilities, and where the
STs are located across the user beam. For example, if smaller consumer antennas (~0.7m) are used
in the beam, the capacity could drop to 500Mbps and a 50/50 mix might result in around 650Mbps
total per forward link beam. Latest state of the art in Very High Throughput Satellite (VHTS) design
can provide capacity up to 2 or 3 GHz.
2.2.1.3 Availability
Availability of the satellite network is affected by propagation conditions. In addition to free space
losses, the link budget must take into account rain and cloud attenuation. This is particularly important
for high frequency bands like Ku and Ka suffer more from rain fading than L, S or C bands. The
performance of satellite networks are different under clear sky conditions and rain conditions. As a
consequence, the availability of a service will only be granted with a certain level of probability
corresponding to the probability that the rain fade exceeds the limits.
Propagation Loss at 20 GHz for 19.2° Geostationary Satellite with 99.9% probability
Figure 2-6 : Propagation Losses of a geostationary satellite located 19.2 East
To obtain a link budget with the targeted link availability and under rain attenuation, the OutDoor Unit
(ODU) is selected with care, having larger antennas and amplifier on locations where the link budget
SaT5G (761413) D3.1 December 2018
Page 22 of 77
is poor. Techniques that vary the modulation and forward error correction (i.e. ACM) are regularly
used to maximise both total throughput and individual link availability, which is implemented in the
modems at each end of the link. In addition, the key links between the satellites and their gateway
locations are protected from rain fading by one or more of the following techniques:
Uplink power control: increasing the transmit power when the link is partially attenuated;
Gateway site redundancy: switch service to an alternative location when raining hard (either
1:1 or m:n protection);
Locating gateways in locations where rain is unlikely: if the satellite coverage allows and a
suitably connected location can be identified, this can offer a low cost means of mitigating rain
attenuation.
In addition, most of the ground segment equipment shall monitor the propagation conditions and
select the best modulation to exploit the satellite resources in an optimal way, while guarantying a
minimum service grade even in poor conditions.
2.2.1.4 Latency, Doppler and Geometry
In GEO Satcom systems, the propagation latency is longer than in non-GEO and in terrestrial
networks due to the distance of the geostationary belt. The typical one-way propagation delay in GEO
satellite between a gateway and a satellite terminal is around 250 ms.
The propagation delay affects mainly voice services which in addition suffer from codec delay due to
framing (~20 ms for coding and decoding) and packetisation and buffered processing by the satellite
ground infrastructure (0-100ms). In total, the end-to-end delay for voice is typically between 300-400
ms (GEO satellite), which might sometimes be an issue to consider for user applications and services
and noticeable by users that are accustomed to the fixed phone quality but not much greater than
some 2G phone connections.
Although quite small as an absolute figure, the GEO propagation delay actually considerably affects
also interactive data services and any TCP/IP network protocols and applications (designed with
terrestrial assumptions in mind) though in a less important manner: For example, the growing
complexity of web pages, optimised for a terrestrial environment is not well supported by satellite. For
example, a web page composed of 10 sub-parts will require 10 individual loading, each of a duration
of 2*250 ms so 0.5 s which is 2 or three times longer than over a classical ADSL line. The same holds
true for the latest generation of video services (such as access to Over the Top contents, i.e. Netflix or
YouTube video) when dealing with dynamic streaming (or other variants).
Some set of solutions exist (e.g. PEP, http2) to accelerate the downloading of Web pages and
modern browsers include features that help such as pipelining requests, pre-fetching content and data
compression. Content Caching, consisting of sending the “popular” content before the user actually
requests it, may also conceal the delay issues. Trends about use of custom transport protocols over
UDP (i.e. Google QUIC) are also currently considered as promising techniques to use in the GEO
SatCom context.
For the backhaul of cellular network, where the support of voice services is of prime importance, the
longer propagation delays may impact several time-out counters and should be studied in details.
To decrease the latency, one solution is to use satellites in lower orbits such as LEO or MEO. The
one way latency reduces to around 10ms on LEO and a little over 60ms for MEO orbits [4]. On one
hand, the best solution in terms of latency is the lowest orbit, i.e. LEO, but raises coverage and/or
handover (in case of constellation) issues. On the other hand, MEO orbit can ensure an equivalent
coverage with less satellites than LEO with a latency somewhere between LEO and GEO.
For non-geostationary satellite systems, the orbital velocities engender doppler shifts far in excess of
what terrestrial mobile networks can see. For example, with a closing velocity of 8 km/s due to orbit
geometry a 12 GHz signal will shift up 320 KHz. The radio systems must have radio tracking loop
design that accommodate these shifts.
SaT5G (761413) D3.1 December 2018
Page 23 of 77
For all satellite systems, the orbit geometry affects what the receiving antennas need to do. Different
than the prevailing practice in terrestrial mobile, satellite links use both polarizations. Particularly for
MEO and LEO constellations, ground terminals’ pointing towards the satellite needs to be corrected to
have the system function optimally. Using circular polarization removes one axis of ground antenna
orientation, at the expense of inevitable axial ratio mismatch losses.
2.2.1.5 Multicast
Satellite signals can be naturally received at multiple locations at any time unless specifically
prevented. It is this simultaneity that is leveraged by broadcast satellite service providers. The
broadband satellite technologies (such as in DVB) and the supporting equipment vendors include
means to prevent unintended reception of data – for example Hughes Network Systems uses a
hardware based encryption system. Conditional Access can also be implemented at higher layers (at
the MAC layer and at the transport/application layer).
The transmission of multicast data over satellite pre-dates even the wide scale adoption of TCP-IP
being implemented in protocols such as X.25 and SDLC. The introduction of increasingly wideband
IP-based satellite networks allowed the implementation of vendor specific IP multicast systems
requiring a server at the satellite gateway and client software at the ST to capture the multicast
content (proprietary solutions can be found in [5] and [6]). These systems tend to use internal
mechanisms for the reliable transmission of content to remote systems addressing techniques such
as:
Sending the content more than once to ensure successful reception;
Employing an application level error correction to recover mixing blocks of data;
Retransmitting missing blocks of data on request.
Traditionally the data is transmitted to an IPv4 multicast address (e.g. 224.x.y.z), but some systems
now allow also IPv6. In both cases the data is sent in UDP datagrams. The content can be sent to
groups of receivers by using an application level addressing scheme and group members changed
dynamically via the content server. Content is generally pushed by the centre but some systems also
allow a subscription-based model wherein a user or application at the remote device that requests the
reception of specific content will get it the next time it is scheduled for transmission. These are
supplier specific creations with their own APIs. Some SatCom system vendors implement physical
layer encryption for the multicast content – others expect the application to provide this security.
Implementations for the physical layer encryption have been used for applications like:
Digital advertising;
Digital cinema distribution (e.g. see [7]);
Employee training and briefing;
Rural education;
ST firmware updates.
There are now standards covering elements of multicast systems such as FLUTE (IETF RFC 6726)
and NACK-Oriented Reliable Multicast (NORM) (IETF RFC 5740 and RFC 5401). As an example, an
Avanti solution using NORM includes both the edge caching servers deployed in the field and the
back-end services used for the deployment, management, monitoring and content distribution. Key
features now supported by the caching devices include:
New portal with access security, user management, personalized content access, and
customizable look and feel;
Developer API allows 3rd-party developers to integrate solutions with the caching server
(Smart TVs, Android Services, STBs, etc.);
Support for multiple content types
o MP4/MPEG DASH multi-bitrate videos with multi-language/subtitle support and DRM;
o Documents/eBooks archives;
o Localized Web content and knowledge bases (e.g. Wikipedia);
SaT5G (761413) D3.1 December 2018
Page 24 of 77
o Live IPTV services distributed over multicast,
o System and software updates;
Protection against content tampering and improper use by introduction of HDD encryption,
secure communications and support for DRM;
Intelligent Multicast delivery scheduling. Using live and history site heuristics to propose
delivery strategies. Saving time, bandwidth and improving the end-user experience.
2.2.2 Satellites technology
2.2.2.1 On-board capabilities
2.2.2.1.1 Bent pipe
Most communication satellites are radio relay stations in orbit and carry dozens of transponders, each
with a bandwidth of tens of megahertz (hundreds of MHz in HTS systems). Most transponders
operate on a bent pipe principle sending back to Earth what goes into the conduit with only
amplification and a shift from uplink to downlink frequency. Generically, a transponder receives the
signal from the ground, amplifies it, changes frequency, amplifies it further and resends this back to
the ground. Typically a transponder is composed of:
an input band-limiting device (an input band-pass filter);
an input low-noise amplifier (LNA), designed to amplify the signals received from the Earth
station(normally very weak due to the large distances involved);
a frequency translator (normally composed of an oscillator and a frequency mixer) used to
convert the frequency of the received signal to the frequency required for the transmitted
signal;
an output band-pass filter;
a high power amplifier (this can be a traveling-wave tube - TWTA - or a solid-state amplifier -
SSPA).
Most of the broadcast satellites and broadband (especially HTS) GEO satellites in-orbit today are
transparent or bent-pipe because of mass, power and thermal budgets, which are all dedicated to the
signals and not to data processing.
2.2.2.1.2 Regenerative
Some modern satellites use on-board processing (OBP), where the signal is demodulated, decoded,
re-encoded and modulated aboard the satellite. This type, called "regenerative" transponder, may
have advantages (more efficient channelization, higher flexibility, routing capabilities, etc.) but is much
more complex in terms of design and implementation and freezes the system to the modulations that
the payload is built for at launch. Contrary to transparent bent pipe satellites, regenerative satellites
reconstruct the signal in space. The reconstruction of the signal can be at physical or data link layers.
The main benefit of physical signal regeneration is the SNR increase due to the possibility to better
exploit the characteristics of the equipment on-board the satellite. If the signal is regenerated then
some form of on-board processing (OBP) can also be applied – for example switching data packets
between beams using techniques such as Multiprotocol Label Switching (MPLS) or IP routing. In-orbit
data caching is also considered from time to time.
The benefits of data link layer regeneration are a better use of the satellite resources, in particular for
the feeder link which aggregates the traffic and can be optimised. The inconvenience is that the
satellite is optimised for a specific and frozen data link layer.
In summary the benefits of regenerative satellites can include:
Improved link budget (no additive noise from uplink and downlink);
Ability provide mesh connections and on board routing;
Enhanced support with faster responses for direct connections to end user devices.
SaT5G (761413) D3.1 December 2018
Page 25 of 77
The disadvantages of regenerative satellites can include:
Use of scarce electrical energy to process signals rather than amplify them;
The radiation environment required the use of hardened electrical components which tend to
be slower and significantly more expensive than their ground based equivalents;
Long operational lifetimes of satellites put on the services the risk to be constrained by the
waveforms and functions installed prior to launch.
An example of regenerative satellite is the SpaceWay 3 satellite manufactured for Hughes Networks
by Boeing and launched in 20071
. SpaceWay 3 enables a full-mesh digital IP network that
interconnects with a wide variety of end-user equipment and systems such as personal computers,
servers, local area networks, and home networks. This broadband satellite provides HughesNet
services in North America [8].
The trade-off between regenerative and bent pipe satellite systems has historically tended to favour
the latter. This has offered the highest throughputs for lowest system cost. New technologies such as
digital channelizers will allow some on board processing without full regeneration and packet
switching.
One example of LEO satellites with some on-board processing is the Iridium constellation that
provides voice communications in the L-band. There are 66 operational satellites in six planes at 780
km with each satellite which can support 1100 voice calls using a low-rate 1.2kbps codec. This
suggests the total capacity is around 87 Mbps. The OBP manages the data routing and voice call
switching. Iridium NEXT, the second-generation worldwide network of telecommunications satellites,
will also consist of 66 active satellites. These satellites will incorporate features such as data
transmission which were not emphasized in the original design. The constellation will provide L-band
data speeds of up to 128 Kbit/s to mobile terminals, up to 1.5 Mbit/s to Iridium Pilot marine terminals,
and high-speed Ka band service of up to 8 Mbit/s to fixed/transportable terminals. The next-
generation terminals and service are expected to be commercially available by the end of 2018. Note
that a GlobalStar offers similar services with a slightly smaller LEO constellation using bent-pipe
satellites.
For 5G, regenerative satellite implies on-board processing capabilities. This allows higher flexibility on
resources allocation and even the possibility to embed a gNB into a satellite. Such a system may for
example work well with LEO satellites. The use of software defined radios and network function
virtualisation will significantly offset the risk of a system supporting out of date waveforms and / or
functions. This aging risk is lower anyway with LEO spacecraft’s given their likely lower lifetime.
2.2.2.2 Single/Multi-beam
The first generation of FSS (Fixed Satellite Service, Radio communication service between earth
stations at given positions) satellites was based on a single beam covering the target service area.
Usually, these satellites are based on a shaped beam covering a country or a continent and the
services associated are television broadcast, military and other telecommunications services.
The main characteristic and its main limitation is the fact that they cannot reuse the spectrum easily
and thus they are quite limited in spectral resources, i.e. total aggregated throughput. A signal
transmitted in one beam from a satellite terminal may be received by another satellite terminal or
gateway in the same beam, or may be in a different beam (spot beam).
1
SaT5G (761413) D3.1 December 2018
Page 26 of 77
Figure 2-7: Classic satellite in spot beam configuration
With the arrival of the internet and the World Wide Web, the aforementioned single beam FSS
satellites were too limited in spectral resources and thus rather not suitable for providing Internet
access. The evolution from the single beamed traditional satellites with rather modest performances
to the first HTS systems was possible thanks to the introduction of multi-beam and frequency reuse
concepts. This allowed a remarkable increase of system spectral resources, pushing multi-beam Ku-
band satellites to a whole new level of satellite capabilities.
Figure 2-8: HTS satellite showing gateway beam connecting with four user beams
Indeed, today there are approximately more than 20 satellites in the GEO orbit entirely dedicated at
providing broadband services to consumers and enterprises. In 2004 with the launch of Anik F2, the
first HTS2 became operational, giving birth to a new class of next-generation satellites providing
improved capacity and bandwidth. It was part of the so-called first generation of broadband satellites
such as WildBlue I or SpaceWay 3 which could provide tenths of Giga bits per second or the big
iPSTAR (Thaicom) which reached total throughput up to 35 Gbps, in a first attempt to make satellite
communications suitable for broadband market.
More recently, the second generation of HTS has pushed forward the first generation performances
thanks to higher Frequency Re-use factor (FR) allowed by narrow satellite antenna beams and higher
spectral efficiency modulation and coding schemes that can reach total capacity from 70 Gbps to 150
Gbps. As a consequence, a significant reduction of cost/Mbps has been achieved, delivering services
akin to those provided by the terrestrial ADSL2+. Beginning with Ka-Sat, launched at the end of 2010
and followed by ViaSat's ViaSat-1 satellite in 2011 and HughesNet’s Jupiter in 2012, consumer
downstream data rates have evolved from 1-3 Mbit/s up to 12-15Mbit/s and beyond. Professional
2 Once the available spectral resource is reused more than twice, the satellite is already considered a HTS.
SaT5G (761413) D3.1 December 2018
Page 27 of 77
systems such as those used for offering backhaul services have evolved from 10Mbit/s plus to
200Mbit/s and above.
Table 2-1: Illustrating increasing performance of HTS satellites
In the following, some details of Ka-Sat which covers Europe to provide mass market broadband
services are described. The spacecraft is equipped with four multi-feed deployable antennas with
enhanced pointing accuracy and a high-efficiency repeater. It is configured with 82 spot beams. Each
spot beam is associated with a 237 MHz wide transponder, allowing a data bit rate throughput of 475
Mbit/s per spot. The spacecraft power is about 14 kW and the payload DC power is 11 kW.
Multi-beam coverage (KA-SAT)
Figure 2-9 : Multi-beam Coverage from KA-Sat (source Wikipedia)
Globally, compared with single-beam satellite system, multi-beam satellite systems allow increased
capacity and thereby cheaper data rates through each satellite by reusing the allocated frequencies
multiple times, thus enabling a very fair positioning of the satellite link as a backhaul option. It is also
worth mentioning that HTS systems require a number of gateways (for instance, the Ka-Sat system
uses 10 gateways), often connected by an optical fibre backbone and such requirements can lead to
significant costs.
2.2.2.3 Satcom Constellation
SaT5G (761413) D3.1 December 2018
Page 28 of 77
Another way to build a satellite system with fibre-like capacity or a global coverage is to set up a
constellation. The historical Iridium and Globalstar constellations have developed LEO constellations
to address a global coverage for voice and data services. Today, new constellations, LEO or MEO are
built to cope with the rising broadband market.
As example, O3b Networks (Figure 2-10) is an innovative satellite network, which combines the reach
of satellite with the speed of fibre, providing around 70% of the world's population with fibre quality
internet connectivity. The system is based on a Ka-band Medium Earth Orbit (MEO) multi-beam HTS
satellite constellation (on a single 8062 km orbit), with high link trunking capacity (theoretical speed up
to 1.2Gbps per beam). The main targeted communication services are mobile backhauling and IP
trunking (MNOs sector), which are further complemented by maritime and energy services (enterprise
sector) as well as governmental services.
The constellation system comprises 16 Ka-band multi-beam HTS satellites at an altitude of 8062 km,
less than one quarter of GEO, significantly reducing satellite latency. These satellites have been
offering high value high bandwidth satellite services to remote areas and cruise ships where the cost
of steerable tracking antennas can be easily sustained. Future growth into wider markets requires the
commercial exploitation of flat panel antenna technologies – which most satellite operators are
pursuing.
Figure 2-10: O3b MEO HTS Satellite System Overview (Source: SES)
The SES’s O3b MEO HTS system delivers broadband connectivity everywhere on Earth within 45o of
latitude north and south of the equator. Its coverage area includes emerging and insufficiently connected
markets in Latin America, Africa, the Middle East, Asia, and Australia, with a collective population of “other
3 billion” (O3b) people.
The SES’s O3b MEO HTS system is as transparent as possible to different waveform options, as well
as to network topologies. It supports any of the star configuration, mesh configuration and point-to-
point and loopback configuration. Flexible and steerable spot beam coverage also supports dynamic
mission reconfiguration. Also, O3b core network architecture is interconnected to a global MPLS
network, with MPLS nodes being located at the place of global Internet exchange points (GIX).
The choice of a MEO system is justified to benefit from shorter delays with respect to GEO system
since the delay is only about up to 75 ms (Round-Trip Time – RTT up to 150 ms, typical value of 125
ms) and completely compatible with interactive/real service like conversational voice and video
according to most stringent ITU requirements (maximum 100 ms required for transfer delay according
to ITU-T Recommendation Y.1541).
SaT5G (761413) D3.1 December 2018
Page 29 of 77
2.3 Satellites network architectures
There exist several network architectures that can be selected according to the capability of the space
and ground segment and user segment. We can distinguish between the following architectures:
Point to point;
Star;
Meshed;
Hybrid.
2.3.1 Point to point architecture
The point to point architecture is the simplest one. It enables to connect two remote sites using a
satellite. In this architecture, the satellite is a repeater that retransmits the signal coming from the
Satellite Terminals to the earth. In the case of a multi-beam satellite, the retransmission can be made
in a different beam than the reception (the satellite must be configured for that). The one way
propagation delay corresponds to the propagation from the transmitting user terminal to the satellite
plus the propagation from the satellite to the receiving terminal and (is around 250 ms for GEO, 10 to
100 ms for MEO and 5 to 10 for LEO). For interactive and conversational services, the delay to take
into account is the two way propagation delay (which is around 500 ms for GEO). For very long
distances, the point to point architecture may use two satellites and a terrestrial relay station. In that
case the one way propagation delay is 500ms and the two way propagation delay is 1 s.
The following figure illustrate this architecture is the case of a GEO-based satellite system.
© 2
01
4 A
irb
us
De
fen
ce a
nd S
pa
ce –
All
rig
hts
re
serv
ed.
The
re
pro
du
ctio
n,
dis
trib
utio
n a
nd
uti
liza
tion
of
this
do
cum
ent
as
we
ll a
s t
he c
om
mu
nic
atio
n o
f it
s c
onte
nts
to o
the
rs w
ith
out
exp
res
s a
uth
oriz
ation
is
pro
hib
ite
d.
Off
en
der
s w
ill b
e h
eld
lia
ble
fo
r th
e p
ay
me
nt o
f d
ama
ges
. All
rig
hts
re
serv
ed
in th
e e
ve
nt o
f th
e g
ran
t of
a p
ate
nt,
util
ity m
od
el o
r de
sig
n.
Airbus Defence and Space Origin Technical Data. Does not contain U.S. Origin Controlled Technical Data
Point to point architecture
250 ms propagation delay
Single hop
500 ms propagation delay
Dual hop
125 ms 125 ms 125 ms 125 ms
125 ms 125 ms
Terrestrial relayTX RX
TX RX
Figure 2-11 : Point to Point architecture
This architecture offers a point to point connection with fixed capacity. Some systems allow this
capacity to change easily from time to time. The connection consumes satellite capacity even though
there is not actual data traffic at that instant in time.
2.3.2 Star, Multi-Star, Meshed and dual architectures
With the exception of very simple cases, the point to point architecture is not often used. In practice,
several remote sites are connected to a central facility and several architecture are possible,
depending on the operating constraints.
SaT5G (761413) D3.1 December 2018
Page 30 of 77
The star architecture is the simplest one to connect several remote sites to a central facility. It can be
seen as several point to point links. However, multiplexing techniques are used to optimise the
spectrum usage on-board the satellite and the system is much more complex in terms of payload
architecture than in a point to point configuration. The same considerations as for the point to point
architecture apply, in particular configuration of the satellite and possible usage of a terrestrial relay
site for very long distance. For interactive and conversational services, two way propagation delay is
500ms between a remote site and a central facility and 1 sec between two remote sites (to be
doubled in case of a terrestrial repeater).
The mesh architecture enables direct communication between two remote sites, leading to reduced
delays. Advanced multiplexing techniques are used to optimise the spectrum usage on-board the
satellite. The mesh architecture often uses the same equipment than the star architecture, but the
cost may be different depending on the commercial strategy of the ground segment vendor. To be
noted is that the mesh architecture is mainly used with single beam satellites or when the remotes
sites are in the same beam.
The advantage of star architecture (and some mesh implementations) over fixed solutions such as the
point to point links is the ability to allocate capacity based on near real-time demand based on flexible
rules. It is possible to provide different Classes of Service (CoS) with different Peak and Committed
Information Rates (PIR and CIR) in capacity pools with one or more sites within these pools. The
capabilities to do this vary between ground segment vendors and their different systems.
Star and mesh architectures are often combined in a dual architecture where, for instance, several
remotes sites are grouped in a cluster. The clusters use mesh architecture internally but communicate
with other clusters via a single gateway (star architecture).
© 2
01
4 A
irb
us
De
fen
ce a
nd S
pa
ce –
All
rig
hts
re
serv
ed.
The
re
pro
du
ctio
n,
dis
trib
utio
n a
nd
uti
liza
tion
of
this
do
cum
ent
as
we
ll a
s t
he c
om
mu
nic
atio
n o
f it
s c
onte
nts
to o
the
rs w
ith
out
exp
res
s a
uth
oriz
ation
is
pro
hib
ite
d.
Off
en
der
s w
ill b
e h
eld
lia
ble
fo
r th
e p
ay
me
nt o
f d
ama
ges
. All
rig
hts
re
serv
ed
in th
e e
ve
nt o
f th
e g
ran
t of
a p
ate
nt,
util
ity m
od
el o
r de
sig
n.
Airbus Defence and Space Origin Technical Data. Does not contain U.S. Origin Controlled Technical Data
Star, Meshed and Hybrid architecture
ST1
ST2
ST3
ST4
GW
ST1 ST2
ST3 ST4
250 ms (500 ms intersite)
250 ms
ST1a ST2a
ST3a ST4a
250 ms
ST1b ST2b
ST3b ST4b
250 ms
GW250 ms
250 ms
Star
MeshedHybrid
Figure 2-12 : Star, Meshed and dual architecture
Most HTS satellites in orbit today use a “bent pipe” connection (introduced in section 2.2.2.1.1) linking
a gateway beam to a number of user beams.
The latest HTS may use multiple gateways, each connecting to their own group of user beams,
leading to a “multi-star” topology. Multi Gateway systems are mainly of interest for: frequency reuse
on the feeder link (i.e. limitation of frequency bands for the whole GW-SAT link service), GW site
diversity to maintain link availability with no degradation of the feeder link data rate and/or also for
geographical GW station location constraints with for example multiple countries to cover.
Future VHTS may actually use forms of dynamic capacity allocation such as beam hopping (see
section 2.5.1) in which at any moment in time there is a connection between a gateway and a set of
user beams. The gateway beams and user beams generally use different frequencies and in GEO
satellites are often covering different regions of the earth. This means that a signal transmitted by a
satellite terminal can only be received at the gateway and vice versa. Therefore, it will be complicated
to implement mesh architectures on this category of satellite.
SaT5G (761413) D3.1 December 2018
Page 31 of 77
Satellites with regenerative payloads and on-board switching can allow a mesh service.
2.4 Satellite network operation
2.4.1 Satellite System Roles and Function Elements
Figure 2-13 below describes a model of the active roles in the satellite communication ecosystem and
the functional elements under each one’s control.
Figure 2-13: Roles and functional elements of a satellite communications system
SaT5G (761413) D3.1 December 2018
Page 32 of 77
The satellite system functional elements identified in Figure 2-13 are:
Spacecraft (SC): The system may encompass one or several satellites, in GEO, MEO or
LEO orbits, each carrying communication payload for earth or inter-satellite communications;
Satellite Control Centre (SCC): The SCC is the entity that controls the satellite/s bus and
may include a unit communicating with the satellite(s) SCCU (satellite control communication
unit), and a Satellite Bus Command and Control (SBCC). The SCC is also known as TM/TC
(TeleMetry/TeleCommand) or TT&C;
Satellite Mission Centre (SMC): A functional element responsible to manage and control the
mission. It mainly refers to the control of the communication payload(s) of the satellite system.
Generally the SMC function is located at the SCC;
Satellite Network Control (SNC): A functional element that manages and sets the traffic
policies within a satellite network. Several satellite networks may share the resources of a
satellite system. The SNC is part of the more general Network Control Centre;
Satellite Gateway (GW): The Satellite Gateway is a functional element used to provide
interworking between the satellite network and one or more external terrestrial networks;
Network Control Centre/Network Management Centre (NCC/NMC): This is the functional
element that manages and controls (typically including real-time control) a communication
network in general;
Network backbone: A functional element that inter-connects any physical elements in a
network and enables distributed operation of functional elements;
Satellite Terminal (ST): A Satellite Terminal (ST) is the equipment that is used to provide
interworking between the satellite network and users, either via direct connection or via a
local network;
Device: Functional entity that allows applications used by the end user to connect to the ST.
Generally, a satellite communications system may serve a number of external networks, and may
include a single satellite or a constellation of satellites (e.g. in non-GEO systems), a set of gateways,
and several terminals.
The main roles and actors of the previously described satellite communication system are:
Satellite Operator (SO): it manages the whole satellite bus (or a satellite constellation bus).
The satellite operator owns and operates the spacecraft (SC), the satellite control centre
(SCC) which controls the bus. The SO business involves launching and operating satellites
and selling their transponder capacity to a mission operator. SO activities are performed at
the SCC and TM/TC stations;
Mission Operator (MO): it manages the satellite payload and sells/leases capacity to one or
several SNOs. The Mission Operator owns and operates the Satellite Mission Centre (SMC)
which controls the payload;
Satellite Network Operator (SNO): it operates, runs, and may own its own network, which is
composed of one or more satellite GW, STs, a NCC, a NMC, a SNC and a backbone to inter-
connect the satellite communication system to the terrestrial network;
Virtual Network Operator (VNO): it is similar to the Satellite Network Operator, is an entity
that provides service to end users. However, it does not own or operate a GW, and may not
own or operate ST’s. For satellite access, it uses the infrastructure of any SNO. It does
operate a NCC/NMC (which can be seen as a “client” NMC, which is delegated to control few
resources of a “master” NMC) and a backbone;
SaT5G (761413) D3.1 December 2018
Page 33 of 77
Service Provider (SP): it sells the service and/or the equipment to customers
(subscribers/end-users or other second-tier SPs). The SP is responsible for managing and
operating the related service provider elements in the STs and in one or more satellite GWs
(the SPs are responsible for the network and above layers of the ST and GW). The SP gives
access to a wide range of services involving terrestrial networks or not. Several categories of
SP can be identified: The Network Service Providers (NSP) or Application Service Providers
(ASP). Examples of NSP are Internet Service Providers (ISP) or Corporations (e.g. VPN).
Examples of ASP are Multicast Service Provider (MSP) and Internet Telephony Service
Provider (ITSP);
Subscriber (SUB): it buys services from SPs. It has a contract with one or several SPs for
the provision of services. Usually one of these SPs provides the STs to the SUB. The
subscriber delegates service usage to end-users, which make use of the services. A
distinction could be made between basic and advanced subscribers/end-users. Basic
subscribers/users include mainly fixed residential users, mobile users, and small enterprises.
Usually the number of basic customers is high. On the other hand, advanced subscribers
typically include enterprises, governments, and utilities. Such customers can ask for both
point to point and multipoint connectivity with high resource demand significantly varying in
time and from customer to customer;
End-users: the user is the entity that makes use of the services via a device. The devices
can connect directly or via a Local Area or Distribution Network to the ST; several devices
and hence several users can share the same ST. The user (via the device) is connected to
applications provided by SPs.
The systems above are supported by the SNO’s BSS/OSS (Business Support Systems and
Operations Support Systems). These provide the tools to manage services by creating sites and
assigning user profiles, create service reports and managing the onward billing for the services
delivered. The approach tends to be tailored to SNO’s business and the vendors systems used to
manage the service. Typically they offer human and machine-to-machine interfaces using web-based
protocols such as HTTP, REST (Representational State Transfer) and SOAP (Simple Object Access
Protocol). Often, for commercial effectiveness, single combined entities perform several of the roles
and functions above.
2.4.2 Satellite Services
The most popular services offered by the satellite telecommunication systems are the following:
Digital TV: As more regions transit from analogue to digital TV, terrestrial networks are being
pushed beyond their capacity to deliver TV programs. Saturated networks decrease
performance for all viewers, leading to poor image quality, lost packets and buffering.
Unaffected by difficult terrain or long distances from urban centres, satellite provides the
same high-quality picture and broad range of content to all viewers within the footprint,
without the need for heavy investment in ground infrastructure. Around the globe well over
700 million TV households are served by satellite, either directly or by cable head end feeds,
with more than 20000 TV channels;
Cellular backhaul: One of the most significant challenges in the mobile services market is
achieving scalable, flexible backhaul, particularly as markets move to 4G/5G networks which
are forecast to need to support 1,000 times more data traffic by 2020. The backhaul
optimisation technologies used to reduce bandwidth cannot solve all backhaul challenges,
especially as the roll-out of LTE continues. As a result there is a need for cost-effective mobile
backhaul over satellite for global 3G/4G/5G expansion to relieve congestion. Mobile operators
must deliver their services at the lowest possible total value of ownership and the cost of the
backhaul is one of the most important factors. Traditionally, satellite backhaul was an
expensive option, but with HTS this is no longer the case – even in areas supported by
SaT5G (761413) D3.1 December 2018
Page 34 of 77
terrestrial access (e.g. [9] states “The arrival of HTS together with advanced ground segments
is making satellite a viable option for backhauling 3G and 4G base stations.”). Within the next
few years, it is predicted that the cost of Mbps over satellite will drop by a factor of six.
Satellite backhaul opportunity is massive compared to current levels of coverage and the
emerging regions present the largest addressable market opportunities;
Broadband services: Nowadays there is an increasing demand for data and service quality
everywhere and anytime. In this context, satellites enter the scene providing broadband
connectivity in every remoted area. O3B that is owned and operated by SES, operates a
MEO satellite constellation, combining the relatively large coverage of satellite with medium
latency to deliver satellite internet services to emerging markets. This means that SES’s
services can meet the same performance requirements as terrestrial connectivity and the
customers on the ground will be able to use fibre-like internet even if they are in a remote
region. Many providers also offer a direct to home broadband service using GEO spacecraft,
either directly (such as Hughes and Viasat in the USA) or via national/regional resellers (such
as Avanti, Eutelsat and SES in EMEA). Furthermore, there are LEO solutions currently under
design, such as the OneWeb satellite constellation system (see Section 2.2.1.1), which can
provide global Internet broadband service;
Mobile communications: Despite the proliferation in cellular and terrestrial communication
services around the world, there will still be vast geographic areas not covered by any
wireless terrestrial communications. These areas are open fields for mobile satellite
communications and they are also key markets for the operators of geostationary and non-
geostationary satellites like SES to provide connectivity to platforms on the move, such as
airplanes, trains and ships. At sea everyone, from cruise ships passengers to the crew on a
shipping liner, want to feel at home by accessing the internet. The same goes in the air,
where passengers and airlines are both finding that high-performance connectivity makes
them truly mobile. In this context, SES has entered in the market of inflight connectivity,
where more than 50% of the satellite connected aircrafts use SES’s capacity at some point,
and further plan to launch and deliver inflight connectivity and services to airline customers,
through SES-17, in 2020. Other significant players in this segment include INMARSAT,
Viasat, and Iridium.
2.5 New trends in satellite communications
In this section, the new trends in satellite communications are discussed. Three main axes are
illustrated, representing the main directions in which future satellite systems will put their efforts. All
those new concepts will potentially be enablers for the SaT5G use cases and thus, are briefly
introduced in this section. These are:
Very High Throughput Satellite (GEO-VHTS);
Software-Defined Payloads;
Broadband mega constellations;
SDN/NVF applied to Satcom.
2.5.1 Very High Throughput Satellites (VHTS)
The need for cost reduction and adaptability to an ever changing market, has pushed operators to
look for more innovative GEO satellite solutions fostering higher total aggregated throughputs,
enhanced flexibility capabilities (in coverage, resources, and in-orbit reconfiguration) and providing
multi-service over large coverage areas. This leads to a new wave of satellite systems with much
more advanced features and with associated design/technical challenges (i.e. VHTS).
The next generation of VHTS satellites needs to tackle:
Increasing overall throughputs: from 250 Gbps up to 1 Tbps;
SaT5G (761413) D3.1 December 2018
Page 35 of 77
Implementing in-orbit flexibility mechanisms: to enable the best use of satellite resources
during the satellite lifetime. Indeed, strong market incertitude is expected in the next years on
broadband and backhauling market, thus leading to quick changes in satellite business
opportunities. As result, satellite-based solutions must include effective flexibility mechanisms
allowing for post-launch system reconfiguration;
While ensuring an attractive economic equation due to a tight economic environment and
fierce competition that puts strong pressure to reduce the acquisition cost of in-orbit capacity,
with the challenge of cost targets around 1M€ - 2M€/Gbps3.
To respond to such challenges, a significant increase in spectrum reuse must be targeted by
increasing the number of beams and reducing size for a given coverage. In addition, innovative
designs based on active antennas, powerful BFN (Beam Forming Network) capabilities and advance
and flexible system techniques are also required. A good example of that is the beam hopping
technique.
Beam hopping:
Beam hopping in satellite systems is a new way to exploit a multi-beam satellite. Rather than
allocating a small amount of spectrum to each beam with a fixed frequency pattern, all the beams
may use the entire band at a particular moment in time. The main interest of beam hopping is the high
level of flexibility provided by this technology to cope with the evolution of the traffic demand, the
reduction embarked in hardware and the fact that it is the enabler of a large coverage area.
Figure 2-14 : Beam hopping principle
Figure 2-14 illustrates the principle of the technique. A sequence composed by a specific number of
time slots is defined. In each time slot, a given number of active beams are defined (sub-set of beams
among all beams on-ground), transmitting simultaneously during the time slot period of time.
Following the desired criteria, the sequence is derived targeting the maximisation of useful capacity
with respect to a given traffic demand. The sequence can be updated depending on the evolution of
3 For a satellite cost of €1.5M (in orbit) a simple analysis suggests this cost element equates to €8.33 per Mbps
per month. On top of this one must add the costs of control and access plus operator margin, all of which might
at least double this figure, nevertheless this shows a significant reduction from today’s best costs.
SaT5G (761413) D3.1 December 2018
Page 36 of 77
the demand, enabling an interesting degree of flexibility. However, it should be noted that the level of
flexibility is somehow dependent on the payload design capabilities.
2.5.2 Software defined payload/satellites
The software defined payloads are the maximum expression of fully flexible and reconfigurable
satellites and the holy grail of the commercial broadband satellite industry. Basically, it corresponds to
a full processed on-board payload with advanced active antennas enabling full reconfiguration of
coverage, dynamic resource allocation and full regenerative capabilities. The most recent example of
that is Eutelsat QUANTUM satellite.
Using a software-based design, Eutelsat QUANTUM (first satellite to be launched in 2018) will be the
first universal satellite to repeatedly adjust to business requirements and be able to operate in any
geographic region in the world. Eutelsat Quantum's in-orbit reprogrammable features will set a new
standard in flexibility and will principally address markets that are highly changeable and mobile:
Communications on the move: dynamic beam shaping and vessel-tracking capabilities can be
optimised for power and throughput as required by maritime, aeronautical and land-based
transportation;
Data networks: bespoke design of wide-area networks and dynamic traffic shaping thanks to
full coverage and capacity steering, responding to demand where and when needed;
Government users: rapid response for public protection and disaster recovery (because of
fully reprogrammable coverage footprint), as well as secure control using the latest encryption
technology (because of on-board processing which can be frequently updated).
This type of satellites presents a great flexibly and configurability but requires high processing
capabilities (impacting non-negligibly power and mass of the satellite), which affects the total
aggregated throughput that can be reached by those systems.
2.5.3 Broadband mega-constellations
An alternative to GEO satellites to provide telecommunication services are the so-called mega
constellation which uses LEO. The interest in these constellations is that they use an orbit that is
much lower than the classical GEO orbit. This leads to much better link budgets (~20 dB) and
propagation delays 10 times smaller than in GEO satellites. These constellations generally also cover
the whole earth, including polar areas. The main inconvenience is that these constellations are not
fixed over a particular place on earth, so that a remarkable number of satellites is required to ensure
service continuity, and tracking of the satellites is required to a good throughput.
An example of mega constellation is the OneWeb constellation. The OneWeb satellite constellation—
formerly known as WorldVu—is a proposed constellation of approximately 648 satellites expected to
provide global Internet broadband service to individual consumers as early as 2019. The 648
communication satellites will operate in circular low Earth orbit, at approximately 1200 km of altitude,
transmitting and receiving in the Ku band of the radio frequency spectrum.
Other mega constellation initiatives have also been advertised by players like Telesat and Space X.
2.5.4 SDN/NFV
TO BE COMPLETED
SaT5G (761413) D3.1 December 2018
Page 37 of 77
3 3GPP Reference architecture for 5G systems
3.1 5G introduction
After the introduction and roll-out of 4th generation (4G) mobile networks, operators and handset
manufacturers, as well as leading research institutions in the field, have launched a series of R&D
initiatives to develop the 5th generation of mobile technology, called 5G, intending to commercialize it
by 2020. 5G is based on three key pillars: enhanced Mobile Broadband, Massive IoT and Low latency
and ultra-reliable communications as shown by Figure 3-1.
Figure 3-1: IMT2020 5G use cases
However, the introduction of the verticals (i.e. stakeholders in very different markets) is one of the
biggest revolutions of 5G. Serving different verticals with different services and indeed network slices
is axiomatic to 5G. From a radio point of view, new spectrum4 and non-3GPP access technologies,
satellite is meant to play an important role to, amongst other drivers, provide the reach needed by 5G.
From a core network point of view, the biggest difference is the introduction of technologies such as
NFV, SDN and MEC. This allows to open the network to new services but also to have flexible
networks than can adapt to services or vertical specific needs.
Within 3GPP, the SA2 Working Group (dealing with System Architecture) has been working on an
architecture that can support all these different ideas and to illustrate the progresses, the basic overall
5G network architecture is depicted in Figure 3-2. In June 2018, 3GPP completed the first set of 5G
specifications in the Release 15.
The SaT5G project contributions to SA2 and other working groups and standardisation organisations
is are dealt with in “D6.2 – Standardisation Action Plan” [10].
4 A review of spectrum is out of scope of SaT5G, in part as this project focusses more towards 3GPP whereas
spectrum is managed by ITU, CEPT and so on.
SaT5G (761413) D3.1 December 2018
Page 38 of 77
5G
UE
N3 RAN
5G RAN
5G CN DN
Figure 3-2: Basic overall 5G network architecture
The architecture consists of the following entities:
A User Equipment (5G UE),
An Radio Network (RAN), which could be 3GPP RAN (5G RAN) or non-3GPP RAN (N3
RAN),
A Core Network (5G CN), which connects to
A Data Network (DN) like internet.
Characteristics of the above architecture are the following:
The 5G UE connects to the 5G CN through a (or multiple types of) Radio Access Network;
through this connection the 5G UE is authenticated and connected to a DN. A 5G signalling
protocol is used between the 5G UE and the 5G CN;
The Radio Access Network can be either a 5G RAN or a non-3GPP RAN. In the first case,
the radio interface between 5G UE and the 5G RAN is completely defined by 3GPP
standards. In the second case, the radio interface between 5G UE and the N3 RAN is not
according to 3GPP standards. In both case, however, the interface(s) between the RAN and
the 5G CN are the same.
The above architecture is also applicable for the cases where local access (i.e. edge
computing) is used and for the cases where the RAN is extended to support relay functionality
(e.g. for the support of wireless backhaul).
In addition to the above basic architecture also alternative architecture are being developed, such as
architectures for direct UE-to-UE communication, and architectures for hybrid fixed and wireless
access networks. For SaT5G these networks architecture are not in scope.
3.2 5G network architecture: core network perspective
Compared to previous generations, the 3GPP 5G system architecture is service based. This implies
that the architecture elements are defined as network functions that offer their services via interfaces
based on a common framework to any network function that is permitted to make use of the services
provided. Network repository function (NRF) allows every network function to discover the services
offered by other network functions. This architecture model, which further adopts principles like
modularity, reusability and self-containment of network functions, is chosen to enable deployments to
take advantage of the latest virtualization and software technologies.
The architecture depicted in Figure 3-3 represents the 5G service-based core network architecture (in
blue), but it also includes a number of traditional reference points towards the UE, RAN, and the User
Plane Function (UPF). Note that the architecture depicted here explicitly shows the use of multiple
UPFs in chain. This illustrates the potential for having edge computing (see Section 3.4.3).
In Section 3.2.1 the Network Functions depicted in this architecture are described and in Section 3.2.2
the general functional principle of the 5G network during connection establishment is described, as
well as some procedures that occur during the lifetime of a connection.
SaT5G (761413) D3.1 December 2018
Page 39 of 77
NRFNEF
5G UE xRAN UPF
DN
N3
N6
N2
N4N1
CPF
UPF
DN
N6
N9
N4
AMF PCF AFSMF
AUSF UDMNSSF
Nnssf Nausf
Namf
Nudm
Nsmf Npcf
Nnef Nnrf
Naf
Figure 3-3: 5G service based core network architecture
3.2.1 Overview of 5G core network function and interfaces
In this section an overview of the most relevant 5G core network functions and their interfaces is
provided. For more details the reader is referred to 3GPP TS 23.501 [13], and 3GPP TS 23.502 [14].
Access and Mobility Function (AMF) is the initial core network function reached after initialisation of
a mobile device. It handles Connection Management, Registration Management and Mobility
Management (see Section 3.2.2). It supports the authentication of the UE with the AUSF and UDM
and is supports Network Slice Selection through the NSSF. It selects the SMF for the subsequent
session management procedures. The RAN nodes (e.g. gNB) have a signalling interface over the N2
reference point. The UEs have a signalling interface over the N1 reference point for the so-called NAS
(Non Access Stratum) signalling. This function also passes NAS signalling message related to
Session Management to the appropriate SMF over the Service Bus.
Session Management Function (SMF) is the core network function responsible for setup, modify
and release of PDU Sessions (i.e. ‘bearers’). It also controls one or more UPFs for these PDU
sessions (see Section 3.4.2). It controls traffic steering in the UPF in case of edge computing (see
Section 3.4.3). This function assigns IP addresses to the UE. It interacts with the Policy Control
Function in order to handle Quality of Service. It also handles session and service continuity and it is
involved in some types of the handover procedures.
User Plane Function (UPF) is the core network function responsible for all user plane handling, such
as packet routing & forwarding, packet marking, packet buffering, traffic usage reporting (e.g. for
charging purposes), user plane part of QoS enforcement. It may also be the anchor point for the PDU
session and support branching in case of multi-homed PDU sessions (see Section 3.4.3).
Policy Control Function (PCF) is the core network function responsible for policy and charging
control. It provides policy rules to the SMF concerning policy rules to be enforced. It uses the Unified
Data Repository (UDR) for the storage of relevant information.
Network Exposure Function (NEF) is the core network function responsible for exposure of
capabilities and events to other Network Functions, such as the Application Function. It can also be
SaT5G (761413) D3.1 December 2018
Page 40 of 77
used to providing access to 3rd
parties to capabilities and events of the network. It uses the UDR for
the storage of relevant information.
Network Repository Function (NRF) is the core network function that enables service discovery of
Network Functions to other Network Functions.
Unified Data Management (UDM) is the core network function supporting the generation of
authentication credentials and user identification handling. It handles the retrieval of subscription data,
UE context data, and UE authentication data. It uses the UDR for the storage of relevant information.
Authentication Server Function (AUSF) is the core network function supporting authentication.
Non 3GPP Interworking Function (N3IWF) is the core network function enabling untrusted non-
3GPP access. It supports the setup of an IPsec tunnel between the N3IWF and the UE. Towards the
core network it exposes the N2 and N3 interface making the non-3GPP RAN behave the same as
3GPP RAN equipment. It encapsulates user plane traffic over the N3 interface to the core network.
Network Slice Selection Function (NSSF) is the core network function responsible for handling slice
selection. It provides the AMF for a given slice and it provides the NRF to be used for selecting the
Network Functions of the given slice. It also provides the allowed and configured slice identifiers.
Application Function (AF) is the core network function that is the point of contact for services
outside of the 3GPP network. If trusted it can interact directly to other Network Functions (such as the
PCF or the SMF), but if not trusted it will access the other functions through the NEF. This function
can be used to influence the traffic steering for edge computing via the SMF.
3.2.2 Most relevant 5G network procedures
When activating a mobile device (UE), a couple of actions occur. In general two phases can be
distinguished:
Phase 1: in this phase Connection, Registration and Mobility Management occurs including
Authentication and Slice Selection;
Phase 2: in this phase Session Management, and User Plane Management including Policy
Control and Quality of Service handling
After the initial phases, the mobile device may experience some changes such as becoming idle of
moving to a different location. In that case the following activities can take place:
Service request, Paging, Mobility Registration Update, or Handover.
In the following a short description of the above activities will be given.
Initialisation phase 1:
Connection Management: Before activation of any mobile device the RAN nodes (e.g. gNBs) will
initiate a connection to the 5G Core Network over the N2 interface. At activation of a mobile device,
this will initiate a RRC (Radio Resource Control) connection to the RAN nodes with NAS signalling
intended for an AMF and provides a list of slice identities in this connection. Based on this list, the
RAN node will select an AMF and forward the NAS signalling to selected AMF. Through this
mechanism the UE establishes an NAS signalling relation over the N1 reference point.
Registration and Mobility Management: After establishing the NAS signalling relation with the AMF the
NSSF function may be queried for information on the relationship of (subsequent) functions in the
slices received from the UE. The UE is further authenticated against the security information through
the AUSF and UDM. Eventually a selection is made of the SMF that shall handle subsequent PDU
Session requests from the UE. For certain slices one or more other AMFs may be selected for
handling access to the slices. After completion of the Registration and Mobility Management
procedures the UE is registered in the 5G Core Network and initially also in Connected state (i.e. not
in Idle state).
SaT5G (761413) D3.1 December 2018
Page 41 of 77
Initialisation phase 2:
Session Management, User Plane Management: After registration the UE may initiate the creation of
one or multiple PDU Sessions through the functionality of the SMF. The SMF will initiate user plane
connections through one or more UPFs and apply Policy Control through the PCF function, which
(among other things) handles the establishment of the appropriate QoS for the PDU Sessions.
Service request and paging:
A mobile device may become disconnected from the mobile network (i.e. enter the idle state). When
the mobile device wants to send user data it has to reinitiate the connection by issuing a service
request. If the mobile network needs to send user data to the mobile device, it initiates paging to the
device after which the mobile device initiated a service request. After entering the Connected state
the mobile devices or the network can send user data again. Note that entering the Idle state does not
mean that the device is deregistered.
Mobility Registration Update and handover:
In case a mobile device enters a tracking area outside of its registration area it is required to send a
mobility registration update to the network. In some cases a moving devices also requires a handover
to a new gNB. It may or may not require relocation of UPF, or even a new AMF. In all cases the SMF
will be unchanged.
3.3 5G radio access technologies
Within 5G networks various radio access technologies can be used, e.g. Wifi, Wireline, but also
Satellite. The native 5G radio access technology defined for 5G is called NR (New Radio). This type
of radio access is called 3GPP access. All other types of access are commonly referred to as non-
3GPP access.
Non-3GPP accesses can either be termed untrusted or trusted, but in both cases additional functions
(e.g. N3IWF, TNGF) are used to connect the radio networks to the 5G Core Network (see Figure 3-4).
untrusted
N3RAN
5GRAN
N3IWF
trusted
N3RANTNGF
N3
N3
N3
NR
Figure 3-4: Non-3GPP access with interworking functions
Note that currently only untrusted non-3GPP access is specified in normative texts (e.g. in TS
23.501), making use of the Non 3GPP Interworking Function (N3IWF). The N3IWF is responsible for
securing the communication between the UE and the core network by applying an IPsec tunnel, it is
responsible for exposing the N2, and N3 interface to the core network, and it is responsible for
transporting the N1 signalling between the 5G UE and the 5G Core Network (3GPP TS 24.502 [11]).
Ideas on trusted non-3GPP access are currently being formulated in the 3GPP informative report TR
23.716 (on Wireless and Wireline Convergence). In this technical report the interworking function
connecting the trusted non-3GPP access to the 5G Core Network is sometimes called a Trusted Non-
SaT5G (761413) D3.1 December 2018
Page 42 of 77
3GPP Gateway Function (TNGF) and sometimes the N3IWF is (re-)used. Also in this case, the TNGF
is responsible for exposing the N2 and N3 interfaces to the core network and for transporting the N1
signalling between the 5G UE and the 5G Core Network.
In this rest of this section the focus will be about the 5G RAN as specified in 3GPP documents TS
38.300 [12] and TS 38.401 [13]. Note that in radio network specifications 5G RAN is called NR RAN.
The basic component of NR RAN is the gNB which provides NR radio connectivity over the Uu
interface to the 5G UE and connects to the 5G core network via the NG interface. Note that the NG
interface is mapped onto the core network reference points N2 (control plane) and N3 (user plane). A
gNB can interact with other gNBs (e.g. for handover purposes) over the Xn interface.
The gNB can be decomposed into a central unit, called gNB-CU, and one (or more) distributed units,
called gNB-DU. The interface between the central unit and a distributed unit is the F1 interface.
In Figure 3-5 the architecture and interfaces of a gNB are depicted.
gNB
gNB-CU
gNB-DU
gNB-DU
gNB-DU F1 N3
Xn-C
NG to 5G CNNR Uu from 5G UE
Xn to other gNB
Figure 3-5: Interfaces and internal architecture of a gNB
Similar to the 4G (eNode-B) Relay – as specified in 3GPP TS 36.300 (and before that in TR 36.806),
also gNB Relay is being formulated for 5G. Currently only informative text is has been created in
3GPP TR 38.874 [14], which is still in draft state. The topic of TR 38.874 is Integrated Access and
Backhaul (IAB) and that is why the relevant nodes are called IAB-node and IAB-donor. They
correspond to the 4G equivalents of Relay Node and Donor eNB, respectively. In Figure 3-6 the
overall architecture for 5G relay is depicted. Note that unlike 4G, multi-hop relay is proposed in 5G.
SaT5G (761413) D3.1 December 2018
Page 43 of 77
IAB-donor
CU-CP
DU DU
Wireline IP
IAB-node
IAB-node
IAB-node IAB-node
UE
UE UE
CN
Wireless backhaul link
Wireless access link
IAB-node
CU-UPOther
functions
Wireless backhaul link
Figure 3-6: 5G relay architecture
In current 3GPP TR 38.874 a number of more detailed architecture options have been elaborated. In
Figure 3-7 and Figure 3-8 two of them are provided. The first option makes use of the architectural
split of a gNB in CU and DU components, the second option considers the gNB in unsplit form. Note
that although the second option makes use of the (core network) function UPF, this does not imply
that these architectures support edge computing natively.
MT
UE
IAB Node IAB Node IAB Donor
MT
NR Uu
NG
DU
F1*
NGC
DU CUDU
F1*
NR Uu
RLC/Adapt RLC/Adapt
UEUE NR Uu NR UuNR Uu
GTP-U
UDP
IP
L1/L2
RLC/Adapt
PHY/MAC
F1-U*
F1-U
RLC*/Adapt*
PHY/MAC
F1-U*GTP-U
Figure 3-7: 5G relay architecture using split gNB
gNBgNB MT
UE
IAB Node IAB Node IAB Donor
MTNR Uu
NG
NG
gNB
NG
NGC
NR Uu
PDU session
UEUE NR Uu NR UuNR Uu
UPFUPF
PDU session
GTP-U
UDP
IP
L1/L2
PHY/MAC
NG-UNG-U
SDAP/PDCP
GTP-U
UDP
IP
RLC
PHY/MAC
NG-U
SDAP/PDCP
GTP-U
UDP/IP
802.1
RLC
Bearer Bearer
Figure 3-8: 5G relay architecture using unsplit gNB
3.4 5G topics
3.4.1 Network slicing
One of the important new features of 5G networks is the concept of network slicing. A network slice
can be viewed as virtualized network running on top of the physical network infrastructure of an
operator which is tailored to a specific type of applications or for specific customers (i.e. the verticals).
SaT5G (761413) D3.1 December 2018
Page 44 of 77
An example of such a division into slices is depicted in Figure 3-9, where an eMBB (enhance Mobile
Broadband) slice, a IoT (Internet of Things) slice and an MVNO slice is presented. In the diagram it is
shown how a UE can make use of slice functionality in the RAN and in Core Network.
Figure 3-9: Example of network slicing
From the perspective of the 5G Core Network a slice will consist of a number of Network Function
instances, but some Network Function (instances) may be shared by multiple slices. In Figure 3-10
this is depicted in graphical form. Note that the diagram suggests that a RAN element is part of a
specific slice. In reality a RAN is not divided in separate functional entities but rather in physical
nodes. In this case, the nodes will normally be slice aware, but they will not be part of only a single
slice (see Figure 3-11). A similar situation may be applicable to the UPF, e.g. in cases where a UPF
consists of dedicated hardware and is not merely a software function.
During the initialization phase of mobile connectivity, the RAN nodes will select appropriate AMFs for
the slice (identities) that are provided by the UE. Based on the subsequent connectivity process, it
may be the case that for part of the slice (identities) provided by the UE other AMF need to be
included. Thus, multiple AMFs may play a role in accessing to a diversity of slices as illustrated in
Figure 3-11.
SaT5G (761413) D3.1 December 2018
Page 45 of 77
UE (R)AN UPF
AF
AMF SMF
NRF PCF
DNN6
NEFUDM
N3
N2 N4
AUSF
Nausf Namf Nsmf
NnrfNnefNudm Npcf Naf
NSSF
Nnssf
NFs in
multiple
slices
Slice specific NFs
Figure 3-10: Division of NFs over a single slice or shared between slices
(R)AN
AMF#2
SMF#1
PCF#1
AF#1
UPF#1
SMF#2
UPF#2
SMF#3
AMF#1
UE
UPF#3
UPF#5
UPF#6
UPF#4
UE
Slice#1
Slice#2
Slice#3
PCF#2
AF#2
Figure 3-11: Role of AMF and RAN in slice selection
3.4.2 Control user plane separation
SDN is advocating the split of networking equipment (such as routers, firewalls, load balancers, etc.)
into an SDN controller part and (one or more) SDN switch parts. Purpose of this split is to concentrate
the ‘dumb’ packet forwarding functionality to the SDN switches and the ‘intelligent’ routing decisions
and packet handling functionality in the SDN controller.
In 3GPP the above SDN split between Control Plane and User Plane has been actualized in a
number of so-called CUPS (Control and User Plane Separation) architectures. For 4G this has
resulted in a SGW-C/PGW-C and SGW-U/PGW-U split. In 5G this concept has been evolved in the
split between SMF (as SDN Controller) and the UPF (as SDN Switch), see Figure 3-12.
SaT5G (761413) D3.1 December 2018
Page 46 of 77
UPF
N4
UPF
N4
SMF
UPF
N4
N9 N9
SDN Controller
SDN Switches
Packet Forwarding Control Protocol
Figure 3-12: Control plane and user plane separation in 5G
In contrast to 4G, in 5G a single controller (SMF) can control multiple switches (UPF) via the N4
reference point. For the protocol between the SMF and the UPF in 3GPP the new protocol Packet
Forwarding Control Protocol (PFCP) has been defined. The PFCP is not compatible with the
commonly use OpenFlow protocol since it is based on the more traditional 3GPP-defined GTP-C
protocol.
3.4.3 Edge computing
In order to improve latency and capability to cope with network loads in 5G the concept of edge
computing has been developed. Edge computing allows traffic to exit the 3GPP core network
(towards a Local Data Network) closer to the UE’s access point of attachment (i.e. close to the RAN).
The mechanism designed makes use of a local UPF in combination with central UPFs for normal
traffic (towards a Central Data Network). In Figure 3-13 this architectural concept is provided.
NEF
UPF
DN
N6
N4
UPF DNN6N9
N4
AFSMF
Nsmf
Nnef
Naf
N3xRAN
Local Data Network
Central Data Network
PCF
Npcf
Figure 3-13: 5G edge computing architecture
SaT5G (761413) D3.1 December 2018
Page 47 of 77
The enablers supporting edge computing are the following.
1. The 5G Core Network selects a UPF close to the UE.
2. The 5G Core Network applies Local Routing and Traffic Steering so that certain traffic is
routed to the Local Data Network. This is realized via the SMF instructing the UPF
through the use of traffic filters. Traffic steering may depend on the UE’s subscription
data, the UE location, or be based on information from the AF.
3. For the purpose of mobility, session and service continuity shall be enabled.
4. An Application Function may influence the UPF selection and traffic routing via the PCF
and/or the NEF. The use of the NEF is needed in case the AF is not trusted to have
direct access to other Network Functions.
5. The PCF may provide rules for QoS Control and Charging for traffic routed to the Local
Data Network.
Local routing and traffic steering assumes that a single PDU session may simultaneously correspond
to multiple N6 interfaces.
3.4.4 Security mechanisms
Within 3GPP network various security mechanisms are and may be applicable. In this section some
of them are elaborated in detail.
At the initialisation (i.e. Registration) phase of the mobile connectivity the 5G UE and the 5G Core
Network perform mutual authentication (i.e. the network authenticates the UE and the UE
authenticates the network). This is performed in the same way as in 4G networks and is based on
shared secret key information in both the UE (e.g. in the USIM card), and in the network (e.g. in the
UDM/UDR). The exchange of authentication information occurs from the UE over the N1 interface via
the Security Anchor Function (SEAF) which is collocated with the AMF via the AUSF to the UDM, see
Figure 3-14.
AMF w/
SEAF
AUSF UDM
Nausf
Namf
Nudm
5G UE N1
Figure 3-14: Network functions and interfaces involved in 5G authentication
Common practice in mobile networks is the use of security mechanisms for securing (partially)
untrusted transport networks. In those cases, often IPsec connections are used controlled by Security
Gateways (SeGW), see Figure 3-15. Sometimes the SeGW on the RAN side is incorporated in the
RAN nodes themselves.
5G UE 5G RAN UPF DNN1 over NR Uu N1, N2, N3 N6
Transport Network
SeGW
CPF
IPsec tunnel carrying N1, N2, N3 and UP traffic
SeGW
Figure 3-15: Use of Security Gateways (SeGW) in case of untrusted transport networks
In 5G for the case of untrusted non-3GPP access the Network Function Non-3GPP InterWorking
Function (N3IWF) has been specified. The UE shall establish an IPsec connection to the N3IWF via
SaT5G (761413) D3.1 December 2018
Page 48 of 77
the NWu interface, see Figure 3-16. The interface Y1 is out-of-scope of 3GPP, and the interface Y2 is
for the transport of NWu traffic.
untrusted
N3RAN
N3IWFY2
NWu
Ipsec tunnel with UP and CP traffic from UE to 5G CN
5G UE
Figure 3-16: Untrusted non-3GPP access using N3IWF
3.4.5 The concept of relay
In 3GPP relay is related to two different topics:
Relay by a radio node (Relay node);
Relay by user equipment (Relay UE).
Relay by a radio node has been specified in LTE in TS 36.300 (see section 4.7). In that specification a
so-called Relay Node (RN) is wirelessly connected to a so-called Donor eNB (DeNB). The RN acts as
an eNodeB towards the UE and it acts as a UE towards the DeNB. An architectural diagram depicting
this situation is given in Figure 3-17 below.
eNB
MME / S-GW MME / S-GW
DeNB
RN
X2 E-UTRAN
Figure 3-17: Relay node architecture in LTE
The relay node concept was introduced in 3GPP release 10 to solve performance issues like the
reduced data rate. It is also used to reach areas where it is difficult or not (yet) possible to deploy
terrestrial communications to towers. As described in the standard, the relay nodes are responsible of
providing extended coverage and capacity at cell edges at low cost. The relay node was initially
designed as a simple radio repeater that was receiving, amplifying the base Station’s signals and was
diffusing them with all their noises and imperfections. Since LTE, the RN is more than a simple
repeater as it extracts data from the received signal, it applies the noise correction techniques and
retransmits the new “clean” signal in its own coverage zone.
As discussed in Section 3.3, in 5G a similar relay concepts exemplified by radio nodes is being
studied in TR 38.874. It should be noted that the 5G relay concept as currently formulated in TR
38.874 does not address the support of MEC. That is, it is not foreseen to have an IAB-node
connected to a local Data Network for support of edge computing. However, the required architecture
– with a local UPF between the gNB part and the UE and MT parts of the IAB-node – resembles part
of the relay architecture for the unsplit gNB (see Figure 3-18 below – architecture option 2a from TR
38.874).
SaT5G (761413) D3.1 December 2018
Page 49 of 77
gNBgNB MT
UE
IAB Node IAB Node IAB Donor
MTNR Uu
NG
NG
gNB
NG
NGC
NR Uu
PDU session
UEUE NR Uu NR UuNR Uu
UPFUPF
PDU session
GTP-U
UDP
IP
L1/L2
PHY/MAC
NG-UNG-U
SDAP/PDCP
GTP-U
UDP
IP
RLC
PHY/MAC
NG-U
SDAP/PDCP
GTP-U
UDP/IP
802.1
RLC
Bearer Bearer
Figure 3-18: Relay architecture with unsplit gNB (from 3GPP TR 38.874)
An architecture supporting relay with edge computing could be as depicted in Figure 3-19 below. Note
that in this architecture the local UPF is being controlled over N4 from the core network and has both
an user plane connection over N6 to the local data network and a user plane connection over N9 to
the central data network. In the diagram the NG interface represents both the N2 and N3 interfaces
and it carries the N1 interface between UE and the 5G core network.
gNBgNB MT
UE
IAB Node IAB Donor
NG
NG
NGC
NR Uu
UE
NR Uu
NR Uu
UPF
PDU session
Bearer
PDU session
Bearer
DN
N6
N4 + N9
Figure 3-19: Relay architecture with edge computing (NOT in 3GPP)
Relay by user equipment in 3GPP is specified in TS 23.303. This type of relay is based on Proximity
Services (ProSe) and the 3GPP term for a UE acting as relay is ProSe UE-to-Network Relay. An
architectural diagram depicting this type of relay is given in Figure 3-20 below.
Remote UE
ProSe UE - to - Network
Relay eNB
Public Safety
AS PC 5 Uu
EPC
SGi
Figure 3-20: UE based relay architecture
3.4.6 Traffic steering
In 3GPP a study is currently ongoing on key issues and solutions for Access Traffic Steering,
Switching, and Splitting between 3GPP and non-3GPP access networks. The resulting document will
be the (informative) report 3GPP TR 23.793. The concept of traffic steering studied distinguishes
between:
Access Traffic Steering, i.e. mechanism to select an access network for a new data flow;
Access Traffic Switching, i.e. mechanisms to move ongoing data flows from on access
network to another access network;
Access Traffic Splitting, i.e. mechanisms to split traffic of data flows over multiple access
network.
The study also includes the concept of:
Multi-Access PDU Session, i.e. a PDU Session that use multiple access networks
simultaneously.
SaT5G (761413) D3.1 December 2018
Page 50 of 77
Although the topic of the study only applies to traffic steering over access networks and hence is not
directly applicable to traffic steering over multi-link backhaul, it is still illustrative to point out a number
of architectural proposals that may become included in future normative specifications.
A high level architectural solution that is being proposed in depicted in Figure 3-21 below.
UEUntrusted Non-
3GPP Access
3GPP
Access
Data
NetworkN3IWF
UPF
AMFSMF PCF
AF
AUSFUDM
N2
N3
N3
N2N14
N1N15
N6
N4
N13
N12 N10N8
N5N7N11
N9
Y1
Y2N1NWu
UE-AT3SF
UPu-AT3SF
CP-AT3SF PC-AT3SF
UDR-AT3SF
N25
UPc-AT3SF
Figure 3-21: Solution 1 from TR 23.793: proposed architecture framework
From the above architecture proposal, it can be seen that traffic steering may need specialized
functionality in UE, SMF, UPF, PCF and UDM. An architectural proposal for the support of Multi-
Access PDU Sessions is depicted in Figure 3-22 below.
3GPP
access
Non-3GPP
accessN3IWF
UE
(including
RG)
UPF
(PSA)
N3
N3
Application
clientServer host
UPF
UPF
N9
N9
MA PDU
PDU
PDU
(linked)
N6
Figure 3-22: Multi-Access PDU Session proposed architecture
As can be seen from the above proposal, multiple UPFs are used in combination with a single ‘end’
UPF which acts as the PDU Session Anchor (PSA).
In addition to the above proposals also additional proposals are given. For instance:
Traffic Flow Control Protocol, i.e. a protocol on top of 5G Access Network protocol layers and
on top of the GTP-U protocol to handle Multi-Access PDU Sessions;
Policy Control based solutions;
Multipath TCP based solutions;
Solutions for the Uplink Classifier case, i.e. for the case with edge computing.
3.4.7 Management and orchestration of 5G networks and network
slicing
SaT5G (761413) D3.1 December 2018
Page 51 of 77
In 3GPP management and orchestration of 5G networks has been focussed on the management and
orchestration of network slicing. An overview of this is presented in 3GPP TS 28.530 [15] which
contains the basic concepts and a set of use cases. The basic concepts include:
The distinction between a Network Operator (NOP), a Communication Service Provider
(CSP), and a Communication Service Customer (CSC); the Network Operator is further
supported by a Virtualization Infrastructure Service Provider, which is supported by a Data
Centre Service Provider; the Network Operator gets its network equipment from a Network
Equipment Provider; the Virtualization Infrastructure Service Provider gets its equipment from
a NFVI Supplier; the Data Centre Service Provider gets its equipment from a Hardware
Supplier; see Figure 3-23 below for a diagram depicting these roles;
The distinction between a Communication Service, a Network Slice Instance (NSI), and a
Network Slice Subnet Instance (NSSI); a Network Slice Subnet Instance can be related to a
5G Core Network or to a 5G Radio Access Network; a Network Slice Instance or a Network
Slice Subnet Instance consist of Network Functions (e.g. AMF, SMF, UPF, etc.); Network
Function can be Virtual Network Functions (VNF) or Physical Network Functions (PNF) which
are further supported by underlying resources (CPUs, storage, networking, etc.). Network
Functions are further interconnected by Transport Networks (TN), which are out-of-scope in
3GPP; see Figure 3-24 and Figure 3-25 below for diagrams depicting some of these
concepts;
Figure 3-23: Role model for 5G management
SaT5G (761413) D3.1 December 2018
Page 52 of 77
Figure 3-24: Examples of communication services provided by network slice instances
Figure 3-25: Example of a network slice instance and the relationship with transport networks
In 3GPP TS 28.530 two models for using slices are defined:
Network Slice as a Service (NSaaS) and
Network Slice as Network Operator internals.
In the first model a network slice is offered by a Communications Service Provider to its
Communications Service Customer in the form of a communication service. In this case the CSC can
use the slice as an ‘end user’ and it can also be allowed to manage the network slice. The CSC can in
this case again be acting as a CSP and offer communication services on top of the network slice. This
model resembles the current model of an MVNO making use of MNO network resources. A diagram
depicting an example of this model is given in Figure 3-26 below.
RAN NFs
TN
CN NFs
CN NFs
CN NFs
Network Slice Instance
TN
TN
App(UE)
App Server
App(UE)
App(UE)
RAN NFs
RAN NFs
TN
TN
SaT5G (761413) D3.1 December 2018
Page 53 of 77
Figure 3-26: Example of a Network Slice as a Service
In the second model, network slices are not part of the offering of the CSP and hence are not visible
to the CSC. In this case, the network operator is using slices for its own purposes only. The CSP still
may get service status information on the service via the management exposure interface. A diagram
depicting an example of this model is given in Figure 3-27 below.
Figure 3-27: Example of a Network Slice as Network Operator internals
As can be seen above network slicing also may involve transport networks that are not in scope of
3GPP. For this, 3GPP TS 28.530 [15] assumes that there is coordination between 3GPP
management and Transport Network (TN) management. A diagram depicting this concept is given in
Figure 3-28 below.
DN NF NF
Network Slice
Network
view
Management
view
CSP
NOP
CSC
NSI
CS
offer
a)
NSI NSI
SaT5G (761413) D3.1 December 2018
Page 54 of 77
RAN
NFs
TN Mngt Sys
3GPP Mgnt System
Manage
RAN
TN
TN
COORManage
CN
CN
NFs
CN
NFsTNTN
RAN CN
TNAPP
ServerUsers
RAN
NFs
Figure 3-28: Example of coordination between 3GPP and TN management systems
In 3GPP TS 28.530 the life cycle of a network slice has been formulated (see Figure 3-29).
Figure 3-29: Life cycle of a Network Slice Instance
In 3GPP TS 28.533 [16] the 5G network management and orchestration architecture is described. It
consists of:
Management Services with their service interfaces, in which each management service
consists of certain components types, i.e.:
Management Operation/Notifications (type A), Management Information type B represented by the
Network Resource Model, and possibly Management Information type C consisting of performance
and fault information.
An example of management services is depicted in Figure 3-30 below.
SaT5G (761413) D3.1 December 2018
Page 55 of 77
Figure 3-30: Example of Management Services and component type A, B, and C
The 3GPP management architecture shall be able to consume ETSI NFV MANO interfaces and via
these interface be able to manage the underlying ETSI VNFs. An example of this type of interface is
given in Figure 3-31 below.
Figure 3-31: Example of deployment of an NSSI with interface to ETSI NFV MANO
Within 3GPP the management of slicing has been worked out in the following management areas:
Configuration Management/Provisioning (see 3GPP TS 28.531, 3GPP TS 28.532);
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.1 December 2018
Page 56 of 77
Fault Management/Fault Supervision (see 3GPP TS 28.545, 3GPP TS 28.546);
Performance Management (see 3GPP TS 28.550, 3GPP TS 28.551); and the associated
performance measurement and assurance data (see 3GPP TS 28.552, 3GPP TS 28.553,
3GPP TS 28.554);
Network Resource Model (see 3GPP TS 28.540, 3GPP TS 28.541, 3GPP TS 28.542, 3GPP
TS 28.543).
The above 5G network management specifications refer to pre-5G specification related to network
management for mobile networks that include virtualized network functions, i.e. to mobile network
including ETSI NFV entities (see 3GPP TS 28.500 to 3GPP TS 28.528). These documents cover the
areas of Configuration Management, Fault Management, Performance Management, and Life Cycle
Management. An overview of the relationship between 3GPP management and NFV-MANO is give in
Figure 3-32 below (from 3GPP TS 28.500).
NFV Orchestrator
(NFVO)
VNF Manager(VNFM)
Virtualised Infrastructure
Manager(VIM)
EM
VNF
NFV-MANO
Vn-NfNE(PNF)
VNF
Vn-Nf
NFVI
Os-Ma-nfvo
Ve-Vnfm-em
Ve-Vnfm-vnf
Nf-Vi
Or-Vnfm
Vi-Vnfm
Or-Vi
EM
NE(PNF)
EM
DM
Itf-N
NM
OSS/BSS
Itf-N
3GPP management system
Figure 3-32: Network management relationship between 3GPP and ETSI MANO
SaT5G (761413) D3.1 December 2018
Page 57 of 77
4 Satellite positioning in 5G System and associated
implementation options
4.1 Satellite positioning in 5G system architecture
As defended in the 3GPP TR 22.822 [17], the satellite system can improve the future 5G system
considering the SaT5G use cases defined in D2.1 [2]. Technically, the satellite link can be
incorporated into a 5G system at different levels for direct and indirect access.
4.1.1 Direct 5G UE access
The diagram in Figure 4-1 shows the architecture in which the 5G UE has direct access via satellite.
In this case, the UE is satellite capable and has a direct access to the 5G network through an access
network ((R)AN in the figure), which is the termination point of the satellite link. The satellite link can
be based on 3GPP access or non-3GPP access: these aspects are identified as implementation
options which are further addressed in sections 0 and 4.3.
Figure 4-1: Architecture showing direct UE access via satellite
4.1.2 Indirect 5G UE access or Backhaul
Figure 4-2 shows the architecture in which the 5G UE has indirect access via satellite. In this case,
the UE has access through various technologies (5G NR, 3GPP or non-3GPP access) to the (R)AN
which is connected to the 5G core through a satellite link. The terminal does not need to be satellite
capable anymore unlike the direct 5G satellite access.
In the frame of SaT5G project, indirect access and backhaul refer to the same concept and constitute
the main focus of the project. Related implementation options for satellite backhaul are addressed in
sections 0 and 4.4.
SaT5G (761413) D3.1 December 2018
Page 58 of 77
Figure 4-2: Architecture showing indirect UE access via satellite
4.1.3 Indirect interconnect in the roaming scenario
TO BE COMPLETED
4.2 Implementation options and support of additional functions
This section identifies and describes the different backhaul implementation options considered within
SaT5G and that are summarised in Figure 4-3Figure 4-3. The figure also represents the potential
support of MEC in case of indirect access with the requirement of edge delivery and the support of
multiple backhaul links (a satellite link and a non-satellite link in this case).
Figure 4-3: Implementation options considered in SaT5G
4.3 Implementation option for direct 5G UE Access
4.3.1 Direct 5G UE access with NR
SaT5G (761413) D3.1 December 2018
Page 59 of 77
Non-terrestrial networks such as the satellite systems are going to be instrumental in the success of
the 5G networks due to the advantage of large coverage footprint, service reliability, and service
availability. To achieve a seamless integration and benefit from the flexibility of 5G NR, the satellite
link can adopt the 5G NR protocols and transmission schemes on its access network.
Direct 5G UE access with NR implies a satellite link on the RAN using the native 5G radio access
technology. Therefore, additional functions for secure authentications are not required. However, a
direct implementation of the 5G NR protocols and schemes using the 3GPP specifications/standards
may be problematic due to the differences in the propagation channel between the terrestrial link and
the satellite link. For example, propagation delays and Doppler shifts at satellite links can be 300
times and 126 times larger than at terrestrial links, respectively. The characteristics of the network
layout can also be significantly different such as the maximum cell size and the mobility of the
infrastructure’s transmission equipment.
To this end, a modification to the 3GPP 5G NR specifications/standards w.r.t., the satellite links will be
required. The impacted areas requiring modification include mainly the network architecture, the
physical and MAC layer procedures.
UE NTN RRU
gNB
5G CN Data Network
N1/N2/N3 N6Satellite 3GPP RAN
Figure 4.3-1: Network architecture- Bent pipe option
UE NTN RRU
gNB
5G CN Data Network
N1/N2/N3 N6Satellite 3GPP RAN
Figure 4.3-2: Network architecture- Regenerative option (gNB embedded in satellite)
Fig. 4.3-1 and 4.3-2 gives two optional modification to the mapping of satellite links to the 5G NR
network architecture. These two options are based on the types of satellite system, i.e., bent pipe
satellite system or regenerative satellite system. Based on the network architecture and the use of NR
SaT5G (761413) D3.1 December 2018
Page 60 of 77
air interface on the access network, some physical and MAC layer procedures will require
modifications such as the subcarrier spacing and the transmission time interval in the NR waveform.
Some other functionalities such as HARQ procedures, uplink and downlink synchronization and timing
advance calculations will require adjustments to suit the satellite channel.
4.3.2 Direct 5G UE access with non-3GPP access
Integration of the satellite system into the 5G network can be achieved with the implementation of
non-3GPP access. The 3GPP 5G core network support multiple access technologies that are not
3GPP specified. Two types of non-3GPP access are defined; Trusted and untrusted. Trusted non-
3GPP access is expected to interact with the 5G CN directly, while untrusted non-3GPP access will
interact with the 5G CN via N3IWF to provide security mechanisms. However, only untrusted access
has been addressed in the specifications.
The implication of non-3GPP access network is that existing satellite network features and protocols
can be re-used to establish connections between the UE and the 5G core network. If the satellite
system is considered as untrusted, additional function known as N3IWF will be required to ensure
secured connections. It should be noted that 3GPP does not specify which non-3GPP access
technologies should be considered trusted or untrusted and only untrusted non-3GPP access is
addressed at the moment [18]. Fig. 4.3-3 shows the network architecture for untrusted non-3GPP
access RAN with satellite link.
UE Gateway 5G CN Data Network
N1/N2/N3 N6Satellite non-3GPP RAN
N3IWF
IPSectunnel
Figure 4.3-3: Untrusted non-3GPP access RAN with satellite link architecture
The use of satellite as a non-3GPP access requires that the mobile device can support satellite radio
communication in addition to the standard cellular radio. The mobile device has a connection
manager which is responsible for the following functions.
Network access discovery: The mobile device gets additional information on the available
access networks within its vicinity. In the case of a satellite link, the mobile device may apply
the techniques specific to the satellite access technology to discover the available satellite
access networks;
Network access selection: The rules for selecting the appropriate satellite access network is
determined and the best satellite access network is selected for registration;
Traffic prioritization and routing: This is part of the connection manger which determines which
traffic will be sent via the access network to the 5G CN and the traffic which will be sent directly
to the internet;
Authentication: The mobile device is configured with a local IP address from the satellite access
network. N3IWF is applied and internet key exchange version 2 (IKEv2) security association
SaT5G (761413) D3.1 December 2018
Page 61 of 77
(SA) establishment procedure is initiated to obtain authentication and authorization for
registration to the 5G CN.
The access network discovery and selection function (ANDSF) provides additional information to the
mobile device to assist in the process of network discovery and selection. The ANDSF will need to
include a satellite network selection policy that will enable the mobile device to select the most
appropriate network access.
4.3.3 Direct 5G UE access with higher 3GPP RAN layer mapped over a
non-3GPP access
TO BE COMPLETED
4.4 Implementation options for Backhaul
4.4.1 Transport Network based implementation options
A satellite system can be used as a transport network within the 5G network in order to provide
connectivity between areas. The backhaul between the access network and the core network can
therefore rely on such system. The satellite system does not necessarily need to be managed by the
same entity managing the 5G network and responsible of the 3GPP management system. The
transport network can have its own dedicated management system.
In that sense, two TN-based implementation options have been specified regarding the provided
flexibility and the level of exposure of interfaces at different planes between the 5G network and the
satellite as transport network, in particular the management plane and the control plane. These two
implementation options are:
Transport network based on 3GPP system specifications, further described in section 4.4.1.1
Transport network not based on 3GPP system specifications, further described in section
4.4.1.2
4.4.1.1 TN Based on 3GPP System Specifications
In this case, it is assumed that the satellite transport network, even if not fully incorporated into 5G the
system, is built taking into consideration the 5G system requirements. Therefore, the TN has its own
Network Management System (NMS) but inherently offers enhanced coordination with the 3GPP
NMS, which manages the 5G network. Furthermore, the interfaces at the control plane are also built
to fulfil the decisions taken from the exchange between the two NMSs in order to process the data
flows that transit between the two networks. The Figure 4-4 presents a functional view of this
approach. The requirements considered to build this “5G ready” satellite transport network can be,
e.g., the support of link capacity expansion, high accurate synchronization, support of network slicing
and other aspects facilitating the continuous adaptation of satellite-based TN to efficiently track
network evolutions.
SaT5G (761413) D3.1 December 2018
Page 62 of 77
Figure 4-4: Satellite transport network based on 3GPP system specifications
4.4.1.2 TN Non Based on 3GPP System Specifications
For this backhaul implementation option, the satellite transport network is not specifically built to be
“5G ready”, unlike the previous implementation option (i.e. TN based on 3GPP system specification
presented in section 4.4.1.1). Therefore, an adaptation layer is required between the 3GPP 5G
network (including 3GPP management system) and the satellite transport network (including satellite
TN management system) in order to meet as much as possible the 5G requirements. This
implementation option is typically envisaged for an existing satellite system that will require an
adaptation layer to act as a transport network for the 5G system.
Figure 4-5: Satellite transport network non-based on 3GPP system specifications
4.4.2 Relay Node based implementation options
In SaT5G, relay node (see section 3.4.5) is foreseen as a solution to provide indirect access within
the satellite system. The satellite link is thus established between the RN (typically integrated in a
satellite terminal) and the 5G core network containing the RAN (Donor Node via a satellite gateway).
It should be highlighted that unlike the typical use of a RN for the simple radio coverage extension in
SaT5G (761413) D3.1 December 2018
Page 63 of 77
terrestrial networks, in SaT5G the application of this concept has been evolved toward a solution
which enables a relay node based backhauling via satellite. Therefore, the foreseen level of
integration characterised by higher protocol stack interaction (rather than simple radio repeater)
provides more control and advanced features such as mobility management features for the RN in
order to enable backhaul connectivity on different moving platforms.
Figure 4-6: Relay node concept for backhaul in 5G
4.4.2.1 Relay Node based on Untrusted Non3GPP Access
The 5G Core Network supports the connection to the RN via non-3GPP access. The RN provides
connectivity to the UEs through any suitable access technology (i.e. 3GPP or non-3GPP).
Since the RN access is untrusted non-3GPP in this case, the N3IWF (Non-3GPP InterWorking
Function) is required between the RN and the 5G core network in order to secure the communication.
Figure 4-7: Satellite terminal acting as a untrusted non-3GPP relay node
4.4.2.2 Relay Node based on Trusted Non-3GPP Access
This is essentially similar to the implementation described above (see section 4.4.2.1) except that the
non-3GPP link between RN and the 5G core network is considered as trusted.
SaT5G (761413) D3.1 December 2018
Page 64 of 77
Since the RN access is trusted non-3GPP in this case, the TNGF (see section 3.3) is required
between the non-3GPP access and the 5G core network in order to secure the communication.
Figure 4-8: Satellite terminal acting as a trusted non-3GPP relay node
4.4.2.3 Relay Node based on 3GPP Access
In this case, since the 3GPP access protocol stack is fully adopted for connectivity between the RN
and the 5G core network and additional functions are not required (such as the N3IWF or the TNGF).
Figure 4-9: Satellite terminal acting as a 3GPP relay node
4.4.3 Preliminary analysis of implementation options
Considering the three identified implementation options for UE direct access though satellite and the
five identified implementation options for satellite backhaul in terrestrial 5G system, the Table 4-1
provides the key challenges to face for each implementation options and an assumption of the
timescale for their realisation.
Additional features such as MEC and multilink supports can be considered for the backhaul
implementation options.
SaT5G (761413) D3.1 December 2018
Page 65 of 77
Table 4-1: Key challenges for the satellite implementation options in 5G
Positioning Implementation
option Key challenges Timescale
Direct
Access
3GPP Access • Adoption of 3GPP-standarized NR over
satellite • Long Term
Trusted non-
3GPP Access
• Make satellite access a trusted non-
3GPP access in standards
• Implement and adapt (if necessary)
required 5G standard mechanisms (e.g.
TNGF) to ensure security compliance
• Mid Term
Untrusted non-
3GPP Access
• Implement and adapt (if necessary)
untrusted access mechanisms as
requested by 5G standards (e.g.
N3IWF)
• Short-Mid
Term
Indirect
Access
(Backhaul)
Relay node
with 3GPP
Access
• Adoption of 3GPP-standarized NR over
satellite
• Adaptation of relay node mechanisms to
satellite terminal specific constraints
• Long Term
Relay node
with Trusted
non-3GPP
Access
• Make satellite access a trusted non-
3GPP access in standards
• Implement and adapt (if necessary)
required 5G standard mechanisms (e.g.
TNGF) to ensure security compliance
• Adaptation of relay node mechanisms to
satellite terminal specific constraints
• Mid Term
Relay node
with Untrusted
non-3GPP
Access
• Implement and adapt (if necessary)
untrusted access mechanisms as
requested by 5G standards
• Adaptation of relay node mechanisms to
satellite terminal specific constraints
• Short-Mid
Term
Transport
Network based
on 3GPP
System
specification
• Design a specific “5G ready” satellite
transport network based on 5G system
specifications
• Short-Mid
Term
Transport
Network non-
based on 3GPP
System
specification
• Design an adaptation layer for existing
satellite transport network • Short Term
The management of the integrated network will be performed either by the 3GPP NMS for the direct
access and backhaul implementation options based on relay node or by the combination of 3GPP
NMS and satellite TN NMS for the backhaul implementation options based on transport network.
SaT5G (761413) D3.1 December 2018
Page 66 of 77
5 Reference SaT5G backhaul architecture and
supported features
5.1 Reference SaT5G backhaul
Once the implementations options have been addressed in section 4, the aim of this section is to
define the reference SaT5G backhaul architecture which clearly identifies the required new
functionalities both at satellite and network level to ensure full integration in the 5G network.
Advanced network functionalities are foreseen within the SatCom access network to facilitate the
integration with terrestrial 5G networks and specific advanced support functions are identified to allow
efficient edge caching and hybrid multiplay connectivity. The diagram in Figure 5-1 shows the role
played by the satellite link to provide backhaul type connection between the satellite gateway (SAT
GW) and the satellite terminal or other non-terrestrial network (NTN) terminal. The N_i interfaces are
presented in detail in the SaT5G deliverable D3.4 [19]. The addition of the CDN server and a local DN
at the edge, enable the edge caching services explored further in the next section 5.2.
Figure 5-1: Reference SaT5G backhaul architecture
5.2 MEC Support
5.2.1 Function delocalization
Leveraging on the paradigms of SDN and NFV adopted in 5G networks, network functions
delocalization will become a reality bringing relevant advantages into new network deployments and
breaking the previous standardisation debate between equipment providers on ‘which function goes
where, between CN and RAN’. The clearer example of it corresponds to the UPF function in the frame
of MEC. In that case, getting UPF closer to the edge allows a bunch of new applications to arise,
shortening the latency enormously by adding local processing capabilities closer to the end users.
Indeed, MEC is being largely assessed in several task force groups in the frame of 5G
standardisation process.
In the frame of SaT5G, besides the MEC case which will be further discussed in section 5.2.2., other
potential network function delocalisation benefits are being assessed. Depending on the SaT5G use
case and scenario, it may be appropriate to delocalize certain network functions (i.e. instantiation of
them) in order to optimise the overall network performance. For instance, in a fixed satellite backhaul
use case, AMF and SMF delocalisation to the edge may be required in order to manage more
SaT5G (761413) D3.1 December 2018
Page 67 of 77
efficiently the users being backhauled, shortening RAN-CN response time and avoiding unnecessary
delay-sensitive interface messages go through the satellite link.
5.2.2 Edge delivery
This section aims at introducing the principle of Edge Delivery. This topic is further discussed in
deliverable D3.2 [3].
The objective of this feature is to provide the best possible QoE when delivering media to the edge
over the satellite link. The main issue when dealing with a satellite link is the potentially high
propagation latency (depending on the satellite constellation) introduced by this type of network. To
circumvent this effect, we introduce cache equipment within the edge network. Instead of going
through the whole network, data packets are directly served from the edge network by the cache. This
is depicted in Figure 5-2.
Figure 5-2: MEC caching high-level architecture
Three main features are introduced in this figure:
A cache equipment within the Edge Network titled “Local DN MEC”: all data packets are
directly served by the local DN if available. This local DN may be provisioned by:
o Pre-fetching: when a user requests a content, the Local DN platform asks the first
packets from the CDN server and then pre-fetches the next one in advance;
o Pre-caching: Network may provision the local DN in advance when a content is
expected to be popular.
A multicast link between CDN Server and Local DN: This link is used to ingest the local
DN with the assets expected to be popular (pre-caching scenario). Popular assets are multi-
casted so they can be retrieved by all local DNs in various Edge Networks.
An AF in the 5G Core: this Caching AF purpose is to decide on redirection policies and
which assets need to be pre-cached. The latter may be externalized outside 3GPP functions
in some use cases. The AF pushes redirection rules to the PCF, which in turn informs the
SMF. The SMF then redirects the UE to the local UPF in the Edge Network. This UPF
delivers the packet from the local DN.
SaT5G (761413) D3.1 December 2018
Page 68 of 77
5.3 Multilink Support
TO BE COMPLETED
5.4 Advanced Satcom functionalities to support
One of the main outcomes of WP3 is indeed the identification and description of new advanced
SatCom functionalities, which will allow to support the requirements of an efficient SatCom-based 5G
backhauling. Satellite core network functionalities will therefore need to be improved or identified and
developed in order to support requirements for 5G backhauling. These functionalities will need to be
compliant with the different implementation options described before. Indeed, specific functionalities
will be required when dealing with a 3GPP based relay node backhaul implementation.
Figure 5-3: Satellite core and interface functionalities for enhanced transport network
As illustrated in Figure 5-3, some pre-identified functionalities are given as examples and will be
further assessed in detail in D3.2 Part A [3]:
SaT-5GC QoS adaptation: adaptation of the QoS requirements as specified in the terrestrial
network (5QI) to the class of service offered by the satellite system (Sat CoS);
Sat-5GC mapping QoS flow to Sat Resources: consider the QoS requirement of a flow to
perform satellite resources allocation;
gNB Mobility Management: manage the mobility of a mobile AN within the satellite network
system.
5.5 Integrated network management
5.5.1 Resource abstraction and network functions virtualization
The concept of resource abstraction and network function virtualization originated when service
providers attempted to speed up deployment of new network services in order to advance their
revenue and growth plans. The constraints of hardware-based appliances led them to applying
standard IT virtualization technologies to accelerate service innovation and provisioning. In fact,
Network Virtualization (NV) is defined as the ability to simulate a hardware platform, such as a server,
storage device or network resource (router, switch), in software. With the help of NV, functionalities
are separated from the actual hardware as “virtual instances”, imitating similar operational abilities of
the traditional hardware devices. Clearly, a host hardware supports the virtual instances, but this
hardware can be general off-the-shelf platform. In addition, a single hardware platform can be used to
support multiple virtual devices or machines, which are easy to spin up or down as needed. As a
result, a virtualized solution is typically much more portable, scalable and cost-effective than a
traditional hardware-based solution.
SaT5G (761413) D3.1 December 2018
Page 69 of 77
Over the past decade, organizations have been adopting virtualization technologies at an accelerated
rate. NV abstracts networking connectivity and services from the traditional dedicated or specialized
hardware devices, turning them into logical virtual functions that are decoupled from and runs
independently on top of general-purpose physical resources. Referring to Figure 5-4, beyond L2-3
services like switching and routing, NV typically incorporates virtualized L4-7 services including
firewalling and server load balancing. NV solves many of the networking challenges, helping
organizations to centrally program and provision the network on-demand, without having to touch
physically the underlying infrastructure. With NV, organizations can simplify how they roll out, scale
and adjust workloads and resources to meet evolving computing needs.
While networks have been moving towards greater virtualization, it is only recently, with the true
decoupling of the control and forwarding planes, as advocated by SDN that network virtualization
surged more as a focus. In fact, SDN and NFV are two complementary approaches. They each offer
a new way to design deploy and manage the network and its services. SDN separates the network’s
control and forwarding planes and provides a centralized view of the distributed network for more
efficient orchestration and automation of network services. NFV offers a new way to design, deploy
and manage networking services. NFV decouples the network functions such as network address
translation (NAT), firewalling, intrusion detection, domain name service (DNS) and caching, to name a
few, from proprietary hardware appliances so they can run in software. A VNF takes on the
responsibility of handling specific functionality that can run on one or more virtual machines (VMs) on
top of the virtualized hardware resources – servers, storage, routers, switches, etc. Individual VNFs
can be connected or combined together as building blocks to offer a full-scale networking
communication service, i.e. the network service (NS). For the sake of completeness, it is worth
mentioning that VMs are not the only way of implementing VNFs.
Figure 5-4: SDN and NFV concept applicability
Since SDN and NFV concepts aim to advance a software-based networking, it is not surprising to see
common doctrines that guide the development both concepts:
Move functionality to software;
Use commodity servers and switches over proprietary appliances;
Leverage on standardized open application program interfaces (APIs);
Support more efficient orchestration, virtualization, and automation of network services.
These approaches are mutually beneficial but are not dependent on one another. However, the reality
is SDN makes NFV more compelling and vice-versa. SDN contributes to a network automation that
SaT5G (761413) D3.1 December 2018
Page 70 of 77
enables policy-based decisions to route network traffic, while NFV focuses on the services and
ensures that network’s capabilities align with the virtualized environments.
Virtualization can provide many benefits for the network operator:
Flexibility: stakeholders (network operators, communication service providers, etc.) seeking
quicker deployment of services require more flexibility and adaptability at the network and
application levels — aiming at easier and quicker installation and service provisioning;
Cost: this is a prime consideration for any operator or service provider (both CAPEX and
OPEX), and even more nowadays since Internet giants (e.g. Google) make use of massive
datacentres using off-the-shelf merchant silicon (commoditized hardware) as a way to drive
down cost (i.e. OPEX);
Scalability: to adapt quickly to users changing needs and provide new services, operators
must be able to scale their network architecture across multiple infrastructures, rather than
being limited by what a single box can do;
Security: security has been, and continues to be, a major challenge in networking. Operators
want to be able to provision and manage the network while allowing their customers to run
their own virtual space and firewall securely within the network;
Virtualization in another service provider network: to meet customers’ needs better, service
providers need to have the ability to substantiate their services anywhere in the world through
virtualisation techniques that can span across different technology providers.
Figure 5-5: Resources abstraction and NFV in SaT5G
The resource abstraction and virtualisation particularly on SatCom networks, although quite in an
initial phase nowadays, constitute one of the main challenges to be addressed in the SaT5G project.
Indeed, applying SDN and NFV paradigms to the satellite access network is one of the main
technological brick developments targeted in Sat5G, which will enable the exposure of key SatCom
functionalities, allowing network slicing and enhanced management and orchestration in an integrated
satellite-terrestrial network.
5.5.2 3GPP management and Transport Network management
SaT5G (761413) D3.1 December 2018
Page 71 of 77
The aim of this chapter is to represent how the various network functions and resources are
aggregated for the correct management/operation of the proposed architectures.
With the emergence of 5G, a radical change on the Information and Communications Technology
(ICT) is observed. Networks are evolving quicker than ever toward smart systems featuring ultra-low
latency, huge traffic volume and higher data rates. Cloud-enabled solution promises effective means
to realize the future communication goals. With the help of softwarisation techniques and cloud/edge
processing capabilities, benefits such as increased resource pooling, scalability, layer interworking,
and spectral and cost efficiency are achievable.
Figure 5-6: 3GPP View on the Mobile Technology Ecosystem
Referring to Figure 5-6, 3GPP the telecommunication ecosystem consists in the following main
domains:
Radio Access Network (RAN): conceptually, it resides between use devices such as a mobile
phone, a computer, or any remotely controlled machine and provides connection to the Core
Network (CN). It is an important part of the mobile telecommunication system that includes
base stations and antennas providing coverage on a given region depends on their capacity.
RAN has been in use since the beginning of cellular technology and continuously been
evolved through the generations of mobile communication: 1G, 2G, 3G, 4G and now 5G.
Such evolution happens at various levels, e.g. transmission technologies and techniques,
protocols, spectrum bands, etc. Just to name few, today’s radio access networks support
multiple-input, multiple-output (MIMO) antennas, large spectrum bandwidths, multi-band
carrier aggregation, software-defined radio (SDR) and so on — all of which bodes well for the
5G future.
Core Network (CN): it is the central part of the mobile telecommunication which allows to
transmit IP packets to external networks such as Internet. 3GPP proposed an architecture
composed of network functions (NFs) and reference points that connects NFs for 5G. The key
components of CN are: (1) Access and Mobility Function (AMF), (2) Session Management
Function (SMF), (3) Policy Control Function (PCF), (4) Application Function (AF), (5)
Authentication Server Function (AUSF), (6) User Plane Function (UPF), (7) User Data
Management (UDM) and (8) Network Slice Selection Function (NSSF). Based on a general
agreement on 3GPP, the mentioned functions form two separate planes in the next
generation architecture, i.e. the user plane and the control plane. The user plane will only
carry out user traffic while the control plane is dedicated signalling in the network.
Transport Network (TN): the transport network that connects RAN and CN. The technology
used on TN domain may vary from Ethernet to the optical communications, all the way down
to the satellite systems. Of course, there is a huge effort to transform TN technology into a
more automated, re-configurable, security and cost effective solution. Historically, the TN has
not been considered in 3GPP standards neither in technology or management level, thus
assuming TN solutions implemented being compliant with network requirements. Typically,
optical fibre does the job quite efficiently but due to actual stringent 5G requirements
standardise interfaces at management level need to be established in order to fully ensure
compliance with foreseen challenging 5G network slices.
SaT5G (761413) D3.1 December 2018
Page 72 of 77
In such a diverse ecosystem, a management and orchestration layer is essential to empower
terrestrial and satellite operators to flexibly / automatically manage network elements and services. In
light of that the management and orchestration solution needs to perform the following tasks:
The network service (NS) orchestration: that includes the lifecycle management of NSs,
composed of both virtual network functions (VNFs) and physical network functions (PNFs).
The management system should enable the terrestrial and satellite operators to respond
automatically to changes according to the defined SLAs and KPIs with their respective
customers (e.g. a company that offers an eHealth, IoT, augmented reality service, etc.). The
up/down and in/out scaling of the VNFs must be also supported by the system, as defined in
the ETSI Management and Orchestration (MANO) documentation.
Resource management of NFV infrastructure (NFVI): the management system must be able
to allocate proper resources for the NS instances. The management system via the
coordination with the virtual infrastructure managers (VIMs) handles the responsibility of VNF
instantiation and instruction with the network controller to form the desired NSs.
Additionally, the management system must facilitate remote interact with the external satellite and
terrestrial Operations Support System / Business Support Systems (OSS/BSS) via appropriate
Application Programming Interface (API). In addition, the solution should provide a user friendly
interactive Graphical User Interface (GUI) for local uses.
In Sat5G, particular emphasis is given to the TN coordination (and TN management system) and the
establishment of a TN management interface connecting the satellite access network management
plane with the 3GPP management system. This certainly applies to SaT5G transport network
implementation options in which specific management interfaces are required between terrestrial and
satellite operators to ensure an efficient and integrated management plane.
5.5.3 Orchestration: Management plane representation
Thanks to the maturity of softwarisation technologies, i.e. NFV and SDN, it is possible to guarantee
higher flexibility, programmability, automation and significant cost/energy reduction in the mobile
technology ecosystem. With the help of NFV and SDN, the embedded general purpose IT resources
in the network are employed to offer special network functionalities, e.g. AMF, SMF, etc. and added
value services, e.g. innovative media services, aiming to improve the end user’s Quality of Experience
(QoE) and creating new business opportunities for service providers. Additional challenges such as
the security of virtual network functions on top of generic hardware such as the secure management
of a remote UPF has to be handled in the orchestration and management planes.
With a closer look to the added value services, it is possible to infer that they are complex operations
composed by one or several software applications, e.g. VNF, cooperating together towards a
common goal. For example, an end-to-end innovative media service is composed of a series of
software each taking a specific part of the work and a virtual machine imitating the functionalities of a
specialized “hard-wired” device like a firewall. This virtual device helps pre-filtering the incoming video
files from end users to the mobile network edge. Non-blocked contents are directed to a video
production application designed for sport events. The video processed by the application is then
broadcasted locally to the end users who are interested to have a 360 vision of the goal. To
guarantee the QoS in any traffic load conditions, the whole media service is constantly monitored and
optimized with regard to the QoS metrics in the Service Level Agreement (SLA).
However, the lifecycle management of virtual functions (instantiation, modification and termination) is
not possible without having an effective management and orchestration systems. As shown in Figure
5-7, the management system is a coordination layer on top of all domains, responsible for automated
cross-domain lifecycle management and coordination as well as interfacing with the operators
(satellite and terrestrial). From one side, 3GPP SA5 focuses on the specifications, requirements and
architecture for provisioning and management of the network and its services. Following SA5
specifications, an end-to-end management solution covers the general NF management concept
which includes: physical and virtual NF lifecycle management, configuration, fault and performance
management. From the other side, European Telecommunications Standards Institute (ETSI) plays a
SaT5G (761413) D3.1 December 2018
Page 73 of 77
leading position worldwide to define a management and orchestration framework for the cloud-
enabled future 5G networks.
As shown in Figure 5-7 the ETSI NFV MANO is meant to address all the issues related with the
management and orchestration of cloud resources (i.e. computing, networking and storage) in which
the following roles can be identified:
The NFV Orchestrator responsible for actions such as: o The on-boarding of new NS and VNF packages, o Global resource management, o NS lifecycle management, o Validation and authorisation of the NFVI resource requests;
VNF Manager: oversees VNF lifecycle management and configurations; VIM: controls and manages the NFVI compute, storage, and network resources.
Nevertheless, merging 3GPP next generation architecture with MANO framework is a very
challenging task, especially when considering a wide picture that includes both satellite and terrestrial
communication technologies. SaT5G targeted to tackle this challenge by introducing a holistic
management and orchestration system able to coordinate terrestrial and satellite network elements.
Such a solution will be based on open source available MANO implementation, in particular Open
Source MANO (OSM), and will support northbound interfaces to both terrestrial and satellite
operators. More details about the SaT5G management system and the result of all related activities
will be presented on D4.2 “Integrated Network Management – Analysis, Design and Proof of
Concepts”.
Figure 5-7: Orchestration in SaT5G
5.5.4 Slice management
TO BE COMPLETED
SaT5G (761413) D3.1 December 2018
Page 74 of 77
6 Conclusion
The main objective of the present document has been to define the main principles and features of
the reference satellite-terrestrial architecture in 5G context. A clear comprehension of satellite
communication systems as well as a deep understanding of the defined 5G system (so far) in 3GPP
standardization groups have been necessary for the identification of the appropriate satellite-
terrestrial integration alternatives and associated challenges.
The analysis of existing satellite communication systems has highlighted how the Satcom ecosystem
is facing major challenges regarding the evolution of ever increasing data rate demand, aggressive
cost reduction per Mbp and enhanced resource flexibility by developing advanced multibeam satellite
systems and pushing innovative techniques such as beam hopping, digitally processed payloads. The
benefits of the adoption of SDN and NFV paradigms which will enable more flexible resource
allocation mechanisms and overall SatCom management have also been highlighted.
The analysis of the current 5G system has shown that the 5G requirements (i.e. support of dynamic
resource allocation, support of network slicing, low latency for URLLC, etc.) are wide and extremely
challenging. Thus, the inclusion of satellite networks in such system will demand an adaptation at
space segment level and, above all, at ground segment level to support such requirements.
Regarding the positioning of satellite link in 5G system architecture, two approaches have been
identified:
Direct access: satellite-capable UE has a direct access to the (R)AN and 5G network through
a satellite link;
Indirect access or backhaul: UE accesses to (R)AN via 3GPP or non-3GPP access
technologies. (R)AN is connected to the 5G core through a satellite link.
As identified in “D3.2 – Integrated SaT5G detailed backhaul architectures” [3], most of the SaT5G use
cases are related to backhaul rather than direct UE access. Therefore, the backhaul implementation
options in the frame of SaT5G have been identified and categorised in two main families:
Backhaul implementation options based on the relay node (RN): satellite-capable UE
endorsing a relay functionality (i.e. multiplexer node role) which can serve other UEs and
being backhauled to the ‘donor RAN’ and 5G core network through a satellite link. This
approach includes 3 implementations options, differentiated by the type of access between
the RN and the 5G core network:
o 3GPP access,
o Trusted non-3GPP access,
o Untrusted non-3GPP access;
Backhaul implementation options based on the transport network:
o Based on 3GPP system specifications (inherently 5G ready),
o Not based on 3GPP system specifications ( require an the implementation of an
adaptation layer to become 5G ready).
The challenges related to these backhaul implementation options are summarized in the table below,
with an assessment of related key challenges, network management impacts, additional supported
features and time to market.
SaT5G (761413) D3.1 December 2018
Page 75 of 77
Table 6-1: Implementation options and key challenges for direct and indirect access
Positioning Implementation
option Key challenges
Network
management
Potential additional
supported features Timescale
Direct
Access
3GPP Access • NR over satellite
Single
integrated
NMS
• Satellite capable UE
• Traffic steering at
UE level
Long Term
Trusted non-
3GPP Access
• Make satellite
access a trusted
non-3GPP access in
standards
Mid Term
Untrusted non-
3GPP Access
• Implement
untrusted access
mechanisms as
requested by 5G
standards
Short-Mid
Term
Indirect
Access
(Backhaul)
Relay node with
3GPP Access
• NR over satellite
• Adaptation of relay
node mechanisms to
satellite terminal
Single
integrated
NMS • Edge delivery
• NF delocalisation
• Hybrid myltiplay
(traffic steering at
RAN level)
• Enhanced UP, CP,
MP interfaces
between satellite
domain and
terrestrial domain
Long Term
Relay node with
Trusted non-
3GPP Access
• Make satellite
access a trusted
non-3GPP access in
standards
• Adaptation of relay
node mechanisms to
satellite terminal
Mid Term
Relay node with
Untrusted non-
3GPP Access
• Implement
untrusted access
mechanisms as
requested by 5G
standards
• Adaptation of relay
node mechanisms to
satellite terminal
Short-Mid
Term
Transport
Network based
on 3GPP System
specification
• Design a specific “5G
ready” satellite
transport network
based on 5G system
specifications
3GPP NMS
and Sat NMS
working in
coordination
Short-Mid
Term
Transport
Network non-
based on 3GPP
System
specification
• Design an
adaptation layer for
existing satellite
transport network
Short
Term
These implementation options are further specified in D3.2 [3].
The support of additional features such as edge delivery, multicast and multilink mechanisms in
combination with backhaul implementations have been also discussed and specified. Such additional
features will play a key role in enabling 5G requirements in SatCom based backhaul implementations.
Exploiting the broadcast capabilities of SatCom networks by pushing content to the edge (as well as
SaT5G (761413) D3.1 December 2018
Page 76 of 77
updating NFV edge functions) will enable effective MEC deployment and content caching and
multicast capabilities improving the end user perception of low latency and fast access to media
content. Regarding multilink technology enabling traffic steering, splitting and switching among
different transmission links will certainly improve the end user QoE and the backhaul resiliency,
latency and versatility. Those aspects combined with backhaul implementation will be further
analysed in other WP as described above:
Support of MEC (edge delivery, NFV updates,…) analysed in D3.2, developed in WP4.6 –
Caching & multicast for optimised content & NFV distribution;
Support of Multilink analysed in D3.2, developed in WP4.3 – Multilink and heterogeneous
transport;
Development of enhanced interfaces between the satellite domain and the terrestrial, in
particular for the backhaul implementation.
Finally, the challenges related to the management and orchestration (MANO) of the integrated
network, have been also addressed and the associated requirements have been identified, mainly in
terms of adoption of SDN/NFV in the satellite domain. Two main approaches for the network
management system have been proposed:
Single integrated network management: in this case, the 3GPP NMS ensure the management
of the whole satellite-terrestrial network, including the satellite terminal. This approach is
typically foreseen for relay node implementation cases in which the satellite terminal acting as
a relay node would be managed by the same entity, managing the terrestrial network i.e. the
3GPP NMS;
Separated NMSs with coordination between the 3GPP NMS and the satellite NMS: in this
case, the 3GPP NMS only manages the terrestrial 3GPP components, while the satellite
components are entirely managed by a separate management system (i.e. satellite NMS).
Coordination between the two NMSs is therefore foreseen for an efficient resource usage and
to ensure appropriate responses to the requests (e.g. service, monitoring, etc.) from one
domain to another. This approach is typically applicable to backhaul implementation option
based on legacy satellite system.
The MANO are further specified in D3.2 are analysed and developed in WP4.1 and 4.2.
SaT5G (761413) D3.1 December 2018
Page 77 of 77
7 References
[1] TS 23.501, System Architecture for the 5G System, 3GPP, 2018.
[2] D2.1, Satellite Reference Use Cases and Scenarios for eMBB, SaT5G, 2017.
[3] D3.2, Integrated SaT5G detailed backhaul architectures, SaT5G, 2018.
[4] O3B Networks, “What is Network Latency and why does it matter,” [Online]. Available:
https://www.o3bnetworks.com/wp-content/uploads/2015/02/white-paper_latency-matters.pdf.
[Accessed 08 2018].
[5] “Hughes data sheet for IP Multicast,” 2001. [Online]. Available:
http://www.eeenterprisesinc.com/pdf/DW_MulticastingSystem_LR.pdf. [Accessed 03 2018].
[6] Newtec, «Satellite Content Distribution,» [En ligne]. Available:
http://www.newtec.eu/frontend/files/application_note/satellite-content-distribution.pdf.
[7] HNS, «Digital Cinema & Content Delivery - White Paper,» [En ligne]. Available:
https://www.hughes.com/collateral-library/digital-cinema-content-delivery. [Accès le 03 2018].
[8] «Echostar Satellite Fleet,» [En ligne]. Available:
http://www.echostarsatelliteservices.com/en/SatelliteFleet/Fleet.aspx. [Accès le 03 2018].
[9] NSR, “SATELLITE BACKHAUL RISING TO DATA DEMAND,” [Online]. Available:
http://www.nsr.com/news-resources/the-bottom-line/satellite-backhaul-rising-to-data-demand/.
[Accessed 04 2018].
[10] D6.2, Standardisation Action Plan, SaT5G, 2018.
[11] TS 23.502, Procedures for the 5G System, 3GPP, 2018.
[12] TS 38.300, NR Overall description, 3GPP, 2018.
[13] TS 38.401, NG-RAN Architecture description, 3GPP, 2018.
[14] TR 38.874, Study on integrated access and backhaul, 3GPP, 2018.
[15] TS 28.530, Management and orchestration; Concepts, use cases and requirements, 3GPP,
2018.
[16] TS 28.533, Management and orchestration Architecture framework, 3GPP, 2018.
[17] TR 22.822, Study on using satellite access in 5G, 3GPP, 2018.
[18] TS 124 502, Access to the 3GPP 5G Core Network (5GCN) via non-3GPP access networks,
ETSI, 2018.
[19] D3.4, Satellite and 3GPP NextGen Reference Interface, SaT5G, 2018.
![D3.1 Modularreasoningforsystemvalidation andverification€¦ · D3.1-Modularreasoningforsystemvalidationandverification Chapter2 Frama-Ctoolbox 2.1 Frama-Ckernel Frama-C[17]isaplatformdedicatedtotheanalysisofCprograms](https://img.dokumen.tips/doc/110x75/605aeaff01f74a5add78b68c/d31-modularreasoningforsystemvalidation-andverification-d31-modularreasoningforsystemvalidationandverification.jpg)
