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 peers 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:
Parameter Description
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 peers 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:
Parameter Description
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
PCEF
DPI


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.dc pcrf-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
PEER REALM scartel.dc ADDRESS pcrf-2.scartel.dc HOST pcrf-
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
PEER REALM scartel.dc ADDRESS pcrf-3.scartel.dc HOST pcrf-
3.scartel.dc HTTP_PORT 8080 MANDATORY AUTOCONNECT WEIGHT 70
PEER REALM scartel.dc ADDRESS pcrf-4.scartel.dc HOST pcrf-
4.scartel.dc HTTP_PORT 8080 MANDATORY AUTOCONNECT WEIGHT 30
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
PEER REALM scartel.dc ADDRESS pcrf-5.scartel.dc HOST pcrf-
5.scartel.dc HTTP_PORT 8080 MANDATORY AUTOCONNECT WEIGHT 100
PEER REALM scartel.dc ADDRESS pcrf-6.scartel.dc HOST pcrf-
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.

Flexible Messages Routing
Yota 2014 9
Flexible Messages Routing
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 cant 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 worker 2
root S< \_ /opt/dra/bin/dra worker 3
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