EPG Architecture

Technical Product Description

141/221 02-AXB 250 12-V3 Uen U2

Copyright

© Ericsson AB 2012–2020. All rights reserved. No part of this document may be

reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to
continued progress in methodology, design and manufacturing. Ericsson shall
have no liability for any error or damage of any kind resulting from the use of this
document.

141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11

 Contents

Contents

1 Platform Architecture 1
1.1 Deployment Types 2
1.2 Virtual Machines 2
1.3 Cloud Environment 3

2 Networking 4
2.1 Logical View of VNs 4
2.2 Admin Networking 8
2.3 Internal Networking 8
2.4 External Networking 9
2.5 Virtual Networks 9

3 Storage 11

4 Non-Uniform Memory Access 12

5 Application Architecture 13
5.1 Startup Procedure 13
5.2 Control Plane Applications 13
5.3 User Plane Applications 15
5.4 EPG Deployments 16

141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11

EPG Architecture

141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11

 Platform Architecture

1 Platform Architecture

The EPG application runs in the Network Functions Virtualization Infrastructure

(NFVI). The NFVI consists of all hardware and software components which build
up the environment in which the EPG is deployed virtually.

For general information on the EPG, refer to EPG Overview.

Figure 1 shows an example of a hardware redundant standalone Control Plane

deployment in a cloud environment with Virtual Service-Forwarders (VSFOs) and
Virtual Route-Processors (VRPs) on two compute hosts. The Virtual EPG can also
be deployed with a standalone User Plane deployment or a single node
deployment, as described in EPG Deployments on page 16

Virtual EPG
CEE
VMs VMs

VRP VRP

VSFO VSFO

Hypervisor Hypervisor
Generic
OpenStack
HW (x86) HW (x86)

Switch Switch

VRP
Control Plane VSFO

Router Router

External PDN

Figure 1 Virtual EPG Logical Architecture (VSFO)

141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11 1

 EPG Architecture

1.1 Deployment Types

The virtual EPG is part of Ericsson virtual EPC (vEPC) Virtual Network Service
(VNS) offerings, consisting of multiple Ericsson vEPC Virtual Network Functions
(VNFs). vEPC deployments are not described in this document.

The virtual EPG can be deployed in the cloud system using Heat. The virtual EPG
supports any dynamic deployment that follows the rules specified in Deploying
Virtual EPG.

For more information on how to configure the VMs and deploy the EPG, refer to
Deploying Virtual EPG. For more information on scaling the EPG, refer to Scaling
The EPG.

1.2 Virtual Machines

Virtual EPG is deployed in the cloud infrastructure as a cluster of VMs. For
information on number of VMs, refer to Deploying Virtual EPG.

1.2.1 VM Types
The virtual EPG uses the following VM types:

— Virtual Service-Forwarder (VSFO): A VSFO can be configured to provide the

following roles:

• User Plane VSFO: Provides virtual EPG application User Plane

capabilities for 2G,3G,LTE,WiFi, and NR (5G radio) with an external SMF.
User Plane VSFO can also provide virtual EPG application aware load
balancing (ingress) and forwarding (egress). It provides Layer 2 and
Layer 3 data forwarding.

• Control Plane VSFO: Provides virtual EPG application Control Plane

capabilities for 2G,3G,LTE and WiFi.

Note: Control Plane VSFOs can be configured with external IP

interfaces for ingress and egress user packet forwarding, same
as User Plane VSFO. However, Control Plane VSFOs must not
handle User Plane traffic because of capacity impact. Therefore,
Ericsson does not recommend configuring Control Plane VSFOs
for user packet forwarding.

— IPsec VSFO: Provides virtual Security Gateway (SEG) application capabilities

to the User Plane and Control Plane. Provides virtual IP Security capabilities
for 2G/3G/LTE/WiFi/CDMA. For more information on SEG refer to IPsec
Technical Product Description.

— VRP: The Virtual Route-Processor (VRP) serves as a node manager for the
virtual EPG application that performs cluster supervision, software

2 141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11

 Platform Architecture

distribution and provides O&M. There is one active VRP and one passive VRP
for redundancy.

1.3 Cloud Environment

The virtual EPG is executed in a cloud environment. The following sections
describe the components of a cloud environment.

1.3.1 Hypervisor
Kernel-based Virtual Machine (KVM) hypervisor is an open-source software
running on top of physical hardware. It is used to provide virtualization layer in
Ericsson Cloud System (ECS). It supports live Motion, that is, moving a VM from
one physical node to another with almost no disruption in service. In the KVM
hypervisor, there is a software-based switch called Virtual Switch (vSwitch). A
vSwitch allows one VM to communicate with other VMs. For more information on
Hypervisor and vSwitch, refer to CEE documentation.

1.3.2 Hardware
Intel® x86 Compute hosts are used as hardware. For full details on the type of
hardware used, refer to CEE documentation.

1.3.3 Cloud Execution Environment

Cloud Execution Environment (CEE) is a virtualization layer which manages the
connection between application and hardware resources. CEE is an environment
provided by the Ericsson cloud infrastructure containing hypervisors, Virtual
Switches, system functions, and O&M support. For more information on CEE,
refer to CEE documentation.

1.3.4 Ericsson Orchestrator

The Ericsson Orchestrator (EO) provides an integrated platform for managing a
cloud computing infrastructure by enabling the creation, orchestration,
activation, and monitoring of services running on virtualized resources. It uses
virtualization technology to abstract resources from the underlying physical
hardware. For more information on the EO, refer to Ericsson Orchestrator-Cloud
Manager documentation.

141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11 3

 EPG Architecture

2 Networking

A Virtual Network (VN) is a logically isolated L2/L3 network provided by the

cloud infrastructure. The VN can be realized as an overlay network using
different encapsulation or tunneling technologies, such as, VLAN (802.1Q),
VXLAN, or GRE on top of a physical underlying network. It is possible that an L2
overlay network spans multiple router hops in a routed L3 underlying network.
The VN is transparent to the virtual EPG, as long as the characteristics required
by the virtual EPG are provided.

The VNs used in the virtual EPG depend on how the virtual EPG is deployed, as
shown in Table 1.

For more information about software versions, see Deploying Virtual EPG.

Table 1 Summary of VNs

VN Type VN Name
Admin MGMT
Internal The virtual EPG uses the following internal VNs for deployments in
CEE or generic OpenStack using software version 2 (or later): MATE,
BP, vFAB
The virtual EPG uses the following internal VNs for deployments in
CEE or generic OpenStack using software version 1: MATE-1,
MATE-2, BP-1, BP-2, vFAB, DBG.(1)
External EXT-x, SC-x
(1) The MATE-1, MATE-2, BP-1, BP-2, and DBG internal VNs have been kept for backwards
compatibility with VNFs deployed with software version 1. By default, deployments use the
internal VNs included in software version 2 (or later).

2.1 Logical View of VNs

2.1.1 Standalone Control Plane Deployments

Figure 2 shows the logical view of the VNs if the virtual EPG is deployed in CEE or
generic OpenStack using software version 2 (or later) in a standalone Control
Plane deployment.

4 141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11

 Networking

VRP VRP VSFO

NM NM Control
RP RP Plane

MATE
BP
vFAB
MGMT VMname_EXT-1

O&M Ext

Figure 2 Standalone Control Plane Deployment: Logical View of the VNs

Deployed in CEE or Generic OpenStack using Software Version 2 (or later)

Figure 3 shows the logical view of the VNs if the virtual EPG is deployed in CEE or
generic OpenStack using software version 1 in a standalone Control Plane
deployment.

VRP VRP VSFO

NM NM Control
RP RP Plane

MATE-1, MATE-2
DBG
BP-1, BP-2
vFAB
MGMT VMname_EXT-1

O&M Ext

Figure 3 Standalone Control Plane Deployment: Logical View of the VNs

Deployed in CEE or Generic OpenStack using Software Version 1

141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11 5

 EPG Architecture

2.1.2 Standalone User Plane Deployments

Figure 4 shows the logical view of the VNs if the virtual EPG is deployed in CEE or
generic OpenStack using software version 2 (or later) in a standalone User Plane
deployment.

VRP VRP VSFO

NM NM User
RP RP Plane

MATE
BP
vFAB
MGMT VMname_EXT-1

O&M Ext

Figure 4 Standalone User Plane Deployment: Logical View of the VNs Deployed
in CEE or Generic OpenStack using Software Version 2 (or later)

Figure 5 shows the logical view of the VNs if the virtual EPG is deployed in CEE or
generic OpenStack using software version 1 in a standalone User Plane
deployment.

6 141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11

 Networking

VRP VRP VSFO

NM NM User
RP RP Plane

MATE-1, MATE-2
DBG
BP-1, BP-2
vFAB
MGMT VMname_EXT-1

O&M Ext

Figure 5 Standalone User Plane Deployment: Logical View of the VNs Deployed
in CEE or Generic OpenStack using Software Version 1

2.1.3 Single Node Deployments

Figure 6shows the logical view of the VNs if the virtual EPG is deployed in CEE or
generic OpenStack using software version 2 (or later) in a single node
deployment.

VRP VRP VSFO VSFO

NM NM Control User
RP RP Plane Plane

MATE
BP
vFAB
MGMT VMname_EXT-1

O&M Ext

Figure 6 Logical View of VNs Deployed in CEE or Generic OpenStack Using

Software Version 2 or Later in a Single Node Deployment

141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11 7

 EPG Architecture

Figure 7shows the logical view of the VNs if the virtual EPG is deployed in CEE or
generic OpenStack using software version 1 in a single node deployment.

VRP VRP VSFO VSFO

NM NM Control User
RP RP Plane Plane

MATE-1, MATE-2
DBG
BP-1, BP-2
vFAB
MGMT VMname_EXT-1

O&M Ext

Figure 7 Logical View of VNs Deployed in CEE or Generic OpenStack Using

Software Version 1 in a Single Node Deployment

2.2 Admin Networking

The Admin interface on the RP connects to the MGMT VN. The Admin interface is
used for temporary outband O&M access, using SSH, SCP, and SFTP when the
normal O&M IP service through the VSFO is either not configured or lost. The
temporary O&M access is used at initial configuration and in some emergency
situations. The Admin interface does not replace the normal O&M IP service
through the VSFO.

The Backup and Restore Management (BRM) function uses the Admin interface
to back up the normal O&M service and to restore backup files.

2.3 Internal Networking

The MATE VN or MATE-1 and MATE-2 VNs are used for synchronization and
monitoring traffic between active and hot standby VRP.

The BP VN or BP-1 and BP-2 VNs are used for internal signalling between all
virtual EPG VMs.

The vFAB VN is used for forwarding external control signalling and user data
traffic between VSFOs.

8 141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11

 Networking

The DBG VN is reserved to use for internal debugging. The DBG VN is not
reserved if the virtual EPG is deployed in CEE or generic OpenStack with Heat
using software version 2 (or later).

2.4 External Networking

The external VNs are used for the virtual EPG external traffic, exchanged through
the VSFOs. The VSFO VNICs connected to the External VNs are also referred to
as VSFO ports.

For more information on external networking, see Configure Virtual EPG External
Network Connectivity.

For more information about SGi-LAN service chaining networking, see Service
Chaining.

2.5 Virtual Networks

Table 2 describes the purpose of the VN and if the VN can be configured as a VRP
or a VSFO.

Table 2 Characteristics of VNs

VN/VM VRP VSFO Purpose
Name
MGMT Yes No VNF-external
Outband O&M
MATE (1)
Yes No VNF-Internal: signalling between VRPs
MATE-1(2) Yes No VNF-Internal: signalling between VRPs
MATE-2(2) Yes No VNF-Internal: signalling between VRPs
BP (1)
Yes Yes VNF-Internal: signalling between VMs
BP-1(2) Yes Yes VNF-Internal: signalling between VMs
BP-2 (2)
Yes Yes VNF-Internal: signalling between VMs
VFAB No Yes VNF-Internal: forwarding external
signalling and user data traffic between
VSFOs
DBG(2) Yes Yes For internal debugging
Not used. Reserved for future use
EXT-x No Yes For external VNF control and payload
communication.
The virtual EPG supports up to 6 external
interfaces per VM if the OVF package is
generated for VMWare. The virtual EPG

141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11 9

 EPG Architecture

VN/VM VRP VSFO Purpose

Name
supports up to 8 external interfaces per VM
HOT file is generated Heat. For more
information, refer to Deploying Virtual EPG.
SC-x No Yes For external SGi-LAN service chaining
monitoring and payload communication.
(1) Used if the virtual EPG is deployed in CEE or generic OpenStack using software version 2 (or a
later software version).
(2) Used if the virtual EPG is deployed in CEE or generic OpenStack using software version 1.

The virtual EPG requires that the VM virtual Network Interface Cards (VNICs)
and VNs are connected in a specified order. The order depends on how the virtual
EPG is deployed.

Table 3 specifies the required connections between VM VNICs and VNs if the
virtual EPG is deployed in CEE or generic OpenStack using software version 2 (or
a later software version).

Table 3 Connection between VM VNICs and VNs in CEE or Generic OpenStack

Deployments Using Software Version 2
VM Type VNIC 1 VNIC 2 VNIC 3
VRP MGMT BP MATE
VSFO BP vFAB -

Table 4 specifies the required connections between VM VNICs and VNs if the
virtual EPG is deployed in CEE or generic OpenStack with software version 1.

Table 4 Connection between VM VNICs and VNs in CEE or Generic OpenStack

Deployments Using Software Version 1
VM Type VNIC 1 VNIC 2 VNIC 3 VNIC 4 VNIC 5 VNIC 6
VRP MGMT BP-1 BP-2 MATE-1 MATE-2 DBG
VSFO BP-1 BP-2 vFAB DBG - -

10 141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11

 Storage

3 Storage

The virtual EPG supports local storage by using the physical disk on the compute
host where the VM is running. For information on storage, refer to Managing
Files.

141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11 11

 EPG Architecture

4 Non-Uniform Memory Access

Non-Uniform Memory Access (NUMA) is common in CPU architectures. It means

that the physical CPU and the memory are partitioned into multiple NUMA nodes.
For example, it is common that a dual socket host has two NUMA nodes, one per
socket. A CPU core has fast access to the memory within its own NUMA node
(local memory), but slower access to the memory in other NUMA nodes (non-
local memory).

The virtual EPG guest OS is NUMA-aware and the virtual EPG application uses
resources accordingly. However, there is a significant capacity penalty and a
complicated integration procedure when user-plane VMs (VSFO as user plane)
are deployed across NUMA boundaries. Control plane VSFO can span two or
more NUMA nodes.

It is recommended to ensure that all VCPUs and the memory of user plane VSFOs
are mapped to physical CPUs and memory on a single NUMA node. In addition,
for maximum capacity of the vSwitch, the vSwitch threads and the physical NIC
need to be on the same NUMA node as the user plane VSFOs. A reference
deployment for user plane VSFOs following this recommendation is called the
compact deployment, described in the virtual EPC documentation.

12 141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11

 Application Architecture

5 Application Architecture

The EPG application software consists of control plane and user plane
applications running on the VSFOs. An allocation of the application types on the
VSFOs takes place during application startup. Based on configuration, each
VSFO is assigned as control plane or user plane. For a description of the startup
procedure, see Startup Procedure on page 13.

5.1 Startup Procedure

The startup procedure of the EPG application software on the VSFOs takes place
as follows:

1. The EPG application software is loaded on the VSFOs during the deployment
of EPG. For more information on deploying EPG, see Deploying Virtual EPG.

2. Once mandatory configuration data and VSFOs are in place, a start is

initiated for the VSFOs. The mandatory configuration data shown in
Configuration Retrieval on page 13 is retrieved.

3. The retrieved configuration data is used to determine which VSFOs run each
of the application types. Roles of VSFOs are determined and applications are
started with the needed configuration data.

5.1.1 Configuration Retrieval

During the startup phase of the control plane applications, the EPG configuration
information is retrieved. This configuration information includes VSFO slot
positions and the number of active and standby cards for each of the application
types. The EPG configuration information also includes single IP addresses or IP
address ranges and routing instance associations used for external interface
communication between the EPG and surrounding nodes.

5.2 Control Plane Applications

Control plane applications on the VSFO consist of the following applications:

— Global Session Controller (GSC)

— PGW Session Controller (PSC)

— SGW Session Controller (SSC)

For more information on the EPG control plane functionality, see PGW-C
Overview and SGW-C Overview.

141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11 13

 EPG Architecture

The EPG has a multicore architecture to enable load distribution. On a single

control plane VSFO, multiple SSC and PSC instances are running on separate
cores. Each SSC/PSC instance is responsible for a dedicated group of subscribers.

5.2.1 GSC
The following are functions of the GSC:

— Admission control

— Shared IP pool functionality

The GSC can run on any control plane VSFO, but only on one control plane VSFO
at a time.

5.2.2 PSC
The PSC establishes and controls user sessions towards the APN networks by
processing GTP-C messages received on the Gn/Gp, S5/S8-C, GTP-based S2a,
and S2b interfaces. The PSC also establishes and controls connections towards
external supporting nodes, such as the Online Charging System (OCS) and the
Event-Based Monitoring (EBM) server.

The PSC also handles gathering of performance monitoring statistics, charging

data generation, and forwarding of PGW Charging Data Records (CDRs) and Rf
ACRs.

The PGW-C communicates with surrounding nodes using single IP addresses

assigned to each logical interface configured for the PGW-C networks. All PSC
instances share a single IP address per network and the PGW-C communicates
each logical interface IP address to the surrounding nodes in the same network
through signalling messages. For information on PGW-C networks with single IP
addresses, see EPG Deployments on page 16.

For information on the port range used by the multicore architecture on the
PGW-C interfaces, refer to Routing.

5.2.3 SSC
The SSC establishes and controls user sessions by processing GTP-C messages
received on the S4-C, S5/S8-C, and S11-C interfaces. The SSC also establishes
and controls connections towards external supporting nodes, such as the
Charging Data Function (CDF) and the EBM server.

The SSC handles charging data generation for SGW-CDRs and Rf ACRs.

The SGW-C communicates with surrounding nodes using single IP addresses

assigned to each logical interface configured for the SGW-C networks. All SSC
instances share a single IP address per network and the SGW-C communicates

14 141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11

 Application Architecture

each logical interface IP address to the surrounding nodes in the same network
through signalling messages. For information on SGW-C networks with single IP
addresses, see EPG Deployments on page 16.

For information on the port range used by the multicore architecture on the SGW-
C interfaces, refer to Routing.

5.3 User Plane Applications

The user plane application runs on user plane VSFOs, and consists of the Data
Plane, the PFCP End-Point, the Timer Wheel, and the Database.

For more information on the user plane functionality, see User Plane Overview.

The following sections describe the architecture of the user plane.

5.3.1 Data Plane

The Data Plane handles the high-speed, real-time forwarding of user packets in
the uplink and downlink directions. The Data Plane performs different operations
on the payload, for example:

— Packet inspection

— Usage measurements

— Policy enforcement

— Packet enrichment

— Redirection

The Data Plane also serves as the Service Function Forwarder (SFF) when
service chaining is used.

5.3.2 PFCP End-Point

The PFCP End-Point serves as the control plane of the user plane, acting as the
end point of PFCP communication over the Sx and the N4 interfaces. The PFCP
End-Point does the following:

— Association management (setup, update, and release).

— Sx and N4 path management.

— Session management (create, update, delete, and report).

The PFCP End-Point is stateless. When handling signaling for a user session, the
user session information is firs retrieved from the Database. Once retrieved, the

141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11 15

 EPG Architecture

signaling is then processed and the Database updated. Finally, the user session
information is written back to the DB.

5.3.3 Timer Wheel

The Timer Wheel providers timer functionality to the user plane. The Timer
Wheel is stateless. When a timer is created for a session, the PFCP End-Point
sends a message to the Timer Wheel, which stores the timer in the Database. The
Timer Wheel periodically checks the Database for timers that expire soon. When
a timer expires, the Timer Wheel sends a message to the PFCP End-Point, which
handles the timer expiry.

5.3.4 Database
The user session information is stored in a distributed replicated Database to
provide fault tolerance if there is user plane VSFO failure.

5.4 EPG Deployments

5.4.1 Standalone Control Plane

The EPG can be run as a standalone control plane node that, depending on the
configuration, acts as a PGW-C, SGW-C, or both.

The control plane node can be connected to one or several user plane nodes. For
more information, see PGW-U Selection Guideline in the PGW-C and SGW-U
Selection Guideline in the SGW-C.

The minimum configuration for a standalone control plane node is two VRPs and
two control plane VSFOs. All control plane VSFOs run the PSC application when
the PGW-C is configured and the SSC application when the SGW-C is configured.
If both the PGW-C and the SGW-C are configured, the control plane VFSOs run
the PSC and the SSC applications simultaneously. In addition to running the PSC
application, the SSC application, or both, one control plane VSFO also runs the
GSC application.

For a standalone control plane deployment, the Sx routing instances need to use
externally routable addresses.

Figure 8 shows an example of a standalone SGW-C and PGW-C control plane

node with all its applications and network IP addresses.

16 141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11

 Application Architecture

Standalone Control Plane Gn/Gp/S5/S8/S2a/S2b-C

IP Address
VSFO (CP)
PSC SSC SGW Rf IP Address

EBM IP Address

Gom IP Address
(Ga/Gx/Gy/Rf(PGW)/S6b)

S5/S8-C IP Address
VSFO (CP)
PSC SSC S4-C/S11 IP Address

GSC Sxa/Sxb/N4 IP Address

Figure 8 Standalone Control Plane Node with Supported Network IP Addresses

Table 5 summarizes the applications that can run on a standalone control plane
node.

Table 5 Standalone Control Plane

Network Function IP Addressing
PGW-C Gn/Gp/S5/S8-C/S2a/S2b network IP
address(1)

Gom network IP address

EBM network IP address

Sxb network IP address

SGW-C S4-C/S11 network IP address

S5-C network IP address

S8-C network IP address

EBM network IP address

Rf network IP address

Sxa network IP address

(1) The Gn/Gp-C and S5/S8-C interfaces belong to the same network, but are configured
separately. For more information, see Configure GTP Interfaces.

For more information on control plane networks, see Routing. For information on
configuring IP addresses and address ranges, see the following documents:

— Configure GTP Interfaces for the GTP-based networks.

— Configure EPG Board for the Gom network.

141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11 17

 EPG Architecture

— Event-Based Monitoring for the PGW-C and Event-Based Monitoring for the
SGW-C for the EBM network.

— Configure Diameter for the PGW-C and Configure Diameter for the SGW-C
for the Rf network.

5.4.2 Standalone User Plane

The EPG can be run as a standalone user plane node that, depending on the
usage, acts as an SGW-U, a PGW-U, a UPF, or any combination of these.

The user plane can be connected to one or several control plane nodes.

The minimum configuration for a standalone user plane node is two VRPs and
two user plane VSFOs running the user plane application.

For a standalone user plane deployment, the Sx routing instances need to use
externally routable addresses.

Figure 9 shows an example of a standalone user plane node acting as a

combined PGW-U and SGW-U, with all its network IP addresses and ranges.

Standalone User Plane

Gom-C IP Address

SGi/N6 IP Address Range

VSFO (UP)
S5/S8-U/N9 IP Address

S1-U/S4-U/S12/N3 IP Address

SGi-LAN Service Chaining

Network IP Address Range

Gn/Gp/S5/S8/S2a-U/S2b
IP Address
VSFO (UP)
Sxa/Sxb/N4 IP Address

Payload
Signaling

Figure 9 Standalone User Plane Node with Supported Network IP Addresses

and Ranges

Table 6 summarizes the network IP addresses and ranges per network function
that the user plane can be used as.

Table 6 Standalone User Plane

Network Function IP Addressing
PGW-U Gn/Gp/S5/S8/S2a/S2b network IP
address or IP address range(1)

SGi network IP address range

18 141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11

 Application Architecture

Network Function IP Addressing

SGi-LAN service chaining network IP
address range

Sxb network IP address

SGW-U S1/S4-U/S12 network IP address

SGW S5/S8-U network IP address

Sxa network IP address

UPF N3 network IP address

N4 network IP address

N6 network IP address range

N9 network IP address
(1) The Gn/Gp-U and S5/S8-U interfaces belong to the same network, but are configured
separately. For more information, see Configure Interfaces for the User Plane.

For more information on user plane networks, refer to Routing. For information
on configuring IP addresses and address ranges, see the following documents:

— Configure Interfaces for the User Plane for the GTP-based networks and the
SGi network.

— Event-Based Monitoring for the User Plane for the EBM network.

— Service Chaining for the SGi-LAN service chaining network.

5.4.3 Single Node with Collocated Control Plane and User Plane
The EPG can be run with the user plane node functionality and the control plane
node functionality deployed on the same COTS servers. The control plane node
and the user plane node are logically two separate nodes communicating
through Sx, but they share the same O&M admin login address.

From the O&M perspective, there is one active RP and one stand-by RP in a
single node. From functionality perspective, the control plane node or the user
plane node does not know that it is in the same COTS HW server as the other
node.

The minimum configuration for a single node deployment is as follows:

— Two control plane VSFOs: the PGW-C runs the PSC application and the
SGW-C runs the SGW Session Controller application. If the node acts as a
PGW-C, one control plane VSFO also runs the GSC application.

141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11 19

 EPG Architecture

— Two user plane VSFOs running the user plane application. The user plane
application can be used as an SGW-U, a PGW-U or as a combined SGW-U
and PGW-U.

— Two VRPs.

For the single node deployment, the Sx routing instances can use private
addressing. Example 1 shows the basic configuration for a single node
deployment with internal routing context. For information on creating a new
context, see Contexts and Interfaces.

Example 1 Single Node Deployment with Internal Routing Context

contexts context internalsx

!
interfaces interface internalsx@internalsx
type ipForward
l3-interface ip address addr-primary addr 192.168.252.254/24
l3-interface context internalsx
!
!
!
epg node logical-interface sxa-c-internalsx
routing-instance internalsx
address 192.168.252.25
!
!
epg node logical-interface sxb-c-internalsx
routing-instance internalsx
address 192.168.252.50
!
!
epg pgw user-plane node-name <name> pfcp-address 192.168.252.100
epg sgw user-plane node-name <name> pfcp-address 192.168.252.100
!
epg sgw interface sx logical-interface sxa-c-internalsx
!
epg pgw interface sx logical-interface sxb-c-internalsx
!
epg user-plane network-instance internalsx
routing-context internalsx
interface cp-function address 192.168.252.100
!
!
epg user-plane default-access-network-instance <access-context>
epg user-plane default-core-network-instance <core-context>
epg user-plane default-cp-function-network-instance internalsx
!
epg sgw interface sx co-located-user-plane
epg pgw user-plane node-name <name>

20 141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11

 Application Architecture

co-located
!

For expansion of the single node with external user planes, the single node can
be deployed by putting the Sx interfaces on external routing contexts. The
procedure is the same for both external and internal configurations except for the
IP addresses that are different for external routing. The IP addresses can vary
based on the configuration and network planning. For more information on the
IP addresses for external routing, see Configure Sxa Interface for the SGW-C,
Configure Sxb Interface for the PGW-C, and Configure Interfaces for the User
Plane.

Figure 10 shows an example of an EPG running as a single node with all its
applications and network IP addresses and ranges.

Single Node
SG
SGi IP Address Range VSFO (CP)
S5
PSC SSC
SGi-LAN service chaining
network IP Address Range (Ga/Gx/G
S5/S8-U IP Address S
VSFO (UP)
VSFO (CP)
S1/S4/S12-U IP Address S4/
PSC SSC
Gn/Gp/S5/S8-U/S2a/S2b
IP Address or IP Address Range GSC

Payload
Signaling

Figure 10 Single Node with Supported Network IP Addresses and Ranges

In a single node deployment, the control plane can be connected to the user
plane in the same node as well as external user planes (by deploying Sx
interfaces on the external routing context). The user plane can only be connected
to the control plane in the same node.

Table 7 Single User Plane and Control Plane

Plane Board Role Network Function IP Addressing
VM Role
Control plane Control plane PGW-C Gn/Gp/S5/S8-
VSFO C/S2a/S2b
network IP
address(1)

141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11 21

 EPG Architecture

Plane Board Role Network Function IP Addressing

VM Role
Gom network IP
address
EBM network IP
address
Sxb network IP
address
SGW-C S4-C/S11
network IP
address
S5/S8-C network
IP address
EBM network IP
address
Rf network IP
address
Sxa network IP
address
User plane User plane VSFO PGW-U Gn/Gp/S5/S8/S2
a/S2b network IP
address or IP
address range(2)
SGi network IP
address range
SGi-LAN service
chaining network
IP address range
Sxb network IP
address
SGW-U S1/S4-U/S12
network IP
address
SGW S5/S8-U
network IP
address
Sxa network IP
address
(1) The Gn/Gp-C and S5/S8-C interfaces belong to the same network, but are configured
separately. For more information, see Configure GTP Interfaces.
(2) The Gn/Gp-U and S5/S8-U interfaces belong to the same network, but are configured
separately. For more information, see Configure Interfaces for the User Plane.

22 141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11

 Application Architecture

For more information about the control plane and user plane networks, see
Routing.

For more information on configuring the Sx logical interfaces, see SGW-C

Software Configuration Overview and PGW-C Software Configuration Overview.

For information on configuring IP addresses and address ranges for the control
plane, see the following documents:

— Configure GTP Interfaces for the GTP-based networks.

— Configure EPG Board for the Gom network.

— Event-Based Monitoring for the PGW-C and Event-Based Monitoring for the
SGW-C for the EBM network.

— Configure Diameter for the PGW-C and Configure Diameter for the SGW-C
for the Rf network.

For information on configuring IP addresses and address ranges for the user
plane, see the following documents:

— Configure Interfaces for the User Plane for the GTP-based networks and the
SGi network.

— Event-Based Monitoring for the User Plane for the EBM network.

— Service Chaining for the SGi-LAN service chaining network.

141/221 02-AXB 250 12-V3 Uen U2 | 2020-09-11 23