NR SA Network Slicing Guidelines
Solution Guideline
2020-05-15
Contents
2020-05-15
1
Introduction ........................................................................................................... 3
1.1
General............................................................................................................... 3
1.2
Scope .................................................................................................................. 4
2
Principles and Guidelines .................................................................................... 5
2.1
Slicing Mechanisms ....................................................................................... 5
2.2
Network Slice Identifiers.............................................................................. 7
2.2.1
PLMN Identifier............................................................................................... 7
2.2.2
Single Network Slice Selection Assistance Information (SNSSAI) ............................................................................................................... 7
2.3
Network Slice Provisioning ......................................................................... 9
2.4
Network Slicing Procedures ...................................................................... 11
2.5
Quality of Service ......................................................................................... 15
2.6
Mobility ............................................................................................................ 17
2.7
Network Slice Management...................................................................... 18
2.7.1
Slice Configuration and Automation...................................................... 18
2.8
Network Sharing ........................................................................................... 21
3
Network Elements and Features ..................................................................... 24
3.1
RAN ................................................................................................................... 24
3.1.1
Slicing Features............................................................................................. 24
3.1.2
Network Sharing Features ........................................................................ 25
3.2
Management.................................................................................................. 25
3.2.1
Slice Observability........................................................................................ 25
3.2.2
Slice Configuration ....................................................................................... 26
4
Network Design Examples ................................................................................ 27
4.1
Fixed Wireless Access (FWA) ................................................................... 27
4.1.1
Planning Considerations ............................................................................ 27
4.1.2
Deployment .................................................................................................... 29
4.1.3
Network Slicing ............................................................................................. 29
4.1.4
Access and Mobility Control ...................................................................... 31
4.1.5
QoS Control .................................................................................................... 31
5
Annex ..................................................................................................................... 32
5.1
Network Slicing in 5GC ............................................................................... 32
5.1.1
User Plane handling for Local Breakout ............................................... 33
5.1.2
Network Slice Interworking with EPS ................................................... 35
5.1.3
Network Elements and Features ............................................................. 39
2 (40)
1
Introduction
This document provides an overview about the 5G network slicing topic as
defined in the relevant standards and supported by Ericsson products for New
Radio Standalone (NR SA) Option 2 deployments.
It covers Radio Access Network (RAN) and Core Network (CN) slicing aspects
and provides basic information about network slice management.
The technical concepts and example network designs described in the document
aim to support technical sales managers during customer engagement and presales activities as well as solution architects in the planning and deployment of
End-to-End (E2E) network slices.
1.1
General
The document presents different techniques to enable network slicing across the
RAN and CN domains. The main focus is on the slicing related aspects in the RAN
domain based on the currently available ERS product functionality, including
slice-aware Quality of Service (QoS), mobility, or CN function selection. Network
slicing aspects and related functions in the CN domain are only covered on a
conceptual level if relevant for the description of certain deployment scenarios or
the RAN-CN inter-working. These can be found in a dedicated Annex.
The practical application of slicing techniques to specific use cases is
demonstrated to support high-level and low-level design activities.
From a network deployment perspective, the assumption is that 5G NR coverage
with Option 2 connectivity to the 5G Core (5GC) is initially only provided in
certain areas within an existing LTE mobile network as shown in Figure 1. Note,
NR NSA Option 3x might be deployed in parallel to NR SA.
5G EPC
Opt. 1
Opt. 3x
S1
B
eNB
S5/N26
X2
5GC
Opt. 2
S1-U
B
eNB
X2
4G
NG
B
gNB
Xn
B
gNB
5G
SA UE
E2E Nw Slicing
Figure 1
2020-05-15
Network Deployment Assumption for 5G Network Slicing
3 (40)
E2E network slicing can only be utilized by NR SA capable UEs when they are
connected to a NR SA enabled cell and registered to the 5GC in those 5G NR
coverage areas. Network slicing is not applicable if SA capable UEs register with
the EPC in a NR cell using NSA with connectivity Option 3x.
Supplementary information is provided by following guidelines and feature
descriptions:
1.2

E2E QoS Guidelines
Explains 5GS QoS concepts

NR SA Connectivity Guidelines with Option 2
Covers E2E connectivity, deployment and EPS-5GS interworking aspects.
Also considers network slicing related to the Transport Network (TN) domain

RAN Slicing Framework (FAJ 121 5095)
Provides operational details about the network slicing features including the
relevant Managed Objects (MO) and parameters to be configured
Scope
This document covers the following topics:

Network slicing techniques standardized in 3GPP Rel-15 and applicable to
New Radio Standalone (NR SA Option 2) deployments

Overview of supported network slicing features in RAN including slice-aware
QoS, mobility, and CN function selection

High-level overview about network slice management

Network slicing concepts in 5GC, including 5GC-EPC interworking and user
plane handling to support Local Breakout (LBO)

Network slicing example for Mobile Broadband (MBB) and Fixed Wireless
Access (FWA) services
Out of Scope
2020-05-15

Network Slicing in the Transport domain

Security aspects related to Network Slicing

Network Slicing for non-3GPP access

Roaming Scenarios

Dimensioning
4 (40)
2
Principles and Guidelines
A network slice is defined by Ericsson as a logical network serving a defined
business purpose or customer, consisting of all required network resources
configured together. The term has been formally introduced by 3GPP in the
context of NR SA deployments with a 5GC network. The standard defines an E2E
slicing approach with network-wide applicability. Essentially, network slicing
provides means to reserve (or partition) the network resources for each slice and
to keep those resources isolated from each other.
Each network slice uses a set of network resources. The resources can be physical
or virtual network functions and be dedicated per slice or shared among different
slices. The resources assigned to a network slice are selected and configured to
fulfil the requirements of a specific business case or service.
Figure 2 illustrates the concept of a single network supporting multiple services
over different network slices.
Management & Orchestration
5GC
5G RAN
RAN Sharing
CN Selection
QoS
Mobility
Slice A
Shared CN
Slice B
CN Partitioníng
Slice C
Dedicated
CN
NR RAN
Transport
Access Sites
Figure 2
2.1
Transport
Aggregation Sites
Central DC
Example Network Slicing Architecture illustrating a single physical network
split into multiple logical networks supporting different services
Slicing Mechanisms
A fundamental challenge with shared infrastructures is to provide traffic isolation
and guarantee appropriate resources to fulfil the required service needs. 3GPP
TS 23.501 specifies the network slicing framework to address this challenge
where slice identification and selection in the RAN and CN domains is based on
the Single Network Slice Selection Assistance Information (S-NSSAI). The
framework permits the harmonized creation and management of network slices
across the RAN and CN domains. Moreover, the separation of control and user
plane resources is an inherent part of the 5GC architecture.
An overview of the available mechanisms for RAN and CN slicing in 5G is
provided in Figure 3. The figure shows different mechanisms and slicing
2020-05-15
5 (40)
parameters connected to the network domains (RAN/CN) in which they are
applied. RAN sharing is also shown as it relates to network slicing.
5G RAN
Sharing
Slicing mechanisms
Other mechanisms for CN
partitioning
PLMN-ID
5G CN
Slicing
DNN
Figure 3
5G RAN
Slicing
S-NSSAI
Network slicing classification per network domain (RAN/CN)
The figure also includes a technique that can further partition CN resources in
combination with other slicing approaches or independently, namely the Data
Network Name (DNN). The DNN is the equivalent to the APN in 4G core networks
and can be used in addition to the S-NSSAI to select the Session Management
Function (SMF) and User Plane Function (UPF) resources for a specific service
type or Data Network (DN).
The main characteristics of the different slicing (and slicing supporting)
techniques are illustrated, in a simplified manner, in Figure 4. The figure shows
that the methods based on Public Land Mobile Network (PLMN) Identifier and SNSSAI can be applied to both the RAN and CN domains.
S-NSSAI
PLMN-ID
CN
CN
CN
CN
CN
gNB
gNB
RU
RU
Cell
Cell
DNN
Cell
Cell
Cell
Cell
S-NSSAI 1
S-NSSAI 2
PLMN 1
PLMN 2
Dedicated Resources
Per Slice
Figure 4
2020-05-15
CN
Shared Resource
Among Slices
5G CN DNN DNN
CN: Core Network
DNN: Data Network Name
PLMN: Public Land Mobile Network
RU: Radio Unit
S-NSSAI: Single Network Slice Selection Assistance Identifier
Overview of different slicing techniques
6 (40)
Using the PLMN-ID to partition RAN or CN resources is typically used in classical
network sharing scenarios like Multi-Operator RAN (MORAN or Multi-Operator
CN (MOCN). This might be referred to as Inter-PLMN slicing approach.
Using the S-NSSAI to partition RAN and CN network resources does not mandate
different PLMN-IDs as S-NSSAIs are always utilized within the scope of a
particular PLMN. This might be referred to as Intra-PLMN slicing approach.
Note: With S-NSSAI based slicing a single UE can be part (make use) of multiple
network slices.
2.2
Network Slice Identifiers
The different network slicing techniques introduced in the previous section are
based on specific slicing identifiers. This section defines these identifiers and
explains how they are used to enable network slicing.
2.2.1
PLMN Identifier
A PLMN identifies the mobile network of an operator in a country. Every PLMN
has a unique code (PLMN-ID) consisting of Mobile Country Code (MCC) and
Mobile Network Code (MNC).
In 5G the PLMN-ID is always used together with the network slice identifier (SNSSAI) to partition the resources in the RAN and CN domains.
The PLMN-ID alone is only used to enable the sharing of RAN or CN
infrastructures among different mobile operators which is known as MultiOperator Radio Access Network (MORAN) or Multi-Operator Core Network
(MOCN).
2.2.2
Single Network Slice Selection Assistance Information (S-NSSAI)
A 5G network slice is identified by a S-NSSAI value and defined within a Public
Land Mobile Network (PLMN), i.e. associated with a PLMN ID.
The S-NSSAI consists of a Slice Service Type (SST) and an optional Slice
Differentiator (SD). The SST identifies a type of network slice with specific
capabilities and characteristics to fulfil the business requirements of services
using that slice. The SD is used to identify different network slices belonging to
the same service type (i.e. having the same SST value). This is illustrated in
Figure 5.
2020-05-15
7 (40)
SST
SD
Service
Type
Comment
Standard S-NSSAIs (3GPP TS 23.501)
No SD
(SD=0xFFFFFF)
1
2
3
4 (Rel-16)
eMBB
URLLC
MIoT
V2X
For standard services requiring global
interoperability and roaming across PLMNs.
0xFFFFFF is the reserved SD value indicating
that the SD is not used for the SST
Non-standard S-NSSAIs
SST < 128
SD >=0 and
!= No SD
Customized
For customized services types having similar
characteristics like standard services e.g. FWA
SST >=128
No SD or
Operator
defined
For operator defined services, e.g. Private
Networks, Mission Critical Public Networks, etc.
SD >=0
S-NSSAI 1
SST
SD
S-NSSAI 2
SST
SD
NSSAI
S-NSSAI N
SST
Slice Service Type (SST)
(8 bits)
Figure 5
SD
Slice Differentiator (SD)
(24 bits)
The format of standard and non-standard S-NSSAIs based on the SST and SD
fields.
For network slices using a non-standard S-NSSAI value, the SD field could be
used to encode supplementary information like a service priority or customer
identity.
Some relevant terms for S-NSSAI slicing are briefly defined below:
2020-05-15

Network Slice Selection Assistance Information (NSSAI): A collection of
one or multiple slices (i.e. S-NSSAI values)

Default Configured NSSAI: Slices that are supported by the Home PLMN
(HPLMN). It can be pre-provisioned on the Subscriber Identity Module (SIM)
card or be provided by the CN to the UEs via signaling. The Default
Configured NSSAI can afterwards be used in any PLMN (e.g. when roaming)

Configured NSSAI: Slices supported within the Serving PLMN (SPLMN)

Allowed NSSAI: NSSAI provided by the SPLMN reflecting the slices that UEs
can use within a registration area (RA). At most eight S-NSSAIs can be part
of the Allowed NSSAI

Requested NSSAI: NSSAI that the UE may provide to the SPLMN during
registration. At most eight S-NSSAIs can be part of the Requested NSSAI. If
provided, the Requested NSSAI is considered by the RAN for AMF selection
and by the CN for slice selection and validation. With the Requested NSSAI
the UE registers the slices that it can later use during Packet Data Unit (PDU)
session establishment. It must be a subset of either:
8 (40)
2.3
-
Allowed NSSAI
-
Configured NSSAI, if the Allowed NSSAI was not received
-
Default Configured NSSAI, if the Allowed and Configured NSSAI were not
received, for example, during initial registration

Subscribed S-NSSAI: S-NSSAI that is provisioned for a UE in the subscriber
database. One of the Subscribed S-NSSAIs can be marked as Default SNSSAI which allows a UE to be associated with a default slice in case the UE
does not provide any S-NSSAI information in registration or PDU session
setup requests

Rejected S-NSSAI: S-NSSAI that the network has banned for use by a UE in
the current PLMN or RA
Network Slice Provisioning
Services and UEs in NR SA deployments are always associated with E2E network
slices in the 5GS. Network slicing is not an optional feature that could be
switched on or off on demand and thus, even running only a single service like
MBB over NR SA requires the provisioning of a corresponding E2E network slice.
Figure 6 shows the provisioning concept for network slices and the
aforementioned slice identifiers in a mobile network. The provisioning is done by
means of:
2020-05-15

Device or node configuration – for example, the Configured NSSAI and
Default Configured NSSAI are provisioned in the Network Slice Selection
Function (NSSF) and Unified Data Management (UDM) nodes respectively.
As mentioned before, the Default Configured NSSAI can also be preprovisioned on the UE (SIM card)

Non-Access Stratum (NAS) signaling – for example, the UE receives the
Configured and Allowed NSSAIs (and Rejected NSSAI) via the AMF of the
serving PLMN and the UE sends the Requested NSSAI when it registers with
the mobile network
9 (40)
PLMN-1
NSSAI-1
AMF associates the UE with a RA at registration
and maintains the Allowed NSSAI as part of UE context
Configured/Allowed NSSAI –
received via AMF during network
registration
At most one NSSAI
can be configured
per PLMN
(Configured NSSAI)
PLMN-1
NSSAIs are managed per TA (i.e. list of Cells and
gNBs) in RAN and per RA (i.e. list of TAs) in CN
UE1
Configured
TA2
TA1
RA1
TA2
TA3
TA1
Allowed
TA1
TA2
UE2
s
D
SIM Card UE1
Configured
AMF
s
D
S-NSSAIs are
associated
with DNN(s)
UDM
Allowed
TA3
SIM Card
NSSF
s
Requested NSSAI – sent by UE during network registration
Configured NSSAI managed by NSSF
per PLMN, TA and
AMF (set)
TA3 RA2
RA1
Default Configured NSSAI
s
D
AMF
UE2
RA2
Subscribed S-NSSAIsmanaged per UE
DNN1, DNN2
DNN3
DNN1
UE1
TA
Tracking Area
Slices (S-NSSAI)
RA
Registration Area
Set of Slices (NSSAI)
Figure 6
Default Configured NSSAI
(optional) managed per UE
DNN1
UE2
NSSAI/S-NSSAI Provisioning Overview
The main provisioning concepts are summarized below:
2020-05-15

The NSSAIs are provisioned and managed per Tracking Area (TA) in the RAN
and per RA in the CN. In the RAN the NSSAIs should be consistently
provisioned per TA; all cells and gNBs in the same TA should support the
same set of NSSAIs. In the CN, all AMFs, i.e. the AMF set, serving an RA
should support the same NSSAIs.
The NSSAIs provisioned on the RAN nodes (gNBs) in different TAs must
match to (are a subset of) the NSSAIs provisioned on the CN nodes (AMF or
AMF set) that are serving those RAN nodes in respective RA. An RA reflects a
TA grouping concept in 5G and consists of a list of TAs which the AMF sends
to the UE during network registration (in the Registration Accept message)

The NSSF manages the Configured NSSAI per PLMN, TA and AMF (or AMF
set). There is at most one Configured NSSAI per PLMN (3GPP TS 23.501)

The subset of the Configured NSSAIs that a UE can use in a PLMN is
represented by the Allowed NSSAI. The AMF, with support from the NSSF,
derives the Allowed NSSAI from the Subscribed S-NSSAI information in the
UDM, the TA where the UE registers with the network, and other operatordefined policies

Besides the Allowed NSSAI, the Configured NSSAI can also be signaled to
the UE when it registers with the network. Note: In contrast to the Configured
NSSAI in the NSSF, the Configured NSSAI signaled to the UE may only
10 (40)
contain a subset of S-NSSAI values matching the Subscribed S-NSSAIs in the
UDM
The distribution of NSSAI information, selection of slices, and slice-specific
Control Plane (CP) functions for subscriber and mobility management (e.g., UDM,
AMF) happens when the UE registers with the network. The actual slice usage
and selection of slice-specific control plane functions for session management
(SMF) as well as User Plane (UP) functions (SMF, UPF) happens when the UE
establishes a PDU session.
Note: Each PDU session is associated with a specific network slice and DNN. The
choice of DNN that can be used for the PDU session is determined by the DNN list
associated with the Subscribed S-NSSAIs in UDM.
2.4
Network Slicing Procedures
Figure 7 shows an example of two network slices with different S-NSSAI values.
In this example, each slice is using dedicated SMF, PCF and UPF functions while
sharing the AMF and UDM functions. The UE, RAN and CN control plane nodes
are aware of the S-NSSAI information and the UE can be simultaneously
connected to different network slices. A UE that uses multiple network slices is
always connected to a single AMF in the 5GC.
s
d
NRF
Network Slice #1
s
d
NSSF
s
d
UDM
S-NSSAI #1
s
d
PCF
Network Slice #2
S-NSSAI #2
s
d
PCF
2
G
S
UPF
SMF
S
3
AMF
S
G
SMF
UPF
1
S-NSSAI Awareness
gNB
Figure 7
2020-05-15
NW Slice #1 Selection Step
S-NSSAI-based Network Slicing in 5G
11 (40)
The UE access to network slices in the 5GS basically consists of two phases:
1
UE Registration: Establishing a control plane connection to the AMF (Step 1
in Figure 7) and registering one or several network slices. The AMF validates
the registration request against the Subscribed S-NSSAIs in the UDM
subscriber profile (Step 2 in Figure 7) and provides the UE with the Allowed,
Configured and Rejected NSSAIs for the serving PLMN
2
PDU Session Establishment: Triggering the setup of a PDU session to a
certain DN for a registered network slice. Based on the UE provided S-NSSAI
and DNN information the AMF selects a SMF with support from the NRF. The
SMF in turn selects an UPF for the PDU session (Step 3 in Figure 7)
Figure 8 outlines some additional details of the UE registration phase including
the information that the UE provides across the AS and NAS layers.
UE
gNB
AMF
RRC: RRCSetupComplete (PLMN, [5G-S-TMSI], [Registered AMF],
[s-NSSAI-List], ded.NAS-Message)
NAS: Registration Request (Requested NSSAI)
AMF Selection
NGAP: Initial UE Message (5G-S-TMSI, NAS-PDU)
NAS: Registration Request (Requested NSSAI)
NAS Security (NAS Identity, Authentication, Security Request/Response)
NGAP: Initial Context Setup Request (GUAMI, Allowed NSSAI, NAS-PDU)
NAS: Registration Accept ([5G-GUTI], Allowed NSSAI, [Configured NSSAI],
[Rejected NSSAI], [NSSAI inclusion mode])
AS Security (SecurityModeCommand/Complete)
RRC: RRCReconfiguration (ded.NAS-MessageList)
NAS: Registration Accept ([5G-GUTI], Allowed NSSAI, [Configured NSSAI],
[Rejected NSSAI], [NSSAI inclusion mode])
RRC: RRCReconfigurationComplete
NGAP: Initial Context Setup Response
Figure 8 UE Registration Call Flow
When a UE registers to the 5GS, it provides either the 5G-S-TMSI, Registered
AMF or Requested NSSAI (s-NSSAI-List) information to the gNB in the
RRCSetupComplete message. The gNB selects the AMF using this information in
following order: 5G-S-TMSI if present, otherwise Registered AMF if present,
otherwise s-NSSAI-List.
If none of this information is provided by the UE, the gNB either selects a default
AMF, if one was configured on the node, or otherwise, performs a weighted
selection amongst all valid AMFs supporting the PLMN based on AMF relative
capacity information. The probability for selecting a particular AMF is equal to
the AMF's relative capacity divided by the sum of relative capacities of all valid
2020-05-15
12 (40)
AMFs. The gNB receives the relative capacity information from each AMF during
NG connection setup process (NG Setup Response message).
The AMF provides the UE with the Allowed, Configured and Rejected NSSAI
information as well as the NSSAI inclusion mode in the NAS Registration Accept
message.
Following is important to note for the UE registration process:

For the initial registration, i.e. when the UE connects to the 5GS for the first
time, the UE does not provide any of the 5G-S-TMSI, Registered AMF, or
Requested NSSAI (s-NSSAI-List) information to the gNB over the Access
Stratum (AS) layer in RRC messages. The handling of the Requested NSSAI
in RRC messages is further explained below

The CN controls whether and how the UE should provide the Requested
NSSAI (s-NSSAI-List) to the gNB in RRC messages using the NSSAI inclusion
mode (see 3GPP TS 23.501). The UE receives the NSSAI inclusion mode from
the AMF in the NAS Registration Accept message. For the initial registration
3GPP currently mandates the UE to operate per default according to NSSAI
inclusion mode “D”. In this mode the UE does not provide the Requested
NSSAI even though NSSAI information (Default Configured NSSAI) might
have been pre-provisioned on the UE. The Requested NSSAI is thus only
provided over the NAS layer to the AMF. Starting with 3GPP Rel-16, UEs can
be pre-configured to operate according to NSSAI inclusion mode “C” in the
HPLMN; the UE then includes the Requested NSSAI in RRC messages during
the initial registration and mobility registration updates

For subsequent registration update procedures, e.g. mobility registration
updates in case the UE moves to a TA outside the current RA or periodic
registration updates in case the UE needs to stay registered during inactivity,
the UE can include the 5G-S-TMSI, Registered AMF, and Requested S-NSSAI
(dependent on the NSSAI inclusion mode) information in RRC messages.
Note: Dependent on the UE implementation the Allowed NSSAI information
that was once received during registration might be permanently stored on
the device and be used to compose the Requested NSSAI in any following
registration procedures including the initial registration after a UE power
off/on cycle
If 5G-S-TMSI, Registered AMF, and Requested NSSAI information is not
presented by the UE during the initial registration, the gNB might select an AMF
that cannot support the network slices that a UE requests over the NAS layer.
In that case the AMF can re-route the registration request either indirectly via the
RAN or directly to the target AMF dependent on local policy and subscription
information (see 3GPP 23.502 for details).
If such AMF re-routing methods are not supported or possible (due to AMF
isolation requirements), the gNB must be configured with a default AMF that
supports all the network slices deployed in the TAs served by the gNB.
2020-05-15
13 (40)
After the UE is registered, a PDU session for a specific S-NSSAI and DNN can be
established.
Figure 9 visualizes the PDU session setup procedure for a UE that is in CMCONNECTED state after having registered with the 5GS. For UEs in CM-IDLE
state the procedure is slightly different as the UE first must re-establish a
signaling connection to the AMF using Service Request procedures according to
3GPP TS.23.502. Latter requires AMF selection by the gNB based on 5G-S-TMSI
information provided by the UE in RRC messages.
CN Slice
S
AMF
6) PDU Session Request (S-NSSAI)
S
2) SMF Selection based on
S-NSSAI, DNN
SMF
3) UPF Selection based on
S-NSSAI, DNN
5) PDU Session Establishment
Accept (S-NSSAI)
1) PDU Session Establishment
Request (S-NSSAI, DNN)
B
gNB
4) N4 session establishment
between SMF and UPF
G
DN A
UPF
PDU Session
7) DRB setup for the PDU
session
8) Establishment of NG-U
Tunnel for the PDU Session
Figure 9
2020-05-15
UE-triggered PDU session establishment based on S-NSSAI
1
UE initiates the establishment of the PDU session sending S-NSSAI and DNN
as input. The S-NSSAI has to be one from the Allowed NSSAIs that the AMF
provided to the UE during the registration phase. Network Slice Selection
Policies (NSSP) configured on the UE or received as part of URSP rules from
the 5GC associate an application with one or more Allowed NSSAIs. If the UE
does not have any NSSP rules it will not include an S-NSSAI identifier in the
PDU session setup request
2
AMF selects the SMF based on the given S-NSSAI and DNN. If no S-NSSAI or
DNN information is provided by the UE, the AMF uses the Default S-NSSAI
and DNN according to the UEs subscription information in UDM
3
SMF selects the UPF based on the given S-NSSAI, DNN and other
information like UE location.
4
SMF initiates a N4 session establishment procedure with the selected UPF
providing Packet Detection Rule (PDR), QoS, and other parameters to the
UPF
5
SMF sends a NAS PDU session establishment accept message including the
S-NSSAI to the AMF in a Namf_Communication_N1N2MessageTransfer
message
14 (40)
6
AMF forwards the NAS PDU session establishment accept in a N2 PDU
Session Request (i.e. NG-AP PDU Session Resource Setup Request) message
to the gNB. Note: The gNB checks if it supports the S-NSSAI in this request
message. If not the PDU session setup will fail
7
gNB establishes DRB between UE and gNB for the PDU session
8
gNB establishes triggers the NG-U tunnel setup between gNB and UPF via
the AMF and SMF for the requested PDU session
Note: The gNB will check whether it supports the network slice for the PDU
session in the Initial Context Setup and PDU Session Resource Setup requests
received from the AMF. The gNB will report an error back to the AMF and will
also not set up DRB(s) for the PDU session if it does not support the slice.
2.5
Quality of Service
To guarantee that mobile traffic is handled according to the needs of the offered
services, QoS techniques are used for identifying and prioritizing different traffic
and subscriber types.
The QoS framework and related scheduler configurations can be used to provide
differentiated traffic handling and to have certain control over the distribution of
the available radio resources. This allows a mobile operator to support services
with different QoS requirements simultaneously over the same network.
Therefore, QoS provides means to support network slicing.
The QoS handling in NR SA is flow-based and standardized in 3GPP TS 23.501.
To support the slice specific QoS treatment in the RAN, a S-NSSAI can be
associated with a certain 5QI and its corresponding QoS profile/characteristics in
the gNB. Network slices can share the same 5QI value, while having different
QoS profiles linked to it.
Figure 10 shows the relevant managed object classes in the Baseband Radio
Node that are used to link a network slice, represented through a corresponding
ResourcePartition MO, to its respective QoS setup, defined through
DU/CUUP/CUCP5qiTable MOs with default5qiTable=False.
Note: For the slice specific QoS treatment of user plane (UP) traffic the most
important ResourcePartition-to-QoS Table mapping to consider is the one for the
gNBDUFunction and gNBCUUPFunction, i.e. the DU/CUUP5qiTable MOs. Only if
a slice specific QoS differentiation of control plane (CP) traffic is needed the
ResourcePartition-to-CUCP5qiTable mapping has to be setup for the
gNBCUCPFunction.
2020-05-15
15 (40)
GNBDU/CUUP/CUCPFunction
gNBId=1
...
CUUP 5QI Parameters
(Incomplete List)
CUUP5qi
ResourcePartitions
DU/CUUP/CUCP5qiTable
resourcePartitionsId=1
....
du/cuup/cucp5qiTableId=2
default5qiTable=False
reservedBy=ResourcePartition=1
....
ResourcePartition
resourcePartitionId=1
related5qiTableRef=
DU/CUUP/CUCP5qiTable=2
...
ResourcePartitionMember
DU/CUUP/CUCP5qi
DU/CUUP/CUCP5qi
DU/CUUP/CUCP5qi
du/cuup/cucp5qiId=2
du/cuup/cucp5qiId=3
profile5qi=2
du/cuup/cucp5qiId=4
profile5qi=3
... profile5qi=4
...
...
DU/CUUP/CUCP5qiTable
du/cuup/cucp5qiTableId=1
default5qiTable=True
...
...
...
DU/CUUP/CUCP5qi
DU5qi
DU5qi
...
Figure 10
Slice Specific QoS Setup
DU 5QI Parameters
(Incomplete List)
DU5qi
ResourcePartitionMemberId=1
pLMNIdList=[PLMN#1]
sNSSAIList=[S-NSSAI#1]
...
Slice Setup on gNB
...
cUUP5qiId
dscp
estimatedE2ERTT
packetDelayBudget
packetDelayBudgetOffset
profile5qi
...
Default QoS Setup
...
dU5qiId
dscp
maxDataBurstVolume
priorityLevel
packetDelayBudget
packetDelayBudgetOffset
profile5qi
...
Baseband Managed Object Classes for a Slice Specific QoS Setup
A default QoS setup can be configured (DU/CUUP/CUCP5qiTable with
default5qiTable=True) and is used for any network slice for which no slice
specific QoS setup has been configured. The default QoS setup is also used for
any QoS flow (5QI) within a network slice for which a slice specific QoS setup
was configured but the QoS profile (DU/CUUP/CUCP5qi) for the respective 5QI is
missing.
Note: For the N3 transport between the gNB and UPF the CUUP5qi profile is
used to specify the relevant QoS parameters like the dscp to be used for the 5QI,
i.e. it provides the 5QI-to-DSCP mapping. In contrast, the corresponding dscp
parameter in the DU5qi profile is relevant for F1 transport between the gNB-DU
and gNB-CUUP functions in the gNB.
There is no need to use the ResourcePartition MO to link a network slice with its
slice specific QoS table and profile if only a single network slice is deployed in a
mobile network, e.g. for the standard MBB service. This can be achieved by just
using the default QoS table.
If more services and thus network slices with specific QoS requirements (different
from those in the default QoS table) are added later on, only these additional
slices make use of the ResourcePartitions framework and slice specific QoS setup
as shown in Figure 11.
Note: The ResourcePartitions framework in general serves the purpose to
connect network slices with local resource management features in the gNB and
thus allows to realize slice specific resource utilization behaviors. QoS could be
regarded as one of these features affecting resource management.
2020-05-15
16 (40)
Slice 1 (S-NSSAI#1, e.g. MBB)
Default QoS Setup
DU/CUUP5qiTable
DU/CUUP5qi
DU5qi
DU5qi
du/cuup5qiTableId=1
default5qiTable=True
...
B
GNBDU/CUUPFunction
gNB
gNBId=1
...
ResourcePartitions
resourcePartitionsId=1
....
ResourcePartition
DU/CUUP5qiTable
resourcePartitionId=1
related5qiTableRef=
DU/CUUP5qiTable=2
...
du/cuup5qiTableId=2
default5qiTable=False
reservedBy=ResourcePartition=1
....
ResourcePartitionMember
Slice 2 (S-NSSAI#2, e.g. FWA)
...
...
ResourcePartitionMemberId=1
pLMNIdList=[PLMN#1]
sNSSAIList=[S-NSSAI#2]
...
...
DU/CUUP5qi
DU5qi
DU5qi
...
...
...
Slice Specific QoS Setup
Figure 11 Example QoS setup (UP) for Multiple Network Slices
The gNB currently schedules the traffic with a basic scheduler treating all DRBs
in the same way from a QoS perspective. Eight PDU Sessions per UE with one
DRB and one 5G QoS flow (non-GBR) per PDU Session are supported. The UE
can be configured (via URSP/NSSP rules) to set up separate PDU sessions per
service (application) by associating it either with a different S-NSSAI or DNN.
Please note that the QoS mechanisms do not provide explicit control over
capacity related resources, for example, Physical Resource Blocks (PRBs) in the
gNB.
For additional information please also refer to the E2E QoS Guidelines, Manage
Quality of Service and respective MO class descriptions.
2.6
Mobility
Slice-aware mobility is supported for intra-frequency handover within the same
gNB and across different gNBs. Neighboring gNBs exchange slice related
information during the Xn setup procedure. For UEs in connected mode, packet
forwarding over the Xn interface is supported for the inter-gNB handover case.
The source gNB initiates the A3 measurement-based handover only if the target
cell candidate supports at least one S-NSSAI used by the UE in the source cell
and no mobility restrictions have been configured for the target cell. In addition,
the target cell must support the PLMN that the UE uses in the source cell.
Figure 12 shows the Inter-gNB handover case.
2020-05-15
17 (40)
Slice aware Intra-frequency/Inter-gNB Handover (HO)
1
Cell 1
(FR1)
B
Slice 1
PDU Session 1
4
gNB
Slice 2
PDU Session 2
S
AMF
HO to Cell 2 (PDU Session 1)
Cell 2
B
(FR1)
3
gNB
X
No HO to Cell 3
Slice 1
PDU Session 1
Slice 3
Cell 3
(FR1)
FR1 = Frequency 1
2
PLMN
1) NGAP: Handover Required(Target ID, PDUSessionResourceList(PDU Session IDs))
2) NGAP: Handover Request(PDUSessionSetupList(PDU Session IDs), S-NSSAIs)
3) NGAP: Handover Request Acknowledge(PDUSessionAdmittedList(PDU Session 1))
4) NGAP: Handover Command(PDUSessionHandoverList(PDU Session 1))
Figure 12 Slice-aware Intra-Frequency, Inter-gNB Handover (HO)
During Inter-gNB handover the target gNB additionally checks the list of PDU
session and corresponding S-NSSAI information that is provided in the NGAP
Handover Request message received from the AMF. It will acknowledge the
handover only for those PDU sessions whose S-NSSAIs are supported in the
target cell. Based on that the source gNB will release the PDU sessions and
related radio bearers for any unsupported S-NSSAI before the handover.
The behavior in the Intra-gNB handover case is similar, with the difference that
no NGAP and AMF involvement is needed. The gNB can directly release the PDU
sessions and bearers for S-NSSAIs that are not supported in the target cell.
2.7
Network Slice Management
The automatic provisioning of an E2E network slice across RAN, TN, and CN
domains is not yet supported. In order to establish a complete network slice, it is
required to do a proper design and configuration of the slice in each network
domain.
2.7.1
Slice Configuration and Automation
Figure 13 shows the high-level architecture of network slice orchestration and
configuration, which also includes the two main products:

2020-05-15
Ericsson Network Manager (ENM)
Contains the External Management System (EMS) for RAN, TN, and CN, as
well as the Software-Defined Networking (SDN) controller functions.
18 (40)

Ericsson Orchestrator (EO)
Hosts the Service Orchestration (SO), Network Function Virtualization
Orchestrator (NFVO) and Evolved-Virtualized Network Function Network (EVNFM) functions.
Currently, E2E slice configuration is done separately per network domain: RAN,
TN and CN. In the future, SO will take the responsibility for the E2E slice
automation. ENM will then take the configuration requirements of RAN and TN
from SO instead of relying on manual preparation.
Configuration of the RAN can be realized by using ENM scripts (via RAN EMS) for
bulk configurations. Bulk configuration is a web-based application in ENM and
allows to simultaneously configure a set of nodes belonging to one slice. It allows
to import configuration management (CM) data to Baseband Radio Nodes in the
live network based on the created bulk configuration file.
Alternatively, the configuration can be done manually node by node, which
results in a higher configuration effort.
If the TN is based on traditional Virtual Private Network (VPN) technologies (e.g.
IP/MPLS VPN), the configuration is done using ENM configuration scripts (via TN
EMS) or manually. Otherwise, if SDN technologies are used in the transport, the
configuration can be conducted in an automated manner by the SDN controller.
Operator
M
CN Slice Provisioning
RAN Slice Provisioning
SO
EO
TN Slice Provisioning
ENM
M
RAN
EMS
M
M
SDNc/
TN EMS
CN
EMS
RAN Slice
Configuration
RAN Sharing
CN Slice
Configuration
M
M
E-VNFM
NFVO
CN Slice
Orchestration
CN Slice
Configuration
TN Slice
Configuration
CN Slice
Instance
SDN/VPN
B
R
RAN
TN
Network Slice C
Network Slice B
Network Slice A
PNF
R
s
r
s
r
s
r
TN
CN
CN
CN
CNF
Figure 13 Ericsson Solution for Network Slice Management and Orchestration
A CN slice can be deployed using Physical Network Functions (PNF) or
Containerized Network Functions (CNF). Using PNFs, manual configuration or
scripting via ENM is needed. With CNFs, the configuration can be automated
together with CN slice orchestration by the SO function in EO.
2020-05-15
19 (40)
The SO handles the CN slice orchestration according to a given slice requirement
definition and instantiates the CN slice with minimal configuration through
NFVO and E-VNFM. Once the CN slice instance is active, SO additionally sends
the configurations requirements to the CN EMS in ENM, which then finishes the
CN slice configuration.
Figure 14 outlines the relevant MOs and parameters to be set in the Baseband
Radio Node for the network slice configuration in RAN. The bulk configuration
application in ENM can be used to commonly provision the relevant S-NSSAI
parameters in all Baseband Radio Nodes of a Tracking Area where the same
network slices are deployed.
For example, the GNBCUUPFunction.sNSSAIList, NRCellDU.sNSSAIList and
ExternalNRCellCU.sNSSAIList (if Xn is not setup) parameters in these nodes
should be updated with corresponding S-NSSAIs. The network slicing
functionality is not operable until these nNSSAIList parameters are configured.
ManagedElement
0..n
GNBDUFunction
dUpLMNId::PLMNId[0..1]
0..n
0..n
GNBCUUPFunction
pLMNIdList::PLMNId[1..12]
sNSSAIList=SSAI [0..1024] (RW)
GNBCUCPFunction
TermPointToAmf
0..64
pLMNIdList::PLMNId[1..12]
sNSSAIList=SSAI [0..1024] (RO)
pLMNId::PLMNId
0..1
Configured by Operator
NRNetwork
0..512
Configured by System
(Received from AMF)
ExternalGNBCUCPFunction
0..48
0..n
NRCellDU
NRCellCU
nRTAC::uint32
pLMNIdList::PLMNId[1..12]
sNSSAIList=SSAI [0..1024] (RW)
sNSSAIList=SSAI [0..1024] (RO)
0.. 256
ExternalNRCellCU
nRTAC::uint32
pLMNIdList::PLMNId[1..12]
sNSSAIList=SSAI [0..1024] (RW)
RO/RW = ReadOnly/ReadWrite
SSAI = SliceSelectionAssistInfo
struct SSAI
{
Configured by Operator
Configured by System
(Received from DU)
Configured by System
(Received from Neighbor gNB)
or
Configured by Operator
(if Xn not available)
}
int32 sst
int32 sd
Figure 14 Network Slicing MOs and Parameters in the Baseband Radio Node
Figure 15 provides an example showing how the slice specific parameters
(sNSSAIList) in the different MOs are to be configured for two network slices
being deployed across the NR cells and gNBs in a particular TA of a PLMN.
Only the network slice information (sNSSAIList) of the GNBCUUPFunction and
NRCellDU MOs must be configured. The other sNSSAIList parameters are
acquired automatically from the gNBDUFunction (NRCellDU), AMF (during N2
connection setup) , and neighboring gNB node (during Xn connection setup). If
there is no Xn connection the ExternalNRCellCU sNSSAIList must be configured
manually.
2020-05-15
20 (40)
S-NSSAIs
configured by operator
S-NSSAIs
received from AMF, DU, External gNB
Slice 1 (S-NSSAI#1)
GNBCUCPFunctionTermPointToAmf
GNBCUUPFunction
sNSSAIList=[S-NSSAI#1, S-NSSAI#2]
NR Cell
GNBDUFunctionNRCellDU
sNSSAIList=[S-NSSAI#1, S-NSSAI#2]
sNSSAIList=[S-NSSAI#1, S-NSSAI#2]
GNBCUCPFunctionNRCellCU
sNSSAIList=[S-NSSAI#1, S-NSSAI#2]
B
gNB1
GNBCUCPFunctionNRNetwork
ExternalGNBCUCPFunction
ExternalNRCellCU
S
NG-C
sNSSAIList=[S-NSSAI#1, S-NSSAI#2]
AMF
Slice 2 (S-NSSAI#2)
Xn
Slice 1 (S-NSSAI#1)
NR Cell
Same network slice setup as gNB1
B
gNB2
Slice 2 (S-NSSAI#2)
Tracking Area 1
PLMN 1
Figure 15 Example Network Slice Configuration
If the sNSSAIList configuration on the GNBCUUPFunction and NRCellDU MOs
was accidentally forgotten, only the eMBB slice (SST=1, No SD) is signaled as
default slice to AMF and neighboring gNB nodes during N2 and Xn connection
setup. The gNB is thus perceived by the peering nodes as if it only supports the
eMBB slice. However, the gNB itself does not perform any slice related checks, for
example related to mobility, whether it supports the network slices of PDU
sessions for which a handover is requested.
With the Managed Object Model (MoM) implemented in the Baseband Radio
Node, network slices are basically provisioned per cell (NRCellDU) and a
maximum of 1024 slices are supported; the number of slices will naturally be
limited by the size of a TA and the number of services offered therein.
Note, that network slice information should be homogenously provisioned across
all cells in a Tracking Area (TA) to avoid abnormal situations, e.g. that a UE might
be able to register and get services in one cell but not in a neighboring cell if
different network slices have been configured across cells belonging to the same
TA.
2.8
Network Sharing
MORAN or MOCN enable the sharing of the RAN infrastructure between multiple
mobile operators or between a mobile operator and an enterprise. One main
purpose of RAN sharing is to improve coverage in a time- and cost-efficient
manner.
When multiple parties share RAN equipment, they typically make use of
dedicated core networks as shown in Figure 16. Hence, RAN sharing and network
slicing are closely related but use different mechanisms serving different
purposes. For example, with MORAN and MOCN the PLMN-ID alone controls the
2020-05-15
21 (40)
selection of and traffic steering to CN nodes while with network slicing the
combination of PLMN-ID and S-NSSAI is used.
MORAN
CN
MOCN
CN
CN
gNB
CN
gNB
RU
RU
RU
Cell
Cell
Cell
A
B
A
B
PLMN 1
PLMN 2
PLMN 1
PLMN 2
Dedicated
Resources
Shared Resource
Figure 16 Network (RAN) Sharing Approaches: MORAN and MOCN
MORAN or MOCN approaches are appealing to Enterprises or Industries that
require dedicated TN and CN infrastructures (sometimes called dedicated
networks) to run security sensitive or mission critical services. The mobile
network infrastructure is not shared except for certain RAN parts and therefore
MORAN or MOCN approaches do not represent the deployment of E2E network
slices on a common, shared infrastructure (PLMN). However, E2E network slicing
could still be applied by an Enterprise and/or MNO within their dedicated
infrastructure (i.e. PLMN) to accommodate different services; meaning network
slicing can be added on top of or combined with MORAN or MOCN.
MORAN is an Ericsson proprietary solution while 3GPP so far only supports
MOCN in 5G (3GPP TS 23.501).
Only MORAN is currently supported in NR SA deployments and the supported
configuration is shown in Figure 17. The NR radio unit is the only network
resource that is shared.
2020-05-15
22 (40)
PLMN #1
PLMN #2
s
d
S
S
G
S
G
S
s
d
UDM
SMF
AMF
UPF
AMF
UPF
SMF
UDM
NG-C
NG-C
NG-U
B
B
gNB
gNB
NG-U
Operator 1
W
Operator 2
NR RU
Shared
NR Cell
NR Cell
Figure 17 MORAN in NR SA
MORAN supports up to six operators (PLMNs) sharing the RAN but for each
PLMN a dedicated gNB (Baseband node) is needed as it can currently only
support one PLMN.
With dedicated gNBs there is no need to provision a PLMN specific CN selection
mechanism in those nodes. Once the gNB can be shared it needs to forward
traffic belonging to different operators to the corresponding CN based on the
PLMN-ID.
Figure 18 exemplifies the application of E2E network slicing in the currently
supported MORAN setup for two operators that each deploy two slices in their
respective PLMN. As S-NSSAIs are always associated with a specific PLMN, the
same S-NSSAI values can be used by both operators to identify the slices.
Slice 1 (S-NSSAI#1)
PLMN #2
NR Cell
Slice 2 (S-NSSAI#2)
Slice 1 (S-NSSAI#1)
PLMN #1
NR Cell
B
S
gNB
AMF
S
SMF
s
d
UDM
G
UPF
W
NR RU
B
S
gNB
AMF
S
SMF
s
d
UDM
G
UPF
G
UPF
Slice 2 (S-NSSAI#2)
Figure 18 Example: E2E Network Slicing in MORAN
2020-05-15
G
UPF
23 (40)
Note: The NR Network Resource Model (NRM) as currently defined by 3GPP TS
28.541 does not allow to specify the relation between PLMN-IDs and S-NSSAIs
in the NR cell MO (NRCellDU). This is no issue as long as dedicated gNBs
(Baseband nodes) are required per PLMN. Once gNBs can be shared, the use of
S-NSSAIs in RAN has to be coordinated between operators until this limitation
has been removed by 3GPP.
3
Network Elements and Features
This section describes the required software packages and features to support
network slicing in RAN for the available Baseband nodes.
3.1
RAN
The Ericsson RAN slicing functionality is provided by a set of software features
with no dependencies on the hardware platform. The main dependency relates to
the support of NR low-, mid- and high-band spectrum as summarized in Table 1.
Note that high-band spectrum for NR SA is not yet supported.
Table 1 Baseband platforms for NR Low-Band (LB) and Mid-Band (MB)
Function
gNB
3.1.1
Supported Band
Platform
LB FDD
Baseband 5216
LB FDD
MB TDD
Baseband 6630, 6318
Baseband 6648, 6641
Radio Processor 6337, 6347
Slicing Features
The features to enable E2E network slicing on Baseband Radio Nodes are
summarized in Table 2.
Table 2
Slicing and Supplementary Features in NR SA
RAN Slicing Value Package (FAJ 801 4015)
RAN Slicing Framework
(FAJ 121 5095)
License controlled for the slice-ware
QoS mapping and mobility functions
NR Base Package (FAJ 801 4002)
2020-05-15
QoS Framework
(FAJ 121 5157)
Handling of Quality of Service (QoS)
flows and Data Radio Bearers (DRBs)
for Protocol Data Unit (PDU) sessions
NR Mobility
(FAJ 121 5041)
Support for NR Intra-Frequency
Mobility, Release with Redirect from
NR to LTE and idle mode inter-RAT
mobility.
Note: The RAN Slicing Framework
24 (40)
feature adds slice-aware mobility
control to this feature
3.1.2
Network Sharing Features
For multi-operator scenarios the features in Table 3 are needed.
Table 3
Shared Networks Features in NR SA
Shared Networks Value Package (FAJ 801 4010)
Multi-Operator RAN
(FAJ 121 5126)
3.2
Management
3.2.1
Slice Observability
Table 4
Multi-Operator RAN support in NR SA
PM Events supporting slice observability in Baseband Radio Nodes
NR Base Package (FAJ 801 4002)
NR Standalone
(FAJ 121 5060)
RAN functionality for NR Standalone
services
From all the PM events that are part of the NR Base Package for SA, only the
ones listed in Table 5 currently provide means for slice observability when tracing
for those events since they contain PLMN ID, S-NSSAI as well as 5QI parameters
as part of the reported event data.
For example, the CuCpProcPduSessionResourceSetup event contains the list of
PDU sessions including their setup status (success or failure), PDU session Id and
the S-NSSAI to which each session is associated. If multiple PDU session setup
failures are related to a certain S-NSSAI, then this could indicate a performance
problem for the given network slice that requires further troubleshooting.
2020-05-15
25 (40)
Table 5
3.2.2
PM Events including PLMN, S-NSSAI as well as 5QI specific data
PM Event
Description
CuCpProcInitialCtxtEstab
Monitors the initial context
establishment procedure
including PDU session and
DRB setup
CuCpProcPduSessionResourceModify
Monitors the PDU session
resource modify procedure
including DRB setup and
release
CuCpProcPduSessionResourceRelease
Monitor the PDU session
resource release procedure
including DRB release
CuCpProcPduSessionResourceSetup
Monitors the PDU session
resource setup procedure
including DRB setup
CuCpProcUeCtxtRel
Monitor the UE context
release procedure including
PDU session and DRB
release
Slice Configuration
Table 6
Slice Configuration Features in ENM
Radio Network Base Package (FAJ 801 1001)
Configuration
Management
Enables slice configuration in RAN
node
WAN-SDN Value Package (FAJ 801 1190)
SDN-C Function
Enables transport SDN autoconfiguration
Core Network Base Package (FAJ 801 1002)
Configuration
Management
2020-05-15
Provides an interface for Core
network configuration data between
ENM and external systems
26 (40)
4
Network Design Examples
4.1
Fixed Wireless Access (FWA)
FWA offers mobile operators a new business opportunity to provide broadband
services to residential customers as an alternative or complement to fixed
broadband access technologies, i.e. Digital Subscriber Line (DSL), cable, or fiber.
Compared to Mobile Broadband (MBB), where data connectivity is realized as a
best effort service, FWA aims at delivering QoS and good user experience in
terms of capacity, availability, and throughput.
The following FWA deployment example covers a scenario where MBB and FWA
services are deployed by a mobile operator within a single PLMN using the
network slicing techniques available in 5G.
4.1.1
Planning Considerations
The decision whether to deploy services like FWA in a dedicated network slice or
co-locate them with other services in a shared network slice as well as the
strategy how to allocate corresponding resources in the RAN, TN and CN
domains depends on a number of factors including following, among others:
2020-05-15

Security and Availability
If the service requires strict isolation from other services from an operational
perspective or additional protection measures (e.g. data integrity, encryption)
when being transported across the mobile network, it should be allocated to
a dedicated network slice. Also, the required resiliency against network or
node failures might influence the choice on network slice usage and resource
allocation therein

QoS and Resource Management
Services that need to provide strict guarantees (SLAs), for example, in terms
of throughput, data rates, packet loss or packet delay/variation (PD/PDV)
and therefore require the use of slice aware packet scheduling or resource
management mechanisms (e.g. capacity control related to RAN PRBs) should
be allocated to dedicated network slices. Note: The use of specific QoS
features or profiles and related scheduler configurations to support the
required service SLAs needs to be considered per service. Services with
similar QoS requirements could be placed in the same network slice which is
then reflecting the main characteristics of the set of services

Service Area and Mobility
The geographical area in terms of number of cells and Tracking Areas where
the service and network slice is deployed and whether mobility and thus also
inter-working with the legacy 4G network must be supported

Organizational Structures
Operators might consist of different divisions being responsible for different
services. For example, a fixed/mobile operator might want to separate
services that are offered through the shared mobile network into different
27 (40)
network slices dependent on which division (fixed or mobile) is responsible
for the service offering and management thereof

Dedicated User or Customer Groups
Services provided to dedicated user or customer groups, for example
enterprises offering dedicated network type of services to their employees,
might request a dedicated, customer specific network slice from the mobile
operator
Evaluating the above criteria for FWA could lead to following network slice
deployment choices:

Shared Network Slice for MBB and FWA
The basic characteristics of FWA and MBB services are similar and FWA also
has no specific needs for security. If the FWA service offering aims to only
provide a best effort connectivity service with no explicit guarantees (SLAs),
like minimum data rates during Busy Hour (BH), then FWA can be deployed
in a shared network slice together with MBB services. Some degree of service
differentiation between FWA and MBB could be added based on traditional
QoS mechanisms, e.g. using different 5QIs for FWA and MBB services.
Differentiation related to 5GC function usage might also be realized by using
different DNNs or NSI IDs (if supported by the 5GC), which allows to allocate
different 5GC functions (SMF, UPF) for FWA and MBB users for the same,
shared network slice

Dedicated Network Slice for FWA
If service guarantees are to be provided or Value-Added Services (e.g.
Video/TV) are included in the FWA offering and therefore slice-aware
resource control, in terms of capacity or 5GC function selection is required,
then FWA services should be deployed in a dedicated network slice. A
dedicated network slice might also be needed due to an operator’s
organizational structure: For example, if the fixed broadband division of a
fixed/mobile operator is responsible for the FWA service offering and
management thereof, the mobile division might decide to provide the fixed
department with dedicated network slice in order to isolate FWA from its
own MBB services.
Only the use of a dedicated network slice for FWA is considered in the following
sections assuming that the service offerings in 5G will in most cases be done with
service guarantees to compete against fixed broadband cable- or fiber-based
offerings.
Besides the network slice deployment considerations, the accurate planning
(dimensioning) of RAN, CN and TN resources as well as access and mobility
control in the CPE, RAN, and CN is required to assure that sufficient resources are
available and resource access is controlled based on the network slice type,
subscriber location, or DNN. QoS mechanisms are always needed to differentiate
between multiple traffic flows within the network slice, especially in case of
congestion.
2020-05-15
28 (40)
4.1.2
Deployment
Figure 19 shows one possible network slice deployment example for FWA and
MBB services in a mobile network. Both services are separated into different E2E
network slices. FWA CPEs and MBB UEs need to be SA capable and always
register with the 5GC network over the NR cell providing coverage and Option 2
connectivity. FWA CPEs are installed at fixed locations and therefore do not
require mobility or 4G inter-working support.
The FWA service is typically limited to defined geographical area (e.g. sub-urban
area) and therefore only a few number of cells and TAs need to be provisioned
with the FWA network slice.
Service
PLMN-1/S-NSSAI
DNN
MBB Internet
SST=1, No SD
Data
SST=1, SD=1
Data3)
FWA Internet
FWA VAS
MBB
Slice 1
PDU Session (Data)
Shared NFs
Internet
NR Cell2)
VAS (TV)
Voice1)
G
UPF
Services
S
B
gNB
S
S
D
S
D
G UL CL3)
UPF
Slice 2
Internet
AMF SMF PCF UDM NSSF
FWA
CDN: Content Delivery Network
DNN: Data Network Name
UL CL: Uplink Classifier
VAS: Value Added Service
S
D
DNN
Data
PDU Session (Data)
G
UPF
DNN
Data
UL/DL Rate Control
DNN
Data
UL/DL Rate Control
CDN
1) VoNR not supported yet
2) Shared spectrum requires sufficient capacity and/or capacity control features to provide FWA with SLAs
3) Dedicated DNNs for specific FWA services in case UL CL not supported for local breakout
Figure 19 Network Slicing in NR SA Deployment
Note: Voice over NR (VoNR) is currently not supported. FWA voice services
should preferably be delivered Over-The-Top (OTT) as EPS fallback could result
in an undesirable behavior impacting EPS and LTE radio capacity.
For example, in LTE+NR SA deployments EPS fallback for voice services would
also shift all FWA data services to the LTE cell additionally draining its radio
capacity there. Moreover, the E2E slice awareness for users handed over to EPS
is lost.
4.1.3
Network Slicing
With dedicated network slices for MBB and FWA, the S-NSSAI for FWA could be
constructed by using the eMBB SST (SST=1) with a specific SD value (e.g. SD=1).
This would also represent FWA being a special type of (e)MBB service.
2020-05-15
29 (40)
4.1.3.1
RAN
One of the main RAN slicing related parameters to consider for FWA is related to
capacity control.
If sufficient NR mid-band spectrum is available, both services, MBB and FWA,
might share the available cell capacity without relying on additional radio
capacity control features, such as Radio Resource Partitioning (RRP).
However, this requires the cell capacity and access to be determined and
controlled as accurately as possible based on the planned FWA service offerings
(sold data rates, minimum bitrate guarantees), number of FWA users including
their data consumption behavior and location in terms of radio coverage.
Capacity overbooking, e.g. allowing more users or higher data rates than
planned, must be avoided to provide good experience of use and commit to the
given SLAs for FWA services.
If there is a need to protect MBB from FWA services and separate their
respective resource demands, the use Radio Resource Partitioning (RRP)
features is recommended or, alternatively, the deployment of dedicated NR
spectrum per service which realizes a kind of static RAN resource partitioning.
Latter will further reduce the risk of doing service/capacity overbookings but is
less preferred as it can waste radio capacity.
Note, that even a few FWA users can already consume some considerable
amount of cell capacity unless their traffic is subject to rate limiting policies; so
other services like MBB sharing the same spectrum capacity cannot be properly
protected without using capacity control features (RRP) or dedicated spectrum.
QoS mechanisms do not provide sufficient control to provide service guarantees
and protection in terms of capacity which is necessary for FWA to compete
against fixed broadband offerings.
4.1.3.2
CN
The control plane and management related functions (e.g. AMF, SMF, UDM) can
be shared across both network slices.
As the SMF selects the UPF mainly based on the S-NSSAI (besides DNN and
other information like user location), the same DNN can be associated with both
network slices, MBB and FWA, and be provisioned on respective UPFs. However,
when sharing the SMF, dedicated DNN(s) to separate FWA from MBB services
might still be needed in case migration and interworking with EPS is required
which is mainly relevant for the MBB service; dedicated DNNs provide a simple
means to assure a unique mapping of DNNs to S-NSSAIs on the shared SMF.
Alternatively, a dedicated SMF can be deployed per slice which allows the same
DNN being used in both slices. Please refer to the Annex section for additional
information regarding the inter-working with EPS.
Dedicated user plane functions (UPFs) per network slice are recommended and
motivated by the high throughput demands of FWA. FWA requires a flexible user
plane scaling solution and optimal UPF deployment (placement) supporting local
2020-05-15
30 (40)
traffic breakout. This will improve the experience of use for FWA users and
offload the TN.
If Uplink Classifiers (UL CL) are not available to realize the local breakout of
bandwidth demanding user plane traffic (e.g. Video/TV), dedicated DNNs should
be provisioned for such services. For example, a Value-Added Service (VAS) DNN
like “Video/TV” could be used to realize the local breakout for Video/TV services
while a Data DNN like “Internet” is used for general Internet services. Video/TV
and Internet services are then handled in different PDU sessions and QoS flows
therein and the QoS flows are mapped to respective DRBs in RAN. Please refer to
the Annex section for supplementary information regarding the user plane
handling to realize local breakout options.
Note: Dedicated user plane functions also facilitate a simple differentiation and
identification of network slices in the transport network domain under the
assumption that IP addresses (GTP tunnel endpoint IPs) are used as main
network slice differentiator in the TN. The TN edge nodes in RAN could then
identify slice specific traffic from the same, shared gNB based on the UPF
destination IP addresses.
4.1.4
Access and Mobility Control
FWA users at a certain location should only have access to NR cells that have
been planned and dimensioned for FWA service usage.
This should primarily be realized by using available CPE locking features that
allow to restrict the access to certain cells, frequency bands or channels.
If the cell spectrum is shared across FWA and MBB services, no specific mobility
control for MBB is needed.
If CPE locking and NR mobility features are not available, the 5GC might provide
some degree of access control, for example by defining Service Area Restrictions
per user in the UDM and PCF or configuring the FWA DNN as Local Area Data
Network (LADN) in the AMF.
4.1.5
QoS Control
The general QoS setup for FWA in 5G is quite similar to the one used in LTE with
the main difference that S-NSSAI together with 5QI information is used to
realize the differentiated service treatment for FWA traffic.
QoS flows in 5G are handled through PDU sessions that are associated with
network slices (S-NSSAIs) and the same 5QI values can be (re-)used across
different slices. Due to the similarity of services and service characteristics being
used in FWA and MBB, the same 3GPP standardized QoS settings and 5QI
values as defined in 3GPP TS 23.501 apply to both.
A slice specific QoS setup is only required in case certain FWA services (e.g.
Value-Added Services like Video/TV) require a special differentiation in the RAN,
2020-05-15
31 (40)
CN or TN domains. For example, a 5QI value could be pre-configured with a
slice-specific 5QI-to-DSCP mapping to realize a prioritized QoS treatment in the
TN domain. Otherwise, the FWA and MBB services can share a common (default)
QoS setup and use the standard 5QIs.
Table 7 summarizes a QoS proposal for a set of MBB and FWA data services in
their respective network slice.
Table 7
QoS setup for MBB and FWA services
Slice
Service
5QI
5QI
Priority
QoS Flow Type
DNN
MBB
Internet/Data
9
90
Non-GBR (default QoS flow)
Data
Internet/Data
9
90
Non-GBR (default QoS flow)
VAS (e.g.
Video/TV)
6
60
Non-GBR
FWA
Data
To achieve a fairer distribution of shared resources in the CN and RAN domains,
the traffic of FWA PDU sessions related to the “Data” DNN should be rate-limited
according (close) to the sold data rate of the user’s subscription.
Rate limiting enforcements can done by the UPF based on the given SessionAMBR (Aggregate Maximum Bit Rate) information. The Session-AMBR in 5G is
comparable to the APN-AMBR in LTE and can be used to realize the DL rate
limiting of FWA traffic related to a certain DNN. Note: The aggregate maximum
bitrate is only shared across non-GBR QoS Flows in a PDU Session. Alternatively,
a more granular rate limiting per service (traffic flow) could be implemented if
supported.
In UL direction the rate limiting might optionally be done in the UE based on the
Session-AMBR if supported.
Rate limiting has following benefits: (1) The FWA service offering is similar to
fixed broadband offerings where users typically do not get higher speeds than
stated in their contract and (2) it provides some remedy in case Radio Resource
Partitioning (RRP) and adequate QoS functions are not applied in RAN.
Together with NR cell capacity planning and controlling the number of FWA
subscribers per NR cell, rate limiting also helps to prevent resource contention
and relaxes the need for sophisticated QoS mechanisms.
5
Annex
5.1
Network Slicing in 5GC
This section provides following information:
2020-05-15
32 (40)
5.1.1

Overview about certain concepts and functions required from a 5GC system
to support the deployment of network slicing solutions

Basic product and software packages needed to support network slicing with
an Ericsson 5GC system
User Plane handling for Local Breakout
Providing mechanisms to realize efficient user plane connectivity was one of the
main goals with 5GC session management. When a UE sets up a session the SMF
selects a so called PDU Session Anchor (PSA) UPF based on the S-NSSAI and
DNN information provided by the UE. Note again, that the SMF can be instructed
to consider additional information for the UPF selection such as the UE location.
A single network slice might be deployed with multiple, distributed UPFs
connecting a certain DN which allows a single PDU session to have more than
one PSA UPF and thus multiple N6 interfaces to the DN.
Different service traffic within the PDU session can then flexibly be steered
across these UPFs based on traffic detection and forwarding rules, called Uplink
Classifiers (UL CL), that the SMF provides to one of the available UPFs, e.g. the
one located closest to the user in the UL traffic path. Based on the UL CL this UPF
then diverts the traffic either to another PSA UPF in the network or to a locally
connected DN.
Edge Cloud
UE Service 1: PDU Session1 (S-NSSAI, DNN)
UE Service 2: PDU Session1 (S-NSSAI, DNN)
Central Cloud
S
S
AMF
N1
UE
UPF Selection Policy/Config
UL CL: Service 1 Flow UPF1
SMF UL CL: Service 2 Flow UPF2
N4
B
gNB
N3
G UL CL
UPF1
G
UPF2
DNN
N6
DN
DNN
N6
DN
UL CL: Uplink Classifier
DN: Data Network
DNN: DN Name
Slice 1 (S-NSSAI #1)
Figure 20 UL CL-based Traffic Steering
With UL CL-based traffic steering the same DNN is provisioned on all the PSA
UPFs and the gNB only has a single N3 interface to the first UL CL UPF in the
uplink traffic path.
2020-05-15
33 (40)
Alternatively, user plane traffic steering within a single network slice can also be
achieved by setting up dedicated PDU sessions per service where each session
and service is associated with a separate DNN provisioned on a different UPF.
This approach basically results in distributing the access to services across
different UPF resources within a network slice.
This DNN-based traffic steering is shown in Figure 21 where a single UE uses a
separate DNN for each PDU session. The SMF is configured with corresponding
UPF selection policies associating a DNN with a specific UPF. The gNB has
multiple N3 interfaces, i.e. one to each UPF on which the respective DNN has
been provisioned.
Edge Cloud
UE Service 1: PDU Session1 (S-NSSAI1, DNN1)
UE Service 2: PDU Session2 (S-NSSAI1, DNN2)
Central Cloud
S
AMF
N4
N1
UE
B
gNB
S
N3
G
UPF Selection Policy/Config
DNN1 UPF1
SMF DNN2 UPF2
G
UPF2
DNN2
UPF1
DNN1
N6
N6
DN: Data Network
DNN: DN Name
DN
DN
Slice 1 (S-NSSAI #1)
Figure 21 DNN-based Traffic Steering
UL CL- or DNN-based traffic steering can be used to realize the Local-Breakout
(LBO) of UP traffic close to the user. Moreover, the SMF can also be configured to
consider UE location information like the Tracking Area (TA) ID for the UPF
selection which allows LBO to be realized in a UE location dependent manner.
If specific DNNs are used to realize the LBO within a network slice, the access to
those can be restricted to certain geographical areas, also called service area, by
defining these DNNs as Local Area Data Networks (LADN). The LADN service
area can for example comprise an industry or campus site in which access is
restricted for certain DNNs.
The service area is represented as a list of TAs and associated with a LADN DNN
based on AMF configuration as shown in Figure 22.
2020-05-15
34 (40)
TA List for LADN SA and DNN2 being
part of LADN SA configured in AMF
PDU Session1 (S-NSSAI
, DNN1) - OK
PDU Session2 (S-NSSAI
, DNN2) - OK
UE1
PDU Session1 (S-NSSAI
, DNN1) - OK
PDU Session2 (S-NSSAI
, DNN2) - NOK
TA1
LADN SA
LADN SA
TA1-2
DNN2 (LADN)
TA1-3
DNN1
TA2
s
s
D
AMF
TA3
RA
UE2
UE2 presence
outside LADN SA
s
TA
Tracking Area
Slices (S-NSSAI)
RA
Registration Area
LADN Service Area
SMF
UDM
UE1
DNN1, DNN2
UE2
DNN1, DNN2
SMF rejects PDU
Session2 setup for UE2
outside LADN SA
Figure 22 Access to LADN DNN in a Service Area
The SMF grants the PDU session setup to a LADN DNN only in the defined service
area based on the presence indication received from the AMF whether the UE is
currently inside or outside the service area for the DNN.
5.1.2
Network Slice Interworking with EPS
A 5GS might initially be deployed as an 5G island within an existing 4G mobile
network. Interworking between EPS and 5GS is needed in order to accommodate
existing services like MBB and support the device mobility between 5GS and EPS.
Other services that are provided only locally in these 5G islands without any need
for mobility, for example FWA or the access to Enterprise factory or campus
network services, do not require any interworking but only the respective
network slicing setup in the 5GS.
The coordination of network slicing during 5GS and EPS interworking is
considered in this section. The EPS may support the DÉCOR for the slicing of CN
resources.
Note: The interworking is defined in 3GPP TS 23.501, TS 23.502 and related
procedures might use the N26 interface between the AMF and MME (also called
tight interworking) or realize the interworking without using the N26 interface.
Combining the use of N26 with S5 between SMF, UPF and SGW for the
interworking is recommended and considered in this section since it provides
inter-system handover with session continuity.
To assure session continuity the combined SMF+PGw-C and UPF+PGw-U
functions must be used as common anchor points for any service access
irrespective of whether the UE connects via 4G or 5G.
2020-05-15
35 (40)
PDN
S6a
s
D
HSS/
UDM
N8
g
s
g
UPF/
PGW-U
PGW
S5
N10
S5-U
s
g
S11
N4
S
S5-C
SMF/
PGW-C
SGW
N11
S
S
N26
MME
S1-U
S1-MME
EPS
User plane in EPS
AMF
N3
B
X2
eNB
B
gNB
N2
5GS
NR Coverage
LTE Coverage
User plane in 5GS
SA UE
Figure 23
5GS and EPS Tight Interworking Architecture
If inter-working is needed for multiple network slices (services) that are deployed
with dedicated SMF and UPF functions, then each of these slices need to provide
SMF+PGw-C and UPF+PGw-U anchor functions to inter-work with the
corresponding SGw(s) in EPS. A single AMF should support all the network slices
requiring inter-working with EPS in a certain region.
Note: The deployment of a shared SMF function for all slices requiring interworking should be considered to further reduce complexity requiring only a single
SMF+PGw-C anchor.
Additional details about device mobility and EPS fallback during the Intersystem handover can be found in the NR SA Connectivity Guidelines with Option
2.
5.1.2.1
Interworking Procedures with N26 Interface
When SA capable UEs move between 5GS and EPS in idle or connected mode,
slice related UE context and PDU session/PDN connection information need to
be transferred between the systems using the N26 interface.
Figure 24 illustrates this information transfer between the AMF and MME which
mainly consist of UE context and related mapping information.
The common anchor SMF+PGw-C node plays a central role in this information
transfer by maintaining the mapping between DNNs, APNs and S-NSSAIs for
each PDU session and PDN connection that needs to be handed over and thus
2020-05-15
36 (40)
supports the AMF/MME to correlate UE context with related PDU session/PDN
connection and S-NSSAI information.
MME/AMF UE context exchange (N26):
incl. EPS Bearer Context with:
• EPS Bearer ID(s), APN
SMF/PGW-C, UPF/PGw-U, SGw Info
(per PDU session/PDN connection)
•
SMF/PGw-C maps:
• S-NSSAI  APN/DNN (per PDU Session/PDN Connection)
• 4G QoS  5G QoS (per QFI/EPS Bearer Id)
Slice 1 Service
5GS Slice 1
(S-NSSAI #1)
G
B
S
gNB
AMF
S
SMF/
PGw-C
5GS Slice 2
(S-NSSAI #2)
UPF/
PGw-U
G
Slice 2 Service
UPF/
PGw-U
N26
B
eNB
Slice 1
Slice 2
EPC Slice 1
(APN A1)
EPC Slice 2
(APN A2)
S
G
MME
SGw
Parameters in 5GS
Parameters in EPS
S-NSSAI = 1
UUT = U1 (optional)
DNN = D1
APN = A1
S-NSSAI = 2
UUT = U2 (optional)
DNN = D2
APN = A2
Figure 24 Interworking Procedures with N26 Interface
To facilitate the inter-working a mapping between S-NSSAIs and DNNs/APNs
must be configured on the SMF+PGw-C node. If the SMF+PGw-C is shared
across multiple network slices the APNs/DNNs must be unique per slice.
For each established PDU session/PDN connection the SMF+PGw-C
automatically maps standardized 4G QCIs to 5QIs (1:1 mapping) based on
available QFI and EPS Bearer ID information. For operator defined QCIs or
dynamically assigned 5QIs additional configuration support is needed to realize
the mapping.
If DECOR is used in EPS, the UE context might include the UE Usage Type (UUT)
which the MME/AMF receives as part of the subscription data from HSS/UDM
and uses to select the correct target MME/AMF for the N26 based information
exchange.
Please note, that the UE also plays an important role in the inter-working by
mapping EPS-GUTIs to 5G-GUTIs (and vice versa), deriving GUMMEI and
GUAMI from respective GUTI information and allocating PDU session IDs also
for PDN connections in EPS.
2020-05-15
37 (40)
5.1.2.2
Migrating EPC DECOR to 5GS Network Slicing
Multiple operators sharing the RAN within the same PLMN typically use an EPC
Dedicated Core Network (DECOR) setup which they might want to migrate to a
5GS setup using Network Slicing as outlined in Figure 25.
In such a setup, the core network nodes are isolated from each other with the
only inter-connection path being the shared RAN nodes and UEs/Users are
usually only allowed to access the services provided by the CN which maintains
the respective user subscription data and service connectivity.
Allowed NSSAIs
(not present at initial
registration)
Dedicated 5GC-1 (e.g. MNO)
Default Configured NSSAIs
G
AMF2 = default AMF on gNB
UE1
1
PLMN-1
UPF
TA1
2
TA1
DNN1
UE1
s
D
s
D
AMF1
NSSF
NRF
AMF supported NSSAIs
Mapping EPC DECOR to
5GS Network Slicing
s
D
UDM
DECOR
DCN1
DCN2
RAN
RA
3
UE3
s
D
AMF1
S
gNB supported NSSAIs
UE2
RA
Cell
s
s
D
s
D
s
D
AMF2
NSSF
NRF
UDM
UUT 1
UUT 2
Rejected NSSAIs
G
1
Registration with AMF re-allocation (NAS re-reroute)
2
Registration without AMF re-allocation
3
Registration with Network Slice Rejection
PLMN-1
UPF
TA1
DNN2
RA
s
D
AMF2
UE2
UE3
DNN1
DNN2
Default Subscribed S-NSSAIs
Dedicated 5GC-2 (e.g. Enterprise)
Figure 25 Mapping EPC DECOR to 5GS Network Slicing
Following considerations need to be taken when mapping such an EPC DECOR
setup to a 5GS Network Slicing setup:
1
2020-05-15
UEs (e.g. UE1 in the figure) that are initially registering with the 5GC might
not provide any network slice information in RRC messages to support the
gNB in selecting the correct AMF; 3GPP Rel-15 currently mandates UEs to
operate per default in NSSAI inclusion mode “D” until the AMF instructs the
UE to use a different mode. Note, starting with 3GPP Rel-16 (TS 23.501) this
behavior is allowed to be changed by pre-configuring UEs to operate
according to NSSAI inclusion mode “C”. If the gNB sends the registration
request to the wrong 5GC AMF based on its local default AMF configuration,
AMF re-allocation (e.g. via RAN) is required if the AMF does not support the
network slices (NSSAI) the user has requested. However, since the control
plane nodes of the different 5GC networks are isolated from each other, the
AMFs cannot exchange UE and NAS security context information
(Namf_Communication_UEContextTransfer). The target AMF therefore does
not know the requested/subscribed slice information and thus cannot
38 (40)
provide the UE with Allowed/Rejected NSSAIs. Moreover, it also cannot
securely communicate with the UE; the UE rejects unsecured NAS messages
from the target AMF after having established NAS security with the initial
AMF which prevents a successful NAS re-route.
Note also, that AMF re-allocation requires as pre-condition that the local
NSSF, AMF and/or NRF are aware of the network slices and AMF nodes in
the other 5GC and the local UDM must also contain the corresponding UE
and slice subscription information; this pre-condition is not reflected in the
figure above.
2
UEs (e.g. UE2 in the figure) registering with the correct 5GC do not require
AMF re-allocation and can access all network slices (services) that they are
subscribed to
3
UEs (e.g. UE3 in the figure) which have dual-service subscriptions and thus
might request access to multiple network slices (services) provided by
different 5GC networks will only get access to those network slices that are
supported by the AMF receiving the initial registration request. The AMF will
reject access to any slice that it does not support if it cannot find other AMFs
supporting all the UE requested network slices either by local configuration or
support from NSSF/NRF functions. The AMF will send respective Rejected
NSSAIs to the UE which prevents latter from accessing the unsupported
network slices. As already mentioned before, a UE using multiple network
slices must be connected to and controlled by a single AMF
Note, that Figure 25 shows an inconsistent network slicing setup in that different
AMFs control gNBs in the same TA and RA but do not support the same set of
network slices. As described above, this will only work under special conditions,
e.g. that the UE always provides network slice information to the RAN to allow
latter to select the correct 5GC and that the selected 5GC also supports all
network slices requested by the UE.
5.1.3
Network Elements and Features
The Ericsson 5GC packages including the essential network functions relevant to
E2E network slicing are summarized in Table 8. Dependent network functions
and packages (e.g. UDR, AUSF) needed for the general operation of a 5GC
network are not shown.
Table 8
Software Packages for Network Slicing in 5GC
5GC Value Packages (FAJ 801 1150, FAJ 801 1155)
2020-05-15
Packet Core
Controller (PCC)
The 5GC Value Package FAJ 801 1150
contains the AMF and SMF with basic 5G
slicing functionality
Packet Core
Gateway (PCG)
The 5GC Value Package FAJ 801 1155
contains UPF supporting 5GC SA NR
deployment
39 (40)
CCSM Base Package (FAJ 801 1106)
Unified Data
Management
(UDM)
Provides the subscription data for network
slicing
CCDM Base Package (FAJ 801 1102)
Unified Data
Repository
(UDR)
UDR stores 5G Core subscription and policy
data for network slicing
CCRC Base Packages (FAJ 801 1109, FAJ 801 1103)
Network Slice
Selection
Function (NSSF)
CCRC Base Package FAJ 801 1109 contains
the NSSF
Network
Resource
Function (NRF)
CCRC Base Package FAJ 801 1103 contains
the NRF
Table 9
Software Packages for Slice Orchestration in EO
Ericsson Orchestrator Base Package (FAZ 1010468/06)
Service Orchestration
Enables CN slice orchestration
For information related to network slicing support and features in different
Ericsson 5GC products and nodes please refer to respective CPI libraries and
roadmap information.
2020-05-15
40 (40)