292616319 Liquid Applications System Description PDF

8/19/2019 292616319 Liquid Applications System Description PDF

1/40

Liquid Applications System Description

Issue 01

Nokia Siemens Networks 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 compo-

nents.

If you should have questions regarding our Environmental Policy or any of the environmental

services we offer, please contact us at Nokia Siemens Networks for any additional information.


2/40

2

Issue 01


Id:0900d80580a3e47a

The information in this document is subject to change without notice and describes only the

product defined in the introduction of this documentation. This documentation is intended for the

use of Nokia Siemens Networks customers only for the purposes of the agreement under whichthe document is submitted, and no part of it may be used, reproduced, modified or transmitted

in any form or means without the prior written permission of Nokia Siemens Networks. The

documentation has been prepared to be used by professional and properly trained personnel,

and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes

customer comments as part of the process of continuous development and improvement of the

documentation.

The information or statements given in this documentation concerning the suitability, capacity,

or performance of the mentioned hardware or software products are given "as is" and all liability

arising in connection with such hardware or software products shall be defined conclusively and

finally in a separate agreement between Nokia Siemens Networks and the customer. However,

Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions

contained in the document are adequate and free of material errors and omissions. Nokia

Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which

may not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO

EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-

TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-

RECT, 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.

This documentation and the product it describes are considered protected by copyrights and

other intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark

of Nokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respectiveowners, and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2013/11/7. All rights reserved

f Important Notice on Product SafetyThis 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.

The same text in German:

f Wichtiger Hinweis zur ProduktsicherheitVon diesem Produkt können Gefahren durch Laser, Elektrizität, Hitzeentwicklung oder

andere Gefahrenquellen ausgehen.

Installation, Betrieb, Wartung und sonstige Handhabung des Produktes darf nur durch

geschultes und qualifiziertes Personal unter Beachtung der anwendbaren Sicherheits-

anforderungen erfolgen.

Die Sicherheitsanforderungen finden Sie unter „Sicherheitshinweise“ im Teil „Legal,

Safety and Environmental Information“ dieses Dokuments oder dieses Dokumentations-

satzes.


3/40

Issue 01

3


Id:0900d80580a3e47a

Table of ContentsThis document has 40 pages.

1 Introduction to Liquid Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1 Mobile edge computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Benefits of proximity and context. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3 Monetization opportunities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 RACS deployment scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Release principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Radio Applications Cloud Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Product concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1 Telecom and IT domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 High-level architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3 RACS hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4 Site configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.5 Cabling options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.6 Software provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.7 Network integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.7.1 Transport network integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.7.2 LTE U-plane integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.7.3 LTE C-plane integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.8 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.8.1 Server security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.8.2 Sever O&M security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.8.3 Application framework O&M security. . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.8.4 Backhaul security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.8.5 Application security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.9 Capacity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 RACS-C and RACS-T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1.1 RACS-C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1.2 RACS-T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1.3 Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5 Operation, administration, and maintenance . . . . . . . . . . . . . . . . . . . . . 30

5.1 NetAct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2 Application Framework Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 Embedded applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.1 Content Optimization and Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.1.1 Content Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.1.2 DNS Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.1.3 Video Prioritization and Pacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.2 TCP Header Enrichment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35


4/40

4

Issue 01


Id:0900d80580a3e47a

7 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

8 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38


5/40

Issue 01

5


Id:0900d80580a3e47a

List of FiguresFigure 1 LA system and product structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Figure 2 RACS deployment scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Figure 3 Release principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Figure 4 RACS, RACS-C, and RACS-T Applications vs. Remote Applications. . 12

Figure 5 RACS - product concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Figure 6 Telecom and IT domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Figure 7 RACS with Traffic Offload Function (TOF). . . . . . . . . . . . . . . . . . . . . . . 15

Figure 8 LA10 RACS high level architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Figure 9 FBSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Figure 10 Flexi Multiradio 10 BTS site configuration . . . . . . . . . . . . . . . . . . . . . . . 17

Figure 11 Flexi Multiradio BTS site configuration. . . . . . . . . . . . . . . . . . . . . . . . . . 18

Figure 12 Cabling options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Figure 13 FBSA connectivity with Flexi Multiradio BTS . . . . . . . . . . . . . . . . . . . . . 19Figure 14 Connectivity with Flexi Multiradio 10 BTS . . . . . . . . . . . . . . . . . . . . . . . 20

Figure 15 U-plane network architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Figure 16 TTP policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Figure 17 Cell trace interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Figure 18 Throughput performance dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . 27

Figure 19 Operability domains and tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Figure 20 Transparent Content Caching - High Level Architecture . . . . . . . . . . . . 34

Figure 21 Content Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Figure 22 DNS Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Figure 23 TCP Header Enrichment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36


6/40

6

Issue 01


Id:0900d80580a3e47a

List of TablesTable 1 System release and network elements . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Table 2 Embedded applications in LA10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Table 3 Ethernet interfaces and IP address . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Table 4 Embedded applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33


7/40

Issue 01

7

Liquid Applications System Description Introduction to Liquid Applications

Id:0900d80580a3fb91

1 Introduction to Liquid ApplicationsThe demand for data-enabled mobile devices, such as smartphones, causes an

increase in mobile broadband traffic within the network of an operator. This trend is

expected to continue, especially with the widespread roll-out of Long Term Evolution

(LTE), which offers increased data rates over mobile networks. Because of increasing

mobile broadband traffic, operators are expected to provide a superior experience for

the customers and create new value from network infrastructure, based on the individual

and personalized applications and services.

Liquid Applications (LA) is an innovative network technology that provides a unique and

enhanced mobile broadband experience and drives new value for the operators. LA

transforms the base station into a value creation engine through applications, services,

and content that is placed in close proximity with the mobile subscribers. Moving the

content at the edge of the mobile network provides a more responsive experience as it

is delivered with lower latency. In addition, content and applications can interact in real-

time with the subscriber, in terms of their individual needs, location and social-based

preferences, making their experience completely personal.

As the primary source of revenue like voice and messaging continue to decline, because

of the rise of over-the-top (OTT) services, LA enables operators to generate new forms

of revenue from new business models, services, and applications.

1.1 Mobile edge computing

LA is the new mobile edge computing platform from NSN. At the heart of LA is the Radio

Applications Cloud Server (RACS) which re-defines the role of the base station through

applications, services and content placed in close proximity to mobile subscribers and

by using real-time network information to offer personalized services.

The RACS deploys the latest cloud technology and service creation capabilities into the

base station, enabling the collection of real-time network data such as radio conditions,

subscriber location, direction of travel, and more. These data are used by applications

to offer context-relevant services that transform the mobile broadband experience.

1.2 Benefits of proximity and context

Content located at the base station provides key advantages in terms of user experi-

ence. It reduces the need for the content to be pulled from the Internet and across the

mobile network whenever it is requested. This is facilitated by a cache located inside the

base station which contains frequently requested or popular content that can be deliv-

ered directly to the mobile subscriber over the radio interface every time it is requested.

Content that is accessed from the base station is five times faster than from caches

located elsewhere in the network.

To provide a contextual experience, real-time radio data can be extracted from inside

the base station to enable location-specific content, such as hyper-targeted advertising

from nearby businesses, or information about tourist and visitor attractions within the

area. This real-time data exposure will open-up fresh and exciting opportunities to pos-

itively impact the mobile broadband experience of the subscribers with personalized

service offerings and improved performance.


8/40

8

Issue 01


Id:0900d80580a3fb91

Introduction to Liquid Applications

1.3 Monetization opportunities

The RACS extends applications and services that normally reside within the Internet or

the centralized core and data centers of operators, to the very edge of the network. An

operator's dense network of base stations is transformed by the RACS into numerousvalue creation engines. The RACS enables innovative, low-latency services, such as

mobile gaming and augmented reality, and accelerates media-rich applications that

deliver an enhanced quality of experience for the mobile subscriber.

The RACS processes large amount of data in real-time that are complex and costly to

deliver on a traditional centralized cloud. The following key features enable a base

station to become a value creation engine:

• Network efficiency – Load in other parts of the network is reduced with the content

stored inside the base station, which leads to saving and reducing of the Total Cost

of Ownership (TCO).

• Application connectivity – To improve the user experience through real-time con-

textually-aware applications and services, real-time data that resides on or off the

base station is extracted and exposed to applications.

• Distributed Cloud architecture – A dense network of computing and storage loca-

tions at the very edge of the mobile network approximates data centers rather than

just improving their computation. Operators will benefit in creating a distributed

Cloud-based architecture as it will empower them to embrace big data, giving them

the opportunity to make more money.


9/40

Issue 01

9

Liquid Applications System Description System overview

Id:0900d80580a3fb9d

2 System overviewThe first LA system release LA10 consists of the following products:

•Radio Applications Cloud Server (RACS)

• RACS-Tokenizer (RACS-T)

• RACS-Core (RACS-C)

• Application Framework Manager (AFM)

Figure 1 LA system and product structure shows the structure of LA system release

LA10.

Figure 1 LA system and product structure

The RACS, RACS-C, and RACS-T are network elements that are managed individually.

For more information, see 3 Radio Applications Cloud Server and 4 RACS-C and

RACS-T.

Table 1 System release and network elements shows the respective network element

software (SW) releases and the supported hardware (HW)

The RACS application platform and RACS applications are managed using AFM. For

more information on AFM, see 5.2 Application Framework Manager . LA10 supports four

Embedded Applications, created by NSN. For more information on Embedded Applica-

tions, see 6 Embedded applications.

2.1 RACS deployment scenarios

LA10 has been developed for LTE macro base station (eNB) deployment. This includes

both Distributed RAN (DRAN) and Centralized RAN (CRAN) scenarios. For the CRAN

(baseband hotel) scenario, there is a one-to-one mapping between the Flexi System

Module and RACS. Figure 2 RACS deployment scenarios shows the deployment sce-

narios of LA. LTE base station deployment is designed for LA system release LA10,

while aggregation and RNC deployments are planned for future releases.

UE eNB RACS

MobileBackhaul

RACS-T SAE-GW RACS-C

AFM

NetAct

Internet

Server

System

Release

RACS RACS-C RACS-T

SW release supported HW SW release supported HW SW release supported HW

LA10 RACS 1.0 FBSA, FBXA RACS-C 1.0 HP DL380 Gen8 RACS-T 1.0 HP DL380 Gen8

Table 1 System release and network elements


10/40

10

Issue 01


Id:0900d80580a3fb9d

System overview

Figure 2 RACS deployment scenarios

2.2 Release principles

LA is based on the LTE and WCDMA system releases, but it is not part of these system

releases. As a result, LA uses features provided by the LTE and WCDMA system

releases. For example, the first LA system release LA10 is based on RL40 and the

second release LA20 is planned to be based on RL50. LA20 will be backwards compat-

ible with RL40. Figure 3 Release principles shows the release principles of the software

life cycles with respect to the application types of the LA

LTEbase station

FlexiMultiradio (10) BTS

Low-order Aggregation(Access)Site

High-order Aggregation Site Backbone Site (GW)

Aggregation

RNC

RNC


11/40

Issue 01

11

Liquid Applications System Description System overview

Id:0900d80580a3fb9d

Figure 3 Release principles

The RACS, RACS-C, and RACS-T applications are application software that run on the

RACS, RACS-C, and RACS-T platforms. There are two types of application, having dif-

ferent life cycle management characteristics:

• Embedded Applications - are created by NSN and provided as part of a system

release.

• Add-on Applications - can be created by NSN or 3rd parties (for example, Inde-

pendent Software Vendors) and provided independently from the LA systemrelease. The latter concept allows a faster release cycle than what is possible from

telecom-based network elements.

Embedded applications in LA10 is shown in Table 2 Embedded applications in LA10.

There are applications that require software to run on other network elements. These

applications are known as Remote Applications, which are located either in the core

network or on the internet. Figure 4 RACS, RACS-C, and RACS-T Applications vs.

Remote Applications shows the comparison between the RACS, RACS-C, and RACS-

T applications and Remote applications.

Embedded applications

Life cycle management Related to LA

Ownership NSN

Storage NOLS

SW management (installation) Using NetAct

Deployment (Activation/Deactivation) Using AFM

Table 2 Embedded applications in LA10


LA System Release

App1

LA10 LA20 LA30

API, resources API, resources

RACS Applications

Add-on Applications App2

App3

Supporting features

RL40

Supporting features

RL50

Supporting features

RL60, RU50


12/40

12

Issue 01


Id:0900d80580a3fb9d

System overview

Figure 4 RACS, RACS-C, and RACS-T Applications vs. Remote Applications


13/40

Issue 01

13

Liquid Applications System Description Radio Applications Cloud Server

Id:0900d80580a3fb97

3 Radio Applications Cloud Server The key element of the LA system is the RACS. The RACS is a new network element in

the Radio Access Network (RAN). For the RACS 1.0, the RACS is connected to the

Long Term Evolution (LTE) base station (eNB).

3.1 Product concept

The RACS is an application server capable of providing computing resources, storage

capacity, and connectivity. The principles of established cloud computing were adopted

to accelerate the development of application software (known as RACS Applications)

running on the RACS. Initially, RACS implements the Infrastructure-as-a-Service (IaaS)

concept where the applications reside in their dedicated Virtual Machines (VM). Support

for Java applications using Platform-as-a-Service (PaaS) principles is planned for future

releases.

The RACS provides a standard runtime environment for applications through virtualiza-

tion. The RACS applications have access to LTE User plane (U-plane) and Control

plane (C-plane) data through the defined Application Programming Interfaces (APIs).

This is shown in Figure 5 RACS - product concept.

g In RACS 1.0, APIs are only exposed towards Embedded Applications. For RACS 2.0, itis planned to extend this towards Add-on Applications.

Figure 5 RACS - product concept

3.1.1 Telecom and IT domains

The IT domain (refers to the user applications, servers, and the IP traffic in between) is

separated from the telecom domain based on the 3rd Generation Partnership Project

(3GPP) design principles. Figure 6 Telecom and IT domain shows the relationship

between the telecom and IT layer. From the perspective of the UE, the first network

App N App 1

Radio ApplicationsCloud Server

App

1

App

N

Application Platform

Hardware

eNB

NodeB RNC


14/40

14

Issue 01


Id:0900d80580a3fb97

Radio Applications Cloud Server

element that has access to the user's IP traffic is the System Architecture Evolution

Gateway (SAE-GW) in the Core Network (CN). Normally, mobile networks were built

with few centralized CNs. This resulted to CN elements being away from the UEs in

terms of networking. Geographical distance turns into propagation delays, which is

further increased by latencies introduced by the many networking hops in between. Fur-

thermore, the Mobile Backhaul (MBH) network is a significant cost factor for the opera-

tors. In most cases, over-dimensioning is prohibitive, so traffic congestion may occur.

This has an impact on the service quality, perceived as Quality-of-Experience (QoE) by

the mobile subscriber.

Figure 6 Telecom and IT domain

The separation between the Radio Access Network (RAN) and the CN defined by 3GPP

is another drawback because most of the real-time information related to the radio inter-

face is hidden in the RAN. Not even the CN elements of the operator can access this

data. The availability of this information is very useful to improve the quality of many ser-

vices.

To address the above-mentioned issues, the RACS intercepts the U-plane. This is

shown in Figure 7 RACS with Traffic Offload Function (TOF). The RACS implements a

Traffic Offload Function (TOF) so that the software running on the RACS has full access

to the IP traffic of the user. Note that the RACS does not conflict with 3GPP protocols.

Through a proprietary interface, the RACS has real-time access to the 3GPP C-plane

and Radio Resource Management (RRM) information in the eNB.

UE eNB

MobileBackhaul

SAE-GW

Internet

Server

UserApp

IP

PDCP

LTE MAC

LTE PHY LTE PHY

LTE MAC

PDCP

GTP-U

UDP

Eth MAC

Eth PHY

Application IP (NAT)

GTP-U

UDP

Eth PHY

Eth MAC Eth MAC

Eth PHY Eth PHY

Eth MAC

IP

Server AppIT Domain

Telecom Domain (3GPP)

3GPP-TNL IPIP IP


15/40

Issue 01

15


Id:0900d80580a3fb97

Figure 7 RACS with Traffic Offload Function (TOF)

3.2 High-level architecture

The LA software is divided into two major components: LA10 RACS Platform and LA10

RACS Applications.

The LA10 RACS Platform is subdivided into the following main components:

• The Base Platform provides computing, storage and connectivity capabilities. The

Base Platform is managed through NetAct.

• The Application Platform provides the capabilities for hosting LA10 RACS Applica-

tions. The Application Platform is managed through the Application Framework

Manager (AFM).

Figure 8 LA10 RACS high level architecture shows the high level architecture of LA10

RACS. Additional value is created through Platform Services which LA10 RACS Appli-

cations can take advantage of. Services are provided through well-documented Appli-

cation Programming Interfaces (API). The architecture also allows LA10 RACS

Applications to provide services to others through their own API.

UE eNB

MobileBackhaul

Internet

Server

User App

IP

PDCP

LTE MAC

LTE PHY LTE PHY

LTE MAC

PDCP

GTP-U

UDP

Eth MAC

Eth PHY

Application IP

IT Domain

Telecom Domain

3GPP-TNL IPIP

SAE-GW

(NAT)

GTP-U

UDP

Eth MAC Eth MAC

IP

RACS

Eth PHY

Eth MAC

IP

Server App

GTP-U

UDP

Eth MAC

IP

Eth MAC

GTP-U

UDP

IP

IPIP

RACS App

Eth PHYEth PHYEth PHYEth PHY


16/40

16

Issue 01


Id:0900d80580a3fb97


Figure 8 LA10 RACS high level architecture

3.3 RACS hardware

The FlexiBTS Server module, version A (FBSA) is the base station-specific hardware

(HW) platform for RACS1.0.see Figure 9 FBSA.

The FBSA module is a HW platform based on a scalable Intel x86 multi-core processor

architecture that provides the functions to execute non-3GPP applications in a virtual-

ized-processing environment. The module runs in a Windriver Linux 4.3 operating

system and Kernel-based Virtual Machine (KVM)-enabled virtualization.

The FBSA is fully compatible to the FlexiMultiradio10 BTS platform. The module is

plugged into the Baseband (BB) extension slot of the FlexiMultiradio 10 System Module

and thus is the most compact solution without requiring extra site cabinets or boxes. It

covers the full temperature range of FlexiMultiradio 10 BTS and there is no need for

additional space and power consuming heat exchange equipment.

The FBSA main characteristics include:

• Intel Xeon Sandy Bridge (Gladden) 4 cores at 2GHz

• 16 Gbyte DDR-3

• 400 Gbyte SSD storage

• SPECInt2006_Rate: 111

• SPECFP2006_Rate: 88

• External interfaces:

– 2x GE RJ-45

– 2x 1/10 GE SFP+ (enables optical and twinax connection)

– -48V Power

Embedded Applications

API

VM VM

API

VM VM VM

Add-on Applications

API

Platform Service API

Platform Service API

Platform Service

Application Platforms (IaaS)

Base Platform (Computing, Storage, Connectivity)

Platform SW

HW

Radio Applciations Cloud Server (RACS)

ApplicationManagers

ApplicationFrameworkManager

NetAct

NSN Applications 3rd Party Applications


17/40

Issue 01

17


Id:0900d80580a3fb97

Figure 9 FBSA

3.4 Site configuration

The FBSA is designed for Flexi BTS mechanics, suitable for both indoor and outdoor

installation. The FBSA supports zero-footprint installation with Flexi Multiradio 10 BTS.

This is shown in Figure 10 Flexi Multiradio 10 BTS site configuration. For example, no

extra installation space is required as the FBSA fits into one of the extension slots under-

neath the System Module FSMF.

Figure 10 Flexi Multiradio 10 BTS site configuration

In case of Flexi Multiradio BTS or if both FSMF extension slots are occupied within the

Flexi Multiradio 10, the FBSA can be installed in a separate casing with the Flexi BTS

Server Extension Kit, version A (FBXA). This is shown in Figure 11 Flexi Multiradio BTSsite configuration.

RACS

(FSMF)

hosted withSystem Module

RF module

FlexiMultiradio 10

Flexi Multiradio 10System Module

(FSMF)

Flexi BTS Server Module (FBSA)


18/40

18

Issue 01


Id:0900d80580a3fb97


Figure 11 Flexi Multiradio BTS site configuration

The FBXA enables the integration of the FlexiBTS Server Module (FBSA) into Flexi

Mutiradio BTS installations. The FBXA allows to use the FBSA module with Flexi Multi-

radio 10 BTS installations with fully utilized FBBx extension slots in an extension config-

uration.

The FBXA provides the integration of the Flexi BTS Server Module into NSN's previous

Flexi Multiradio BTS generation. This allows the operator to use the FBSA server

module even in deployments with previous and actual Flexi Multiradio installations

enabling a smooth transition to NSN's latest Flexi Multiradio BTS 10 solution.

3.5 Cabling options

There are many cabling options available, which is shown in Figure 12 Cabling options.

FlexiMultiradio

Flexi BTS Server Extension Kit

(FBXA)

Flexi BTS Server Module (FBSA)

Extension kitfor stand-alone

RF moduleSystem module(FSMD/FSME)


19/40

Issue 01

19


Id:0900d80580a3fb97

Figure 12 Cabling options

Connectivity with Flexi Multiradio BTS

The connection of the FBSA with Flexi Multiradio BTS is shown in Figure 13 FBSA con-nectivity with Flexi Multiradio BTS.

Figure 13 FBSA connectivity with Flexi Multiradio BTS

WithoutTransportSubmodule

WithoutServer Extension

WithTransportSubmodule

WithServer Extension

Flexi Multiradio 10 BTS Flexi Multiradio BTS

FSMF

FBBA 1 FBSA 1

FTIF FTIF FTIF

FSMFFSMFFSMF

FBBA 1 FBBA 1 FBBA 1FBSA 1 FBSA 1 FBSA 1

FTIF FTIF FTIF

FSMF FSMF FSMF

FBBA 2 FBBA 2 FBBA 2 FBBA 1FBBA 1FBBA 1

FBSA 1 FBSA 1 FBSA 1 FBSA 1

FSME

FTLB

sRIO

GE copper

GE opt

TRS

TRS TRS TRS

TRS TRS TRS TRS

case 1

case 1 case 1 case 1

case 1 case 1 case 1 case 1

case 2 case 2 case 2 case 2

DCOut1 DCOut2 DCOut3 DCOut4 EIF3 EIF2 EIF1 IF4 IF3 IF2 IF1

LMP BBU OVP ETP EAC SOUT SIN RF1 RF2 RF3 EXT1 EXT2

FSME

DCIn DCIn DCOut DCOut Alarm

DCIn EIF1 EIF2 EIF3 EIF4

FBSA

DC-48V

FTLB

TRSGE Copper / Optical

FBS Ext

DC-48V

LMP


20/40

20

Issue 01


Id:0900d80580a3fb97


Flexi Multiradio 10 BTS

The connectivity with Flexi Multiradio 10 BTS is shown in Figure 14 Connectivity with

Flexi Multiradio 10 BTS

Figure 14 Connectivity with Flexi Multiradio 10 BTS


FBBA

FSMF

DC-48V

DCOut DCIn LMP EIF2/RF4 RF3 RF2 RF1 SRIO BBExt1 BBExt2 EI F1 EAC SIN SOUT

DCIn DCOut RF/Ext BBExt SRIO

TRSGE optical

LMP


FBBA

FSMF

DC-48V

DCOut DCIn LMP EIF2/RF4 RF3 RF2 RF1 SRIO BBExt1BBExt2 EIF1 EAC SIN SOUT

DCIn DCOut RF/Ext BBExt SRIO

TRSGE copper/optical

LMP


EIF4 EIF3 EIF2 EIF1 IF4/8 IF3/7 IF2/6 IF1/5

TRSGE copper

FBBA1

FSMF

DC-48V

DCOut DCIn LMP EIF2/RF4 RF3 RF2 RF1 SRIO BBExt1BBExt2 EIF1 EAC SIN SOUT

DCIn DCOut RF/Ext BBEx t SRIO

TRSGE copper/optical

EIF4 EIF3 EIF2 EIF1 IF4/8 IF3/7 IF2/6 IF1/5

TRSGE copper

FTIF

FTIF

DCIn DCOut RF/Ext BBEx t SRIO

FBSA

FBSA

FBBA2

FBSA

DC-48V

FBXA

LMP


21/40

Issue 01

21


Id:0900d80580a3fb97

3.6 Software provisioning

The RACS supports commissioning in two stages: pre-commissioning at the factory and

final commissioning at the BTS site. The factory pre-commissioning installs the RACS

SW and configures the default parameters like RACS IP Address, subnet mask,gateway and certificates in FBSA HW.

For local commissioning using the Structured Command Line Interface (SCLI), the

RACS provides a Local Management Port (LMP). The final commissioning at the site

provides the capabilities to setup the following:

• the management interface (NE3S/WS) for remote management through NetAct

• the management interface for application and cloud management through AFM

• the interface to the eNB

The LA10 SW (including Embedded Applications) will be shipped pre-installed on the

FBSA. Later release upgrades might be done remotely using NetAct.

Software Asset Monitoring (SWAM) has to be set up in the network. The activation ofEmbedded Applications is monitored using SWAM.

3.7 Network integration

This section provides information about the following network integration:

• Transport network integration

• LTE U-plane integration

• LTE C-plane integration

3.7.1 Transport network integrationBefore installing the RACS, the eNB is connected to the First-Hop-Router (FHR) through

a layer-2 (Ethernet) network. see Figure 15 U-plane network architecture. Physical inte-

gration of the RACS is done without affecting the operation of the LTE network. Network

integration can be performed remotely as a configuration action on both eNB and FHR:

The RACS is configured as a next hop as seen from the eNB in uplink and as seen from

the FHR in downlink direction. This configuration is done for the the U-plane only

(primary U-plane path). The eNB C-plane, M-plane and S-plane are not affected.

Figure 15 U-plane network architecture

The routing concept supports fail-safe behavior because Ethernet links between RACS

and FHR and between RACS and eNB are supervised by Bidirectional Forwarding

RACS

First-Hop-Router (FHR)

SAE-GWeNB

Primary U-plane pathSecondary U-plane path

MobileBackhaul

(IP)

MobileBackhaul(Ethernet)

eNB integratedEthernet switch

eNB integratedIP router


22/40

22

Issue 01


Id:0900d80580a3fb97


Detection (BFD). With this, both the eNB and the FHR can perform redundancy switch-

ing, which means re-routing the traffic from the primary to the secondary U-plane path.

The FBSA is connected to the eNB through either the EIF1 or EIF3 interface. For more

information on FBSA, see 3.3 RACS hardware. EIF2 is allotted for the Local Manage-ment Port (LMP).

Traffic separation

The traffic between RACS Applications and related servers in the Core Network is called

application plane traffic. In LA10, this applies to the traffic between the Content Optimi-

zation and Delivery (COD) applications running on the RACS, RACS-C, and RACS-T.

Separation between different types of traffic, like User plane (U-plane), Management

plane (M-plane), and Application plane (A-plane) traffic, can be done optionally using

VLAN (IEEE 802.1q).

The RACS has access to LTE C-plane information, but this is provided through the M-

plane. The LTE C-plane traffic bypasses RACS. As a result, C-plane is not included in

RACS traffic separation.

Transport QoS

The RACS supports QoS on both the Ethernet layer (IEEE 802.1p) and on the IP layer

(DSCP).

3.7.2 LTE U-plane integration

The Traffic Offload Function (TOF) in RACS is responsible for routing selected user

traffic from/to selected applications. The traffic offload policy decision in LA10 follows a

similar path as in the mobile packet core, for an EPS bearer / E-UTRAN Radio Access

Bearer (E-RAB). In addition to an access decision, the policy can also set packet filters.

The E-RAB might enter the system through the establishment of a new E-RAB or differ-

ent handover scenarios.

LA10 uses a static local policy decision. The policy is configured separately for each

Traffic Termination Point (TTP) through the Application Framework Manager (AFM).

The AFM allows different TTP Policy configurations for different RACS. The TTP policy

can be modified during the run-time of the application and does not require restarting or

redeploying the application. Figure 16 TTP policy shows the packet flow with the

sequence of admission decisions that are made and the role of policy filters in overalldecision chain.

Ethernet interface IP address Usage

EIF1/EIF3 IP_oam external connectivity to O&Msystems (NetAct,

AFM) and eNB integration (cell trace)

IP_app external connectivity for RACS applications

IP_uc gateway address for U-plane downlink traffic

from core

IP_ub gateway address for U-plane uplink traffic from

eNB

EIF2 IP_lmp local management port (LMP0

Table 3 Ethernet interfaces and IP address


23/40

Issue 01

23


Id:0900d80580a3fb97

Figure 16 TTP policy

The optional policy filters have two categories:

•E-UTRAN Radio Access Bearer (E-RAB) policy filters

• packet policy filters

The E-RAB policy filters implement E-RAB-level admission decision. The packet policy

filters allow filtering based on IP protocol version, Network IP address, and UE IP

address.

The following E-RAB policy filter parameters are supported:

• Subscriber Profile ID (SPID)

• Quality Class Indicator (QCI)

• Allocation Retention Priority (ARP)

The RACS performs U-plane interception to provide user IP layer data to the application.

This results in decapsulation and later reconstruction of the following:

• Transport Network Layer (TNL) IP Header (including DSCP persistence)

• GTP-U header (including PDCP SN and GTP-U SN persistence)

3.7.3 LTE C-plane integration

The integration of the RACS to the control and management plane of the eNB enables

the RACS to act as a third party trace collection entity through the cell trace interface,

see Figure 17 Cell trace interface. Both the U-plane and C-plane data are carried

through a single Ethernet link between the RACS and eNB.

PDN conn./eRAB

PDN conn./eRAB

Application

PDN conn./eRAB

Application processing

Applicationspecific filters

Reject

Pass

Application policy filters

Reject

Pass

eRAB policy filters

Reject

Pass

Reject

Pass

Reject

Pass

eRAB ARP filters

QCI (qualityclass indicator)

Subscriber profile ID

ApplicationU-planeinterface

Packetadmission

policy decision

eRAB

admissionpolicy decision

Scope of TTP policy

End-to-end IP trarffic


24/40

24

Issue 01


Id:0900d80580a3fb97


Figure 17 Cell trace interface

The NetAct TraceViewer application is used for the configuration of the cell trace inter-

face at the eNB.

The RACS monitors cell trace signaling and detects creation, modification and deletion

of E-RABs. The procedures that triggers offload start are:

• S1AP - E-RAB setup, E-RAB modify, initial context setup, UE context modification,

and incoming S1 handover

• X2AP - incoming X2 handover

The procedures that triggers offload termination are:

• S1AP: E-RAB Modify, E-RAB release, UE context modification, outgoing S1 han-

dover, Reset

• X2AP: outgoing X2 handover

3.8 Security

This section provides information about the following RACS security features:

• Server Security

• Server O&M Security

• Application Framework O&M Security

• Backhaul Security

• Application Security

3.8.1 Server security

The server security feature provides hardware and software protection for the RACS. It

includes the following sub-features:

•

AES-based disk encryption • Secure boot preparations

• Pre-Installed vendor certificate

• Double authentication for root account

AES based disk encryption

The AES-based disk encryption sub-feature adds a physical security layer to the data

stored on the integrated Solid State Disks (SSD). It provides a hardware-based mecha-

nism for encryption and decryption of user data without performance impact.

The AES-based disk encryption prevents critical data on the SSD to be read or cloned

by putting the SSD in another computing device with a SATA interface. The data on the

SSD cannot be modified offline in unattended situations.

RACS

MobileBackhaul

Cell TraceInterface

S1

eNBUE SAE-GW

TOF

TOF Traffic Offload Function


25/40

Issue 01

25


Id:0900d80580a3fb97

The AES encryption is according to Federal Processing Standards (FIPS)

Publication197. An AES key length of 128 is the minimum requirement.

Secure Boot preparations

The secure boot preparations sub-feature ensures that only authenticated and integrity-checked boot code, OS code, and application code is allowed to go into service. It allows

the operator, in future releases, to upgrade to a secure boot environment without site

maintenance.

Pre-Installed vendor certificate

The NSN vendor certificate is an individual certificate, which contains the FBSA's serial

number, public key, certificate's validity period, and the NSN factory Certification Author-

ity's (CA) signature. The NSN vendor certificate is pre-installed into the FBSA during

production.

This certificate may be used in later releases to authenticate the FBSA as genuine NSN

hardware to an operator's Public Key Infrastructure (PKI).

Double authentication for root account

Double authentication for the root account is a concept where the access is granted to

two super users simultaneously, to conduct any system-wide administrative operation.

A representative from NSN and from the operator is required to grant access. None of

them alone can take full control of the RACS node without the other party supervising

the actions.

3.8.2 Sever O&M security

The server O&M security provides support in authenticating the O&M connectivity with

X.509 certificates and managing these certificates in the RACS. It enables secure O&Mcontrol and bulk data communication between RACS and NetAct.

Secure O&M Connections

• HTTPS (NE3S/WS) is the protocol used for securing the O&M connection between

RACS and NetAct. TLS is used for encryption and integrity protection of NE3S/WS

carried by HTTP to form HTTPS.

• File transfer between RACS and NetAct is encrypted and integrity-protected.

Operator certificate management

Private key, public key, and digital certificates in X.509v3 format are handled by the

RACS certificate management. Certificate management is required for the enrollment of

operator certificates when public key infrastructure (PKI) is used in the network of thecustomer.

3.8.3 Application framework O&M security

The Application Framework O&M Security secures the connection between the RACS

and Application Framework Manager. The O&M messages and commands through the

RACS and AFM are encrypted and integrity-protected by the Transport Layer Security

(TLS) using X.509 certificates for authentication. File transfer between RACS and AFM

is encrypted and integrity protected by TLS (HTTPS).


26/40

26

Issue 01


Id:0900d80580a3fb97


3.8.4 Backhaul security

The backhaul security enhances the security for all traffic of the of User plane (U-plane),

Management plane (M-plane), and Application plane (A-plane) of the RACS, by provid-

ing authentication, encryption, and integrity protection using IPsec. The IPsec providessecure communications between the RACS and the core nodes by using secure trans-

port and application protocols.

IPsec supports the following capabilities:

• Services: data integrity protection, origin authentication and anti-replay protection,

confidentiality

• Protocol: ESP (RFC 4303)

• IPsec mode: tunnel mode

• Encryption/ciphering algorithms:

– AES-128-CBC

–

3DES-192-CBC – NULL

• Integrity protection algorithm: HMAC-SHA-1-96

• Authentication: digital certificates in X.509v3 format, pre-shared key (PSK)

• Identification with IP addresses, fully qualified domain names (FQDN, only with cer-

tificate authentication), and distinguished name ID_DER_ASN1_DN (only with cer-

tificate authentication)

• Key exchange:

– IKEv1

– Diffie-Hellman: Group 2 (1024-bit MODP)

3.8.5 Application security

Applications are packaged and deployed as per OVF 1.1 standard (OVA packages). In

LA10, only pre-integrated Embedded Applications are installed. Thus, there is no possi-

bility to install an unknown, unauthorized and unauthenticated application image.

3.9 Capacity

For LA10, the capacity of the RACS is designed to be compatible with the eNB capacity

of 3-cell configurations for 20 Mhz 2x2 MIMO, applying the all-average/single-peak prin-

ciple. This is shown in Figure 18 Throughput performance dimensioning. The RACS

also supports a maximum average throughput of 180 Mbps for the downlink and 60

Mbps for the uplink at the Ethernet level of the LA10 Embedded Applications.


27/40

Issue 01

27


Id:0900d80580a3fb97

Figure 18 Throughput performance dimensioning

The maximum number of E-RABs that can be handled for the RACS is 5040. The

average round trip time (RTT) for all kinds of packets in the RACS without the applica-

tions is less than 1 millisecond.

Cellaverage

Cellpe

ak

All-Averageaverage All-Average / Single-Peak

MAX (( average), peak)

All-Peakpeak

Recommended dimensioning range

Air interface capacity Transport capacity

Overbooking

PracticalMaximum

Minimum

Theoretical Maximum(overdimensioning)


28/40

28

Issue 01


Id:0900d80580a3fb99

RACS-C and RACS-T

4 RACS-C and RACS-TThe RACS-C and RACS-T are the key HW elements of the Content Optimization and

Delivery (COD) solution located in the EPC. These two new HW entities host the RACS-

C/COD and RACS-T/COD software.

4.1 Hardware

The RACS-C and RACS-T are based on commercial off-the-shelf (COTS) carrier grade

servers. Furthermore, specific switches are selected supporting the required L2-based

load balancing using LAG/LACP with SRC/DEST-IP hashing.

4.1.1 RACS-C

• HP DL380 Gen8 with 2 x XEON E5-2620 (6 Core @ 2GHz, HT, 15MB cache)

• memory: 48GB RAM

• HDD: 2 arrays of 8 disks of 900 GB to16 x 900 GB = 14,4 TB; highly reliable "enter-

prise" server disks; Smart Array P420/2GB FBWC controller

• 10G-BaseT Ethernet cards (default)

– 5 x 10G cards with 10 x 10G ports; DPDK-capable Intel 10G controllers (HP

10GBase-T controller 561T (Intel's 540/ Twinville chipset))

• AC (default) or DC power supply

• 2 rack units

4.1.2 RACS-T

• HP DL380 Gen8 with 1 x XEON E5-2620 (6 Core @ 2GHz, HT, 15MB cache)

• memory: 8GB RAM

• HDD: 2 disks of 300 GB to 600 GB

• 10G-BaseT Ethernet cards (default)

– 2 x 10G cards with 4 x 10G ports; DPDK-capable Intel 10G controllers (HP

10GBase-T controller 561T (Intel’s 540 / Twinville chipset))

– 2 x 1G cards with 2 x 1G ports (for CODP & O&M)


• 2 rack units

4.1.3 Switches

Default (electrical):

• HP 5900AF-48XGT-4QSFP (electrical + 4 x QSFP)

• 48 x 10G 10BaseT electrical ports

• 4 x 40G QSFP optical ports


• 1 rack unit

Optional (optical):

• HP 5900AF-48XG-4QSFP (optical + 4 x QSFP)

•

48 x 10G SFP+ optical ports • 4 x 40G QSFP optical ports


29/40

Issue 01

29

Liquid Applications System Description RACS-C and RACS-T

Id:0900d80580a3fb99


• 1 rack unit

4.2 SoftwareThe HW entities RACS-C and RACS-T are hosting the RACS-C/COD and RACS-

T/COD software:

RACS-C:

• OS: CentOS 6.4

• RACS-C/COD application SW

RACS-T:

• OS: CentOS 6.4

• RACS-T/COD application SW


30/40

30

Issue 01


Id:0900d80580a3fb95

Operation, administration, and maintenance

5 Operation, administration, and maintenanceWith the separation of the telecom and IT domains discussed in 1.2 Telecom and IT

domains, the operation, administration, and maintenance for LA is addressed by

domain-specific tooling:

• NetAct (for the telecom domain)

• Application Framework Manager (for the IT domain)

• Application specific managers (as required)

Figure 19 Operability domains and tools shows the operability domains and tools.

Figure 19 Operability domains and tools

5.1 NetAct

The network resource management (NRM) provides the ability and means to monitor

and control NEs from a central location. It supports the operator in executing automated

tasks, such as the configuration of NEs, fault detection, fault handling, or performance

surveillance.

Netact is the NRM platform for managing the LA network elements. NetAct provides

extended and sophisticated NEM functions, which includes the complete set of func-

tional areas, fault, configuration, security as well as software management and perfor-

mance monitoring.

NetAct is designed as a client and server system. The client provides a graphical user

interface (GUI), which enables the operator to inspect individual LA network elements

or groups of NEs. The server is the central processing entity and operates in the back-

ground. The server provides the contents of the GUIs displayed on a client using Web-

UI and Java functions. Management applications on the server communicate with the

dedicated O&M agents residing on RACS network elements, thus completing the func-

tional NRM communication path from the client via the server to a NE and vice-versa.

The main functional areas to be covered by the NRM system are commonly knownunder the acronym FCAPS, which stands for fault, configuration, accounting, perfor-

mance, and security management. In addition, NetAct provides system management.

Besides these functional areas, NetAct additionally provides the possibility of a central-

ized backup and restore function.

Fault management

NetAct Monitor is the fault management application of the NetAct tool. It enables differ-

ent and independent monitoring tools to be integrated within the same common desktop.

Failures are represented by alarms with a certain severity level like: critical, major, and

minor. In addition, explanation and repair texts are displayed.

Application Platform

Base Platform

ApplicationFrameworkManager

ApplicationManagers

NetAct

Application


31/40

Issue 01

31

Liquid Applications System Description Operation, administration, and maintenance

Id:0900d80580a3fb95

The fault management function provides fault monitoring of all the software layers of the

LA. The fault management of LA is based on the FlexiPlatform (FP) FPT2.0 release and

the Nokia Enhanced SNMP Solution Suite- Web Service (NE3S/WS) agent.

Configuration managementNetAct has access to the LA data through the use of dedicated NE3S/WS agent for con-

figuration management (CM) purposes. The communications between NetAct and the

NE is based on SOAP (XML over HTTPS). For accessing configuration data, a generic

GUI is provided on the NetAct client.

The configuration management of the LA is based on the NetAct Configurator applica-

tion, which consists of the CM Editor and the CM Operations Manager. In the context of

the NetAct Configurator, configuration is a set of Managed Objects. The NetAct Config-

urator application modules provide a set of tools to visualize and manage the configura-

tion of network resources.

The NetAct Configurator provides a north mediation interface to export CM data in XML

or CSV syntax, which can be further processed and adapted to systems in the operator's

environment.

Performance monitoring

Performance monitoring for LA10 uses the NetAct Reporter to provide data collection,

processing, and web-based tools to create and manage reports and KPIs. Pre-made

Reporting Suites are provided for the RACS network elements. In addition, own reports

can be created by the user with free selection of performance indicators and network

elements to be contained within the reports.

The NetAct Reporter also provides a north mediation interface to export performance

monitoring data in XML format.

Software management

Software management of the RACS elements is provided by the NetAct software

manager. Software manager provides the capability to roll out new software releases

and change packages in a fast and reliable manner from a centralized location.

Log management

Log Management is done with the NetAct Audit Trail application. Logs from the LA log

database are uploaded to the Audit Trail. Log data might be exported from the Audit Trail

storage.

g Audit trail support will be provided for the LA future releases

System management

The system management of NetAct includes launching element managers that cover

the following functions for LA:

• Process management

• Shell access

• Trace management

Backup and restore

Backup and restore (B&R) management enables the backup and restoration of NE data

and software. B&R is used for the recovery of different types of failures and disasters.

The following backup types are used depending on the degree of loss:

• Full backup of relevant file systems


32/40

32

Issue 01


Id:0900d80580a3fb95

Operation, administration, and maintenance

• Incremental backup of relevant file systems

• Full database backup

• Incremental database backup

The failure or disaster severity determines the procedure to be performed to restore thedata. The following restoration types are used:

• Restore of relevant file systems

• Restore of last full database backup

• Point-In-Time restore of database (only if supported by the database)

• Complete restore of the NE

The B&R solution also supports Fast System Restore (FSR) and Monitoring backup and

restore applications. NetAct uses Networker-based B&RServer (BRS) that runs on a

computing platform (CPf). The CPf uses HW from the HP Proliant product family,

RedHat Linux (RHEL) for the SW, and IBM SolidDB for the operating system and data-

base. The Networker server is managed via NetAct. Through the NE3S/WS agent, theNetworker server forwards the alarms and counters to the monitoring and performance

management applictions of NetAct. For the Networker operation, the Networker GUI is

a screen level that is integrated in NetAct.

5.2 Application Framework Manager

The Application Framework Manager (AFM) is a user interface that manages the lifecy-

cle and operability of the application and services provided by the application platform

of the LA. In LA10, AFM is based on the following components:

• HW: HP DL360p Gen8

•

SW: – ITNCM (IBM Tivoli Netcool Configuration Manager) version 6.4

– Redhat Linux

The AFM supports the following functions:

• Application Platform Configuration Management

– Machine application policy (for example, machine recovery priority)

– TTP policy (RAB selection parameters)

• Application life cycle management

– Application deploy (activation)

– Application undeploy (deactivation)

– Application start – Application stop

• Application configuration management - Application properties (exposed to applica-

tions running inside the virtual machine)


33/40

Issue 01

33

Liquid Applications System Description Embedded applications

Id:0900d80580a3fb8f

6 Embedded applicationsTable 4 Embedded applications shows the embedded applications supported by LA10

and the required NE(s) for each application feature.

Content Caching, DNS Caching, and Video Prioritization and Pacing are supported by

the Application Package Content Optimization and Delivery. TCP Header Enrichment

requires the respective Application Package to be installed.

Content Caching and TCP Header Enrichment applications are activated by default

when the respective application package is installed. DNS Caching and Video Prioriti-

zation and Pacing is optionally activated, depending on the need of the customer.

6.1 Content Optimization and Delivery

The main function of the Content Optimization and Delivery (COD) solution is mobile-

network-optimized transparent content caching. Transparent content caching allows to

cache and serve content from a content cache hosted by the RACS at the eNB. The

COD solution has three building blocks; for more information, see Figure

20 Transparent Content Caching - High Level Architecture. The three COD solution

building blocks are:

• The RACS/COD is an Embedded Application on the RACS at the eNB base station

providing a local content cache.

• The RACS-C/COD application is located at the SGi side of the mobile packet core

providing a central content cache and cache control.

• The RACS-T/COD (Tokenizer) application is located at the S1 or S5 side of the

mobile packet core, replacing the TCP payload with references to the real content

as stored in the local cache at RACS/COD.

The COD-P (COD protocol) provides the connectivity for intra-COD signaling and data

transfer.

Application

(Application

Package)

Application

Feature

Activation RACS RACS-T RACS-C

Content Optimiza-

tion and Delivery

(COD)

Content Caching default x x x

DNS Caching optional x

Video Prioritization

and Pacing

optional x x x

TCP Header

Enrichment (TCP-HE)

TCP Header

Enrichment

default x

Table 4 Embedded applications


34/40

34

Issue 01


Id:0900d80580a3fb8f


Figure 20 Transparent Content Caching - High Level Architecture

The COD supports the following applications:

• Content Caching

• DNS Caching • Video Prioritization and Pacing

6.1.1 Content Caching

Frequently requested content is cached in proximity with the requesting mobile users.

Therefore, content caching reduces the load on the backhaul network and improves the

user experience because of faster content download. Figure 21 Content Caching shows

the content caching solution. The solution supports handover, charging, and Lawful

Interception (LI) functions, which is performed by the respective CN elements.

Figure 21 Content Caching

6.1.2 DNS Caching

The purpose of DNS caching is to improve the DNS response time for the end-users by

answering DNS queries from a local DNS cache at the RACS. When a UE requests a

single web page, it triggers several DNS queries. Frequently requested address resolu-

tions are cached on the RACS instead of routing DNS queries to remote DNS servers.

This makes the web page load faster as DNS requests are quickly responded to, thus

improving the perceived user-experience. Figure 22 DNS Caching shows the DNS

caching network aspects.

Packet DataNetwork

eNBUE

RACS/COD

RACS-T/COD

S-GW P-GWRACS-C/

COD

Localcache

S1-U S1-U S5

SAE-GWSGi SGi

Centralcache

Policy, Charging, LI

(COD-P intra COD communication)

RAN EPC

WebServer LTE-Uu

UE eNB RACS

MobileBackhaul


Internet

Server

Caching Caching“Tokenization”

LI, Charging


35/40

Issue 01

35

Liquid Applications System Description Embedded applications

Id:0900d80580a3fb8f

Figure 22 DNS Caching

Cached entries are managed according to the DNS response frame Time-To-Live (TTL)

value. Although the DNS query is served from the DNS cache, the original DNS query

is forwarded to the respective DNS server to satisfy lawful interception regulations.

6.1.3 Video Prioritization and PacingThe Video Prioritization and Pacing application contains two optimization techniques for

the delivery of cached video from RACS:

• Video Rating and Prioritization- The Video Rating and Prioritization performs

intra-E-RAB optimization of concurrent traffic of one user without interfering with the

prioritization between E-RABs. The optimization monitors the media parameters of

each flow, including the required video bit-rate. If the actual video bit-rate is lower

than the required, the RACS controls the bit-rate of the low-priority TCP flows

passing over the same E-RAB.

• Adaptive Video Pacing- The Adaptive Video Pacing is about “just-in-time” delivery

of a media stream towards the UE. The UE is served with the content while being

consumed by the user. This is important in cases where the user starts consuming

content and stops the session after a short t ime. With this capability, only the portion

of the content being consumed by the user is downloaded towards the UE.

6.2 TCP Header Enrichment

The TCP Header Enrichment conveys Radio Resource Management (RRM) data to a

content optimizer, such as the NSN Flexi Content Optimizer (FCO), in real time. The

TCP Header Enrichment provides the cell ID, cell load, and per bearer throughput

guidance indicators. These indicators are inserted in the upstream user IP flows into the

options field of the TCP header. The enriched flows are received by FCO which is

deployed on the Gi interface. As a result, FCO applies optimization schemes under finegranular radio condition awareness. Figure 23 TCP Header Enrichment shows the TCP

Header Enrichment network aspects.

UE eNB RACS

MobileBackhaul


Internet

Server

Caching Caching“Tokenization”

LI, Charging


36/40

36

Issue 01


Id:0900d80580a3fb8f


Figure 23 TCP Header Enrichment

UE eNB RACS

MobileBackhaul

SAE-GW ContentServer

Content Optimizer (in Core Network)

Internet

IP

TCP

HTTP

Content

TCP Header Enrichment

IP IP Application IP IP

TCP

HTTP

Content

IP

TCP

HTTP

Content

2) Optimized content delivery

1) TCP with additional header information


37/40

Issue 01

37

Liquid Applications System Description Glossary

Id:0900d80580a3e397

7 Glossary

Application Frame-

work Manager

the user interface (UI) to manage the RACS Application Platform and the lifecycle of

RACS Applications. AFM in LA10 is based on ITNCM v6.4 (IBM Tivoli Netcool Configu-ration Manager).

RACS application

feature

a functional item of a RACS application

Upon activation of a RACS Application Package, one or more supported RACS Appli-

cation Features might be enabled by default. Other (optional) RACS Application

Features might be activated selectively through AFM.

RACS application

package

SW image which is deployed on the RACS platform using the Application Framework

Manager (AFM) and supports the RACS Application

RACS / RACS-C /

RACS-T add-on

applications

(from LA20 onwards) can be created by NSN or 3rd parties (for example, Independent

Software Vendors) and provided independently from a Liquid Applications system

release

RACS / RACS-C /

RACS-T applications

application software running on the RACS / RACS-C / RACS-T application platform

RACS / RACS-C /

RACS-T embedded

applications

created by NSN and provided as part of a Liquid Applications system release

Remote applications application software running on other network elements, but is functionally related to

RACS / RACS-C / RACS-T applications


38/40

38

Issue 01


Id:0900d80580a40deb

Acronyms

8 Acronyms

AC Alternating current

AFM Application Framework Manager

API application programming interface

ARP allocation and retention priority

A-plane Application plane

BFD Bidirectional Forwarding Detection

CDR charging data record

CM Configuration Management

CN core network

COD Content Optimization and Delivery

COTS commercial off-the shelf product

CRAN Centralized RAN

C-plane Control plane

DC direct current

DEST Destination

DRAN Distributed RAN

EPC evolved packet core

E-RAB E-UTRAN radio access bearer

FCO Flexi Content Optimizer

FHR First-Hop-Router

FM Fault Management

FTP file transfer protocol

GE Gigabit Ethernet

GW gateway

HDD hard disk drive

HTTP hypertext transfer protocol

HW hardware

IaaS Infrastructure-as-a-Service

ITNCM IBM Tivoli Netcool Configuration Manager

L2 Layer 2


39/40

Issue 01

39

Liquid Applications System Description Acronyms

Id:0900d80580a40deb

LA Liquid Applications

LACP Link Aggregation Control Protocol

LAG Link Aggregation Group

LI lawful interception

LMP local management port

LTE long-term evolution

MBH mobile backhaul

M-plane management plane

NRM Network Resource Management

O&M operation and maintenance

OS operating system

OTT Over-the-top

PaaS Platform-as-a-Service

PKI public key infrastructure

PM Performance Management

QC quality class indicator

QoE quality of user experience

QoS quality of service

QSFP Quad Small Form-Factor Pluggable (Transceiver-Module)

RACS Radio Applications Cloud Server

RACS-C RACS-Core

RACS-T RACS-Tokenizer

RAN radio access network

RRM radio resource management

RTT round-trip time

SAE system architecture evolution

SCLI Structured Command Line Interface

SEG security gateway

SFP small form-factor pluggable

SNMP Simple Network Management Protocol

SPID service provider identification

SRC source


40/40

Liquid Applications System Description Acronyms

SSD Solid State Disk

SW software

SWAM software asset monitoring

S-plane synchronization plane

TCO total cost of ownership analysis

TOF traffic offload function

TTP traffic termination point

UE user equipment;

UI user interface

U-plane user plane

VM virtual machine

Documents

292616319 Liquid Applications System Description PDF