Sie sind auf Seite 1von 65

Flexi Network Gateway, Rel.

17.5 MP3, Operating
Documentation, v1

Flexi NG Architecture 
DN09130502
Issue 5-0
 
 
Flexi NG Architecture

The  information  in  this  document  applies  solely  to  the  hardware/software  product  (“Product”)  specified
herein, and only as specified herein. Reference to “Nokia” later in this document shall mean the respective
company within Nokia Group of Companies with whom you have entered into the Agreement (as defined
below).

This document is intended for use by Nokia's customers (“You”) only, and it may not be used except for the
purposes  defined  in  the  agreement  between  You  and  Nokia  (“Agreement”)  under  which  this  document  is
distributed. No part of this document may be used, copied, reproduced, modified or transmitted in any form
or  means  without  the  prior  written  permission  of  Nokia.  If  You  have  not  entered  into  an  Agreement
applicable to the Product, or if that Agreement has expired or has been terminated, You may not use this
document in any manner and You are obliged to return it to Nokia and destroy or delete any copies thereof.

The  document  has  been  prepared  to  be  used  by  professional  and  properly  trained  personnel,  and  You
assume  full  responsibility  when  using  it.  Nokia  welcomes  your  comments  as  part  of  the  process  of
continuous development and improvement of the documentation.

This  document  and  its  contents  are  provided  as  a  convenience  to  You.  Any  information  or  statements
concerning the suitability, capacity, fitness for purpose or performance of the Product are given solely on
an  “as  is”  and  “as  available”  basis  in  this  document,  and  Nokia  reserves  the  right  to  change  any  such
information  and  statements  without  notice.  Nokia  has  made  all  reasonable  efforts  to  ensure  that  the
content  of  this  document  is  adequate  and  free  of  material  errors  and  omissions,  and  Nokia  will  correct
errors  that  You  identify  in  this  document.  Nokia's  total  liability  for  any  errors  in  the  document  is  strictly
limited to the correction of such error(s). Nokia does not warrant that the use of the software in the Product
will be uninterrupted or error-free.

NO  WARRANTY  OF  ANY  KIND,  EITHER  EXPRESS  OR  IMPLIED,  INCLUDING  BUT  NOT  LIMITED  TO
ANY  WARRANTY  OF  AVAILABILITY,  ACCURACY,  RELIABILITY,  TITLE,  NON-INFRINGEMENT,
MERCHANTABILITY  OR  FITNESS  FOR  A  PARTICULAR  PURPOSE,  IS  MADE  IN  RELATION  TO  THE
CONTENT  OF  THIS  DOCUMENT.  IN  NO  EVENT  WILL  NOKIA  BE  LIABLE  FOR  ANY  DAMAGES,
INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL
OR  ANY  LOSSES,  SUCH  AS  BUT  NOT  LIMITED  TO  LOSS  OF  PROFIT,  REVENUE,  BUSINESS
INTERRUPTION,  BUSINESS  OPPORTUNITY  OR  DATA  THAT  MAY  ARISE  FROM  THE  USE  OF  THIS
DOCUMENT  OR  THE  INFORMATION  IN  IT,  EVEN  IN  THE  CASE  OF  ERRORS  IN  OR  OMISSIONS
FROM THIS DOCUMENT OR ITS CONTENT.

This document is Nokia proprietary and confidential information, which may not be distributed or disclosed
to any third parties without the prior written consent of Nokia.

Nokia  is  a  registered  trademark  of  Nokia  Corporation.  Other  product  names  mentioned  in  this  document
may be trademarks of their respective owners.

Copyright © 2019 Nokia. All rights reserved.

f Important Notice on Product Safety
  This product may present safety risks due to laser, electricity, heat, and other sources of danger.

Only  trained  and  qualified  personnel  may  install,  operate,  maintain  or  otherwise  handle  this
product and only after having carefully read the safety information applicable to this product.

The  safety  information  is  provided  in  the  Safety  Information  section  in  the  “Legal,  Safety  and
Environmental Information” part of this document or documentation set.

Nokia is continually striving to reduce the adverse environmental effects of its products and services. We
would  like  to  encourage  you  as  our  customers  and  users  to  join  us  in  working  towards  a  cleaner,  safer
environment. Please recycle product packaging and follow the recommendations for power use and proper
disposal of our products and their components.

If you should have questions regarding our Environmental Policy or any of the environmental services we
offer, please contact us at Nokia for any additional information.

2 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
Flexi NG Architecture

Table of Contents
This document has 65 pages
   
1 Changes in Flexi NG Architecture..................................................7
1.1 Changes between release 16.5 and release 17.5 .........................7
1.2 Changes between release 16 MP1 and release 16.5.................... 7
1.3 Changes between release 16 and release 16 MP1....................... 7
1.4 Changes between release 15 MP1 and release 16....................... 7
1.5 Changes between release 15 and release 15 MP1....................... 8
   
2 About this document.................................................................... 10
2.1 Scope........................................................................................... 10
2.2 Audience...................................................................................... 10
   
3 Flexi NG in 3GPP mobile network................................................ 11
   
4 Hardware architecture..................................................................13
4.1 ATCA HW platform....................................................................... 13
4.2 ATCA hardware architecture........................................................ 16
4.3 Blades.......................................................................................... 17
4.4 Internal network architecture........................................................18
4.5 Hardware variants........................................................................ 20
   
5 Software architecture................................................................... 21
5.1 Overview...................................................................................... 21
5.2 Flexi Platform Linux operating system......................................... 22
5.3 High availability............................................................................ 22
5.3.1 High availability in Flexi NG......................................................... 22
5.3.2 Flexi NG high availability implementation overview..................... 23
5.3.3 Basic high availability services.....................................................23
5.3.4 High availability concepts.............................................................24
5.3.5 High availability services architecture.......................................... 25
5.4 Disk I/O........................................................................................ 26
5.4.1 System disks................................................................................ 26
5.4.2 Logical volumes........................................................................... 26
5.4.3 Distributed replicated block device...............................................27
5.4.4 Storage solution with DRBD.........................................................27
5.4.5 Network file system...................................................................... 28
5.5 Software architecture overview.................................................... 28
5.5.1 Management blades.....................................................................28
5.5.2 Service blades..............................................................................29
5.5.3 Service aware blades...................................................................31
5.5.4 Interface blades............................................................................32
5.6 CPU core allocations....................................................................32
5.7 Message paths in Flexi NG.......................................................... 34
5.7.1 Internal traffic paths without DPI.................................................. 34

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 3
Flexi NG Architecture

5.7.2 Internal traffic paths with DPI....................................................... 35
5.8 Main functional areas................................................................... 37
5.8.1 Basic gateway functionality.......................................................... 41
5.8.2 Additional major functional areas................................................. 44
   
6 Operation and maintenance architecture..................................... 49
6.1 Operation and maintenance overview..........................................49
6.2 Secure shell connections............................................................. 50
6.3 User management........................................................................50
6.4 Operation and maintenance features...........................................52
   
7 Networking architecture............................................................... 57
7.1 Routing.........................................................................................57
7.1.1 Introduction to routing.................................................................. 57
7.1.2 Distribution architecture with centralized routing..........................59
7.1.3 Service blade and interface blade connectivity options............... 60
7.1.4 Advertising UE IP addresses....................................................... 61
7.2 Site connectivity........................................................................... 62
7.3 Network connectivity monitoring.................................................. 63
   
8 Glossary....................................................................................... 64

4 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
Flexi NG Architecture

List of Figures
Figure 1 Flexi NG in 3GPP mobile network...................................................... 12
Figure 2 ATCA cabinet front view..................................................................... 13
Figure 3 ATCA hardware and embedded software as part of a network element
............................................................................................................14
Figure 4 Types of ATCA embedded software and hardware building blocks... 14
Figure 5 Example of 16-slot shelf ATCA HW architecture used in a server-type
application.......................................................................................... 16
Figure 6 Blade locations................................................................................... 18
Figure 7 Base Interface.................................................................................... 19
Figure 8 Fabric Interface...................................................................................19
Figure 9 Flexi NG software architecture layers.................................................21
Figure 10 Conceptual model of a HAS cluster....................................................24
Figure 11 Logical volume groups........................................................................26
Figure 12 Management blade software architecture as main functional blocks.....
29
Figure 13 Service blade operating environments............................................... 30
Figure 14 Service blade software architecture as main functional blocks.......... 31
Figure 15 Service aware blade software architecture as main functional blocks...
31
Figure 16 Interface blade software architecture as main functional blocks........ 32
Figure 17 External connectivity via interface blades without DPI....................... 35
Figure 18 External connectivity via service blades without DPI..........................35
Figure 19 External connectivity via interface blades with DPI............................ 36
Figure 20 External connectivity via service blades with DPI...............................37
Figure 21 IPsec tunneling in SGi and Gi interfaces............................................ 43
Figure 22 L2TP connection to PDN.................................................................... 43
Figure 23 LIE software modules......................................................................... 44
Figure 24 RADIUS signaling...............................................................................45
Figure 25 Logical division between SPI and DPI in Flexi NG............................. 46
Figure 26 Charging in Flexi NG.......................................................................... 47
Figure 27 Packet traversing among IB and SB...................................................48
Figure 28 Operation and maintenance interfaces...............................................49
Figure 29 External and Internal usage of SSH from generic shells such as bash..
50
Figure 30 Relations between users, groups and permissions............................ 51
Figure 31 Example on linked configuration profiles............................................ 53
Figure 32 Distribution architecture with centralized routing................................ 59
Figure 33 VLANs on OSPF routing with interface blades...................................62

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 5
Flexi NG Architecture

List of Tables
Table 1 AB4 HW Resource utilization schemes.............................................. 33
Table 2 Supported modes for Flexi NG basic gateway functionalities............ 37
Table 3 Supported modes for Flexi NG additional major functional areas...... 40
Table 4 Terms and definitions..........................................................................64

6 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Changes in Flexi NG Architecture

1  Changes in Flexi NG Architecture
Changes between document issues are cumulative. Therefore, the latest document
issue contains all changes made to previous issues.

1.1  Changes between release 16.5 and release 17.5
Changes in issue 5-0
Chapter Operation and maintenance overview: removed FMA from figure Operation and
maintenance interfaces
Chapter deleted: Flexi NG Maintenance Application (FMA)

1.2  Changes between release 16 MP1 and release 16.5
Changes in issue 4-0
Editorial corrections throughout the document.

1.3  Changes between release 16 and release 16 MP1
Changes in issue 3-2
Chapter Flexi NG in 3GPP mobile network: updated 3GPP baseline for P-GW and S-GW
to release 11.

1.4  Changes between release 15 MP1 and release 16
Changes in issue 3-1

g Note:  The MBMS-GW functionality described in this document is available for trialing in
the current release, with productization aimed at the next release.

Chapter Operation and maintenance overview: in figure Operation and maintenance
interfaces, changed the connection between NetAct and Flexi NG from NE3S to
NE3S/WS.

Changes in issue 3-0
The following chapters have been updated to describe MBMS-GW functionality:
• Service blades
• Interface blades
• Main functional areas

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 7
   

Changes in Flexi NG Architecture Flexi NG Architecture

• Basic gateway functionality
• Additional major functional areas
• Introduction to routing
• Distribution architecture with centralized routing

Removed information on Flexi CO throughout the document.
Updated figures by renaming interfaces Gi to SGi and Gn to S1-U throughout the
document.
Chapter Flexi NG in 3GPP mobile network, updated Flexi NG in 3GPP mobile network
figure as below:
• added TWAG for S2a interface
• renamed Non-3GPP to CDMA, Trusted non-3GPP IP access to Trusted WLAN and
S2c to S2a
• added an HSGW box to link CDMA with PDN GW

Chapter Blades: added figure Blade locations.
Chapter High availability concepts: added load-sharing to the software redundancy
models supported by Flexi NG.
Chapter Basic gateway functionality:
• updated reference to Flexi NG User Guide chapter IP address allocation
• updated Load balancing section to describe the Internal load balancing functionality

Chapter Operation and maintenance features:
• section Configuration data management, added description of the new SCLI
transaction for configuration support
• section Software management, added information about Deep Packet Inspection
(DPI) bundle updated software
• added section for In Service Upgrade (ISUG) feature

Chapter Introduction to routing:
• added information that Flexi NG supports maximum 32 paths of each ECMP routes
• replaced control plane references with routing control plane

Chapter Distribution architecture with centralized routing:
• renamed IP networking stacks to IP packet forwarding stacks
• removed monitoring from the list of events handled by EdgeRouting daemon

Chapter Site connectivity: removed figure Shelf cabling when using direct connections to
interface blades

1.5  Changes between release 15 and release 15 MP1
Changes in issue 2-3
Editorial changes.

8 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Changes in Flexi NG Architecture

Changes in issue 2-2
Chapter Additional major functional areas: in Single diameter section, updated the
description of figure Packet traversing among IB and SB.

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 9
   

About this document Flexi NG Architecture

2  About this document
This document provides an introduction to the architecture of Flexi Network Gateway
(Flexi NG), covering the main aspects of the product structure and operation .

2.1  Scope

This document describes the Flexi NG hardware, software and networking architecture
on a high level. It is intended as an introduction which gives basic understanding
required for integrating and operating the system, and for this purpose the concepts are
usually not described in detail. Instead, the document contains references to more
specific information.
The product features or configuration of those features are also not in the scope of this
document.

2.2  Audience

This document is intended for everybody working with Flexi NG. It is recommended that
this document is read as the first step towards getting familiar with the system.

10 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Flexi NG in 3GPP mobile network

3  Flexi NG in 3GPP mobile network
Flexi NG can be used as a GGSN,as a serving gateway (S-GW), as a packet data
network gateway (P-GW), or as a combination of both S-GW and P-GW.
The 3GPP baseline for S-GW and P-GW is release 11.
The serving gateway (S-GW) is the gateway which terminates the interface towards
evolved universal terrestrial radio access network (E-UTRAN), GSM/EDGE radio access
network (GERAN), and UMTS terrestrial radio access network (UTRAN).
The PDN gateway (P-GW) is the gateway which terminates the interface towards the
packet data network. P-GW acts as a session anchor for functions such as IP address
allocation, charging and policy enforcement.
The GGSN functionality is included in Flexi NG for supporting UTRAN/GERAN access
networks. To support UE mobility between E-UTRAN and UTRAN/GERAN, both P-GW
and GGSN functions can be integrated into Flexi NG.
In Flexi NG, it is possible to deploy multiple gateway functionalities using the same
hardware and software. Each Flexi NG ATCA shelf can be independently configured
according to the options listed below:

• GGSN
• S-GW
• P-GW
• combined S-GW and P-GW

For more information on different deployments and external interfaces available in each
mode, see chapter Deployment options in Flexi NG Product Description.

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 11
   

Flexi NG in 3GPP mobile network Flexi NG Architecture

Figure 1 Flexi NG in 3GPP mobile network

Radioaccessnetwork (Evolved)PacketCore Gy
OCS

BTS BSC Gz/Bp(1)


Gz/Bp OFCS
2G SGSN/MME
Gb Gxc(2)
SGSN Gx PCRF
Gn
/Gp
Rx+
NodeB RNC
Iu S4 ServicesinPacket
3G S5 Gi/SGi
DataNetwork
S12/Gn/Gp
S3
Serving PDN Operator
S1-U services
eNodeB S11
Gateway
LTE S1-MME
Internet

MME
Corporate

RADIUS
services
S10
CDMA HSGW

S2a
AAA
S6b(3)
ePDG
S6a HLR/
Untrustednon-3GPPIPaccess
S2b HSS
TWAG
SGs/Sv
TrustedWLAN MSS
S2a

Controlplane
Userplane

(1)SGW-CDRsaregeneratedwhen:
-FlexiNGisusedasastandaloneS-GW
-FlexiNGisusedasacombinedS-GWandP-GWandthebearerisconnectedthroughtheS5interfacetoaseparateP-GW

(2)S5-PMIPvariantonly

12 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Hardware architecture

4  Hardware architecture

4.1  ATCA HW platform

ATCA HW is based on the Advanced Telecommunications Computing Architecture
(AdvancedTCA or ATCA) specifications.

ATCA specifications
ATCA is a series of industry standard specifications for the next generation of carrier
grade communications equipment. These specifications are driven by over 100
companies with the PCI Industrial Computers Manufacturers Group (PICMG). The
specifications mainly concentrate on three areas:

• mechanics of building blocks (shelf, blade, mezzanine, rear transition module)
• interconnects
• hardware management

Figure 2 ATCA cabinet front view

Reartransitionmodules

Cabinet

Shelf(16-slot) Powerdistributionunit
for16-slotshelf
Blades

AMCs

DN70207711

DN70429962
Frontview

Building blocks of ATCA-based network elements

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 13
   

Hardware architecture Flexi NG Architecture

The ATCA building blocks consist of:

• ATCA hardware, ranging from mechanical/electromechanical units, such as cabinets
and shelves, to units that provide processing and network interfaces, such as blades,
AMCs and RTMs. The exact combination of hardware is defined by the network
element architecture.
• ATCA embedded software; this means software that is integral to the functioning of a
particular hardware unit, such as BIOS, an embedded Linux operating system and
hardware management software. The main types of embedded software are
introduced below in ATCA embedded software.

On top of the ATCA building blocks, network elements consist of layers of application
software and, depending on network element, a software platform that provides the main
operating system.

Figure 3 ATCA hardware and embedded software as part of a network element

Application

Softwareplatform

ATCAhardwareplatform

Embeddedsoftware
Hardware
DN0948687

ATCA embedded software
Several types of embedded software are used by the ATCA hardware building blocks:

Figure 4 Types of ATCA embedded software and hardware building blocks

Embeddedsoftware Hardwarebuildingblock

EthernetswitchingSW Interconnectiondomain Ethernetswitchesinhubandcarrierblades

BIOS,embeddedLinux CPUsandunitcomputerson
Computerdomain
andBSP bladesandAMCs

Blades,RTMsandAMCswith
NetworkinterfaceSW Networkinterfacesdomain
networkinterfaces

Shelfmanagerandallfield-replaceable
HWmanagementSW HWmanagementdomain
units

Powerfeed Powerentrymodules

Mechanicsandelectromechanics Cabinet,shelf,fanmodules

• Ethernet switching SW
Ethernet switching software runs on units that are equipped with their own switches,
directing Ethernet frames to/from the backplane interfaces.
• BIOS, embedded Linux and BSP

14 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Hardware architecture

The computer domain’s embedded software contains BIOS for main CPU processors
(such as in CPU blade), boot and reset logic, as well as an embedded Linux
operating system as part of the board support software package (BSP) in all
hardware units with unit computers. This software resides in the local flash memory
of each unit.
• Network interface SW
Network interface software controls the external traffic flowing through blades and
AMC modules with network interfaces.
• HW management SW
Hardware management software consists of software related to shelf and system
management, including hardware management controller firmware, shelf manager
software, communication over IPMB-0 and IPMB-L, management communication
over the base interface using remote management control protocol (RMCP) and
remote procedure call protocol (RPC), and remote access to blades and AMCs
(serial over LAN). The HW management domain includes also FRU information
storages in all hardware products that have a hardware management controller.
• Software management (not illustrated)
Software management software handles all embedded software updates.

Benefits of ATCA
The main strength of ATCA is in its versatility, its ability to support larger volumes, and its
capacity to harmonize different platforms. In the long run, ATCA will allow faster time to
market and lower costs in terms of both equipment and development, as it will be
possible to employ a wide variety of building blocks with minimal modifications.

• Modularity and configurability
ATCA allows diverse applications to be created in one platform using multiple
modules with various interfaces, including CPUs and storage media from different
manufacturers.
• Redundancy
ATCA features many levels of redundancy throughout the system, achieving
99.999% availability (five-nines or carrier grade availability). The option to allow less
demanding applications to utilize non-redundant configurations for lower cost is also
possible.
• Support for Ethernet switching fabric
ATCA specifications support various serial-type switching fabrics, such as Ethernet
and PCI Express. The ATCA HW platform currently uses 10 Gbps or 40 Gbps
backplane Ethernet technology, depending on the used hardware.
The backplane is a dual star backplane, which means that each slot has two
backplane links. One connector connects the blade to the hub blade in slot 8 and the
other to the hub blade in slot 9. This means that each slot has 20 Gbps or 80 Gbps
total backplane bandwidth, depending on the used hardware. For redundancy
reasons, system dimensioning allows Flexi NG to run at full speed with just one
active hub blade.
• Scalable capacity
Scalability in ATCA is enabled by a centralized switching hub, interconnected to all
shelf slots in a star configuration. The hub can handle full-duplex line rate switching
at 40Gbps to all slots.
With the 16-slot shelf, capacity can be scaled upwards by adding the necessary
amount of blades, RTMs and AMC modules. On the cabinet level, more shelves or
even cabinets can be added.
• Regulatory requirements compliance

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 15
   

Hardware architecture Flexi NG Architecture

ATCA adheres to operating requirements and environmental regulations set out by
the Network Equipment Building System (NEBS) and the European
Telecommunications Standards Institute (ETSI).
• Hot-swappable units
Blades and other field replaceable units (FRUs) are hot-swappable.
• Faster time to market
Open architecture allows faster innovation and reduced engineering time.

4.2  ATCA hardware architecture

The ATCA hardware architecture allows network elements to be created from a set of
basic hardware building blocks: cabinet, shelf, PDUs, blades, AdvancedMCs (AMCs)
and rear transition modules (RTMs).
The example below illustrates some of the main architectural concepts:

• The smallest operational size of the HW platform is one shelf.
• The shelf manager is the highest entity in the shelf management subsystem; it
controls all the other field-replaceable units (FRUs) in the shelf. Shelf managers are
implemented as separate field-replaceable hardware modules in the shelf.
• Blades, RTMs and AMCs are interconnected through base and fabric interfaces in
the shelf backplane.
• Network interfaces can be provided from several different FRUs, depending on the
selected hardware configuration.

Figure 5 Example of 16-slot shelf ATCA HW architecture used in a server-type
application
Externalnetworks Externalnetworks

RTM

Fabric
switch Fabricinterface
Blade
Blade

Other
ATCA RTM
Hub Blade
shelves

RTM
Blade
Base Baseinterface
switch

Shelf Managementbus
manager

16 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Hardware architecture

4.3  Blades

Flexi NG uses the following blade types:

Hub blades
Hub blades provide the intra-shelf connectivity between the blades. A hub blade provides
base interface and fabric interface connectivity for each blade in the ATCA shelf.

Management blades
Management blades (MB) are used for O&M and management functionality. The
hardware used for management blades is based on the x86 Intel processor. The
management blades also provide hard disks for the system. These hard disks are used
for storing the software images, including the operating system and configurations, as
well as storing the data produced by a running system, like logs, charging data and
alarms.
Note that management blades are also known as CLAs. These terms are used
interchangeably in this document.

Service blades
Service blades are used for both control and user plane functionality. A service blade
contains two multi-core ATCA packet processors, which are based on the MIPS
architecture. Both processors run an independent gateway instance that consists of two
nodes running on dedicated cores:

• Application services node (AS node) hosting the gateway control plane.
Each AS node can have its own configuration and interfaces.
• The simple executive node (SE node, also known as Fastpath or accelerated packet
processing) hosting the gateway user plane.

In other words, each service blade has two AS nodes and two SE nodes.
The service blades also take advantage of hardware acceleration for services such as
IPSec and checksum calculations.

Service aware blades
A Service aware blade (SAB) is an optional blade type used for providing the deep
packet inspection (DPI) functionality. Having dedicated hardware for DPI provides
flexible scalability to the dimensioning, as the need for DPI capacity varies greatly
depending on the operator’s use case (all traffic or only a small portion of it) and traffic
profiles. Service aware blades use the same hardware as service blades.

Interface blades
An Interface blade (IB) is an optional blade type used for aggregated network
connectivity, MPLS, BGP, single diameter functionality and load balancing (load-
balancing mode and single addressing mode). It can be used for reducing the amount of
needed external ports and/or for interface redundancy when separate Gn and Gi routers
are deployed. Interface blades use the same hardware as service blades.

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 17
   

Hardware architecture Flexi NG Architecture

Customization blades
A Customization blade (CB) is an optional blade type that can be used for operator-
specific application development within Flexi NG. Customization blades use the same
hardware as management blades.
For a deployment view, refer to the following figure.

Figure 6 Blade locations

CB/SAB/IB/SB
CB/SAB/IB/SB
SAB/SB

MB1
IB/SB
IB/SB

IB/SB

SB
SB
MB0

SB
HB
HB
SB
SB
SB

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

FlexiNG

4.4  Internal network architecture

The Flexi NG ATCA hardware provides a high performance clustered environment with
two internal data traffic networks both implemented with Ethernet technology. The base
interface (BI) is dedicated for control and management traffic, and the fabric interface
(FI) is reserved for the rest of the traffic. Both of these networks are implemented in the
backplane of the shelf. The front side connectors of each blade are not used for
accessing BI or FI networks.
In the ATCA cluster, the management blade (x86) is directly connected to both BI and FI
networks. The AMPP blades have two multi-core processors (CPU0 and CPU1 in
figures), which are connected to the BI and FI networks through a switch. Shelf
Managers (ShM) have access to the BI only. The AHUB blades have the switches
connecting all slots to the BI and FI networks.
Both FI and BI networks are duplicated to avoid single point of failure (SPOF). The
Ethernet switches (on the HUB blades) are duplicated, and all nodes have network
interfaces to both switches.

18 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Hardware architecture

Figure 7 Base Interface

Figure 8 Fabric Interface

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 19
   

Hardware architecture Flexi NG Architecture

The internal network, which is based on Ethernet technology both in the base interface
and the fabric interface, is used when nodes and processes inside the cluster
communicate with their respective peer entities. The internal network is not visible to the
network elements outside the cluster.
Two types of IP addresses are used in the internal network: redundant addresses are
associated with recovery groups and node addresses are associated with nodes. IP
addresses are allocated from an internal IPv4/IPv6 subnet. The system is responsible for
allocating and assigning all the internal IP addresses in the commissioning phase. The
IPv4 subnetwork reserved for the internal network cannot overlap with the external
network.

4.5  Hardware variants

Flexi NG software supports several hardware generations and variants. These variants
have different characteristics related to the amount of memory, the amount of CPU core,
hard disk sizes, number of interfaces, and so on. Newer hardware variants provide more
effective processing and other capabilities, but the basic roles of the blades are not
affected by the actual hardware.
Flexi NG software on the feature level does not depend on the actual hardware it runs
on. Several abstraction layers are used to separate the gateway logic from the low level
hardware. Naturally the software still has some visibility to the hardware, so that, for
example, with a larger amount of memory it is possible to support more bearers in the
service blade, and more flows in the service blades, service aware blades and interface
blades. The number of value-added features that can be simultaneously enabled in
certain blade types also benefit from having a larger total amount of memory available,
although the memory requirements of these features usually scale up with the amount of
bearers. In another dimension, increased CPU power also means increased use plane
data throughput.
The blade variants also have differing amounts of external interfaces, which must be
taken into account when planning the site connectivity.

g Note:  Flexi NG does not support mixing the hardware variants in a single shelf.

20 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Software architecture

5  Software architecture

5.1  Overview

The overall software architecture of the Flexi NG consists of several layers as shown in
the following figure.

Figure 9 Flexi NG software architecture layers

At the bottom of the stack, the Fastpath execution environment is used in blades which
process the packets for high-throughput end-user data handling. This includes both basic
services needed in the standard networking, as well as Flexi NG specific application
modules.
The operating system provides basic services and a run-time environment. On top of the
operating system, the software platform enriches many features while also providing
additional telecommunication network element specific features. Flexi NG uses many
basic platform services without any major changes. The product-specific configurations,
alarms, and license handling have been built on a foundation provided by the platform.
At the highest level, the Flexi NG specific application logic provides the gateway element
core functionality, without having to take part in run-time environment basic operations.
The following chapters provide a high level description of the operating system, internal
storage solutions and software architecture with the different blade types used in Flexi
NG, and introduce some basic messaging flow concepts and provide some information
on selected features.
For more information on the file system in Flexi NG, see chapter File System in
document Troubleshooting Flexi NG.

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 21
   

Software architecture Flexi NG Architecture

5.2  Flexi Platform Linux operating system

Flexi NG uses the Flexi Platform's Linux operating system. This product includes the
base kernel, kernel modules (optional low level features and drivers to be loaded as
needed), and various software components provided by Nokia. These software
components are also known as userland packages.
The userland is located outside the kernel, and any application running outside the
kernel is known as a userland application. The main difference is that the applications in
the kernel run in privileged mode and the applications in userland run in non-privileged
mode.
In privileged mode, functions and applications have unrestricted access to memory and
other resources in the system. In non-privileged mode, functions and applications have
limited access to resources. In this mode, the kernel takes care of which resources are
allocated to each application, as well as when they are allocated. Therefore, when an
application experiences resource handling problems, it cannot starve the other
applications of resources, provided that it is running in non-privileged mode.
Most applications run in userland, and it is not possible for regular users to instruct any
applications to run within the kernel. This increases the stability of the environment
because no application can prevent other applications from accessing critical system
resources such as memory or processor time.

Linux kernel
The Linux kernel manages processes and resources in the Linux operating system. The
kernel is constantly evolving to support new technologies and architectures. For more
information on the standard Linux kernel features, see Linux kernel documentation. The
kernel is the entity that performs the basic OS functions.
The kernel is reconfigured to support only those features that are needed by the network
element. This is done to optimize the kernel size and required memory space, which in
turn maximizes the resources available for the applications.

Packages
The operating system includes a set of necessary packages selected by Nokia. The
current version includes around 200 packages. Some of these packages are modified or
extended by Nokia.

5.3  High availability
5.3.1  High availability in Flexi NG

This chapter introduces the high availability services, which forms the foundation for
software management, supervision and run-time environment for all processes in the
Flexi NG.
For more information, see High Availability Solutions Reference Guide.

22 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Software architecture

5.3.2  Flexi NG high availability implementation overview

High availability (HA) solutions improve packet network robustness and ensure
uninterrupted end-user service in case of component malfunction. High availability also
improves element maintainability with redundant hardware resources, making sure that
business critical data is not lost, and helps to avoid a signaling flood when an element is
restarted. The high availability options available in Flexi NG provide 99.999% availability
(at maximum 5 minutes downtime during a year) at different redundancy levels, including
session continuity through the use of session replication in active-standby service blade
pairs.In the cloud deployment, the redundancy of the hardware is responsibility of the
infrastructure provider.
Basic Flexi NG functionality provides N+ high availability that includes full redundancy for
all external interfaces and hardware components, excluding service blades, where
sessions on a failing service blade need to be re-established.
The optional 2N high availability feature extends system redundancy to service blades,
providingfor the GatewayNodes provides session continuity. The 2N high availability
feature uses the hot active-standby redundancy model, in which session redundancy is
achieved by using a standby unit that replicates the data of the active unit and takes over
the functionality of the active unit if a failure occurs. This type of switchover allows
session continuity as reconnection is not required.
Both N+ and 2N high availability are supported in all Flexi NG modes (GGSN, S-GW, P-
GW, and combined S-GW and P-GW).
The high availability solution (N+ or 2N HA deployment) used in Flexi NG is selected in
the commissioning phase. For more information on selecting the HA deployment option
during commissioning, see Deployment options in Commissioning and Integrating Flexi
NG.

5.3.3  Basic high availability services

The High Availability Services (HAS) subdomain contains services that enable:

• Definition of a cluster with the desired infrastructure (nodes, services implemented by
the software loaded and started up in the nodes), and modification of the cluster
infrastructure at cluster runtime.
• Startup and shutdown of the cluster and its elements and services.
• Runtime supervision of the elements and services in the cluster.
• Management of the states of the elements and services in the cluster.
• Automated detection, isolation and recovery from faults in the cluster.

HAS minimizes the effect of a detected fault by automatically reconfiguring the system
according to the dynamic state of its elements. HAS executes automated recovery
actions to recover from a detected failure, for example, by exchanging the roles of the
active and standby elements upon a failure in the active element. HAS itself is
implemented fully in the Linux userspace. However, some critical parts of it run in the
Linux real-time scheduling class to guarantee that they do not “starve” in certain overload
situations.
Additionally, HAS:

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 23
   

Software architecture Flexi NG Architecture

• Provides the operator with an ability to view and manipulate the states and statuses
of the managed objects in the system through a uniform user interface.
• Supports scaling the physical capacity of the system, for example, by adding more
nodes to the cluster at runtime.

HAS monitors applications firstly, by passive supervision, which detects unexpected
process terminations, and secondly, by active supervision, which periodically checks the
health of the application by sending heartbeat messages to the application and expecting
a reply.

5.3.4  High availability concepts

The highest level entity in the high availability terminology is a cluster, which contains
one or several nodes. A node is typically hosted by a blade containing one or several
CPUs which share a single Linux image.
The following figure represents the basic conceptual model of a HAS cluster:

Figure 10 Conceptual model of a HAS cluster

HAS supports several redundancy models. A redundancy model defines how a service is
deployed and handled in the system, and determines recovery actions when a failure is
detected. Flexi NG supports all of the following software redundancy models:

• hot active/standby redundancy
• cold active/standby redundancy
• load-sharing

24 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Software architecture

• no-redundancy

The redundancy solution is usually discussed on the node level, rather than on individual
recovery group level. Still, the recovery groups are visible for example in some IP
addressing configurations. For more information on redundancy models, see Flexi NG
High Availability Solutions Reference Guide.

5.3.5  High availability services architecture

The HAS system architecture consists of the HAS central part running on a single node,
and distributed parts running on every node in the cluster.

HAS central part
The central part of the HAS is the cluster manager process (HASClusterManager).
This process runs on one of the active/standby redundant nodes. If the active instance
fails, backup instances of this process in cold standby mode take over in other nodes.
The redundant CMF feature ensures that one—and only one—active instance of the
cluster manager process is running in the cluster. If the node running this process fails, a
backup process on another node is automatically activated. The show cmf SCLI tool
can also be used to view the status of cluster manager process instances.

HAS distributed part
The central part of the HAS controls processes on a cluster-wide basis via the node
agent processes (HASNodeAgent) running on every node in the cluster.
The node agent process reacts to faults of resources within the node where it is running.
In other words, the agent process can also operate without the involvement of the cluster
manager process.
The node agent autonomously performs resource isolation within the node, provided the
node is operational. If the cluster manager is available, it decides the recovery action (for
instance an RU restart or switchover), otherwise the node agent autonomously runs the
recovery unit repair cycle—for instance, by periodically attempting to restart the failed
recovery unit.
When a node in the cluster is powered on or restarted, the operating system
automatically starts the HAS node agent process on this node. The node agent
communicates with other parts of the HAS system and starts, stops, and restarts the
processes in the node in a controlled fashion.
The HAS node agent passively supervises all the processes it has started. It can react to
the failure and, for example, restart the process.
If the node agent determines that the faulty managed object is a recovery unit instead of
a process, the cluster manager is notified. The cluster manager might order this node
agent to restart the RU, or order the node agent running in another node to start the
standby RU in the RG. The corresponding node agent then starts the individual
processes as part of the RU startup.

Handling of disk failures in HAS
The HAS monitors disk resources in the CLA nodes by checking for disk SCSI errors and
periodically accessing the available physical disk(s). If serious errors are detected, an
attempt is made to raise an alarm and the node is reported faulty. This leads to an

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 25
   

Software architecture Flexi NG Architecture

attempt to reboot the node. An attempt to raise an alarm can be unsuccessful in single
CLA configurations since the disk failure might handicap the alarm system. For more
information, refer to alarm 70359 HARD DISK DRIVE FAILURE.

5.4  Disk I/O
5.4.1  System disks

All software and configuration data resides on a redundant pair of centralized system
disks. All software and configuration data can be accessed from these disks by CLA
nodes. The other nodes can access their software and configuration data using network
services provided by the CLA nodes.
The CLA nodes allow the other nodes to write variable data to the system disks using the
Network File System (NFS). The nodes may also use other storage medium to store
variable data.
Some nodes can also have partial local replicas of the system disks to allow them to
function more independently.

5.4.2  Logical volumes

Logical volumes are used in addition to the more traditional direct disk partitioning.
Logical volumes add a layer of abstraction between the actual disk partitions and the
mount points that the OS uses to write to the disk.
In logical volume management, a disk partition or partitions from one or multiple disks
(known as physical volume) are added to a volume group. This volume group is
equivalent to a single hard disk in the traditional partitioning scheme. This is illustrated in
the following figure.

Figure 11 Logical volume groups

26 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Software architecture

Logical volumes are created within the volume group. The actual physical disk partitions
are irrelevant in this case as the logical volumes are mapped into the volume groups
instead of into physical disks or disk partitions.
When volume groups are used instead of direct disk partitions, the system becomes
more flexible and requires less downtime. For example, if one logical volume within a
volume group becomes full, it is possible to reduce the size of another logical volume
within the volume group dynamically, and thus increase the size of the full logical volume
without downtime.
It is also possible to add additional physical volumes into a volume group. After the
expansion of the volume group, the full logical volume can be expanded to use the newly
available space within the volume group. This reduces downtime and enables more
flexible administration of storage resources. It is even possible to replace smaller hard
disks with larger disks - without losing data - by dynamically shrinking and expanding
logical volumes.

5.4.3  Distributed replicated block device

The Distributed Replicated Block Device (DRBD) is a kernel module that allows online
replication of disk devices between two nodes. All data written to a (primary) DRBD
device in one node is sent over the network and written to a (secondary) DRBD device in
another node. Hence, DRBD can be considered as a network-based RAID 1
implementation.
A DRBD device can be read-write- (or read-only-) mounted only in the node where the
DRBD device is in primary state. A secondary DRBD device cannot be mounted at all. A
secondary DRBD device that needs to be mounted must first be promoted to the primary
DRBD device. This requires dropping the existing primary device to the secondary state.
Handling of DRBD devices is performed automatically by the high availability services
(HAS). Each DRBD device is associated with one active-standby recovery group. During
startups and failovers HAS sets the DRBD device states and mounts the device to the
node where the recovery group has an active recovery unit. Each DRBD device is
controlled separately so depending on recovery group role assignments, a node can
have some DRBD devices in primary and others in secondary state.
During node restarts or failures, the data of DRBD devices can become unsynchronized.
The disk resynchronization protocol of DRBD is intelligent. Usually only the changed
blocks need to be copied, and the resynchronization operation is relatively fast.

5.4.4  Storage solution with DRBD

The storage solution with shared system disks provides a redundant environment for
clustered applications. The system disks are directly accessible by the CLA nodes, and
the other nodes can load their software and configuration data using network services
provided by the CLA nodes. The CLA nodes allow the other nodes to write to the system
disks using the Network File System (NFS), but services running in these nodes may
also use other storage media to store variable data. Some nodes can also have partial
local replicas of the system disks to allow them to function more independently.

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 27
   

Software architecture Flexi NG Architecture

Each system disk contains a number of partitions. Typically, the first partition is the boot
partition, which contains files needed to boot the CLA nodes and possibly other nodes
that can access these disks. On each system disk, there can be one optional partition
called the compatibility partition, which is used in major software upgrades.
The CLA nodes have directly attached storage (DAS) devices that use distributed
replicated block devices (DRBD) to mirror the master state volume, the master log
volume, the cluster manager state volume, and all application-specific logical volumes.
Additionally, Flexi NG has DRBD-protected partitions mainly for storing CDR files, but
also for internal data which needs permanent and reliable storage.

5.4.5  Network file system

Flexi NG utilizes Network file system (NFS) to make software available to diskless
nodes. The NFS server is a critical service within the network element. To get more
independence from the centralized NFS server, some of the critical services (such as
HAS) on diskless nodes have their software copied to a local RAM disk, therefore
removing the runtime dependency on NFS. As an additional effort to make the NFS more
robust, TCP instead of the traditional UDP is used as the underlying protocol.
The default security settings set up filters for limiting visibility and access to the NFS only
for the clients on the internal LAN and subnets.

5.5  Software architecture overview

This chapter gives an overview on the Flexi NG software architecture in each main blade
type on the logical level. Individual processes are not covered, but more details can be
found in Troubleshooting Flexi NG appendices Flexi NG process information and
Recovery groups.
For a generic overview on the blade roles and hardware, see chapter Hardware and
deployment overview in Site Connectivity Guidelines.
For detailed information on how the logical application interfaces are available in different
Flexi NG modes and blades, see chapters Logical interfaces in different modes and
Logical interface mapping to recovery groups, nodes, and physical interfaces in Site
Connectivity Guidelines.

5.5.1  Management blades

Management blades are used for O&M and management functionality. The overall
architecture is described in the figure below. Note that management blades are also
known as CLAs. These terms are used interchangeably in this document.

28 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Software architecture

Figure 12 Management blade software architecture as main functional blocks

There are many centralized services which run on management blades so that the other
blades act in simpler client roles. This applies to services which distribute information
(such as propagating different kinds of configuration information) and to services which
aggregate data from the other nodes (such as performance statistics, alarms, tracing
data).
For example, the performance management data (statistics counters) is collected on
each node separately, and provided to a centralized service running on the management
blade. This service publishes the separate and aggregate statistics towards the official
performance management interfaces.
As another example where the information flow is going in the opposite direction, the
configuration management functionality is based on central storage (LDAP) and its
controlling entities, which run on management blades. When a node (SB, SAB, IB)
comes up or a change in the configuration during runtime has been detected, the
centralized part is responsible for informing all the interest parties about the change. The
nodes or rather, the processes running on those nodes will then read and process those
configurations. Each node will also relay the configurations all the way to the local
Fastpath when necessary.
The generic network element control software, such as the high availability (HA) service,
also run mainly on the management blades, while having only distributed agent software
in the other node types.
One of the most crucial services is provided by the central routing daemon. This routing
daemon controls all dynamic routing protocols, maintains neighbourships and controls
the distribution of forwarding information inside Flexi NG. For more information, see
chapter Distribution architecture with centralized routing.
All services utilizing the hard disks are located in the management blades (for example,
logging, subscriber tracing, CDR storage).
The management blades are not directly involved in user packet handling.

5.5.2  Service blades

The service blades (SB) run basically all of the 3GPP-defined gateway element service
logic. Each service blade has two independent processors, which implement
independent gateway instances.
There are two distinctive operating environments in the service blades: the Linux and the
Fastpath.

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 29
   

Software architecture Flexi NG Architecture

The Linux environment handles all the standard control plane activities (including end-
user signaling, UE IP address allocation, and session maintenance) and specific tasks
such as lawful interception and subscriber tracing. Each CPU core allocated to the Linux
can run any process with standard scheduling.
The Fastpath environment is specialized for high-performance packet analysis and
forwarding. The processing is done in a pipelined mode of operation, where the
individual CPU cores have specialized roles. The whole Fastpath is a single binary
running directly on a very thin operating system.

Figure 13 Service blade operating environments

The main function of the control plane is the end-user session management and eMBMS
session management (multicast traffic needs to be forwarded to a group of users). The
session control process includes most of the control logic and databases, and dedicated
signaling processes per protocol are used for encoding/decoding tasks. The control
plane also includes specific features such as lawful interception (LI), together with
various important auxiliary services such as agents for system services such as O&M
and high availability.
The overload control is implemented on all application software, which means that the
first process that handles the new incoming signaling procedure can detect overload and
perform necessary actions depending on the procedure.
Besides simple packet forwarding, the Fastpath handles for example service awareness
(SA) including shallow packet inspection (SPI), policy control and charging (PCC) and
Quality of Service (QoS) enforcement. The user plane load can also be taken into
account in control plane overload control decisions.

30 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Software architecture

Figure 14 Service blade software architecture as main functional blocks

5.5.3  Service aware blades

The service aware blades (SAB) are needed for deep packet inspection (DPI). If the
service awareness analysis in the service blade notices that there is a L7 PCC filter for
the packet (possibly after first checking the L3/L4 filters), the packet is forwarded to a
SAB node for further analysis. For more information, see chapter Deep packet inspection
in Service Awareness.
Similarly as with the service blades, the SABs also have two distinctive operating
environments: the Linux and the Fastpath.
The Linux side handles basic O&M operations and DPI reporting function together with
various important auxiliary services such as agents for system services such as high
availability.
The Fastpath handles all the end-user packets for service awareness, including DPI
analysis and policy control and charging (PCC) rule matching. If the DPI analysis did not
produce a match to the rules, it is possible to continue the SPI analysis in SAB. The final
result of the analysis is returned to the service blade, which handles all necessary
actions defined in the PCC rules.

Figure 15 Service aware blade software architecture as main functional blocks

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 31
   

Software architecture Flexi NG Architecture

5.5.4  Interface blades

The interface blades (IB) are used for traffic aggregation.
Similarly as with SBs and SABs, the IBs also have two distinctive operating
environments: the Linux and the Fastpath.
The Linux side handles basic O&M operations together with various important auxiliary
services such as agents for system services such as high availability. When using single
addressing mode load balancing, IBs also participate in the peer element management.
In case single diameter functionality is used, diameter based connections are maintained
by IB SingleDiameter service. Diameter application related messages, which are
basically handled on SBs, are forwarded by IB toward the appropriate SB on ingress
direction or externally routed if received from SB on egress direction.
In case single diameter functionality is not in used then diameter related messages do
not traverse Linux side of IB.
The Fastpath takes care of all end-user packet handling. Besides aggregating physical
interfaces, it is also possible to use the IBs for aggregating (summarizing) the routing
advertisements (for example, for host routing), and to provide MPLS and BGP
connectivity.
For multicast routes, the Protocol Independent Multicast (PIM) is supported to allow
dynamic learning of multicast registrations in the network and to set up the interface
blade specific multicast forwarding accordingly. Currently, the only supported mode is
PIM-SSM (Source Specific Multicast).

Figure 16 Interface blade software architecture as main functional blocks

IBnode
Linux
O&Magents Singleloopback

SingleDiameter
BFD Bidirectionalforwardingdetection
MPLS Multiprotocollabelswitching
O&M Operationandmaintenance
QoS Qualityofservice
Fastpath

MPLStermination QoS BFD


Forwarding Externalinterface&routeaggregation

5.6  CPU core allocations
Flexi NG uses several different blade types, operating environments and internal
configuration to optimize the system performance. Even when the same blade hardware
is used, the allocation of cores between the user plane (Fastpath) and control plane
(Linux) can vary, as can the role of the cores in the Fastpath.

32 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Software architecture

Note that Flexi NG operates stably even when the CPU load reaches 100%, as long as
generic resources are available. For more information about system stability protection
mechanisms, see chapter Overload control in Flexi NG User Guide.

Management blades
Management blades run non-CPU-intensive tasks. Linux scheduling allocates
processes/threads to the cores like it does for other userland programs.

Service blades
In the control plane, the CPU cores do not have specific roles. Usually the most of the
CPU resources are consumed by the session control process instances. Other
processes share the rest of the cores according to the normal Linux scheduling.
In the user plane, dedicated roles have been assigned to the CPU cores:

• Most of the CPU cores run the application logic.
These CPU cores take new jobs until they overflow, and only then the next cores are
utilized.
• Some cores are dedicated for packet forwarding.

To provide some dynamic adaptation to varying system loads, several cores are shared
between application and forwarding tasks. Additionally, the application cores can also
join in the output handling if the dedicated cores are not enough for the task. Note that
the amount of cores for each task is also dependent on the hardware variant.
This also means that the load factor of single core(s) cannot be used as an indicator.
Instead, Flexi NG provides an overall load factor in the statistics and SCLI, which takes
into account the core roles and internally calculates the overall load factor.
For AB4 HW, it is possible to have two resource utilization schemes defined in the table
below.

Table 1 AB4 HW Resource utilization schemes
       
Scheme Cores used by Linux Cores used by Note
Fastpath

User plane oriented 8 24 Default setting

Control plane oriented 12 20

There is an available SCLI command that can be used for changing the configuration of
resource allocation scheme of all service blade nodes. To use the updated configuration,
it is needed to reboot all service blade nodes.

Service aware blades
In the control plane, the CPU cores do not have specific roles.
In the user plane, dedicated roles have been assigned to the CPU cores. A few cores
are dedicated for packet I/O processing while the rest work totally independent of each
other on DPI analysis (sharing load as evenly as possible).

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 33
   

Software architecture Flexi NG Architecture

5.7  Message paths in Flexi NG

This section explains some basic concepts related to packet handling inside Flexi NG
utilizing a few specific packet path examples. The purpose is to provide the reader with
an understanding on internal packet paths that might be valuable for collecting specific
troubleshooting information (for example, interface captures) and illustrating the locations
of possible bottlenecks in the data paths in hardware and software.
This chapter concentrates on end-user packet handling (including both control and data
plane). O&M connectivity is not covered.
The blades offer connectivity via multiple different types of external interfaces. In
addition, the physical interfaces can be located in the front panel or the rear panel. For
more information, see chapter Interface configuration in Flexi NG User Guide.

5.7.1  Internal traffic paths without DPI

The following figures show the packet paths without the DPI feature. The figures are also
applicable for deployments having SABs for packets which do not require DPI analysis
(for example, no service awareness needed at all, only SPI is enough, or even with DPI
for certain packets inside packet flows when the DPI offloading feature in SBs is able to
use an existing classification based on previous packets of the flow).
The user plane packets are always handled only in the Fastpath, and the control plane
(signaling) packets are handled on the Linux environment providing connections also
towards neighboring control plane elements. One exception are the address resolution
protocol (ARP) packets and the neighbor discovery (ND) packets, which are always
pushed to Linux.
When using interface blades, all end-user packets enter and exit Flexi NG via the
external interfaces located in the interface blades as shown in the figure below.

34 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Software architecture

Figure 17 External connectivity via interface blades without DPI

When interface blades are not used, all packets enter and exit the Flexi NG via the
external interfaces located in the service blades as shown in the figure below.

Figure 18 External connectivity via service blades without DPI

5.7.2  Internal traffic paths with DPI

The following figures show the packet paths with the DPI feature. If there are subscribers
which do not need DPI analysis, the packet paths are essentially the same as described
in the previous chapter.

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 35
   

Software architecture Flexi NG Architecture

Only the user plane packets are sent to the DPI analysis. The DPI analysis is always
handled only in the Fastpath.
When using interface blades, the packets enter and exit the Flexi NG via the external
interfaces located in the interface blades as shown in the figure below.

Figure 19 External connectivity via interface blades with DPI

When interface blades are not used, all packets enter and exit the Flexi NG via the
external interfaces located in the service blades as shown in the figure below.

36 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Software architecture

Figure 20 External connectivity via service blades with DPI

5.8  Main functional areas

The purpose of this chapter is to describe the major feature and functional areas in the
Flexi NG architecture. In this scope, individual features are not discussed in depth.
Instead, the chapter describes logical functionality areas, including their location in the
overall architecture.
The tables below show which functions are enabled in different Flexi NG modes.

Table 2 Supported modes for Flexi NG basic gateway functionalities
Functionality Supported modes
Session management GGSN
S-GW
P-GW
Combined S-GW and P-GW

UE IP address allocation GGSN
P-GW
Combined S-GW and P-GW

Load-balancing mode Gn interface GGSN

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 37
   

Software architecture Flexi NG Architecture

Table 2 Supported modes for Flexi NG basic gateway functionalities (Cont.)
Functionality Supported modes

g Note:  This  mode  applies  only  to P-GW


Control plane interfaces. Combined S-GW and P-GW

Gp interface GGSN
P-GW
Combined S-GW and P-GW

S4 interface S-GW
Combined S-GW and P-GW

S5  interface S-GW


(GTP-based)
P-GW
Combined S-GW and P-GW

S8  interface S-GW


(GTP-based)
P-GW
Combined S-GW and P-GW

S11 interface S-GW
Combined S-GW and P-GW

S2  interface P-GW


(GTP-based)
Combined S-GW and P-GW

Single addressing mode Gn interface GGSN

g
P-GW
Note:  This  mode  applies  to  both
Control  plane  and  User  plane Combined S-GW and P-GW
interfaces.
Gn-U interface P-GW
S-GW
Combined S-GW and P-GW

Gp interface GGSN
P-GW
Combined S-GW and P-GW

Gp-U interface P-GW
S-GW
Combined S-GW and P-GW

S1-U interface S-GW

38 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Software architecture

Table 2 Supported modes for Flexi NG basic gateway functionalities (Cont.)
Functionality Supported modes

Combined S-GW and P-GW

S11 interface S-GW
Combined S-GW and P-GW

S4-C interface S-GW
P-GW
Combined S-GW and P-GW

S4-U interface P-GW
S-GW
Combined S-GW and P-GW

S12 interface S-GW
Combined S-GW and P-GW

S5-C  interface P-GW


(GTP-based)
S-GW
Combined S-GW and P-GW

S5-U  interface P-GW


(GTP-based)
S-GW
Combined S-GW and P-GW

S8-C  interface P-GW


(GTP-based)
S-GW
Combined S-GW and P-GW

S8-U  interface P-GW


(GTP-based)
S-GW
Combined S-GW and P-GW

Single diameter Gx interface GGSN


P-GW
Combined S-GW and P-GW

Gy interface GGSN
P-GW
Combined S-GW and P-GW

S6b interface P-GW

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 39
   

Software architecture Flexi NG Architecture

Table 2 Supported modes for Flexi NG basic gateway functionalities (Cont.)
Functionality Supported modes

Combined S-GW and P-GW

Gxc interface S-GW
Combined S-GW and P-GW

Tunneling in SGi, SGi-mb and Gi interfaces GGSN
P-GW
Combined S-GW and P-GW

QoS GGSN
S-GW
P-GW
Combined S-GW and P-GW

Lawful interception GGSN
S-GW
P-GW
Combined S-GW and P-GW

Table 3 Supported modes for Flexi NG additional major functional areas
Functionality Supported modes
AAA GGSN
P-GW
Combined S-GW and P-GW

3GPP AAA P-GW
Combined S-GW and P-GW

Service awareness GGSN
P-GW
Combined S-GW and P-GW

Charging GGSN
S-GW
P-GW
Combined S-GW and P-GW

Policy control GGSN
S-GW (PMIP S5 interface)

40 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Software architecture

Table 3 Supported modes for Flexi NG additional major functional areas (Cont.)
Functionality Supported modes
P-GW
Combined S-GW and P-GW

Reporting GGSN
P-GW
Combined S-GW and P-GW

5.8.1  Basic gateway functionality

The basic gateway logic offers user equipment connectivity to the operator networks and
beyond. For the eMBMS functionality no user equipment signaling is required towards
Flexi NG.

Session management
Session management allows creating, maintaining, and deleting packet data network
(PDN) connections, MBMS sessions and EPS bearers/PDP contexts within PDN
connections. The session management is handled in the service blades.
In the service blades, the session data and related protocol state machines are located
in the control plane (Linux). Session handling is concentrated on a single component,
which allows managing complicated situations such as procedure collisions and quality
of service (differentiating bearers on congestion). Protocol decoding/encoding and
controlling the actual transmissions is handled by separate helper processes, which are
dedicated per protocol (Diameter, RADIUS, and so on). The session database also
exists in lighter form in the Fastpath, for example, for packet handling, charging, and
statistics. For eMBMS procedures, a seperate component concentrates session handling
that also takes care of procedures collision and QoS issues. eMBMS uses seperate
databases.
For further details on the procedures, see Session Management Reference Guide.

UE IP address allocation
The purpose of the IP address allocation is to define the IP address of a subscriber
terminal. Flexi NG supports static and dynamic end-user IP address allocation methods.
IP address allocation is an essential part of establishing connectivity. Selecting and
possibly acquiring the IP address from an external source is handled in service blades as
part of the session management procedures, and the routing advertisements are
handled centrally in the management blades by the centralized IP pool manager (CPM)
process.
IP address allocation is used in eMBMS to define the multicast IP address that is used
on M1 interface. Such IP address can only be allocated locally in a dynamic manner.
For more information on supported IP address allocation alternatives and their
configuration, see chapter IP address allocation in Flexi NG User Guide.

Load balancing

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 41
   

Software architecture Flexi NG Architecture

Load balancing for new user sessions has two basic alternatives. It can be handled on
the network level where Flexi NG is shown to the outside world as multiple network
elements, one per AS node. The load is then distributed to these nodes by
SGSN/MME/ePDG(s). This alternative operates in a node-specific addressing mode.
The other alternative is to make the load balancing decision internally in Flexi NG, which
makes it based on the distribution algorithm. This alternative operates in two modes:
load-balancing and single addressing.
The internal load balancing functionality monitors the state and load of each
GatewayService Recovery group, and directs the new sessions to the service blade
nodes taking into account their current load, favoring the less loaded nodes.
For additional information, see Load balancing chapter in User Guide.
An additional feature closely related to the load balancing is the Flexi NG internal service
group concept, with which the operator can link one or more recovery groups to an
access point. By defining a service group you can dedicate each recovery group for a
certain purpose, for example, to guarantee resources for corporate end-users.
Besides load balancing the user sessions, Flexi NG supports internal load balancing for
deep packet inspection (DPI). The SAB node selection is session-based, and the
selection is done from a list of available SAB nodes. Once an SAB node for a session is
selected, Flexi NG forwards all packets of that specific session needing DPI analysis to
the selected SAB node. If the selected SAB node goes down, the SAB node reselection
is done when the system handles end-user traffic which is to be forwarded to that SAB.
This behavior is fully automated and therefore not configurable by the operator.
For additional information, see Flexi NG Product Description and Flexi NG User Guide.

Tunneling in SGi and Gi interfaces
Using optional tunneling services provides a way to encapsulate packets of a different
protocol inside a transport protocol. This might be done, for example, to be able to
support overlapping IP addresses among corporate end-users.
Tunneling features in Flexi NG include:

• IP security architecture (IPsec)
• Generic Routing Encapsulation (GRE), version 0
• Layer 2 Tunneling Protocol (L2TP), version 2
• Virtual local area network (VLAN, 802.1Q)
• MPLS (For more information, see chapter Introduction to routing.)

IPsec provides a transparent, secure communication mechanism for implementing virtual
private networks (VPNs). In tunnel mode of IPsec, the entire IP packet (including header)
is secured. This option is used for securing IP traffic between two security gateways
located in two network elements.
The hardware-accelerated IPsec in the Fastpath (located in service blades) provides
multi-Gigabit throughput that is in most cases essential to the bearer network.

42 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Software architecture

Figure 21 IPsec tunneling in SGi and Gi interfaces

Access Corporate
network network
IPSectunnel
Userequipment FlexiNG VPNGW

There is also specific logic for VPN tunnel management to track the states of the VPN
tunnels for Flexi NG session control. VPN tunnel management signals either a tunnel up
state or a tunnel down state for the session control (SC), which then reacts accordingly.
A separate process runs on each service blade node for this purpose.
GRE is a tunneling protocol that can encapsulate a wide variety of protocol packet types
inside IP tunnels, creating a virtual point-to-point link to routers at remote points over an
IP network. GRE uses completely stateless tunnels, so that endpoints do not know the
state or availability of peer endpoints.
Layer 2 Tunneling Protocol (L2TP) is used as a tunneling protocol, enabling Point-to-
Point Protocol (PPP) high-level data link control (HDLC) frames to be encapsulated and
carried from the radio access network (RAN) to a packet data network, for example, a
corporate network. In an L2TP tunnel, an L2TP access concentrator (LAC) and an L2TP
network server (LNS) act as tunnel endpoints.

Figure 22 L2TP connection to PDN

L2TP tunnel PDN


RAN

LAC(NG) LNS

A tunnel between Flexi NG and LNS is established for each session profile, and a
separate L2TP session is established within the tunnel for every PDN connection.
The L2TP operation is divided between the control plane and user plane. A signaling
process runs on the control plane handling the tunneling setup and related operations,
while the Fastpath handles end-user packet forwarding to/from the tunnel.
VLAN tagging allows the operator to interconnect Flexi NG to the virtual LAN
infrastructure used on the site, allowing routing of traffic to the proper virtual LAN. VLANs
are available on all Flexi NG blade types.
For more information, see Gi/SGi Interface Description and MBMS Interfaces
Description.

QoS
The QoS for PDP contexts/EPS bearers can be used to implement prioritization in case
of congestion, to restrict the maximum bandwidth, and to guarantee a negotiated level of
performance.
The QoS features affecting the PDP contexts/EPS bearers are mainly available in
service blades, but also partially in interface blades and even service aware blades. The
QoS mechanisms in management blades is mainly for protecting the O&M connections,

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 43
   

Software architecture Flexi NG Architecture

not for prioritization as such. The features are implemented both by the hardware (for
example, packet queueing and scheduling) and software (for example, session control
and Fastpath).
The QoS of eMBMS allows prioritization between MBMS bearers at MBMS session
establishment, using the ARP. Additionally it supports packet dropping in the traffic flow
to adapt to the available r negotiated resources, using the GBR. The QCI can also be
used for DSCP marking of DL packets on M1 interface.
For more information, see QoS Concept Overview.

Lawful interception
The lawful interception extension (LIE) in Flexi NG is a part of the lawful interception (LI)
system that allows law enforcement agencies to intercept PDP context/EPS bearer data.
The LI implementation of Flexi NG is based on the Lawful Interception Gateway (LIG)
solution. Note that LIG contains both the lawful interception browser (LIB) and the lawful
interception controller (LIC).
The local LIE software modules in Flexi NG act according to LIG instructions, perform
the actual interception, and send the intercepted data to LIG.

Figure 23 LIE software modules
FlexiNG LIG
MB

Add,Removetargets
LICClient LIC
X1_1

Targets

SB Check IRI
SessionControl0 LIBClient
LIB1
Events X2,X3
CC
SessionControln
LIB10
Create,Update, Data
Delete
GWUP

The centralized control point in the management blade retrieves the interception types
and targets from LIC, stores to a local in-memory database (DB) and distributes the
interception information to distributed LIB clients.
The distributed interception points are located in all service blade nodes and provide the
transport solution for interception-related information (IRI) and content of communication
(CC) data towards the LIB. The event information is provided by the session control (SC)
processes and end-user data is provided by the Fastpath.

5.8.2  Additional major functional areas

Flexi NG contains also value-added services which enable operators to realize great
variety of different use cases and business models. Some of these major features are
shortly re-introduced in this chapter.

44 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Software architecture

AAA
The authentication, authorization, and accounting (AAA) functionality of Flexi NG is
based on the RADIUS protocol (3GPP, IETF). The main functions are:

• RADIUS authentication procedure
To authenticate the end-user, request for IP address allocation by AAA, and request
for other possible parameters hosted by the AAA.
• RADIUS accounting procedures
For PDP context/bearer tracking to inform the AAA server of the PDP context/bearer
start and end, and monitoring online cumulative usage of resources (time, volume).
• RADIUS disconnect procedure
To allow PDP context / bearer termination triggered by external control servers.

The RADIUS client process provides local service on each service blade node. Similar
architecture is used for other signaling protocols such as Diameter and DHCP.

Figure 24 RADIUS signaling

RADIUS signaling can be triggered by many different procedures, for example, PDP
context activation/modification/deactivation and periodic accounting.
For more information, see RADIUS Interface Description.
Note that Flexi NG also supports the AAA function related to Diameter-based S6b
interface, which is used in those cases where mobility between non-3GPP access and
3GPP is allowed.

Service awareness
Flexi NG service awareness gives the operator the ability to identify and control service
data flows based on traffic inspection, and to report and charge for the identified traffic.
Traffic can be identified using either layer 4 (L4) traffic analysis methods (shallow packet
inspection (SPI)) based on the IP 5-tuple, or layer 7 (L7) traffic analysis deep packet
inspection (DPI) methods. Flexi NG applies different gating, policing, or charging rules
either according to the local policy configuration in Flexi NG or controlled from the policy
control server (PCRF) through the Gx interface.

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 45
   

Software architecture Flexi NG Architecture

Figure 25 Logical division between SPI and DPI in Flexi NG

Charging
Flexi NG supports charging functionality with both offline (CDRs) and online (Diameter-
based Gy interface) methods. Flexi NG can meter the time a certain PDP context or EPS
bearer has been open, and the amount of data transferred. This requires tight
cooperation between the control plane in charge of creating the charging records and the
user plane measuring the transferred data and handling of quotas. The charging data
collection is fully implemented in the service blades.
In offline charging, the operator can select to store CDRs on the hard disk of Flexi NG
(located in management blades) or transfer the CDRs immediately out of the system
using the GTP’ (Gz/Ga) interface to charging gateways.
When combined with service awareness features, differentiated charging enables
separate charging for different applications, protocols, and destinations. This is achieved
by classifying traffic based on L4 (transport layer) and L7 (application layer) triggers and
metering the L4 and L7 flows based on volume, content, and time. Each flow can then be
charged differently.
Offline charging is also supported for MBMS bearers that can only measure time and/or
volume along with the access-nodes (MMEs) participating in the eMBMS service. Storing
MBMS related CDRs in the hard disk, is not supported.

46 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Software architecture

Figure 26 Charging in Flexi NG

Policy control
Policy control is a functionality which defines how user sessions are handled in Flexi NG.
The functionality in Flexi NG service blades to implement policy decisions is called the
policy and charging enforcement functionality (PCEF).
Flexi NG supports external servers to allocate subscriber-specific policies for the end-
user, and local predefined policy decision logic where policies are applied based on the
configuration related to the session profile.
After the analysis of the user packet and the applicable rules, different actions can be
performed:

• PCEF actions (for example, QoS enforcement, gate enforcement, flow based
charging)
• Basic DPI functionality (such as analysis and reporting)
• Other implementation-specific DPI actions (for example, redirection, HTTP header
enrichment, access point switching)
• Dedicated bearer activation/modification/deletion

Single diameter
In order Single diameter to be functional Interface Blades' presence is mandatory.
Diameter protocol based applications used on policy control, online charging and AAA
can operate with single diameter functionality.
Without single diameter feature the functionality is hosted only on SB as it is already
described in sections Charging and Policy control.

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 47
   

Software architecture Flexi NG Architecture

With single diameter feature the diameter functionality is hosted on both SBs and IBs.
IBs hold and maintain the external diameter connection and are responsible for Diameter
Base protocol.
As shown on figure Packet traversing among IB and SB diameter application messages
are generated on SBs like in non-single environment and forwarded internally to the
proper IB that maintains the connection with a set of diameter servers. The IB transmits
the messages over its diameter connection and on the ingress direction IB receives the
diameter messages and forwards them internally to the proper SB. This is a simplified
flow example. For details on how the diameter connections are spread to the IBs, how
the SBs select the IBs to be used and the resiliency schemes are described in High
Availability Solutions Reference Guide.

Figure 27 Packet traversing among IB and SB

Reporting
Flexi NG is able to provide subscriber-specific reports as well as reports on network
usage to external servers.
The supported interfaces are real-time reports towards Traffica and periodic reports
towards external FTP servers.
The aim of these reports is to provide the operator with insight and analysis on the
network behavior and on specific end-users, obtain statistical data and trends on network
usage and finally to allow the operator to supervise network utilization and improve
customer satisfaction.
Because both reporting mechanisms can contain sensitive end-user information, they
are both license-controlled.
For more information, see documents Traffica Interface Description and DPI Interface
Description.

48 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Operation and maintenance architecture

6  Operation and maintenance architecture

6.1  Operation and maintenance overview

Operation and maintenance (O&M) refers to all the system functions with which the
operator controls the behavior of the system and receives data about the operation of the
system.
Flexi NG is supported by NetAct for configuration management, fault management,
performance management, user management and element monitoring purposes.The
NE3S/WS interface provides fault management, performance management, user
management, and audit-trail logging. Configuration management is supported by NetAct
through the command manager. Flexi NG can also be integrated with other network
management systems which support the standard SNMP interface. A limited set of
management information bases (MIB) are supported by Flexi NG for statistics and other
kinds of management information such as alarm notifications (traps). Nokia proprietary
MIBs are supported for alarm notifications (traps).

Figure 28 Operation and maintenance interfaces

NetAct

Fault Performance Configuration Servicequalitymonitoring


management management management Reportingsuites

NE3S/WS

SCLIforconfiguration
management,
maintenanceand
SSH FlexiNG
runtimeoperations

O&M consist of many areas including:

• Commissioning and integration
• Hardware and software management
• Software management, including backup and restore
• Configuration data management
• User management
• Fault management
• Performance management
• General maintenance and troubleshooting
• Subscriber-specific troubleshooting

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 49
   

Operation and maintenance architecture Flexi NG Architecture

• Backup and restore

6.2  Secure shell connections

Flexi NG runs two separate SSH servers. The external SSH server is available for
connections originated externally to the gateway. It runs on the active management
blade. The internal SSH server running on each node, as well as on the standby
management blade. These SSH servers are only reachable from the internal subnet. The
internal SSH servers are the main means to create shell sessions on a node. The shell
sessions may originate from any node in the network element. Typically, they originate
from a session created using the external SSH server.

Figure 29 External and Internal usage of SSH from generic shells such as bash

Both internal and external SSH servers allow the usage of SFTP and SCP. By default,
the external SSH server has stricter security-related settings. It does not allow remote
access with the root account. Users must first log in with a user-specific account and
then, if it is required, to log in with the root account.

6.3  User management

Flexi NG offers a set of SCLI commands with which operators can create, modify, and
delete user and group accounts as well as mappings between users, groups and
permissions.
With the exception of Linux system accounts and fallback accounts that are stored in the
operating system, all interactive accounts (for humans) and service accounts (for
process-to-process communication) meant for managing Flexi NG are stored in the
system’s internal configuration directory server. So, they are equally available for all
nodes and for all connection types. Fallback accounts are used to login to the system
when internal configuration directory server is not accessible.

50 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Operation and maintenance architecture

Flexi NG follows the Linux user-private-group principle. Each interactive account has a
group account set as its primary group account by default, for which the textual and
numeric ID are the same as the interactive account.

Figure 30 Relations between users, groups and permissions

The users are authenticated and their operations authorized as well as logged. Generally
the management interface adapters (SCLI, NE3S) perform these operations. Once the
input request has been validated, it is handed over to the respective internal
management service (such as the alarm system), which implements the actual logic
(such as compiling a list of currently active alarms). The result obtained from the service
is then returned to the user through the management interface adapter.
As the current set of SCLI commands does not cover all management or troubleshooting
cases with only the SCLI shell, escaping to the generic bash shell as root is still needed
in some specific cases. Apart from these special cases, both the root access and the full
bash shell usage are discouraged. The full bash shell offers neither any authorization
(save file permissions) nor accountability (audit trails).
Flexi NG provides a changed root (chroot) environment with a limited bash shell to be
used for daily system monitoring and maintenance tasks. The chroot environment
provides increased security, because the root file system is hidden and only certain
directories needed in normal operations are exposed.
When accessing files using the SCLI framework, the implementation ensures that the
Linux kernel correctly applies file permissions when accessing the files. The SCLI
functions also correctly apply a chroot environment for these files. This assures that
operators see only a very limited set of files, and not all the details of the full set of
binaries, internal storage places and pseudo-filesystems internal to the network element.
Proper usage of the available role-based access control mechanisms contribute to the
security of the system, provide the capability to track the changes in the configuration
and the responsible user, and prevents costly operational errors caused by mistakes
performed by users with high access levels. In case root rights are used, there is a
danger of system damage which can only be repaired by restoring it with a recent
backup.

Remote user information management
Remote user information management (RUIM) is a concept specified and provided by
NetAct so that permissions for management access to multiple network elements can be
centrally managed within NetAct. Network elements are expected to use a centralized
(external) NetAct Directory server located within the network management system (NMS)
domain.
Flexi NG RUIM functionality allows the utilization of user information, which is stored
remotely in a centralized user management system (in NetAct), for user authentication
and authorization on all external management interfaces. Using RUIM requires certain
conventions, so that interactive accounts locally stored within the network element do not
overlap with interactive accounts stored in the centralized RUIM LDAP server.

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 51
   

Operation and maintenance architecture Flexi NG Architecture

6.4  Operation and maintenance features
Commissioning
Commissioning tasks consist of the complete installation of the physical hardware,
installation of the software to the network element, and configuration of the network
element in order to make it, together with other equipment, fully operational in the
network.
In the field, commissioning can be carried out by a network operator or Nokia, depending
on the agreement. It includes, operational tests and configuring of the transmission
equipment.
Commissioning includes all tasks that are necessary to set up a physical cluster with the
desired software delivery and desired configuration and start the services up so that the
desired services of the cluster are available for use or verification. The commissioning of
a network element is successfully completed when all services provided by all the nodes
are available.
Commissioning utilizes an external Field Engineering Workstation (FEWS) and a Linux
workstation into which the software delivery is first installed. FEWS is used for
establishing the physical connection to the target system subject to commissioning.

Configuration data management
Configuration data does not contain transient state information. Configuration data is
typically read by applications when they start up, or when they get an announcement
about a modification to the configuration data.
Configuration data is typically generated at the commissioning phase of the cluster.
Generation is made from source files that belong to the software delivery, representing
the desired configuration of the network element. Afterwards, only the operator can
initiate the modification of configuration data.
A special area of configuration data is the deployment configuration data that essentially
describes the cluster structure in terms of physical hardware and its interconnections, as
well as in terms of managed objects understood by High Availability Services.
The configuration services in Flexi NG rely on the use of a centralized configuration data
repository, implemented in a specialized intra-cluster LDAP server called Configuration
Directory Server, accessed by different applications in the system via LDAPv3 protocol.
Flexi NG uses a profile-object-based linked configuration model for most application
logic. This means many general entities such as Diameter server profiles, PCC rules,
and IP pools are provided in such a way that these objects group together many relevant
parameters, and can be then pointed to from another configuration objects. The relations
can be N:M, so a profile can refer to multiple other profile objects, while at the same time
be referred to from multiple other profile objects. This concept simplifies the configuration
management, as it allows easy re-use of the configuration objects instead of configuring
each attribute multiple times for different use cases.

52 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Operation and maintenance architecture

Figure 31 Example on linked configuration profiles

For a larger illustration of the relations between different configuration objects, see
Appendix Configuration structure and interdependencies in Flexi NG User Guide.
The user interface used for inputting configuration data to the system is the SCLI.
Configuration management with SCLI is done by most FlexiPlatform scli
command hierarchies, like networking and routing. The SCLI hierarchy used for
Flexi NG application configuration is the ng which forms add, set, unset, delete,
show, list comnands for all the NG specific configuration objects like session-
profiles, ip-pools, access-points and so on.
A configuration framework is in place to allow easy development of the NG configuration
commands, in a way that all new commands and configuration objects that are added
under ng hierarchy are following a pattern of how they are handled by the application.
The SCLI provides many features that assist in the configuration management.
• Snapshot management provides to the user the capability to save snapshots of the
running configuration and restore back a saved confsuration snapshot in a later
phase.
• Configuration lock prevents parallel configuration actions when a user is making
many changes in the configuration.
• Configuration transactions provide the capability to bundle more that one
configuration commands together and form a single configuration plan, which is
handled seperately. This plan is treated as a single transaction, it is validated as a
whole and all the commands are either accepted or not collectivelly. The usage of
configuration transactions result in having large configuration plans validated and
taken in use faster by the system.

Flexi NG supports configuration of many parameters during runtim without causing
downtime. In most cases the configuration changes are eventually applied to all sessions
(including existing sessions that were created before the configuration change), since
otherwise it is difficult to know the active configuration for example during
troubleshooting. For more information on the runtime configurability, refer to
documentation for the parameter in question in the Flexi NG User Guide.

Software management
Software management provides the means to control which software is installed and run
in Flexi NG. It provides the means to install/uninstall, upgrade/downgrade, and
activate/deactivate the installed software.
A software delivery refers to a software build, meaning a collection of software that can
be installed and activated in the target system. A delivery contains a complete software
build. As the software management is based on utilization of disk images, a delivery
refers to a complete disk image of a system disk, containing all software subsystems that
belong to the same software build, installed in the target system.

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 53
   

Operation and maintenance architecture Flexi NG Architecture

In a typical software upgrade, a complete software base delivery is first installed to the
target system and then activated there with a separate command (or set of commands)
in the desired nodes in the desired order.
Flexi NG supports optional Deep Packet Inspection (DPI) bundle updates as a
standalone software delivery. The DPI bundle updates the protocol detection capabilities
in Flexi NG. Up to three DPI bundles cab be installed and activated. DPI bundles are
delivered on top of regular software deliveries.
Firmware, or embedded software (eSW), as a term refers to the software that is
embedded to the hardware device. The vendors of the hardware components, such as
CPU boards or Ethernet switches, provide factory default firmware versions (for
example, BIOS in x86 boards) on the flash memory of the hardware boards.

SCLI
The Structured Command-Line Interface (SCLI) is an interactive shell that provides
formally defined and structured commands with context-sensitive help and auto-
completion of commands. The SCLI can be also used in non-interactive mode.
The SCLI framework includes a SCLI daemon process located in a centralized node
(management blade) in a cluster. The daemon process will spawn child proxy processes
for actual execution of commands. As a command editing and execution interface, the
framework provides an interactive fsclish shell. The commands are available in a
controlled structured way in this shell.

Fault management, performance management and logging
The basic architecture used for these services is based on the separation of tasks in two
categories:

• Distributed components running on every node, which locally collect the node’s input
data, and forward the data to the centralized server located in a management blade.
• Centralized server located in a management blade, which aggregates the data
coming in from all nodes, and presents the data in the format suitable for each
standard interface.

The external interfaces are available from the management blades, providing full access
to aggregated alarms, statistics and logs without having to take into account the actual
composition of the system or the currently active feature set.

General maintenance and troubleshooting
Maintenance refers to the combination of all technical and corresponding administrative
actions, including supervision actions, intended to maintain or restore an item at a state
in which it can perform its required function. Troubleshooting refers to identifying and
correcting problem situations in hardware and software.
The main method for notifying about the problems is raising alarms. Additionally, Flexi
NG supports basic system logs with configurable log levels which include important
information. Error logs are produced for software problems and are enabled by default.
More detailed information can be acquired by configuring lower level logs, but these are
in most cases very detailed and will have significant performance impact. Because of
this, operator logs concept has been introduced. These logs are meant for operating
personnel as an indication of specific problems and as the usage is strictly defined and
controlled, they are all enabled by default.

54 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Operation and maintenance architecture

Subscriber-specific troubleshooting
Flexi NG provides several ways to collect information for troubleshooting related to a
particular subscriber.
The subscriber trace can be used to create logs and traffic capture files related to
specific subscribers based on their international mobile subscriber identity (IMSI).The
subscriber trace can be activated with configuration and then the trace activation is
automatically distributed to each service blade in the system. The subscriber trace can
be alternatively activated for active subscriber based on the received GTP message and
then the trace activation is done in the service blade serving the subscriber. The
collected data is aggregated in the management blade. The signaling and user plane
packets are stored in standard pcap format, which enables analysis with standard tools
such as Wireshark.
Flexi NG also supports display of information about active PDP contexts or EPS bearers
based on the IMSI, MSISDN, or UE IP address. This service also hides the internal
structure of the system from the operator, as the centralized service enquires the
information from all present service blades and aggregates the information to be able to
produce a summary view.
It is also possible to use real-time reporting in connection with the Serve atOnce Traffica.
Flexi NG provides subscriber-specific application-related as well as session bearer
information to Traffica. Traffica then analyzes the information and creates various
graphs, in realtime.

Backup and restore
Backup and restore provides the means to take backups of the desired storage
resources of the network element, and to restore such a backup later. This functionality
also provides a unified interface (command-line interface tools) and a generic instruction
template for backup and restore operations.
Backups are taken by default on a local storage device; moving them safely and securely
to an external storage solution has to be separately managed by the operator.
The operator can produce either a full backup or a partial backup of the target system.
A full backup contains a copy of software volumes (system image), configuration
volumes, the master state volume, application file systems, plug-ins and databases. A
full backup enables restoration of the system from scratch, for example, after a
catastrophic disk failure that has destroyed all content from system disks. A partial
backup can contain one or more of the previously listed items as chosen by the operator.
A restore operation can be partial or full, depending on the type of the backup archive.
A partial restore can be used to restore for example configuration data if all the stored
snapshots are faulty but Flexi NG is otherwise operational. Partial restore is done in the
run-time environment and can be performed either from a partial backup image or from a
full backup image. A full restore operation requires re-commissioning the system with a
full backup image. It is required when the system cannot be repaired by using a partial
backup or when the system is not accessible at all. A broken system image might also
cause the network element to go into a reboot loop. This may be because of a logical
disk crash, a corrupted file system or the accidental removal of files or directories on the
system image.

In Service Upgrade

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 55
   

Operation and maintenance architecture Flexi NG Architecture

In Service Upgrade (ISUG) introduces the implementation of a new generic internal
interface protocol library, which will accommodate for backward and forward compatibility
of inter-node messages between arbitrary software releases. This is achieved by
applying a Type-Length-Value (TLV) encoding and decoding to this type of messages
and by implementing the business logic for automatic message adaptation to the target
protocol version.

56 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Networking architecture

7  Networking architecture

7.1  Routing
7.1.1  Introduction to routing
The Flexi NG EdgeRouting solution provides support for static routing, dynamic routing
(OSPFv2, OSPFv3, BGP-4), Protocol Independent Multicast (PIM) protocol, and Multi-
Protocol Label Switching (MPLS). The EdgeRouting consists of a set of processes
running the routing control plane protocols and programming the forwarding data plane.
For MPLS, the EdgeRouting daemon supports both static Label-Switched Paths (LSPs)
and Label Distribution Protocol (LDP). Multiprotocol Border Gateway Protocol (MP-BGP)
together with MPLS provides possibility to establish MPLS L3VPNs to provide customer
separation into isolated VRFs.
For more information, see chapter Routing protocols in Flexi NG User Guide.
Virtual routing
With virtual routing instances the operator can separate routing information between
different logical networks. The EdgeRouting solution supports virtual routing instances
for all routing control plane protocols. Additionally, BGP-4 includes VPN support,
meaning that a single BGP-4 instance can be attached simultaneously to multiple virtual
routing instances.
The EdgeRouting solution supports virtual routing instances for all routing control plane
protocols. Additionally, BGP-4 includes VPN support, meaning that a single BGP-4
instance can be attached simultaneously to multiple virtual routing instances.

g Note:  MPLS and LDP can be enabled only to a single virtual routing instance at a time.

Each virtual routing instance has its own set of routing and forwarding tables. So a virtual
routing instance is a routing domain that has control over a number of logical interfaces.
Each logical interface belongs to one (and only one) virtual routing instance. The routing
instances can have overlapping IP address ranges. It is possible to configure the normal
routing policy (route protocol rank, aggregation, and re-distribution) for each virtual
routing instance.

MPLS and MPLS L3VPNs
MPLS LSP information can be exchanged dynamically between neighbors by LDP. The
OSPF routing protocol must be used together with LDP. The OSPF protocol exchanges
the routing information, and LDP exchanges Forwarding Equivalency Class (FEC)
information, which relates to the routing information exchanged by the OSPF but
includes label information. The label must be programmed to the MPLS dataplane to
reach the destination route over the MPLS network.
MPLS L3VPN information is exchanged via BGP-4 routing protocol. OSPF and LDP
protocols are used to provide MPLS LSP connectivity as described earlier. BGP is used
to exchange the routing information between the corresponding Virtual Private Network
(VPN), where a correct VPN VRF is chosen by the use of Route Distinguishers and
Route Targets. Route Distinguishers (RD) are used to make VPN route unique and

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 57
   

Networking architecture Flexi NG Architecture

Route Targets (RT) define their VPN membership. Essentially the VPN route information
exchanged by the BGP includes a L3VPN label and next-hop information. Next-hop
information is resolved to an existing MPLS LSP; this LSP is used as the transport LSP
over the MPLS network for the L3VPN LSP. L3VPN labels are used to identify in which
VRF the forwarded MPLS packets belong.
The LSP functionality provides the operator a capability to configure static MPLS LSPs.
The operator may use static LSPs as backup paths in case of dynamic routing failures.

g Note:  MPLS and BGP are only available when Flexi NG is deployed with interface
blades.

Equal-cost multi-path routes
If there are several equal-cost paths towards the destination (meaning the cost for the
routes is the same), it is possible to configure static or dynamic routing to use those
several paths to share the traffic load. This is called equal-cost multi-path (ECMP).
ECMP can be done on per-address basis.
Equal-cost multi-path routes on per-address basis are supported with IPv4 and IPv6
static routes, OSPFv2, OSPFv3, BGP-4 and MPLS (LDP).
Flexi NG supports maximum of 32 paths for each ECMP route. For more information on
setting the maximum number of ECMP paths, see chapter Setting maximum number of
equal-cost paths in Flexi NG User Guide.

Graceful restart and non-stop forwarding
The EdgeRouting daemon supports Graceful restart procedures for all site connectivity
mechanisms, including OSPFv2, OSPFv3, BGP-4, and LDP protocols as well as static
routes, static LSPs, and MPLS L3VPNs.
Graceful restart consists of a restart of all or part of the routing control plane while the
data plane continues forwarding data (non-stop forwarding). After restarting the routing
control plane relearns network state and synchronizes with the data plane while traffic
continues to flow uninterrupted. In the event of a system configuration or network
topology change during the restart, some traffic disruption may occur.
OSPFv2 and OSPFv3 protocols support both a planned and unplanned Graceful restart,
as well as the Helper node functionality. Planned restart is a user-initiated event, and an
unplanned restart can be either user-initiated or initiated during a hardware or software
failure. Helper node functionality is always enabled for OSPFv2 and OSPFv3 protocols
allowing EdgeRouting daemon to work as a supporting node for another router(s) to
undergo Graceful restart.
Graceful restart must be enabled for BGP-4 and LDP protocols at both neighbors of an
established adjacency to support the functionality.

Multicast routing
For multicast routes, the Protocol Independent Multicast (PIM) is supported to allow
dynamic learning of multicast registrations in the network and to set up the interface
blade specific multicast forwarding accordingly.
Currently, in Flexi NG the only supported mode of PIM is the PIM-SSM (Source Specific
Multicast), which is a subset of the PIM-SM (Sparse Mode).

58 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Networking architecture

In order to communicate SSM route information between PIM-enabled routers, it is
necessary that the route to the source address S is known and the S is a regular unicast
address. A unicast routing configuration to the PIM-enabled routers must be created.
Typically the OSPF is used to communicate the unicast routes.
In Flexi NG, only IPv4 multicast routing is supported.

7.1.2  Distribution architecture with centralized routing

The EdgeRouting solution is based on a centralized routing control plane. For the routing
control plane this means that the centralized routing protocol services are running in the
management blades (using active-standby redundancy configuration). IP packet
forwarding stacks still run as standalone instances per node.
The distribution is implemented with the help of distribution agents. These agents are
used to provide interface information, routing table updates, socket layer connectivity,
neighbor communication management and program the MPLS data plane. The active
management blade runs the distribution agents for controlling local interfaces and
connectivity. The other blades (SBs, IBs, SABs) run only the distribution agents.

Figure 32 Distribution architecture with centralized routing
MB1

Centralized Centralized
components components

IB7
Distributed
components Distributed
components

Mgmt
network
MB2
Distributed S1-U
Centralized components network
components

Distributed
components IB10

Distributed SGi
components network

SB/SAB

Distributed
Distributed
components
components

Distributed
components

EdgeRouting daemon core functionality
The core part of the EdgeRouting daemon provides mechanisms for scheduling protocol
computation, memory management, route storage, and configuration support.
The routing table is built from running routing protocols and local connectivity
information.
Events handled by the EdgeRouting daemon can be summarized as:

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 59
   

Networking architecture Flexi NG Architecture

• Receive and send protocol messages
• Protocol functionality processing
• Receive interface state changes and take corresponding protocol actions
• Trigger timers and generate resulting actions
• Respond to the received signals, including automatic EdgeRouting daemon
reconfiguration based on changes in the system configuration
• Add/delete routes to/from the kernel forwarding table
• MPLS dataplane configuration
• Add/delete Multicast Forwarding Cache (MFC) entries

The route storage mechanism in the EdgeRouting daemon routing modules provides a
central repository for different protocol instances (OSPFv2, OSPFv3, BGP-4, LDP, PIM)
to maintain routing information in memory.
The EdgeRouting daemon keeps a single view of the cluster-wide Routing Information
Base (RIB), which is distributed to each node by the help of distributed agents.

7.1.3  Service blade and interface blade connectivity options

Flexi NG offers possibility to connect the external interfaces to the site routers either
directly to the service blades or to the interface blades. With the EdgeRouting solution,
these alternatives have very distinct differences.
For more information on routing, see chapter Routing in Flexi NG User Guide and the
Site Connectivity Guidelines document.

Interface blade connectivity
The interface blade connectivity solution uses a concept called global VRF. This solution
uses a single routing instance (with its own router-ID) per VRF for the whole system, and
the network element can be advertised to the external network with a single router ID.
This means that the outside world sees a network element as a single router, reducing
greatly the number of neighbors visible to the site routers.
The global VRF name alone identifies a routing instance.
In this solution, the user data packets arriving to Flexi NG from site routers always pass
through an interface blade node, which then automatically forwards the packets internally
to the correct target AS node using proprietary L2 forwarding. The forwarding decision is
made according to the IP addresses tied to the services located in the other blades. The
interface blade connectivity supports both load-balancing and single addressing modes
of operation.
The interface blade connectivity solution is the preferred deployment for Flexi NG. This
approach results to the following:

• Reduced cabling and port usage in site routers
• Less load to site routers due to decreased routing topology
• BGP, MPLS and single loopback solutions are only supported with interface blades
• In 2N high availability, service blade switchovers are not visible to the site routers
• Adding and removing service blades or service aware blades is not visible to site
connectivity configuration

Service blade connectivity

60 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Networking architecture

The service blade connectivity solution uses a concept called Node Specific VRF (NSV),
which is very similar to the legacy approach used before EdgeRouting. In this solution,
the VRF configuration object itself is global to the whole system (using the same name
and the same numeric ID), while having an individual routing instance (with its own
router-ID) for each node.
In this solution, the data packets arriving to Flexi NG from the site routers always go
directly to the correct node, without any need for internal forwarding.
Configuring NSVs can result in a large number of individual routing instances. This can
lead to scalability issues in large configurations, and thus a limit of 1500 individual
routing instances and 600 VRF IDs in the system is enforced.
The service group (SG) approach can be used to limit certain VRFs to particular nodes.
The SGs are used mostly for private corporate networks, which usually are the main
cause for large amounts of VRFs. With a service group, one or more recovery groups
can be linked to an access point. An incoming request, which has an associated service
group, is only served by those indicated recovery group(s).

Distinct differences between the connectivity options
Because of the internal forwarding mechanisms with global VRFs, the load balancing
configuration is different. An additional non-routable dummy interface is used in each
node for internal traffic flow management, even though the actual routable address
appears in the management blade.
The service blade connectivity option does not support global VRFs for anything except
O&M traffic. This is because it is important to be able to receive incoming packets
directly to the external interfaces of correct node to have consistent forwarding capacity.
Packet forwarding between SBs is always disabled. Note also that the default (O&M)
VRF is always a global VRF.
BGP and MPLS are  only supported with the interface blade connectivity option.

7.1.4  Advertising UE IP addresses

The IP addresses for the UEs can be allocated by several different methods as
explained in chapter Basic gateway functionality. These IP addresses can be exported to
the routing system if the IP pool they belong to allows dynamic advertisement (for OSPF
or BGP). Otherwise, static routing has to be configured. An exception to this are the
MPLS L3 VPNs, where the advertisement is automatically enabled when the VRF
configured in the IP pool has been linked to MPLS L3 VPN.
For host-based routing and for IP pools with shared-subnets, the individual routes (host
routes or fragments of the shared subnet) are injected during runtime to the routing
system, which advertises them to the peer routers. This same mechanism is available for
service blade and interface blade connectivity options. With interface blades, the
forwarding tables of the IB nodes are configured to forwarding packets to the right target
AS node based on the global VRF routing table.With service blade connectivity, the
routing advertisement is done directly by the corresponding service blade nodes.

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 61
   

Networking architecture Flexi NG Architecture

7.2  Site connectivity

Flexi NG connects to the operator network through external interfaces located in different
blades. In most cases, the O&M connections are established directly from the
management blades, while the 3GPP interfaces for signaling and user data are either
through service blades or interface blades.
This chapter introduces the overall concepts related to the aforementioned connectivity
options. The concepts are described at a high level and are applicable for both the N+
and 2N service blade high availability options. Presence of SABs or CBs are not
separately discussed, as they do not have major impact on the site connectivity.

Interface blades
When the external connections are aggregated using the interface blades, the amount of
cabling for a fully equipped shelf can be limited to only what is required for the system
throughput. For example, there is no need to provide full capacity resiliency for all
service blades. This helps to significantly reduce the number of ports required at the site
routers.
Flexi NG is usually connected to the site routers by using VLANs and OSPF routing. The
figure below illustrates this solution showing a couple of service blades and interface
blades.

Figure 33 VLANs on OSPF routing with interface blades

FlexiNG

S1-URouter1 20 IB7 SB6


0
IB7-0 AS6-0
20

SGiVRF S1-UVRF
2

S1-Ulb Gateway
201
logic
0 S1-UVRF SGiVRF
S1-URouter2 30 SGilb
20
3

302 IB7-1 AS6-1


SGiVRF S1-UVRF
1

S1-Ulb
30

Gateway
SGiRouter1 3 logic
30 S1-UVRF SGiVRF
SGilb

lb=loopback

SGiRouter2
-OneVRFspansoverallnodes
-SamerouterIDvisiblefromwholeNGperVRF
-ForwardingoverBackplane
EachinterfaceneedsauniqueVLANperVRF

When interface bladesare used, the BGP and MPLS options can also be used for
connectivity. For more information, see documents Site Connectivity Guidelines and Site
Connectivity Guidelines for BGP and MPLS Solutions.

62 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Networking architecture

7.3  Network connectivity monitoring

The keepalive mechanisms embedded into the dynamic routing protocols are usually
used for monitoring connections to the surrounding network. It is possible to use
Bidirectional Forwarding Detection (BFD) to supplement the basic keepalives to
decrease fault detection times, and to allow efficient use of resources on Flexi NG and
on the adjacent routers. It is also possible to link the connection monitoring to the Flexi
NG high availability framework by using the Link State Detector (LSD) feature. With this
feature, loss of connectivity can be used to trigger blade/node switchovers. The LSD is
useful for the management blades and in deployments without interface blades also for
service blades and service aware blades.

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 63
   

Glossary Flexi NG Architecture

8  Glossary
Table 4 Terms and definitions
Term Definition
3GPP 3rd Generation Partnership Project
ARP Address Resolution Protocol
ATCA Advanced Telecommunications Computing Architecture
BGP Border Gateway Protocol
CC Content of Communication
CDR Charging Data Record
CPM Centralized IP pool manager
DNS Domain Name System
DPI Deep Packet Inspection
DRBD Distributed Replicated Block Device
EDGE Enhanced Data Rates for Global Evolution
ePDG Evolved Packet Data Gateway
EPS Evolved Packet System
eSW Embedded Software (firmware)
FEC Forwarding Equivalency Class
FEWS Field Engineering Workstation
FIB Forwarding information base
GERAN GSM/EDGE Radio Access Network
GGSN Gateway GPRS Support Node
GPRS General Packet Radio Service
GRE Generic Routing Encapsulation
GSM Global System for Mobile Communications
GWUP Gateway User Plane
IMSI International Mobile Subscriber Identity
IB Interface Blade

IP Internet Protocol
IPsec Internet Protocol security
IRI Interception-Related Information
LDAP Lightweight Directory Access Protocol
LDP Label Distribution Protocol
LIB Lawful Interception Browser
LIC Lawful Interception Controller
LIE Lawful Interception Extension

64 © 2019 Nokia. Nokia confidential. DN09130502 Issue: 5-0
   

Flexi NG Architecture Glossary

Table 4 Terms and definitions (Cont.)
Term Definition
LIG Lawful Interception Gateway
LIPv2 Lawful Interception Protocol, version 2
LSP Label-Switched Path
LTE Long-Term Evolution
MIB Management Information Base
MPLS Multi-Protocol Label Switching
ND Neighbor Discovery
NG Network Gateway
NFS Network File System
OSPF Open Shortest Path First
PAM Pluggable Authentication Module
PCC Policy and Charging Control
PDN Packet Data Network
P-GW PDN Gateway
QoS Quality of Service
RADIUS Remote Authentication Dial-in User Service
RG Recovery Group
RU Recovery Unit
RUIM Remote User Information Management
SAB ServiceAwareBlade
SAE System Architecture Evolution
SB ServiceBlade
SC Session Control
SCLI Structured Command-line Interface
SFTP Secure File Transfer Protocol
SGSN Serving GPRS Support Node
S-GW Serving Gateway
SPI Shallow Packet Inspection
TCP Transmission Control Protocol
UDP User Datagram Protocol
UE User Equipment
UMTS Universal Mobile Telecommunications System
UTRAN UMTS Terrestrial Radio Access Network
VLAN Virtual Local Area Network
VPN Virtual Private Network
VRF Virtual Routing and Forwarding

DN09130502 Issue: 5-0 © 2019 Nokia. Nokia confidential. 65