Liquid_Applications_System_Description.pdf

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.

2Issue 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 which the 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 respective owners, 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 Produktsicherheit Von 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.

Issue 013


Id:0900d80580a3e47a

Table of ContentsThis document has 40 pages.

1 Introduction to Liquid Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1 Mobile edge computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Benefits of proximity and context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 Monetization opportunities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1 RACS deployment scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Release principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Radio Applications Cloud Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1 Product concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1.1 Telecom and IT domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 High-level architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3 RACS hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4 Site configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.5 Cabling options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.6 Software provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.7 Network integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.7.1 Transport network integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.7.2 LTE U-plane integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.7.3 LTE C-plane integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.8 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.8.1 Server security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.8.2 Sever O&M security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.8.3 Application framework O&M security . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.8.4 Backhaul security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.8.5 Application security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.9 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 RACS-C and RACS-T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.1.1 RACS-C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.1.2 RACS-T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.1.3 Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2 Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5 Operation, administration, and maintenance . . . . . . . . . . . . . . . . . . . . . 305.1 NetAct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.2 Application Framework Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 Embedded applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.1 Content Optimization and Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336.1.1 Content Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.1.2 DNS Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.1.3 Video Prioritization and Pacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.2 TCP Header Enrichment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4Issue 01


Id:0900d80580a3e47a

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

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

Issue 015


Id:0900d80580a3e47a

List of FiguresFigure 1 LA system and product structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Figure 2 RACS deployment scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Figure 3 Release principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Figure 4 RACS, RACS-C, and RACS-T Applications vs. Remote Applications. . 12Figure 5 RACS - product concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Figure 6 Telecom and IT domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Figure 7 RACS with Traffic Offload Function (TOF). . . . . . . . . . . . . . . . . . . . . . . 15Figure 8 LA10 RACS high level architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Figure 9 FBSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Figure 10 Flexi Multiradio 10 BTS site configuration . . . . . . . . . . . . . . . . . . . . . . . 17Figure 11 Flexi Multiradio BTS site configuration. . . . . . . . . . . . . . . . . . . . . . . . . . 18Figure 12 Cabling options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Figure 13 FBSA connectivity with Flexi Multiradio BTS . . . . . . . . . . . . . . . . . . . . . 19Figure 14 Connectivity with Flexi Multiradio 10 BTS . . . . . . . . . . . . . . . . . . . . . . . 20Figure 15 U-plane network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Figure 16 TTP policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Figure 17 Cell trace interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Figure 18 Throughput performance dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . 27Figure 19 Operability domains and tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Figure 20 Transparent Content Caching - High Level Architecture . . . . . . . . . . . . 34Figure 21 Content Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Figure 22 DNS Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Figure 23 TCP Header Enrichment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6Issue 01


Id:0900d80580a3e47a

List of TablesTable 1 System release and network elements . . . . . . . . . . . . . . . . . . . . . . . . . . 9Table 2 Embedded applications in LA10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Table 3 Ethernet interfaces and IP address . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Table 4 Embedded applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Issue 017

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 computingLA 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 contextContent 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.

8Issue 01


Id:0900d80580a3fb91

Introduction to Liquid Applications

1.3 Monetization opportunitiesThe 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 numerous value 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.

Issue 019

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 scenariosLA10 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

10Issue 01


Id:0900d80580a3fb9d

System overview

Figure 2 RACS deployment scenarios

2.2 Release principlesLA 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

Issue 0111

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 system release. 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

12Issue 01


Id:0900d80580a3fb9d

System overview

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

Issue 0113

Liquid Applications System Description Radio Applications Cloud Server

Id:0900d80580a3fb97

3 Radio Applications Cloud ServerThe 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 conceptThe 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, it is planned to extend this towards Add-on Applications.

Figure 5 RACS - product concept

3.1.1 Telecom and IT domainsThe 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 NApp 1

Radio ApplicationsCloud Server

App1

AppN

Application Platform

Hardware

eNB

NodeB RNC

14Issue 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

User App

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

Issue 0115


Id:0900d80580a3fb97

Figure 7 RACS with Traffic Offload Function (TOF)

3.2 High-level architectureThe 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

16Issue 01


Id:0900d80580a3fb97


Figure 8 LA10 RACS high level architecture

3.3 RACS hardwareThe 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 ServiceAPI

Platform ServiceAPI

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

Issue 0117


Id:0900d80580a3fb97

Figure 9 FBSA

3.4 Site configurationThe 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 BTS site configuration.

RACS

(FSMF)

hosted withSystem Module

RF module

FlexiMultiradio 10

Flexi Multiradio 10System Module

(FSMF)

Flexi BTS ServerModule (FBSA)

18Issue 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 optionsThere are many cabling options available, which is shown in Figure 12 Cabling options.

FlexiMultiradio

Flexi BTS ServerExtension Kit

(FBXA)

Flexi BTS ServerModule (FBSA)

Extension kitfor stand-alone

RF moduleSystem module(FSMD/FSME)

Issue 0119


Id:0900d80580a3fb97

Figure 12 Cabling options

Connectivity with Flexi Multiradio BTSThe 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

WithoutServerExtension

WithTransportSubmodule

WithServerExtension

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

20Issue 01


Id:0900d80580a3fb97


Flexi Multiradio 10 BTSThe 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 EIF1 EAC SIN SOUT

DCIn DCOut RF/Ext BBExt SRIO

TRSGE optical

LMP


FBBA

FSMF

DC-48V



TRSGE copper/optical

LMP


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

TRSGE copper

FBBA1

FSMF

DC-48V



TRSGE copper/optical

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

TRSGE copper

FTIF

FTIF


FBSA

FBSA

FBBA2

FBSA

DC-48V

FBXA

LMP

Issue 0121


Id:0900d80580a3fb97

3.6 Software provisioningThe 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 of Embedded Applications is monitored using SWAM.

3.7 Network integrationThis 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

22Issue 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 separationThe 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 QoSThe RACS supports QoS on both the Ethernet layer (IEEE 802.1p) and on the IP layer (DSCP).

3.7.2 LTE U-plane integrationThe 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 overall decision 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

Issue 0123


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 integrationThe 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

Application

specific

filtersReject

Pass

Application

policy

filtersReject

Pass

eRAB

policy

filters

Reject

Pass

Reject

Pass

Reject

Pass

eRABARP filters

QCI (qualityclass indicator)

Subscriberprofile ID

ApplicationU-planeinterface

Packetadmission

policy decision

eRABadmission

policy decision

Scope ofTTP policy

End-to-end IP trarffic

24Issue 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 SecurityThis 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 securityThe 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 encryptionThe 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

Issue 0125


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 preparationsThe 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 certificateThe 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 accountDouble 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 securityThe 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&M control 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 managementPrivate 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 the customer.

3.8.3 Application framework O&M securityThe 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).

26Issue 01


Id:0900d80580a3fb97


3.8.4 Backhaul securityThe 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 provides secure 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 securityApplications 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 CapacityFor 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.

Issue 0127


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

Ce

ll p

ea

k

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)

28Issue 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 HardwareThe 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) • AC (default) or DC power supply • 2 rack units

4.1.3 SwitchesDefault (electrical):

• HP 5900AF-48XGT-4QSFP (electrical + 4 x QSFP) • 48 x 10G 10BaseT electrical ports • 4 x 40G QSFP optical ports • AC (default) or DC power supply • 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

Issue 0129

Liquid Applications System Description RACS-C and RACS-T

Id:0900d80580a3fb99

• AC (default) or DC power supply • 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

30Issue 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 NetActThe 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 known under 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 managementNetAct 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

Issue 0131

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 monitoringPerformance 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 managementSoftware 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 managementLog 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 managementThe system management of NetAct includes launching element managers that cover the following functions for LA:

• Process management • Shell access • Trace management

Backup and restoreBackup 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

32Issue 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 the data. 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, the Networker 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 ManagerThe 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)

Issue 0133

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 DeliveryThe 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

34Issue 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 CachingFrequently 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 CachingThe 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

WebServerLTE-Uu

UE eNB RACS

MobileBackhaul


Internet

Server

Caching Caching“Tokenization”

LI, Charging

Issue 0135

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 time. With this capability, only the portion of the content being consumed by the user is downloaded towards the UE.

6.2 TCP Header EnrichmentThe 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 fine granular 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

36Issue 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

Issue 0137

Liquid Applications System Description Glossary

Id:0900d80580a3e397

7 GlossaryApplication Frame-

work Managerthe 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 applicationfeature

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 applicationpackage

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

38Issue 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

Issue 0139

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

40Issue 01


Id:0900d80580a40deb

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

Liquid_Applications_System_Description.pdf