Yota DRA 3.6.1 Quick Start Guide

© Yota 2014

Yota DRA

Quick Start Guide

Product version: 3.6.1

Document version: 1.0

Status: development

© Yota 2014 2

Revision History

Date Version Author Revision

01.05.2014 1.0 Evgenia Martynyuk Document created

© Yota 2014 3

Table of Contents

Introduction .............................................................................................................. 4

Related Materials ................................................................................................... 4

Abbreviations ........................................................................................................ 4

DRA Configuration ..................................................................................................... 5

DRA Configuration File Structure ............................................................................. 5

DRA Configuration Example .................................................................................... 7

Flexible Messages Routing .......................................................................................... 9

Yota PCRF and DRA Interaction Configuration............................................................... 10

Maintenance ............................................................................................................ 11

Yota DRA 3.6.1

Quick Start Guide

© Yota 2014 4

Introduction

In the core of highly loaded LTE network the number of components that interact via Diameter

protocol rapidly grows as well as signaling traffic volume. Balancing, optimization and Diameter

traffic management are possible with Yota Diameter Routing Agent (Yota DRA).

In this release Yota DRA supports:

Topology Hiding

Message Resending

Flexible Messages Routing

Load Balancing

Session Failover

Gx, Gy, Rx Interfaces Support

This step-by-step guide will help you to understand the essential principle of DRA configuration, PCRF and DRA interaction, as well as maintenance procedures.

Related Materials

1. 3GPP TS 29.212 Rel. 9. Specification 3GPP TS 29.212 Policy and charging control over Gx

reference point

2. 3GPP TS 29.210 Rel. 9. Specification 3GPP TS 29.210 Charging Rule Provisioning over Gx

Interface

3. IETF RFC 3588. Specification IETF RFC 3588 Diameter Base Protocol

4. IETF RFC 4006. Specification IETF RFC 4006 Diameter Credit Control Application

5. Yota PCRF Installation Guide. Installation process description of Yota PCRF for LTE network

Abbreviations

Abbreviation Meaning

DDF Data Distribution Function

PCRF Policy and Charging Rules Function

DRA Diameter Routing Agent

PGW PDN Gateway

IMS IP Multimedia Subsystem

DPI Deep Packet Inspection

AF Application Function

DRA Configuration

© Yota 2014 5

DRA Configuration

General DRA configuration file is /etc/dra/config/dra.conf, which contains settings of all

clusters/nodes that will interact with each other using DRA.

The file can be uploaded via DRA O&M Console (Configuration -> List Files -> Upload).

After the first installation the configuration file contains only DRA node settings by default.

These settings are taken from deploy configuration file. Also after the installation

/etc/dra/config/sample.conf file is added, which contains an example of full configuration.

If dra.conf file was updated the system applies changes immediately.

DRA Configuration File Structure

DRA configuration file include:

1. CLUSTER sections, where all clusters are described: PCRF, UGW, CTF, OCS, DPI, DDF and

so on.

CLUSTER section parameters:

Parameter Description

NAME User friendly cluster name. Used in engine.lua in command like proxy_to("cluster_name"). Must be unique. If not set then HOST parameter is used

HOST Shared Diameter host for all cluster nodes, which will be used as a peer host if HIDE_PEERS parameter is set

REALM Shared Diameter realm for all cluster nodes, which will be used as a peer realm if HIDE_PEERS parameter is set

HIDE_PEERS

Hides the number of peers and their names from external systems. If the parameter is set then to external clusters only shared cluster name, realm will be shown, not peer’s one. If not set than original domain name of a peer is taken.

CLUSTER section contains:

Mandatory sections PEER, where cluster nodes are described. Nodes can be described

more than in one section.

PEER section parameters:


REALM Diameter Realm of a peer. Mandatory

ADDRESS FQDN or IP address of a peer. Mandatory

HOST Diameter hostname of a peer. Mandatory

PORT Diameter port of a peer (3868 by default)

HTTP_PORT HTTP port of a peer (80 by default)

MANDATORY If peer’s availability is critical or not (0 by default)

AUTOCONNECT 0 (Default) – this node will wait for income connection from another peer (for example, DRA); 1 – a node will initiate connection with another peer itself. (0 by default)

WEIGHT What load this node takes (in %)

PROTOCOL What protocol is used – TCP or SCTP (TCP by default)

BACKUP If a node is a backup node or not. Is the parameter is set this node will not be involved in load processing while at list one of all main nodes operates fine

Yota DRA 3.6.1

Quick Start Guide

© Yota 2014 6

Optional sections FAILOVER_GROUP, where nodes are grouped to a failover group. If

one of nodes from this group becomes unavailable sessions created on the node are

then processed by other nodes of the group.

2. DRA node configuration parameters:


DWR_INTERVAL DWR send interval, 6-30 seconds (30 sec by

default)

PEER_UPDATE_INTERVAL Interval between reconnect attempts and Peer

table scan

DRA_MSG_RESEND_TIMEOUT Request message will be resent after this timeout

if the answer is not received, in seconds (3 sec by

default)

DRA_MSG_DROP_TIMEOUT Request messages resend attempts will be

stopped after this timeout, in seconds (10 sec by

default)

MAX_DOWN_SECONDS After this timeout process that manages

interaction via Diameter closes all connections

CLEAN_OLD_SESSIONS_TIMEOUT Clean session mapping after this timeout, in

seconds. For example 21600 seconds – 6 hours

SUBSCRIPTION_TYPES Defines search priority of Subscription ID in

messages by type (IMSI, E164, NAI, SIP_URI,

PRIVATE, UNKNOWN)

DRA Configuration

© Yota 2014 7

DRA Configuration Example

Example components scheme and DRA configuration according to this scheme are presented below:

Figure 1. Example components scheme

Gx

P-GW

PCEFDPI

DRA

Gx Rx

Gx, Rx Gx, Rx

Video Streaming

AF

dra-1/2.scartel.dc

huawei-1/2.scartel.dc procera-1/2.scartel.dc af-1/2.scartel.dc

DRA

SPR SPR SPR

pcrf-1/2.scartel.dc pcrf-3/4.scartel.dc pcrf-5/6.scartel.dc(HIDE_PEERS) (HIDE_PEERS)

PCRF-A PCRF-B PCRF-C

dra.scartel.dcpcrf-B.scartel.dc

DRA configuration file example:

CLUSTER NAME PCRF-A REALM scartel.dc HOST pcrf-A.scartel.dc

FAILOVER_GROUP

PEER REALM scartel.dc ADDRESS pcrf-1.scartel.dc HOST pcrf-

1.scartel.dc HTTP_PORT 8080 MANDATORY AUTOCONNECT WEIGHT 100


2.scartel.dc HTTP_PORT 8080 MANDATORY AUTOCONNECT WEIGHT 100 BACKUP

FAILOVER_GROUP_END

CLUSTER_END

CLUSTER NAME PCRF-B REALM scartel.dc HOST pcrf-B.scartel.dc HIDE_PEERS

FAILOVER_GROUP





Yota DRA 3.6.1

Quick Start Guide

© Yota 2014 8

FAILOVER_GROUP_END

CLUSTER_END

CLUSTER NAME PCRF-C REALM scartel.dc HOST dra.scartel.dc HIDE_PEERS

FAILOVER_GROUP




6.scartel.dc HTTP_PORT 8080 MANDATORY AUTOCONNECT WEIGHT 100 BACKUP

FAILOVER_GROUP_END

CLUSTER_END

CLUSTER NAME huawei

PEER REALM scartel.dc ADDRESS ugw-1.scartel.dc HOST ugw-1.scartel.dc

MANDATORY

PEER REALM scartel.dc ADDRESS ugw-2.scartel.dc HOST ugw-2.scartel.dc

MANDATORY

CLUSTER_END

CLUSTER NAME procera

PEER REALM scartel.dc ADDRESS procera-1.scartel.dc HOST procera-1.scartel.dc

MANDATORY

PEER REALM scartel.dc ADDRESS procera-2.scartel.dc HOST procera-2.scartel.dc

MANDATORY

CLUSTER_END

CLUSTER NAME af

PEER REALM scartel.dc ADDRESS af-1.scartel.dc HOST af-1.scartel.dc MANDATORY

PEER REALM scartel.dc ADDRESS af-2.scartel.dc HOST af-2.scartel.dc MANDATORY

CLUSTER_END

DWR_INTERVAL 30

PEER_UPDATE_INTERVAL 10

DRA_MSG_RESEND_TIMEOUT 11

DRA_MSG_DROP_TIMEOUT 2

DRA_MAX_DOWN_SECONDS 10

SUBSCRIPTION_TYPES IMSI E164

In this configuration cluster PCRF-A has open for other clusters topology but PCRF-B and PCRF-

C have hidden ones.

There are one main and one backup nodes in PCRF-A cluster that are joined to a failover group.

Entire load will be processed by pcrf-1.scartel.dc node and only in case of its total failure

pcrf-2.scartel.dc node will start to process new sessions and sessions previously created on

pcrf-1.scartel.dc.

There are only mains nodes in PCRF-B cluster that are joined to a failover group. In this case

70% of load will be processed by pcrf-3.scartel.dc and 30% of load will be processed by

pcrf-4.scartel.dc. If one of the nodes falls down the other one will take the entire load.

There are also one main and one backup nodes in PCRF-C cluster that are joined to a failover

group. Entire load will be processed by pcrf-5.scartel.dc node and only in case of its total

failure pcrf-6.scartel.dc node will start to process new sessions and sessions previously

created on pcrf-5.scartel.dc.


© Yota 2014 9


DRA routes messages using the algorithm described by Lua scripting language. Using Lua gives the flexibility to configure message routing rules through DRA nodes.

Routing rules are described in /etc/dra/config/lua/engine.lua. This file can be saved

directly to /etc/dra/config/lua directory or uploaded via DRA O&M Console

(Configurations -> List Files -> Lua -> Upload button).

The list of functions that can be used in DRA engine.lua is available at:

http://<dra_host>:8091/doc/lua_info.html

Lua functions allow you to get different parameters values (origin-host, application, imsi) from

income messages and on the basis of these values flexibly decide to which cluster a messages

should be forwarded by function proxy_to().

Example of Lua file content:

function route_msg()

local app_name = get_application_name()

local cluster_name = get_source_cluster_name()

log_write(string.format("app_name = %s", app_name))

log_write(string.format("cluster_name = %s", cluster_name))

balance_by_session_id()

if get_source_cluster_name() == "huawei" then

log_write("relaying to PCRF-A cluster")

proxy_to("PCRF-A")

return 0

end

if get_source_cluster_name() == "procera" then

log_write("relaying to PCRF-B cluster")

proxy_to("PCRF-B")

return 0

end

if get_source_cluster_name() == "af" then

log_write("rejecting!")

reject()

return 0

end

-- default route:

proxy_to("PCRF-C")

end

In the example above cluster name is defined, where the message comes from.

If a message is sent by the cluster with name huawei then this message is forwarded further to cluster PCRF-A.

If a message is sent by the cluster with name procera then this message is forwarded further to cluster PCRF-B.

If a message is sent by the cluster with name af then this message is rejected.

Yota DRA 3.6.1

Quick Start Guide

© Yota 2014 10

Yota PCRF and DRA Interaction

Configuration

If DRA is used for serving of Yota PCRF signaling traffic then PCRF nodes must interact with DRA using Static Routes functionality. Static routing setup is described below.

All targeted nodes P-GW, DPI and DRA node must be configured on Yota PCRF nodes. At the same time static routing to P-GW, DPI nodes must be set through DRA.

There is two ways to set static routing on Yota PCRF nodes:

In O&M Console go to Configurations -> Network Topology -> Static Routes and set pairs

of values Diameter Proxy/Relay Peer ID (PEER_ID_FROM) and Destination Peer ID

(PEER_ID_TO), where Diameter Proxy/Relay Peer ID is DRA peer ID and Destination Peer ID is targeted P-GW, DPI peer ID.

OR

Set pairs of values PEER_ID_FROM and PEER_ID_TO directly in ADM.ROUTE_STATIC table of the PCRF database.

Yota PCRF tables content example:

select PEER_ID, HOST, REALM from adm.peer;

< 1, pcrf-1.scartel.dc, scartel.dc >

< 2, pcrf-2.scartel.dc, scartel.dc >

< 11, dra-1.scartel.dc, scartel.dc >

< 21, huawei-1.scartel.dc, scartel.dc >

< 22, huawei-2.scartel.dc, scartel.dc >

select PEER_ID_FROM, PEER_ID_TO from ADM.ROUTE_STATIC;

< 11, 21 >

< 11, 22 >

Important

In Yota PCRF the Diameter exchange process chooses the shortest traffic route. That is why

if Diameter auto connect is set to P-GW, DPI nodes the messages will be routed directly to

these nodes (bypassing DRA). Such situation disrupts the logic of interaction with DRA and

DRA can’t be used for signaling traffic centralization.

Therefore, autoconnect to P-GW, DPI nodes from PCRF and to PCRF nodes from P-GW, DPI

must not be set.

Parameter autoconnect can be set to DRA node only.

Maintenance

© Yota 2014 11

Maintenance

1. After the installation procedures have been finished the following processes must start on

the target DRA node:

root Ss /opt/dra/bin/dra -l debug -d -s 97794 root S< \_ /opt/dra/bin/dra worker 0

root S< \_ /opt/dra/bin/dra worker 1



root S \_ /opt/dra/bin/dra [RS] - dra resend

root S<s /opt/drug/bin/drug -l notice -d

root Ss dra_console: master process /opt/dra_console/bin/dra_console -c

460 S \_ dra_console: worker process

460 S \_ dra_console: worker process

root Ss /opt/stat_writer2/bin/stat_writer2 -l notice –d

root SNs /opt/trace_writer/bin/trace_writer -l notice -d

root SNs /opt/log_writer/bin/log_writer -l notice -d

root Ss /opt/rx_watchdog/rx_watchdog -d -l notice

2. To see Diameter messages exchange in the log file lv command is used in the command

line.

Log records example:

14-02-09 12:59:11.435 dra_MA[15817] NOTI GxCCR-I f:huawei-1 t:pcrf-1

h2h:52A5BE9A->2F000000 dest h:pcrf-1 r:scartel.dc

14-02-09 12:59:11.479 dra_MA[15817] NOTI GxCCA-I f:pcrf-1 t:huawei-1

h2h:2F000000->52A5BE9A orig h:dra-1 r:scartel.dc

These records describe:

GxCCR-I message was sent by the node with Origin-Host="huawei-1" to DRA node and

it would be forwarded to the node with Origin-Host="pcrf-1". While the message is been

forwarded Hop-By-Hop-Id value is changed from "52A5BE9A" to "2F000000" and AVP

Destination-Host value is changed from "dra-1" to "pcrf-1".

Then GxCCA-I message was sent by the node with Origin-Host="pcrf-1" to DRA node

and it would be forwarded to the node with Origin-Host="huawei-1". While the message

is been forwarded Hop-By-Hop-Id value is changed from "2F000000" to "52A5BE9A"

and AVP Destination-Host value is changed from "pcrf-1" to "dra-1".

Also Diameter messages exchange can be seen in O&M Console of DRA node, clicking View

Trace button, or at:

http://<dra_host>/trace/

3. Every minute /opt/dra/utils/dra_backup.sh script runs, which saves current session

binding to nodes.

If required the sessions binding can be restored by the utility:

/opt/dra/utils/dra_import

Documents

Yota DRA 3.6.1 Quick Start Guide